5.2. Shared Prozessoren (Micro-Partitioning)
Wird ein dedizierter Prozessor nur wenig ausgelastet, kann die nicht verwendete Rechenleistung nicht genutzt werden. Daher wurde mit Einführung von POWER5 Systemen von IBM die Micro Partitionierung eingeführt. Dabei werden ein oder mehrere Prozessoren von mehreren LPARs gemeinsam benutzt. Damit wird eine höhere Auslastung der Prozessoren erreicht. Die Rechenleistung eines physikalischen Prozessors wird dabei in 100 Anteile aufgeteilt. Jeder Anteil entspricht dabei 0.01 Processing Units (1 hundertstel eines Prozessors bzw. 1% eines Prozessors). Den LPARs können dann Processing Units mit einer Granularität von 0.01 Processing Units zugewiesen werden.
In Bild 5.2 ist die Aufteilung der Prozessor Anteile eines physikalischen Prozessors auf 3 LPARs dargestellt. Dabei bekommt LPAR1 0.15 Processing Units (15%), LPAR2 bekommt 0.10 Processing Units (10%) und LPAR3 bekommt 0.15 Processing Units (15%) der Rechenleistung des Prozessors. In der Summe sind das 0.40 Processing Units (40%), womit noch 0.60 Processing Units (60%) für weitere LPARs zur Verfügung stehen würden. Der Begriff Micro-Partitionierung kommt daher das hier eine Ressource in weitere Anteil aufgeteilt wird. Bei den dedizierten Prozessoren, wird als kleinste Einheit immer ein ganzer Prozessor einer LPAR zugeordnet, bei der Micro-Partitionierung wird ein Prozessor weiter aufgeteilt (in 100 Anteile) und diese kleineren Anteile können verschiedenen LPARs zugeordnet werden.
Die zugewiesenen Processing Units einer LPAR werden als Entitlement (Anspruch) oder Entitled Capacity bezeichnet. Der Hypervisor garantiert das eine LPAR die zugeordnete Entitled Capacity unter allen Umständen auch zugewiesen bekommt, unabhängig von der aktuellen Auslastung der unterliegenden Hardware.
Die Aufteilung der Anteile eines physikalischen Prozessors auf die zugehörigen LPARs erfolgt in einem Zeitscheiben-Verfahren. Dabei weist der Hypervisor in jedem 10ms Zeitintervall den LPARs einen Anteil an der Prozessor-Zeit gemäß den konfigurierten Anteilen zu. Ein physikalischer Prozessor wird damit von mehreren LPARs gemeinsam genutzt, daher auch der Begriff Shared Prozessor für den gemeinsam genutzten physikalischen Prozessor, sowie Shared Prozessor LPAR für eine LPAR welche Shared Prozessoren verwendet. Wie in Bild 5.3 gezeigt ist, bekommt während jedes 10ms Zeitintervalls jede LPAR den Shared Prozessor für ein kurzes Zeitintervall (entsprechend den konfigurierten Anteilen der LPAR) zugewiesen. Die gelbe LPAR aus dem Bild mit 0.15 Processing Units bekommt entsprechend einen Anteil von 1.5ms in jedem 10ms Zeitintervall zugewiesen.
Wie bei LPARs mit dedizierten Prozessoren, lässt sich auch beim Anlegen von Shared Prozessor LPARs die Anzahl der gewünschten Prozessoren angeben. Es werden aber keine physikalischen Prozessoren zugeordnet, sondern sogenannte virtuelle Prozessoren. Ein virtueller Prozessor in einer LPAR erlaubt es Anteile an einem physikalischen Prozessor gemäß dem oben angesprochenen Zeitscheiben-Verfahren zu bekommen. Wird eine LPAR z.B. mit 8 virtuellen Prozessoren konfiguriert, dann kann sie bis zu 8 physikalische Prozessoren parallel nutzen. Wieviele Anteile die LPAR an den physikalischen Prozessoren bekommt, wird wie gehabt über das zugeordnete Entitlement (oder Entitled Capacity) der LPAR bestimmt.
Das LPAR-Tool erzeugt, wenn nicht anders angegeben, per Default Shared Prozessor LPARs. Die gewünschte Anzahl an virtuellen Prozessoren kann hierbei analog wie bei den dedizierten LPARs über das Attribut desired_procs angegeben werden:
$ lpar create -m ms02 lpar10 desired_procs=2
.
> lpar10
$
Die schon von den dedizierten LPARs bekannten Attribute min_procs und max_procs behalten ihre Bedeutung. Die beiden Attribute beziehen sich jetzt aber nicht auf dedizierte Prozessoren, sondern auf virtuelle Prozessoren. Eine LPAR kann nur aktiviert werden, wenn mindestens die durch min_procs angegebene Anzahl an virtuellen Prozessoren zugeordnet werden kann. Die Anzahl der virtuellen Prozessoren kann online in den von min_procs und max_procs vorgegebenen Grenzen dynamisch geändert werden.
Die im Beispiel oben neu erzeugte LPAR lpar10 hat die folgende Konfiguration:
$ lpar -p standard lsproc lpar10
PROC PROCS PROC_UNITS UNCAP PROC
LPAR_NAME MODE MIN DESIRED MAX MIN DESIRED MAX SHARING_MODE WEIGHT POOL
lpar10 shared 1 2 2 0.2 0.2 0.2 uncap 100 DefaultPool
$
Der Prozessor-Mode (proc_mode) ist shared. Die minimale Anzahl an virtuellen Prozessoren (min_procs) ist 1, die gewünschte Anzahl an virtuellen Prozessoren (desired_procs) ist 2 und die maximale Anzahl an virtuellen Prozessoren (max_procs) ist ebenfalls 2.
Alle physikalischen Prozessoren die nicht als dedizierte Prozessoren verwendet werden, sind automatisch Shared Prozessoren und bilden den sogenannten Physical Shared Prozessor Pool. In Bild 5.4 sind 2 Prozessoren (blau) dedicated Prozessoren und die restlichen 8 Prozessoren (rot) sind damit Shared Prozessoren. Die virtuellen Prozessoren von Shared Prozessor LPARs bekommen ihr Entitlement aus dem Pool der Shared Prozessoren zugewiesen. Dabei muss nicht notwendigerweise in jedem 10ms Zeitintervall der gleiche physikalische Prozessor zugewiesen werden, die Zuordnung kann auch wechseln, wenn die Ressource-Verteilung durch den Hypervisor dies notwendig macht. Die beiden virtuellen Prozessoren der gezeigten Shared Prozessor LPAR können 2 verschiedenen physikalischen Prozessoren in einem Zeitintervall zugewiesen werden, es ist aber durchaus auch möglich das beiden virtuellen Prozessoren der gleiche physikalische Prozessor zugewiesen wird (natürlich nicht zur gleichen Zeit). Die Zuordnung von virtuellen Prozessoren zu physikalischen Prozessoren ist also nicht fest, sondern kann sich dynamisch je nach Erfordernissen ändern.
Das gewünschte Entitlement (Entitled Capacity) kann beim Erzeugen einer LPAR über das Attribut desired_proc_units angegeben werden. Pro virtuellem Prozessor müssen mindestens 0.05 Processing Units konfiguriert werden (bei POWER7 oder älter 0.10 Processing Units). Bei 2 virtuellen Prozessoren (desired_procs=2) müssen damit für desired_proc_units mindestens 2 * 0.05 = 0.10 Processing Units angegeben werden. Auch beim Entitlement können ein minimaler Wert (min_proc_units) und ein maximaler Wert (max_proc_units) angegeben werden. Der Wert von min_proc_units bestimmt die minimal benötigten Processing Units um eine LPAR aktivieren zu können. Die Werte von min_proc_units und max_proc_units geben den Bereich an, innerhalb dessen das Entitlement zur Laufzeit einer LPAR dynamisch geändert werden kann. Der Wert von min_proc_units muss kleiner oder gleich dem Wert desired_proc_units sein, welcher wiederum kleiner oder gleich dem Wert max_proc_units sein muss:
min_proc_units <= desired_proc_units <= max_proc_units
Das folgende Beispiel demonstriert, wie diese Attribute beim Anlegen einer neuen LPAR angegeben werden können:
$ lpar create -m ms02 lpar11 desired_procs=2 max_procs=4 desired_proc_units=0.8 max_proc_units=1.6
.
> lpar11
$
Die LPAR lpar11 wurde mit 2 gewünschten virtuellen Prozessoren und maximal 4 virtuellen Prozessoren angelegt. Das gewünschte Entitlement (desired_proc_units) ist 0.8 Processing Units und als Maximum sind 1.6 Processing Units angegeben. Die nicht explizit angegebenen Attribute min_procs und min_proc_units werden vom LPAR-Tool automatisch mit Werten belegt. Im Profil standard lassen sich alle Attribute nachschauen:
$ lpar -p standard lsproc lpar11
PROC PROCS PROC_UNITS UNCAP PROC
LPAR_NAME MODE MIN DESIRED MAX MIN DESIRED MAX SHARING_MODE WEIGHT POOL
lpar11 shared 1 2 4 0.1 0.8 1.6 uncap 100 DefaultPool
$
Die 0.8 Processing Units werden dabei nach Möglichkeit auf 2 physikalische Prozessoren aufgeteilt, die LPAR bekommt dabei in jedem 10ms Zeitintervall 4ms (entspricht 0.4 Processing Units) von beiden physikalischen Prozessoren zugeteilt. Die Zuteilung kann dabei wie in Bild 5.5 gezeigt gleichzeitig auf beide physikalische Prozessoren erfolgen, es ist aber auch möglich das die Zuteilung zu unterschiedlichen Zeitpunkten stattfindet, z.B. auf dem ersten physikalischen Prozessor erfolgt die Zuteilung sofort am Anfang des 10ms Zeitintervalls und auf dem zweiten physikalischen Prozessor erst einige Millisekunden später. Prinzipiell kann dies auch in jedem 10ms Zeitintervall unterschiedlich sein. Es ist lediglich garantiert das die LPAR ihr Entitlement von 0.8 Processing Units in jedem 10ms Zeitintervall bekommt.
Sollten keine 2 physikalischen Prozessoren verfügbar sein, wird beiden virtuellen Prozessoren der gleiche physikalische Prozessor zugeordnet. Beide virtuellen Prozessoren bekommen dann eine Zuteilung von jeweils 4ms des gleichen physikalischen Prozessors, natürlich nacheinander. Das sollte aber für eine gute Performance vermieden werden.
Das maximal mögliche Entitlement sind 1.0 Processing Units pro virtuellem Prozessor! Zusammen mit der Bedingung das pro virtuellem Prozessor ein Entitlement von mindestens 0.05 konfiguriert werden muß, erlaubt dies noch einen weitern Bereich von möglichen Werten. In der nachfolgenden Tabelle ist bei vorgegebener Anzahl von virtuellen Prozessoren der erlaubte Bereich des Entitlements aufgelistet:
Wieviele Konfiguration-Möglichkeiten es gibt, lässt sich noch besser sehen, wenn man das Entitlement vorgibt und sich die minimal und maximale mögliche Anzahl von virtuellen Prozessoren anschaut, die mit dem Entitlement möglich sind:
Ein Entitlement von 0.40 beispielsweise, kann mit 1, 2 oder bis zu 8 virtuellen Prozessoren realisiert werden.
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.