Now that SQL 2017 is installed on both nodes, we need to configure the Windows Cluster service. Although SQL AAGs don't use the 'traditional' clustering technology of shared SCSI disks and a quorum disk, the clustering service is required to manage the state and failover the AAG instances.
For this procedure we will need one new IP address and a cluster DNS name. Get those ready before proceeding. The cluster name is only used for management purposes, and is NOT related to the SQL listener name. If DHCP is active on the server subnet the wizard will automatically pull an IP.
Microsoft has a technology called "Cluster Aware Updating" (CAU) which orchestrates the installing of Windows patches on hosts that are a part of a cluster. However, I think its utility is mostly aimed at Hyper-V hosts/clusters and less so at enterprise applications such as SQL. So I won't cover configuring CAU in this series.
​Cluster Role Installation
1. On the first SQL server launch Server Manager and select Add Roles and Features.
2. Select Role-Based or Feature-Based Installation.
3. Select the local server when prompted.
4. Skip the Server Roles page and on the Features page check Failover Clustering. When prompted, add the required features.
6. Continue through the rest of the wizard and wait for the installation process to complete.
7. Install Windows Failover Clustering on the second SQL node.
​Cluster Validation
1. On Node A launch the Failover Cluster Manager, and in the left pane right click on Failover Cluster Manager and select Validate Configuration.
2. Enter the two hostnames of the SQL servers you are configuring. Run all of the tests.
3. Review the cluster report for any errors. A warning regarding non-redundant NICs is normal, and can be ignored. If there are any other warnings/errors (such as a pending reboot due to patching), take the required action to remediate.
4. On the Validation summary screen check the box next to "Create a cluster now using the validated hosts..." and click Finish.
​Cluster Configuration
1. ​Enter the Cluster name (e.g. SQL2017CLA).
​2. In my case DHCP was active on the server subnet, so the wizard automatically pulled an IP from the pool and assigned it to the cluster hostname. If DHCP is unavailable the wizard will prompt you for an IP.
3. Validate that all of the cluster information is correct and UN-check the box next to the "Add all eligible storage to the cluster" option and click Next. Wait for the cluster to be built.
Note: If you forget to UN-check​ the storage box below, the cluster service may claim all of your SQL disks and they could disappear from Explorer. If they have disappeared, then go into the cluster manager and remove all drives as a cluster resource. Then open the Computer Manager and online each of the drives. Reboot the SQL server if you had to do this procedure.
​4. Review the summary screen to make sure all is well. You can safely ignore any warnings regarding a disk witness. We will configure a File Share Witness (FSW) in the next post.
5. Do a forward and reverse DNS lookup of the new cluster name to verify A and PTR records were created. Correct any issues.
​Summary
In this installment we configured the Windows failover cluster service, and created a new cluster. This cluster name is used only for management purposes, and not used for the SQL listener. Next up in Part 7 we will configure the File Share Witness (FSW).
SQL 2017 Installation Series Index
​SQL 2017 Always-on AG Pt. 1: Introduction​
SQL 2017 Always-on AG Pt. 2: VM deployment
SQL 2017 Always-on AG Pt. 3: Service Accounts​
SQL 2017 Always-on AG Pt. 4: Node A SQL Install​
SQL 2017 Always-on AG Pt. 5: Node B SQL Install​
SQL 2017 Always-on AG Pt. 6: Cluster Configuration​
SQL 2017 Always-on AG Pt. 7: File Share Witness​
​SQL 2017 Always-on AG Pt. 8: ​AAG Setup
​​​​SQL 2017 Always-on AG Pt. 9: Kerberos (Coming)
​SQL 2017 Always-on AG Pt. 10: SSL Certificates (​Coming)
​SQL 2017 Always-on AG Pt. 11: Max Mem & Email Alerts (Coming)
SQL 2017 Always-on AG Pt. 12: Maintenance Jobs (Coming)
