vmware bietet dem Administrator in jeder Edition einige Einstellmöglichkeiten um Virtuelle Maschinen [VMs] Performence-technisch zu steuern und zu priorisieren.
Dieses sind vor allem die Möglichkeit Memory (RAM) und CPU (MHz) einer VM zu limitieren bzw. zu reservieren. Dieses sind die sogenannten „Limits“ und „Reservations“ – siehe Screenshot.
Eine weitere Möglichkeit besteht darin VMs unterschiedlich zu priorisieren. Dieses geschied über die sogenannten „Shares“. Was sind nun Shares und was kann man damit machen?
Als erstes sei gesagt, das all diese Einstellmöglichkeiten nur dann Verwendung finden sollten wenn es wirklich benötigt wir und einiges nur im Falle eines Resourcen Engpasses zum Tragen kommt. Haben Sie in Ihrer Umgebung kein „Overcommitment“, also mehr Resourcen verteilt als Sie physikalisch haben, brauchen Sie sich z.B. über die Einstellung von Shares für RAM und CPU keine Gedanken machen.
Halten Sie Ihre Umgebung so einfach wie möglich!
Wenn Sie allerdings VMs priorisieren müssen (zu wenig physikalischer RAM oder CPU lastige VMs) dann bieten sich die Share Einstellungen der einzelnen VM bzw. eines Resource-Pools (in einem späteren Artikel) dazu an.
vmware bietet hier die Möglichkeit von drei vordefinierten Einstellunge oder alternativ einem frei einstellbaren Wert. Vorgegeben sind dabei:
- Low := 500 Shares
- Normal := 1000 Shares
- High := 2000 Shares
Dieses bedeutet das eine VM welche auf High in Bezug auf den RAM Bedarf gesetzt wird vom VMKernel eben bevorzugt mit physikalischen RAM versorgt wird, oder umgedreht – als letzte z.B. zum baloonen oder swappen genötigt wird.
Aber was ist nun ein Share? Erst einmal gar nichts! Denn Shares haben mehrere Fakten die zu beachten sind.
- Shares sind KEINE Prozentualen Anteile an einer Resource!
- Shares haben keine direkte Wertigkeit!
Soll heissen: Ob Sie allen VMs Einstellung im Bereich 10 / 20 / 40 Shares oder 5000 / 10.000 / 20.000 Shares geben spielt keine Rolle. - Shares sind immer nur im Zusammenhang mit den Einstellungen der anderen VMs eines Hostes bzw. Clusters zu betrachten!
Einstellungen einer einzelnen VM ohne Kenntnis der anderen VMs sind ohne Aussage!
Eine kurze Grafik soll dieses Erläutern:
Hier sehen wir in Status A erst mal alle VMs eines Hostes (oder Clusters) gleich priorisiert. Alle stehen auf Normal und haben somit prinzipiell Anspruch auf den gleichen Anteil (z.B. der CPUs)
Wir nun eine VM auf 3000 Shares gesetzt Status B verschiebt sich die Priorisierung zugunsten dieser VM. Nachfolgende Grafik soll die effektiven „Ansprüche“ verdeutlichen.
Status C zeigt die Veränderung durch das Ausschalten einer VM und Status D dann das hinzufügen einer „very High“ Shared VM. Was tatsächlich für die VMs bleibt zeigt die Grafik unten
In dieser Grafik wird die Verteilung anhand der Verschiedenen Stati und deren Verteilung in „Kuchenstücke“ gezeigt.
In meinen Kursen versuche ich immer den Spruch zu prägen „Einen Kuchen kann man nur einmal teilen! Je mehr Mitesser, desto kleiner die Stücke„. Wenn nun ein Mitesser höher priorisiert ist erhält Er eben einen doppelten oder n-fachen Anteil der anderen. Trotzdem ist der Kuchen nur einmal zu teilen!
Somit kann man Shares nicht immer leicht fassen, da man die Gesamtsituation betrachten muß und nur dann Rückschlüsse auf das VMKernel Verhalten im Fall des Resourcen Engpasses sehen.
Im Gegensatz zu Reservations sind Shares somit eher eine „weiche“ Einstellmöglichkeit ohne feste Werte. Bedeutet, ich muß, um z.B. eine tatsächliche Höherpriorisierung eine VM zu erreichen, diese mit einem „signifikant“ höheren Share – Wert versehen. Also alle VMs auf 1000 Shares und eine auf 1010 Shares macht sehr wenig Sinn. Vor allem ändert sich die Auswirkung mit der Anzahl der VMs auf dem Host bzw. Cluster, so das hier möglicherweise später „nachgebessert“ werden muß.
Um dieses in großen Umgebungen bzw. für ganze Gruppen von VMs nun nicht einzeln konfigurieren zu müssen existieren die sogenannten Resource-Pools. Diese möchte ich demnächst in einem weiteren Artikel behandeln.
dervirtuellewirt 