der-phil
Goto Top

Windows Failover Cluster - Ressource nicht abschalten bei kurzem Netzwerkproblem

Hallo!

Gerade hat mein Windows 2016 Failover Cluster eine Ressource abgeschaltet, als kurz die Netzwerkverbindung weg war (Spanning-Tree Neuberechnung):

EventID 1127
In der Clusternetzwerkschnittstelle "FOSERVER-1 - OfficeLAN-Failover1" für Clusterknoten "FOSERVER-1" im Netzwerk "Management" ist ein Fehler aufgetreten. Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um die Netzwerkkonfiguration zu prüfen. Wenn das Problem weiterhin besteht, prüfen Sie, ob Hardware- oder Softwarefehler in Bezug auf den Netzwerkadapter vorliegen. Prüfen Sie auch, ob andere Netzwerkkomponenten fehlerhaft sind, an die der Knoten angeschlossen ist, z. B. Hubs, Switches oder Brücken.

2x EventID 1077
Fehler bei der Integritätsprüfung für IP-Schnittstelle "IP-Adresse 10.10.101.1" (Adresse "10.10.101.1") (Status: "1117"). Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um sicherzustellen, dass der Netzwerkadapter ordnungsgemäß funktioniert.

EventID 1069
Fehler in der Clusterressource "IP-Adresse 10.10.101.1" des Typs "IP Address" in der Clusterrolle "FOSERVER".
Abhängig von den Fehlerrichtlinien für die Ressource und die Rolle wird vom Clusterdienst möglicherweise versucht, die Ressource auf diesem Knoten online zu schalten oder die Gruppe auf einen anderen Knoten des Clusters zu verschieben und die Ressource dann neu zu starten. Prüfen Sie den Ressourcen- und Gruppenzustand mit dem Failovercluster-Manager oder mit dem Windows PowerShell-Cmdlet "Get-ClusterResource".


EventID 1077
Fehler bei der Integritätsprüfung für IP-Schnittstelle "Cluster-IP-Adresse" (Adresse "10.10.101.220") (Status: "1117"). Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um sicherzustellen, dass der Netzwerkadapter ordnungsgemäß funktioniert.


All das war innerhalb von nur 4 Sekunden. Danach hat dann auch der passive Knoten das Problem gemerkt.
Ende vom Lied war, dass die Rolle nicht mehr gestartet ist.

Könnt ihr mir einen Tipp geben, wie ich eine Art "größere" Toleranz einbaue, dass der Cluster nicht so schnell reagiert?

Was mich wundert ist, dass TROTZ diese Konfiguration schon nach 4s alles abgebrochen ist:
get-cluster | fl *subnet*

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


Reicht es, hier den Threshold auf z.B. 60 hochzusetzen, um das Problem zu vermeiden, oder muss ich noch mehr tun. Ehrlich gesagt möchte ich NIE, dass der Cluster bei einem detektierten Ausfall in unter einer Minute schwenkt oder eine Ressource beendet...

Danke und Grüße
Phil

Content-Key: 344771

Url: https://administrator.de/contentid/344771

Ausgedruckt am: 19.03.2024 um 09:03 Uhr

Mitglied: emeriks
emeriks 28.07.2017 um 13:26:26 Uhr
Goto Top
Hi,
hast Du ein Quorum eingerichtet?

E.
Mitglied: Der-Phil
Der-Phil 28.07.2017 um 13:48:42 Uhr
Goto Top
Hallo!

Ja, ein Quorum habe ich. Das Problem war auch nicht ein Schwenk, sondern dass die eine Ressource gestört war.

Grüße
Phil
Mitglied: emeriks
emeriks 28.07.2017 aktualisiert um 14:14:11 Uhr
Goto Top
Ja, ist klar. Aber das Failover-Verhalten bei Netzwerkausfall ist mit Quorum anders als ohne.
Hast Du einen extra Netzwerkstrang für die Kommunikation der Cluster Nodes untereinander? Nicht bloß VLAN, sondern getrennte Switche?
Bei physischen Nodes ist das sehr zu empfehlen. Bei VM's nur unter der Bedingung, dass die Anbindung nach außen dann tatsächlich über getrennte Netzsegmente geht.

Grundlegendes zu Quorumkonfigurationen in einem Failovercluster
Was hast Du da gerade eingestellt?
Knotenmehrheit (für Cluster mit einer ungeraden Anzahl von Knoten empfohlen)
Kann den Ausfall der Hälfte der Knoten (aufgerundet) abzüglich eines Knotens tolerieren. Beispielsweise kann ein Cluster mit sieben Knoten drei Knotenausfälle tolerieren.

Knoten- und Datenträgermehrheit (für Cluster mit einer geraden Anzahl von Knoten empfohlen)
Kann den Ausfall der Hälfte der Knoten (aufgerundet) tolerieren, wenn der Zeugendatenträger online geschaltet bleibt. Beispielsweise kann ein Cluster mit sechs Knoten, in dem der Zeugendatenträger online geschaltet ist, drei Knotenausfälle tolerieren.

Kann den Ausfall der Hälfte der Knoten (aufgerundet) abzüglich eines Knotens tolerieren, wenn der Zeugendatenträger offline geschaltet wird oder ausfällt. Beispielsweise kann ein Cluster mit sechs Knoten mit einem fehlerhaften Zeugendatenträger zwei (3-1=2) Knotenausfälle tolerieren.

Knoten- und Dateifreigabemehrheit (für Cluster mit besonderen Konfigurationen)
Funktioniert ähnlich wie Knoten- und Datenträgermehrheit, doch anstelle eines Zeugendatenträgers wird für diesen Cluster eine Zeugendateifreigabe verwendet.

Wenn Sie Knoten- und Dateifreigabemehrheit verwenden, muss mindestens einer der verfügbaren Clusterknoten eine aktuelle Kopie der Clusterkonfiguration enthalten, damit Sie den Cluster starten können. Andernfalls müssen Sie das Starten des Clusters über einen bestimmten Knoten erzwingen. Weitere Informationen finden Sie unter "Weitere Überlegungen" im Thema Starten oder Beenden des Clusterdiensts auf einem Clusterknoten.

Keine Mehrheit: Nur Datenträger (nicht empfohlen)
Kann den Ausfall aller Knoten bis auf einen tolerieren (wenn der Datenträger online geschaltet ist). Diese Konfiguration wird jedoch nicht empfohlen, da es sich bei dem Datenträger um eine einzelne Fehlerquelle handeln kann.

E.
Mitglied: Der-Phil
Der-Phil 28.07.2017 aktualisiert um 16:06:33 Uhr
Goto Top
Hallo!

Danke für Deinen Post!
Die Cluster-Knoten sind direkt per LWL auf zwei Pfaden miteinander verbunden (ohne Switche). Entsprechend sollte hier eine gewisse Sicherheit kommen. Mir ist aber unklar, wie ich diese hinein bringe. Ich habe aktuell keine Ressource, die diese LWL-Direktverbindungen berücksichtigt. Kannst Du mir hier einen Tipp geben? Bisher sieht es so aus:

3x Netzwerk:
- Office-LAN (zu den Switchen) - Konfiguriert als "Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen" - Cluster und Client
- 2x Sync-Interfaces, direkt - aktuell konfiguriert als "Netzwerkkommunikation für Cluster in diesem Netzwerk nicht zulassen"

Beim Quorum zeigt der Failovercluster-Manager: "Zeuge: Quorum"
Ich gehe davon aus, dass es sich um eine Knotenmehrheit handelt, aber ich finde dazu keine klare Aussage.


Irgendwie sind für mich die Konfigurationen unklar:
Wenn etwas im "geswitchten Netzwerk" passiert, soll frühestens nach 60s ein Failover passieren. Wenn ich auf die Richtlinien der IP-Adresse der Rolle gehe, kann ich auswählen "Bei Ressourcenfehler nicht neu starten". Was passiert denn dann? Behält der Knoten einfach die IP und wenn nach einer Minute alles da ist, läuft es auf dem Knoten weiter, wo es war, oder bleibt der Fehler dann ewig, auch wenn die Switche wieder funktionieren?


Kannst Du mir hier einen Tipp geben?

Gruß
Phil
Mitglied: emeriks
emeriks 28.07.2017 um 16:13:53 Uhr
Goto Top
- 2x Sync-Interfaces, direkt - aktuell konfiguriert als "Netzwerkkommunikation für Cluster in diesem Netzwerk nicht zulassen"
Das musst Du dann schon aktivieren. Nur den Unterpunkt "Clients das Herstellen einer Verbindung ..." kannst deaktivieren.

Was für Adressen haben die Nodes in diesem LWL-Netz?
Ich hoffe doch Adresse aus einem anderen IP-Subnet, dediziert nur für die Kommunikation der Nodes untereinander (nirgend woanders genutzt, wohin die Cluster antworten können müssen)?
Mitglied: Der-Phil
Der-Phil 28.07.2017 um 16:37:15 Uhr
Goto Top
Hallo!

Ja, das sind andere IP-Bereiche auf den beiden Interfaces.

Ich verstehe aber trotzdem noch nicht, wie ich den Cluster "träger" bekomme. Wenn ich die beiden Interface zur Clusterkommunikation zulasse - bleibt dann die Rolle für eine längere Zeit auf dem Knoten? Gibt es so eine Art "definierbare Wartezeit" bis zum Failover?

Grüße