Partager via

Empfohlener Windows-Hotfix für Database Availability Groups (DAGs), die unter Windows Server 2008 R2 ausgeführt werden

  • Article

Veröffentlichung des Originalartikels: 20.11.2011

Anfang August 2011 hat das Windows SE-Team den folgenden Knowledge Base-Artikel und einen begleitenden Softwarehotfix veröffentlicht, um ein Problem in Windows Server 2008 R2-Failoverclustern zu beheben:

KB2550886 - A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working

Dieser Hotfix wird dringend für alle DAGs (Database Availability Groups) empfohlen, die sich auf mehrere Datacenter erstrecken. Für DAGs, die sich nicht auf mehrere Datacenter erstrecken, ist dieser Hotfix jedoch auch nützlich. In dem KB2550886-Artikel werden eine Racebedingung und ein Clusterdatenbank-Deadlockproblem beschrieben, das auftreten kann, wenn im Windows-Failovercluster ein vorübergehender Kommunikationsfehler auftritt. In der Logik für die Verbindungswiederherstellung der Clusterknoten gibt es eine Racebedingung, die sich zeigt, wenn im Cluster Kommunikationsfehler auftreten. Tritt diese Racebedingung auf, bleibt die Clusterdatenbank hängen, sodass es im Failovercluster zu einem Quorumverlust kommt.

Eine DAG (Database Availability Group) hängt von bestimmten Clusterfunktionen ab, einschließlich der Clusterdatenbank, so wie in diesem TechNet-Artikel beschrieben. Damit eine DAG betriebsbereit ist und eine hohe Verfügbarkeit bereitstellen kann, müssen auch der Cluster und die Clusterdatenbank ordnungsgemäß ausgeführt werden.

Microsoft hat Szenarien ermittelt, in denen ein vorübergehender Netzwerkfehler auftritt (keine Netzwerkkommunikation für ca. 60 Sekunden), der dazu führt, dass es im gesamten Cluster zu einem Deadlock kommt und die Bereitstellung aller Datenbanken in der DAG aufgehoben wird. Da es schwierig ist, den Clusterknoten mit dem tatsächlichen Deadlock zu ermitteln, wenn aufgrund einer Racebedingung in der Verbindungswiederherstellungslogik ein Failoverclusterdeadlock auftritt, besteht die einzig mögliche Vorgehensweise darin, alle Mitglieder im gesamten Cluster neu zu starten, um die Deadlockbedingung zu beseitigen.

Das Problem zeigt sich normalerweise in Form eines Clusterquorumverlusts aufgrund eines asymmetrischen Kommunikationsfehlers (wenn zwei Knoten nicht miteinander, aber dennoch mit anderen Knoten kommunizieren können). Wenn es zwischen anderen Knoten beim Empfang von Clustergruppierungswiederherstellungs-Nachrichten, die vom globalen Update-Manager (Global Update Manager, GUM) des Clusters stammen, zu Verzögerungen kommt, werden die Nachrichten zur Gruppierungswiederherstellung möglicherweise in unerwarteter Reihenfolge empfangen. Wenn dies geschieht, verliert der Cluster Quorum, anstatt das erwartete Verhalten aufzurufen, nämlich einen der Knoten zu entfernen, in dem der anfängliche Kommunikationsfehler im Cluster aufgetreten ist.

Dieser Fehler macht sich im Allgemeinen bei einer asymmetrischen Wartezeit (wenn z. B. die Hälfte der DAG-Mitglieder eine Wartezeit von 1 ms hat, während die Wartezeit für die andere Hälfte der DAG-Mitglieder 30 ms beträgt) zweier Clusterknoten bemerkbar, wenn die Verbindung zwischen diesem Paar unterbrochen ist. Wenn der erste Knoten den Verlust der Verbindung viel früher als der zweite Knoten erkennt, kann eine Racebedingung auftreten:

  • Der erste Knoten initiiert eine erneute Verbindung des Datenstroms zwischen den beiden Knoten. Hierdurch wird der zweite Knoten veranlasst, den neuen Datenstrom zu seinen Daten hinzuzufügen.
  • Durch Hinzufügen des neuen Datenstroms wird der alte Datenstrom abgebrochen, und der Fehlerhandler wird auf "Ignorieren" gesetzt. Im Fehlerfall ist der alte Datenstrom der abgebrochene Datenstrom, der noch nicht erkannt wurde.
  • Wenn der Verbindungsabbruch auf dem zweiten Knoten erkannt wird, initiiert der zweite Knoten eine eigene Sequenz zur Verbindungswiederherstellung. Wird der Verbindungsabbruch im richtigen Racefenster erkannt, wird der Fehlerhandler des abgebrochenen Datenstroms auf "Ignorieren" gesetzt, und der Prozess zur Verbindungswiederherstellung initiiert keine erneute Verbindung. Es wird jedoch Anforderung zum Anhalten der Sendewarteschlange ausgegeben, damit, dass zwischen den Knoten keine Nachrichten mehr gesendet werden. Wenn die Nachrichtenübermittlung gestoppt wird, kann der GUM nicht korrekt ausgeführt werden und erzwingt einen Clusterneustart.

Wenn dieses Problem auftritt, hat dies ernsthafte Folgen für die DAGs. Daher wird empfohlen, diesen Hotfix auf allen Mailboxservern bereitzustellen, die Mitglied einer DAG sind, insbesondere wenn die DAG sich auf mehrere Datencenter erstreckt. Dieser Hotfix ist auch für Umgebungen mit Exchange 2007-Einzelkopieclustern sowie für Umgebungen mit fortlaufender Clusterreplikation nützlich.

Neben einer Lösung für das oben beschriebene Problem enthält KB2550886 zudem andere wichtige Windows Server 2008 R2-Hotfixes, die auch für DAGs empfohlen werden:

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2