Install a clustered SQL instance Part 2

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

This article focuses on the installation of the first SQL Cluster node. 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. 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

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.

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 per different services. 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

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

At the end of the installation of the first node of the cluster we can revisit the Cluster Manager again and as expected a new Role has been created where the first node of the cluster appear 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 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

Michele Domanico

Passionate about Virtualization, Storage, Data Availability and Software Defined Data Center technologies. The aim of is sharing with the Community the knowledge and experience gained with customers, industry leaders and like minded peers. Always open to constructive feedback and new challenges.

Leave a Reply

%d bloggers like this: