Erfahrungen mit Netzwerkkonfiguration (Bonds, Bridges) gefragt

[Naumburger-Bauunion]

Guten Tag,

man sieht an meinen Posts, dass ich neu hier bin - man möge mir verzeihen.

Mein Wissensstand : Ich denke, die grundsätzlichen Dinge zu Proxmox sind mir geläufig. Ich habe einen einzelnen Host produktiv am laufen - neben ESXI-Hosts .
Ich möchte alle ESXIs entfernen und gegen ein Proxmox Cluster austauschen.
Dazu habe ich im Vorfeld aus 4 recht schwachen alten Servern ein Cluster gebaut, um das Zusammenspiel mit Cluster, HA und gemeinsamen iSCSI-Storage zu erforschen.

So - jetzt habe ich zwei neue Hosts, beide mit aktuellem Proxmox und Subscription aufgesetzt und ein Cluster erzeugt.
HA geht noch nicht, dazu braucht es ja einen dritten Host - der läuft aber grad noch mit ESXi - weshalb ich den schnell "leeren" würde.

Meine Frage bezieht sich auf die Netzwerkverbindungen.

Folgende Konfiguration habe ich mir vorgestellt (pro Host) :

LAN1, 10GBit - Managementschnittstelle für Weboberfläche, IP-Netz A
LAN2+3, 2x10GBit Bond1 - Schnittstelle zu Cluster, IP-Netz B - < Linux Bridge dafür gemacht
LAN4+5, 2x10GBit Bond2 - Schnittstelle zu iSCSI, IP-Netz C -> Linux Bridge dafür gemacht
LAN6+7, 2x10GBit Bond3 - Schnittstelle VMnet, keine IP-Adresse zugewiesen - Bridge gemacht, für die VMs ins Domänennetz

Die Bonds sind allesamt als LACP(802.3ad) Hash layer3+4 erzeugt. Der Switch (Netgear M4350xxx) spielt mit.

Nun habe ich beim testen zufällig bemerkt, dass VMs auf Host A auf einmal keine Verbindung in Domänennetz hinkriegen - auch kein DHCP o.ä., auf HOST B aber schon.
Sogar wenn ich eine VM von Host A auf Host B migriere, hat diese auf einmal eine normale Verbindung.

Den nicht funktionierenden Host habe ich neu gestartet, die Kabelverbindungen geprüft und Bond und Bridge neu erstellt - nix.

Nun die Frage, welche Erfahrungen Ihr so habt.

Macht vielleicht eine andere Bond-Art Sinn, womöglich eine, wo man den Switch nicht explizit konfigurieren muss ?
Muss ich da starke Einbußen hinnehmen bezüglich Durchsatz und Latenz ?

Ich brauche quasi sehr schnell reagierende Maschinen - da sind bis zu 20 Server drauf, teilweise auch mit Datenbanken (Exchange).

Deshalb habe ich sämtliche Verbindungen mit 2x10GBit LWL Karten (als LAG) hergestellt und mir eingebildet, damit eine hohe Geschwindigkeit zu erzielen.

So, viel Text - ich hoffe auf gute Tips.

Vielen Dank !

Der Mike

 

[mikee]

Moin,

prüfe noch mal die LACP-Konfiguration an allen teilnehmenden Ports und Devices ob identisch. Ggf. mal L2+L3 probieren. Ich erinnere mich düster, dass ich mit L3+L4 Probleme hatte.

m.

 

[Dunuin]

So - jetzt habe ich zwei neue Hosts, beide mit aktuellem Proxmox und Subscription aufgesetzt und ein Cluster erzeugt.
HA geht noch nicht, dazu braucht es ja einen dritten Host - der läuft aber grad noch mit ESXi - weshalb ich den schnell "leeren" würde.

Cluster braucht immer 3 Nodes, nicht nur bei HA. Hast du nur 2 Nodes darfst du keinen von beiden ausschalten/neustarten weil der andere dann auch nicht mehr funktioniert (PMXCFS geht read-only und lässt keine Änderungen mehr zu und Dinge wie VMs starten wird fehlschlagen), da dir dann Quorum fehlt. Und neustarten sollte man die Nodes ja regelmäßig, damit auch neue QEMU- und Kernel-Versionen benutzt werden. Sprich, 2-Node-cluster sollte man nie produktiv betrieben.

 

[Naumburger-Bauunion]

Moin,

prüfe noch mal die LACP-Konfiguration an allen teilnehmenden Ports und Devices ob identisch. Ggf. mal L2+L3 probieren. Ich erinnere mich düster, dass ich mit L3+L4 Probleme hatte.

m.

Hi, also ich habe was rausgefunden - schaue aber morgen nochmal drüber.
Ich war komplett auf dem Holzweg. Folgendes ist passiert :

Die Hosts und das Cluster waren komplett funktionstüchtig konfiguriert.
Dann habe ich die Subscription eingetragen und die ganzen anfallenden Updates incl. Reboot durchgeführt.
Zuerst ist es mir nicht aufgefallen bzw. ich kann es immer noch nicht glauben :
Es wurden die Netzwerkanschlüsse umbenannt !! Also z.B. von eno1 auf eno1fs0 usw.
Damit waren meine Bonds quasi funktionsunfähig und ich musste alle löschen und mit den neuen Bezeichnungen neu erstellen.
Auf einmal funktionierte wieder alles - incl. den LAGs mit LACP.

Allerdings habe ich ziemlich lange gebraucht, bis mir das überhaupt aufgefallen ist - es gab keine Fehleranzeigen oder so.

Also wenn das die Regel bei Kernelupdates ist, dann gute Nacht Marie !

 

[Naumburger-Bauunion]

Cluster braucht immer 3 Nodes, nicht nur bei HA. Hast du nur 2 Nodes darfst du keinen von beiden ausschalten/neustarten weil der andere dann auch nicht mehr funktioniert (PMXCFS geht read-only und lässt keine Änderungen mehr zu und Dinge wie VMs starten wird fehlschlagen), da dir dann Quorum fehlt. Und neustarten sollte man die Nodes ja regelmäßig, damit auch neue QEMU- und Kernel-Versionen benutzt werden. Sprich, 2-Node-cluster sollte man nie produktiv betrieben.

Hmm, da habe ich aber anderes gelesen - bzw. getestet. Cluster mit 2 Nodes läuft bei meinem Testnetzwerk ganz normal. Auch Migrationen (manuell) sowie Wartungsmode ON/OFF geht. Zumindest lässt es sich erstmal einrichten, was man bei HA nicht kann. Da muss zwangsläufig ein dritter Host im Cluster sein.
Aber Du hast recht - ein 2 Node Cluster soll es am Ende nicht werden. Ich habe aber momentan nur 2 zur verfügung, der dritte beherbert noch einen ESXi. Dessen VMs müssen erstmal auf einen der zwei Nodes "geparkt" werden, dann kann ich den ESXi killen und den 3. Proxmox Host draus bauen.

 

[Dunuin]

Hmm, da habe ich aber anderes gelesen - bzw. getestet. Cluster mit 2 Nodes läuft bei meinem Testnetzwerk ganz normal. Auch Migrationen (manuell) sowie Wartungsmode ON/OFF geht. Zumindest lässt es sich erstmal einrichten, was man bei HA nicht kann. Da muss zwangsläufig ein dritter Host im Cluster sein.

Ja, läuft solange beide IMMER laufen. Dann hast du ja noch 2 von 2 Votes und damit ÜBER 50% der Votes und Quorum. Ist einer von beiden warum auch immer nicht erreichbar, dann hat der verbleibende nur noch 1 von 2 Votes, damit nur 50% der Votes, Quorum fehlt und der verbleibende Node macht dicht, damit es nicht zum Split-Brain kommt. Daher will man immer mindestens 3 Nodes, dass da mit 2 von 3 Votes mit 66% weiterhin Quorum besteht, auch wenn ein Node mal nicht erreichbar ist.

 

[Falk R.]

Hi, also ich habe was rausgefunden - schaue aber morgen nochmal drüber.
Ich war komplett auf dem Holzweg. Folgendes ist passiert :

Die Hosts und das Cluster waren komplett funktionstüchtig konfiguriert.
Dann habe ich die Subscription eingetragen und die ganzen anfallenden Updates incl. Reboot durchgeführt.
Zuerst ist es mir nicht aufgefallen bzw. ich kann es immer noch nicht glauben :
Es wurden die Netzwerkanschlüsse umbenannt !! Also z.B. von eno1 auf eno1fs0 usw.
Damit waren meine Bonds quasi funktionsunfähig und ich musste alle löschen und mit den neuen Bezeichnungen neu erstellen.
Auf einmal funktionierte wieder alles - incl. den LAGs mit LACP.

Allerdings habe ich ziemlich lange gebraucht, bis mir das überhaupt aufgefallen ist - es gab keine Fehleranzeigen oder so.

Also wenn das die Regel bei Kernelupdates ist, dann gute Nacht Marie !

Das ist nicht immer so, aber im 6.6er Kernel hat Intel neue Treiber verteilt und hält sich jetzt an die Namenskonventionen der anderen Hersteller.
Das Thema ist nicht neu und betrifft alle Linux Basierenden Systeme beim Wechsel von pre 6.6 Kernel zu 6.6 oder höher. Proxmox ist von 6.5 auf 6.8 gegangen.
Das sollte jetzt also nicht so schnell wieder vorkommen.

Zu deiner Konfiguration. Bitte niemals Bonds für iSCSI benutzen. Mache NAS Hersteller machen soetwas und läuft auch einigermassen, aber wenn man ein vernünftiges iSCSI Storage hat macht man Multipathing und da sollte man kein LAG (LACP) benutzen.