Mit Microsoft SQL Server AlwaysOn-Verfügbarkeitsgruppen (AGs) können Sie Datenbanken über mehrere SQL Server Enterprise-Instanzen hinweg replizieren.

Ähnlich wie SQL Server-Failover-Clusterinstanzen, AlwaysOn-Verfügbarkeitsgruppen verwenden Windows Server Failover Clustering (WSFC) zur Implementierung von Hochverfügbarkeit. Diese beiden Funktionen unterscheiden sich jedoch in mehreren Punkten:

	AlwaysOn-Verfügbarkeitsgruppen	Failover-Clusterinstanzen
Umfang des Failovers	Gruppe von Datenbanken	Instanz
Speicher	Nicht freigegeben	Freigegeben

Einen detaillierteren Vergleich finden Sie unter Vergleich von Failover-Clusterinstanzen und Verfügbarkeitsgruppen.

AlwaysOn-Verfügbarkeitsgruppen unterstützen mehrere Verfügbarkeitsmodi. In dieser Anleitung wird gezeigt, wie Sie AlwaysOn-Verfügbarkeitsgruppen im synchronen Commit-Modus bereitstellen können, um Hochverfügbarkeit für eine oder mehrere Datenbanken zu implementieren.

Bei der Einrichtung erstellen Sie drei VM-Instanzen. Die VM-Instanzen node-1 und node-2 dienen als Clusterknoten und führen SQL Server aus. Die dritte VM-Instanz witness wird verwendet, um ein Quorum in einem Failover-Szenario zu erreichen. Die drei VM-Instanzen werden auf drei Zonen verteilt und teilen sich ein gemeinsames Subnetz.

Mit einer SQL Server-AlwaysOn-Verfügbarkeitsgruppe wird eine Beispieldatenbank bookshelf synchron über die beiden SQL Server-Instanzen repliziert.

In einer lokalen Windows Server Failover Clustering-Umgebung lösen ARP-Ankündigungen ein Failover der IP-Adresse aus. Google Cloudignoriert jedoch ARP-Ankündigungen. Daher müssen Sie eine der beiden folgenden Optionen implementieren: einen internen Load-Balancer und einen verteilten Netzwerknamen (Distributed Network Name, DNN). In diesem Artikel wird davon ausgegangen, dass Sie Active Directory bereits in bereitgestellt haben und Grundkenntnisse in Sachen SQL Server, Active Directory und Compute Engine haben. Google Cloud Weitere Informationen zu Active Directory in Google Cloudfinden Sie im Abschnitt „Vorbereitung“