In einem DRS-Cluster kann man Ressource-Pools als weitere logische Abstraktionsebene anlegen. Sie lassen sich zur Partitionierung verfügbarer CPU-Leistung und von Arbeitsspeicher benutzen und sogar in Hierarchien anordnen. Eine falsche Verwendung des Features kann aber Ressourcen blockieren.
Eines der Haupteinsatzgebiete von Ressource-Pools ist das Bilden von Ressourcen-Silos für den Fall, dass Abteilungen im Unternehmen oder Subunternehmen als Mandanten betrachtet werden. Sie bezahlen zum Beispiel im Rahmen von SLAs für eine bestimmte Menge an Rechenleistung, die dann garantiert werden muss.
Kapselung von Ressourcen
Ein anderer Zweck von Ressourcen-Pools besteht in der Möglichkeit dafür zu sorgen, dass eine Ressource-Gruppe eine in der Hierarchie höherliegende Ressource nicht beeinträchtigen kann, wenn sie außer Kontrolle gerät.
Grundsätzlich handelt es sich bei Ressourcen-Pools um ein Cluster-Feature, und zwar speziell im Zusammenhang mit DRS. Daher setzt es eine Enterprise-Plus-Lizenz voraus. Das Feature ist somit auch deaktiviert, wenn kein DRS im Cluster aktiviert ist.
Ressourcen-Pools auf einzelnen Host problematisch
Das ist deshalb so, weil die Hosts in einem Cluster im Falle eines Server-Ausfalls austauschbar sein sollen. Ressourcen-Pools auf Host-Ebene in einem Cluster können jedoch das Verhalten der virtuellen Maschine drastisch beeinflussen, wenn ein Failover auf einen anderen ESXi-Host im Cluster erfolgt, zu dem der Ressourcen-Pool nicht gehört.
Auch wenn Zweck und Konfiguration von Ressource-Pools auf dem ersten Blick leicht verständlich erscheinen, ist bei der Verwendung dennoch Vorsicht geboten. Am wichtigsten ist zu verstehen, dass Reservierungen und Grenzwerte immer die Flexibilität des CPU-Schedulers bzw. Memory-Allocators sowie des VMKernel-Storage-Stacks beschränken.
Starre Ressourcenzuteilung
Die hier gemachten Einstellungen wirken sich nämlich immer aus, egal ob die virtuellen Maschinen gerade erhöhten Ressource-Bedarf haben oder ob Host-seitig überhaupt eine Ressourcen-Knappheit vorliegt, die zu einer etwaigen Konkurrenzsituation unter den Verbrauchern führt. Anteile hingegen sind flexibler, da sie vom Hypervisor nur berücksichtigt werden, wenn es zu einer Konkurrenzsituation kommt.
Kann die noch verfügbare Kapazität des Hosts oder Clusters die Erfordernisse der Ressourcen-Verbraucher nicht erfüllen, dann muss der Nutzer ggf. die Menge der Ressourcen anpassen, die der Kernel den Ressourcen-Pools zuteilt.
Dazu dienen die Einstellungen Anteile (Shares), Reservierungen (Reservations) und Grenzwerte (Limits). Sie bestimmen die CPU-, Arbeitsspeicher- und Storage-Ressourcen, die einem Ressourcen-Pool zur Verfügung gestellt werden. Sinn und Zweck der genannten Steuerungs-Instrumente sollte vSphere-Admins bekannt sein.
Hier eine kurze Zusammenfassung:
- Mit einer Reservierung stellt man den garantierten Mindestwert für die Ressourcenzuteilung einer virtuellen Maschine oder eines Resource-Pools ein. Im Falle der Arbeitsspeicher-Virtualisierung wird die hier eingetragene Größe von jener der Auslagerungsdatei (VM-Name.vswp im VM-Directory des Hosts) abgezogen.
- Der Grenzwert legt eine Obergrenze für CPU-, Arbeitsspeicher- oder Storage-I/O-Ressourcen fest, die der Hyperversior der virtuellen Maschine bzw. dem Ressourcen-Pool zuteilt und ist immer kleiner oder gleich der konfigurierten Arbeitsspeichergröße oder CPU-Taktfrequenz.
- Anteile hingegen spiegeln die relative Wichtigkeit einer virtuellen Maschine (oder eines Ressourcen-Pools) gegenüber anderen Verbrauchern wieder. Verfügt eine virtuelle Maschine über doppelt so viele Anteile einer Ressource wie eine andere virtuelle Maschine verfügt, darf sie in einer Konkurrenzsituation (nur dann wirken sich Anteile aus) doppelt so viele Ressourcen zu verbrauchen.
In vielen VMware-Blogs und öffentlichen Vorträgen findet man dazu häufig eine Abbildung der folgenden Art, die allerdings etwas unglücklich ist, da sie häufig zu einer Miss-Interpretation führt.