LPAR-Tool: Konsole

Console with LPAR-Tool

Mit dem LPAR-Tool kann jederzeit eine Konsole für eine LPAR geöffnet werden:

$ lpar console lpar01
Open in progress
Open completed.
PowerPC Firmware
SMS 1.7 (c) Copyright IBM Corp. 2000,2008 All rights reserved.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Main Menu
1. Select Language
2. Setup Remote IPL (Initial Program Load)
3. Change SCSI Settings
4. Select Console
5. Select Boot Options
…

Um eine Konsolensitzung zu beenden wird die Escape-Sequence „~.“ verwendet.

Einige Kommandos des LPAR-Tools unterstützen das Öffnen einer Konsole über die Option „-c“ (console):

    • Aktivieren einer LPAR mit „lpar activate -c„.
    • Herunterfahren einer LPAR mit „lpar shutdown -c„.
    • Herunterfahren des Betriebssystems mit „lpar osshutdown -c„.
    • Initiieren eines Dumps einer LPAR mit „lpar dumprestart -c„.

Eine Präsentation zu dem Thema findet sich hier: Konsole mit dem LPAR-Tool

NTP-Konfiguration auf HMC mit LPAR-Tool

NTP-Konfiguration HMC

Den aktuellen Status von NTP auf einer HMC kann man sich dann mittels „hmc lsntp“ anzeigen lassen:

$ hmc lsntp
NAME   XNTP     XNTPSTATUS    XNTPSERVER
hmc01  disable  -             -
hmc02  enable   synchronized  192.168.189.77,192.168.189.78
hmc03  enable   synchronized  192.168.189.77,192.168.189.78
$

Über das Kommando „hmc addntpserver“ kann der NTP-Konfiguration einer HMC ein weiterer NTP-Server hinzugefügt werden:

$ hmc addntpserver hmc01 192.168.189.77
$ hmc addntpserver hmc01 192.168.189.78
$

Eine Kontrolle mit „hmc lsntp“ zeigt, das nun zwei NTP-Server konfiguriert sind, NTP aber nach wie vor nicht aktiviert ist:

$ hmc lsntp hmc01
NAME   XNTP     XNTPSTATUS  XNTPSERVER
hmc01  disable  -           192.168.189.77,192.168.189.78
$

NTP kann nun mit dem Kommando „hmc enablentp“ aktiviert werden:

$ hmc enablentp hmc01
$

Die erste Synchronisierung kann eine Weile dauern:

$ hmc lsntp hmc01
NAME   XNTP    XNTPSTATUS      XNTPSERVER
hmc01  enable  unsynchronized  192.168.189.77,192.168.189.78
$

Die Zeit auf der HMC ist unmittelbar nach dem Aktivieren von NTP noch nicht synchronisiert (XNTPSTATUS: unsynchronized).

Einen detaillierten Status für jeden NTP-Server bekommt man durch Verwendung der Option „-a“ (all NTP-Servers):

$ hmc lsntp –a hmc01
NAME    SERVER         STATE          POLL_FREQ_SECONDS  SECONDS_SINCE_LAST_POLL
hmc01  192.168.189.77  not connected  64                 0
hmc01  192.168.189.78  not connected  64                 0
$

Sobald eine Synchronisierung mit einem der NTP-Server erreicht ist, ist der Gesamt-Status synchronized:

$ hmc lsntp -a hmc01
NAME   SERVER          STATE         POLL_FREQ_SECONDS  SECONDS_SINCE_LAST_POLL
hmc01  192.168.189.77  synchronized  64                 40
hmc01  192.168.189.78  available     64                 35
$

Eine ausführlichere Beschreibung findet sich hier: NTP-Konfiguration auf der HMC

Das LPAR-Tool kann zum Testen hier heruntergeladen werden: Download

LPAR-Tool 1.7.0.1 ist ab sofort verfügbar

Ab sofort ist die Version 1.7.0.1 des LPAR-Tools in unserem Download-Bereich verfügbar.

Die neue Version unterstützt unter anderem die folgenden neuen Features:

    • Installation von IFixes und Updates auf der HMC (hmc help updhmc)
    • System-Firmware Updates (und mehr) von Managed Systems (ms help updatelic)
    • Anzeigen von FLRT Daten mit Online Abfrage bei IBM (hmc help flrt, ms help flrt, lpar help flrt)
    • Konfiguration von NTP auf HMCs (hmc help ntp)

Es stehen Versionen für Linux, AIX und Macos zur Verfügung.

Alle Versionen beinhalten eine Test-Lizenz mit einer Gültigkeit bis 30.09.2022.

Also Downloaden, Installieren und dann Ausprobieren!

IOS-Version als normaler Benutzer anzeigen

Auf einem Virtual-I/O-Server kann man die IOS-Version als Benutzer padmin mit Hilfe des Kommandos ioslevel anzeigen:

padmin> ioslevel
3.1.2.10
padmin>

Als Benutzer root (nach Verwendung von oem_setup_env), lässt sich die IOS-Version wie folgt anzeigen:

# /usr/ios/cli/ioscli ioslevel
3.1.2.10
#

Beide Kommandos funktionieren aber nicht als normaler, nicht privilegierter, Benutzer:

$ ioslevel
ksh: ioslevel: not found.
$ /usr/ios/cli/ioscli ioslevel
Access to run command is not valid.

$

Die IOS-Version ist aber einfach in einer Text-Datei gespeichert und lässt sich als normaler Benutzer ganz einfach mit dem Kommando cat anzeigen:

$ cat /usr/ios/cli/ios.level
3.1.2.10
$

Virtual Network Interface Controller (vNIC)

vNIC adapter with 2 vNIC backing devices and vNIC failover.

Der große Nachteil von SR-IOV, sowie oben beschrieben, besteht darin, das das Verschieben (LPM) von LPARs mit logischen SR-IOV Ports nicht möglich ist. Nach der Einführung von SR-IOV auf Power Systemen gab es eine Reihe von Vorschlägen für Workarounds. Allerdings bedingen alle diese Workarounds zum Einen eine besondere Konfiguration und zum Anderen eine Reihe von Umkonfigurationen die vor und nach einer LPM-Operation durchzuführen sind. Im praktischen Alltag werden dadurch LPM-Operationen aber unnötig verkompliziert.

Mit der Einführung von vNICs können Client-LPARs SR-IOV Adapter benutzen und trotzdem LPM unterstützen. Wie schon bei VSCSI und VFC wird dazu ein Paar von Adaptern benutzt: auf der Client-LPAR wird der sogenannte vNIC Adapter in einem virtuellen Slot verwendet und auf einem Virtual-I/O-Server wird ein zugehöriger vNIC-Server Adapter verwendet. Der logische SR-IOV Port wird dem Virtual-I/O-Server zugeordnet. Der vNIC-Server Adapter, auch als vNIC-Backing-Device bezeichnet, dient dabei als Proxy für den logischen SR-IOV Port. Das Zusammenspiel der verschiedenen Adapter ist in Bild 7.19 dargestellt.

Communication path of vNIC for control information and data.
Bild 7.19: Kommunikationspfad von vNIC für Kontroll-Informationen und Daten.

Um eine gute Performance zu erreichen, werden nur Kontroll-Informationen vom vNIC Adapter der Client-Adapter zum vNIC Server Adapter übertragen, welche von diesem über den zugehörigen logischen SR-IOV Port zum entsprechenden logischen Port (Virtual Function) des SR-IOV Adapters übertragen werden. Die Daten selbst werden zwischen vNIC Client-Adapter und dem logischen Port des SR-IOV Adapters per DMA (Direct Memory Access) mit Hilfe des Hypervisors übertragen. Es findet also insbesondere kein Kopieren der Daten über den Virtual-I/O-Server statt. Der vNIC Adapter auf dem Client ist ein rein virtueller Adapter, daher funktioniert LPM auch problemlos. Der Client besitzt den logischen SR-IOV Port nicht und greift auch nicht selbst über den PCIe Bus (Switch) auf diesen zu.

Shared Ethernet Adapter

SEA with multiple trunking adapters and VLANs

Trotz SR-IOV und vNIC ist Shared Ethernet immer noch die am häufigsten verwendete Virtualisierungslösung, wenn es um die Virtualisierung von Ethernet geht. Dabei implementiert der POWER Hypervisor virtuelle interne IEEE802.1q kompatible Netzwerk-Switches, die im Zusammenspiel mit sogenannten Shared Ethernet Adaptern oder kurz SEA die Anbindung an externe Netzwerke übernehmen. Die Shared Ethernet Adapter werden durch den Virtual-I/O-Server in Software als Layer-2 Bridge implementiert.

Wie in Bild 8.2 gezeigt, kann ein Shared Ethernet Adapter mehrere sogenannte Trunking Adapter besitzen. Der gezeigte SEA hat die 3 Trunking Adapter ent8, ent9 und ent10, welche alle 3 an den virtuellen Switch mit dem Namen ETHMGMT angebunden sind. Alle Trunking Adapter unterstützen im gezeigten Fall VLAN-Tagging. Neben den Port-VLAN-IDs (PVIDs) besitzen die 3 Trunking Adapter noch weitere VLANs über VLAN-Tagging. Neben der Anbindung an den virtuellen Switch über die Trunking Adapter besitzt der SEA noch eine Anbindung an ein externes Netzwerk über den physikalischen Netzwerk-Adapter (ent0). Netzwerk-Pakete von Client-LPARs an externe Systeme werden über einen der Trunking-Adapter zum SEA und dann über den zugehörigen physikalischen Netzwerk-Adapter ins externe Netzwerk weitergeleitet. Netzwerk-Pakete von externen Systemen an Client-LPARs werden vom SEA über den Trunking Adapter mit dem richtigen VLAN an den virtuellen Switch weitergeleitet, welcher die Pakete dann an die Client-LPAR weiterleitet.

SEA with multiple trunking adapters and VLANs
Bild 8.2: SEA mit mehreren Trunking Adaptern und VLANs.

Im einfachsten Fall kann ein SEA aus nur einem Trunking Adapter bestehen. Ein SEA kann bis zu 16 Trunking Adaptern besitzen, wobei jeder der Trunking-Adapter neben der Port-VLAN-ID bis zu 20 weitere VLANs besitzen kann.

Welche SEAs es auf einem Virtual-I/O-Server schon gibt, lässt sich mit Hilfe des Kommandos „vios lssea“ (list SEAs) herausfinden:

$ vios lssea ms05-vio1
                                       TIMES   TIMES    TIMES    BRIDGE 
NAME   HA_MODE  PRIORITY  STATE       PRIMARY  BACKUP  FLIPFLOP  MODE
ent33  Sharing  1         PRIMARY_SH  1        1       0         Partial
ent34  Sharing  1         PRIMARY_SH  1        1       0         Partial
$

Zu jedem SEA werden einige grundlegende Informationen angezeigt, wie z.B. der HA-Mode (siehe später), die Priorität des SEA, sowie Informationen wie häufig der SEA schon Primary bzw. Backup war.

Virtuelle FC-Adapter und NPIV

Physical FC port with Virtual FC and NPIV

Eine Möglichkeit für die Virtualisierung von Storage unter PowerVM ist die Verwendung von virtuellen FC Adaptern. Dabei ist ein virtueller FC-Client Adapter über den POWER Hypervisor mit einem virtuellen FC-Server Adapter auf einem Virtual-I/O-Server verbunden, wie in Bild 7.10 gezeigt. Auf dem Virtual-I/O-Server wird der virtuelle FC-Server Adapter dann mit einem der physikalischen FC-Ports verbunden (Mapping). Jeder der verbundenen virtuellen FC-Server Adapter kann dabei einen eigenen Login in die FC-Fabric durchführen. Jeder virtuelle FC-Server Adapter bekommt dabei eine eigene 24-bit FC-Adresse zugewiesen.

Communication path of the virtual FC client adapter to the SAN LUN.
Bild 7.10: Kommunikationspfad virtueller FC Client Adapter zur SAN-LUN.

Der Vorteil von Virtual FC besteht darin, das jeder virtuelle FC-Client Adapter einen eigenen N_Port besitzt und damit direkt mit dem Storage in der FC-Fabric kommunizieren kann. Die Storage-LUNs können dem virtuellen FC -Client Adapter direkt zugewiesen. Der Virtual-I/O-Server selbst sieht normalerweise die Storage-LUNs der virtuellen FC Clients nicht. Das macht die Administration deutlicher einfacher als bei virtuellem SCSI, wo jede Storage-LUN auf dem Virtual-I/O-Server auf einen virtuellen SCSI Server Adapter gemappt werden muss (siehe nächstes Kapitel).

Bevor ein virtueller FC Adapter angelegt und gemappt wird, sieht die Situation auf einem Virtual-I/O-Server so wie in Bild 7.11 dargestellt aus. Der physikalische FC-Port ist an eine FC-Fabric angeschlossen und konfiguriert daher einen N_Port. Der physikalische FC-Port loggt sich in die Fabric ein (FLOGI) und bekommt die eindeutige N_Port ID 8c8240 zugewiesen. Danach registriert der FC-Port seine WWPN (hier 10:00:00:10:9b:ab:01:02) beim Simple Name Server (SNS) der Fabric (PLOGI). Danach kann der Virtual-I/O-Server über das Gerät fcs0 mit anderen N_Ports in der Fabric kommunizieren.

Physical FC port without virtual FC and NPIV
Bild 7.11: Physikalischer FC-Port ohne Virtual FC und NPIV

N_Port-ID Virtualisierung oder kurz NPIV ist eine Erweiterung des FC-Standards und erlaubt das sich über einen physikalischen FC-Port mehr als ein N_Port in die Fabric einloggen kann. Im Prinzip gab es diese Möglichkeit schon immer, allerdings nur im Zusammenhang mit FC Arbitrated Loop (FC-AL) und Fabrics. Mit NPIV können mehrere Client LPARs einen physikalischen FC-Port gemeinsam verwenden. Jeder Client hat dabei seinen eigenen eindeutigen N_Port.

In Bild 7.12 ist die Situation mit 2 virtuellen FC-Client Adaptern gezeigt. Jeder der Client Adapter hat eine eindeutige WWPN. Diese wird von PowerVM beim Erzeugen des virtuellen FC-Client Adapters zugewiesen (um Live-Partition Mobility unterstützen zu können, werden immer 2 WWPNs zugewiesen, wobei nur eine der beiden WWPNs aktiv ist). Jeder virtuelle FC-Client Adapter benötigt auf einem Virtual-I/O-Server einen Partner Adapter, den virtuellen FC-Server Adapter (oder auch vfchost). Dem virtuellen FC-Server Adapter muß auf dem Virtual-I/O-Server einer der physikalischen FC-Ports zugeordnet werden. Ist die Client-LPAR aktiv, dann loggt sich der virtuelle FC-Server Adapter in die Fabric ein (FDISC) und bekommt eine eindeutige N_Port ID zugewiesen. Im Bild ist das für den blauen Adapter die 8c8268 und für den roten Adapter die 8c8262. Danach registriert der blaue Adapter seine Client-WWPN (hier c0:50:76:07:12:cd:00:16) beim Simple Name Server (SNS) der Fabric (PLOGI). Das gleiche macht der rote Adapter für seine Client-WWPN (hier c0:50:76:07:12:cd:00:09). Damit haben dann beide virtuellen FC-Client Adapter jeweils einen N_Port mit einer eindeutigen 24-bit ID und können damit mit anderen N_Ports in der Fabric kommunizieren.

Physical FC port with Virtual FC and NPIV
Bild 7.12: Physikalischer FC-Port mit Virtual FC und NPIV

Die zu Daten werden natürlich zwischen virtuellem FC-Client Adapter und virtuellem FC-Server Adapter nicht vom Hypervisor kopiert, das würde zuviel Performance kosten. Der Hypervisor gibt lediglich die physikalische Speicheradresse weiter, an der die Daten stehen und der physikalische FC-Port verwendet dann DMA (Direct Memory Access) um auf diese Daten dann zuzugreifen.

Administrieren von Storage Pools in PowerVM

File Storage Pool

Für die schnelle Bereitstellung von Client-LPARs ist die Verwendung von SAN-LUNs mittels NPIV in vielen Fällen nicht geeignet. Die SAN-LUNs müssen auf den externen Storage Systemen zunächst angelegt werden und anschließend muss das Zoning im SAN angepasst werden, damit die neuen SAN-LUNs auch für die WWPNs der Client-LPAR sichtbar sind. Auch die Verwendung von VSCSI für das Mapping der SAN-LUNs auf die Client-LPARs erfordert einigen Aufwand. Jede SAN-LUN wird dabei per VSCSI einem oder mehreren Client-LPARs zugeordnet, was zu einer großen Anzahl von SAN-LUNs auf den Virtual-I/O-Servern führen kann.

Eine Möglichkeit Storage für Client-LPARs schneller bereit zustellen besteht in der Verwendung von Storage Pools auf den Virtual-I/O-Servern. Nachdem ein Storage Pool einmal angelegt ist, kann Storage für Client-LPARs mit nur einem Kommando zur Verfügung gestellt werden. Auf dem Storage Pool werden dabei sogenannte Backing-Devices erzeugt, die per Virtual SCSI den Client-LPARs zugeordnet werden können. Storage für Client-LPAR kann damit per PowerVM von den Virtual-I/O-Servern zur Verfügung gestellt werden. Damit kann z.B. eine Boot-Platte für eine neue Client-LPAR innerhalb von wenigen Sekunden angelegt und sofort benutzt werden.

PowerVM bietet zwei verschiedene Arten von Storage Pools an: lokale Storage Pools und Shared Storage Pools. Ein lokaler Storage Pool, oder auch einfach Storage Pool, wird immer nur von einem Virtual-I/O-Server zur Verfügung gestellt. Jeder Virtual-I/O-Server kann seine eigenen unabhängigen Storage Pools besitzen. Ein Shared Storage Pool hingegen wird von mehreren Virtual-I/O-Servern, die in einem Cluster zusammengefasst sind, zur Verfügung gestellt werden. Der Zugriff auf den Shared Storage Pool ist von jedem der Virtual-I/O-Server der zum Cluster gehört möglich. Shared Storage Pools werden in diesem Kapitel nicht behandelt.

Es gibt zwei Arten von lokalen Storage Pools: Logical Volume Storage Pools und File Storage Pools. Bei einem Logical Volume Storage Pool wird für die Client-LPARs Storage in Form von Logical Volumes zur Verfügung gestellt, beim File Storage Pool in Form von Dateien.

In Bild 8.13 ist ein Logical Volume Storage Pool dargestellt. Der Storage Pool ist in Form einer Volume Group realisiert und bezieht daher seine Storage Kapazität über die zugehörigen Physical Volumes. Um Storage für Client-LPARs bereit zustellen, werden Logical Volumes in dem Storage Pool erzeugt, im Bild die Logical Volumes bd01, bd02 und bd03. Die Logical Volumes werden dabei als Backing-Devices bezeichnet, da sie letztlich als Speicherort für die Daten der Client-LPARs dienen. Die Zuordnung eines Backing-Devices zu einer Client-LPAR, genauer einem vhost-Adapter welcher eins-zu-eins einem virtuellen SCSI-Adapter einer Client-LPAR zugeordnet ist, erfolgt über ein sogenanntes virtuelles Target Device (vtscsi0, vtscsi1 und vtscsi2 im Bild). Das virtuelle Target Device ist ein Kind-Gerät eines der vhost-Adapter und zeigt über das Attribut aix_tdev auf das entsprechende Backing-Device. Beim Mapping wird das virtuelle Target Device unterhalb des vhost-Adapters erzeugt.

Logical Volume Storage Pool
Bild 8.13: Logical Volume Storage Pool

Solange der Storage Pool noch freie Kapazität besitzt, können jederzeit weitere Backing-Devices angelegt und Client-LPARs zugeordnet werden. Die Bereitstellung von Storage für Client-LPAR ist damit sehr flexibel und vor allen Dingen sehr schnell und unterliegt komplett der Kontrolle des PowerVM Administrators.

Neben dem Logical Volume Storage Pool sind auch File Storage Pools unterstützt. In Bild 8.14 ist ein solcher File Storage Pool gezeigt, er ist als Dateisystem implementiert. Das unterliegende Logical Volume liegt in dem Logical Volume Storage Pool mypool. Als Name für das Logical Volume wird der Storage Pool Name verwendet, im Bild filepool. Das Dateisystem wird unterhalb von /var/vio/storagepools/filepool gemountet, wobei die letzte Pfad-Komponente gleich dem Storage Pool Namen ist. Als Backing-Devices werden Dateien verwendet, wobei der Dateiname gleich dem Backing-Device Namen ist. Das Mapping wird weiterhin über virtuelle Target Devices realisiert, im Bild vtscsi3 und vtscsi4. Das Attribut aix_tdev der virtuellen Target Devices zeigt dabei auf die jeweilige Datei im File Storage Pool.

File Storage Pool
Bild 8.14: File Storage Pool

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.