Ein Hochverfügbarkeitscluster stellt besondere Anforderungen an die Erreichbarkeit der einzelnen Knoten im Cluster. Werden ein oder mehrere Knoten eines Clusters in einem bestimmten Zeitraum nicht mehr erreicht, werden Maßnahmen durchgeführt, die bis hin zu einem Failoverswitch auf einen anderen Knoten führen. Ein Clusterknoten sendet dazu »Heartbeats«, dass sind im Prinzip Pings zB an den zweiten Knoten im Cluster und es wird erwartet, dass diese innerhalb bestimmter Zeiträume »Delay« und zu einer bestimmten Ping Verlust Rate »Threshold« beantwortet werden müssen. Folgendes Kommando liest die aktuelle Konfiguration diesbzgl. aus (Ersetzen Sie »DAG1« mit dem Namen ihres Clusters):

[PS] C:\Windows\system32>get-cluster | fl *subnet*


CrossSubnetDelay          : 1000
CrossSubnetThreshold      : 5
PlumbAllCrossSubnetRoutes : 0
SameSubnetDelay           : 1000
SameSubnetThreshold       : 5

Die oben mit dem »get-cluster« Kommando ermittelten Werte bilden die Standardeinstellungen ab. Der Wert »1000« bei »SameSubnetDelay« bedeutet, dass alle 1000 Millisekunden ein Ping gesendet wird und der Wert »5« bei »SameSubnetThreshold« bedeutet, dass maximal 5 dieser Pings verloren gehen dürfen, ehe Failovermaßnahmen ergriffen werden. Das bedeutet, dass die Netzwerkverbindung maximal 5 Sekunden ausfallen darf²⁾³⁾.

Unsere Knoten im Cluster sind beide virtualisiert, wodurch es uU schon mal zu Problemen mit der Erreichbarkeit kommen kann, wenn der Host zB gerade stark ausgelastet ist. Gerade wenn ein Backup- und/oder Replikationstask auf dem Host ausgeführt wird, kann es ggf. zu einem Überschreiten der Grenzwerte kommen, was zu einem Auslösen der Failovermaßnahmen führt. Interessant sind in diesem Kontext die Werte der Parameter »SameSubnetDelay« und »SameSubnetThreshold«, wenn sich die Knoten innerhalb eines Subnetzes befinden, bzw. »CrossSubnetDelay« und »CrossSubnetThreshold«, wenn die Knoten des Clusters auf mehrere Subnetze verteilt sind⁴⁾.

Typische Fehler die auftreten können, wenn ein Knoten im Cluster ausfällt sind zB folgende:

Die Liste der Ereignisse ist standardmäßig erst mal leer, sie muss auch bei Eintreten eines Problems zuerst generiert werden. Rufen Sie dazu in der Navigationsleiste das Kontextmenü des Listenpunkts »Clusterereignisse« auf und führen dort eine »Abfrage« durch. Weitere Filter oder anderweitige Modifikationen der »Abfrage« stehen Ihnen unmittelbar nach dem Aufruf des Kommandos zur Verfügung.

Es gibt eine Fülle von Empfehlungen, wie die Konfiguration idealerweise angepasst werden soll (zB:⁵⁾), die häufigste stellt die Werte auf die maximal erlaubten »2000« Millisekunden bei »SameSubnetDelay« bzw. »CrossSubnetDelay« und »10« bei »SameSubnetThreshold« bzw. »20« bei »CrossSubnetThreshold« ein. Unsere Knoten sind nicht über mehrere Subnetze verteilt, was bedeutet wir ändern nur die »SameSubnet*« Parameter:

[PS] C:\Windows\system32>cluster /cluster:DAG1 /prop SameSubnetDelay=2000:DWORD
[PS] C:\Windows\system32>cluster /cluster:DAG1 /prop SameSubnetThreshold=10:DWORD
[PS] C:\Windows\system32>get-cluster | fl *subnet*


CrossSubnetDelay          : 1000
CrossSubnetThreshold      : 5
PlumbAllCrossSubnetRoutes : 0
SameSubnetDelay           : 2000
SameSubnetThreshold       : 10

Die Werte werden in die Registry nach »HKLM\Cluster« geschrieben und auf die restlichen Mitglieder des Clusters repliziert. Die Einstellungen können auf einem beliebigen Mitglied des Clusters vorgenommen werden.

Da bei uns ausschließlich der Knoten mit der passiven Datenbankkopie betroffen war und dieses Problem ausschließlich während eines Umfangreichen Replikationstasks auftrat, liegt die Vermutung nahe, dass das Netzwerkinterface des Hypervisors der Flaschenhals ist. Best Practice Szenarien sehen hierfür ein dediziertes »Heartbeat-Netzwerk« vor, was den virtuellen »Heartbeat-Adapter« auf ein anderes physikalisches Netzwerinterface mappt. Dadurch bliebe auch der Cluster während großer Last auf dem Haupt-Interface innerhalb der Standard-Parameter erreichbar⁶⁾.

— pronto 2016/11/09 15:03