Multiple Shared Prozessor Pools: Entitled Pool-Kapazität

Distribution of processor shares to shared processor pools and LPARs in the default shared processor pool according to EPC or EC.

Eine wichtige Änderung in PowerVM bei Verwendung von Multiple Shared Prozessor Pools betrifft die Verteilung ungenutzter Prozessor-Anteile der LPARs. Ohne Shared Prozessor Pools werden ungenutzte Prozessor-Anteile an alle uncapped LPARs gemäß ihrer Gewichtung aufgeteilt. Sobald Shared Prozessor Pools verwendet werden, erfolgt die Verteilung zwei-stufig. Ungenutzte Prozessor-Anteile werden zuerst auf uncapped LPARs im gleichen Shared Prozessor Pool verteilt. Nur die ungenutzten Prozessor-Anteile, die von keiner anderen LPAR im gleichen Shared Prozessor Pool benötigt werden, werden auf LPARs in anderen Shared Prozessor Pools aufgeteilt.

Jeder Shared Prozessor Pool besitzt eine sogenannte Entitled Pool-Kapazität (Entitled Pool Capacity EPC). Diese setzt sich zusammen aus der Summe der garantierten Entitlements der zugewiesenen LPARs und der reservierten Pool-Kapazität (Reserved Pool Capacity RPC). Die reservierte Pool-Kapazität kann über das Attribut reserved_pool_proc_units des Shared Prozessor Pools konfiguriert werden und hat per Default den Wert 0. So wie bei einer Shared Prozessor LPAR das Entitlement garantiert ist, ist für einen Shared Prozessor Pool die Zuweisung der Entitled Pool-Kapazität garantiert, unabhängig davon, wie diese dann auf die zugehörigen LPARs im Shared Prozessor Pool aufgeteilt wird. In Bild 5.15 sind Reserved, Entitled und Maximum Pool-Kapazitäten für einen Shared Prozessor Pool gezeigt.

Dabei muß für die Pool-Kapazitäten immer folgende Bedingung erfüllt sein:

Reserved Pool Capacity <= Entitled Pool Capacity <= Maximum Pool Capacity

Die Pool-Kapazitäten werden in der Ausgabe von „ms lsprocpool“ immer mit angezeigt:

$ ms lsprocpool ms06
MS_NAME  PROCPOOL     ID  EC_LPARS  RESERVED  PENDING  ENTITLED  MAX
ms06  DefaultPool  0   7.90      -         -        7.90      -
ms06  SharedPool01  1   0.60      0.10      0.10     0.70      1.00
$

In der Spalte EC_LPARS sind die garantierten Entitlements der zugewiesenen LPARs aufaddiert, hier 0.60 für den Pool SharedPool01, in der Spalte RESERVED findet sich die reservierte Pool-Kapazität (0.10 für SharedPool01), in der Spalte ENTITLED dann die Entitled Pool-Kapazität und schließlich in der Spalte MAX die maximale Pool-Kapazität. (Der SharedPool01 ist der Shared Prozessor Pool aus Bild 5.15.)

Wie die Aufteilung von Prozessor-Anteilen in Anwesenheit von mehreren Shared Prozessor Pools funktioniert, ist im Bild oben gezeigt.

Jeder Shared Prozessor Pool bekommt einen Anteil an den Prozessoren (Cores) gemäß seiner Entitled Pool-Kapazität. Shared Prozessor LPARs im Default Shared Prozessor Pool bekommen Prozessor-Anteile gemäß ihrem Entitlement. Die nicht zugewiesenen Prozessor-Anteile werden auf alle LPARs, unabhängig von Shared Prozessor Pools, gemäß ihrer Gewichtung aufgeteilt (das ist in der Graphik nicht gezeigt).

Die jedem Shared Prozessor Pool zugewiesenen Prozessor-Anteile (gemäß Entitled Pool-Kapazität) werden dann innerhalb des Shared Prozessor Pools auf die zugehörigen LPARs gemäß ihrem Entitlement aufgeteilt. D.h. insbesondere das auch jede LPAR in einem Shared Prozessor Pool weiterhin ihr garantiertes Entitlement bekommt!

Verbraucht eine LPAR in einem Shared Prozessor Pool ihr Entitlement nicht, dann werden diese ungenutzten Prozessor-Anteile zunächst innerhalb des Shared Prozessor Pools an andere LPARs verteilt, welche einen Bedarf an zusätzlichen Prozessor-Anteilen haben. Die Verteilung erfolgt dann wie gehabt unter Berücksichtigung der Gewichtung der LPARs. Ungenutzte Prozessor-Anteile werden also innerhalb eines Shared Prozessor Pools sozusagen „recycled“. Sollten auf diesem Wege nicht alle ungenutzten Prozessor-Anteile im Shared Prozessor Pool verbraucht werden, dann werden diese über den Hypervisor an alle (LPARs mit Bedarf an zusätzlichen Prozessor-Anteilen) LPARs aufgeteilt unabhängig vom zugehörigen Shared Prozessor-Pool.

Diese zweistufige Verteilung von Prozessor-Anteilen lässt sich in einem kleinen Versuch sehr gut beobachten. Dazu haben wir bei den 3 LPARs (lpar1, lpar2 und lpar3) das garantierte Entitlement auf 0.8 erhöht:

$ lpar addprocunits lpar1 0.4
$ lpar addprocunits lpar2 0.4
$ lpar addprocunits lpar3 0.4
$

Die Zuordnung zu den Shared Prozessor Pools bleibt weiterhin lpar1 und lpar2 sind dem Shared Prozessor Pool benchmark zugeordnet und die lpar3 bleibt in DefaultPool:

$ lpar -m ms11 lsproc
           PROC         PROCS           PROC_UNITS                     UNCAP   PROC    
LPAR_NAME  MODE    MIN  DESIRED  MAX  MIN  DESIRED  MAX  SHARING_MODE  WEIGHT  POOL
lpar1      shared  1    4        8    0.1  0.8      2.0  uncap         100     benchmark
lpar2      shared  1    4        8    0.1  0.8      2.0  uncap         100     benchmark
lpar3      shared  1    4        8    0.1  0.8      2.0  uncap         100     DefaultPool
ms11-vio1  ded     1    7        8    -    -        -    keep_idle_procs    -       -
ms11-vio2  ded     1    6        8    -    -        -    keep_idle_procs    -       -
$

Im Shared Prozessor Pool benchmark ergibt sich dann die Entitled Pool-Kapazität von 2 * 0.8 + 0.0 = 1.6 (die reservierte Pool-Kapazität ist 0.0). Die Entitled Pool-Kapazität des Default Shared Prozessor Pool mit nur einer LPAR ist 0.8.

$ ms lsprocpool ms11
MS_NAME  PROCPOOL     ID  EC_LPARS  RESERVED  PENDING  ENTITLED  MAX
ms11  DefaultPool  0   0.80      -         -        0.80      -
ms11  testpool     1   0.00      0.00      0.00     0.00      2.00
ms11  benchmark    2   1.60      0.00      0.00     1.60      2.00
$

Wir starten wieder den Benchmark, dieses Mal auf lpar1 (Shared Prozessor Pool benchmark) und lpar3 (Shared Prozessor Pool DefaultPool) parallel. Auf lpar2 (Shared Prozessor Pool benchmark) wird keine Auslastung produziert, die LPAR liegt während des Benchmarks bei einer Auslastung von ca 0.000.01. Damit steht die garantierte Entitled Pool-Kapazität von 1.6 exklusiv für lpar1 zur Verfügung! Das garantierte Entitlement von lpar2 im Default Pool ist nur 0.8. Von den 3 physikalischen Prozessoren (Cores) im Physical Shared Prozessor Pool bleibt damit nur noch ein Entitlement von 3.0 – 1.6 – 0.8 = 0.6, welches auf LPARs mit zusätzlichem Bedarf an Prozessor-Anteilen verteilt werden kann. Da lpar1 und lpar3 beide die gleiche Gewichtung (uncap_weight=100) haben, bekommen beide jeweils zusätzlich 0.3 Processing Units. Das macht dann für lpar1: 1.6 + 0.3 = 1.9. Und für lpar3: 0.8 + 0.3 = 1.1. In den Graphiken zur Prozessor-Auslastung (Bild 5.17) ist dies sehr schön zu sehen. Kurze Zeit nach dem Start des Benchmarks auf lpar1 werden dort ca 1.9 physikalische Prozessoren (Cores) verbraucht, bei lpar3 sind es ca 1.1. Aufgrund der größeren Prozessor-Anteile wird der Benchmark auf lpar1 schneller fertig, womit die Prozessor-Auslastung dort herunter geht. Damit steht aber dann lpar3 mehr an Prozessor-Anteilen zur Verfügung und es werden von lpar3 dann am Ende in der Spitze fast die 3 verfügbaren Prozessoren komplett vereinnahmt.

Ohne zusätzliche Shared Prozessor Pools profitieren alle uncapped LPARs von ungenutzten Prozessor-Anteilen die eine LPAR nicht verbraucht. Da potentiell alle LPARs Teile dieser ungenutzten Prozessor-Anteile bekommen, ist der Anteil für eine individuelle LPAR nicht so groß. Werden zusätzliche Shared Prozessor Pools verwendet, dann profitieren in erster Linie uncapped LPARs im gleichen Shared Prozessor Pool von ungenutzten Prozessor-Anteilen einer LPAR. Das sind weniger LPARs und damit ist der Anteil an zusätzlicher Prozessor-Kapazität pro LPAR auch höher.