AlwaysOn-Verfügbarkeitsgruppen wechseln in den Status "Auflösen"

Wir haben einen Cluster mit zwei Knoten eingerichtet, auf dem SQL Server 2012 unter Windows Server 2012 R2 ausgeführt wird. Der Basiscluster besteht nur aus diesen beiden Knoten. Das Quorum wird als Knoten + Festplattenmehrheit eingerichtet, wobei sich eine gemeinsam genutzte Festplatte auf einem EqualLogic-Array befindet, das über iSCSI eine Verbindung herstellt. Die Clusterkonfiguration wird ohne Fehler überprüft.

Die beiden auf dem Cluster ausgeführten Verfügbarkeitsgruppen (beide primär auf Knoten 1) wurden heute auf beiden Knoten aufgelöst. Bei Betrachtung der Clusterereignisse gibt es nichts, bis versucht wird, den Dienst neu zu starten. Alles unter dem Windows-Failovercluster wird grün angezeigt (online und ohne Warnungen) - Festplatten, Netzwerkschnittstellen, Knoten usw.

Beim Betrachten des Anwendungsprotokolls in der Windows-Ereignisanzeige wurde das Ereignis, das anzeigt, dass die Verfügbarkeitsgruppen in den Auflösungsstatus wechseln, vom Cluster dazu aufgefordert, da kein Quorum eingerichtet werden konnte. Ich kann in keinem Protokoll etwas anderes finden, das dies unterstützt, und das Quorum wird während der Clusterüberprüfung übergeben.

Die AGs erholen sich nicht. Wir haben im AlwaysOn-Protokoll in SQL Server-Protokollen festgestellt, dass der erste Knoten einen Spiegelungsendpunktfehler hatte. Dies trat unmittelbar nach einer Speicherzugriffsverletzung mit Symptomen auf, die einem Problem ähneln, das Microsoft mit Cumulative Update 6 behoben hat. Wir werden dies als Nächstes versuchen.

Ich konnte den SQL Server-Dienst auf Knoten 1 neu starten (derjenige mit den Speicherzugriffsverletzungen, mit denen die zweite Notiz nicht kommunizieren konnte), und ich konnte die Verfügbarkeitsgruppe zu diesem Zeitpunkt wieder online schalten. Ein Neustart bringt auch alles wieder auf 100%.

Haben Sie einen Einblick, warum dies nicht Knoten 1 ausgefallen wäre und die Datenbank auf Knoten 2 am Leben erhalten hätte, wenn der Spiegelungsendpunkt ausgefallen wäre? Wir sind derzeit auf AG Level 3; Würde eine Erhöhung auf 4 den Fehler auf Knoten 1 auslösen, während der Dienst auf Knoten 2 am Leben bleibt?

Ich habe gesehen, dass dies häufig vorkommt, wenn Leute nur einen Satz Netzwerkkabel haben, die ihre Server verbinden - das heißt, bestenfalls ein Paar 1-Gbit-Ethernet-Kabel in jedem Knoten, und diese verwenden sie sowohl für reguläre Netzwerke als auch für iSCSI Speicherkonnektivität. (Die Tatsache, dass Sie Equallogic verwenden, ist ein Hinweis - ich habe viele davon mit 1-GB-Implementierungen gesehen.)

Wenn Sie überhaupt Netzwerkprobleme haben:

• Die beiden Knoten können sich nicht sehen
• Keiner der Knoten kann den Speicher sehen
• Presto, niemand sieht eine Mehrheit, und Sie verlieren das Quorum

Dinge, die dies verursachen können, sind:

• Backup-Software (große Lesevorgänge von der Festplatte bei gleichzeitiger Sättigung des Netzwerks)
• Ausführen einer CHECKDB (erneut große Lesevorgänge von der Festplatte sowie große Schreibvorgänge in TempDB, wodurch verhindert werden kann, dass die Cluster-Heartbeats durchkommen, wenn Sie nur eine Netzwerkschnittstelle für reguläres Netzwerk und Speicher haben).

Um es zu umgehen:

• Verwenden Sie separate Netzwerkschnittstellen für reguläres Netzwerk und iSCSI (wie ein Paar (mindestens) 1-Gbit-Ports, die nur für iSCSI vorgesehen sind, und sonst nichts).
• Verwenden Sie schnellere Netzwerkschnittstellen (wie 10 GB anstelle von 1 GB).
• Führen Sie weniger festplatten- / netzwerkintensive Arbeiten durch (beenden Sie die Sicherung und CHECKDB, ha ha ho ho, aber vereinfachen Sie auch die Indexwiederherstellung).

Ich hatte eine Verfügbarkeitsgruppe mit den gleichen Symptomen. Aus Wartungsgründen war 1 Knoten ausgefallen. Das Quorum blieb vom 2. Knoten und der Dateifreigabe erhalten.

Nach 7 Stunden hat der lebende Knoten (wahrscheinlich) die Verbindung zur Dateifreigabe verloren und als letzter stehender Mann aufgehört, Clients zu bedienen - hat er die Konnektivität zu einem Großteil des Quorums verloren.

Wenn die Dateifreigabe verfügbar ist, wurde sie nicht aus dem Auflösungsstatus wiederhergestellt. Nur der Neustart des SQL Server-Dienstes hat geholfen. Wahrscheinlich aufgrund der Unsicherheit, ob die Daten während des Solitärzeitraums nicht geändert wurden.