Legen Sie Ihren Cluster auf Eis: Der eine Schritt, den Sie bei Proxmox HA nicht vergessen dürfen

Es gibt eine ganz besondere Art von Panik, die nur entsteht, wenn Ihr Proxmox-Cluster mitten in einem eigentlich routinemäßigen Hardware-Upgrade spontan neu startet. Eben lief noch alles rund. Im nächsten Moment herrscht Chaos – und Sie versuchen zusammenzupuzzeln, was passiert ist, während Ihr Stolz sich leise in eine Ecke verkriecht.

Genau das ist einem Proxmox-Nutzer passiert, als er die Stromversorgung in seinem Server-Rack überholen wollte. Er hatte einen soliden Plan. Das Ziel? Ein paar Geräte tauschen, einen 48-Port-Dell-Switch durchstarten und weitermachen. Aber er vergaß einen entscheidenden Schritt: High Availability (HA) in den Wartungsmodus zu versetzen.

Die Kettenreaktion, die niemand will

Schauen wir uns an, was schiefgelaufen ist. In diesem Setup lief die gesamte Corosync-Cluster-Kommunikation über diesen einen 1G-Dell-Switch. Als er neu startete, brach die Corosync-Kommunikation abrupt weg, und Proxmox tat genau das, wofür es gebaut ist – es löste HA aus, ging davon aus, dass Nodes ausgefallen waren, und begann in einem hektischen Versuch, die Dienste am Leben zu halten, VMs zu migrieren oder neu zu starten.

Das Ergebnis? Ein vollständiges, clusterweites Reboot-Ereignis, das niemand kommen sah.

Zu seinen Gunsten muss man sagen: Der OP gab nicht dem System die Schuld. Er kannte den HA-Wartungsmodus. Er hatte ihn nur … vergessen. Eine winzige Auslassung in einem ansonsten gut durchdachten Plan wurde zu einer nicht ganz so lustigen Lektion darüber, wie brüchig ein falsch konfiguriertes oder unvollständiges Setup sein kann.

Also, was ist der HA-Wartungsmodus, und warum ist er wichtig?

Wenn Sie einen Proxmox-Cluster verwalten und HA nutzen, dürfen Sie diesen Teil nicht überspringen. Wartungsmodus bedeutet in diesem Zusammenhang, dem Cluster zu sagen, er solle sich chillen – nicht zu reagieren, wenn er glaubt, ein Node sei ausgefallen. Sie legen den Watchdog absichtlich still, damit er nicht versucht, Sie vor sich selbst zu retten, während Sie geplante Arbeiten durchführen.

Ohne das zu aktivieren, hält der HA-Manager von Proxmox den Node für ausgefallen, sobald er den Netzwerkkontakt verliert, und versucht dann zu „helfen", indem er kritische VMs auf anderen Nodes neu startet – manchmal mit unbeabsichtigten und katastrophalen Folgen.

Der richtige Schritt ist hier einfach: Vor jeder Operation, die die Cluster-Kommunikation stören könnte, besonders bei allem, was Switches oder die Stromversorgung von Netzwerkgeräten betrifft, sollten Sie diese HA-Ressourcen in den Modus „ignored" versetzen.

Praxiswissen aus den Schützengräben

Das war kein Einzelfall. Tatsächlich entfachte es eine lebhafte Diskussion unter anderen Proxmox-Admins, von denen viele genau dieselbe Geschichte hatten. Einige teilten ihre eigenen Erfahrungen mit unerwartetem Cluster-Verhalten, als sie HA nicht richtig deaktiviert hatten, besonders bei Upgrades, Stromwechseln oder Netzwerkänderungen.

Und es wird noch frustrierender: Es gibt keine GUI-Option, um HA in den Wartungsmodus zu versetzen. Wie ein Nutzer es formulierte: „Seit 2023 – wie kann das immer noch kein Feature sein?" Fairer Punkt. Proxmox hat Fortschritte dabei gemacht, mehr Features in die UI zu bringen, aber HA-Management ist weiterhin nur über die CLI möglich – zumindest vorerst.

Der Befehl, der den Tag gerettet hätte?

sudo ha-manager crm-command set vm:<VMID> state=ignored

Sie können das auch für mehrere VMs nutzen, um zu verhindern, dass Proxmox versucht, sie zu migrieren oder neu zu starten.

Im Thread kam auch etwas Verwirrung auf. Ein Nutzer versuchte, den Node selbst in den Wartungsmodus zu versetzen, in der Annahme, das reiche aus. Tut es nicht. Sie müssen HA auf Ressourcenebene deaktivieren, nicht nur auf Node-Ebene. Einen Node in den Wartungsmodus zu versetzen, drained zwar VMs, hindert HA aber nicht daran, zu versuchen, sie herumzuschieben. Was der OP brauchte, war, HA komplett zu stoppen.

Resilienz einplanen (auch bekannt als „Seien Sie nicht ich")

Es steckt eine größere Lektion darin, als nur HA-Einstellungen umzulegen. Mehrere Nutzer steuerten Infrastruktur-Tipps bei, die Ihnen helfen können, diese Art von Cluster-Ausraster von vornherein zu verhindern:

Nutzen Sie mehrere Corosync-Interfaces. Proxmox unterstützt das, und redundante Pfade (z. B. gebondete Interfaces über verschiedene Switches hinweg) können den Unterschied zwischen nahtloser Uptime und totalem Cluster-Ausfall ausmachen.

Vermeiden Sie Single Points of Failure. Ein einzelner Switch, über den Ihr gesamter Corosync-Traffic läuft, ist eine Einladung für Ärger. Dual-Fabric-Setups werden empfohlen, mit VLAN-Trennung für Corosync-Ring-0- und Ring-1-Traffic.

Active-Backup-Bonding ist für viele eine beliebte Wahl, weil es die Komplexität von LACP vermeidet und weder Stacking noch fortgeschrittene Switch-Features erfordert.

Vermeiden Sie es, Corosync durch Firewalls zu routen. Wenn diese Firewall neu startet oder stockt, könnte Ihr Cluster das Quorum verlieren oder Schlimmeres. Halten Sie Corosync-Traffic auf isolierten, nicht gerouteten VLANs.

Ein Nutzer legte ein bombenfestes Beispiel dar: zwei 10G-Switches, zwei Interfaces pro Node im Active/Backup-Bonding und dedizierte, isolierte VLANs für jeden Ring. Als bei einer USV-Migration versehentlich beide Switches ausfielen, hielt der Cluster stand – kein Split-Brain, keine Reboot-Stürme, nur eine einzelne VM, die manuell neu gestartet werden musste.

Also, was sollten Sie vor der Wartung tun?

Hier die mentale Checkliste:

1. Versetzen Sie HA-verwaltete VMs in den Modus „ignored". Das sagt dem Cluster, sie in Ruhe zu lassen, egal was passiert.

2. Wenn Sie Switches oder irgendetwas, das Corosync betrifft, neu starten müssen, verteilen Sie diesen Traffic zuerst auf mehrere Interfaces/Switches.

3. Gehen Sie nicht davon aus, dass „Wartungsmodus" überall dasselbe bedeutet. Node-Wartung ≠ HA-Wartung.

4. Dokumentieren Sie Ihren Plan. Im Ernst. Vertrauen Sie nicht Ihrem Gedächtnis. Es geht nicht ums Alter – es geht um Fehlermarge.

Die Quintessenz

Der Wartungsmodus ist nicht nur ein Button (auch wenn er einer in der GUI sein sollte). Er ist ein Sicherheitsnetz, eine Erinnerung daran, dass Ihr Cluster nur so zuverlässig ist wie die Annahmen, die Sie hineinbauen.

Prüfen Sie also vor Ihrem nächsten Wartungsfenster noch einmal Ihre Checkliste. Legen Sie HA auf Eis, wenn es sein muss. Denn egal, wie solide Ihr Plan ist: Wenn Sie diesen einen Schalter vergessen, zieht Ihnen Ihr Proxmox-Cluster vielleicht einfach den Boden unter den Füßen weg – und nimmt Ihren Stolz gleich mit.