SQL first node cluster instance install Part 2

Part 2 – Install the SQL first node of the clustered SQL instance

This article focuses on the installation of the SQL first node in a Clustered instance. I’m assuming all the steps as per previous article have been accomplished. The installation of the first node is a very simple and straightforward process. Let’s run the setup.exe and then choose the New SQL Server failover cluster installation.

The wizard to add SQL first node starts by asking for the Product  Key. Let’s provide this one and move to the next screen.

Let’s accept the End User License Agreement.

Since we’re using SQL 2014 version we can ignore the warning about MS-DTC configuration as not required in this version. More info in the next screen by clicking on the link.

Since MSDTC service is now part of the “SQL engine” this does not need to be clustered as well. So let’s accept the message and move to the next screen.

Unless we want this particular SQL instance to be SharePoint specific we can go with the first option. The latter provides an integration by mean of SQL Server Reporting Services (SSRS) to report on various types of SharePoint Data. Of course it is possible to use SharePoint with the first option and integrate services at a later stage.

In my case this instance will also serve non SharePoint databases.

The basic selection of Database Engine Services and the Management Tools is what we need for our SQL first node. Let’s make sure to point to a local drive (P:\ in my case) and the same drive to exist with the same letter on the other nodes of the cluster as well. This is a SQL requirement and best practice.

Additionally I would recommend to install the SQL Management Studio to easily administer the SQL instance and SQL Server nodes.

Finally we can specify the chosen SQL cluster name. In my environment this installation will be used primarily for SharePoint hence the named instance after its purpose.

At this point as part of the SQL first node install the wizard will try to determine the available storage resources in the Windows Failover Cluster. Let’s click on next and check the available storage.

Let’s make sure all created disks as per previous article are selected. The first disk is not appearing in this list as it is already used as Quorum witness disk.

Let’s specify the IP Address associated with the SQL cluster VIP name. Ideally it’ better to configure multiple Networks and assign them to the cluster avoiding this only network to work as a single point of failure. Moreover considering we’re using  iSCSI connected drive a dedicated network should be used just for the storage without interfering with the Management network to operate the cluster and vice versa.

These in fact are also recommendation highlighted in the Cluster Validation Report. For a home lab this configuration is sufficient and with good performances.

In this case I’m using a single account for multiple services (hey don’t shoot me I’m only the piano player!)  but it is recommended to use dedicated ones for different services of course. Just type in the password and progress.

Standard collation should be fine for the vast majority of application databases and so does SharePoint.

As a precaution I like to use the mixed mode authentication on top of adding extra accounts as SQL Server Administrators. Domain Admins accounts should be avoided at all costs in favour of dedicated accounts for this scope with limited permissions only on selected Servers.

Now this is where things get a bit interesting: as mentioned in the previous article this is the part of the wizard where we can specify the location for the various SQL components and Databases. There are really plenty of considerations to do here on how to scale out SQL server installation including amongst other things:

• Using dedicated drives for separate components
  • Root Directory, Binaries, System Databases , User Databases, Backups
• Separate SQL Database Data drives from SQL Database Logs Drives
• Run a capacity planning exercise to determine how to distribute data across the drives also considering the data size current and future, number of CPUs, network throughput and storage IOPS

It would be definitely interesting to cover this aspects in a separate article focusing on this very topic. Now to our scenario for the SQL first node we can have something similar to this:

The wizard is now checking the Cluster features.

And it is also showing the main details for the configuration of SQL first node. Of course the second node will receive the configuration as part of the same Clustered SQL instance.

And a final screen shows the success of the operations. Let’s make sure to review all Statuses are “Succeeded”.

At the end of the installation of the SQL first node of the cluster we can revisit the Cluster Manager again. As expected a new Role has been created where the SQL first node of the cluster appears as the owner.

It is important to check / extend the ownership of the same role to all intended nodes before “failing over” the instance to these nodes.

Same thinking applies to resources like disks, networks and others.

So far we have completed the first part of the Failover Cluster SQL installation and when connecting to the SQL instance from the SQL first node we can already see we have technically a cluster consisting of one node. Not much if we intend to do a failover!

So let’s make this cluster more consistent adding a second node which will be part of the next article