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.



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.



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.


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.


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:





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!

Add Comment