Was tun, wenn Ihr Always On-Cluster das Quorum verliert?

Ich habe die DR-Verfahren unseres Unternehmens überprüft und online nach Lösungen für ein Quorum gesucht, bei dem Always On Cluster das Quorum verliert. Ich war drei Seiten in den Google-Ergebnissen, bevor ich den ersten SE-Beitrag zum Thema Clustering vs. Transaktionsreplikation vs. Verfügbarkeitsgruppen fand, der das Thema verlorenes Quorum nur geringfügig berührt.

Obwohl sich alle einig sind, dass das Quorum zu verlieren schlecht ist und es einige Vorschläge gibt, das Potenzial zu verringern, kann es dennoch passieren. Ich bin auf der Suche nach einer guten Peer-Review-Antwort auf den besten Weg zur Wiederherstellung nach einem Quorumverlust im Always On-Cluster.

AGs basieren auf Windows Clustering. Es gelten die WSFC-Verfahren für Quorum Loss.

• WSFC Disaster Recovery durch Forced Quorum
• Erzwingen Sie, dass ein WSFC-Cluster ohne Quorum gestartet wird

Sobald die WSFC ausgeführt wird, können Sie bei Bedarf die AG erzwingen. Führen Sie ein erzwungenes manuelles Failover einer Verfügbarkeitsgruppe durch :

Nach dem Erzwingen des Quorums für den WSFC-Cluster (erzwungenes Quorum) müssen Sie das Failover für jede Verfügbarkeitsgruppe erzwingen (mit möglichem Datenverlust). Das Erzwingen eines Failovers ist erforderlich, da der tatsächliche Status der WSFC-Clusterwerte möglicherweise verloren gegangen ist. Sie können jedoch Datenverlust vermeiden, wenn Sie ein Failover auf der Serverinstanz erzwingen können, auf der sich das Replikat befand, das das primäre Replikat war, bevor Sie das Quorum erzwungen haben, oder auf ein sekundäres Replikat, das synchronisiert wurde, bevor Sie das Quorum erzwungen haben. Weitere Informationen finden Sie unter Mögliche Möglichkeiten zur Vermeidung von Datenverlust nach dem Erzwingen des Quorums .

Was tun, wenn Ihr AlwaysOn-Cluster das Quorum verliert?

Ich war in dieser Situation besonders mit Multi-Subnetz-Clustering in verschiedenen Ländern (NY-LD-HK).

Wie vermeide ich Quorum Loss in einem Multi-Subnetz-Cluster?

• Ändern Sie die Standardeinstellung des Clusters in einen entspannteren Überwachungsstatus, insbesondere die Einstellungen für den Cluster-Heartbeat mithilfe von CrossSubnetDelayoder die CrossSubnetThresholdEigenschaft dieses Hotfixes .
• Die AG verwendet die WSFC, die einen quorumbasierten Ansatz zur Bestimmung des Clusterzustands verwendet. Stellen Sie sicher, dass Sie das Quorum richtig auswählen und konfigurieren . Dieser Blog-Beitrag befasst sich eingehender mit der Konfiguration der Quorum-Abstimmung für AlwaysON

• In Windows Server 2016 ändern sich die Dinge mit der Einführung von standortbezogenen Clustern und Cloud-Zeugen .

  Knoten in gestreckten Clustern können jetzt basierend auf ihrem physischen Standort (Standort) gruppiert werden. Die Cluster-Site-Awareness verbessert wichtige Vorgänge während des Cluster-Lebenszyklus, z. B. Failover-Verhalten, Platzierungsrichtlinien, Herzschlag zwischen den Knoten und Quorum-Verhalten.

  Cloud Witness ist eine neue Art von Failover-Cluster- Quorum-Zeugen , die Microsoft Azure als Arbitrierungspunkt nutzt. Es verwendet Microsoft Azure Blob Storage zum Lesen / Schreiben einer Blob-Datei, die dann bei einer Split-Brain-Auflösung als Arbitrierungspunkt verwendet wird.

Was tun, wenn das Kollegium verloren geht?

• Wenn der Cluster aufgrund eines ungeplanten Ausfalls / einer Katastrophe ausfällt, ist ein manueller Eingriff erforderlich. Entweder ein Windows-Administrator oder ein Cluster-Administrator muss das Quorum manuell erzwingen (Verknüpfung mit der Antwort von @ Remus, da dies diesen Punkt abdeckt) und die überlebenden Knoten online schalten.

Um eine RCA (Root Cause Analysis) durchzuführen, erfassen Sie wie immer Ihre Windows-Clusterprotokolle für AlwaysON RCA - verwenden Sie SQL Server-Failovercluster-Diagnoseprotokolle . Diese Dateien im SQL Server-Protokollverzeichnis haben das folgende Format : <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.

Einmal war ich in einen Ausfall verwickelt, bei dem unsere gespiegelten Server die Konnektivität verloren haben. Sie müssen sich unter anderem darum kümmern, dass Ihre Anwendungen auf eine einzelne Instanz verweisen. Bei einem Netzwerkausfall können alle Knoten eines Always On-Clusters aktiv sein, jedoch nicht miteinander kommunizieren. Sie erzwingen ein Failover auf ein sekundäres Failover. Solange ein Ausfall vorliegt, können Sie zwei primäre Knoten haben, da der ursprüngliche primäre Knoten nichts über das erzwungene Failover weiß.

Abhängig von den Standorten Ihrer Anwendungsserver, ihrer Konfiguration und ihrer Fähigkeit, einen SQL-Server zu erreichen, können theoretisch zwei Knoten davon ausgehen, dass sie primär sind und gleichzeitig Daten geändert werden. Sobald Sie Ihre Netzwerkprobleme behoben haben und die Knoten die Konnektivität wieder aufnehmen, werden alle auf der ursprünglichen Primärdatenbank geänderten Daten von dem Knoten überschrieben, zu dem das Failover erzwungen wurde. Dies kann zum Verlust kritischer Daten führen.

Ich habe diese Situation einmal mit SQL 2005 und Spiegelung gesehen. Und wir haben beschlossen, das Failover nicht zu erzwingen und es nicht erreichbar zu lassen. Der Grund dafür ist, dass im schlimmsten Fall, wenn wir sichern und wiederherstellen müssten, um die Spiegelung neu zu starten, dies ein zweitägiger Prozess für uns wäre, bei dem das Risiko besteht, dass das Transaktionsprotokoll voll wird und die Festplatte, auf der es sich befindet, nicht erweitert werden kann.