NiC Teaming und Failover + HA Fragen

[mangold]

moin, wir hatten heute morgen das Problem, dass ein Switch ausgefallen ist, und dadurch mehrere ESX Hosts und ihre VMs nicht erreichbar waren.

Wider Erwarten, erfolgte bei den NICs kein Failover. Jetzt habe ich mir das genauer angeschaut, es war so, dass auf dem betroffenen NIC zwar kein IP Traffic mehr laufen konnte, aber ein physischer Link vorhanden war. Nun stehen die Virtuellen Switche + Console im NicTeaming unter "Fail over detection" lediglich auf "link status only". Eigentlich wäre in diesem Fall "beacon proabing" besser gewesen. Ist dabei etwas zu beachten? Was passiert genau bei "beacon proabing"?

2. Frage: Die HA Agents auf den verbleibenden Servern haben erkannt, dass die anderen Hosts weg waren und haben auch versucht ein VM Failover zu erreichen. Da die VMs ja liefen (nur nicht im Netz erreichbar) und die VMX und VMDKs im Zugriff waren schlug das Failover fehl. Nun ist in der HA Config in "Isolation Response" auch "leave powered on" eingestellt. Wenn ich das vestehe, sollen die VMs am Laufen bleiben,. wenn ein HOST isoliert wird, also im Netzwerk nicht erreichbar ist.

In diesem Fall bin ich ganz froh, dass es nicht auf "powered off" gestellt war, ansonsten wären 40 VMs neu gestartet worden. Aber eigentlich will ich sicherstellen, dass diese auch laufen. Jetzt bin ich im Zwiespalt wie ich das handhaben soll. Welche Tipps habt ihr hierbei.

[MatZ]

gabs nicht auch mal 4 einstellungen? eine zum erreichen einer MAC und noch eine zum erreichen einer IP? das konnt man schön auf den core-switch packen und hat dann auch kaskadierte ausfälle bemerken können...wird zeit das ESX 4 dann auch spanning tree kann

das mit dem powered of/on hat schon einen sinn bei der isolation eben um die maschienen vom zugriff zu lösen...überdenke vllt mal deine infrastruktur wenn ein einfacher switch schon eine isolation hervor ruft oder ist nur ein netzwerk segment zwischen deinem serverraum und deinen clients aufgetreten?

schau ma hier, selbe sache...
http://vmware-forum.de/viewtopic.php?p=66726#66726

Giesbert:
nochmal zum verständnis: eine isolation sieht für die anderen hosts wie ein HA aus weil der host ja weg ist, netzwerkseitig, also nichtmehr zu erreichen ist über die HA-schnittstelle...und wie jörg meinte isolation ist ein sonderfall des HA...vergleichbar mit einem 2-nodes cluster denen du den heardbeat wegnimmst und dann beide versuchen auf die clusterdaten zuzugreifen, was dann ja nicht funktioniert

man kann aber kommende probleme mit durchdachten redundanzen aus dem weg räumen

[mangold]

das mit dem powered of/on hat schon einen sinn bei der isolation eben um die maschienen vom zugriff zu lösen...überdenke vllt mal deine infrastruktur wenn ein einfacher switch schon eine isolation hervor ruft oder ist nur ein netzwerk segment zwischen deinem serverraum und deinen clients aufgetreten?

wie es dazu kommt, dass ein einzelner Switch zur Isolation führen kann, habe ich in meinem ersten Absatz erklärt und auch ne Frage dazu gestellt
Der Switch hat den NICs noch einen physischen Link "angeboten", jedoch war der IP Traffic abgestellt (OS des Switches war down, kann aber auch passieren wenn ein Uplink down ist) und dass hat das NIC Teaming nicht erkannt, weil es lediglich auf "Link Status only" eingestellt ist, der Link war da also gabs kein NIC Failover auf den anderen Standby Switch. Ich möchte ja gern auf "beacon proabing" stellen, will mir aber erst über die Konsequenzen dieser Einstellung klar sein. Werd mal ins Admin Guide schauen ob da mehr Erklärungen als in der Help drin stehen.

EDIT: Nachdem was hier drin steht (Config Guide) ist Beacon Probing wohl die bessere wahl

„ Network Failover Detection — Specify the method to use for failover 
detection.
„ Link Status only – Relies solely on the link status that the network 
adapter provides. This option detects failures, such as cable pulls and 
physical switch power failures, but not configuration errors, such as a 
physical switch port being blocked by spanning tree or that is 
misconfigured to the wrong VLAN or cable pulls on the other side of a 
physical switch.
„ Beacon Probing – Sends out and listens for beacon probes on all NICs in 
the team and uses this information, in addition to link status, to 
determine link failure. This detects many of the failures previously 
mentioned that are not detected by link status alone.

[MatZ]

jo grad getestet, er schickt nen arp einfach von einem port zum benachbarten geteamten port...aber wenn dir ein switch in 2ter instanz wegfliegt ist das ganze dann nicht so sinnvoll...also wirkt das wirklich nur in erster instanz oder man haut die beiden adapter auf 2 verschiendene switches und macht einen bogen ums echte trunking : /

ja aber willst du denn das er bei isolation auch die maschienen freigibt (man kann einstellen das sie sauber runtergefahren werden, der andere host nimmt sich die VMs und startet die wieder (er denkt ja der host is komplett abgeschmiert, für ihn is es ja ein HA-fail)...ich glaub da muss man aber die HA-zeit evtl hochsetzten wenn die maschienen lange zum runterfahren brauchen--> http://www.yellow-bricks.com/ha-advanced-options/

[mangold]

Das war ja meine Frage nach Erfahrungswerten bei der Isolation. Wenn ich weiß, dass die Isolation in Kürze beseitigt wird, ist mir das lieber als viele VMs booten zu lassen. Ab einer gewissen zeit, kann man damit aber nicht leben. Heute waren 3 Hosts betroffen mit jeweils 20 Vms, das hätte bedeutet, dass 60 vms auf den drei verbliebenden Hosts gestartet worden wären, mit 40 Vms wären die ein wenig überfordert gewesen. Muss wohl anfangen ein wenig zu priorisieren und zu schauen, welche VM benötigt wird und welche nicht im Falle einer Störung.

Danke für den Link, war ja mal wieder klar, dass man an diese HA Options nicht so einfach per GUI rankommt. da kann man ja nur entscheiden ob sie "power off" oder nicht bleiben.

Derzeit ist jeder NIC an einem separatem Switch, deswegen ärgert es mich ja um so mehr, dass die NICs kein Failover gemacht haben, was bei meinen Einstellungen ja auch korrekt ist. Werde dann mal auf "probing" umstellen nächste Woche nach ein paar Tests.

[MatZ]

wenn du die zeit hochsetzt bis er wirklich erst einen HA oder eine isolation bemerkt sollte es passen...

die VMs kannst du aber auch in den HA-clustereinstellungen auch sanft ausmachen lassen (vmware tools vorrausgesetzt), früher bei 3.0.x wars noch schwieriger da musste man etwas basteln...

wenn du aber wirklich spaß haben willst kannst du mit CLI-scripten auf einer lokalen VM ein heard-beat selbst bauen und duch das RCLI dann entsprechende befehle ausführen lassen...denke aber das lohnt nur wenn der nutzen auch stimmt...

schonmal daran gedacht wenn du vile nics, hosts und switche hast das ganze mal mit teamings/spanningtree so aufzubauen das dich ein einzelner ausgefallener switch nicht sonderlich stört? ich weis ich reite darauf rum, kenne aber deine struktur nich aber wenn ich schon höre jede NIC an seperatem switch... *hrrhrr*

ich bin aber der meinung wenn der host 6-8 ports hat und die geschickt verdrahtet sind kann eigendlich keine isolation entstehen...ich hab lösungen designt und implementiert bei kunden die können nur ausfallen wenn man das RZ zerstört...

[mangold]

ich weiß auch nicht warum du darauf rum reitest.
host hat zwei Nics, jeder der BEIDEN Nics hängt an einem Switch, traffic geht über einen, dieser Switch geht kaputt, failover erfolgt nicht, server ist isoliert. ist doch nicht so schwierig.

das eine fehlerhaft Konfig vorliegt, habe ich doch schon selbst gemerkt

[MatZ]

dann mach das VM-bases-teaming und knüpf mal den server an 2 switches...

hat dein host im ganzen nur 2 nics? empfehlen würde ich immer min 4 nics, am besten 6 und 2 weitere für jedes weitere netzwerk was du pysisch abtrennen willst (DMZ)...

vllt kannst du bei deinem geldgeber ja mal anfragen, vmware selber sagt ja auch kernel, serviceconsole und VMnetze sollen auf getrennten adaptern liegen, also brauchst du schonmal min 3 nics und bist aber nichtmal redundant...

[mangold]

dann mach das VM-bases-teaming und knüpf mal den server an 2 switches...

ist schon, wie 3 mal geschrieben. Was meinst du mit VM Bases Teaming?
Teaming ist doch ne Eigenschaft des virtuellen Switches, bzw, wird bei der Zuordnung der physischen Nics konfiguriert und ist per default an, auf "Link Status only", was ja scheinbar nicht ausreicht, wie ich selbst erleben musste.

hat dein host im ganzen nur 2 nics? empfehlen würde ich immer min 4 nics, am besten 6 und 2 weitere für jedes weitere netzwerk was du pysisch abtrennen willst (DMZ)...

2 Gigabit NICs für die Console (Backups laufen drüber) und 2 Gigabit NICs für die VMs. Warum noch mehr NICs wenn die VMs nichtmal GIgabit ausreizen.

Ein gewisses Maß an Netzwerk Know How ist schon vorhanden , aber eigentlich wurde zu meiner Anfangsfrage wenig gesagt (probing und praktische Erfahrungen)

[bla!zilla]

Best Practise kann man auch überteiben, keine Frage. Weniger als vier NICs würde ich aber auch nur in ganz seltenen Fällen nutzen.

[MatZ]

also es gibt 4 teaming modes das einfachste is dieses VM-basierende (sry mein cluster steht zur zeit auf halde und bin nich auf arbeit)

da shuffelt er durch 1VM 1ste NIC, 2te VM 2te nic, 3te VM 1ste nic...das is das default aber besser ist ein load-bases teaming, also bonding unter linux oder trunking auf switch ebene, geht aber nicht wenn du 2 nics load-balanced und sie an 2 switchen machst, es sei denn deine netzwerk-struktur macht mashing...

das probing hab ich selbst nochnicht activ eingesetzt weil selten nötig, ich seh da aber probleme wenn du zb einen block hast wegen einer spanning-tree-topologie änderung...mir würde linkstatus auf 2 switche reichen, wenn du in der ebene wo dir deine 2 switche ankommen was wegfliegt (core switch) dann würd ich eh meinen hast du ein anderes problem, wenn man ein coreswitch-tandem hat und entsprechend spanningtree geziehlt einsetzt kann es keinen ausfall geben wenn nicht was größeres passiert...

ne durchdachte infrastruktur kannst du mit wenig (finanziellen) aufwand schon mit wenigen mitteln erreichen...

das probing kann ich ja mal in meinem versuchscluster ausprobieren, hab aber grad keine gescheiten switche daheim

[bla!zilla]

Genau bei sowas hilft dir Beaconing. Bei STP Fehlern, fehlerhafter VLAN Konfiguration usw. Da bringt dir Link Failure Detection mal GAR NICHTS.

Mehrere pNICs an einem pSwitch bringen dir natürlich schon etwas, vor allem da von einem vSwitch (bei mehreren aktiven Adaptern) per Default ein einfaches Load-Balancing gemacht wird. Bei mehreren pNICs ist der Einsatz von mehreren pSwitches natürlich sinnvoll und erwünscht. Aber auch wenn du alle pNICs an einem pSwitch ist, ist der Einsatz von Beaconing SINNVOLL. Daher kann ich es nur empfehlen.

@ MatZ

Schön was du alles tolles Hochverfügbares gebaut hast - hab ich auch. Aber deine Postings sind echt schwer zu lesen und zu verstehen. Bitte achte da in Zukunft darauf.

[mangold]

Genau bei sowas hilft dir Beaconing. Bei STP Fehlern, fehlerhafter VLAN Konfiguration usw. Da bringt dir Link Failure Detection mal GAR NICHTS.

Mehrere pNICs an einem pSwitch bringen dir natürlich schon etwas, vor allem da von einem vSwitch (bei mehreren aktiven Adaptern) per Default ein einfaches Load-Balancing gemacht wird. Bei mehreren pNICs ist der Einsatz von mehreren pSwitches natürlich sinnvoll und erwünscht. Aber auch wenn du alle pNICs an einem pSwitch ist, ist der Einsatz von Beaconing SINNVOLL. Daher kann ich es nur empfehlen.

danke DAMIT kann ich dann was anfangen, die Diskussion war davor etwas unproduktiv.

@MAtz: das mit der durchdachten Struktur ist schon ok, schließlich betreibe ich meine Farm seit 4 Jahren , du solltest mal konkret auf Fragen eingehen und nicht immer erzählen wie toll alles machbar ist.

das probing hab ich selbst nochnicht activ eingesetzt weil selten nötig, ich seh da aber probleme wenn du zb einen block hast wegen einer spanning-tree-topologie änderung...mir würde linkstatus auf 2 switche reichen, wenn du in der ebene wo dir deine 2 switche ankommen was wegfliegt (core switch) dann würd ich eh meinen hast du ein anderes problem, wenn man ein coreswitch-tandem hat und entsprechend spanningtree geziehlt einsetzt kann es keinen ausfall geben wenn nicht was größeres passiert...

entweder hast du meine Frage nicht wirklich verstanden oder du willst angeben

[MatZ]

okok werde es zukünftig ausführlicher beschreiben was ich meine...

config:
2 switche an 1 "core- switch" und an jedem dieser beiden switche je 1 NIC vom host

vswitch settings:



hab das probing aber mal ausgetestet und den switch dicht gemacht, linkstatus war ok, server hat umgeschalten auf die andere NIC an anderem switch...alle 4 VMs waren soweit verfügbar gab aber wohl einen kleinen abriss client hat das packet 2mal geschickt, das wars

funktioniert also

hab ich mich nun besser ausgedrückt?