Dynamic Load Balancer in PVE 9.2: DRS-Ersatz oder nicht?

/01Was der Dynamic Load Balancer ist — und was er nicht ist

Der Dynamic Load Balancer ist kein eigener Dienst, sondern eine Betriebsart des Cluster Resource Schedulers (CRS) in pve-ha-manager. Der CRS entscheidet seit Jahren, auf welchem Knoten ein HA-Gast nach einem Ausfall, im Wartungsmodus oder beim Start landet. Mit Proxmox VE 9.2 vom 21. Mai 2026 kommt eine zweite Aufgabe hinzu: Der Scheduler darf im dynamischen Modus laufende Gäste auch ohne Anlass verschieben, wenn die gemessene Auslastung der Knoten zu weit auseinanderläuft. Proxmox nennt das in der Pressemitteilung „intelligent scheduler that optimizes guest placement across cluster nodes" und schreibt dazu, dass Migrationen die vom Nutzer gesetzten HA-Regeln respektieren.

Was der Balancer nicht ist: ein Ersatz für die Kapazitätsplanung, eine Antwort auf Speicherengpässe oder ein Werkzeug, das jede VM und jeden Container im Cluster anfasst. Die drei Betriebsarten des CRS stehen in der datacenter.cfg: basic zählt nur die Zahl der Dienste je Knoten, static rechnet mit den konfigurierten CPU- und Speicherwerten der Gäste, dynamic zieht zusätzlich die tatsächliche CPU- und Speichernutzung heran. Nur die dritte Betriebsart misst — und nur mit ihr ergibt der automatische Ausgleich Sinn.

Die Mechanik des Schedulers — wie Ungleichgewicht berechnet wird, wie die Werkseinstellungen zusammenspielen, wie der Einstieg über den statischen Modus aussieht — steht in Proxmox CRS: Dynamische Lastverteilung im Cluster einrichten. Dieser Artikel setzt darauf auf und beantwortet die Frage, die VMware-Umsteiger tatsächlich stellen: Ist das DRS?

/02Was DRS in vSphere tatsächlich tut

Der Distributed Resource Scheduler von VMware ist seit vielen Jahren im Markt, und die meisten Administratoren kennen ihn als Schalter, den man einmal auf „Fully Automated" stellt und dann vergisst. Hinter dem Schalter steckt laut Broadcom-Dokumentation ein Regler mit fünf Stufen von „Conservative" bis „Aggressive": Die konservativste Stufe erzeugt nur Empfehlungen der Priorität eins — die verpflichtenden, etwa bei Regelverstößen oder Wartungsmodus —, und je aggressiver die Einstellung, desto häufiger empfiehlt DRS Migrationen, um die „VM happiness" zu verbessern. Dazu kommen drei Automatisierungsgrade: Im vollautomatischen Modus werden Empfehlungen angewendet, im manuellen und teilautomatischen Modus dem Administrator zur Bestätigung vorgelegt. Microsofts Gegenstück unter Hyper-V heißt dynamische Optimierung im Virtual Machine Manager und ist hier nicht Thema.

DRS ist außerdem der Unterbau für weitere Funktionen, die im Alltag oft gar nicht als DRS wahrgenommen werden: VM-Host-Regeln („diese VMs nur auf diesen Hosts"), VM-VM-Regeln (Affinität und Anti-Affinität), der Wartungsmodus, der einen Host automatisch leert, Storage DRS für den Ausgleich von Speicherplatz und I/O-Last zwischen Datastores, und Predictive DRS, das Lastprognosen aus der Monitoring-Historie in die Platzierung einbezieht. Wer den Funktionsumfang des Load Balancers bewertet, muss also erst auseinandernehmen, welchen dieser Teile der eigene Cluster tatsächlich genutzt hat.

In der Praxis: Die meisten Mittelstandscluster mit drei bis fünf Hosts haben DRS auf „Fully Automated" mit Standardschwelle laufen lassen, zwei bis drei Anti-Affinitätsregeln gepflegt und den Wartungsmodus benutzt. Storage DRS lief, wenn überhaupt, im manuellen Modus. Predictive DRS setzte vRealize beziehungsweise Aria Operations voraus und war damit in dieser Größenklasse selten. Das ist keine Statistik, sondern ein Erfahrungswert aus Migrationsgesprächen — aber er verschiebt die Vergleichsfrage deutlich.

/03Reichweite: alle Gäste gegen HA-Gäste

Hier liegt der Unterschied, der in keinem Feature-Vergleich fett gedruckt ist und trotzdem alles entscheidet. In vSphere ist die Teilnahme einer VM an DRS nicht daran gekoppelt, ob sie HA-geschützt ist — DRS und HA sind zwei getrennte Cluster-Eigenschaften, und eine VM kann an beidem, an einem oder an keinem teilnehmen. In Proxmox VE bewegt der Load Balancer ausschließlich Gäste, die als HA-Ressource eingetragen sind. Die Pressemitteilung sagt es ohne Umschweife: Migriert werden „workloads managed by the High Availability stack".

Das hat zwei Konsequenzen. Erstens: Ein Cluster, in dem nur die wichtigsten zehn von sechzig VMs unter HA stehen, bekommt einen Lastausgleich für zehn VMs — die übrigen fünfzig bleiben, wo sie sind, egal wie schief die Auslastung ist. Zweitens: Wer alle Gäste unter HA stellt, um den Balancer voll zu nutzen, holt sich damit auch das HA-Verhalten für alle Gäste — Fencing des Knotens bei Verbindungsverlust, automatischer Neustart, Quorum-Abhängigkeit. Für eine Test-VM, die nach einem Knotenausfall nicht zwingend sofort wieder laufen muss, ist das mehr Automatik, als man will. Was HA im Fehlerfall konkret tut und warum Corosync dabei Knoten neu startet, steht in Warum Corosync nachts Knoten neu startet.

# Welche Gaeste kommen fuer den Balancer ueberhaupt infrage?
ha-manager status
# quorum OK
# master pve01 (active, Mon Sep 28 08:05:12 2026)
# lrm pve01 (active, ...)
# service vm:101 (pve01, started)
# service vm:102 (pve02, started)
# service ct:200 (pve03, started)

# Gegenprobe: alle laufenden VMs im Cluster
pvesh get /cluster/resources --type vm --output-format json \
  | jq -r '.[] | select(.status=="running") | "\(.vmid) \(.node) hastate=\(.hastate // "none")"'

Die zweite Abfrage zeigt in der Spalte hastate, welche Gäste keinen HA-Eintrag haben — sie sind für den Balancer unsichtbar. Vor jeder Bewertung „der Balancer tut nichts" gehört diese Liste auf den Tisch.

/04Automatisierungsgrade: fünf Stufen gegen drei Stellschrauben

DRS regelt seine Aggressivität über den fünfstufigen Schwellenwert und den Automatisierungsgrad, und beides lässt sich je VM überschreiben — eine Datenbank-VM kann im manuellen Modus bleiben, während der Rest vollautomatisch läuft. Proxmox VE regelt den Balancer über Parameter in der datacenter.cfg, die für den ganzen Cluster gelten. Laut Handbuchseite datacenter.cfg(5) sind das:

Drei Dinge fallen im Vergleich auf. Es gibt keinen Parameter für einen reinen Empfehlungsmodus — der Balancer migriert oder er tut nichts, ein „zeig mir, was du tun würdest" kennt die Konfiguration nicht. Es gibt keine Einstellung je Gast; die Schwellen gelten clusterweit. Und es gibt keinen Stufenregler, sondern drei Zahlen, die zusammenwirken: Erst wenn das Ungleichgewicht über dem Schwellenwert liegt, und zwar über die Haltezeit hinweg, und eine Migration das Ungleichgewicht um mindestens die Marge verbessert, passiert etwas. Das ist weniger bequem als ein Schieberegler, aber nachvollziehbarer — jede Migration lässt sich auf diese drei Bedingungen zurückführen.

# Dynamischen Modus mit vorsichtigen Werten aktivieren
# (datacenter.cfg, clusterweit; Aenderung greift ohne Neustart)
crs: ha=dynamic,ha-auto-rebalance=1,ha-auto-rebalance-threshold=40,ha-auto-rebalance-margin=15,ha-auto-rebalance-hold-duration=5

# Ergebnis pruefen
pvesh get /cluster/options --output-format json | jq .crs
journalctl -u pve-ha-crm --since "1 hour ago" | grep -i -E 'balanc|migrat'

Die höheren Werte im Beispiel sind Absicht: Wer den Balancer zum ersten Mal einschaltet, will sehen, dass er bei deutlichem Ungleichgewicht reagiert — nicht, dass er bei jeder Lastspitze eines Batchlaufs migriert. Belastbare Werte für Ihre Umgebung liefert nur die Beobachtung des Protokolls über einige Wochen.

/05Regeln: Affinität, Anti-Affinität und Knotenbindung

Bei den Regeln ist der Abstand am kleinsten. Proxmox VE 9 hat die alten HA-Gruppen durch HA-Regeln ersetzt: Node-Affinity-Regeln binden Ressourcen an bestimmte Knoten, Resource-Affinity-Regeln halten Gäste zusammen oder trennen sie. Die Roadmap nennt für 9.0 die Umstellung „HA groups are replaced by HA node affinity rules for more flexible resource placement" und als weiteres Ziel reichere Ausdrucksmöglichkeiten — weich gegen hart, gruppenweise, topologiebewusst. Der Balancer respektiert diese Regeln bei jeder Migration; die Pressemitteilung zur 9.2 hebt das ausdrücklich hervor.

Der typische Fall aus der VMware-Welt — zwei Domänencontroller nie auf demselben Host, die beiden Knoten eines Datenbank-Clusters getrennt, der Terminalserver bevorzugt auf dem Knoten mit den schnellsten CPUs — lässt sich damit eins zu eins abbilden. Was fehlt, ist die Verknüpfung mit Host-Gruppen im DRS-Sinn („VM-Gruppe A muss auf Host-Gruppe B"); Proxmox bildet das über die Node-Affinity je Ressource ab, was bei vielen Regeln unübersichtlicher wird, aber dasselbe Ergebnis liefert.

Ein Punkt, der bei der Migration gern übersehen wird: Die Regeln greifen nur für HA-Ressourcen — wie der Balancer selbst. Eine Anti-Affinitätsregel für zwei VMs ohne HA-Eintrag hat keine Wirkung, weil der HA-Manager sie nicht verwaltet. Wer Anti-Affinität ohne HA-Verhalten will, hat in Proxmox VE derzeit keinen Mechanismus dafür.

/06Was weiter fehlt: Storage DRS, Vorhersage, Empfehlungsmodus

Drei DRS-Bausteine haben in Proxmox VE 9.2 keine Entsprechung, und es ist fair, das ohne Relativierung zu sagen.

Storage DRS

vSphere kann Speicherplatz und I/O-Last zwischen Datastores eines Clusters automatisch ausgleichen und VMs bei Bedarf per Storage vMotion verschieben. Proxmox VE hat dafür nichts Automatisches. Ein Volume wandert per qm move-disk oder qm disk move — im laufenden Betrieb, aber auf Anweisung. Wer mit mehreren SAN-LUNs unter LVM oder ZFS-Pools arbeitet und die Belegung bisher DRS überlassen hat, braucht nach der Migration ein Monitoring mit Schwellenwert und einen Menschen, der handelt. Bei Ceph entfällt die Frage weitgehend, weil ein Pool über alle Knoten verteilt ist — das ist einer der Gründe, warum Ceph in Proxmox-Clustern so verbreitet ist.

Predictive DRS

Die Platzierung anhand von Lastprognosen aus der Monitoring-Historie gibt es in Proxmox VE nicht. Der Balancer arbeitet mit der aktuellen Messung und der Haltezeit — er reagiert, er antizipiert nicht. Für Cluster mit vorhersehbaren Lastmustern (Monatsabschluss, nächtliche Batchläufe) heißt das: Entweder man setzt die Haltezeit so, dass kurze Spitzen ignoriert werden, oder man verschiebt vor dem Monatsabschluss von Hand. Beides ist Betriebsaufwand, den DRS mit Aria Operations abgenommen hat — bei den wenigen, die diese Kombination hatten.

Empfehlungsmodus

Der manuelle DRS-Modus, in dem Empfehlungen angezeigt und einzeln bestätigt werden, fehlt. In der Praxis war er für viele Administratoren der Einstieg: erst zusehen, was DRS tun würde, dann freischalten. In Proxmox VE bleibt dafür nur das Protokoll des pve-ha-crm im Nachhinein — oder der statische Modus ohne ha-auto-rebalance, der bei Wartung und Ausfall die Platzierung übernimmt, aber im Normalbetrieb nichts verschiebt.

/07Der Vergleich in einer Tabelle

Zur Lizenzzeile: Welche vSphere-Edition DRS heute enthält und was sie kostet, hat sich seit der Broadcom-Übernahme mehrfach geändert; belastbar ist nur das aktuelle Angebot Ihres Händlers. Die Einordnung der Lizenzlage steht in VMware-Alternativen 2026; hier geht es um die Funktion, nicht um den Preis.

/08Wo es hakt: die stillen Voraussetzungen

Vier Punkte, die beim ersten Einschalten nicht in der Oberfläche stehen.

Die Werkseinstellung tut nichts

Ab Werk steht ha auf basic und ha-auto-rebalance auf 0. Wer nach dem Upgrade auf 9.2 erwartet, dass sich der Cluster von allein ausgleicht, wartet vergeblich. Das ist eine bewusste Entscheidung von Proxmox — und die richtige, denn ein Balancer, der ungefragt migriert, ist im Betrieb schlimmer als keiner.

Migration kostet Bandbreite und Latenz

Jede automatische Migration ist eine Live-Migration mit allem, was dazugehört: Arbeitsspeicher wird über das Cluster-Netz kopiert, die VM steht für den letzten Umschaltmoment kurz still, und auf geteiltem Storage — iSCSI- oder Fibre-Channel-LUN, NFS, Ceph — muss die Disk nicht mitwandern, auf lokalem Storage schon. Wer den Balancer auf einem Cluster mit lokalem ZFS und 1-GbE-Migrationsnetz einschaltet, bekommt Migrationen, die länger dauern als die Lastspitze, die sie auslösen sollte. Ein eigenes Migrationsnetz ist keine Kür.

Der Scheduler sieht CPU und Speicher, sonst nichts

Die Dokumentation nennt für den dynamischen Modus die statische und dynamische CPU- und Speichernutzung der Dienste. Netzwerklast, Storage-I/O, GPU-Belegung oder NUMA-Lokalität gehen nicht in die Entscheidung ein. Ein Knoten, dessen Netzwerkkarte am Anschlag ist, gilt für den Balancer als entspannt, solange CPU und RAM Luft haben.

Ein Gast, der oft wandert, ist ein Symptom

Wenn das Protokoll dieselbe VM mehrmals täglich zwischen Knoten zeigt, sind die Schwellen zu eng oder die VM ist schlicht zu groß für die Reserve des Clusters. Der Balancer verteilt Last, er schafft keine Kapazität. Ein Cluster, der nahezu voll ausgelastet ist, wird durch Umverteilung nicht leerer — er wird nur gleichmäßig voll.

/09Für wen der Load Balancer reicht — und für wen nicht

Die Antwort auf die Titelfrage: Der Dynamic Load Balancer ist ein DRS-Ersatz für das, was die meisten Mittelstandscluster von DRS genutzt haben — und kein Ersatz für den vollen Funktionsumfang.

Es reicht, wenn

• Ihr Cluster drei bis fünf Knoten hat und die produktiven Gäste ohnehin unter HA stehen sollen: Dann deckt der Balancer genau die Menge ab, die DRS bei Ihnen bewegt hat.
• Sie DRS auf „Fully Automated" mit Standardwerten hatten und Regeln nur für Anti-Affinität: Beides bildet Proxmox VE ab, die Regeln sogar mit weichen und harten Varianten.
• Ihr Storage geteilt ist — Ceph, SAN, NFS: Migrationen sind dann Speicherkopien ohne Disk-Transfer, und Storage DRS war bei einem einzigen Datastore ohnehin bedeutungslos.
• Sie ein Monitoring haben, das Migrationen und Belegung sichtbar macht: Der fehlende Empfehlungsmodus wird durch ein gelesenes Protokoll ersetzt.

Es reicht nicht, wenn

• Sie viele Gäste bewusst ohne HA betreiben und trotzdem ausgleichen wollen: Diese Gäste sind für den Balancer unsichtbar, und daran ändert keine Einstellung etwas.
• Storage DRS bei Ihnen aktiv Speicherplatz zwischen mehreren Datastores verschoben hat: Das wird nach der Migration Handarbeit mit Alarmierung.
• Sie je VM unterschiedliche Automatisierungsgrade brauchen: Die Datenbank manuell, der Rest automatisch — das geht in Proxmox VE nur über die Entscheidung, welche Gäste überhaupt unter HA stehen.
• Predictive DRS Teil Ihres Betriebskonzepts war: Das ist selten, aber wo es zutrifft, gibt es keine Entsprechung.

Unsere Praxis-Linie: Nach der Migration den Cluster erst im statischen Modus ohne automatischen Ausgleich laufen lassen, die HA-Ressourcen bewusst festlegen, das Protokoll lesen — und den dynamischen Ausgleich mit konservativen Schwellen einschalten, wenn das Muster der Auslastung bekannt ist. Das dauert Wochen, nicht Stunden, und es ist die Reihenfolge, in der auch DRS damals eingeführt wurde: erst manuell, dann automatisch.

/10Häufige Fragen