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.00 – 0.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.
5.5. Multiple Shared Prozessor Pools
5.5.1. Physical Shared Prozessor Pool
5.5.2. Multiple Shared Prozessor Pools
5.5.3. Konfigurieren eines Shared Prozessor Pools (Maximale Pool-Kapazität)
5.5.4. Zuweisen eines Shared Prozessor Pools
5.5.5. Entitled Pool-Kapazität (EPC)
