Im Standardmodus basic verteilt Proxmox VE 9.2 HA-Gäste ohne Messwerte zur aktuellen Auslastung. Für die Platzierung anhand statischer Ressourcenangaben gibt es static-load; dynamic-load berücksichtigt die gemessene Nutzung. Hohe CPU-Last allein löst keine Migration aus. Ich halte die Hold Duration für die wichtigste Stellschraube gegen unnötige Balancing-Migrationen, weil sie kurze Lastspitzen ausfiltert, bevor der Scheduler eine Verschiebung erwägt.
Welche Gäste kann der Proxmox-Load-Balancer verschieben?
Automatische Balancing-Migrationen betreffen nur VMs und Container, die Proxmox als HA-Ressourcen verwaltet. Eine VM außerhalb der HA-Verwaltung bleibt auch bei aktiviertem dynamic-load auf ihrem Knoten, selbst wenn andere Knoten weniger ausgelastet sind. Für HA-Gäste kommen nur Ziele infrage, die Platzierungsregeln und technische Migrationsvoraussetzungen erfüllen.
Affinitäts- und Platzierungsregeln begrenzen die Auswahl möglicher Zielknoten. Der Scheduler platziert einen Gast nicht allein wegen günstiger Lastwerte entgegen diesen Regeln. Wenn im Testcluster trotz sichtbarer Lastunterschiede keine Migration stattfindet, geben die HA-Ressourcenübersicht und die Platzierungsregeln erste Hinweise auf die Ursache.
Nach einem Knotenausfall startet die HA-Verwaltung einen Gast auf einem geeigneten Knoten neu; bei laufendem Cluster kann der Scheduler dagegen eine Balancing-Migration veranlassen. Auch bei ausgeschaltetem auto-rebalance bleibt die HA-Verwaltung aktiv. Wer die HA-Konfiguration vertiefen möchte, findet dazu die Proxmox-Trainings. Für den Versuch zählt zunächst der Scheduling-Modus.
Cluster Resource Scheduling im Testcluster aktivieren
In der Proxmox-Oberfläche liegt die Einstellung unter Datacenter → Options → Cluster Resource Scheduling. basic ist der Standardmodus. Für den Lasttest stehen static-load und dynamic-load zur Wahl; nur der dynamische Modus berücksichtigt die gemessene Ressourcennutzung.
| Modus | Bedeutung für den Test |
|---|---|
basic | Standardmodus ohne lastbasiertes Balancing |
static-load | Scheduling anhand statischer Ressourcenangaben |
dynamic-load | Scheduling unter Berücksichtigung der gemessenen Nutzung |
Ein Vergleich verwendet denselben HA-Gast und unveränderte Platzierungsregeln. Dann lässt sich beobachten, ob die Modi bei wechselnder Auslastung unterschiedlich entscheiden, ohne dass eine geänderte Regel das Ergebnis verfälscht. Auch die Migration zum vorgesehenen Zielknoten muss möglich sein: Die Speicheranbindung, gebundene Geräte oder die CPU-Kompatibilität können sie verhindern.
Mit dynamic-load beginnt der Lasttest. Ob und wann der Scheduler einen Gast verschiebt, hängt nun von den Schwellenwerten und der Dauer des Ungleichgewichts ab.
Wann löst ein Lastunterschied eine HA-Migration aus?
Die CPU-Anzeige eines einzelnen Knotens beantwortet diese Frage nicht. Der Scheduler bewertet die Lastschieflage und die Verbesserung, die eine Migration voraussichtlich bringt.
Imbalance Threshold und Imbalance Improvement unterscheiden
In der Standardkonfiguration stehen für den Imbalance Threshold 30 Prozent und für die Imbalance Improvement 10 Prozent. Der erste Wert beschreibt die nötige Lastschieflage, der zweite die durch eine Verschiebung erwartete Verbesserung. Ein Improvement-Wert von 10 Prozent ist keine CPU-Grenze für einzelne VMs.
Für einen Vergleich bleiben beide Werte zunächst unverändert. Bleibt eine Migration aus, muss neben der Schieflage auch geprüft werden, ob die Verschiebung die geforderte Verbesserung erreicht und ein zulässiger Zielknoten verfügbar ist. Eine weitere Bedingung betrifft die Dauer des Lastunterschieds.
Hold Duration gegen kurze Lastspitzen einsetzen
Ein Ungleichgewicht muss über die eingestellte Hold Duration bestehen, bevor eine Balancing-Migration in Betracht kommt. Eine kurzzeitig rechenintensive Aufgabe kann abklingen, bevor der Scheduler eine Verschiebung erwägt. Bei periodischen Jobs zeigt der Test, ob die gewählte Dauer deren Lastspitzen überbrückt.
Der Scheduler prüft die Last wiederholt. Die Hold Duration verhindert, dass eine einzelne Momentaufnahme als dauerhaftes Ungleichgewicht zählt; Schwellenwerte und zulässige Zielknoten bleiben zusätzliche Bedingungen. Für den Vergleich eignen sich ein kurzer Lastanstieg und eine Schieflage, die länger als die eingestellte Hold Duration besteht. Ob daraus eine Migration entsteht, zeigen die Task-Logs im nächsten Schritt.
Wie testest du HA-Rebalancing vor dem Produktionsbetrieb?
Eine nicht kritische VM eignet sich als Testgast, sofern sie als HA-Ressource konfiguriert ist. Ihre Platzierungsregeln müssen einen weiteren Knoten zulassen; sonst sagt eine ausbleibende Migration nichts über die Lastbewertung aus. Auch die Migration selbst muss technisch möglich sein. Eine VM mit gebundenem Gerät prüft sonst vor allem die Gerätekonfiguration statt der Scheduler-Entscheidung.
Während des Versuchs zeigen die Knotendaten die Ressourcennutzung vor und nach einer möglichen Verschiebung. Die HA-Ressourcenübersicht und die Task-Logs zeigen, welcher Gast migriert wurde und ob der Vorgang erfolgreich war. Getrennte Aufzeichnungen für den kurzen Lastanstieg und die anhaltende Schieflage machen sichtbar, unter welchen Bedingungen der Scheduler eingreift.
Für latenzempfindliche Gäste lässt sich auto-rebalance einzeln deaktivieren. Das unterbindet automatische Balancing-Migrationen für den betreffenden Gast; nach einem Knotenausfall kann die HA-Verwaltung ihn weiterhin auf einem geeigneten Knoten neu starten. Die Option kommt infrage, wenn selbst eine technisch mögliche Migration die laufende Anwendung beeinträchtigen würde. Die Task-Logs und Knotendaten liefern anschließend die Grundlage für die Entscheidung über den Produktionsbetrieb.
Fazit: Migrationen am Nutzen messen
Eine Migration, nach der die Lastschieflage kaum abnimmt, verursacht Aufwand ohne erkennbare Entlastung. Vergleiche vor dem Rollout bei einer nicht kritischen HA-VM die Knotenauslastung vor und nach einer Testmigration.