In this series, I will demonstrate how to install a SQL Server 2012 clustered instance 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.
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 diles (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 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 Serve 2012.
What is a clustered instance?
Basically a clustered instance is a SQL Server instance installed over a Windows Cluster (WCF) service. The main purpose of WCF 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 diles (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 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 Serve 2012.
Prerequisites
Before we start the installation, we need to assure that we have the following items ready to be used.- A virtual hostname
- A virtual IP
- Available shared storage. The best practice is to have, atleast one for Data files(mdf and ldf) one for log files (ldf) and one for Tempdb fiiles.
- Service Accounts: One for SQL Server engine and another for SQL Server Agent (this is the best practice)
Note:- Notice that service accounts are domain accounts. We have no other choice, to build a cluster we need to be a part of a domain.
On this step by step guide, we will use the following environment - based on virtual machines
Our Environment
On this step by step guide, we will use the following environment - based on virtual machines
- Windows Server 2012 R2 nodes
- W2012SRV03 - 192.168.123..205
- W2012SRV03 - 192.168.123..206
- The both nodes are part of the following cluster
- W2012CLT02 - 192.168.123.111
- Storage:
- As this is a lab you can use 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
