Sharing-Mode uncap und uncapped_weight

Als PDF anschauen

Virtualizierung mit PowerVM > Praktische Einführung > Prozessor Virtualisierung > Shared Prozessoren (Micro-Partitioning)

5.2.3. Sharing-Mode uncap und uncapped_weight

Shared-Prozessor LPARs, die den Sharing-Mode uncap verwenden, konkurrieren miteinander um zusätzliche CPU-Zeit. Wieviel zusätzliche CPU-Zeit eine solche LPAR bekommen kann, hängt von drei Faktoren ab:

- Menge an zusätzlicher verfügbarer CPU-Zeit, die keiner LPAR zugewiesen ist.
- Der Gewichtung der LPAR, diese kann für jede uncapped Shared-Prozessor LPAR über das Attribut uncapped_weight auf einen Wert zwischen 0 und 255 gesetzt werden (Default ist 128). Je größer der Wert desto höher ist der Anteil den die LPAR bekommt.
- Wieviele weitere LPARs gerade um zusätzliche CPU-Zeit konkurrieren und deren Gewichtung. Eine LPAR die idle ist, konkurriert nicht um zusätzliche CPU-Zeit.

Die Ermittlung der zusätzlichen CPU-Anteile erfolgt dann wie folgt:

1. Die Gewichtungen aller LPARs die um zusätzliche Zeit konkurrieren werden addiert.
2. Der Anteile einer individuellen LPAR ergibt sich durch den Quotienten aus der eigenen Gewichtung und der Summe der Gewichtungen der konkurrierenden LPARs.
3. Der Anteil wird mit der zusätzlich zur Verfügung stehenden CPU-Zeit multipliziert.

In Bild 5.8 ist dies für 3 LPARs mit den Gewichtungen LPAR1 150, LPAR2 50 und LPAR3 100 gezeigt. Alle 3 LPARs konkurrieren um die nicht zugewiesenen 6ms des physikalischen Prozessors.

Die Ermittlung der Anteile für die einzelnen LPARs erfolgt dabei wie oben beschrieben:

- Bildung der Summe der Gewichtungen der konkurrierenden LPARs: 150 + 50 + 100 = 300.
- Ermittlung des Anteils eine LPAR durch Quotienten-Bildung:

LPAR1: 150 / 300 = 1/2

LPAR2: 50 / 300 = 1/6

LPAR3: 100 / 300 = 2/6

- Multipliziert mit dem zur Verfügung stehenden CPU-Anteil von 6ms ergibt sich dann:

LPAR1: 6.0 ms * 1/2 = 3.0 ms
LPAR2: 6.0 ms * 1/6 = 1.0 ms
LPAR3: 6.0 ms * 2/6 = 2.0 ms

Die zusätzlichen Anteile an CPU-Zeit sind allerdings nicht garantiert und können sich auch in jedem 10ms Zeitintervall ändern! Z.B. könnte eine weitere LPAR aktiviert werden, welche dann natürlich ihr Entitlement auch garantiert bekommt. Oder das Entitlement einer laufenden LPAR wird erhöht, womit dann weniger nicht zugewiesene Kapazität zur Verfügung steht.

Benötigt eine LPAR die ihr garantierten Processing Units in einem Zeitintervall nicht, dann gehen die nicht genutzten Processing Units an den Hypervisor zurück, der diese dann nach dem obigen Schema auf andere LPARs aufteilt.
Die Gewichtung einer LPAR (uncapped_weight) kann dynamisch zur Laufzeit geändert werden. Dazu kann das Kommando „lpar chproc“ (change processors) verwendet werden. Hierbei wird neben der LPAR einfach das Attribut uncapped_weight mit einem neuen Wert zwischen 0 und 255 angegeben:

$ lpar chproc aix05 uncapped_weight=100
$

Wird für uncapped_weight der Wert 0 angegeben, dann kann die LPAR keine zusätzlichen CPU-Anteile über ihr Entitlement hinaus bekommen. Sie verhält sich dann genauso wie eine LPAR mit dem Sharing-Mode cap!

Soll die Gewichtung in einem Profil geändert werden, muß das Kommando mit der Option „-p“ und dem Profilnamen gestartet werden:

$ lpar -p standard chproc aix05 uncapped_weight=100
$

In Bild 5.9 ist die Prozessor-Auslastung einer LPAR mit Sharing-Mode uncap gezeigt. Die LPAR wurde mit einem Entitlement von 0.6 (gelbe Linie) und einem virtuellen Prozessor konfiguriert.

Mit nur einem virtuellen Prozessor kann maximal nur ein physikalischer Prozessor zu 100% verwendet werden, die maximal mögliche Prozessor-Auslastung ist daher 1.0 (rote Linie). Verbraucht eine LPAR in einem Zeitintervall ihr garantiertes Entitlement nicht, dann wird der nicht verwendete Teil des garantierten Anteils anderen LPARs überlassen (ceded capacity – hell gelb). Der verbrauchte Teil des garantierten Anteils ist in grün eingezeichnet. Es gilt: verbrauchter Anteil des garantierten Entitlement plus ceded Kapazität ist gleich dem garantierten Entitlement. Das ist in der Graphik auch sehr gut erkennbar. Da die LPAR uncapped ist, kann sie bei Bedarf über den garantierten Anteil hinaus weitere Prozessor-Anteile bekommen, abhängig von der Menge an verfügbaren Anteilen und der Zuteilung an andere LPARs. Die zusätzlichen Prozessor-Anteile sind im Bild in blau eingezeichnet. Der grüne (garantierte) Anteil plus der blaue (zusätzliche) Anteil kann jedoch in Summe den Wert 1.0 nicht übersteigen. In der Graphik ist zu sehen, das die verbrauchten Prozessor-Anteile zweimal bei 1.0 „anstoßen“.

Hinweis: Die maximal mögliche Prozessor-Auslastung hängt von der Anzahl der virtuellen Prozessoren ab. Insbesondere gibt der Wert von max_proc_units nicht die maximal mögliche Anzahl von Processing-Units an, die eine LPAR bekommen kann! Der Wert max_proc_units gibt an, bis zu welchem Wert das garantierte Entitlement angehoben werden kann.