Der Proxmox-Cluster verliert einzelne Knoten, diese rebooten und reißen damit die verbleibenden Knoten ebenfalls ins Jenseits. Das passiert nicht nur einmal, sondern in bunter Reihenfolge!
Symptome
Nach Isolation eines Knoten mittels pvecm expected 1 lässt sich dieser vom Dauerboot abhalten. Zu beobachten ist, dass der zerotier-Prozess mehrere CPUs voll belegt und sein Speicherbedarf stetig steigt. Bei 120GB ist dann Schluss, das OS schießt den Prozess ab.
Schleife
Da der Heartbeat des corosync über einen mittels zerotier aufgebauten Tunnel läuft, ist der Knoten jetzt isoliert und das Fencing reißt ihn nach 60 Sekunden in den Abgrund… Nach dem Reboot passiert das Gleiche wieder und wieder…
Analyse
Zerotier greift sich zum Aufbau des Tunnels alle verfügbaren physischen Interfaces.
Wenn also ein Zerotier-Interface Teil einer Bridge ist, geht der Zerotier-Traffic auch über diese Bridge und damit rekursiv wieder über das Zerotier-Interface – eine perfekte Schleife, die alles verfügbare RAM aufbraucht!
Abhilfe
Man kann zerotier das Verhalten abgewöhnen, indem man die kritischen Interfaces in eine blacklist einträgt. Das geschieht mittels der Datei /var/lib/zerotier-one/local.conf
Falls diese noch nicht existiert, muss sie angelegt werden.
{
"physical": {
"172.16.0.0/16": {
"blacklist": true
},
"10.0.0.0/8": {
"blacklist": true
}
},
"settings": {
"interfacePrefixBlacklist": [ "eth100","vmbr10","vmbr666","vmbr999" ]
}
}Es sollten alle nicht nach draußen führenden Interfaces – und alle privaten IP-Ranges ausgeschlossen werden. Danach zerotier neu starten und sich über den moderaten Ressourcenverbrauch freuen…
Fazit
Kleine Ursache, große Wirkung, lange Analyse, lange Downtime -> nicht schön!
Davon abgesehen ist es keine sehr gute Idee, den Heartbeat über zerotier laufen zu lassen, die Latenzen sind bisweilen gigantisch, was der Stabilität des Clusters nicht gut bekommt.
Mittlerweile kommt auch für den Heartbeat tinc zum Einsatz, der Cluster ist damit deutlich stabiler geworden!
