I a big believer in SQL Server's Always-On technology. With storage being cheap, and the fast fail-over of an Always-On server, there is no reason to use the older clustering technology that required shared storage and could take up to 30 seconds in my experience to start the SQL Database Engine and complete the fail-over. With Always-On, there is also the ability to do “geo” based replication and fail-over. Geo-Replication enables you to configure readable secondary databases in the same or different data center locations. Secondary databases are available for querying and for fail-over in the case of a data center outage or the inability to connect to the primary database.
Here is how I set-up SQL Server 2016 Always-On Clusters. For these examples I'll use the following assumptions:
The first step is to install Install Windows Server 2012 R2 on both nodes. I also add two additional disks: one for data and one for logs. I also format them with 64K allocation units which I think gives SQL better performance:
$disks = @( $(Get-Disk -Number 1), $(Get-Disk -Number 2) ) foreach ($disk in $disks) { Set-Disk -Number $disk.Number -IsOffline $false Set-Disk -Number $disk.Number -IsReadOnly $false Initialize-Disk -Number $disk.Number -PartitionStyle GPT New-Partition -DiskNumber $disk.Number -UseMaximumSize -GptType '{ebd0a0a2-b9e5-4433-87c0-68b6b72699c7}' -AssignDriveLetter $partition = (Get-Partition -DiskNumber $disk.Number | Sort-Object Size -Descending | Select-Object -First 1) Format-Volume -FileSystem NTFS -Partition $partition -AllocationUnitSize 65536 -Confirm:$false }
The next step is to create an Active Directory Group for DBAs and the Group Managed Service Accounts for the SQL Engine to use. On the Domain Controller or a system with a remote server administrative tools (RSAT) installed:
Import-Module ActiveDirectory New-ADGroup -Name SQLAO1DBA -GroupCategory Security -GroupScope Global New-ADServiceAccount -Name svc-sqlao1 -Enable $true -DNSHostName sqlao1.contoso.com New-ADGroup -Name SQLAO1Nodes -GroupCategory Security -GroupScope Global Add-ADGroupMember SQLAO1Nodes SQLAO1N1$,SQLAO1N2$ Set-ADServiceAccount -Identity svc-sqlao1 -PrincipalsAllowedToRetrieveManagedPassword SQLAO1Nodes
Then, reboot each node and then execute the following on each node:
Add-WindowsFeature RSAT-AD-PowerShell Import-Module ActiveDirectory Install-ADServiceAccount -Identity svc-sqlao1
Now the account is available on each node.
While SQL is being installed on the first node, repeat this on the other node to get it ready.
Once both nodes are up and running and have SQL Server installed, it is time to install Fail-Over Clustering. Open an elevated PowerShell session on each node:
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools Test-Cluster -Node SQLAO1N1,SQLAO1N2
You may get warnings regarding one network interface or no shared disk but these are ok as the Fail-over is only managing a shared IP address for the listener. On one of the nodes, execute the following in an elevated PowerShell session:
New-Cluster -Name SQLAO1 -Node SQLAO1N1,SQLAO1N2 -StaticAddress 172.16.101.81 -NoStorage
I usually set up Cluster-Aware Updating at this point so that I can apply updates easily, but I'll put the directions in another page since it is pretty much the same on all types of Windows clusters.
Always-On needs a place to store the database during the initial replication. I typically create a folder D:\Backups
drive for backups and the initial replication. Share this folder and give the SQL gMSA account permission to Modify, Read & execute. Then:
Enable AlwaysOn Availability Groups
and make sure that the Windows fail-over cluster name is correct.At this point you should be able to use the cluster name as the database server name just like any other SQL server to access the databases. Unless you have a need to have separate listeners to segregate access to databases, there is no need to configure a listener. Skipping a separate listener also consume one less IP address on the network.