Hohe Netzwerkauslastung Hyper-V Clusternodes -> Blue Screen

[Doso 77]

Wir hatten die Tage eine größere Netzwerkstörung. Jemand hatte eine Schleife im Backend Netzwerk gesteckt, was sich dann auch zu unserem Serverraum Netzwerk verbreitet hatte. Dies hat dann dazu geführt das unsere Hyper-V 2012R2 Cluster Nodes alle in einen Blue Screen gegangen sind, Meldung User_Mode_Health_Monitor. Die Server sind dann alle mehrfach neu gestartet, mit entsprechenden Auswirkungen auf die virtuellen Maschinen. Der Spuk hat erst aufgehört als die Schleife aufgelöst war.

 

Wir haben auch noch einen Testcluster, hier war zwar auch das Netzwerk nicht nutzbar, aber die Server sind nicht ständig neu gestartet.

 

Ich vermute das hat hiermit zu tun: https://blogs.technet.microsoft.com/askcore/2009/06/12/why-is-my-failover-clustering-node-blue-screening-with-a-stop-0x0000009e/

 

Die Server sind neu gestartet weil sie keinen Hearthbeat mehr voneinander erhalten haben. b***d nur das ich eigentlich ein getrenntes Netzwerk mit eigenen kleinen Switches für diese Cluster Kommunikation / Live Migration vorgesehen habe. Und dieses Netzwerk sollte eigentlich auch dafür genommen werden, da niedrigste Metrik.

 

Ich stehe daher aktuell total auf dem Schlauch was man dagegen tun könnte. Jemand eine Idee?

 

Im Anhang ein Screenshot der Cluster Netzwerke. ClusterMove Team ist ein NIC Team aus 2x 1GBe Ports, Serverraum Teaming sind 2x 1GBe NIC Team für die Anbindung der VMs (hier war die Störung). Dies restlichen 4 Ports sind für die Anbindung von Storage, iSCSI, ohne NIC Teaming.

 

Edit:

 

Get-ClusterNetwork | ft Name,Metric

 

Name                                        Metric

----                                             ------

ClusterMove Team                    30384

DS3512-gross-3                        79985

DS3512-gross-4                        70384

DS3524-schnell-3                      79841

DS3524-schnell-4                      79840

Serverraum Teaming                  79842

bearbeitet 4. Januar 2018 von Doso

[djmaker 95]

Der Anhang fehlt . . . . 

 

BTW: Hast Du nun den Heartbeat getrennt oder nicht?

[faulibaerstuttgart 0]

Cluster kann man nicht sinnvoll über ein Forum supporten.

[Doso 77]

Der Anhang fehlt . . . . 

 

BTW: Hast Du nun den Heartbeat getrennt oder nicht?

 

Habe es oben hinzugefügt.

 

Der Heartbeat sollte über das NIC Team laufen, zusammen mit dem Live Migrations Verkehr.

[djmaker 95]

Deine Vermutung bzgl der Ursache (Artikel) scheint in die richtige Richtung zu gehen. Eventuell kannst Du den Heartbeat über separate NICs in ein sparates VLAN stecken.

 

Nils kann bestimmt auch noch weitere Infos liefern. :-)

[NilsK 2.957]

Moin,

 

wie sind denn die IP-Segmente der verschiedenen Netze? Sind die voneinander getrennt, oder versucht der Cluster, dasselbe Segment über mehrere Karten zu erreichen? Das wäre spontan das einzige, was mir einfällt, warum der Cluster trotz separierten Heartbeat-Netzes in den Status geht. Oder das Netz ist eben in Wirklichkeit nicht separiert, wodurch der Loop alle Netze in Mitleidenschaft zieht.

 

Gruß, Nils

[Doso 77]

Ich habe Live Migration und Cluster/CSV Verkehr über ein NIC Team laufen. Kann es sein das die Hosts irgendwie panisch versuchen Live Migration zu machen z.b. weil ein Host raus ist und dadurch auch dieses Netzwerk zu macht? Evtl. sollte ich das NIC Team auflösen und sowohl Cluster/CSV Verkehr und Live Migration wieder trennen. Hatte die eigentlich zusammen gepackt um mehr Speed bei der Live Migration zu bekommen.

[NilsK 2.957]

Moin,

 

zumindest früher war es nicht mal supported, das Heartbeat-Netz zu teamen. Man sollte stattdessen zwei separate Netze einrichten, weil der Clusterdienst selbst ein Failover darüber macht - genauer gesagt über alle Netze, die ihn mit den anderen Nodes verbinden. Diese Supportstatement gilt zwar nicht mehr, seit das Teaming Teil des Betriebssystems ist, aber es zeigt, dass man an der Stelle kein Team braucht.

 

Viele Kunden wollen wie du maximale Geschwindigkeit für Live Migrations. Da frage ich mich immer, wieviel man denn im Normalbetrieb live migriert. Solange man keine höchstdynamische Umgebung hat, migriert man vielleicht einmal im Monat, vor den Host-Updates. Dafür braucht man aber keine Maximalperformance. Ohnehin hülfe das Team nur, wenn du zwei VMs gleichzeitig migrierst, was man in mittelständischen Umgebungen auch eher selten tut.

 

Ganz abgesehen davon, solltest du aber dem Netzwerkproblem auf die Spur kommen, statt dich auf Nebenschauplätze zu konzentrieren. Das Verhalten des Clusters war nicht OK, und das muss einen Grund haben.

 

Gruß, Nils

[testperson 1.707]

Hi,

 

OT:

Viele Kunden wollen wie du maximale Geschwindigkeit für Live Migrations. Da frage ich mich immer, wieviel man denn im Normalbetrieb live migriert. Solange man keine höchstdynamische Umgebung hat, migriert man vielleicht einmal im Monat, vor den Host-Updates. Dafür braucht man aber keine Maximalperformance. Ohnehin hülfe das Team nur, wenn du zwei VMs gleichzeitig migrierst, was man in mittelständischen Umgebungen auch eher selten tut.

 

Darum mag ich Converged Network. Da kann man diese Kunden so richtig glücklich mit machen. ;)

 

Gruß

Jan

[NilsK 2.957]

Moin,

 

ja, das wäre evtl. mal was für ein Redesign beim TO. Aber erst, wenn ausreichend Vertrauen in die Netzwerkkonfig drumrum besteht. :D

 

Gruß, Nils

[Doso 77]

Danke für Anregungen!

 

Habe das Netzwerk Team auf dem Cluster/Livemigrations Netz wieder aufgelöst. Es hat zwar die Zeiten etwas reduziert wenn ein Host leer gemacht wurde. Aber wie Nils schon schrieb, so wirklich groß ist der Unterschied nicht.

 

Habe weiterhin bemerkt das einer der Node ein Problem hatte und immer mal wieder kurz aus dem Cluster flog. Habe mir das Ding dann mal angeschaut. Irgendwie war eine Netzwerkkarte etwas locker im Gehäuse, da war dann die Verbindung nicht so wirklich stabil.

 

Habe weiterhin bemerkt das wir ja doch eine physische Netzwerkverbindung haben. Wir haben da ein Verwaltungsnetz. Das würde zwar bedeuten das die Netzwerkstörung mehrere Switches,  eine Firewalls und VLANs übersprungen hat.. und eigentlich sollte das nicht .. aber...  So wirklich oft müssen wir nicht an die kleinen Switches ran, da kann ich notfalls die paar Meter zum Serverraum auch laufen. Daher die Management Verbindung getrennt (Kabel gezogen).

 

Ob davon nun irgendwas wirklich was gebracht hat weiß ich nicht. Bis zur nächstes großen Netzwerkstörung dann... wenn der Trend anhält in 3 Jahren dann?!

[testperson 1.707]

Loop nochmal stecken ;) Nach möglichkeit dann aber wohl besser in einem Wartungsfenster.

[DocData 85]

Habt ihr kein Spanning-Tree??