Kapazität und Admission Control

Frei im Normalbetrieb ist nicht reserviert für den Ausfall

Ein Dashboard zeigt 38 Prozent freien Arbeitsspeicher, und trotzdem lehnt der Cluster das Einschalten einer VM ab. Der Widerspruch löst sich auf, sobald man zwei Zahlen trennt, die im Alltag ständig verwechselt werden: was gerade frei ist und was für einen definierten Ausfall zurückgehalten wird.

Zulassungskontrolle — Die Prüfung, ob eine Aktion — meist das Einschalten einer VM — die zugesagte Ausfallreserve verletzen würde. Sie wirkt vor der Aktion und lehnt notfalls ab.

Failoverreserve — Der Anteil der Clusterkapazität, der rechnerisch unbenutzt bleibt, damit die VMs einer definierten Zahl ausgefallener Hosts anderswo anlaufen können.

Der Unterschied ist keine Wortklauberei. Freie Kapazität im Normalbetrieb ist eine Momentaufnahme; die Reserve ist eine Zusage gegen ein benanntes Ereignis. Wer die Reserve aufbraucht, weil gerade Platz ist, hat die Zusage stillschweigend gekündigt — und merkt es erst beim Ausfall.

Die Zulassungskontrolle rechnet mit Reservierungen, nicht mit Verbrauch

Das ist der Befund, der die meisten Kapazitätsdiskussionen umdreht. Beide rechnenden vSphere-Politiken arbeiten mit Reservierungen, nicht mit gemessener Nutzung. Die Dokumentation ist dabei ausdrücklich: Hat eine VM keine CPU-Reservierung, wird ihr ein Standardwert von 32 MHz zugewiesen; beim Speicher zählt die Reservierung zuzüglich Speicheraufschlag.

Daraus folgt etwas Unbequemes. Eine VM mit 64 GiB zugewiesenem Arbeitsspeicher und ohne Reservierung trägt zur Anforderung nur ihren Aufschlag bei — nicht 64 GiB. Ein Cluster voller unreservierter VMs kann die Zulassungskontrolle also mühelos bestehen und im Failover trotzdem zusammenbrechen, weil die tatsächliche Nachfrage mit der gerechneten nichts zu tun hat.

Ein Zahlenbeispiel macht die Lücke greifbar. Zehn VMs mit je 64 GiB zugewiesenem Speicher und ohne Reservierung ergeben eine gerechnete Anforderung von rund 10 mal dem Speicheraufschlag — je nach Ausstattung wenige Gigabyte. Ihre tatsächliche Nachfrage im Failover beträgt bis zu 640 GiB. Dieselben zehn VMs mit voller Reservierung ergeben eine Anforderung von 640 GiB plus Aufschlag. Die Hardware ist in beiden Fällen identisch; nur die Rechnung unterscheidet sich, und mit ihr die Aussagekraft des grünen Häkchens.

Die praktische Folge: Wer sich auf Zulassungskontrolle verlässt, muss zuerst entscheiden, welche Workloads eine Reservierung verdienen. Reservierungen sind der Hebel, über den die Rechnung überhaupt Kontakt zur Wirklichkeit bekommt — und zugleich reduzieren sie den frei planbaren Pool. Diese Spannung lässt sich nicht wegkonfigurieren, nur bewusst auflösen.

Slot-Politik: die größte Reservierung bestimmt jeden Slot

Die Slot-Politik zerlegt den Cluster in gleich große Blöcke. Ein Slot ist eine logische Einheit aus CPU und Speicher, die groß genug ist, um jede eingeschaltete VM des Clusters aufzunehmen. Genau in diesem „jede“ steckt die Falle.

• Die CPU-Komponente entsteht, indem die CPU-Reservierung jeder eingeschalteten VM ermittelt und der größte Wert gewählt wird.
• Die Speicherkomponente entsteht ebenso: Reservierung plus Aufschlag je VM, davon der größte Wert.
• Die Slots je Host ergeben sich aus Host-CPU geteilt durch CPU-Komponente und Host-Speicher geteilt durch Speicherkomponente, jeweils abgerundet — die kleinere Zahl gilt.
• Die aktuelle Failoverkapazität nennt, wie viele Hosts ausfallen dürfen, ohne dass Slots für die eingeschalteten VMs fehlen.

Eine einzige VM mit einer ungewöhnlich großen Reservierung vergrößert damit jeden Slot im Cluster. Aus vielen kleinen Blöcken werden wenige große, die Slotzahl bricht ein, und das Einschalten weiterer VMs wird abgelehnt — während das Dashboard reichlich freien Speicher zeigt. Der Cluster ist nicht voll; er ist falsch zerteilt.

Die Dokumentation nennt für diesen Fall ausdrücklich Obergrenzen: das.slotcpuinmhz und das.slotmeminmb deckeln die beiden Komponenten. Der voreingestellte CPU-Mindestwert für VMs ohne Reservierung lässt sich über das.vmcpuminmhz ändern.

Prozentpolitik: Summe statt Maximum

Die Politik über den Prozentsatz der Clusterressourcen vermeidet das Slotproblem, weil sie nicht mit dem größten Einzelwert rechnet, sondern mit der Summe. Sie hält einen festgelegten Anteil der CPU- und Speicherressourcen für das Failover zurück.

Zwei Feinheiten der Rechnung sind wichtig. Erstens zählen laut Dokumentation die Ressourcen des Wurzel-Ressourcenpools eines Hosts, nicht seine gesamte physische Ausstattung — der Eigenbedarf des Hypervisors ist also bereits abgezogen. Zweitens werden nur Hosts berücksichtigt, die verbunden sind, sich nicht in Wartung befinden und keine HA-Fehler melden. Ein Host im Wartungsmodus verschwindet damit aus der Rechnung und senkt die Kapazität genau dann, wenn ohnehin Betrieb stattfindet.

Die Kehrseite gegenüber der Slot-Politik: Ein Prozentsatz ist grob. Er sichert eine Gesamtmenge, aber nicht die Platzierbarkeit einer einzelnen großen VM. Rechnerisch können 20 Prozent frei sein, während keine einzelne Lücke groß genug ist, um die 96-GiB-Datenbank aufzunehmen — Fragmentierung schlägt die Summenrechnung.

Dedizierte Failoverhosts: teuer, aber eindeutig

Die dritte Politik benennt bestimmte Hosts, die für das Failover vorgehalten werden. Im Normalbetrieb nehmen sie keine VMs auf; fällt ein Host aus, laufen dessen VMs dort an. Der Vorteil ist die Eindeutigkeit: Die Reserve ist keine Rechnung, sondern ein Gerät, das man anfassen kann.

Stärke

Die Reserve ist sichtbar und nicht durch schleichendes Auffüllen aufzubrauchen

Preis

Im Normalbetrieb steht Hardware ungenutzt herum — der teuerste der drei Wege

Grenze

Eine Sonderausstattung des Failoverhosts kann eigene Bedingungen erzeugen; so ist etwa persistenter Speicher dedizierter Failoverhosts laut Dokumentation für den Failoverzweck reserviert und dort nicht für VMs bereitstellbar

Wer diese Politik wählt, kauft Klarheit mit Auslastung. Das ist keine schlechte Wahl — in Umgebungen mit harten Zusagen und wenigen, großen VMs ist sie oft die einzige, die im Ernstfall auch hält. Sie ist nur selten die billigste.

Welche Politik zu welchem Cluster passt

Die Wahl folgt der Streuung der VM-Größen und der Härte der Zusage, nicht der Gewohnheit.

Slot-Politik

Passt bei ähnlich großen VMs. Bei stark streuenden Reservierungen blockiert sie den Cluster, solange die Komponenten nicht gedeckelt sind

Prozentpolitik

Passt bei vielen, unterschiedlich großen VMs. Sichert eine Menge, aber nicht die Platzierbarkeit der größten VM

Dedizierte Hosts

Passt bei harten Zusagen und überschaubarer VM-Zahl. Teuerste Variante, dafür ohne Rechenfehler

Zwei Stellschrauben gehören zur Entscheidung. Die Zahl der tolerierten Hostausfälle legt fest, wogegen überhaupt abgesichert wird. Und die tolerierte Leistungsminderung bestimmt, welcher Leistungsverlust im Ausfall als zumutbar gilt — sie setzt voraus, dass DRS aktiv ist.

Das Ausfallmodell ist eine Annahme, kein Naturgesetz

Jede Reserve schützt gegen ein benanntes Ereignis. Üblich ist der Ausfall eines Hosts, oft als N-1 bezeichnet. Diese Zahl ist eine Entscheidung, keine Eigenschaft des Clusters — und sie deckt nur das ab, was sie benennt.

• N-1 trägt den Ausfall eines Hosts. Ein zweiter Ausfall während der Reparaturzeit ist nicht abgedeckt.
• N-2 trägt zwei Hosts und kostet entsprechend mehr Reserve.
• Gemeinsame Fehlerdomänen hebeln das Modell aus: Liegen vier Hosts in einem Rack an einer Stromschiene, ist ein Rackausfall kein N-1-Ereignis, sondern N-4.
• Wartung zählt mit: Ein Host im Wartungsmodus fällt aus der Kapazitätsrechnung heraus — während der Wartung läuft der Cluster faktisch mit einer um eins verringerten Reserve.

Der letzte Punkt erklärt eine wiederkehrende Überraschung: Ein Cluster, der N-1 zusagt, erfüllt diese Zusage während eines Wartungsfensters nicht mehr, solange der gewartete Host aus der Rechnung fällt. Wer beides zugleich zusagen will, braucht die Reserve für Wartung zusätzlich zur Reserve für den Ausfall.

Fehlerdomänen sind dabei der unangenehmste Teil, weil sie außerhalb des Clusters liegen und im Werkzeug nicht auftauchen. Stromschiene, Switch-Stack, Kühlkreis, Firmwarestand und Virtualisierungshost-Charge sind allesamt Kandidaten für einen gemeinsamen Ausfall. Ein Cluster kann rechnerisch N-2 tragen und trotzdem an einem Ereignis scheitern, das vier Hosts gleichzeitig trifft. Die Reserve ist nur so viel wert wie die Unabhängigkeit der Dinge, gegen die sie versichert.

Proxmox platziert, statt zuzulassen — und zählt dabei Gäste

Proxmox VE geht die Frage von der anderen Seite an. Die Dokumentation beschreibt keinen vorab prüfenden Mechanismus, der das Starten einer VM wegen fehlender Failoverreserve ablehnt. Sie beschreibt einen Cluster Resource Scheduler, der Zielknoten auswählt, wenn Dienste platziert oder nach einem Fencing wiederhergestellt werden müssen.

Dessen Voreinstellung ist bemerkenswert. Konfiguriert wird sie in datacenter.cfg über crs: ha=<basic|static|dynamic>, Standardwert ist basic. Und basic bedeutet laut Dokumentation: Es wird nur die Anzahl der Dienste herangezogen.

basic (Standard)

Nur die Zahl der aktiven Gäste je Knoten entscheidet über den Zielknoten

static

Berücksichtigt die konfigurierten CPU- und Speicherzuteilungen der aktiven Gäste

dynamic

Berücksichtigt zusätzlich die durchschnittliche gemessene CPU- und Speichernutzung

In einem Cluster mit gleichartigen VMs ist das unauffällig. In einem gemischten Cluster ist es ein Platzierungsrisiko: Ein Knoten mit drei kleinen Containern gilt als voller als einer mit zwei 96-GiB-VMs. Nach einem Knotenausfall können so mehrere große VMs auf demselben Ziel landen, obwohl anderswo mehr Luft wäre.

Überbuchung ist ein Nachfragerisiko, keine Quote

Zulassungskontrolle und Überbuchung werden leicht vermengt, beantworten aber verschiedene Fragen. Die Zulassungskontrolle fragt: Bleibt die zugesagte Reserve nach dieser Aktion bestehen? Überbuchung fragt: Was passiert, wenn mehr VMs gleichzeitig ihren zugewiesenen Anteil abrufen, als physisch vorhanden ist?

Die Ressourcensemantik dahinter — Reservierung, Limit, Gewichtung, Speicherdruckstufen, NUMA — gehört in das Modul zu CPU und Speicher und wird hier nicht wiederholt. Für die Kapazitätsentscheidung genügt die Abgrenzung: Überbuchung ist ein Risiko über die Zeit und die Gleichzeitigkeit, die Reserve ein Betrag für ein Ereignis.

Beide treffen sich an einer Stelle: Reservierungen. Sie sind der einzige Hebel, der zugleich die Zulassungsrechnung befüllt und das Überbuchungsrisiko für eine bestimmte VM begrenzt — und genau deshalb der einzige, der sparsam vergeben werden muss.

Lehnt die Zulassung ab, gibt es genau zwei ehrliche Antworten

Eine Ablehnung ist kein Defekt, sondern ein funktionierendes Tor. Sie meldet, dass die gewünschte Aktion mit der bestehenden Zusage unvereinbar ist. Daraus folgen zwei Wege — und ein dritter, der nur so aussieht.

Kapazität ergänzen

Host hinzufügen, Reservierungen senken oder Last verlagern, bis die Zusage wieder trägt

Zusage bewusst senken

Das Ausfallmodell oder die tolerierte Leistungsminderung ausdrücklich anpassen — mit Eigentümer, Datum und Begründung

Tor abschalten

Sieht nach Lösung aus, verschiebt das Risiko aber nur vom Einschaltzeitpunkt in den Ausfallzeitpunkt

Der Unterschied zwischen Weg zwei und Weg drei ist ausschließlich die Dokumentation der Entscheidung. Beide senken den Schutz; nur einer hinterlässt jemanden, der weiß, dass er gesenkt wurde. Wer das Tor still deaktiviert, erzeugt eine Zusage, an die der Betrieb weiterhin glaubt.

Arbeitsbeispiel: abgelehnt bei 400 GiB freiem Speicher

Übertragbar ist das Muster hinter dem Fall: Wo ein System in Einheiten rechnet, die es selbst bildet, sagt die Rohzahl auf dem Dashboard wenig über die Entscheidung aus. Die Frage lautet nicht „wie viel ist frei“, sondern „in welchen Einheiten rechnet das Tor, und wer bestimmt deren Größe“.