0

I have a 4TB iSCSI LUN that formated as NTFS in Windows 2008. I've shared this formated volume as a folder over SMB. When the capacity of this volume is not enough, I have to add more iSCSI LUNs, but the end-users must see only the folder that I've shared before. So, when I expand the NTFS volume that is currently 4TB, with more iSCSI LUNS(for example 2 more 4TB LUN), if one of the luns is failed, or missing, will all of my data in the folder be lost? I imagine that the expanding ntfs volume is like RAID 0(striped). if it is like RAID 0, then all my data will be lost when one of the luns is failed, or missing. In brief, there are two questions in here: 1- What will be happened, if one of the luns is missing in an expanded ntfs volume? 2- Is there another way to merge all of iscsi luns as only a folder, in that way the users don't see any extra folder even if I add extra iscsi luns to the file server.(I don't mention about DFS) Regards.

2 Answers 2

3

You are correct, spanning one volume over multiple LUNs increases its vulnerability to outages. This isn't strictly Raid0, as that implies a striping regime. This is merely one volume on multiple storage entities. If any one LUN goes missing the chances of dataloss are certain. The scale of the loss varies, as files can exist on one, two, or all LUNs in the spanned volume. NTFS doesn't provide a way to isolate directories onto physical device members of a spanned volume.

1
  • Sysadmin is right, rather than raid 0 it is more akin to JBOD. You could, in theory, allocate 3 4TB luns and use windows' software raid 5 to provide some level of parity and recoverability, but this isn't an ideal solution either.
    – Alex Berry
    May 7, 2014 at 10:26
1

A simple solution would be to move some of the directories to another disk and link to them using hardlinks (or junctions). Its transparent to the user. Thus you could put 100Gb of files on 10 luns and make 10 links, one to each of these directories from the main shared directory (assuming a simple world and they were equal sizes). Each of these 100Gb luns could be on a separate Nas, each with its own Raid setup. You can use this technique to move stuff off the c: disk on systems which have temp space problems.

I've done something similar where data was organised by year. Years 2014, 2013, 2012 were on the local disk of the server. Previous years were just junctions pointing to directories on an iSCSI volume used for archiving. The users could not tell the difference.

2
  • This would work too, although there are storage provisioning considerations in this scenario, i.e. you wouldn't be expanding the whole drive, rather you would be splitting storage allocations between different folders.
    – Alex Berry
    May 7, 2014 at 10:30
  • Its a compromise solution, but its simple and it works with a minimum of effort. Its easy to manage as well so long as you make a decision early on as to how the structure is going to be divided. In the end this is exactly how the unix file systems work, so its hardly something new.
    – Ian Murphy
    May 8, 2014 at 13:20

You must log in to answer this question.