Cluster crash nach durch hinzufügen eines 15. Nodes

[aPollO]

Hallo,

ich habe ein Cluster aufgebaut mit insgesamt deutlich über 15 Nodes. Hat auch zu Beginn alles super funktioniert, wir hatten 12 Nodes und alles lief. Haben dann Hardware nachbestellt und nachgeschoben, das heißt es liefen da auf den vorhandenen Nodes auch schon VMs ohne Ende.
Das Cluster besteht eigentlich primär zur einfachen Verwaltung, es gibt kein Ceph und es werden auch seltens irgendwelche VMs irgendwohin migriert.

Ich hatte jedoch HA regeln eingerichtet, sodass VMs auf jeden Fall laufen und auch wieder gestartet werden wenn sie gestoppt werden.

Nun war es soweit und ich habe den 15. Server versucht ins Cluster zu joinen....in dem Moment flog alles auseinander. Mehrere Nodes starteten neu, alle mit HA Regeln. VMs sind gecrasht. Je nachdem welchen Node ich im Browser aufrief sah ich unterschiedliche Status Zustände des Clusters, mal wurden mir die einen Nodes als Offline angezeigt, mal die anderen. Manche Nodes haben auch nur noch sich selbst "gesehen" und alle anderen als Offline.

Ein Blick ins Corosync-Log zeigte dann folgendes eine Menge verlorene Links und ein KNET/pmtud der MTU's ändert.

Ein entfernen des Nodes (runterfahren) brachte keine Besserung mehr. Ich musste dann auf allen Nodes den ARP Cache leeren und plötzlich ging es wieder. Dachte ich mir....OK das war wohl nix. Als ich dann das ganze Chaos beseitigt hatte und alles wieder lief, lies ist den 15. Node aus und installierte den 16. Node ohne eine Ahnung was genau passiert ist. Und das war wieder genau das selbe Spiel. In dem Moment in dem ich ins Cluster joinen wollte crashten zig VMs, die Cluster-Kommunikation ging verloren und so weiter.

Also wieder alles zum Laufen gebracht und recherchiert. Ich fand dann diesen Thread: https://forum.proxmox.com/threads/c...-reboots-as-soon-as-i-join-a-new-node.116804/

Bei mir handelt es sich auch wie bei dem Nutzer im Thread um HPE DL360/380 Gen10 Server. Es gibt zwei (physische) Netzwerke, die jeweils aus einem bond aus zwei Ports bestehen. Das erste Netzwerk ist für die Kommunikation nach außen, das zweite war ein 1Gbit Netzwerk nur für Corosync und die Cluster-Kommunikation.

Hier mal ein Beispiel, wie mein Corosync-Netzwerk konfiguriert war:

auto bond1
iface bond1 inet manual
        ovs_bonds eno1 eno2
        ovs_type OVSBond
        ovs_bridge vmbr1
        ovs_options bond_mode=active-backup

auto vmbr1
iface vmbr1 inet static
        address 172.16.0.1/24
        ovs_type OVSBridge
        ovs_ports bond1

Nachdem ich den Thread gefunden habe, hab ich dann das Bonding aufgelöst, hab die Interfaces ohne bond und bridge Konfiguriert und hab jedem Interface eine eigene IP verpasst und sie als link0 und link1 konfiguriert. Ausserdem die MTU auf 9000 gesetzt. Sieht jetzt so aus:

auto eno1
iface eno1 inet static
        address 172.16.0.1/24
        mtu 9000
#Nur Interne Clusterkommunikation

auto eno2
iface eno2 inet static
        address 172.16.1.1/24
        mtu 9000
#Nur Interne Clusterkommunikation

Das ganze Cluster ist jetzt so konfiguriert und installiert und jetzt funktioniert auch alles problemlos mit mehr als 15 Nodes.

So im dem verlinkten Thread wird jetzt spekuliert, dass es dort dadurch verursacht wird, dass durch die zusätzlichen Nodes das Netzwerk überlastet wird, da dort Storage und Corosync auch das selbe Netzwerk teilen. Das ist bei mir nicht der Fall. Aber das mit den springenden MTUs ist sehr wohl der Fall. Als Workaround empfiehlt @fabian den Parameter netmtu zu verwenden. Wenn ich das richtig lese ist das aber in der aktuellen Version von corosync absolet, denn das ganze KNET Zeug kam dazu und es gibt diesen Parameter so nicht mehr.
Ich versteh auch nicht so ganz wie ein 1 Gbit Netzwerk nur mit 15 Nodes die im Cluster miteinander sprechen, überlastet sein soll.

Ich schätze es hat irgendwas mit dem OVS bond zu tun gehabt, denn seitdem ich das raus genommen habe, kam auch keinerlei Meldung mehr von KNET/pmtud das irgendwelche MTUs geändert werden. Solche Meldungen gab es allerdings davor schon zu Hauf, auch ohne das irgendwas kaputt ging.

Versteht Jemand was hier passiert ist und wie sich das verhindern lässt? Ist Bonding auf dem Corosync Interface einfach eine dumme Idee?

 

[mr44er]

Ist Bonding auf dem Corosync Interface einfach eine dumme Idee?

Ob das technisch wirklich dumm ist, weiß ich nicht (ich hätte dann 2 getrennte vlans für corosync gemacht und die dann in/auf den bond), ich hab mir corosync-traffic selbst nie angeschaut. Es machts aber unnötig kompliziert, weil du es nicht brauchst, da corosync von sich aus bis 8 Leitungen selbst verwalten kann und den failover damit macht. 0-7 und die "nullte" hat die höchste Prio. Hast du ja jetzt auch so, wie das verstehe.

Ich versteh auch nicht so ganz wie ein 1 Gbit Netzwerk nur mit 15 Nodes die im Cluster miteinander sprechen, überlastet sein soll.

Nicht mit der Bandbreite überlastet, eher schaukelt sich die Latenz zu hoch. Aber zugegeben, mit sovielen Nodes hatte ich noch nicht zu tun...maximal die Hälfte. Vielleicht kannst du da über den Switch mehr sehen, was auf den Ports passiert.
Btw. Switch. Kann es sein, dass du da in ein Limit rennst und der Switch das als Angriff siehst und vorsichtshalber die Ports dichtmacht? Sowas wie...maximal 15 IPs/gleichzeitige Verbindungen?

Ein Klassiker wäre auch irgendeine abweichende Firmware der NICs, die was anderes als zu erwarten treibt, wenn sie neuer sind. ISCSI oder LLDP ins Netz brüllen z.b.

 

[aPollO]

Ob das technisch wirklich dumm ist, weiß ich nicht (ich hätte dann 2 getrennte vlans für corosync gemacht und die dann in/auf den bond), ich hab mir corosync-traffic selbst nie angeschaut. Es machts aber unnötig kompliziert, weil du es nicht brauchst, da corosync von sich aus bis 8 Leitungen selbst verwalten kann und den failover damit macht. 0-7 und die "nullte" hat die höchste Prio. Hast du ja jetzt auch so, wie das verstehe.

Ja genau das war auch mein Gedanke, corosync kann sich ja selbst um die Redundanz kümmern. Darum hab ich diese aus der Netzwerk-Konfiguration komplett rausgenommen.

Nicht mit der Bandbreite überlastet, eher schaukelt sich die Latenz zu hoch. Aber zugegeben, mit sovielen Nodes hatte ich noch nicht zu tun...maximal die Hälfte. Vielleicht kannst du da über den Switch mehr sehen, was auf den Ports passiert.
Btw. Switch. Kann es sein, dass du da in ein Limit rennst und der Switch das als Angriff siehst und vorsichtshalber die Ports dichtmacht? Sowas wie...maximal 15 IPs/gleichzeitige Verbindungen?

Ich kenne mich da nicht wirklich mit aus was irgendwelche Port-Modi angeht. Leider sind die Switche nicht von mit administriert und ich kann da nicht drauf schauen.

Was mir direkt ins Auge gesprungen ist, dass die Konfiguration bei dem Kollegen aus dem verlinkten Thread halt auffällig ähnlich ist mit dem bonding auf dem Netzwerk und auch noch der gleiche/sehr ähnliche Server-Typ zum Einsatz kam.

 

[mr44er]

Leider sind die Switche nicht von mit administriert und ich kann da nicht drauf schauen.

Dann frage mal den Admin der sie administriert, ob da etwas reingrätschen könnte. Weil...wenn du ein 15tes irgendwie hinzufügst und die Hölle bricht los...dann stimmt was nicht und wenn dem so ist, wäre das Umstellen der Switche das kleinere Übel bzw. gar keines.

Ich tendiere eher dazu, als dass du latenzmäßig in ein Limit rennst. Auch mit 14 nodes hättest du das irgendwann mal erleben sollen/müssen/können.

Aber alles nur so als Ideengebung, IT ist blöd.

 

[Falk R.]

Hi @aPollO,
Für Corosync ist Bondig nicht empfohlen. Funktionieren tut es in der Regel trotzdem relativ gut.
Corosync ist sehr Latenzempfindlich und da macht die OVS Bridge das ganze nicht besser. Am besten nutzt man mindestens 2 Links für Corosync, und wenn möglich dann direkt mit einer IP auf dem Interface. Kein Bonding oder Bridges.
Oft wird ein Link dediziert für Corosync genutzt und das Management (oft vmbr) dann als zweiter Link und wenn du Ceph oder anderen IP Speicher nutzt diese Links dann als weitere Corosync Links.

Bei Clustern ab ca. 20 Nodes empfehle ich auch eine dedizierte 10G verbindung und bei 50+ Nodes mindestesn eine 25G Verbindung für Corosync.
Da sind die Frequenzen höher und somit die Latenzen niedriger.

 

[tscret]

Hmm ich als Netzwerker frage mich was da auf dem Switch konfiguriert ist, wenn du mit Active/Standby Bonds arbeitest... könnte dann mit der MAC-Table und Spanningtree lustiges Portflapping geben was zu "komischen" Netzwerkverhalten führt. Ist die MTU des Switches auch auf 9000?

Wenn ich Bonds mache probiere ich immer mit LACP (802.3 oder so) zu arbeiten weil das so ne saubere Sache ist.

Noch n dummer Gedanke... war auf den neuen Büchsen noch irgend n iLO oder so auf Shared auf einem der Bond-NIC drauf?

 

[aPollO]

@Falk R. da stimme ich dir schon zu, ich hab es jetzt auch so konfiguriert das es zwei links für corosync gibt und beide sind plain Interface mit IP. Das Management geht über eine andere Bridge mit 10Gbit Interfaces über die dann auch der VM Traffic läuft.

@tscret Active-Standby deshalb, weil die ganze Hardware nur gemietet ist und ich keinerlei Zugriff auf die Switches habe und das der Hoster auch nicht so einfach her gibt dort solche Dinge wie LACP zu konfigurieren. Ich hab schon angefragt ob dort irgendwas zu sehen ist, angeblich sieht auf den Switches alles "gut" aus. Ich hab auch die Konfiguration für die Ports erhalten. Abgesehen von einem VLAN das für unsere Systeme dort hinterlegt ist gibts da auch nichts spannendes zu sehen. Jumbo Frames mit MTU 9000 wurde mir zugesagt, dass das funktioniert. Ich habe es aber auch erstmal ausprobiert mit Pings ob das alles sauber durch geht.

Die iLOs haben eigentlich dedizierte Interfaces, aber das ist auch ein guter Gedanke. Da kann ich noch mal schauen ob die ggf. trotzdem shared da mit drauf liegen.

Es ist und bleibt mir noch ein Rätsel was hier wirklich passiert ist. Das keiner weiter Probleme hat mit plain Interfaces beruhigt mich aber defintiv schon mal, dass ich das Problem mit der MTU 9000 jetzt nicht einfach auf den 90. Node verschoben habe (nein so viele plane ich nicht )

 

[Falk R.]

Ich persönlich nutze immer Standard MTU für Corosync, da die Pakete eigentlich nicht groß werden und du mit jumbo Frames so eventuell die Latenz wieder anhebst.