Ausfall HyperV-Failovercluster - Zweifel an NIC-Teamingfunktion

[Christoph_A4 10]

Guten Morgen,

 

ich versuche die Umgebung mal auf das Wesentliche zusammenzufassen:
Wir betreiben einen HyperV-Failovercluster (WinServer2012R2, 8 Nodes) mit einem darauf gesetzten SCVMM.
Wir haben einen virtuellen Switch für das VM-Netzwerk, der aus 6 physikalischen NICs je Host geteamt ist. die Kabel der 6 NIC verteilen sich auf 3 physikalische Switches.

Heute ist einer dieser Switches ausgefallen. Unsere Annahme:
2 der 6 NICs des NIC-Teams fallen aus, das Team besteht nur noch aus 4 NICs. Die VMs bleiben allesamt online.

 

Es kam anders:
Alle VMs liefen zwar weiterhin, diverse VMs gingen jedoch offline. Höchstwahrscheinlich die, welche über die 2 NICs des ausgefallenen Switches kommunizierten.

Frage: Wird ein Switchausfall nicht durch das Teaming kompensiert? Geschieht dies nur, wenn die NICs selbst einen Defekt aufweisen oder auf eine andere Weise deaktiviert sind/werden?

 

Vielen Dank schon mal für die Antworten.

[DocData 85]

Das Team am Host besteht aus 6 NICs? Welchen Ladtverteilungsmodus verwendest du?

[Doso 77]

Wir haben auch sowas, aber halt nur 2 NICs im Team. Das hält einen Switch Ausfall (Modul getauscht) und einen Ausfall einer Verbindung (Kabel ziehen) problemlos aus. Die Verbindung läuft ja über die virtuelle NIC des NIC Team da sollte der Ausfall einzelner Mitglieder nicht so viel machen.

 

Wir verwenden Switch Independent. Habt ihr evtl. LACP verwendet und euch da bei der Konfiguration vertan?

[Christoph_A4 10]

Der Teaming-Modus ist "Switch Independent".

Der LB-Modus ist dynamisch.

Einen Standby-Adapter haben wir nicht explizit definiert.

[Doso 77]

Eigtl. sollten die VMs über alle 6 NICs kommunizieren und nicht nur über 2 davon. Sie sollten auch nicht offline gehen, im schlimmsten Fall haben sie einfach kein Netzwerk mehr.

[testperson 1.676]

Hi,

 

ich habe jetzt keine große Ahnung vom Hyper-V Switch und wie er das Teaming aufzieht des weiteren bin ich auch kein Netzwerk-Profi ;) Aber im VMWare Fall würde ich Richtung Switche schauen (lassen) (Gratuitous ARP / o.ä?).

NIC Treiber / Firmware und Switch Firmware alles aktuell?

 

Gruß

Jan

[NilsK 2.934]

Moin,

 

das Team liegt in dem Fall "unterhalb" des virtuellen Switches. Und wie hier schon gesagt wurde, sollte das beobachtete Phänomen nicht auftreten. Da ist also irgendwas falsch gelaufen, aber was genau, lässt sich nicht ohne Weiteres sagen.

 

Gruß, Nils

[Christoph_A4 10]

Hallo,

 

Wir sind auch zu dem Ergebnis gekommen, dass die NICs auf den Hosts nicht als down gekennzeichnet waren. Der Switch war lt. unserem Netzwerkkollegen in einem undefinierbaren Defekt-Zustand. Er hat nicht funktioniert, hat aber kein Link-down-Signal an den Host weitergeben können. Für die HyperV-Hosts war der Switch in Ordnung, die Fehlfunktion HINTER dem Port am Switch konnte der Host nicht erahnen. Deswegen liefen die VMs auch weiterhin auf diesen beiden NICs, dessen Pakete den Switch aber nicht verlassen haben.

Wäre das so erklärbar?

[NilsK 2.934]

Moin,

 

ja, denkbar wäre das.

 

Sowas in der Art haben wir auf anderer Ebene auch schon mal bei einem Storagesystem gesehen. Da war eine Platte in einem seltsamen Zwischenzustand, was das Storagesystem nicht richtig erkannt hat. Im Ergebnis ist das ganze Storage ausgefallen, weil keiner seiner Verfügbarkeitsmechanismen angesprungen ist. Das sind "schöne" Beispiele, dass technische Verfügbarkeitsmechanismen bei weitem nicht alle Schadensszenarien abdecken.

 

Gruß, Nils

[Doso 77]

Wir hatten einen HP 48 Port Switch gehabt der sowas ~ einmal im Jahr gemacht hat. Hier half es die Firmware zu aktualisieren, war wohl ein bekanntes Problem das sie dann mal korrigiert haben. Hättet ihr kein NIC Teaming gehabt, hätte halt gar nix mehr funktioniert, so hat zumindest noch ein Teil der VMs scheinbar funktioniert.

[zahni 554]

Gibt es im Hyper-V keine Path Validation? Hier schickt der Host im vSwitch regelmäßig Broadcasts durch die Gegend und prüft, ob sie an allen Ports ankommen.

Produziert natürlich traffic. Da muss man sich halt entscheiden. Damals im VMware-Seminar hatte der Trainer empfohlen sich nicht auf "link state only" zu verlassen.

[DocData 85]

Beacon Probing erfordert aber auch drei NICs. Hat man die, ist das eine tolle Sache.

[Christoph_A4 10]

Gibt es denn "Beacon Probing"-Ähnliches für HyperV? Wäre mir neu.