45
Kurzzeitige Netzwerkaussetzer bei VM, wenn ESX-Host redundant am Netz hängt
Hallo Zusammen,
wir haben ein ESX-Cluster aus drei Hosts. Host 1 und 2 sind die "Arbeiter" und der Host 3 ist der (schwächere) Witness-Server.
Wir haben 3 Core-Switches. Jeder der Core-Switches hat eine LAG aus zwei LWL-Verbindungen zu jedem der anderen beiden Switches (im Bild die grünen Verbindungen).
ESX-Host 1 und 2 hängt jeweils redundant mit einem LWL an Switch 1 und mit einem LWL an Switch 2 (im Bild die blaue Verbindungen).
Der ESX-Host 3 hängt lediglich mit 2 LWL an Switch 3.
Nun ist mir aufgefallen, dass wenn ich z. B. ausgehend von VM1 (auf Host 1) die VM3 (auf Host 2) über einen längeren Zeitraum anpinge, es zu ca. 10 % Verlust kommt.
In die Gegenrichtung habe ist das gleiche.
Zunächst dachte ich, dass an der VLAN-Konfiguration der Switch-Ports etwas nicht stimmt, so dass nicht auf jeder Route das entsprechende VLAN konfiguriert ist, aber das habe ich schon mehrfach geprüft und ist nicht der Fall.
Nun ist mir aufgefallen, dass wenn ich von der redundanten Anbindung vom ESX-Host 1 eine Leitung deaktiviere, der Host dann also nicht mehr redundant am Netz hängt, es zu keinen Verlusten kommt. Dabei ist egal, welche der beiden Leitungen ist deaktiviere.
Habt ihr eine Idee an was das liegen könnte?
Leider kenne ich mich mit VMware nur oberflächlich aus.
Wenn ihr mir aber sagt, welche Informationen für eine Unterstützung relevant sind und wo ich die finde, liefere ich die natürlich nach.
VMware läuft übrigens in der Version 8 auf dem Cluster.
Danke
mabue88
wir haben ein ESX-Cluster aus drei Hosts. Host 1 und 2 sind die "Arbeiter" und der Host 3 ist der (schwächere) Witness-Server.
Wir haben 3 Core-Switches. Jeder der Core-Switches hat eine LAG aus zwei LWL-Verbindungen zu jedem der anderen beiden Switches (im Bild die grünen Verbindungen).
ESX-Host 1 und 2 hängt jeweils redundant mit einem LWL an Switch 1 und mit einem LWL an Switch 2 (im Bild die blaue Verbindungen).
Der ESX-Host 3 hängt lediglich mit 2 LWL an Switch 3.
Nun ist mir aufgefallen, dass wenn ich z. B. ausgehend von VM1 (auf Host 1) die VM3 (auf Host 2) über einen längeren Zeitraum anpinge, es zu ca. 10 % Verlust kommt.
In die Gegenrichtung habe ist das gleiche.
Zunächst dachte ich, dass an der VLAN-Konfiguration der Switch-Ports etwas nicht stimmt, so dass nicht auf jeder Route das entsprechende VLAN konfiguriert ist, aber das habe ich schon mehrfach geprüft und ist nicht der Fall.
Nun ist mir aufgefallen, dass wenn ich von der redundanten Anbindung vom ESX-Host 1 eine Leitung deaktiviere, der Host dann also nicht mehr redundant am Netz hängt, es zu keinen Verlusten kommt. Dabei ist egal, welche der beiden Leitungen ist deaktiviere.
Habt ihr eine Idee an was das liegen könnte?
Leider kenne ich mich mit VMware nur oberflächlich aus.
Wenn ihr mir aber sagt, welche Informationen für eine Unterstützung relevant sind und wo ich die finde, liefere ich die natürlich nach.
VMware läuft übrigens in der Version 8 auf dem Cluster.
Danke
mabue88
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669163
Url: https://administrator.de/contentid/669163
Ausgedruckt am: 21.11.2024 um 13:11 Uhr
45 Kommentare
Neuester Kommentar
Moin,
Spannend. Ich glaube, du suchst aber an der falschen Stelle. Nicht vSphere ist dein Problem, sondern das Netzwerk.
Welche Switche kommen zum Einsatz?
Welche STP-Protokolle (STP, RSTP, MSTP, ...) werden genutzt? Oder ist alles per Stack/ MLAG verbunden?
Spannend. Ich glaube, du suchst aber an der falschen Stelle. Nicht vSphere ist dein Problem, sondern das Netzwerk.
Welche Switche kommen zum Einsatz?
Welche STP-Protokolle (STP, RSTP, MSTP, ...) werden genutzt? Oder ist alles per Stack/ MLAG verbunden?
Die Core-Switches sind Netgear M4300-12X12F.
Dazu noch ein Nachtrag:
Jeder der im Bild dargestellten Core-Switches ist ein Stack aus 2 M4300-12X12F
Die Switches 1, 2 und 3 sind nicht gestackt.
Hier die Konfig auf Switch 1 über das LAG zu Switch 2.
Die Konfig auf Switch 2 über das LAG zu Switch 1 ist identisch.
Soweit ist weiß, wurde die STP-Konfig bei der Inbetriebnahme der Switche in den Default-Einstellungen belassen.
Hier mal ein Screenshot von dem Menü-Punkt "STP Configuration".
Auf dem Screenshot ist absichtlich das Menü dargestellt, so dass du mir sagen kannst, welche Einstellungen evtl. noch von Interesse sind.
Danke!
Dazu noch ein Nachtrag:
Jeder der im Bild dargestellten Core-Switches ist ein Stack aus 2 M4300-12X12F
Die Switches 1, 2 und 3 sind nicht gestackt.
Hier die Konfig auf Switch 1 über das LAG zu Switch 2.
Die Konfig auf Switch 2 über das LAG zu Switch 1 ist identisch.
Soweit ist weiß, wurde die STP-Konfig bei der Inbetriebnahme der Switche in den Default-Einstellungen belassen.
Hier mal ein Screenshot von dem Menü-Punkt "STP Configuration".
Auf dem Screenshot ist absichtlich das Menü dargestellt, so dass du mir sagen kannst, welche Einstellungen evtl. noch von Interesse sind.
Danke!
Moin...
abgesehen das die Netgear Teile echt gruselig sind, wie sind die den verbunden ... SFP+ 10GBASE-T?
bei 10GBASE-T kannst du schon bei einem knick im Kabel probleme bekommen wenn die Neogation zuschlägt... von der abwärme bei 10GBASE-T möchte ich nicht mal sprechen.
was sagen die Protokolle in den switchen?
Frank
abgesehen das die Netgear Teile echt gruselig sind, wie sind die den verbunden ... SFP+ 10GBASE-T?
bei 10GBASE-T kannst du schon bei einem knick im Kabel probleme bekommen wenn die Neogation zuschlägt... von der abwärme bei 10GBASE-T möchte ich nicht mal sprechen.
was sagen die Protokolle in den switchen?
Frank
Das Netzwerk hat einen (vermutlich) aus Redundanzgründen gewollten Loop was bekanntlich der sichere Tod bei Ethernet Netzen ist ohne Loop Protection. Ringstrukturen sind deshalb immer ein NoGo im Ethernetumfeld das in der Regel Sternstrukturen erfordert. In deinem Falle wären Core Switches mit Full Stacking Funktion die deutlich bessere HW Wahl gewesen als eine unglückliche Ring Struktur mit LACP LAGs zumal LAGs keine homogene Linkauslastung garantieren bei schlechter Mac- oder IP Adress Entropie. Alles in allem also ein eher suboptimales Design für ein Datacenter.
Wir raten jetzt mal das du auf allen 3 Core Switches dann Spanning Tree aktiv hast, weil das in so einem Ring Setup absolut zwingend ist andernfalls kollabiert dein Netz durch den Loop. Eine Loop Protection mit Spanning Tree und ein sauberes Customizing ist also essentiell für dich und die Netzwerk Infrastruktur.
Dazu die eigentliche Frage:
Wie die Kollegen oben schon sagen ist sehr wahrscheinlich zu 98% deine Netzinfrastruktur und ein vermutlich falsches oder fehlerhaftes Switch Setup dein eigentliches Problem.
Zum Thema Netgear ist ja oben schon alles gesagt worden.
Wir raten jetzt mal das du auf allen 3 Core Switches dann Spanning Tree aktiv hast, weil das in so einem Ring Setup absolut zwingend ist andernfalls kollabiert dein Netz durch den Loop. Eine Loop Protection mit Spanning Tree und ein sauberes Customizing ist also essentiell für dich und die Netzwerk Infrastruktur.
Dazu die eigentliche Frage:
- Wenn Spanning Tree welches Protokoll?? (STP, RSTP, PVRSTP, MSTP etc.) Und ist das durchgängig auf allen Switches aktiviert?
- Ein sauberes Spanning Tree Setup erzwingt immer die Festlegung eines Root Switches also einen Switch mit erhöhter STP Priority (Vielfache von 4096) um die STP Topologie sicher festzulegen. Welcher der 3 Switches ist das bei dir?? Der Root Switch bestimmt welcher der LAG Ports in den Blocking Mode geht um den Loop zu trennen.
Wie die Kollegen oben schon sagen ist sehr wahrscheinlich zu 98% deine Netzinfrastruktur und ein vermutlich falsches oder fehlerhaftes Switch Setup dein eigentliches Problem.
Zum Thema Netgear ist ja oben schon alles gesagt worden.
Innerhalb der Stacks (also die beiden Geräte innerhalb Switch 1, Switch 2 und Switch 3) sind mit 2x 10GBASE-T verbunden.
Die LAG-Verbindungen zwischen Switch 1, 2 und 3 sind per LWL (SFP+) ausgeführt.
In den Logs von Switch 1 stehen vom 27.10.2024 ein paar Spanning Tree Topology Changes:
In den Logs von Switch 2 stehen etliche "SFP Interrupts":
Danach muss ich gleich mal schauen.
Die LAG-Verbindungen zwischen Switch 1, 2 und 3 sind per LWL (SFP+) ausgeführt.
In den Logs von Switch 1 stehen vom 27.10.2024 ein paar Spanning Tree Topology Changes:
In den Logs von Switch 2 stehen etliche "SFP Interrupts":
Der scheinbar kaputte SFP Port auf Unit 2 triggert dann die wechselnden Spanning Tree Topology Changes die dann wiederum in dem Ringdesign wechselnde (LAG) Ports in den Blocking Mode zwingen mit genau den Symptomen die du dann siehst.
Primär musst du zuallererst also den defekten oder fehlerhaften SFP Port an Unit 2 fixen. Kann auch die SFP Optik oder wenn du DAC/Twinax oder AOC Kabel nutzt das Kabel sein?!
In einem sauber designten Netz mit entsprechender Spanning Tree Hierarchie darf es keinerlei Topology Changes geben und natürlich auch keinerlei "SFP Interrupts"! Im Log sollte diesbezüglich also niemals etwas zu sehen sein.
Primär musst du zuallererst also den defekten oder fehlerhaften SFP Port an Unit 2 fixen. Kann auch die SFP Optik oder wenn du DAC/Twinax oder AOC Kabel nutzt das Kabel sein?!
In einem sauber designten Netz mit entsprechender Spanning Tree Hierarchie darf es keinerlei Topology Changes geben und natürlich auch keinerlei "SFP Interrupts"! Im Log sollte diesbezüglich also niemals etwas zu sehen sein.
Spanning Tree ist auf den Switches zwar aktiviert, aber ich bezweifle, dass es sauber konfiguriert ist.
Dass ALLE DREI Core-Switches derzeit die gleiche STP Priority haben, untermauert das.
Um auf die Frage, welche Spanning Tree Protokolle verwendet werden, eine Antwort geben zu können, fehlt mir noch der Background bzw. finde in der Switch-Konfig nicht die passenden "Begriffe". Kann es sein, dass Netgear etwas andere Begrifflichkeiten verwendet?
Ich schaue jetzt gleich mal nach dem SFP-Port, von dem die Log-Einträge kommen.
Das Netzwerk wurde 2022 in Betrieb genommen, läuft jetzt also seit ca. 2 Jahren. Daher müssen die Geräte noch etwas durchhalten. Aber irgendwann müssen die ja ersetzt werden...
Welchen Hersteller würdet ihr aktuell empfehlen?
Dass ALLE DREI Core-Switches derzeit die gleiche STP Priority haben, untermauert das.
Um auf die Frage, welche Spanning Tree Protokolle verwendet werden, eine Antwort geben zu können, fehlt mir noch der Background bzw. finde in der Switch-Konfig nicht die passenden "Begriffe". Kann es sein, dass Netgear etwas andere Begrifflichkeiten verwendet?
Ich schaue jetzt gleich mal nach dem SFP-Port, von dem die Log-Einträge kommen.
Das Netzwerk wurde 2022 in Betrieb genommen, läuft jetzt also seit ca. 2 Jahren. Daher müssen die Geräte noch etwas durchhalten. Aber irgendwann müssen die ja ersetzt werden...
Welchen Hersteller würdet ihr aktuell empfehlen?
Man könnte den Ring ja theoretisch auch erstmal auftrennen (also beide Leitungen an Switch 2 zu entweder Switch 1 oder Switch 3 kappen) an der fraglichen Unit 2 und der zugehörigen Unit 1, um zu beobachten, ob dein Netz dann sauber läuft.
Läuft über die Switches auch ISCSI? Dann wäre ich sehr zurückhaltend...
Läuft über die Switches auch ISCSI? Dann wäre ich sehr zurückhaltend...
Moin,
der Sinn von dem Core "Ring" erschließt sich mir nicht.
Ich würde das Konstrukt aufbrechen, zwei Switche als Core verwenden (Stack or what ever) und den dritte reduntant an den Core hängen.
Die Komponenten auf Switch drei bekommst du mit deinen begrenzten Mitteln nicht redundant angebunden. Dafür wackelt dein Netz dann nicht mehr.
Außerdem würde ich alle ESXer per LACP anbinden falls noch nicht geschehen.
Gruß
Spirit
der Sinn von dem Core "Ring" erschließt sich mir nicht.
Ich würde das Konstrukt aufbrechen, zwei Switche als Core verwenden (Stack or what ever) und den dritte reduntant an den Core hängen.
Die Komponenten auf Switch drei bekommst du mit deinen begrenzten Mitteln nicht redundant angebunden. Dafür wackelt dein Netz dann nicht mehr.
Außerdem würde ich alle ESXer per LACP anbinden falls noch nicht geschehen.
Gruß
Spirit
1
Hi,
Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
Außerdem würde ich alle ESXer per LACP anbinden falls noch nicht geschehen.
Setz aber Distributed Switches in Vsphere mit der Enterprise Plus Lizenz voraus.Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
aber ich bezweifle, dass es sauber konfiguriert ist.
Was dann keine gute Voraussetzung für einen stabilen Betrieb ist. bzw. finde in der Switch-Konfig nicht die passenden "Begriffe".
Ist, wie üblich, im Bereich Spanning Tree des Setup Menüs zu finden. Beispiel hier an einem Cisco Switch:
Läuft über die Switches auch ISCSI? Dann wäre ich sehr zurückhaltend...
Nein, ISCSI läuft nicht darüber.
Ich würde das Konstrukt aufbrechen, zwei Switche als Core verwenden (Stack or what ever) und den dritte reduntant an den Core hängen.
Den Vorschlag werde ich mir mal durch den Kopf gehen lassen. Hört sich spontan auf jeden Fall deutlich besser an.
Die ESX hängen aktuell nicht per LACP an den Switches. Wir haben aber auch nur eine Standard-Lizenz.
Ist, wie üblich, im Bereich Spanning Tree des Setup Menüs zu finden. Beispiel hier an einem Cisco Switch:
Gefunden! Ich habe es nicht gefunden, weil nicht die Protokollnamen, sondern die Standardnamen aufgeführt sind.
IEEE 802.1w ist auf allen Switches aktiviert, was RSTP entspricht.
Unabhängig von allen anderen Punkten, würde ich die Priority am Wochenende an den Switches anpassen.
Dabei würde ich Switch 1 zur Root-Bridge durch die Priority 4096 zur Root Bridge machen.
Switch 2 erhält dann 8192 und Switch 3 erhält dann 12288. Das sollte passen, oder?
Das sollte passen, oder?
Oben lesen was dir gepostet wurde... 
Es reicht nur den Root Switch zu definieren! Uplinks am Root gehen niemals in den Blocking Mode. Wähle also diesen Switch klug aus. An dem sollten primär alle ESXi zu mindestens mit einem Bein angeschlossen sein.
Wenn du unbedingt willst kannst du den Backup Root Switch mit 8192 definieren, das legt dann ganz wasserdicht die RSTP Topologie fest. Der 3 Switch und ggf. weitere kann auf seinem Default 32768 verbleiben!
Da mit dieser RSTP Topologie dann der LAG Port an Switch 3 zum Switch 2 in den Blocking Mode geht um den Loop zu unterbrechen kann Traffic zw. VM 5 und VM 3 und 4 im Worst Case einmal im Kreis laufen sofern es solche Kommunikationsbeziehung zw. diesen VMs gibt.
Zitat von @tech-flare:
Hi,
Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
Hi,
Außerdem würde ich alle ESXer per LACP anbinden falls noch nicht geschehen.
Setz aber Distributed Switches in Vsphere mit der Enterprise Plus Lizenz voraus.Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
ja guter Punkt, hatte ich vergessen.
Das die solch ein Standard Feature immer noch unter Enterprise-Lizenz stellen.
Zitat von @Spirit-of-Eli:
ja guter Punkt, hatte ich vergessen.
Das die solch ein Standard Feature immer noch unter Enterprise-Lizenz stellen.
Zitat von @tech-flare:
Hi,
Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
Hi,
Außerdem würde ich alle ESXer per LACP anbinden falls noch nicht geschehen.
Setz aber Distributed Switches in Vsphere mit der Enterprise Plus Lizenz voraus.Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
ja guter Punkt, hatte ich vergessen.
Das die solch ein Standard Feature immer noch unter Enterprise-Lizenz stellen.
Was wäre denn aus deiner Sicht besser mit LACP zum ESXi? Ich bin ohne immer gut gefahren.
1
Macht und braucht man in der Regel ja auch nicht, da der ESXi Host ja im Default die VM Macs über seinen vSwitch im Round Robin auf die parallelen Links der Brodcast Domain verteilt. Das ermöglicht auch für Laien einen parallelen Betrieb der Hypervisor NICs auf billigen, ungemanagten Switches was sonst ja auch wieder zu Loops führen würde.
LACP ist zw. Hypervisor vSwitch und physischem Switch also eher weniger sinnvoll und bringt auch durch die Hash basierte Verteilung keine Vorteile.
LACP ist zw. Hypervisor vSwitch und physischem Switch also eher weniger sinnvoll und bringt auch durch die Hash basierte Verteilung keine Vorteile.
2Zitat von @Spirit-of-Eli:
ja guter Punkt, hatte ich vergessen.
Das die solch ein Standard Feature immer noch unter Enterprise-Lizenz stellen.
Zitat von @tech-flare:
Hi,
Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
Hi,
Außerdem würde ich alle ESXer per LACP anbinden falls noch nicht geschehen.
Setz aber Distributed Switches in Vsphere mit der Enterprise Plus Lizenz voraus.Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
ja guter Punkt, hatte ich vergessen.
Das die solch ein Standard Feature immer noch unter Enterprise-Lizenz stellen.
Zitat von @Spirit-of-Eli:
ja guter Punkt, hatte ich vergessen.
Das die solch ein Standard Feature immer noch unter Enterprise-Lizenz stellen.
Zitat von @tech-flare:
Hi,
Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
Hi,
Außerdem würde ich alle ESXer per LACP anbinden falls noch nicht geschehen.
Setz aber Distributed Switches in Vsphere mit der Enterprise Plus Lizenz voraus.Wenn nicht vorhanden, steckst die Kabel vom ESXI "einfach so" an. Den Rest regelt VMware selbst.
ja guter Punkt, hatte ich vergessen.
Das die solch ein Standard Feature immer noch unter Enterprise-Lizenz stellen.
Da es für den „normalen“ Betrieb auch nicht notwendig ist.
Und wenn du zb. Ein Cisco UCS Blade Center für den Betrieb verwendest, nützt dir LACP im VMware auch nichts, da alles der Cisco Interconnect Switch regelt und du im Hypervisor dann nur virtuelle NICs hast
Der Ersteller hat leider ganz andere Probleme. Für ihn wäre es besser er baut sich einen einfachen Stack oder nutzt das MLAG Feature.
vPC fällt aus, da er keine NEXUS Switches verwendet, wobei wir ja gerade „gelernt“ haben, dass es dem ESXI sowieso egal ist und auf alles Uplinks den Traffic „rausjagt“
da er keine NEXUS Switches verwendet
Dacia und Ferrari lassen sich auch schwer vergleichen. Der Ersteller hat leider ganz andere Probleme. Für ihn wäre es besser er baut sich einen einfachen Stack oder nutzt das MLAG Feature.
Wie vorher schon geschrieben, mache ich mir mal Gedanken dazu, Switch 1 und 2 als Stack zu betreiben.
MLAG unterstützen die Netgear M4300 wohl nicht.
Der scheinbar kaputte SFP Port auf Unit 2 triggert dann die wechselnden Spanning Tree Topology Changes die dann wiederum in dem Ringdesign wechselnde (LAG) Ports in den Blocking Mode zwingen mit genau den Symptomen die du dann siehst
Den verursachenden Port habe ich gefunden. Ich bin mir aber noch nicht sicher, ob es der Switch-Port oder das SFP-Modul ist. Aktuell habe ich erst einmal einen neuen SFP-Transceiver in einen anderen Switch-Port gesteckt und den LWL dort aufgesteckt.
Ausgehend von den Pings, die ich hier kontinuierlich laufen habe, sieht es schon mal viel besser aus.
Ein paar Pings (ca. 1 %) gehen aber immer noch verloren.
Deswegen habe ich mir unabhängig davon, dass das Netzwerk zwischen den Core-Switches Verbesserungspotenzial aufweist, mir das aktuelle Setup nochmal angeschaut.
Rapid STP ist auf allen drei Switches aktiv und identisch konfiguriert.
Die Bridge Priorities sind auch auf allen 3 Switches identisch, aber wenn ich das richtig verstanden habe, äußert sich das nur dadurch, dass die anhand der MAC-Adressen der Switches entschieden wird, welcher Switch zur Root-Bridge wird, die Root Bridge also nicht explizit festgelegt wird.
Der Switch 2 hat die kleines MAC-Adresse, weshalb er aktuell auch die Root Bridge ist.
Hier ein Bild dazu, ich hoffe es ist einigermaßen leserlich
Damit sollte durch Spanning Tree aktuell die Schleife vermieden sein, oder?
Da wir aber immer noch hin und wieder Pings verlieren, muss noch ein anderer Fehler vorliegen...
Switch 1 und 2 als Stack zu betreiben.
Wäre sicher das Sinnvollste in deinem Setup. Wenn die NG Gurken auch horizontal Stacking supporten wäre es noch deutlich sinnvoller auch den 3ten Switch in den Stack zu integrieren.Wenn sie on top auch noch Stack Trunking supporten, also das Bündeln von Stack Uplinks umso besser! Dann kannst du die auch weiter mit 20G Bandbreite betreiben.
Das eliminiert dann auch gleichzeitg vollständig die Spanning Tree Thrematik wenn du sie in einem Daisy Chaining Setup verbindest.
Ein paar Pings (ca. 1 %) gehen aber immer noch verloren.
Kein gutes Zeichen. Bei deiner Bandbreite sollte es niemals zu Ping Losses kommen.
aber wenn ich das richtig verstanden habe, äußert sich das nur dadurch, dass die anhand der MAC-Adressen der Switches entschieden wird, welcher Switch zur Root-Bridge wird
Das ist richtig! Die niedrigste Mac gewinnt dann die Root Lotterie bei gleicher Priority. Dein Bild zeigt es entsprechend.Damit sollte durch Spanning Tree aktuell die Schleife vermieden sein
Ja.Die NG Gurken können sicher nur Single Span Spanning Tree, richtig? Also ein gemeinsamer STP Prozess für alle VLANs. Eh nur relevant wenn du eine VLAN Segmentierung auf den Kisten machst.
Da wir aber immer noch hin und wieder Pings verlieren, muss noch ein anderer Fehler vorliegen...
Richtig! Das dürfte in deinem Setup und bei 20G Uplink Bandbreite niemals passieren! Da liegt vermutlich irgendwo nochwas im Argen.
Es tut mir leid, das zu schreiben, aber irgendwie hast du alle nciht so optimalen Möglichkeiten kombiniert.
Das Design ist kein Design, sondern eine Katastrophe.
Ich würde mich entscheiden was erreicht werden soll, dann best practices strikt einflegen.
Wie schon angemerkt könnte ein SFP ständig die Topologie neu bauen lassen. Hier fällt eben auf, dass das im Core passiert und dort nichts zu suchen haben sollte.
Vielleicht holst du einen Pro für ein tag ins haus und baust etwas Solides mit dem Mann?!
Das Design ist kein Design, sondern eine Katastrophe.
Ich würde mich entscheiden was erreicht werden soll, dann best practices strikt einflegen.
Wie schon angemerkt könnte ein SFP ständig die Topologie neu bauen lassen. Hier fällt eben auf, dass das im Core passiert und dort nichts zu suchen haben sollte.
Vielleicht holst du einen Pro für ein tag ins haus und baust etwas Solides mit dem Mann?!
Ich habe ein Update für euch.
Am Wochenende habe ich die Bridge Priorities angepasst. Damit passt im aktuellen Aufbau zumindest mal die Root-Bridge.
Außerdem habe ich im vCenter vermutlich einen Fehler in der Konfiguration gefunden.
Innerhalb der verteilten Portgruppe ist unter
"Konfiguration" -> "Richtlinien" -> "Teaming und Failover" -> "Lastausgleich"
=> Anhand des IP-Hashs routen
eingestellt.
Dafür wird aber ein LAG benötigt. Mit der aktuellen Anbindung an die beiden nicht-gestackten Switches geht das ja aber nicht.
Könnt ihr bestätigen, dass an dieser Stelle die Einstellung
=> Anhand des ursprünglichen virtuellen Ports routen
im aktuellen Aufbau die bessere/korrekte Wahl wäre?
Nach euren Hinweisen und Kommentaren werden wir mit entsprechender externen Unterstützung den aktuellen Aufbau nochmal unseren Anforderungen gegenüberstellen, kritisch hinterfragen und anschließend entsprechend anpassen.
Vielen Dank schon mal für eure konstruktive Unterstützung!
Am Wochenende habe ich die Bridge Priorities angepasst. Damit passt im aktuellen Aufbau zumindest mal die Root-Bridge.
Außerdem habe ich im vCenter vermutlich einen Fehler in der Konfiguration gefunden.
Innerhalb der verteilten Portgruppe ist unter
"Konfiguration" -> "Richtlinien" -> "Teaming und Failover" -> "Lastausgleich"
=> Anhand des IP-Hashs routen
eingestellt.
Dafür wird aber ein LAG benötigt. Mit der aktuellen Anbindung an die beiden nicht-gestackten Switches geht das ja aber nicht.
Könnt ihr bestätigen, dass an dieser Stelle die Einstellung
=> Anhand des ursprünglichen virtuellen Ports routen
im aktuellen Aufbau die bessere/korrekte Wahl wäre?
Nach euren Hinweisen und Kommentaren werden wir mit entsprechender externen Unterstützung den aktuellen Aufbau nochmal unseren Anforderungen gegenüberstellen, kritisch hinterfragen und anschließend entsprechend anpassen.
Vielen Dank schon mal für eure konstruktive Unterstützung!
Nein kann nicht bestätigt werden.
Du musst deine Perspektive ändern.
Optimal ist ein Core, wenn dessen Member vom anderen Member nicht nur nichts wissen, sondern deren Ausfall auch nicht bemerken. Der Admin sieht fehlende Bandbreite, der Server sollte meisten mit weniger als 50% laufen.
Die ESXi brauchen einfach nur Uplinks. Die Uplinks sollten genug Bandbreite haben.
Reichen 1/2,5/5 und 10 nicht aus, dann macht man 10/25/40/50 und 100 aber keine Aggregationen.
Du musst deine Perspektive ändern.
Optimal ist ein Core, wenn dessen Member vom anderen Member nicht nur nichts wissen, sondern deren Ausfall auch nicht bemerken. Der Admin sieht fehlende Bandbreite, der Server sollte meisten mit weniger als 50% laufen.
Die ESXi brauchen einfach nur Uplinks. Die Uplinks sollten genug Bandbreite haben.
Reichen 1/2,5/5 und 10 nicht aus, dann macht man 10/25/40/50 und 100 aber keine Aggregationen.
1
Aber aktuell passt die Konfiguration der ESX-Uplinks doch nicht dazu, wie die Uplinks auf den Switches landen?!?!
Wenn ich das richtig verstehe, müsste ausgehend von der ESX-Konfiguration die Uplinks Switch-seitig doch als LAG konfiguriert sein, damit das zusammen passt, oder?
Wenn ich das richtig verstehe, müsste ausgehend von der ESX-Konfiguration die Uplinks Switch-seitig doch als LAG konfiguriert sein, damit das zusammen passt, oder?
In deiner aktuellen Skizze oben fehlen leider die ESXi Hosts so das man dazu schlecht etwas sagen kann.
Üblicherweise sind LACP LAGs aber eher die seltene Ausnahme bei VmWare, weil die vSwitches ja so oder so von sich aus bei parallelen Links eine Round Robin Verteilung der VM Mac Adressen vornehmen. Default damit man auch an ungemanagten Switches parallele Links betreiben kann. Das macht dann eine LAG Konfiguration von sich aus überflüssig.
Üblicherweise sind LACP LAGs aber eher die seltene Ausnahme bei VmWare, weil die vSwitches ja so oder so von sich aus bei parallelen Links eine Round Robin Verteilung der VM Mac Adressen vornehmen. Default damit man auch an ungemanagten Switches parallele Links betreiben kann. Das macht dann eine LAG Konfiguration von sich aus überflüssig.
1Zitat von @mabue88:
Aber aktuell passt die Konfiguration der ESX-Uplinks doch nicht dazu, wie die Uplinks auf den Switches landen?!?!
Wenn ich das richtig verstehe, müsste ausgehend von der ESX-Konfiguration die Uplinks Switch-seitig doch als LAG konfiguriert sein, damit das zusammen passt, oder?
Aber aktuell passt die Konfiguration der ESX-Uplinks doch nicht dazu, wie die Uplinks auf den Switches landen?!?!
Wenn ich das richtig verstehe, müsste ausgehend von der ESX-Konfiguration die Uplinks Switch-seitig doch als LAG konfiguriert sein, damit das zusammen passt, oder?
Nein eben nicht! Du hast dir die Antworten nicht durchgelesen, oder?
Für ESXI brauchst du in der Regel kein LAG ( nutzen wir selbst bei mehreren hunderten VM mit 100G nicht).
Davon abgesehen benötigst du für LACP in VMware eine Enterprise Plus Lizenz - hast du diese?
Dein Problem ist dein "Konstrukt" mit/ohne Stack und SpanningTree und nicht der ESXI Host.
1
Wie die Kollegen schreiben... Du musst deine LAGs vergessen, egal was die LAGs steuert.
LAG ist Mist. Wir haben 2024.
Es scheint so, als würdest du ohne es zu bemerken, ganz viele Techniken kombinieren wollen, die für sich genommen nachteilig sind. Und dann ist deine Kombi unterm Strich nicht nur nachteilig sondern anfällig und ein Stück weit sinnfrei.
LAG ist Mist. Wir haben 2024.
Es scheint so, als würdest du ohne es zu bemerken, ganz viele Techniken kombinieren wollen, die für sich genommen nachteilig sind. Und dann ist deine Kombi unterm Strich nicht nur nachteilig sondern anfällig und ein Stück weit sinnfrei.
Eigentlich meinte ich das auch so.
Aktuell ist die Verbindung in den ESX-Hosts so konfiguriert, als ob die beiden Uplinks als LAG laufen.
Switch-seitig funktioniert das bei dem aktuellen Aufbau ja aber nicht, da die beiden Switches, auf denen je ein Uplink hängt, nicht als Stack laufen.
Daher würde ich die Konfiguration in den ESX-Hosts so ändern, dass die beiden Uplinks eben NICHT als LAG konfiguriert sind.
Und das müsste doch der Fall sein, wenn ich innerhalb der verteilten Portgruppe unter
"Konfiguration" -> "Richtlinien" -> "Teaming und Failover" -> "Lastausgleich"
=> Anhand des IP-Hashs routen
als Betriebsart auswähle.
Damit sollten die beiden Uplinks ESX-seitig nicht mehr als LAG laufen.
Aktuell ist die Verbindung in den ESX-Hosts so konfiguriert, als ob die beiden Uplinks als LAG laufen.
Switch-seitig funktioniert das bei dem aktuellen Aufbau ja aber nicht, da die beiden Switches, auf denen je ein Uplink hängt, nicht als Stack laufen.
Daher würde ich die Konfiguration in den ESX-Hosts so ändern, dass die beiden Uplinks eben NICHT als LAG konfiguriert sind.
Und das müsste doch der Fall sein, wenn ich innerhalb der verteilten Portgruppe unter
"Konfiguration" -> "Richtlinien" -> "Teaming und Failover" -> "Lastausgleich"
=> Anhand des IP-Hashs routen
als Betriebsart auswähle.
Damit sollten die beiden Uplinks ESX-seitig nicht mehr als LAG laufen.
ja aber nicht, da die beiden Switches, auf denen je ein Uplink hängt, nicht als Stack laufen.
Da hast du Recht. Das kann niemals so klappen denn bekanntlich arbeiten LAGs prinzipbedingt nur auf einer Hardware. Ein Splitting der LAG Member Links sieht der 802.3ad Standard nicht vor!Ausnahme ist: Deine Switches supporten eine MLAG Funktion (Multichassis LAG)?! Damit wäre ein Splitting der LAG Memberlinks auf unterschiedliche Switch Hardware problemlos möglich. Leider machst du dazu keinerlei hilfreiche Angaben ob das ggf. so bei dir konfiguriert ist.
Es bleibt aber dabei: LAGs sind in einem Hypervisor Umfeld aufgrund des Handlings paralleler Links im Default in der Regel überflüssig.
Ja, dass ist das was ich sage. Als ob sie so laufen? Sind sie so konfiguriert? Oder nicht? Wenn ja, was genau ist konfiguriert?
Und dann willst du dem ein Stack gegenüberstellen, weil du die LAG-Ports aufteilen willst. Kann man machen, macht aber fast niemand und wenn, dann mit sehr guten Gründen und auch Ahnung von der Materie. Stacks sind -wenn überhaupt- etwas fürs Edge. Also vor 20 Jahren.
Ja, IP Hash macht Sinn, wäre sinnvoller, wenn es kein als ob LAG wäre.
Du musst an das Thema anders ran. 1. Was ist mein Bedarf. 2. was sind die Best Practices.
Jetzt hinterlässt das den Eindruck, als würdest du alle Buzzwords einer Vertriebsveranstaltung verbauen wollen.
Was läuft den überhaupt auf dem ESXI, dass aus einem LAG Profit schlagen würde? (Bedarf)
Was würden die Switches von einem LAG untereinander für Vorteile haben? (Bedarf)
Hast du eine entsprechende Lizenz aufm ESXi für LAG (distributed Switch)?
Wenn du das Ganze toll findest, was ich gut verstehe, dann gucke lieber ob du an NSX kommst, das bedienen kannst und ein Spine-Leaf baust. Das geht auch mit wenig Hosts und Switches, wenn auch mit miesen ROI.
Und dann willst du dem ein Stack gegenüberstellen, weil du die LAG-Ports aufteilen willst. Kann man machen, macht aber fast niemand und wenn, dann mit sehr guten Gründen und auch Ahnung von der Materie. Stacks sind -wenn überhaupt- etwas fürs Edge. Also vor 20 Jahren.
Ja, IP Hash macht Sinn, wäre sinnvoller, wenn es kein als ob LAG wäre.
Du musst an das Thema anders ran. 1. Was ist mein Bedarf. 2. was sind die Best Practices.
Jetzt hinterlässt das den Eindruck, als würdest du alle Buzzwords einer Vertriebsveranstaltung verbauen wollen.
Was läuft den überhaupt auf dem ESXI, dass aus einem LAG Profit schlagen würde? (Bedarf)
Was würden die Switches von einem LAG untereinander für Vorteile haben? (Bedarf)
Hast du eine entsprechende Lizenz aufm ESXi für LAG (distributed Switch)?
Wenn du das Ganze toll findest, was ich gut verstehe, dann gucke lieber ob du an NSX kommst, das bedienen kannst und ein Spine-Leaf baust. Das geht auch mit wenig Hosts und Switches, wenn auch mit miesen ROI.
Zitat von @150631:
Wie die Kollegen schreiben... Du musst deine LAGs vergessen, egal was die LAGs steuert.
LAG ist Mist. Wir haben 2024.
Wie die Kollegen schreiben... Du musst deine LAGs vergessen, egal was die LAGs steuert.
LAG ist Mist. Wir haben 2024.
Die Aussage ist mit Vorsicht zu genießen.
Bei ganz vielen kleinen Workloads mag dieses simple aufstecken der ESXer ja funktionieren. Sobald aber ein Loadbalancing von peaks nötig ist, stößt dieses Verfahren an seine Grenzen.
Ich habe das lang genug diskutiert, daher haben wir tatsächlich den Aufwand betrieben, und sämtliche neuen ESXer per LACP angebunden. (jeweils LAN ein Trunk und das vSAN ein Trunk)
1
Wo läuft denn den LB? Und warum soll der LB aus LAGs Profit ziehen können, der aus der Summe der Links nicht ohnehin möglich ist?
vSAN würde ich hier noch mal außen vorlassen, da gibt es noch sehr viele zusätzliche und andere Aspekte zu beachten.
Die Grundfeststellung muss bzw sollte doch sein, dass auf dem ESXi etwas läuft, dass effektiv ein LAG Vorteile bringt. Was wäre das? Ein LB, der nur einen Uplink kann?
vSAN würde ich hier noch mal außen vorlassen, da gibt es noch sehr viele zusätzliche und andere Aspekte zu beachten.
Die Grundfeststellung muss bzw sollte doch sein, dass auf dem ESXi etwas läuft, dass effektiv ein LAG Vorteile bringt. Was wäre das? Ein LB, der nur einen Uplink kann?
Das Problem ohne LAG ist, dass die Verbindung einer VM dann auf einem Link hängen bleibt.
Pro VM findet kein Loadbalancing statt. Dass ist nur mit LACP möglich.
Das Resultat ist, dass bei zwischenzeitlich auftretenden großen Lasten alles über einen Link vom ESX auf den Switch fällt.
Die unterschiedlichen Hash-Verfahren mal außen vor gelassen. Es geht um das Scenario wo auf Switch Seite keine Anpassung statt findet.
Pro VM findet kein Loadbalancing statt. Dass ist nur mit LACP möglich.
Das Resultat ist, dass bei zwischenzeitlich auftretenden großen Lasten alles über einen Link vom ESX auf den Switch fällt.
Die unterschiedlichen Hash-Verfahren mal außen vor gelassen. Es geht um das Scenario wo auf Switch Seite keine Anpassung statt findet.
1
Die VM sieht keine Links, sondern ein Switchport.
Die VM mit ihrer Software muss in der Lage sein die Vorteile eines LAG zu nutzen. Deshalb Frage ich nach der VM und dessen Software?!
Wenn da eine Single-Session "Last" läuft, dann ist sowohl jeder weitere Member im LAG als auch weiterer Round-Robin Pfad über mehr Ports unnütz.
Wenn da eine "last" läuft, die viele Session aufmacht, dann interessiere ich mich dafür, warum die Summe der Ports ohne LAG dem LAG mit selbiger Portanzahl vorzuziehen ist.
Die VM mit ihrer Software muss in der Lage sein die Vorteile eines LAG zu nutzen. Deshalb Frage ich nach der VM und dessen Software?!
Wenn da eine Single-Session "Last" läuft, dann ist sowohl jeder weitere Member im LAG als auch weiterer Round-Robin Pfad über mehr Ports unnütz.
Wenn da eine "last" läuft, die viele Session aufmacht, dann interessiere ich mich dafür, warum die Summe der Ports ohne LAG dem LAG mit selbiger Portanzahl vorzuziehen ist.
Die VM sieht keine Links, sondern ein Switchport.
Womit du vermutlich den vSwitch meinst?! Das ist per se richtig aber entscheidend ist wie der vSwitch dann mit den NICs umgeht die ihn auf den physischen LAN Switch connecten.Hier hat Kollege @Spirit-of-Eli natürlich Recht das ohne LAG eine VM fest auf einen NIC Link gemappt ist und ein Traffic Balancing unterschiedlicher Endgeräte zur VM nicht stattfindet. Bei einem Hypervisor mit z.B. nur 2 VMs aber 4 aktiven NICs würden nur 2 NICs aktiv genutzt. Das "Balancing" ohne LAG ist also quasi nur die Anzahl der NIC Links selber, nicht aber ein Balancing des jeweiligen VM Traffics über alle zur Verfügung stehenden NICs.
Das erreicht man natürlich nur mit einem LAG der dann je nach verwendetem Hashing Algorithmus den Traffic verteilt. Bei einer VM mit sehr viel Clients kann ein LAG also in bestimmten Situationen Sinn machen. Es kommt halt auf die Nutzung an.
Ja, es kommt auf die Nutzung an.
Macht die Software der VM nicht viele gleichzeitige Verbindungen, dann ist die Diskussion obsolet.
Bei 100/1000MBit ist das eine Diskussion hin und wieder wert, weil es aufm Papier sich rechnet günstige Port zu aggregieren. Aber bei größer als 10/25 nicht mehr. Deshalb Frage ich ja, was da läuft.
Ich beobachte auch sehr oft, das falsche Vorstellungnen von dem Thema herrschen. Viele Admins glauben 1GbE ist zu wenig und dann sind die Ports im Mittel bei nciht mal 10Mbit übern Tag verteilt. Das gilt auch oft für die Serverseite.
Und Anfang war ja der Hilferruf: Hilfe, ich aggregiere meine Hardware und STP, was die Bandbreiten eh halbiert, läuft nciht stabil und es schüttelt den Baum. Das wirft Fragen auf, warum überhaupt Techniken so ungünstig kombiniert werden. also teure Ports schalten, die dann von einem Protokoll teilweise deaktiviert werden usw.. usw...
Macht die Software der VM nicht viele gleichzeitige Verbindungen, dann ist die Diskussion obsolet.
Bei 100/1000MBit ist das eine Diskussion hin und wieder wert, weil es aufm Papier sich rechnet günstige Port zu aggregieren. Aber bei größer als 10/25 nicht mehr. Deshalb Frage ich ja, was da läuft.
Ich beobachte auch sehr oft, das falsche Vorstellungnen von dem Thema herrschen. Viele Admins glauben 1GbE ist zu wenig und dann sind die Ports im Mittel bei nciht mal 10Mbit übern Tag verteilt. Das gilt auch oft für die Serverseite.
Und Anfang war ja der Hilferruf: Hilfe, ich aggregiere meine Hardware und STP, was die Bandbreiten eh halbiert, läuft nciht stabil und es schüttelt den Baum. Das wirft Fragen auf, warum überhaupt Techniken so ungünstig kombiniert werden. also teure Ports schalten, die dann von einem Protokoll teilweise deaktiviert werden usw.. usw...
Zitat von @150631:
Ja, es kommt auf die Nutzung an.
Macht die Software der VM nicht viele gleichzeitige Verbindungen, dann ist die Diskussion obsolet.
Ja, es kommt auf die Nutzung an.
Macht die Software der VM nicht viele gleichzeitige Verbindungen, dann ist die Diskussion obsolet.
Eben genau die Annahme ist Käse. Die VM kann gerne 1000x gleichzeitige Verbindungen aufbauen.
Ohne LACP am Hypervisor bleiben die alle auf einem Link des Hypervisors hängen.
1
Nein, tun sie nicht. Sie würden schön auf die Uplink verteilt werden, wenn nichts anders eingestellt ist.
Zitat von @150631:
Nein, tun sie nicht. Sie würden schön auf die Uplink verteilt werden, wenn nichts anders eingestellt ist.
Nein, tun sie nicht. Sie würden schön auf die Uplink verteilt werden, wenn nichts anders eingestellt ist.
Ohne dem Switch irgend etwas beizubringen kann das schon von der Logik her nicht funktionieren.
Das hätte zur Folge, dass eine MAC über mehrere Schnittstellen am Switch erreichbar sein müsste. Das kann bekanntlich nicht funktionieren. Zumindest nicht nach reinem IP-Standard.
Sie würden schön auf die Uplink verteilt werden
Nein, das ist so nicht richtig und weisst du vermutlich auch selber. Wenn nicht kannst du es dir mit dem Wireshark an einem Mirror Port einer Hypervisor NIC ansehen. VM Macs werden immer fest eine ein NIC gemappt. Kollege @Spirit-of-Eli hat hier Recht.
Noch mal, zum dritten oder vierten mal: Was läuft da?!
Ein Webservice hat andere Bedürfnisse als ein SMB-Server.
Und ja richtig erkannt, über die Anzahl von z. b. der MACs, IPs, Ports usw kann man in den meisten Fällen schon mehr erreichen als ein Aggregation am Server zu bauen die ich am anderen Ende nur schwer den Gummi auf die Straße bringt. Die Kernaussage ist und bleibt, dass mehr Ports (pust an brunch of ports) in den misten Fällen mehr bringt als eine Aggregation. Ausnahmen bestätigen die Regel. Ich will mich ml versuchen zu erinnern, aber seit 10 Jahren habe ich nichts mehr gesehen was ein LAG übervorteilt am ESXi. Auch nicht bei 1GbE.
Ich lasse mich aber gerne inspirieren.
Ein Webservice hat andere Bedürfnisse als ein SMB-Server.
Und ja richtig erkannt, über die Anzahl von z. b. der MACs, IPs, Ports usw kann man in den meisten Fällen schon mehr erreichen als ein Aggregation am Server zu bauen die ich am anderen Ende nur schwer den Gummi auf die Straße bringt. Die Kernaussage ist und bleibt, dass mehr Ports (pust an brunch of ports) in den misten Fällen mehr bringt als eine Aggregation. Ausnahmen bestätigen die Regel. Ich will mich ml versuchen zu erinnern, aber seit 10 Jahren habe ich nichts mehr gesehen was ein LAG übervorteilt am ESXi. Auch nicht bei 1GbE.
Ich lasse mich aber gerne inspirieren.
@150631
Ich denke mal "Inspiration" haben wir genug geliefert. Wenn dir das nicht reicht verschwende ich da auch keine Energie.
Der TO darf da gerne seine Schlüsse draus ziehen.
Ich denke mal "Inspiration" haben wir genug geliefert. Wenn dir das nicht reicht verschwende ich da auch keine Energie.
Der TO darf da gerne seine Schlüsse draus ziehen.
1
Ich denke der TO hat andere Sorgen.
Ich habe schon teilweise 400G zur Verfügung, und somit auch andere Sorgen.
Ich habe schon teilweise 400G zur Verfügung, und somit auch andere Sorgen.
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Hallo,
auf den ESX-Hosts laufen unterschiedlichste Server/VMs.
Die Anforderung an die Netzwerkanbindung der Server ist im wesentlichen, dass die VMs beim Auftreten EINES Fehlers, z.B.
- Ausfall/Trennen einer Netzwerkverbindung
oder
- Ausfall eines Switches
weiterhin im Netzwerk erreichbar sein sollen.
Die Bandbreite spielt gar nicht so die große Rolle, es gehen nur sehr selten mehr als 1G über die Leitung/en.
Wie auch schon geschrieben, gibt es bei dem aktuellen Aufbau Punkte, die man anders lösen kann.
Der Ziel des ERSTEN Schritts war es aber das Netz mit dem aktuellen Aufbau zunächst wieder stabil zum Laufen zu bekommen. Einige Schritte werden aber noch folgen.
Nochmal zusammenfassend:
- Auf den ESX war ein LAG konfiguriert, das aber nicht zur Struktur des Netzwerkes und der Switch-Config passt. Das war schlicht ein Konfigurationsfehler.
- Dadurch traten Paketverluste auf.
- Diese Paketverluste konnten wir durch die Konfigurationsanpassung auf den ESX beseitigen, dort ist jetzt kein LAG mehr konfiguriert.
Danke für eure Unterstützung.
auf den ESX-Hosts laufen unterschiedlichste Server/VMs.
Die Anforderung an die Netzwerkanbindung der Server ist im wesentlichen, dass die VMs beim Auftreten EINES Fehlers, z.B.
- Ausfall/Trennen einer Netzwerkverbindung
oder
- Ausfall eines Switches
weiterhin im Netzwerk erreichbar sein sollen.
Die Bandbreite spielt gar nicht so die große Rolle, es gehen nur sehr selten mehr als 1G über die Leitung/en.
Wie auch schon geschrieben, gibt es bei dem aktuellen Aufbau Punkte, die man anders lösen kann.
Der Ziel des ERSTEN Schritts war es aber das Netz mit dem aktuellen Aufbau zunächst wieder stabil zum Laufen zu bekommen. Einige Schritte werden aber noch folgen.
Nochmal zusammenfassend:
- Auf den ESX war ein LAG konfiguriert, das aber nicht zur Struktur des Netzwerkes und der Switch-Config passt. Das war schlicht ein Konfigurationsfehler.
- Dadurch traten Paketverluste auf.
- Diese Paketverluste konnten wir durch die Konfigurationsanpassung auf den ESX beseitigen, dort ist jetzt kein LAG mehr konfiguriert.
Danke für eure Unterstützung.
3
