Compartilhar via

Adding mount points to a WSFC SQL Cluster ( FCI ) Instance

  • Artigo

 

In this blog post I will look at how you can add a mount point to a Windows Server Failover Cluster and use that mount point for SQL Server 2005 and later installations.   I already have the SQL FCI setup and configured, so at this point all I am going to do is add the mount point. 

 

The first step is to open up diskmgmt.msc and look at the available drive for the mount point.  Since this is on my laptop I have a specific VM setup just to share disks.  I created an iSCSI disk on that VM and make it available to my cluster.  At this point the drive doesn’t have a drive letter or mount point associated with it.

clip_image002

 

Next, I am going to go out to my M drive and create a folder to use for my mount point.  There are a couple of things to make note of here. First – my M drive is a resource on my cluster.  When SQL fails over from one node to another, so does my M (data) and L (log) drives. Since I am putting the mount point on a clustered resource, I ultimately have to make the mount point a clustered resource and I must make it dependent upon the SQL Server service itself.  I have created a folder in my M drive named MountedDrives which I will use as an entry point for the drive I plan to mount.

 

clip_image004

Here is what my SQL Server Failover Cluster Instance (FCI) configuration looks like.  I have 2 nodes in the cluster (FarmFCIA & FarmFCIB). FarmFCIA is the current owner and my disks 2 & 3 currently belong to that node.  Disk 1 (my quorum disk) is currently on node FarmFCIB.

 

clip_image006

 

Before I add a pointer to the mount point to FarmFCIA, I must first add the unassigned disk to the WSFC. Right click on Storage and select ‘Add a Disk’.  My available disk shows up and I add it to the cluster.

 

clip_image008

 

At this point, the resource is available to the cluster but it is not assigned to a cluster resource group. Right click on the disk, select More Actions, and then ‘Move this resource to another service or application.’

clip_image010

 

Choose my SQL Server resource and select OK.

clip_image012

 

At this point, a drive letter has been added to the drive.  However, we want to mount this drive in a folder on the M drive, so we aren’t quite done yet.

 

clip_image014

 

Open up diskmgmt.msc and choose ‘Change Drive Letter and Paths’ on the drive we intend to mount.

clip_image016

 

Navigate to the folder that we plan to mount the drive in and choose ‘OK’.

clip_image018

 

Now the cluster disk shows up as a mounted volume in Cluster Manager.

clip_image020

 

Next, I will add a dependency so that my mount point clustered disk relies on Clustered Disk 2 (the M drive where the mount point lives).  In this setup, my SQL Server service relies upon my Clustered Disk 2 (my M drive) and Clustered Disk 3 (my log drive). 

 

clip_image022

 

The SQL Server resource also must depend on Cluster Disk 4, which I am not showing here.

 

Failover the active node so that it lives on my secondary node, in this case FarmFCIB.  Note that at this point the mounted drive will no longer be visible in My Computer. 

clip_image024

 

I can navigate on node FarmFCIB and see that the drive has failed over.

 

clip_image026

To test the new drive, I’ll connect to my cluster resource name, SQLCluster in SSMS.

clip_image028

 

Create a new database that lives in the mount point location.

clip_image030

 

Failover the node again so that active node is currently FarmFCIA.

clip_image032

 

Refresh the Databases list in SSMS to ensure my database comes back online.  Voila!  A working mount point!

clip_image034

 

Thanks!

Tim Chapman, MCM

Comments

  • Anonymous
    August 28, 2013
    what about ntfs permissions?  You have not addressed that issue in this article.  As shown above this will work if your SQL server runs under an account that is a local administrator.  If your SQL Server service account is not a local admin (which it should not be) then you will run into permission issues when you attempt to create databases in the new mountpoint location.

  • Anonymous
    September 09, 2013
    Hi, Thanks for your comment.  You're right, I didn't cover permissions in this post - and your comment is correct.  I just happened to not have covered security permissions in this post. Thanks again, Tim

  • Anonymous
    April 16, 2015
    From my experience as I recall, you have to apply the NTFS permissions to the root of the new volume while it has a drive letter applied to it.  Sub-folders and files you can modify permissions after it has been moved to be a mount point still.  Otherwise, attempts to change the permissions of the root, will instead be applied to the folder your volume is mounted in. You should also consider adding some mention of why it is so important to make sure you set up the dependency of this new volume on the disk that you are mounting it to.  If it tries to mount before the other disk mounts, it will fail, and will leave the folder you were mounting to open, and any files created, will be written to that folder, causing it to no longer be an empty folder, preventing future attempts to mount your volume to it.