Cluster Resource Scheduler: automatische Lastverteilung im Proxmox-Cluster

/01Was der CRS im dynamischen Modus tut — und was nicht

Der Cluster Resource Scheduler ist der Teil von pve-ha-manager, der entscheidet, auf welchem Knoten ein Gast läuft. Die Auswahl trifft der Parameter ha in der datacenter.cfg mit drei möglichen Werten: basic, static und dynamic. Werkseinstellung ist basic — der Scheduler nimmt dann den ersten passenden freien Knoten, ohne Auslastung oder Kapazität gegeneinander abzuwägen. Das war über Jahre das gesamte Verhalten von Proxmox VE bei der Platzierung von Gästen: nützlich bei Wiederherstellung nach einem Ausfall, aber ohne jeden Anspruch auf Verteilung.

Der statische Modus rechnet erstmals mit Kapazität — allerdings mit den konfigurierten Maximalwerten der HA-Gäste (CPU-Kerne, Arbeitsspeicher-Limit), nicht mit dem, was tatsächlich läuft. Der dynamische Modus geht einen Schritt weiter: Er zieht die reale Auslastung heran, die der Cluster laufend misst, und kann daraus ableiten, dass ein Knoten überlastet und ein anderer frei genug ist, um einen Gast zu übernehmen — auch außerhalb einer Störung, mitten im Normalbetrieb.

Wichtig ist die Abgrenzung zu dem, was VMware mit DRS oder Microsoft mit dynamischer Optimierung unter Hyper-V anbieten: Beide Systeme sind länger im Markt und verteilen standardmäßig alle laufenden Gäste, nicht nur eine Teilmenge. Der CRS von Proxmox VE bewegt sich konzeptionell in dieselbe Richtung, ist aber ein jüngeres Feature mit einer bewusst engeren Reichweite: Nur Gäste, die unter der Hochverfügbarkeit laufen, kommen für eine automatische Verschiebung überhaupt infrage. Das ist keine Fußnote — es ist die Grenze, an der die meisten Erwartungen im ersten Gespräch scheitern.

/02Von der Vorschau zum Produktivfeature: der Weg zu PVE 9.2

Der statische Scheduler lief seit PVE 9.1 (19.11.2025) als Technology Preview mit im Paket pve-ha-manager. Wer damals genauer hinsah, fand in älteren Forendiskussionen noch die Aussage, CRS treffe seine Entscheidung ausschließlich bei Wiederherstellung, Wartungsmodus oder Neustart eines Gastes — von laufender Umverteilung war explizit nicht die Rede. Das hat sich mit PVE 9.2 geändert: Seit dem Release am 21.05.2026 gehört der dynamische Lastausgleich zum Lieferumfang, und der Technology-Preview-Status für den CRS-Lastausgleich selbst ist entfernt worden. Lediglich die Option, einen Gast schon beim Start über CRS optimal zu platzieren (ha-rebalance-on-start), gilt laut Proxmox-Personal im Support-Forum weiterhin als experimentell.

Technisch verändert das nichts an den Grundvoraussetzungen eines Proxmox-Clusters. Ein Quorum bleibt erforderlich, damit die verbleibenden Knoten überhaupt gemeinsam entscheiden dürfen, welcher von ihnen einen Gast übernimmt. Ohne Mehrheit der stimmberechtigten Knoten trifft der CRS keine Entscheidung — dynamisch oder nicht. Bei einem Knotenausfall greift zusätzlich Fencing: Der ausgefallene Knoten wird isoliert, bevor seine Gäste andernorts neu gestartet werden, damit ein und derselbe Datenträger nicht gleichzeitig auf zwei Knoten beschrieben wird.

Der eigentliche Mechanismus, mit dem CRS einen Gast verschiebt, ist Live-Migration: Der Arbeitsspeicherzustand einer laufenden VM wandert im laufenden Betrieb auf den Zielknoten, mit einer kurzen Umschaltpause im Millisekundenbereich statt eines Neustarts. Das ist keine neue Technik von PVE 9.2 — CRS nutzt sie lediglich automatisiert, wo ein Administrator sie bisher von Hand angestoßen hat.

/03Wie der dynamische Scheduler rechnet

CRS bewertet für jeden Knoten ein Ungleichgewicht aus CPU- und Arbeitsspeicherauslastung der HA-verwalteten Gäste — sowohl virtuelle Maschinen als auch Container. Zwei Verfahren stehen dafür zur Wahl, gesteuert über ha-auto-rebalance-method: bruteforce als Werkseinstellung gewichtet CPU-Last und Speichernutzung gleich stark. topsis ist die Alternative und gewichtet Speicher gegenüber CPU im Verhältnis von etwa 5 zu 1 — sinnvoll für Cluster, in denen der Arbeitsspeicher tatsächlich der knappere Engpass ist, etwa bei speicherlastigen Datenbank- oder Anwendungsservern.

Was in diese Rechnung nicht einfließt: Storage-Last. Nutzer im Proxmox-Support-Forum haben nachgefragt, ob Ceph-Auslastung oder allgemeiner Speicherdurchsatz Teil der Metrik sind — die Antwort war nein. CRS gleicht CPU und Arbeitsspeicher der HA-Gäste aus, nicht die Auslastung des zugrunde liegenden Storage-Clusters. Ein Knoten kann nach CRS-Logik perfekt ausbalanciert sein und trotzdem an einem überlasteten Ceph-Pool hängen.

Die Berechnung läuft in jeder HA-Runde neu: Der Scheduler ermittelt das aktuelle Ungleichgewicht über alle Knoten, simuliert mögliche Migrationen und prüft, ob eine davon die drei Bedingungen aus dem nächsten Abschnitt erfüllt. Erst wenn das der Fall ist, wird tatsächlich migriert — nicht bei jeder kleinen Schwankung.

/04Die drei Stellschrauben: Schwellenwert, Verbesserung, Haltezeit

Drei Parameter aus der datacenter.cfg entscheiden gemeinsam, ob und wann CRS eingreift. Alle drei sind im offiziellen Handbucheintrag zu datacenter.cfg mit Wertebereich und Werkseinstellung dokumentiert:

• ha-auto-rebalance-threshold — das Ungleichgewicht zwischen den Knoten in Prozent, ab dem CRS überhaupt reagiert. Werkseinstellung: 30.
• ha-auto-rebalance-margin — die relative Mindestverbesserung in Prozent, die eine Migration bringen muss, damit sie sich lohnt. Werkseinstellung: 10.
• ha-auto-rebalance-hold-duration — die Anzahl an HA-Runden, für die der Schwellenwert überschritten bleiben muss, bevor CRS eine Migration auslöst. Werkseinstellung: 3.

Zusammen ergibt das eine bewusst zurückhaltende Logik: Ein einzelner CPU-Ausschlag reicht nicht. Das Ungleichgewicht muss den Schwellenwert von 30 % überschreiten und über drei aufeinanderfolgende Runden bestehen bleiben und die vorgeschlagene Migration muss die Lage um mindestens 10 % verbessern. Erst dann verschiebt CRS einen Gast. Der vierte Parameter, ha-auto-rebalance, ist der Hauptschalter — Werkseinstellung 0, also aus. Ohne ihn bleibt CRS auch im dynamischen Modus bei den klassischen Auslösern: Wiederherstellung, Wartung, Start eines Gastes.

# /etc/pve/datacenter.cfg — dynamischer CRS mit Werkseinstellungen
crs: ha=dynamic,ha-auto-rebalance=1,ha-auto-rebalance-threshold=30,ha-auto-rebalance-margin=10,ha-auto-rebalance-hold-duration=3,ha-auto-rebalance-method=bruteforce

# Zustand und letzte Entscheidungen prüfen
hostspezial@pve01:~$ ha-manager status
hostspezial@pve01:~$ pvesh get /cluster/ha/status/current

In der grafischen Oberfläche liegt dieselbe Einstellung unter Rechenzentrum → Optionen → Cluster Resource Scheduling. Wer sie dort ändert, schreibt am Ende dieselbe Zeile in die datacenter.cfg — die Datei bleibt die verbindliche Quelle, auch wenn niemand sie von Hand editiert.

/05Einrichten: vom statischen zum dynamischen Modus

Der pragmatische Weg beginnt nicht bei dynamic, sondern bei static. Drei Schritte dafür:

1. HA-Ressourcen mit realistischen Limits versehen

Static-Load rechnet mit den konfigurierten Maximalwerten der Gäste. Ein Gast, dem großzügig 16 Kerne und 64 GB zugewiesen sind, obwohl er im Schnitt zwei Kerne und 8 GB nutzt, verzerrt die Rechnung von Anfang an. Vor der Umstellung lohnt sich deshalb ein Blick auf die tatsächlich konfigurierten Limits jeder HA-Ressource, nicht erst danach.

2. ha: static setzen und beobachten

Mit ha=static in der datacenter.cfg platziert CRS neue und wiederhergestellte Gäste nach Kapazität statt nach Zufallsprinzip. Migrationen im laufenden Betrieb finden noch nicht statt — das ist der Punkt, an dem sich beobachten lässt, ob die Platzierungslogik zur eigenen Umgebung passt, ohne dass gleich der ganze Cluster in Bewegung gerät.

3. Erst danach auf dynamic und ha-auto-rebalance=1 wechseln

Für Live-Migrationen im laufenden Betrieb braucht jeder betroffene Knoten Zugriff auf denselben Gast-Datenträger — geteiltes Storage über SAN oder Storage-Replikation, etwa per ZFS-Replikation zwischen den Knoten. Ohne das bricht die Migration ab oder läuft nur über einen Umweg mit Kopieren des gesamten Datenträgers. Wer Fibre-Channel-SAN im Cluster betreibt, findet die Einrichtung im Detail unter Proxmox-Cluster mit Fibre-Channel-SAN. Grundlagen zum Cluster-Aufbau selbst — Quorum, Netzwerk, Knotenzahl — stehen in der Schritt-für-Schritt-Anleitung zum Proxmox-Cluster-Setup.

/06Was der Scheduler bewegt — und was er ignoriert

Die Einschränkung aus Abschnitt /01 verdient eine genaue Lesart: CRS verschiebt ausschließlich Gäste, die explizit als HA-Ressource eingetragen sind — per ha-manager add oder über die Oberfläche unter Rechenzentrum → HA. Eine VM, die produktiv läuft, aber nie in die HA-Verwaltung aufgenommen wurde, bleibt auf ihrem Knoten stehen, selbst wenn dieser Knoten zu 90 % ausgelastet ist und der Nachbarknoten leer läuft. Für viele KMU-Cluster, in denen nur ein Teil der Gäste unter HA läuft, heißt das: CRS optimiert einen Ausschnitt der Umgebung, nicht die gesamte Auslastung.

Eine Migration verändert dabei nichts am Zustand des Gastes selbst — anders als ein Snapshot vor einem riskanten Update verschiebt CRS nur den Ausführungsort, nicht den Inhalt. Bei Containern berichten Nutzer im Support-Forum allerdings von spürbaren Unterschieden zur klassischen VM-Live-Migration: Je nach Konfiguration kommt es zu kurzen Unterbrechungen durch Neustart statt einer unterbrechungsfreien Übernahme. Bei VMs mit GPU-Passthrough (vGPU) wird laut Forenberichten eine Migrationspause von etwa 6 bis über 20 Sekunden beobachtet, abhängig vom zugewiesenen Speicher — Erfahrungswerte aus der Community, keine offizielle Herstellerangabe. Wer GPU-gebundene Gäste unter HA betreibt, sollte diesen Effekt vor dem produktiven Einsatz selbst nachmessen.

Auch das ist wichtig für die Erwartungshaltung: CRS ist kein Ersatz für ein Disaster-Recovery-Konzept. Es verbessert die Verteilung innerhalb eines funktionierenden Clusters, sagt aber nichts über Wiederherstellungsziele nach einem Totalausfall des Rechenzentrums aus. Diese Fragen beantwortet ein Backup- und Notfallkonzept, nicht der Scheduler.

/07Wo es hakt: blinde Flecken und Abstimmungsfragen

Kein automatischer Mechanismus ohne Preis. Vier Punkte, die vor der Aktivierung auf den Tisch gehören.

Aggressive Werte können unnötige Migrationen auslösen

Die Werkseinstellungen sind bewusst vorsichtig kalibriert. Wer Schwellenwert und Mindestverbesserung deutlich niedriger setzt und gleichzeitig die Haltezeit verkürzt, riskiert, dass kurzzeitige CPU-Spitzen — ein nächtlicher Batch-Job, ein Backup-Lauf — als dauerhaftes Ungleichgewicht gewertet werden und eine Live-Migration auslösen, die dem eigentlichen Betrieb nichts bringt. In der Praxis ist das der Grund, mit den Werkswerten zu starten und erst nach einer Beobachtungsphase gezielt nachzujustieren, nicht umgekehrt.

Storage-Last bleibt außen vor

Wie in Abschnitt /03 beschrieben, fließt weder Ceph- noch allgemeine Storage-Auslastung in die CRS-Rechnung ein. Ein Cluster kann nach CPU und Arbeitsspeicher ausgeglichen sein und trotzdem an einem einzelnen überlasteten Storage-Knoten hängen.

Protokollierung, wer eine Migration ausgelöst hat, fehlt noch

Im Task-Log unterscheidet sich eine CRS-Migration derzeit nicht von einer manuell angestoßenen. Ein entsprechender Wunsch nach einer eigenen Kennzeichnung „Migrated — initiated by CRS" ist im Proxmox-Bugtracker als Feature-Anfrage (Bugzilla #7567) erfasst, aber noch nicht umgesetzt. Wer nachvollziehen will, wie oft CRS tatsächlich eingreift, braucht bis dahin eigene Auswertung — etwa über einen Prometheus-Exporter für den HA-Status und ein Grafana-Dashboard, das Migrationen über die Zeit sichtbar macht.

ha-rebalance-on-start ist weiterhin experimentell

Anders als der eigentliche CRS-Lastausgleich trägt die Option, einen startenden Gast direkt optimal zu platzieren, noch den Status Technology Preview. Wer sie einschaltet, sollte das Verhalten in einer Testumgebung prüfen, bevor produktive Starts davon abhängen.

/08Basic, Static-Load, Dynamic-Load im Vergleich

Die letzte Zeile fasst den Reifegrad zusammen: Der Kernmechanismus von Dynamic-Load ist kein Experiment mehr, aber nicht jede Randfunktion drumherum trägt schon dasselbe Vertrauen. Das ist keine Warnung vor dem Feature — es ist die Grundlage für eine informierte Entscheidung, in welcher Reihenfolge man einsteigt.

/09Wann sich der Wechsel lohnt — und wann nicht

Dafür spricht

• Der Cluster wächst und schrumpft: Neue Gäste kommen regelmäßig dazu, alte werden abgebaut, die Auslastung driftet ohne manuelles Eingreifen auseinander. Dynamic-Load hält das automatisch im Gleichgewicht und stützt so die Verfügbarkeit der HA-Gäste, statt dass jemand einmal im Quartal von Hand nachsieht.
• Die HA-Ressourcen sind bereits sauber gepflegt: Wer CPU- und RAM-Limits realistisch konfiguriert hat, bekommt den Nutzen von Static- und Dynamic-Load praktisch geschenkt — die Datenbasis stimmt bereits.
• Geteiltes Storage ist vorhanden: Ohne SAN oder Storage-Replikation bleibt Live-Migration die Ausnahme statt der Regel, und damit auch der Nutzen von CRS im laufenden Betrieb.
• Mehr als drei bis vier Knoten: Je mehr Knoten im Cluster, desto schwerer lässt sich Ungleichgewicht von Hand erkennen — und desto größer der Gewinn durch automatische Erkennung.

Dagegen spricht

• Zwei oder drei Knoten mit stabiler, vorhersagbarer Last: Bei so wenigen Knoten lässt sich Ungleichgewicht meist auf einen Blick erkennen. Der Betriebsaufwand für Abstimmung und Beobachtung übersteigt dann schnell den Gewinn.
• Kein geteiltes Storage: Dynamic-Load ohne Live-Migration ist ein Widerspruch in sich — dann bleibt Static-Load die sinnvollere Obergrenze.
• GPU-Passthrough auf vielen HA-Gästen: Die berichteten Migrationspausen bei vGPU-Gästen sprechen dafür, diese Gäste bewusst aus dem automatischen Ausgleich herauszuhalten, statt sie der Werkseinstellung zu überlassen.
• Kein Monitoring der Migrationshäufigkeit: Ohne eigene Auswertung, wie oft und warum CRS eingreift, lässt sich weder tunen noch im Ernstfall erklären, was passiert ist. Das sollte vor der Aktivierung stehen, nicht danach nachgerüstet werden.

Die meisten KMU-Cluster fahren mit einer Kombination gut: Static-Load als Dauerzustand für alle HA-Gäste, Dynamic-Load gezielt für die Knoten und Gastgruppen, bei denen Auslastung tatsächlich schwankt. Ein vollständiger Umstieg auf Dynamic-Load für den ganzen Cluster ist selten der erste sinnvolle Schritt.

/10Häufige Fragen