In continuation of our series on how to install a SQL Server 2012 clustered instance, let´s begin the actual installation, starting from the first node.
The objective of this second blog post in my series of three is to demonstrate how to install the first node of a clustered SQL Server 2012 instance and how to basically manage it from the Failover Cluster Manager tool, on Windows Server 2012 R2.
Just to refresh our memory, this is our infrastructure:
For more details about the prerequisites and a general explanation, check out Part 1 of this series.
The installation: Starting from the very first node
So let’s start the installation. If you remember, I mentioned that we have two steps to complete the installation on both nodes. For now we will start doing the new instance installation in one of the nodes. This node will be W2012SRV03.
- With the SQL Server installation binaries available, click “Setup”:
- The SQL Server Installation Center will open. Click “Installation” in the left menu, then select “New SQL Server Failover Cluster Installation”:
- A check will run in order to find possible constraints when installing the SQL Server Setup support files. At the end of the check, click “OK”:
- Now the installation will check for available updates, I recommend that you include those updates into the installation. Click “Next”:
- At this step, the setup support files will be extracted and installed, click “Install”:
- Finally, we have all the setup files installed. Another check will run in order to validate if problems might occur when SQL Server files is installed.
Best Practice:
It’s recommended to have a clustered MS DTC resource, as well as a dedicated MS DTC resource dedicated to each SQL Server group.
Here is a link to a good resource about this theme: https://blogs.msdn.com/b/cindygross/archive/2009/02/22/how-to-configure-dtc-for-sql-server-in-a-windows-2008-cluster.aspx - At this step, just insert the product key and click “Next”:
- Select “I accept the license terms” and click “Next”:
- To install a SQL Server clustered instance, choose the first option “SQL Server Feature Installation”. Click “Next”.
- Here we have few options to install on “Instance Features” and “Shared Features” sections.
For “Instance Features” pick the “Database Engine Services” item.
For “Shared Features” pick “Management Studio (complete)”.Another important point here is the directory that the shared tools will be installed. A good practice is have a dedicated local disk to install SQL Server related files. In the image I’m using the drive C, the same that I have my OS. This is my lab, so I advise that this is not a good practice for a productive system. Click “Next”.
- At this step another check will run, this time to identify problems that might block the setup, based on our choices of the last step. Just wait for its completion and click “Next”.
- This is an important step: Here we will define the instance network name (one of our prerequisites), whether we will use a default or name instance, the Instance ID and the instance root directory.A few things to consider here:
– On “Detected SQL Server instances and Features on this computer” section, we already have one instance installed. So I had to use a named instance and change the Instance ID to do not conflict with the existing one.
– Based on the information above, to connect to our instance we will need to use: SQL04\\DB.
– Another important point is the “Instance root directory”: It’s recommended to use a dedicated local disk to install the SQL Server binaries. Avoid using the system drive, a.k.a. “drive C”.Fill and verify all the points an click “Next”: - This step confirms if the disk space requirements are being met. Click “Next”:
- Now this is related to the Cluster Resource Group name to be used. The installation suggests a name, but you can change it.
This window also shows the reserved and already used Resource Group names. Change the Resource Group name if you are not satisfied with the suggestion and click “Next”:
- Now the disks! Another piece of the prerequisites has been shown. At this step, we will have the information of all available storage to be used on our new clustered instance.
As mentioned before, I have only on available disk for this guide, so let’s use this. Just select the desirable disks and click “Next”:
- Do you remember the requisite of an IP? It’s time to use it! Just pick the network that you will use, unmark the DHCP column and fill the address column with the value of the IP. And… “Next”:
- Here is our last requisite: Service Accounts. Fill the information about the SQL Server Engine and Agent service account (login and password).
Note: For a clustered instance, the “Startup Type” for the services should be as “Manual”. The Cluster Service will manage this for us.
Click “Next”.
- At the same step, we have another tab where we can define the collation to be used in our database engine. By default it has “Latin1_General_CI_AS”.
For more information about collations, click here. This can be a very important choice! If you have an special collation requirement, don’t forget to select the right one during the installation, otherwise you will have a hard work ahead to change this. - Now we need to choose the authentication mode of our instance.The options are either “Windows Authentication”, which will take benefit from domain and local server logins, or “Mixed Mode”, which accepts Domain/Windows logins as well as logins created and managed by SQL Server.If you pick “Mixed Mode” a login called “sa”, member of the “Sysadmin” role will be enabled. For this reason we need to specify the password for this login.In the box bellow, we need to add all domain/Windows users that have access to the instance and will be part of the “Sysadmin” fixed server role. You need to use the three buttons to add/remove logins from this list:
- Now it’s time to define the disk strategy.This step worth an entire article — I’m using only one disk for demonstration purposes, but the recommendation is to use one isolated disk for each one of the points.
The general rule here is: The most spread, the better!We could use a layout like the following:
The only thing that we cannot specify directly is a place to store the non-clustered indexes. This separation of the non-clustered and clustered index is a case aside.
Points to take attention here:
- Isolate the TempDB in a fast disk. Remember: From SQL Server 2012 we can store the TempDB in a local disk on clustered installations!
- Place your data files in one disk and log files in another one.
- Request the disks with an appropriate RAID level.
- Pay attention to the partition offset and block size before the installation, even if you are using a Windows 2008+ OS.
After consider all those points, set carefully the disks for each point and click on “Next”.
- Here you have an option to send error reports or not. Click “Next”:
- Another check will run to verify if the failover cluster installation will be blocked. After the check, click “Next”:
- Here we will be able to review all chosen options. Review and click “Install”:
- The installation will begin — wait for completion.
- In the end you will have a confirmation about the success or not of each feature installation.
You are done here! Click “Close”:
On this second part, we passed for all the steps to install the first node of a clustered instance. Of course some points will be slightly different from your environment, but here are pretty much all the steps to follow. After the completion of this installation you will need to add the other nodes to this clustered installation and you will be able to see the SQL Server “Role” created into the WFC Manager.
Dealing with Failover Cluster Manager
As we already have one node of our clustered instance installed, we will need to manage its resources using the Failover Cluster Manager tool.
- Click on the “Windows Key”+R.
- Write “cluadmin.msc” and click on “Ok”.
- The Windows Failover Cluster will be opened.
On the image you can see two “Roles”, representing two clustered SQL Server instances. The labeled as “SQL Server (DB)” is the one that we installed (Do you remember the choice made on the step 14?).
Selecting this Role will show all the resources that are part of this clustered installation, such as IPs, Disks, etc.
At this point, we have the clustered instance installed into one node only, so we cannot do a failover yet.
To stop the SQL Server, which will stop also the SQL Server Agent, right-click over the SQL Server Engine service and do the following:
In other hands, to start do the following:
Note: When you start the SQL Server, the agent service needs to be started also. One way to reduce the number of steps is first start the Agent, this way, the SQL Server Engine will start automatically. The reason is that the SQL Server Agent is dependent of the SQL Server Engine, this way WFC will try to start the Engine service prior to start the Agent.
Another very important item are the dependencies of our SQL Server.
To check that:
- Right-clicking the SQL Server Engine service.
- Click on Properties.
- Select the “Dependencies” tab.
This way you can see all the resources that the SQL Server Engine is dependent. Looking for our picture, if either the “Cluster Disk 1” or “SQL Server network name (SQL04)” fails, the SQL Server Engine will shutdown/failover!!
All the clustered resources can be dependent of another resource. For example, the “SQL Server network name (SQL04)” is dependent of the IP. This way, if the IP fails, the resource “SQL Server network name (SQL04)” will be offline and this will fire a SQL Server failover/shutdown.
What to take from here?
Check the dependencies and conditions on this tab, this can be useful to increase you availability rate!
As a practical example:
All the disks are important, but if the backup disk fails, we can continue with the service online, and fix the problem in background. But, if the SQL Server is dependent of this disk, we will have a failover/shutdown.
So, pay attention to this!
What’s next?
After completing the second step, we already have our instance working on a clustered environment, but we have only one available node. We will complete this series with more two parts:
- Adding another nodes to our WFCI.
- Configuring a dedicated MS DTC resource for our SQL Server Role.
If you haven’t already read it, find the first blog post in this series, Step-by-Step Installation of a SQL Server 2012 Clustered Instance — Part 1.
Next, find the third blog post in this series, Step-by-Step Installation of a SQL Server 2012 Clustered Instance — Part 3.
Finally, find the fourth blog post in this series, Step-by-Step Installation of a SQL Server 2012 Clustered Instance — Part 4.
Pythian is a global leader in data consulting and managed services. We specialize in optimizing and managing mission-critical data systems, combining the world’s leading data experts with advanced, secure service delivery. Learn more about Pythian’s Microsoft SQL Server expertise or check out some more SQL Server-related blog posts.
20 Comments. Leave new
You show the SAN on the same network as the public LAN, it should be noted that the heartbeat and storage networks are segregated from the public LAN. This is both for security and performance
Regards Perry
Hi Perry,
Thank you for your comment.
The intention of this article was show how to install the SQL Server 2012 in cluster.
But yes, you are right, it’s a best practice to have a different LAN for storage, front end and back end access, to transfer backups, etc.
Thank you again for your contribution.
Murilo
Hi!
Great article… We are looking to upgrade our SQL cluster environment because of old hardware. A few questions I have… We currently have 2 nodes(2-HP DL380 Gen 5 server) in the cluster and one direct attached storage connected with a SAS cable. The hardware is old so we need to upgrade the hardware and OS. Preferably Windows 2012r2, now do I need to purchase a new direct storage (HP MSA) or I can I just fill the server bay’s up with hard-drives therefore no need for a MSA? Thoughts? Thank you and it is greatly appreciated!
Hi Joel,
I’m glad you liked the article.
About the storage, to get a precise answer, the best is contact the support of Microsoft and HP :)
Thank you!
hello
i would like to ask if sql 2012 standard edition supports the configuration you made in this topic.
Yes, you can do this without problems.
Hi Murilo. Thanks for posting this series, it’s been a big help in getting started with this subject. One question; you use “F:\etc etc etc” when setting up your Data Directories but I can’t see where you defined your F drive. I assume this is NOT a local disk, it’s on your shared storage. Where/when do you assign the F drive to your node? Was this done through the Failover Cluster management “Storage” interface? Cheers. Ben
Did you get an answer to this Ben?
I am assuming the drives are configured when the actual Windows Failover Cluster is created, and that the drives are hen visible to the SQL Install, but I would also be interested in some clarification on this.
at some point we had issues when installing the node on one server and showed that there was missing X drive and installation failed due to that. We added that drive and proceed for new install and was success, so now can we get rid of those X drive in 2 servers and move the files to other drive if moving the Bin files will cause any harm to current SQLs.Can you please let us know
Hi Sui,
If this X drive is storing database files (even system databases) you can move those DBs to another disk and remove the drive from the SQL Server role. Anyway, take care with this movement, otherwise you can break the instance.
Hello guys,
any help would be greatly appreciated thanks
we have two node cluster installed in the virtualized environment with RDM mapping in single esxi host, when we are trying to validated the cluster am getting error, its stating “validate scsi -3 persistent reservation failed”
So what we have done is we added the data and log disk in the MSDTC resource, after that validation is success but am getting some of the warnings we skipped and installed the sql cluster.
is ths correct way to configure and it will make any problem moving to prodcution
Configuration details:-
Quorum disk, network ip
MSDTC Disk, Network ip
Data Disk under MSDTC resource groups
Log Disk under MSDTC resource groups
Hi Arun,
If the MSDTC in cause is in a separate cluster role, SQL Server won’t be able to use any of its resources. If it’s into the SQL Server’s role, you can (I mean, it’s possible to) use the disk to store data and log files, although this is not recommended.
I have tried and tried and tried but every time I get a validation error on failed shared disk check.
I set up the cluster and iscsi volumes using the server 2012 manager.
Drives are not csv volumes and each has a drive letter.cluster currently has no roles but has 2 nodes and all storage listed under disks. There are no errors or warnings when running complete cluster validation.
Do you have any pointers at all.
Running hyper-v vms and iscsi to a qnap has. All running windows server 2012 data centre edition and standard for ty’s guest vms.
Great article as well.
Many thanks.
Hi Craig,
If the storage was initialized, associated to a letter, is accessible and added to the cluster service as available storage, maybe the problem is related to access permissions.
I need more details in order to help here. What’s the error that you are getting?
i have a 2 node cluster with two instance of sql2008R2.So if i need to create one more instance in clustered mode with sql 2012 .How can i achieve this.I dont need to interrupt current cluster instances.
Thanks ,
Mukesh
I my opinion- no you don’t need the interrupt the current cluster instance. add node 3 to windows cluster and run sql server install add cluster node option. Should take care of it. But i didn’t try this.
Hi Murilo,
The services account that has been used is it normal domain user account. Do i need to set special permission for it?
Thanks.
Can you please load part – 3 of this series ?
Hi Murilo,
What is your recommendation regarding the size of the disk for the Data root directory (which will include the system databases, data and log files, except tempdb).
I’m planning a SQL Server installation in a cluster and I want to configure the disks like this:
– 1 disk for MSDTC (512 MB)
– 1 disk for Data root directory (which will include the system databases, data and log files, except tempdb)
– 1 disk for Tempdb (data + log files)
– 1 disk for data files of user databases
– 1 disk for log files of user databases
Please let me know if you have a size recommendation for the Data root directory. If you have any improvement on my disk configuration, don’t hesitate to share it :)
Regards,
Bogdan