Udostępnij za pośrednictwem

Disk Considerations for Large File Share Servers

  • Artykuł

While working here at Microsoft, I have noticed over the years that many administrators have been creating large single volumes for file shares. This has become more prevalent as storage space has become cheaper. With SAN attached storage, a disk can be carved to just about any size and I have seen single file share volumes in access of 80TB.

 

From an administration standpoint, having a single disk or volume that can grow over time as space is needed by the users is very simple to manage. All an administrator has to do is add more space to the end of the disk and extend the volume.

 

So here is a question you might want to think about. What happens if that disk or volume becomes unavailable? How long will it take to get the share back online?

 

Those questions are some a lot of administrators do not think about. For most, it is panic and a frantic rush to get the data to the users as quickly as possible and a call to Microsoft. If you ever had this happen to your file server, I’m sure you know the feeling when all the users are not able to access their data, especially if it is someone from upper management.

 

My goal with this Blog is to help minimize the effect of losing shares when a disk goes bad by using multiple drives and mount points.

 

Below are some of the reasons using Mount Points for large file shares as an alternative to having one large, single volume is a better option. 

 

  1. If file system corruption occurs, it may take days to run CHKDSK against a very large volume.
  2. Restoring data from backup can take hours or days.
  3. If the disk goes down or becomes unavailable, all users that use that share will not have access to their files.

 

When using mount points pointing to smaller disks, you are reducing the chance of all your users losing access to their shares in case of a disk failure. You also get a performance increase since data requests are spread out across multiple disks.

 

You can design this to where one disk would hold the mount points and the root share. The other disks will be used to hold folders that are split up between the users or groups of users.

 

In my example below, I use Disk U: as the mount point storage disk with a folder called “Users” as my root share. Then I create folders A-Z to be the mount points. The U: Disk size is 100MB

 

Disk U:\Users\A-D\

Disk U:\Users\I-L\

Disk U:\Users\M-O\

Disk U:\Users\P-T\

Disk U:\Users\U-Z\

Each folder (Mount point) would in turn be mounted to a disk.

 

A-D – Disk1

E-H – Disk2

I-L – Disk3

M-O – Disk4

P-T – Disk5

U-Z – Disk6

 

In this example, if one disk goes down, you only lose 1/6th of your data or user access, not 100% as with a single large volume. The other advantage of this type of configuration is running CHKDSK or restoring data from backup will not take as long if needed.

 

Increasing space on the mount point disks will also be easier. As users add files to the share, you can see what drives fill up faster and only add storage to the heavily used shares. You can also rearrange or add mount point folders to better accommodate usage so data is distributed more evenly across all disks and the disks size does not grow too large.

 

If you are configuring drives and shares for a new file server, then setting up mount points should not be much more configuration than normal. If you are going to implement this to an existing file server, it is much more involved as you would need a redesign of your currently used LUNs and would be much more time consuming.

 

Below are the steps I took to make the file share and mount points on my server.

 

1. Create the folder structure on the mount point drive.

clip_image001

 

 

 

2. Share the folder.

clip_image002

3. Create the mount points for each folder and disk.clip_image003clip_image003[1]

 

 

 

clip_image004

 

clip_image005

 

(Repeat step 3 for each folder/disk.)

 

4. Create user folders.

clip_image006

 

 

 

 

Additional information about mount points.

 

947021 How to configure volume mount points on a server cluster in Windows Server 2008

https://support.microsoft.com/default.aspx?scid=kb;EN-US;947021

 

318534 Best Practices for Drive-Letter Assignments on a Server Cluster

https://support.microsoft.com/default.aspx?scid=kb;EN-US;318534

 

812547 The Limitations of Using Mount Points on a Volume That Uses Shadow Copies in Windows Server 2003

https://support.microsoft.com/default.aspx?scid=kb;EN-US;812547

 

  

Best regards,

Michael Champion
Support Engineer
Microsoft Enterprise Platforms Support

Comments

  • Anonymous
    April 29, 2011
    The comment has been removed
  • Anonymous
    April 29, 2011
    RAID sets give good fault tolerance for hardware failures but does not protect from file system corruption, accidental deletion of a volume, or any other volume related mishap that may happen.  If you ever had to run CHKDSK or restore a backup for a large file shares, you would know what I am talking about.To give you an example, I have worked cases where customers didn't have good backups and had to run CHKDSK on volumes with 2TB+ of small files, it took almost a week to complete.  Fortunately the data was still intact but if they used mount points, the file server wouldn't be completely down and running CHKDSK on that one failed volume/disk would have taken a lot less time.  So, the big benefit of having mount points is you are not putting all your eggs (data) in one basket (volume).  
  • Anonymous
    May 01, 2011
    Hi MichaelThanks, I see the point now :-)
  • Anonymous
    May 02, 2011
    Thanks for this article, it forced me to think about large volumes from a different perspective.
  • Anonymous
    May 04, 2011
    What happens if the disk with the root share is lost? Is recovery just a matter of creating a new root share on a different disk and remapping your mount points? And since the root share drives are so small, do you recommend putting multiple root shares on one disk?
  • Anonymous
    May 10, 2011
    If the mount point disk is lost, it is a matter of recreating the mount point/folder structure and setting up any shares again.  As far as having multiple root shares on the same mount point storage disk, that's something which is really an administrative decision.  I personally would put them on different disks if the mount points or root shares are used for something other than user shares like Exchange or SQL.  
  • Anonymous
    May 21, 2011
    MichaelThat is a very nice blog. I have a question in my mind after reading the above post.  For a existing file server if mount point are created then would there be any issues with there NTFS permissions? Is there any possibility of the NTFS shares getting effected?Thanks
  • Anonymous
    May 27, 2011
    The comment has been removed
  • Anonymous
    June 14, 2012
    Jeff,I've seen lots of information about the use of mountpoints in 2008 clusters.  The info on "backing up" the data on those mountpoints (and the associated mountpoint mappings) is pretty sparse/inexistant.  Do you know where I can find info about:  1) Backing up Data on Mountpoints using DPM 2010 or DPM 2012.  2) Capturing a mountpoint configuration (script, utility, etc)?Thanks for your help!Rob
  • Anonymous
    August 14, 2015
    What`s the behavior of this in a cluster file share??
  • Anonymous
    October 16, 2015
    I'll thought out. Do not do things this way in an Enterprise Environment.