17
Proxmox Cluster Bond mit Netgear LAG - Hilfe
Guten Tag in die Runde,
ich benötige dringend das Schwarmwissen.
Ich möchte Folgendes tun :
Erstellung eines Proxmox Clusters mit dediziertem Clusternetzwerk.
Das sieht ungefähr so aus :
In jedem Host befinden sich 8 Netzwerkschnittstellen (10GB/s).
Jeweils 3 x 2 davon sollen als Bond (Proxmox) an ein LAG (Netgear-M4350 Switch) angebunden werden.
Das ganze mit möglichst größtmöglicher Performance.
Ich habe folgendes probiert :
Einstellungen am Switch :
Erstellung eines LAG mit 2 Ports :
Hash Mode 3 (src/dest MAC, VLAN, EType incoming port) und auch
Hash Mode 6 (src/dest IP and TCP/UDP Port Fields)
Einstellung an Proxmos Hosts :
Erstellung eines Bond mit LACP layer2, layer 2+3 und layer 3+4 mit 2 der Netzwerkanschlüsse
Erstellung einer Linux-Bridge mit dem bond und Vergabe einer IP-Adresse, die mit dem normalen Netzwerk nichts zu tun hat (in diesem Fall 10.10.1.1/24, beim nächsten Host 10.10.1.2/24 usw.)
Egal, wie ich die Bonds und Lags kombiniere, ich bekomme nur lokal einen Ping auf die eigene IP hin, auf die "gegnerische" nicht.
Ich bin am verzweifeln.
Hat das schon mal jemand gemacht und kann mir sagen, wo mein Fehler liegt ?
Als Gegentest habe ich Folgendes getan :
Am Switch LAG aufgelöst - also zwei eigenständige Ports.
Am Proxmos Host den Bond wie oben beschrieben erstellt, allerdings mit Hash-Mode balance-rr.
Damit habe ich zwischen den Hosts eine Verbindung.
Leider stellt dies aber nur eine Art Failover dar, ich möchte höchstmögliche Performance, weil in dem Cluster ca. 50 virtuelle Maschinen laufen werden.
Wer kann mir helfen ?
Viele Grüße
der gestresste Mike
ich benötige dringend das Schwarmwissen.
Ich möchte Folgendes tun :
Erstellung eines Proxmox Clusters mit dediziertem Clusternetzwerk.
Das sieht ungefähr so aus :
In jedem Host befinden sich 8 Netzwerkschnittstellen (10GB/s).
Jeweils 3 x 2 davon sollen als Bond (Proxmox) an ein LAG (Netgear-M4350 Switch) angebunden werden.
Das ganze mit möglichst größtmöglicher Performance.
Ich habe folgendes probiert :
Einstellungen am Switch :
Erstellung eines LAG mit 2 Ports :
Hash Mode 3 (src/dest MAC, VLAN, EType incoming port) und auch
Hash Mode 6 (src/dest IP and TCP/UDP Port Fields)
Einstellung an Proxmos Hosts :
Erstellung eines Bond mit LACP layer2, layer 2+3 und layer 3+4 mit 2 der Netzwerkanschlüsse
Erstellung einer Linux-Bridge mit dem bond und Vergabe einer IP-Adresse, die mit dem normalen Netzwerk nichts zu tun hat (in diesem Fall 10.10.1.1/24, beim nächsten Host 10.10.1.2/24 usw.)
Egal, wie ich die Bonds und Lags kombiniere, ich bekomme nur lokal einen Ping auf die eigene IP hin, auf die "gegnerische" nicht.
Ich bin am verzweifeln.
Hat das schon mal jemand gemacht und kann mir sagen, wo mein Fehler liegt ?
Als Gegentest habe ich Folgendes getan :
Am Switch LAG aufgelöst - also zwei eigenständige Ports.
Am Proxmos Host den Bond wie oben beschrieben erstellt, allerdings mit Hash-Mode balance-rr.
Damit habe ich zwischen den Hosts eine Verbindung.
Leider stellt dies aber nur eine Art Failover dar, ich möchte höchstmögliche Performance, weil in dem Cluster ca. 50 virtuelle Maschinen laufen werden.
Wer kann mir helfen ?
Viele Grüße
der gestresste Mike
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 21169377353
Url: https://administrator.de/contentid/21169377353
Printed on: July 26, 2024 at 23:07 o'clock
17 Comments
Latest comment
Das LACP LAG Tutorial hast du gelesen zu der Thematik?!
Link Aggregation (LAG) im Netzwerk
Vermutlich hast du nicht beachtet das das LAG Verfahren an beiden Enden identisch sein muss!! 🤔
Auf der Switch Seite ist nur ein LACP LAG nach IEEE Standard 802.3ad bzw. IEEE 802.1ax standartisiert. Alles andere sind proprietäre Verfahren die dann auch immer beide Seiten supporten müssen, denn beide Seiten müssen identische Verfahren nutzen ansonsten kommt so ein LAG nicht zustande.
Du kannst also niemals "frei" unterschiedliche Verfahren an beiden Enden mischen. Schon deswegen nicht um nicht in die Gefahr eines Netzwerk Loops zu geraten oder einen Spanning Tree Blocking Event auszulösen. Nur das du das auf dem Radar hast...
Wie LACP LAGs auf Proxmox Seite laufen erklärt deren Knowledgebase:
https://forum.proxmox.com/tags/lacp/
Link Aggregation (LAG) im Netzwerk
Vermutlich hast du nicht beachtet das das LAG Verfahren an beiden Enden identisch sein muss!! 🤔
Auf der Switch Seite ist nur ein LACP LAG nach IEEE Standard 802.3ad bzw. IEEE 802.1ax standartisiert. Alles andere sind proprietäre Verfahren die dann auch immer beide Seiten supporten müssen, denn beide Seiten müssen identische Verfahren nutzen ansonsten kommt so ein LAG nicht zustande.
Du kannst also niemals "frei" unterschiedliche Verfahren an beiden Enden mischen. Schon deswegen nicht um nicht in die Gefahr eines Netzwerk Loops zu geraten oder einen Spanning Tree Blocking Event auszulösen. Nur das du das auf dem Radar hast...
Wie LACP LAGs auf Proxmox Seite laufen erklärt deren Knowledgebase:
https://forum.proxmox.com/tags/lacp/
Ja, soweit habe ich das schon verstanden. Nur leider scheitert es schon an den unterschiedlichen Bezeichnungen auf beiden Seiten (Netgear und Proxmox).
Meine Frage zielt darauf, herauszufinden, welche LAG Verfahren zwischen Proxmox und Netgear funktionieren.
Das Proxmox Forum hat mir da bisher nicht weitergeholfen.
Meine Frage zielt darauf, herauszufinden, welche LAG Verfahren zwischen Proxmox und Netgear funktionieren.
Das Proxmox Forum hat mir da bisher nicht weitergeholfen.
Bei Switch Infrastrukturen in der Regel die nach dem LACP LAG Standard 802.3ad bzw. IEEE 802.1ax.
Es gibt auch statische wie es in Hypervisoren wie VmWare usw. üblich ist, die dann die VM Mac Adressen im Round Robin auf multiple, parallele Links verteilen aber dazu muss aus Hypervisor Sicht immer sichergestellt sein das diese entsprechende Loop Protection Mechanismen aktiv haben ansonsten kommt es auf Switchseite sofort zu einem Loop bzw. Spanning Tree Blocking sofern aktiv.
Es gibt auch statische wie es in Hypervisoren wie VmWare usw. üblich ist, die dann die VM Mac Adressen im Round Robin auf multiple, parallele Links verteilen aber dazu muss aus Hypervisor Sicht immer sichergestellt sein das diese entsprechende Loop Protection Mechanismen aktiv haben ansonsten kommt es auf Switchseite sofort zu einem Loop bzw. Spanning Tree Blocking sofern aktiv.
Da Du es allgemein ausdrückst, nehme ich an, Du hast das mit Proxmox noch nicht durchgespielt ?
Zitat von @miscmike:
Da Du es allgemein ausdrückst, nehme ich an, Du hast das mit Proxmox noch nicht durchgespielt ?
Da Du es allgemein ausdrückst, nehme ich an, Du hast das mit Proxmox noch nicht durchgespielt ?
Proxmox nutzt den Begriff 802.3ad wie du hier sehen kannst: https://pve.proxmox.com/wiki/Network_Configuration#sysadmin_network_bond
Und hier kotzt Netgear sich aus. Die benutzen auch da auch die Bezeichnung: 802.3ad
1
Moin!
ich tingel hier durch diverse Themen und bin gerade hier hängengeblieben.
Wir haben hier momentan zwei Proxmox-Cluster zu laufen.
Alle Verbindungen sind redundant aufgebaut und verwendet habe ich dafür Balance ALB auf Proxmox.
Dann braucht man sich um die Switchports nicht mehr zu kümmern. (abgesehen von den VLANs)
Es ist keine Konfiguration alá LACP etc. notwendig.
Alles läuft hier seit Jahren fehlerfrei und performant.
Schönen Tag noch.
Hucklebuck
ich tingel hier durch diverse Themen und bin gerade hier hängengeblieben.
Wir haben hier momentan zwei Proxmox-Cluster zu laufen.
Alle Verbindungen sind redundant aufgebaut und verwendet habe ich dafür Balance ALB auf Proxmox.
Dann braucht man sich um die Switchports nicht mehr zu kümmern. (abgesehen von den VLANs)
Es ist keine Konfiguration alá LACP etc. notwendig.
Alles läuft hier seit Jahren fehlerfrei und performant.
Schönen Tag noch.
Hucklebuck
Hallo Hucklebuck,
naja - dabei dürfte doch aber die maximale Bandbreite nie über die eines einzelnen Ports gehen.
Adaptive Load Balancing verteilt die Pakete lediglich auf Sende- und Empfangsrichtung.
Bei LACP sollte die beste Kombination aus Leistung und Zuverlässigkeit gegeben sein.
Grüße
naja - dabei dürfte doch aber die maximale Bandbreite nie über die eines einzelnen Ports gehen.
Adaptive Load Balancing verteilt die Pakete lediglich auf Sende- und Empfangsrichtung.
Bei LACP sollte die beste Kombination aus Leistung und Zuverlässigkeit gegeben sein.
Grüße
Das ist korrekt.
Aber wir haben noch nie am Limit gekratzt.
Hier sind alle Netze dediziert mit 2x 10Gbit/s
Ceph-Netz, Migrationsnetz, jeweilige SRV-Anbindung und Backup-Netz
Läuft!
Aber wir haben noch nie am Limit gekratzt.
Hier sind alle Netze dediziert mit 2x 10Gbit/s
Ceph-Netz, Migrationsnetz, jeweilige SRV-Anbindung und Backup-Netz
Läuft!
dürfte doch aber die maximale Bandbreite nie über die eines einzelnen Ports gehen.
Ist bei einem LACP LAG aber auch nicht der Fall!!Über das Hashing Verfahren wir je nach Mac oder IP Adresse dann immer fest einer der Memberports für die Verbindung zugewiesen. Auch hier ist die max. Bandbreite also niemals mehr als ein einzelner Memberport. Es findet lediglich eine Verteilung statt so das die Last auf alle Memberports verteilt und damit insgesamt reduziert wird. Mehr oder minder beim Balance ALB auch nur das dort vermutlich Round Robin verwendet wird statt Adress Hashing und das das Verfahren nicht dynamisch und beidseitig ist sondern vom Hypervirsor gesteuert wird was es dann Switch unabhängig macht. (Siehe Tutorial oben)
Hmm, ich habe das irgendwie so verstanden, dass wenn verschiedene Verbindungen, also MAC1<->MAC4 und MAC2<->MAC3 hergestellt sind, die maximale Portbandbreite pro Verbindung gilt. Also max in der Summe trotzdem über die maximale Bandbreite eines einzelnen LAG-Memberports kommt. Ist das nicht so ? Weil, dann frage ich mich schon, wieso man nicht grundsätzlich ein einfaches Load-Balancing benutzt, ohne aufwändig die Switche zu konfigurieren.
Nein, zu mindestens bei einem LACP LAG (802.3ad Standard) ist das nicht so! Ein Kommunikationspärchen (Mac o. IP Adresspaar) landet immer auf einem vom Hashing bestimmten Memberport.
https://de.wikipedia.org/wiki/Link_Aggregation
https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlage ...
https://de.wikipedia.org/wiki/Link_Aggregation
https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlage ...
Naja, "ein Kommunikationspäärchen" - darunter verstehe ich MAC1 und MAC2 und weitere Paarungen.
Anders ausgedrückt, Kommunikation zwischen Server1 und Server2 = Paar1, zwischen Server3 und ClientA = Paar2, zwischen Server2 und NAS1 = Paar3 usw.
Dann hatte ich die Logik so verstanden, dass die Switche "merken", wer mit wem kommuniziert und dann jeweils über einen Weg die Verbindung herstellen. Intelligenterweise hätte ich vermutet, dass "freie" Member-Links erstmal gefüllt werden, um mehr Durchsatz zu kriegen.
Wenn das nicht so ist, erschließt sich mir der Sinn eines LAG nicht - außer Fehlertoleranz.
Anders ausgedrückt, Kommunikation zwischen Server1 und Server2 = Paar1, zwischen Server3 und ClientA = Paar2, zwischen Server2 und NAS1 = Paar3 usw.
Dann hatte ich die Logik so verstanden, dass die Switche "merken", wer mit wem kommuniziert und dann jeweils über einen Weg die Verbindung herstellen. Intelligenterweise hätte ich vermutet, dass "freie" Member-Links erstmal gefüllt werden, um mehr Durchsatz zu kriegen.
Wenn das nicht so ist, erschließt sich mir der Sinn eines LAG nicht - außer Fehlertoleranz.
Das hast du dann genau richtig verstanden. 👍
Freie Links füllen geht aber nicht, da der errechnete Hash Wert aus den Adressen (und ggf. anderen Parametern) immer der gleiche ist pro Paarung und damit auch auf einen festen physischen Memberlink weist.
Bei LACP LAGs kann es also prinzipbedingt niemals zu einer vollständig homogenen Verteilung kommen weil es dafür niemals genug Entropie bei den Hashing Parametern gibt!
Der tiefere Sinn ist also nur die Verteilung und die damit einhergehende Reduzierung der Last auf den Memberlinks (Performance) und natürlich die Redundanz.
Klar, bei einem LAG mit sehr geringer Entropie kann es sein das einige Memberlinks wenig oder gar nicht belegt sind mit Traffic. Auf die Dauer hilft also nur eine "Fat Pipe".
Freie Links füllen geht aber nicht, da der errechnete Hash Wert aus den Adressen (und ggf. anderen Parametern) immer der gleiche ist pro Paarung und damit auch auf einen festen physischen Memberlink weist.
Bei LACP LAGs kann es also prinzipbedingt niemals zu einer vollständig homogenen Verteilung kommen weil es dafür niemals genug Entropie bei den Hashing Parametern gibt!
Der tiefere Sinn ist also nur die Verteilung und die damit einhergehende Reduzierung der Last auf den Memberlinks (Performance) und natürlich die Redundanz.
Klar, bei einem LAG mit sehr geringer Entropie kann es sein das einige Memberlinks wenig oder gar nicht belegt sind mit Traffic. Auf die Dauer hilft also nur eine "Fat Pipe".
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!
How can I mark a post as solved?
How can I mark a post as solved?
So, die Lösung war recht banal. Wenngleich ich es auch übersehen habe, da ich mir nicht vorstellen konnte/wollte, dass so etwas möglich ist.
Auf einem der beiden Hosts haben sich nach dem Einspielen der neuesten Produktivupdates die Bezeichnungen der Netzkarten geändert (Bsp. eno3 auf eno3fh3 oder so) und das bei einer kompletten 4Port Karte.
Damit waren die konfigurierten Bonds quasi ohne physische Bindung. Das ist mir zuerst garnicht aufgefallen, da es keine Fehlermeldung o.ä. gab.
Nun erstellte ich die Bonds neu mit den neuen Netzwerkkartennamen (LACP L3+4) und siehe da, es funktioniert wieder.
Ich frage mich, wie das geht - normalerweise sollten doch die Bezeichnungen der Netzwerkkarten, wenn einmal erkannt fix sein ?
Auf einem der beiden Hosts haben sich nach dem Einspielen der neuesten Produktivupdates die Bezeichnungen der Netzkarten geändert (Bsp. eno3 auf eno3fh3 oder so) und das bei einer kompletten 4Port Karte.
Damit waren die konfigurierten Bonds quasi ohne physische Bindung. Das ist mir zuerst garnicht aufgefallen, da es keine Fehlermeldung o.ä. gab.
Nun erstellte ich die Bonds neu mit den neuen Netzwerkkartennamen (LACP L3+4) und siehe da, es funktioniert wieder.
Ich frage mich, wie das geht - normalerweise sollten doch die Bezeichnungen der Netzwerkkarten, wenn einmal erkannt fix sein ?
1
Ja, damit gab es auch viel Spaß bei unseren Proxmox-Servern.
Hintergrund ist/war die Umsetzung der neuen Benamung von Netzwerkkarten im Kernel.
Glaube (nicht wissen), dass es hauptsächlich um Intelkarten ging.
https://www.freedesktop.org/software/systemd/man/latest/systemd.net-nami ...
Gruß Hucklebuck
Nachtrag: So sah es bei uns aus:
Hintergrund ist/war die Umsetzung der neuen Benamung von Netzwerkkarten im Kernel.
Glaube (nicht wissen), dass es hauptsächlich um Intelkarten ging.
https://www.freedesktop.org/software/systemd/man/latest/systemd.net-nami ...
Gruß Hucklebuck
Nachtrag: So sah es bei uns aus:
aus:
lshw -c network -businfo
Bus info Device Class Description
============================================================
pci@0000:3d:00.0 eno1 network Ethernet Connection X722 for 10GBASE-T
pci@0000:3d:00.1 eno2 network Ethernet Connection X722 for 10GBASE-T
pci@0000:3d:00.2 eno3 network Ethernet Connection X722 for 10GBASE-T
pci@0000:3d:00.3 eno4 network Ethernet Connection X722 for 10GBASE-T
pci@0000:af:00.0 ens801f0 network Ethernet Controller X710 for 10GBASE-T
pci@0000:af:00.1 ens801f1 network Ethernet Controller X710 for 10GBASE-T
pci@0000:af:00.2 ens801f2 network Ethernet Controller X710 for 10GBASE-T
pci@0000:af:00.3 ens801f3 network Ethernet Controller X710 for 10GBASE-T
wurde:
lshw -c network -businfo
Bus info Device Class Description
============================================================
pci@0000:3d:00.0 eno1np0 network Ethernet Connection X722 for 10GBASE-T
pci@0000:3d:00.1 eno2np1 network Ethernet Connection X722 for 10GBASE-T
pci@0000:3d:00.2 eno3np2 network Ethernet Connection X722 for 10GBASE-T
pci@0000:3d:00.3 eno4np3 network Ethernet Connection X722 for 10GBASE-T
pci@0000:af:00.0 ens801f0np0 network Ethernet Controller X710 for 10GBASE-T
pci@0000:af:00.1 ens801f1np1 network Ethernet Controller X710 for 10GBASE-T
pci@0000:af:00.2 ens801f2np2 network Ethernet Controller X710 for 10GBASE-T
pci@0000:af:00.3 ens801f3np3 network Ethernet Controller X710 for 10GBASE-T
Ja genau, die ganzen Intelkarten.
Das kannste Dir nicht ausdenken - mann mann mann
Das kannste Dir nicht ausdenken - mann mann mann