As Hyper Converged solutions have gotten more popular across the industry, we have seen several use cases migrate to HCI from traditional SAN based architecture. With its modular and grow-as-per-your-need approach, HCI has made believers out of IT decision makers in several organizations who prefer this new architecture over the older one. One interesting use case that we have seen HCI now being talked about is in running MS SQL workloads.

While running MS SQL workloads in Hyperconverged Infrastructure is fairly straightforward, what becomes of particular interest is in building a high availability architecture for MS SQL databases. Today, we will try and understand in brief what needs to be in place for building such a cluster and what are the licensing requirements for the same.

There are two scenarios that we may need this high availability architecture for. The first could be for a deployment within the DC and this failover mechanism would be within the different nodes in a cluster in the DC. The second would be for a DR setup where the failover will exist between two different clusters running in the different datacenters. However, if the DC and DR is deployed as a stretched cluster, it would fall under the deployment and licenses for the first scenario.

Please note: The architecture talked about here is from the perspective of providing failover through the database HA. In today’s modern-day applications, it is always recommended to provide continuous availability from the application or database side. In the older days, HA would be provided from the infrastructure side, which is both inefficient and slow & may not always result in a consistent outcome. So, always think of how you can deploy HA from the application or database that you are building right from the start.

High Availability within the DC

The primary methodology for providing a high availability configuration for MS-SQL databases would be through an “Always-On Availability Group”. An availability group supports a replicated environment for a discrete set of user databases, known as availability databases. Each set of availability database is hosted by an availability replica. Two types of availability replicas exist: a single primary replica, which hosts the primary databases, and one to eight secondary replicas, each of which hosts a set of secondary databases and serves as a potential failover target for the availability group.

An availability group would need a WSFC (Windows Server Failover Cluster) to be setup between the various SQL instances. Also, the database would need to sit on a Clustered File System (Shared Disk). This is where things get interesting from an HCI perspective.

Not all HCI vendors support a Shared Disk, which is needed for a single volume to be attached to multiple instances. This is the reason why not all HCI vendors support a WSFC. A Hyper Converged solution’s storage architecture will need to have full support for this multi-attaching of volumes within the cluster to create the WSFC.

For automatic failover within this Availability Group, the Synchronous Commit and Automatic Failover options can be selected within the group for no data loss and to eliminate downtime within the DC. These options are to be selected in the SQL Group configurations.

Licensing Note #1

Two types of Availability Group Licenses exist:

– Basic (can be run on SQL Standard Server License, but is limited to only one Primary and one Secondary replica within an Availability Group)

– Full (needs SQL Enterprise Licenses, can have eight replicas within an Availability Group)

Licensing Note #2

MS-SQL Virtual Machines (VMs) can be licensed with both Standard as well as Enterprise Licenses. For Standard Licenses, the following two options exist:

– per Core License (the number of vCPUs of the VM needs to be licensed not the physical cores of the server & does not need user CALs) (minimum 4 cores)

– per Server License + CAL (the VM can be licensed with this Standard license, but it will need individual CALs for the users)

High Availability between the DC & DR

For a failover to exist correctly between the DC & DR, a slightly different domain known as a “Distributed Availability Group” has to be applied. A Distributed Availability Group is nothing, but the ability to connect two separate Availability Groups that do not need to be in the same location or a part of the same cluster. The only requirement between these two, would be the presence of a stable consistent connection.

The prime difference between a normal group and a distributed group is in how the resources are configured. In a normal Availability Group, everything is configured with the WSFC cluster. However, now that our DC & DR are in two unique clusters, the ability to use the same mode does not exist. Hence, in this case everything is maintained within the SQL server itself.

Although the option to select synchronous or asynchronous commit exists in a Distributed Availability Group, it is very highly recommended that an asynchronous data movement is selected. Since selecting synchronous would need the acknowledgement from all targets that they have the data, it may lead to an exorbitant amount of latency. This should only be done under exceptional situations.

The final point to note for a Distributed Availability Group is that it necessitates a manual failover.  You should not configure for automatic failover with rare exceptions.

Licensing Note #3

Distributed Availability Groups can only be configured if there are Enterprise Licenses for both the Availability Groups (DC & DR). For Enterprise Licenses, the only option below exists:

– per Core License (the number of vCPUs of the VM needs to be licensed not the physical cores of the server & does not need user CALs) (minimum 4 cores)

PLEASE NOTE:  All information provided above is an interpretation of what is available online (some reference links are mentioned below) and for your guidance. You can get in touch with the Deployment or Solutioning team at EnCloudEn for a more in-depth discussion on your specific requirements. Also, it is recommended that the customer talks to a Microsoft Licensing Professional for the final applicable licenses.

Leave a Reply

Your email address will not be published. Required fields are marked *