Cluster-Lebenszyklus und Hoständerungen

Ein beigetretener Host ist noch keine nutzbare Clusterkapazität

Ein Host kann technisch Mitglied eines Clusters sein und trotzdem keine produktive VM sicher übernehmen. CPU-Modell, Firmware, Hypervisorversion, virtuelle Geräte, Storagepfade, Portgruppen, Managementidentität und lokale Spezialhardware bestimmen, welche Workloads tatsächlich migrieren oder nach einem Ausfall starten können. Der Join ändert zunächst Mitgliedschaft und Konfiguration; erst Prüfungen machen daraus belastbare Kapazität. Das Gegenstück gilt beim Entfernen. Ein leerer Host ist nicht automatisch entbehrlich. Er kann Recoveryreserve, Quorumstimme, Storage- oder Replikationsrolle, Netzwerkpfad oder einzige Zielkompatibilität für eine VM bereitstellen. Retirement verändert deshalb Fehlerdomäne und Menge zulässiger Zielhosts, selbst wenn im Moment keine VM auf dem Knoten läuft. Behandle Clusterwachstum und -abbau als Expand → Validate → Migrate → Contract. Zuerst kommt der neue Host ohne breite produktive Platzierung hinzu. Dann werden Konfiguration, Kompatibilität und Canary-Migrationen geprüft. Erst danach wird Last stufenweise aufgenommen. Beim Entfernen läuft die Reihenfolge rückwärts: neue Platzierung stoppen, Abhängigkeiten lösen, Workloads evakuieren, verbleibende Zusagen messen und erst dann Mitgliedschaft abbauen. Dieses Modul trennt den Lebenszyklus von der HA-Entscheidungslogik des nächsten Moduls. Hier geht es darum, eine Mitgliedschaftsänderung so klein, überprüfbar und rückrollbar zu halten, dass Quorum, Fencing und Recoverypolicy auf einem bekannten Bestand arbeiten.

Mitgliedschaft, Schedulability und Dienstfreigabe sind drei Zustände

Cluster-Mitglied

Der Knoten nimmt am Management- und Mitgliedschaftsprotokoll teil; Identität, Zertifikate und gemeinsame Konfiguration sind integriert.

Platzierbarer Host

Validatoren, CPU- und Gerätekompatibilität, Storage, Netz und Kapazität erlauben definierte Workloadklassen.

Produktiv freigegeben

Canary-Migration, Neustartpfad und repräsentative Dienstprüfung erfüllen vorher festgelegte Grenzwerte.

Ein einziger Boolescher Hoststatus vermischt diese Zustände. Führe stattdessen explizite Labels oder Admission-Gates: joined, quarantined, canary, production und gegebenenfalls Workloadklassen wie general, legacy-cpu oder passthrough. Die konkrete Plattform kann andere Begriffe verwenden; entscheidend ist, dass der Join keine automatische Breitenplatzierung auslöst. Vor dem Join wird die Ausgangslage gesichert: Clusterzustand, Mitglieder, Versionen, Quorum, laufende Alarme, Storage- und Netzpfade, aktuelle Reserve und geplante Hostidentität. Der Zielzustand nennt nicht nur „ein Host mehr“, sondern welche Workloads nach welcher Evidenz dort laufen dürfen und wie der Host bei einem fehlgeschlagenen Gate wieder entfernt oder isoliert wird. Nach dem Join werden zunächst nur hostbezogene Prüfungen ausgeführt. Danach folgt eine nichtkritische, repräsentative Canary-VM. Sie testet nicht jede Workloadklasse, sondern genau ihren Vertrag: Migration hin und zurück, Netzwerk, Storage, Guest Tools, Zeit, Monitoring und Dienstprobe. Passthrough-, lokale Disk- oder spezielle CPU-Workloads brauchen getrennte Gates oder bleiben bewusst ausgeschlossen. Erst eine erfolgreiche Canary-Welle erweitert den Platzierungsscope. Diese Trennung macht Rollback billig: Solange der Host keine produktiven VMs und keine exklusiven Rollen trägt, kann die Mitgliedschaft meist mit deutlich kleinerem Blast Radius zurückgenommen werden.

Preflight schützt den Bestand vor Join-Nebenwirkungen

Ein Clusterjoin ist keine neutrale Registrierung. Plattformen verteilen gemeinsame Konfiguration, Zertifikate und Mitgliedschaftsdaten. Die Proxmox-Dokumentation nennt einen besonders scharfen Vertrag: Beim Join wird bestehende Konfiguration unter /etc/pve überschrieben; ein beitretender Knoten darf deshalb keine Gäste tragen, unter anderem weil VM-IDs im Cluster kollidieren könnten. Das ist produktspezifisch, zeigt aber das allgemeine Prinzip: Erst die dokumentierte Join-Semantik lesen, dann den Host vorbereiten. Der Preflight prüft eindeutigen Hostnamen und Managementadresse, Zeit- und Namensauflösung, unterstützte Version, Cluster- und Managementzertifikate, Netzwerkpfade, MTU, Storageinitiator, Multipath, virtuelle Switches und Hostvalidatoren. virt-host-validate qemu kann lokale KVM-/QEMU-Voraussetzungen prüfen. Ein grüner Validator ersetzt weder Supportmatrix noch Clusterpfade; er ist ein Gate unter mehreren. ``bash virt-host-validate qemu pvecm status pvecm nodes `` Erfasse außerdem, ob der neue Host lokale VMs, replizierte Daten, Backupjobs, Storage-Daemons oder andere Rollen besitzt. Ein Join kann deren Konfiguration überschreiben oder einen Namens- und ID-Konflikt in den Cluster tragen. „Der Host ist frisch installiert“ ist kein Nachweis; sichere die relevante Inventar- und Datenträgeransicht. Der Rückfall wird vor dem Join festgelegt. Welche Konfiguration wird gesichert, welcher Knoten führt den Join aus, wie wird ein teilintegrierter Host isoliert, und welche gemeinsamen Artefakte bleiben nach einer Entfernung bestehen? Ein Join ohne dokumentierten Rückweg darf nicht durch spätere Produktionsplatzierung irreversibler gemacht werden.

CPU-Kompatibilität ist eine Gast-ABI-Entscheidung

Eine laufende VM nimmt den ihr präsentierten CPU-Zustand mit zur Zielmaschine. Der Zielhost muss diese Features bereitstellen können. QEMU beschreibt host-passthrough als nahezu direkte Weitergabe des Hostmodells und empfiehlt sie, wenn Live Migration nicht erforderlich ist; Migration zwischen abweichenden Hosts ist damit im Allgemeinen nicht sicher. Benannte CPU-Modelle oder Libvirts host-model können eine migrationsfähige Gast-ABI über heterogene Hosts bilden. Das bedeutet nicht, dass immer das älteste denkbare Modell gewählt werden muss. Eine zu niedrige Baseline verschenkt Features und kann Sicherheits- oder Leistungsanforderungen beeinträchtigen. Eine zu hohe Baseline schließt Zielhosts aus. Die Clusterentscheidung lautet: Welche Gast-CPU-Zusage sollen alle zulässigen Ziele der jeweiligen Workloadklasse erfüllen? Inventarisiere zuerst die produktiven Domaindefinitionen und Hostfähigkeiten. virsh domcapabilities beschreibt Domainfähigkeiten für Emulator, Architektur, Maschine und Virtualisierungstyp. Libvirt bietet CPU-Vergleichs- und Baselinefunktionen, doch das Ergebnis muss zur tatsächlich verwendeten VM-Konfiguration und QEMU-Version passen. Ein theoretischer gemeinsamer Feature-Satz beweist noch keine erfolgreiche Migration. ``bash virsh domcapabilities --virttype kvm virsh dumpxml app-01 ` Teste mindestens eine laufende und eine ausgeschaltete Migration pro relevanter CPU- beziehungsweise Geräteklasse. Sichere Guest- und Anwendungssignal nach dem Wechsel. Eine erfolgreiche Canary-VM mit generischem CPU-Modell sagt nichts über eine Datenbank mit host-passthrough` oder eine VM mit durchgereichtem Gerät aus. Markiere Ausnahmen maschinenlesbar in der Platzierung.

Kompatibilität umfasst mehr als CPU und Version

• Virtuelle Maschine: CPU-Modell, Machine Type, Firmware, Secure Boot, virtuelle Geräte, Balloon- und Guest-Agent-Fähigkeiten.
• Host: Hypervisor- und QEMU-Version, Kernel, Firmware, Microcode, Treiber, lokale Geräte und unterstützte Upgradefolge.
• Storage: dieselbe aktive Diskquelle oder ein freigegebener Kopierpfad, identische LUN-/Export-Sicht und ausreichende Multipathzustände.
• Netz: Portgruppen oder Bridges, VLANs, MTU, Sicherheitsrichtlinien, Migrationstransport und Managementroute.
• Betrieb: Monitoring, Backup, Logging, Zeit, Namensauflösung, Identität, Automation und Lizenz- beziehungsweise Supportgrenzen.

Libvirt unterscheidet bei Migration Quellverbindung, Zielverbindung und je nach Modus eine hypervisorspezifische Daten-URI. Bei Peer-to-Peer-Migration verbindet sich der Quelldaemon mit dem Ziel unter seiner eigenen Identität; dass ein Administrator beide Hosts einzeln erreicht, beweist daher nicht, dass der echte Migrationspfad funktioniert. Nicht geteilte Diskdaten benötigen einen expliziten Kopierpfad. Libvirt nennt dafür beispielsweise --copy-storage-all; weitere lokale Zustände wie UEFI-Variablenspeicher können eigene Grenzen besitzen. Eine Canary-Migration mit Shared Storage prüft diesen Fall nicht. Klassifiziere Workloads nach Storage- und Gerätemodell, bevor du aus einem Erfolg eine Clusterfreigabe ableitest. Gemischte Versionen sind oft nur in einer dokumentierten Upgradephase unterstützt. „Beide Hosts starten dieselbe VM“ reicht nicht. Prüfe Migrationsrichtung hin und zurück, virtuelle Hardware, Managementkompatibilität und den Punkt, ab dem Konfiguration oder Gastzustand von der älteren Version nicht mehr verstanden wird. Dieser Punkt ist die Rollbackgrenze des Rollouts. Eine Supportmatrix ist Eingabe, nicht Beweis. Erst der lokale Preflight und kontrollierte Workloadtest zeigen, ob Firmwarestand, Netz- und Storagepfad sowie konkrete VM-Eigenschaften in dieser Umgebung zusammenpassen.

Canary-Platzierung prüft eine Workloadklasse in beide Richtungen

Die Canary muss den riskanten Vertrag repräsentieren. Für allgemeine VMs kann das CPU-Modell, Shared Storage und Standardnetz sein. Für lokale Storagekopie, große Speichermenge, spezielle virtuelle Geräte oder enge Latenzziele brauchst du eigene Proben. Ein synthetischer Kleinstgast beweist lediglich, dass der Grundpfad existiert. Lege Grenzwerte vorher fest: maximale Downtime, Migrationsdauer, Dienstlatenz, Storage- und Netzlast, Fehlerzähler und verbleibende Clusterreserve. Ohne Schwelle wird jede abgeschlossene Migration als Erfolg gewertet, auch wenn sie das SLO verletzt oder den Migrationspfad sättigt. Die Rückmigration ist besonders wertvoll. Sie prüft, dass der alte Host die vom neuen Host präsentierte VM weiterhin übernehmen kann und dass kein einseitiger Versions- oder Gerätewechsel eingetreten ist. Scheitert sie, bleibt die Canary auf einem bereits isolierten Scope; breite Platzierung wird nicht gestartet. Nach einer grünen Probe folgt nicht automatisch die ganze Flotte. Verteile Workloads in kleinen Wellen, beobachte gemeinsame Pfade und halte den neuen Host als eigene Kohorte sichtbar. Fehler, die erst mit Lastdichte auftreten, erscheinen nicht bei einer einzelnen Canary. Ein erfolgreiches Join-Protokoll ist daher der Beginn der Freigabe, nicht ihr Ende.

Rolling Changes brauchen eine explizite Mischphase

Firmware-, Kernel- und Hypervisorupdates werden häufig hostweise ausgerollt. Währenddessen existiert ein gemischter Cluster. Dieser Zwischenzustand braucht einen eigenen Vertrag: unterstützte Versionskombination, erlaubte Migrationsrichtungen, Cluster- und Storageformat, Managementkompatibilität und maximale Dauer der Mischphase. Vor dem ersten Host wird ein repräsentativer Zielstand außerhalb oder in einem isolierten Cluster geprüft. Im Produktivcluster folgen Health- und Kapazitätsgate, Drain, Update, Hostvalidierung, Canary-Rückkehr und Beobachtungszeit. Erst danach beginnt der nächste Host. Mehrere gleichzeitig geleerte Hosts sparen Kalenderzeit, verbrauchen aber Recoveryreserve und erschweren die Ursachenabgrenzung. Ein Rollback kann verschiedene Dinge bedeuten. Vor dem Update lässt sich der Drain abbrechen. Nach dem Update kann ein Host möglicherweise auf das alte Paket- oder Firmwarelevel zurück. Nach einem Clusterformat-, Management- oder VM-Hardwareupgrade kann dieser Weg geschlossen sein. Benenne für jeden Schritt den letzten wirklich getesteten Rückfall und vermeide irreversible Upgrades bis die Hostkohorte stabil ist. Halte Upgrade und Kapazitätsänderung getrennt. Neue CPU-Generation, mehr RAM, neue NICs und neuer Hypervisorstand gleichzeitig machen einen Canaryfehler mehrdeutig. Wenn neue Hardware zwingend mit neuer Software kommt, behandle die Kombination als neue Hostklasse und teste ihre Verträge einzeln statt sie als bloßen Ersatz zu etikettieren.

Drain ist eine Inventur der tatsächlichen Bindungen

Ein Maintenance Mode oder Drain fordert die Plattform auf, neue Platzierung zu stoppen und Workloads zu bewegen. Er kann keine fehlende Zielkompatibilität erzeugen. Vorher werden VMs nach Migrationsklasse sortiert: live migrierbar, nur ausgeschaltet bewegbar, lokal gebunden, gerätegebunden, lizenz- oder netzgebunden und ohne zulässiges Ziel. Lokale Disks, Passthrough-Geräte, Host-USB, SR-IOV-VFs, spezielle CPU-Features und lokale Netz- oder Secretabhängigkeiten können eine Migration verhindern. Manche Bindungen sind beabsichtigt. Dann braucht Wartung ein freigegebenes Dienstfenster, einen alternativen Host mit gleicher Fähigkeit oder eine vorherige Architekturänderung. HA erzwungen abzuschalten, um den Host trotzdem leer zu bekommen, verschiebt das Risiko nur. Führe Drain in Wellen aus. Starte mit einer unkritischen VM und beobachte Quell- und Zielhost, Migrationsnetz, Storage, Dienst und verbleibende Reserve. Stoppe, wenn ein Grenzwert überschritten wird. Der Quellhost wird erst neu gestartet oder entfernt, wenn sein Inventar leer beziehungsweise jede verbleibende Ausnahme ausdrücklich freigegeben ist. Nach der Evakuierung prüfst du den Cluster im Zielzustand, nicht nur den leeren Host. Haben Anti-Affinity-Regeln gehalten? Bleibt Kapazität für den vereinbarten zusätzlichen Ausfall? Sind Backup, Monitoring und Netzpfade der verschobenen Dienste gesund? Ein leerer Knoten kann durch seinen Drain bereits den Restcluster überlastet haben.

Der beste Rückfallpunkt liegt vor der ersten produktiven Platzierung

Nach einem Join können mehrere Dinge schiefgehen: Zertifikats- oder Namenskonflikte, instabile Mitgliedschaft, fehlende Storagepfade, asymmetrische Migration oder fehlerhafte Automation. Begrenze deshalb automatische Scheduler- und HA-Platzierung, bis Preflight und Canary bestanden sind. Wenn ein Gate scheitert, stoppe neue Wirkung. Sichere Befund und gemeinsamen Clusterzustand. Entscheide dann zwischen Korrektur im isolierten Hostscope und kontrollierter Entfernung. „Noch eine produktive VM testen“ ist keine Eingrenzung, wenn der grundlegende Vertrag ungeklärt ist. Der Rückfall selbst folgt der Plattformdokumentation. Gemeinsame Konfigurationsobjekte, Zertifikate, SSH-Fingerprints, Node-Verzeichnisse oder Storageeinträge können nach dem Entfernen fortbestehen. Proxmox nennt beispielsweise verbleibende Node-Konfiguration und SSH-Fingerprints als nachgelagerte Bereinigung. Entferne solche Artefakte erst, wenn der Host sicher aus Mitgliedschaft und Workloadpfaden heraus ist. Ein erfolgreich zurückgenommener Join stellt auch die Ausgangszusage wieder her: ursprüngliche Mitglieder, Quorum, Platzierungsregeln, Kapazität, Alarme und keine verwaiste Zielreferenz. Nur „Host nicht mehr in der Liste“ ist zu wenig. Dokumentiere, welches Gate scheiterte und welche Voraussetzung ein neuer Versuch erfüllen muss.

Arbeitsbeispiel: Neue CPU-Generation scheitert erst bei der Rückmigration

Retirement entfernt erst Abhängigkeiten, dann Mitgliedschaft

Vor Retirement wird neue Platzierung auf dem Host gestoppt. Inventarisiere VMs, lokale Disks, Replikationsjobs, Storage- oder Netzwerkrollen, Backups, HA-Regeln, Affinity, Monitoring, Managementzertifikate und Quorum- beziehungsweise Witnessbezug. Produktdokumentation kann eine eigene Reihenfolge für Ceph-, Replikations- und Clustermitgliedschaft verlangen; diese Reihenfolge ist Teil des Datenvertrags. Evakuiere Workloads kontrolliert und prüfe sie am Ziel. Danach wird die verbleibende Clusterzusage neu gerechnet: Kapazität und zulässige Zielhosts nach dem definierten Ausfall, Anti-Affinity, Wartungsreserve und Migrationspfad. Ein leerer Host bleibt Mitglied, bis diese Rechnung grün oder eine geänderte Zusage ausdrücklich freigegeben ist. Entferne anschließend hostbezogene Rollen nach der dokumentierten Abhängigkeitsreihenfolge und sichere den Clusterzustand nach jedem Schritt. Erst dann folgt die Mitgliedschaft. Der ausgeschaltete ehemalige Knoten darf nicht mit alter Clusterkonfiguration wieder im selben Netz starten; Quarantäne oder Neuinstallation schützt vor einer unbeabsichtigten Parallelidentität. Nachgelagerte Bereinigung umfasst DNS, Zertifikate, SSH-Fingerprints, Monitoring, Backup, CMDB, Port- und Storagefreigaben sowie Platzierungsregeln. Entferne nichts allein aufgrund eines Namens. Belege, dass der Cluster und alle Verbraucher den Host nicht mehr referenzieren. Der Abschlussnachweis verbindet vier Aussagen: kein Workload oder exklusiver Zustand verbleibt, die Restkapazität erfüllt den Vertrag, die Mitgliedschaft ist konsistent und alte Zugriffswege sind kontrolliert zurückgenommen. Erst dann ist der Host nicht nur leer, sondern außer Betrieb.