In this series, I will demonstrate how to install a SQL Server 2012 clustered instance in a cluster of two nodes. In general, the installation will be done in two parts:
- New instance installation in one of the nodes.
- Add the other node to the existing clustered instance.
For a cluster with more than two nodes, we would need to perform the first step in one of the nodes, and repeat the second step on all other nodes.
What is a clustered instance?
Basically, a clustered instance is a SQL Server instance installed over a Windows Failover Cluster (WFC) service. The main purpose of a WFC solution is protect our systems from hardware failures.
In a scenario of a cluster with two nodes, we are talking about two servers, with similar hardware configuration, connected by a Failover Cluster service. Having one SQL Server instance installed over this solution, we can call this instance as a clustered instance. That clustered instance must be active in only one of the available nodes, and this means that the other nodes will be in IDLE mode, with no active functions.
Another important point is that the WFC accepts shared storage, which means that we need a SAN to store the database files (logs and data). However, the SQL Server binaries generated by the installation should be in a local disk.
Other than shared storage, we also have an option to store our database files into a SMB Fileshare, which is cheaper, but not as good as a solution using SAN. From SQL Server 2012 we have an option to store the TempDB isolated in a local disk, which brings lots of benefits.
This way, the WFC is a high availability solution and not a load balancing or a disaster recovery solution. We can reach this by having an AlwaysOn configuration, available from SQL Server 2012.
I’m assuming that at this point we already have a built cluster solution with two or more nodes. Normally, the DBA receives the environment ready to install the clustered instance. The WFC build is usually made by the System Administrators. However, I’m planning on doing another article explaining how to configure a WFC solution. Stay tuned!
Before we start the installation, we need to assure that we have the following items ready to be used:
- A virtual hostname. In our example we will use “SQL04″.
- A virtual IP, a.k.a vIP. We will use: 192.168.123.124.
- Available shared storage. The best practice is have, at least, one for Data files (mdf and ldf), one for Log files (ldf) and one for Tempdb files. On this guide I will use one disk for everything, to simplify, but this is a bad approach!
- Service Accounts: One for SQL Server Engine and another for SQL Server Agent (this is the best practice). We will use the following accounts: SSLABSVCSQLSRVENG and SSLABSVCSQLAGT.
- Notice that the service accounts are domain accounts. We have no other choice, to build a cluster we need to be part of a domain!
On this step-by-step guide, we will use the following environment – based in virtual machines:
- Windows Server 2012 R2 nodes:
- W2012SRV03 – 192.168.123.205
- W2012SRV04 – 192.168.123.206
- The both nodes are part of the following cluster:
- W2012CLT02 – 192.168.123.111
- As this is a lab, I’m using a Synology Diskstation as my SAN. Just for information, the IP is: 192.168.123.103.
- For SQL Server:
- vHostname – SQL04
- vIP – 192.168.123.124
- Version: Microsoft SQL Server 2012 (SP1) – 11.0.3128.0 (X64) - Enterprise Edition
Installation Permissions for the used login
To install the SQL Server I’m using the domain login called “SSLABdba”, which is part of the Administrators group on W2012SRV03 and W2012SRV04. The login “SSLABdba” is a simple user into the domain, without special permissions.
To proceed with the installation of our first node, see Part 2 of this series.
5 Responses to “How to install a clustered SQL Server 2012 Instance – step-by-step – Part 1”
Leave a Reply