SQL Server AlwaysOn-Verfügbarkeitsgruppen ist die neueste Technologie von Microsoft zur Erfüllung der Hochverfügbarkeits- und Notfallwiederherstellungsanforderungen von Organisationen, die SQL Server verwenden. Ein großer Vorteil von AlwaysOn ist die Fähigkeit, sowohl HA als auch DR in einer Implementierung zu adressieren. Die wichtigsten Vorteile von AlwaysOn, die wir erlebt haben, sind die folgenden:
Wir können zusammengehörige Datenbanken als Teil einer einzigen Verfügbarkeitsgruppe gruppieren und bei Bedarf ein Failover zusammenführen. Dies ist besonders nützlich für Anwendungen, die von mehr als einer Datenbank abhängen, wie z. B. Microsoft Office SharePoint, Microsoft Lync oder Sage.
Im Vergleich zu SQL Server-Failover-Cluster-Instanzen stellen wir fest, dass der Speicher als einzelner Fehlerpunkt eliminiert wurde, da jeder Instanz, die ein Replikat darstellt, ein eigener Speicher zugewiesen wurde.
Mit AlwaysOn ist es möglich, HA und DR gleichzeitig zu konfigurieren. Dies wird erreicht, indem Multi-Site-Windows-Failovercluster als Grundlage Ihrer AlwaysOn-Konfiguration erstellt werden. Das Durchführen eines Rollenwechsels bei Verwendung von AlwaysOn ist erheblich einfacher als bei Verwendung des Transaktionsprotokollversands.
Die WSFC-Abhängigkeit
Wenn Sie SQL Server AlwaysOn AG für Hochverfügbarkeit und Notfallwiederherstellung verwenden, müssen Sie zunächst einen Windows-Failovercluster konfigurieren. AlwaysOn-AGs hängen von WFCS ab, um die AlwaysOn-AG als Rolle zu verwalten, die sich aus Clusterressourcen wie dem Namen der Verfügbarkeitsgruppe, dem Namen der Dateifreigabe, dem Listener-Namen und einer IP-Adresse zusammensetzt.
Abb. 1 AlwaysOn AG als Cluster-Ressource
Quorum
Quorum ist die Mindestanzahl an Stimmen, die für eine Mehrheit in einem Failover-Cluster erforderlich ist. Das Quorum bestimmt, wie viele Knotenausfälle der Cluster verkraften kann. Über das private Netzwerk an Port 3343 kommunizieren alle Cluster-Knoten Integritätsstatus- und Ressourcenüberwachungsinformationen. Im Fehlerfall zeigen die Votes, welche Nodes den Status „Up“ haben und auf welchen Nodes Ressourcen online gebracht werden müssen.
Seit Windows Server 2012 beträgt die maximale Anzahl unterstützter Clusterknoten sechzehn. In den meisten Umgebungen, mit denen ich vertraut bin, sind Zwei-Knoten-Cluster jedoch üblich. Ein Zwei-Knoten-Cluster stellt ein kleines Problem in Bezug auf das Erreichen des Quorums dar, da jeder Knoten eine Stimme hat und wenn es ein Problem mit der Kommunikation zwischen den beiden gibt, kann jeder davon ausgehen, dass der andere nicht fehlerfrei ist. Dies wird als Split-Brain-Szenario bezeichnet. Split-Brain-Szenarien sind der Grund für die Konfiguration eines Tiebreakers wie einer Festplatten- oder Dateifreigabe.
Wenn Sie eine ungerade Anzahl von Knoten haben, ist es nicht notwendig, einen Tiebreaker zu konfigurieren. Dynamische Quorumkonfiguration und dynamischer Zeuge wurden in Windows Server 2012 bzw. Windows Server 2012 R2 eingeführt. Mithilfe dieser Technologien verteilt Windows die Stimmen in einem Cluster automatisch neu, sodass die Anzahl der Knoten in einem Cluster bei der Einrichtung eines Quorums keine Rolle spielt. Die Stimme eines Cluster-Knotens wird entfernt, indem die Cluster-Eigenschaft „NodeWeight“ auf 0 gesetzt wird. Diese Funktionen sind standardmäßig aktiviert.
Abb. 2 Abrufen aller Cluster-Eigenschaften mit PowerShell
Abb. 3 Zugewiesene Stimmen in einem Zwei-Knoten-Cluster
PowerShell verwenden
Der PowerShell-Befehl Get-Cluster kann verwendet werden, um die Quorum-Konfiguration auf einem Windows-Cluster zu überprüfen. Abb. 4 zeigt, wie alle Cluster-Eigenschaften im Zusammenhang mit Quorum auf einem Cluster überprüft werden, und Abb. 5 zeigt die Eigenschaften des Dateifreigabe-Zeugen. Es gibt viele andere PowerShell-Befehle zum Überprüfen und Verwalten von Windows-Clustern.
Get-Cluster | Format-List –Property *Quorum*
Abb. 4 PowerShell-Befehl zum Überprüfen von Quorum-bezogenen Eigenschaften
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Abb. 5 PowerShell-Befehl zum Überprüfen der Details der Dateifreigabe-Zeugeneigenschaften
Quorum-Modi
Windows Server Failover Cluster ermöglicht die Konfiguration von bis zu vier Modi. Quorum-Modi sind im Wesentlichen Optionen, die Sie auswählen, um festzulegen, wie der Cluster mit Knotenausfällen umgeht.
1. Knotenmehrheit
Dieser Quorum-Modus kann Ausfälle von bis zu (n/2)-1 Knoten vertragen. Es wird für Cluster mit einer ungeraden Anzahl von Knoten empfohlen. Beispielsweise würde in einem Cluster mit fünf Knoten ein Ausfall von zwei Knoten erforderlich sein, um einen Clusterausfall zu verursachen.
2. Knoten- und Datenträgermehrheit
Kann Ausfälle von bis zu der Hälfte der Cluster-Knoten vertragen, solange der Datenträgerzeuge (auch als Quorum-Datenträger bezeichnet) online bleibt.
3. Knoten- und Dateifreigabemehrheit
Dieser Quorum-Modus kann Ausfälle von bis zu der Hälfte der Anzahl von Cluster-Knoten verkraften, solange die Dateifreigabe zugänglich bleibt. Ab Windows Server 2012 R2 empfiehlt Microsoft, beim Erstellen eines Clusters immer einen Zeugen (Datenträger oder Dateifreigabe) zu konfigurieren.
4. Keine Mehrheit
Dies ist ein Nur-Festplatten-Modus. Dieser Modus kann Ausfälle aller Knoten bis auf einen aushalten, solange die Festplatte online ist. Dieser Modus wird nicht empfohlen, da die Festplatte zu einem Single Point of Failure wird.
Tipps zum Konfigurieren der Knoten- und Dateifreigabemehrheit
AlwaysOn-Verfügbarkeitsgruppen unterstützen nur zwei dieser Quorum-Modi:Knotenmehrheit und Knoten- und Dateifreigabemehrheit. Beim Erstellen eines SQL Server AlwaysOn-Verfügbarkeitsgruppen-Clusters sollte der DBA einige Punkte beachten:
1. Verwenden von physischen Servern
Wenn Sie einen Zwei-Knoten-Cluster für AlwaysOn konfigurieren, müssen sich Ihre Knoten in verschiedenen physischen Racks befinden. Der Server, der Ihre Dateifreigabe hostet, muss sich in einem dritten Rack befinden.
2. Virtuelle Server verwenden
Wenn Sie einen Zwei-Knoten-Cluster für AlwaysOn konfigurieren, müssen sich Ihre virtuellen Maschinen auf separaten Hosts befinden. Die virtuelle Maschine, die Ihre Dateifreigabe hostet, muss sich auf einem dritten Host befinden.
3. Multi-Site-Clustering
Bei der Konfiguration eines Multi-Node-Clusters für AlwaysOn über Rechenzentren hinweg muss sich der Dateiserver, der Ihre Dateifreigabe hostet, in einem idealen Szenario in einem dritten Rechenzentrum befinden.
4. Dateifreigabeberechtigungen
Das Clusternamensobjekt sollte Berechtigungen für die Dateifreigabe haben, die als Quorumzeuge verwendet wird. Ohne dies würden normalerweise Fehler beim Versuch auftreten, Quorum Witness zu konfigurieren.
Abb. 6 Berechtigungen für die Dateifreigabe
5. Online-Konfiguration
Quorummodi können konfiguriert werden, während der Cluster online ist. Falls also der Dateifreigabeserver ausfällt oder neu konfiguriert werden muss, stellen Sie sicher, dass Sie ihn schnell neu konfigurieren, um sicherzustellen, dass keine unerwarteten Ausfälle auftreten, insbesondere in einem Zwei-Knoten-Cluster.
Ein realer Anwendungsfall
Das Diagramm in Abb. 7 zeigt einen echten Multi-Site AlwaysOn AG-Cluster. Es handelt sich um einen Vier-Knoten-Cluster mit zwei Knoten an einem Standort und zwei weiteren an einem entfernten DR-Standort. Der Dateiserver, auf dem die als Tie-Breaker verwendete Dateifreigabe gehostet wird, wird in einem dritten Rechenzentrum gehostet. Im vorliegenden Fall befindet sich der Dateiserver in derselben Stadt wie das primäre Rechenzentrum, aber wenn Sie es sich leisten können, wäre es ideal, den Dateiserver in einer anderen Stadt zu haben. Die Kommunikation zwischen den drei Seiten muss von guter Qualität sein, um Fehlalarme zu vermeiden.
Zum Beispiel haben wir bei unserer ersten Implementierung dieses Clusters „Synchronous Replication with Automatic Failover“ über die Live- und DR-Sites hinweg verwendet. Mehr als einmal erlebten wir einen Kommunikationsfehler, der ein automatisches Failover auf die DR-Site auslöste und einen Fehler in unserer Konfiguration aufdeckte. Dies führte dazu, dass der Listener-Name in die zugehörigen IP-Adressen am DR-Standort aufgelöst wurde und Clients keine Verbindung mehr herstellen konnten, da die Kommunikation mit dieser neuen IP-Adresse auf den Netzwerk-Firewalls nicht zulässig war. Wir haben einfach zum primären Standort zurückgekehrt, um das Problem zu mindern, und die Konfiguration für Knoten, die sich in Rechenzentren befinden, in „Asynchrone Replikation mit manuellem Failover“ geändert. Wir planen, den Aspekt der Namensauflösung in unserem nächsten „AlwaysOn“-Artikel zu behandeln.
Abb. 7 Ein realer Anwendungsfall
Schlussfolgerung
Die Funktion „AlwaysOn-Verfügbarkeitsgruppen“ wurde in SQL Server 2012 eingeführt und ist die neueste Technologie von Microsoft, um sowohl die Anforderungen für hohe Verfügbarkeit als auch für die Notfallwiederherstellung zu erfüllen. Das Konfigurieren von AlwaysOn-Verfügbarkeitsgruppen hängt stark vom Windows-Failoverclusterdienst ab. Failover-Cluster wiederum hängen stark von der korrekten Quorum-Konfiguration ab. Beim Erstellen von AlwaysOn auf Multi-Site-Clustern ist die Latenz zwischen Ihren Knoten an den verschiedenen Standorten und der als Arbiter verwendeten Dateifreigabe wirklich wichtig. Stellen Sie sicher, dass Ihre Quorum-Konfiguration immer in Topform ist, um unerwartetes Verhalten mit den Verfügbarkeitsgruppen zu vermeiden.
Referenzen
Übersicht über AlwaysOn-Verfügbarkeitsgruppen
Windows-Failover-Clustering mit SQL Server
PowerShell-Dokumentation
Grundlegendes zum Windows Server-Failover-Cluster-Quorum
