VMware-Forum

Hallo Liebes Forum,

ich habe ein komisches Problem in einer ESX 3.5 Landschaft.

Zur Umgebung:

Es laufen 4 ESX Hosts die jeweils zu zwei HA Clustern zusammgefasst sind (DRS und VMotion). Storage wird über ein SAN zur Verfügung gestellt. Die Netzwerkkonfiguration umfasst 3 vSwitches (
- einer für die Service Console mit 2 zugeordneten physikalischen NICs
- einer für die VMs mit 4 zugeordneten physikalischen NICs und
- einer für das VMKernel Netz mit einer zugeordneten physikalischen NIC )

Die Konfiguation hat die ganze Zeit auch Problemlos funktioniert. Alle physikalischen NICs waren immer zusammen auf dem selben physikalischen Switch im Netzwerk verbunden. Jetzt war die Idee um eine höhere Ausfallsicherheit zu erreichen, die verschiedenen physikalischen NICs auf mehrere physikalische Switche aufzuteilen, um im Falle eines Hardwaredefektes eines physikalischen Switches nicht einen Komplettausfall zu haben). Soviel zur Idee

Jetzt steckt physikalisch jeweils eine NIC des ersten virtuellen Switches auf Swtich 1 und die zweit auf Switch 2 (diese beiden Switche sind übers Backbone miteinander verbunden). Bei den 4 Karten des zweiten vSwitch ist es genauso.

Seit dieser Konfiguration kommt es häufig vor das einzelne VMs über das Netzwerk nicht erreichbar sind. Vor der Änderung lief die Konfiguration schon fast ein Jahr ohne Fehler. Auch beim Umziehen einzelner VMs kommt eine Fehlermeldung das der Heartbeat nicht verfügbar sei (was ja auch auf Netzwerkfehler hinweist).

Jetzt muss ich zu meiner Schande gestehen das ich mich mit den Einstellungen des virtuellen Netzwerks nie viel beschäftigt habe. Ich habe zwar schon heute morgen einige Interessante Themen hier im Forum gefunden aber leider noch nichts was mir helfen konnte.

Achso die vSwtiches stehen auf Port Based Balacing (was ja eigentlich wie Round Robin ist).

Für Hilfe und Anregungen wäre ich sehr dankbar !!!

Klingt schwer nach Problemen wegen (R)STP oder das ARPs nicht ganz rumgehen. Nutzt ihr VLANs, Routing auf den Switches, STP o.ä.?

Hi,

also ich muss vorab sagen das der Kollege der das Netzwerk betreuet gerade nicht greifbar ist.
Von der Struktur ist es so das es zweit große Backbone Router gibt (Black Diamond von Extreme) die auch als virtuelle Router funktionieren. VLANs werden zwar genutzt aber (noch) nicht im Serverbereich.
Das Routing läuft komplett über diese Core Switches. Ein STP Problem kann ich mir (vielleicht auch durch fehlendes Wissen) schwer vorstellen.
Ich habe das Port Base Balancing so verstanden das jeweils eine VM der Reihe nach einer physikalischen Karte zugeordnet wird. Somit sollte es doch eigentlich nicht zu Redundanzen kommen, oder? Erst im Fehlerfall oder beim Umzug sollte doch die andere Karte aktiv werden.

Oder ändert die VM im laufenden Betrieb die Zuordung zur physikalischen Karte? Wenn diese geändert wird hängt sie doch eigentlich trotzdem nur an einem Switch.

Aber schonmal Danke für die Infos, werde gleich nochmal mit unserem Netzwerker reden !

Grüße

Hi, falsch verstanden. STP hat mit VMware erstmal nix zu tun. VMware kann das nicht mal. Es geht viel mehr darum, dass bei einem Failover eine VM möglicherweise auf einer NIC landet, deren Link durch STP geblockt ist. Habt ihr mal mit der Linkstatus-Pürung über Beaconing getestet? Standardmäßig testet VMware ESX nur den Linkstatus. Das führt aber zum Problem, wenn Links über STP geblockt werden oder die VLAN Konfiguration falsch ist. Da hilft die Prüfung über Beaconing-Pakete.

So abschließend die Lösung des Problems:

- Der Fehler konnte auf einen virtuellen Host begrenzt werden.
- Diese VMs auf diesem virtuellen Host konnten Sich (wenn Sie auf dem selben vSwitch waren) untereinander im Netzwerk erreichen. Lediglich die Server welche nicht auf diesem vSwitch waren konnte diese Server nicht erreichen.
- Beim Kontrollieren der physikalischen NICs im Networkmanger ist aufgefallen das eine Karte keine observed IP Range hat
- Sobald man diese Karte vom vSwitch (als Uplink) entfernt fuktioniert alles problemlos.
- Die Einschätzung von bla!zilla (vielen Dank an dieser Stelle) war richtig. Die besagte Karte ist unbeabsichtigt auf einem "tagged" Port gelandet (VLAN) und hatte somit einen Link war aber logisch nicht erreichbar.
- Lösung für die Zukunft, wir haben die Prüfung von Link-Status only auf beacon probing umgestellt.
- Fehler nochmal provoziert und VMWare erkennt die falsche Konfiguration - tolle Sache

Vielen Dank für die Hilfe !!!

Freut mich das es klappt.