Warum Ihr Proxmox-Cluster nachts Knoten neu startet — und wie Sie es abstellen

/01Was Corosync ist — und was Hochverfügbarkeit nicht bedeutet

Ein Proxmox-Cluster fällt selten am helllichten Tag aus. Er fällt nachts aus, wenn niemand hinschaut, ein Knoten sich kurz nicht mehr meldet, und der Watchdog die Konsequenz zieht: Neustart. Am nächsten Morgen sind die VMs wieder da, das Ticket ist geschlossen, und niemand hat verstanden, was passiert ist. Die Ursache sitzt fast immer an derselben Stelle — nicht im vermeintlich ausgefallenen Knoten, sondern im Netz, über das sich die Knoten gegenseitig versichern, dass sie noch da sind.

Dieses Netz trägt Proxmox nicht selbst, sondern Corosync, ein eigenständiges Cluster-Kommunikationssystem, das PVE unter der Haube einsetzt. Corosync hat eine einzige Aufgabe: Es stellt fest, welche Knoten gerade Mitglied des Clusters sind, und verteilt dieses Wissen an alle. Aus dieser Mitgliedschaft leitet sich das Quorum ab — die Mehrheit, die ein Cluster braucht, um sich selbst als handlungsfähig zu betrachten. Was Corosync nicht tut: VM-Verkehr transportieren, Storage replizieren oder irgendetwas, das mit der eigentlichen Arbeitslast zu tun hat. Es ist reine Verwaltungskommunikation — wenige, aber sehr zeitkritische Pakete.

Genau diese Verwechslung ist der Ausgangspunkt der meisten nächtlichen Neustarts: Wer Corosync für ein gewöhnliches Netzwerkprotokoll hält, das sich ein Kabel mit allem anderen teilen kann, baut einen Cluster, der bei jeder Lastspitze auf Storage- oder Backup-Netz kurzzeitig taub wird — und ein tauber Knoten ist für die anderen ein toter Knoten. Was dann folgt, ist Fencing: das erzwungene Abschalten oder Neustarten eines Knotens, der aus Sicht des Clusters nicht mehr sicher mitspielt. Fencing ist kein Fehler im Cluster — es ist eine Schutzfunktion, die verhindert, dass eine VM auf zwei Knoten gleichzeitig läuft und ihre Festplatte sich selbst zerstört. Das Problem ist nicht, dass Fencing existiert. Das Problem ist, wenn es ausgelöst wird, obwohl kein Knoten wirklich ausgefallen ist.

Für Hochverfügbarkeit im engeren Sinn ist ha-manager zuständig, ein weiterer Dienst auf Basis dieser Mitgliedschaft. Er überwacht Dienste und startet sie auf einem anderen Knoten neu, wenn ihr bisheriger Knoten aus dem Cluster fällt — und er schaltet am Ende den Watchdog scharf. Wer HA nicht aktiviert hat, bekommt trotzdem Fencing, nur ohne den Nutzen: Der Knoten fährt trotzdem herunter, sobald ihm das Quorum fehlt und Dienste mit Watchdog-Bindung darauf liegen.

/02Das Quorum-Modell: Mehrheit oder Stillstand

Quorum ist, vereinfacht, Mehrheitsentscheidung durch Abwesenheit. Jeder Knoten bekommt standardmäßig eine Stimme. Damit sich der Cluster für handlungsfähig hält, braucht er mehr als die Hälfte aller konfigurierten Stimmen — nicht mehr als die Hälfte der gerade erreichbaren Knoten, sondern der insgesamt eingetragenen. Ein Cluster mit fünf Knoten bleibt handlungsfähig, solange drei erreichbar sind. Fallen drei gleichzeitig aus, stehen die verbleibenden zwei still, obwohl sie technisch einwandfrei laufen — sie wissen nur nicht mehr sicher, ob nicht irgendwo im Netz noch eine dritte Fraktion mit eigener Mehrheit unterwegs ist.

Das ist eine bewusste Entscheidung gegen Split-Brain, kein Konstruktionsfehler. Zwei Netzhälften, die beide glauben, den Cluster allein zu vertreten, und dieselbe VM parallel beschreiben — genau das verhindert Quorum um jeden Preis, notfalls indem beide Hälften anhalten. Cluster-Design ist deshalb zuerst eine Entscheidung über die Anzahl der Stimmen, dann erst über Hardware. Laut Proxmox-Dokumentation braucht, wer verlässlich mit Quorum arbeiten will, mindestens drei Knoten — bei zwei Knoten kann rechnerisch keine Seite je eine echte Mehrheit erreichen, was Abschnitt /06 gesondert behandelt.

Verloren geht das Quorum in der Praxis selten, weil ein Knoten wirklich abstürzt. Es geht verloren, weil Corosync-Pakete auf dem Weg zwischen den Knoten zu spät ankommen. Und dafür hat Corosync eine sehr enge Toleranz: Laut Proxmox-Dokumentation braucht der Cluster-Stack eine verlässliche Latenz von unter 5 Millisekunden zwischen allen Knoten, um stabil zu laufen. Bei kleineren Clustern mag es auch mit höheren Latenzen funktionieren — garantiert ist das nicht, und oberhalb von etwa 10 Millisekunden gilt das bei mehr als drei Knoten laut Hersteller als eher unwahrscheinlich. Das ist kein Bandbreitenproblem. Ein Cluster-Netz mit 100 Mbit/s reicht für Corosync bei Weitem; ein Cluster-Netz, das durch Storage-Spitzen zwei Millisekunden Jitter bekommt, reicht nicht.

/03Der Grundfehler: ein Netz für Corosync, Storage und VMs

Die meisten selbst gebauten Cluster haben zwei, drei Netzwerkkarten je Knoten und eine gewachsene Zuordnung: eine Karte fürs Management, eine für VM-Verkehr, vielleicht eine dritte für iSCSI oder Ceph. Corosync bekommt dabei oft keine eigene Karte, sondern läuft über dasselbe Interface wie das Management — und Management-Interfaces sind genau die Interfaces, über die auch Backup-Jobs, ZFS-Replikation und gelegentlich sogar Storage-Traffic laufen. Das funktioniert wochenlang, bis eine nächtliche Replikation, ein größerer Restore oder ein Backup-Fenster genug Bandbreite zieht, dass Corosync-Pakete Warteschlangen durchlaufen statt sofort verschickt zu werden.

Proxmox benennt das in der eigenen Dokumentation ausdrücklich: Corosync soll sich kein Netz mit Storage teilen, außer als niedrig priorisiertem Fallback in einer redundanten Konfiguration. Für den Regelfall wird eine dedizierte physische Netzwerkkarte empfohlen — eine einzelne 1-Gbit-Karte genügt in den meisten Fällen, weil Corosync selbst kaum Bandbreite braucht. Der Grund für die eigene Karte ist nicht Durchsatz, sondern Isolation: Sobald ein anderer Dienst dieselbe Karte sättigen kann, sättigt er sie irgendwann, und Corosync hat keine Möglichkeit, sich vorzudrängen. Am Protokoll liegt es nicht — Corosync läuft wahlweise über IPv6 oder IPv4, die Isolation vom übrigen Verkehr ist die eigentliche Stellschraube.

Wer Redundanz will, muss sie nicht auf einer Karte bauen — dazu mehr im nächsten Abschnitt. Ein zweites virtuelles Interface auf derselben physischen Karte ist dabei keine Redundanz, sondern Selbstbetrug: Fällt die Karte aus, fallen beide Links gleichzeitig.

/04Redundanz richtig gebaut: zwei Links auf getrennter Hardware

Eine dedizierte Karte für Corosync löst das Netz-Problem — sie schafft aber selbst einen neuen Einzelpunkt: Fällt genau diese Karte, dieser Switch-Port oder dieses Kabel aus, verliert der Knoten sein einziges Cluster-Netz, obwohl er sonst fehlerfrei arbeitet. Corosync ist für genau diesen Fall gebaut: Es unterstützt laut Hersteller bis zu acht parallele Links und wechselt automatisch, wenn einer ausfällt.

Entscheidend ist dabei nicht die Anzahl der Links, sondern ihre Unabhängigkeit. Zwei VLANs auf demselben physischen Uplink sind zwei Links im Sinne der Konfiguration, aber ein einziger Fehlerpunkt im Sinne der Physik — fällt der Switch, fallen beide gleichzeitig. Ein zweiter Link lohnt sich nur, wenn er über eine andere Karte, ein anderes Kabel und im Idealfall einen anderen Switch läuft. Für die meisten Mittelstandscluster reicht dafür eine zweite, einfache 1-Gbit-Karte je Knoten, verkabelt auf einen zweiten, unabhängigen Switch — kein Stacking, kein gemeinsames Netzteil, keine gemeinsame Uplink-Leitung zum Kern.

In der Praxis wird dieser zweite Link am häufigsten aus Kostengründen weggelassen — „die eine Karte reicht doch, wir haben ja noch nie einen Switch verloren". Das stimmt, bis es nicht mehr stimmt, und dann trifft es den gesamten Cluster gleichzeitig, nicht nur einen Knoten. Der Mehrpreis für eine zweite einfache Karte und einen zweiten kleinen Switch liegt im Bereich eines Bruchteils dessen, was eine einzige nächtliche Downtime an Ticketaufwand kostet.

/05Die Diagnosekette: welche Protokolle in welcher Reihenfolge

Nach einem nächtlichen Neustart ist die erste Frage immer dieselbe: War es wirklich Fencing, oder ist der Knoten aus einem anderen Grund neu gestartet? Eine feste Reihenfolge spart hier Zeit — im Kern ist das nichts anderes als Incident Response in Kurzform: Befund sammeln, eingrenzen, Ursache bestätigen, erst danach handeln. Jeder Schritt grenzt die Fragestellung des nächsten ein — von der Cluster-Sicht zur Netz-Sicht zum Watchdog selbst.

hostspezial@pve01:~$ journalctl -u corosync -p warning --since "02:00" --until "05:00"
# Warnungen und Fehler von Corosync im fraglichen Zeitfenster — TOTEM-Meldungen,
# Retransmit-Listen, Token-Verluste

hostspezial@pve01:~$ corosync-cfgtool -s
# Ring-Status je konfiguriertem Link: welcher Link zu welchem Zeitpunkt down war

hostspezial@pve01:~$ corosync-quorumtool -s
# Quorum-Status: wie viele Stimmen aktuell da sind, wie viele gebraucht werden

hostspezial@pve01:~$ pvecm status
# Cluster-Gesamtsicht: Mitgliederliste, Quorum, aktueller Knoten

hostspezial@pve01:~$ journalctl -u pve-ha-crm -u pve-ha-lrm --since "02:00"
# HA-Manager-Sicht: wann wurde der Knoten als verloren erklaert, welche
# Dienste wurden verschoben

hostspezial@pve01:~$ dmesg -T | grep -i watchdog
# Bestaetigung: hat der Watchdog tatsaechlich ausgeloest, oder war es ein
# anderer Reboot-Grund (Kernel-Panic, OOM, manueller Reboot)

Die Reihenfolge ist bewusst so gewählt: zuerst Corosync selbst, weil ein Fencing-Vorfall dort fast immer seine erste Spur hinterlässt — meist eine Reihe von Retransmit-Meldungen, bevor ein Link komplett als down markiert wird. Erst danach lohnt der Blick auf den HA-Manager, weil der nur reagiert, nicht verursacht. Und erst zum Schluss der Watchdog-Beweis über dmesg, weil er die Konsequenz bestätigt, nicht die Ursache erklärt. Wer diese Reihenfolge umdreht und gleich im Kernel-Log nach dem Watchdog sucht, findet die Bestätigung, aber nicht den Auslöser — und verliert genau die Zeit, die eine feste Kette an der MTTR spart.

Wer die Meldungen dauerhaft sammeln will, statt sie nach jedem Vorfall aus dem Journal zu fischen, bringt Prometheus mit einem Corosync-Exporter in ein Grafana-Dashboard ein. Der Wert liegt weniger im Diagramm als in der Alarmierung über Alertmanager, bevor ein Ring komplett ausfällt — ein Link, der zeitweise Pakete verliert, kündigt sich fast immer Tage vorher an.

/06Zwei-Knoten-Cluster: QDevice als dritte Stimme

Zwei Knoten sind der häufigste Einstieg in einen Proxmox-Cluster — und die häufigste Quelle nächtlicher Überraschungen. Das Quorum-Modell aus Abschnitt /02 braucht eine echte Mehrheit, und bei genau zwei Stimmen gibt es keine: Fällt einer der beiden Knoten aus, hat der verbleibende genau eine von zwei Stimmen — keine Mehrheit, kein Quorum, kein automatischer Weiterbetrieb der HA-Dienste. Ein Zwei-Knoten-Cluster ohne weitere Maßnahme ist damit für Hochverfügbarkeit ungeeignet, auch wenn beide Knoten technisch tadellos laufen.

Für genau diesen Fall bietet Proxmox das QDevice an, gestützt auf den externen Dienst QNetd: eine dritte Stimme, die nicht auf einem dritten vollwertigen Cluster-Knoten liegt, sondern auf einer beliebigen erreichbaren Linux-Maschine — eine kleine VM an einem dritten Standort, ein separater Server, in der Praxis nicht selten sogar ein Einplatinenrechner, sofern das die Verfügbarkeitsanforderung mitträgt. QNetd verbindet sich über TCP/IP und stellt keine Anforderungen an die Corosync-typische Latenz, weil es am Cluster-Verkehr gar nicht teilnimmt — es beantwortet nur eine Frage: „Ich sehe Knoten A noch, siehst du ihn auch?"

Damit hat der Zwei-Knoten-Cluster wieder eine ungerade Stimmenzahl: Beide Knoten plus QDevice ergibt drei, und zwei von drei sind eine Mehrheit. Fällt das QDevice selbst aus, bleibt der Cluster mit zwei Stimmen weiter handlungsfähig — es ist Schiedsrichter, nicht dritter Spieler. Fällt dagegen ein Knoten und das QDevice gemeinsam, bleibt dem letzten Knoten nur eine Stimme, und der Cluster hält an, wie es das Modell verlangt.

Ein Fallstrick, der in der Praxis regelmäßig übersehen wird: Wächst der Cluster später auf drei oder mehr echte Knoten, muss das QDevice wieder entfernt werden. Eine ungerade Zahl echter Knoten braucht keinen Schiedsrichter mehr, und ein stehen gelassenes QDevice kann die Quorum-Rechnung dann verzerren, statt sie zu stützen. Wer Zwei-Knoten-Cluster als Zwischenschritt plant, sollte das QDevice deshalb von Anfang an als vorübergehende Maßnahme behandeln, nicht als Dauerlösung.

/07Wiederkehrende Fencing-Ursachen aus der Praxis

Die Proxmox-Dokumentation beschreibt, wie Corosync und Quorum funktionieren sollen. Was tatsächlich zu unerwartetem Fencing führt, zeigt sich eher in den Supportforen als im Handbuch. Die folgenden Muster sind Praxisbeobachtungen aus Forenberichten, keine Herstellerangaben — aber sie wiederholen sich auffällig oft.

MTU-Fehlkonfiguration

Ein wiederkehrendes Muster in Forenberichten: Jumbo-Frames sind auf einem Teil der Strecke aktiviert — etwa auf den Servern und einem Switch —, auf einem anderen Segment aber nicht. Corosync-Pakete, die dann größer sind, als das schwächste Glied der Strecke verträgt, werden fragmentiert oder verworfen, was sich zunächst als steigende Retransmit-Zahl zeigt und bei anhaltender Störung in Fencing endet. In einem dokumentierten Forenfall half am Ende weder die durchgängige Aktivierung von Jumbo-Frames noch die Rückkehr zur Standard-MTU — die Lösung war ein bewusst kleinerer Wert für die Corosync-eigene MTU-Einstellung.

Geteiltes Netz unter wachsender Last

Der in Abschnitt /03 beschriebene Fall taucht in Forenberichten in einer bestimmten Variante besonders oft: ein Cluster, der monatelang unauffällig lief, bis eine Erweiterung — ein weiterer Knoten, mehr VMs, mehr Backup-Volumen — die Grundlast auf dem geteilten Netz über die Schwelle hob, an der Corosync noch pünktlich bedient wurde. Der Fehler zeigte sich nicht bei der Erweiterung selbst, sondern zeitversetzt, sobald die Zusatzlast erstmals mit einem vollen Backup-Fenster zusammenfiel.

Bonding-Modus

Mehrfach in Forenberichten genannt: Der Wechsel von einem lastverteilenden Bonding-Modus auf einen aktiv-passiven Modus für die Cluster-Karte hat wiederkehrende Retransmit-Probleme beseitigt. Lastverteilende Modi verteilen Pakete nach eigener Logik auf mehrere physische Wege — für normalen Datenverkehr ein Vorteil, für ein latenzkritisches Protokoll wie Corosync, das auf gleichmäßig eintreffende Pakete angewiesen ist, eher ein Risiko.

QDevice-Fallen

Aus Forenberichten zu Zwei-Knoten-Clustern: Wird das QDevice auf einer Maschine betrieben, die selbst regelmäßig ausfällt oder unsauber angebunden ist — etwa ein Einplatinenrechner an einem privaten Anschluss ohne eigene Absicherung —, verschiebt sich das Problem nur. Der Cluster hält dann still, obwohl alle produktiven Knoten laufen, nur weil der Schiedsrichter selbst nicht erreichbar ist.

/08Wann Hochverfügbarkeit die falsche Antwort ist

Hochverfügbarkeit klingt fast immer nach der besseren Wahl. In der Praxis ist sie das nur, wenn jemand sie pflegt — Redundanz baut, das Cluster-Netz überwacht, Test-Failover fährt und die Diagnosekette aus Abschnitt /05 tatsächlich beherrscht. Ein HA-Cluster, den niemand pflegt, ist nicht neutral. Er ist schlechter als gar keine Automatik, weil er im Ernstfall genau die Neustarts auslöst, die dieser Artikel beschreibt — ohne dass jemand da ist, der versteht, warum.

Der ehrliche Vergleichsmaßstab ist nicht „HA oder nichts", sondern die beiden Kennzahlen, die jedes Wiederanlaufkonzept ohnehin beziffern muss: RPO und RTO — wie viel Datenverlust ist im Ernstfall hinnehmbar, und wie lange darf der Wiederanlauf dauern. Für viele Mittelständler mit überschaubarer Knotenzahl und einer IT-Mannschaft, die den Cluster nebenbei betreut, liefert ein sauberes Disaster-Recovery-Konzept mit getesteten Proxmox-Backup-Server-Wiederherstellungen einen belastbareren Wert als ein HA-Cluster, dessen Watchdog-Verhalten niemand im Haus wirklich versteht. Ein Restore, den jemand tatsächlich schon einmal geübt hat, schlägt eine automatische Übernahme, die im Ernstfall zum ersten Mal ausprobiert wird.

Die Herstellerangabe zur ha-manager-Leistung stützt diese Rechnung: Typische Fehlererkennungs- und Übernahmezeiten liegen laut Proxmox bei rund zwei Minuten, was rechnerisch nicht mehr als etwa 99,999 Prozent Uptime erlaubt — selbst im Idealfall, mit sauber getrenntem Netz und funktionierendem Fencing. Wer diese zwei Minuten Ausfall pro Ereignis ohnehin verkraften kann, steckt Zeit und Budget oft besser in ein getestetes Wiederanlaufkonzept als in eine HA-Automatik, die im Ernstfall selten beherrscht wird.

In der Praxis lohnt sich HA vor allem dort, wo mindestens drei Knoten stehen, das Cluster-Netz dediziert und redundant aufgebaut ist, und ein Team existiert, das Testausfälle regelmäßig fährt statt nur zu hoffen, dass der Ernstfall nicht eintritt. Fehlt eine dieser drei Voraussetzungen, ist ein dokumentiertes, geübtes Wiederanlaufverfahren die robustere Investition — nicht, weil HA technisch schlecht wäre, sondern weil ungepflegte Automatik im Zweifel gegen einen arbeitet statt für einen.

/09Der Wartungsablauf, der kein Fencing auslöst

Der einfachste Weg, sich selbst ein nächtliches Fencing zu bescheren, ist ein ganz gewöhnliches Reboot für ein Kernel-Update — ohne Vorbereitung. Verlässt ein Knoten mit laufenden HA-Diensten den Cluster durch einen simplen Neustart, wertet der Rest des Clusters das exakt so, wie er einen echten Ausfall werten würde: Dienste werden verschoben, und der kurz als fehlend geltende Knoten kann je nach Konfiguration weitere Reaktionen auslösen, die mit dem eigentlichen Wartungsvorhaben nichts zu tun haben.

Proxmox löst das seit einigen Versionen mit einem eigenen Wartungsmodus. Der Ablauf hat drei Schritte, und die Reihenfolge ist verbindlich:

hostspezial@pve01:~$ ha-manager crm-command node-maintenance enable pve01
# Alle HA-verwalteten Dienste auf pve01 werden zu anderen Knoten verschoben --
# per Live-Migration, sofern die Ressource das unterstuetzt

hostspezial@pve01:~$ pvecm status
# Pruefen: pve01 traegt keine HA-Dienste mehr, Quorum bleibt unveraendert

# jetzt Wartung fahren: Patchen, Reboot, Hardware-Wechsel

hostspezial@pve01:~$ ha-manager crm-command node-maintenance disable pve01
# Dienste, die beim Aktivieren auf pve01 liefen, wandern zurueck

Wichtig: Der Wartungsmodus wird bei einem Reboot des Knotens laut Proxmox-Dokumentation nicht automatisch beendet, sondern bleibt aktiv, bis er manuell deaktiviert wird. Wer das vergisst, hat einen Knoten, der zwar wieder online ist, aber dauerhaft keine HA-Dienste mehr übernimmt, weil der Cluster ihn weiterhin als „in Wartung" führt — kein Fencing-Problem mehr, aber ein Betriebsproblem, das sich still einschleicht.

Der eigentliche Gewinn dieses Ablaufs ist die Live-Migration im ersten Schritt: Dienste wechseln den Knoten, während sie laufen, ohne dass der Cluster den alten Knoten je als ausgefallen betrachtet. Es findet kein Fencing statt, weil aus Cluster-Sicht nichts Unerwartetes passiert — der Knoten hat sich ordentlich abgemeldet, nicht kommentarlos aufgehört zu antworten. Der Unterschied zwischen Wartung und Ausfall liegt für Corosync exakt an dieser Stelle: Hat sich der Knoten angekündigt, oder ist er einfach verschwunden.

Wer das öfter macht als einmal im Quartal, sollte diesen Ablauf als Runbook dokumentieren — mit den genauen Befehlen, der erwarteten Ausgabe je Schritt und der Erinnerung an den letzten, oft vergessenen Befehl. Ein Runbook, das ein zweiter Mitarbeiter ohne Rückfrage abarbeiten kann, ist am Ende der eigentliche Unterschied zwischen einem Cluster, der Wartungsfenster übersteht, und einem, der bei jedem Patchday ein kleines Risiko trägt.

/10Häufige Fragen