Over the past few weeks I have been involved in a major SQL cluster roll-out and as such got my hands dirty with getting SQL 2008 R2 clusters built. With the release of SQL Server 2012 I decided I might just was well contrast the two builds for the fun of it. As it turns out the builds are very similar in the way the deployment is executed. I still thought it would be of value to go through the process step-by-step below.
Before you begin:
Prior to starting the SQL Server 2012 setup there are various requirements than needs to be in place. For the purpose of this article I am assuming that most of these have been covered including:
- Server hardware (incl. HBA’s) patching and firmware updates
- Operating system and patching
- Network patching for both external and heartbeat networks
- .Net Framework and Failover Clustering features added
- Cluster validation is done (and passed of course)
As with SQL Server 2008 the MSDTC service is still a required component prior to starting the SQL Server installation itself. If you fail to install MSDTC on both nodes you will be presented with the error message as shown below.
Let’s start the SQL installation.
Step 1: Start the SQL Server 2012 installation and select “Installation” – “New SQL Server failover cluster”
Step 2: Verify that all requirements are met. In my example I still have two errors (one relating to the server not having internet access and the second due to the way my virtual machine network is confirmed. In production please ensure that your binding order is set for the external network to have the highest priority.
Step 3: Accept the SQL Server 2012 terms and conditions. You can choose to send feature data to Microsoft to improve the product in future.
Step 4: To install SQL components choose the “SQL Server Feature Installation” option. If you wish to play or deploy PowerPivot the new data presentation tool choose the “SQL Server PowerPivot for SharePoint” option. If you have not seen PowerPivot I recommend you try it out since it is an amazing way to represent large tabular datasets in a very easy to navigate (and pretty) format.
Step 5: On the feature selection screen choose your components to install. Also decide where to place your shared Microsoft SQL Server installation files. Note that these file should be on the operating system or node specific drive. The shared files for each of the various instances of SQL that will be installed will be placed with the respective drive resources later in the installation.
Step 6: The feature rule validation will validate your feature selection against the node configuration.
Step 7: Next you need to select you instance configuration. In my example above I am only installing a single instance of SQL Server, but in production your requirements might be different. I would suggest that you create a named instance of SQL Server that allows you to create additional multiple instances (named) on the same cluster in the future. (Just to be clear, you will be able to create another instance at any time, but then you will have default and named instances on the same cluster).
Step 8: Review your disk space requirements for your shared configuration.
Step 9: Provide the name for the cluster group that will be created by the installation within “Fail-over Cluster Manager”.
Step 10: Select the disk resources that will be used within this cluster group to deploy the SQL features. In the case where you are deploying mulitple instances of SQL, try to ensure that you create descriptive names for the disk resources when you create and assign then in Windows Storage configuration. This will make it easier to find during this step. In my example, I am only deploying a single instances (with DB features as the primary goal), thus I only created 3 disk resources.
Step 11: Configure you network resource for the cluster group. Ensure that you remove the DHCP tick boxand specify an VIP on the correct subnet for you SQL Server instance name.
Step 12: Provide the required domain service accounts for the various SQL Server features. Something new I did notice is that when doing a single server local installation of SQL Server 2012, there is a set of new built-in accounts that can be used to deploy SQL Server (e.g. NTService\MSSQLServer, etc.). These are not available due to the requirement that a shared domain account has access to both the nodes while in a cluster configuration.
Step 13: Ensure your instance has the correct Collation type. Note that products like System Center 2012 require different collation types for components such as OpsMgr.
Step 14: Ensure that you authentication to the new cluster is enabled with the required auth mode as well as by specifying an administrator account(s) to be added to the SQL Server during installation.
Step 15: In the “Database Engine Configuration” -> “Data Directories” tab you need to specify the various data directories that will be used for the specific instance of SQL Server. You need to specify the “Data Root” which will contain the shared files for the instance. Additionally you have the option to specify where to place all new (and installation created) databases such as MDF, LDF, TempDB and Backup files.
Step 16: (Optional based on components). If you are installing Analysis Services you need to decide what data model the server will be using by selecting the “Server Mode”. Options include “Multidimensional and Data Mining Mode” or Tabular Mode”. If you want to play with the new PowerPivot features in SQL Server you need to select “Tabular Mode”. Additionally you need to specify the account(s) that will be granted administrative permissions to the Analysis Services features as part of the installation.
Step 17: As with the database features, the Analysis Features can be installed on their own set of disk resources. (In my example I have not created separate LUN’s for this so I will be using the existing resources. In production separate resources should be created, presented and assigned in this step).
Following this you will be presented with the final few cluster validation steps and configuration review. The cluster should start the installation process and complete the installation of the first node.
In Building a SQL 2012 Always-On Cluster – Part 2 of the article I provide an illustration of the process of adding a second node to the cluster.
Related articles: