Microsoft SQL Server Always On availability groups (AG) let you replicate databases across multiple SQL Server Enterprise instances.

Similar to SQL Server Failover Cluster Instances, Always On availability groups use Windows Server Failover Clustering (WSFC) to implement high availability. But the two features differ in multiple ways, including:

	Always On availability groups	Failover cluster instances
Scope of fail-over	Group of databases	Instance
Storage	Not shared	Shared

For a more detailed comparison, see Comparison of Failover Cluster Instances and Availability Groups.

Always On availability groups support multiple availability modes. This tutorial shows how you can deploy Always On availability groups in synchronous commit mode to implement high availability for one or more databases.

In the setup, you will create three VM instances. Two VM instances, node-1 and node-2, serve as cluster nodes and run SQL Server. A third VM instance, witness, is used to achieve a quorum in a failover scenario. The three VM instances are distributed over three zones and share a common subnet.

Using a SQL Server Always On availability group, an example database, bookshelf, is synchronously replicated across the two SQL Server instances.

In an on-premises Windows Server Failover Clustering environment, ARP announcements trigger IP address failover. Google Cloud, however, disregards ARP announcements. Consequently, you must implement one of the following two options: using an internal load balancer and a distributed network name (DNN). The article assumes that you have already deployed Active Directory on Google Cloud and that you have basic knowledge of SQL Server, Active Directory, and Compute Engine. For more information about Active Directory on Google Cloud, see the Begin Section