it-swarm.com.de

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 zu diesem Thema fand Clustering vs. Transaktionsreplikation vs. Verfügbarkeitsgruppen , 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.

9
James Jenkins

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

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 :

Nachdem Sie das Quorum für den WSFC-Cluster erzwungen haben (erzwungenes Quorum), müssen Sie für jede Verfügbarkeitsgruppe ein Failover 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 Erzwingung des Quorums .

10
Remus Rusanu

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 Cluster-Heartbeat-Einstellungen mit der Eigenschaft CrossSubnetDelay oder CrossSubnetThreshold von dieser Hotfix .
  • 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 Konfiguration der Quorum-Abstimmung für AlwaysON
  • In Windows Server 2016 ändern sich die Dinge mit der Einführung von standortbezogene Cluster und Cloud-Zeuge .

    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 ein neuer Typ von Failovercluster Quorum-Zeugen , der Microsoft nutzt Azure als Arbitrierungspunkt. 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 Quorum 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 @ Remus 'Antwort, da dies diesen Punkt abdeckt) und die überlebenden Knoten online schalten.

Um eine Ursachenanalyse (RCA) durchzuführen, sammeln 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.

6
Kin Shah

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 es einen Ausfall gibt, 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.

0
Alen