Home > Workload Solutions > SQL Server > White Papers > Scaling SQL Server 2022 VMs on Dell Integrated System for Microsoft Azure Stack HCI > HA for SQL Server databases
Always On Availability Groups (AGs) are a high-availability and disaster recovery solution from Microsoft. They provide an alternative to database mirroring. An AG facilitates an environment for failover for user databases by supporting primary databases to 1 through 8 secondary databases. As described by Microsoft, Always On AGs does not depend on any form of shared storage.
To effectively use and implement Always On AGs, each availability replica should reside on a different node of a single Windows Server Failover Clustering (WSFC) within separate fault-domains.
The SQL Server instances we deployed are already on a pre-designed optimally configured WSFC cluster which makes it easy for customers to take advantage of the SQL Server Always On AGs. For more information about Always On AGs, see the Microsoft website.
The WSFC cluster nodes we created were deployed with cluster property of ClusterEnforcedAntiAffinity which creates a hard block and prevents 2 VMs which are part of this group from running on the same node. For more information regarding affinity, anti-affinity and failover clustering, see the Microsoft website.
For the Availability Group sqlag0 we created, we used a Windows Server Failover Cluster which included the AGT1 database with the Primary replica hosted on VM sqlvm14 and Secondary replica hosted on sqlvm13 with synchronous commit mode with automatic failover.
We chose to deploy a primary and secondary replica using a shared storage to configure the Failover Cluster Instances and for the initial data synchronization between replicas using a Full database and Log backup. This was easily configured through the DNS node of our environment. However, it is possible to instead deploy and sync the primary and secondary replicas using database seeding. Figure 18 shows the Primary replica hosted on VM sqlvm14 and Secondary replica hosted on sqlvm13 on their respective SQL Server instances.
Figure 18. Availability Group sqlag0 with a primary and secondary replica