While teaching last week at our Tampa Immersion Event, I mentioned the support for SMB as a storage in SQL Server 2012, which is allows you to create a Failover Cluster without shared storage on a SAN, and is documented in the following Books Online topics.
Install SQL Server with SMB fileshare as a storage option
Hardware and Software Requirements for Installing SQL Server 2012 : Storage Types for Data Files
Someone asked the question about whether SMB could be used for the shared storage for a failover cluster in SQL Server 2012, and I had to go do a little research, but I found that it was a supported configuration.
AlwaysOn Failover Cluster Instances (SQL Server)
Before Installing Failover Clustering
Last year, Kevin Farlee from the Storage Engine Team blogged about the changes in the SMB stack that make hosting SQL Server databases over SMB 2.2 a feasible prospect in his blog post SQL Databases on File Shares – It’s time to reconsider the scenario. Additionally the SQLCAT team, actually Kevin Cox specifically, blogged about the use of SMB for hosting database files in the Top 10 Hidden Gems in SQL Server 2008R2 post. Now that this is a viable alternative to expensive SAN’s it is not surprising to see that it is also a viable storage option for SQL Server Failover Clustering in SQL Server 2012.
(Note: SAN infrastructures provide a lot of additional benefits that a single server hosting a file share doesn’t, so before you run out and place a mission critical SQL Server database on a SMB file share, make sure that you understand the implications of doing so, and the trade offs that you are making in the process.)
Building the Failover Cluster in Windows
Building the Failover Cluster in Windows is essentially the same as building a standard Failover Cluster for SQL Server, with the exception that you have to skip the Disk checks in the Cluster Validation Tool, and then override the failed checks to actually form the cluster. To do this, select the option to Run only tests I select on the Validate a Configuration Wizard.
Then collapse all of the parent nodes in the treeview and uncheck the Storage checks and run the cluster validation.
When the validation tests complete, review the report and make sure that you have a supported configuration for failover clustering.
Then click the No option on the Validation Warning page and create the cluster by providing a Cluster Name and IP Address.
Configuring the File Share for Failover Clustering Support
The first step in setting up a Failover Cluster instance for SQL Server that uses SMB for its shared storage is to configure the File Share server to support the clustered instance being able to connect to it with the appropriate permissions to manage the SQL Server databases. Since there is no shared storage in the environment, there is an additional requirement, if you are using a 2 node Failover Cluster, that the File Share will need to be the witness in the quorum configuration using Node and File Share Majority. The requirements for this are documented in the Exchange Books Online (I tried to find a SQL Server Books Online or Windows Server Failover Clustering Books Online entry that provided the correct details and couldn’t) http://technet.microsoft.com/en-us/library/bb676490(EXCHG.80).aspx. Essentially, you need to have a separate File Share for the quorum, and a separate File Share for the SQL Server instance to use for data storage.
Note: I didn’t initially set my environment up this way, and due to the time it took to create the screenshots for this blog post before filling in the text, I chose to not go back and correct this error, but as a best practice, you should have separate shares for the quorum and SQL Server instance installation if you choose to use SMB for a failover cluster. This is documented in the Windows Server Failover Clustering Books Online. http://technet.microsoft.com/en-us/library/cc770620(WS.10).aspx
The first thing you want to do is Provision a new Share using the Provision Share context menu item from the Share and Storage Management node on the File Server.
Then you need to provide a path for the storage of the share. If you are actually setting this up, perform all these steps twice to create two separate shares with the necessary permissions.
Then you want to manually edit the NTFS Permissions for the File Share being created.
For the Quorum Share, you need to provide the Failover Cluster Virtual Computer Object (VCO) account Full Control of the Share in NTFS. The VCO is the ClusterName followed by a $ in Active Directory, and you will need to click the Objects button to add in the Computers object for the search to find the account. For the installation share, the SQL Server Service Account will require Full Control permissions in NTFS.
The next step is to provide a name for the File Share(s) that you are creating which will be the path to the share for configuring your quorum and then your Failover Cluster installation.
I am skipping over the SMB Settings window and going to the SMB Permissions where you will need to customize the share permissions for the specific Users that need to access the share to minimize security issues in the environment.
Just like with NTFS, for the Quorum Share, you need to provide the Failover Cluster Virtual Computer Object (VCO) account Full Control of the Share. For the installation share, the SQL Server Service Account will require Full Control permissions over the Share.
Then create the share and you are ready to configure the quorum settings for the failover cluster.
Configuring Quorum Settings
To configure the Node and File Share Majority quorum for the cluster, required only if you have an even number of voters in the configuration which is typical for 2 node clusters, click the Configure Cluster Quorum Settings menu item from the failover clusters context menu.
Pick the Node and File Share Majority radio button.
Then Browse for the shared folder and type in the name of the File Server that is hosting the SMB share for the quorum.
If all the permissions are configured correctly, you will have a successful configuration of the quorum in the environment.
Installing the Failover Cluster Nodes
For the interests of brevity, I am going to skip showing all of the standard Failover Cluster installation setup screens and only show the ones that matter for the configuration using SMB as the shared storage. For the instance features in this blog post, the Database Engine, Client Connectivity, Client Connectivity Backwards Compatibility, and Management Tools have been selected for a minimum install in the environment. Everything is exactly the same as it would be in a standard SQL Server Failover Clustered instance installation until you get to the Cluster Disk Selection page of the installation. Here there will be nothing shown in the environment, and what is interesting in comparison to SQL Server 2008R2 and previous is that you still have the option to click Next.
The next page of interest is the the Database Engine Configuration page, where you will provide the UNC path to the SMB share for the Data root directory, and if you have multiple shares that target different physical disk arrays in the File Server for the instance you could also specify those UNC paths to achieve physical isolation of the I/O for logs, data files, tempdb and backups following best practices.
Notice the warnings about the file server being specified as the data directory. If you double click on one of the warnings it will produce a dialog box similar to the following box.
If you don’t get the warnings, don’t worry, you will still get the above warning dialog box as soon as you click Next on the page.
After this last warning Setup will proceed as normal only it will install into the File Share everything that would have been on the shared disk in a standard configuration with a SAN. Once the first node is setup, you can then proceed to run setup on the additional nodes and they will work just like a standard failover cluster configuration would against a SAN.
Once all of the setup completes, you can validate the location of the database files using the sys.master_files DMV in SQL Server.
The SMB storage option lets you get past the 25 instance limitation for SQL Server when using shared disks with drive letters assigned, since each instance requires a separate drive letter. Using SMB up to 50 instances can be installed in a failover cluster, which provides a significant increase in the number of instances you can get over using a SAN. The improvements in the SMB stack make this a much more viable solution to expensive shared storage implementations using SAN hardware, but as I pointed out earlier, there are still considerations that should be made about the level of redundancy and other benefits that are provided by SAN implementations before you determine that a SMB solution for shared storage in a failover cluster is appropriate for your specific environment.
27 thoughts on “SQL Failover Cluster without Shared Storage – SQL Server 2012 and SMB”
HI, what would be your suggestion about using SMB o iSCSI SAN… Actually I have one VM on Hyper-V for SQL Server 2012 that use Virtual HD on one LUN that have 8 HDs 15k 146Gb… What you think… It best configure SMB over these LUN and put system database there?
Thanks for your answer…
There is no where near enough information provided to be able to offer you an idea for what is the ideal configuration. A failover cluster isn’t the best answer to high availability in every scenario, and no matter what configuration you use, you still have a single point of failure in the iSCSI SAN or SMB storage for the system so that is something else to consider. If you have a SAN, I would consider using it first for a lot of different reasons.
In the SQL CAT Lab, we’re looking forward to testing not only Kevin’s work, but also now yours. Thanks, Jonathan
Nice explanation Jonathan, as always.
I am assuming that we don’t get any errors as such when we are installing SQL Server 2012 cluster install via command line and using SMB fileshare?
What would the appropriate steps be to convert an existing SQL 2012 cluster that uses a shared SAN to a cluster that just uses and SMB share?
Thanks for this article,it’s working perfectly for the db but SSAS don’t accept these method ( crashing during the validataion phase on the beginning of the installation) Do i need to setup something else for using SMB and SSAS with fail-over ?
All the best
Is it fair to say that for any 2 or even number of windows clustering would require to setup Quorum? i.e. applies to 2 servers clustered for SQL 2012 AlwaysOn
To configure the Node and File Share Majority quorum for the cluster, required only if you have an even number of voters in the configuration which is typical for 2 node clusters
Voting for quorum for failover clustering is always based on maintaining an odd number of votes, even in Windows Server 2012 where Dynamic Quorum is possible. It is about configured node weighting for votes towards quorum and not strictly based on the number of nodes participating. This applies to AlwaysOn Failover Clustered Instances and AlwaysOn Availability Groups, two distictly different features using the AlwaysOn marketing brand in SQL Server 2012 (http://msdn.microsoft.com/en-us/library/ms190202.aspx).
Right, that makes sense. Node weighting for votes towards quorum is the key to setting up any cluster to avoid split-brain.
How do you get around the Features Rules check within SQL Server setup. It keeps telling me there are no suitable cluster disks… :/
Press back and uncheck “Analysis Services” to get round this.
How to configure SMB on win server 2012?
Our DBA’s are setting up a SQL AO 2012 cluster. Here’s my first question: They have asked for 2 sets of SAN volumes, one for each node but all these exist in the same data center – and the storage is on the same storage device? What sense does that make?
Second question – we use virtualized storage with Easy Tier SSD’s. If one volume of a cluster is active enough to be moved to SSD, isn’t it’s mirror going to qualify as well? If I exclude one and the other gets moved, the speed is only as fast as the slowest component so Always On is wasting SSD’s for nothing. I just can’t see the advantages of having an Always on cluster in the same data center.
I’m working at a two node sql server 2012 (Sql server 2012 Standard Edition) cluster built on 2 vm in Iaas Azure.
Can I use Azure file service as smb share for sql database and for witness in the quorum?
Thanks for your answer!
Can I create a shared storage on one of the node or it has to be somewhere else on the 3rd server?
It should be on a third server, separate from the cluster nodes.
Thanks . Great information..
Can I add another node instead of the file shared quorum in windows 2012 R2, this is for multi site cluster, the file share gives some permissions issues ? what will be the risk to have a that node instead of the Quorum?
You could do that if you wanted, so long as it had odd number of votes, but the challenge is that if you stretched sites in a geo-clustered implementation, you can’t move the node as easily as you would a fileshare witness in a failover, so it is in the same datacenter as the current primary/owner node.
This is definately a low cost option.
But, Would it not impact the SQLServer IO ?
SQL server is always senstive for Disk IO and if we create the databases on SMB File share, we have added Network Latency to access the MDF and LDF files ?
The changes in SMB and improvements in ethernet speeds make it possible to achieve 97% storage throughput of direct attached storage when setup properly. Microsoft has a number of videos on Channel 9 like this one:
that go into how this works and performs for SQL Server workloads.
Thanks for the article. I had the setup successfully done following the steps. However I had difficulty adding DTC to the failover cluster due to unavailable storage error. What do you propose for a workaround?
I would recommend that you read Shon’s post on MSDTC. https://blogs.msdn.microsoft.com/alwaysonpro/2014/01/15/msdtc-recommendations-on-sql-failover-cluster/
This guide is absolutely brilliant – easy to follow and came across no issues. I know this is a late post as this document was posted a good few years ago.
My only problem here is what if the File Share for the Quorum and SQL Data file goes down? Isn’t this essentially a single point of failure?
Do you have any tips or advise on removing this single point of failure? Would it be possible to have a File Share Cluster without Shared Storage(SAN)?
In Windows Server 2016 S2D allows a clustered file share without a shared disk and you also now have the option of a cloud witness in Azure for the cluster.
I have a Sql 2014 cluster without enough SAN storage. Can I, for a while, keep the datafiles on a local storage and access the databases?
In fact I want to mix the SAN storage with the local storage.
No you can’t do this until Windows Server 2016 with Storage Spaces Direct (S2D). The only thing that can be on local storage outside of S2D is tempdb starting with SQL Server 2012.