Welche Größe hat der interne Log bei JFS2

inline log size

Eine triviale Frage über die wir kürzlich gestolpert sind:

Wie groß ist denn der interne JFS2 Log aktuell?

Die Größe des internen JFS2 Logs muss die folgenden beiden Bedingungen erfüllen:

    1. Der Log kann nicht größer als 10% der Dateisystem-Größe sein.
    2. Die maximale Größe kann 2047 MB nicht überschreiten.

Beim Anlegen eines JFS2 Dateisystems mit internem Log, wenn keine Log-Größe (-a logsize=Value) angegeben wird, werden standardmäßig 0.4% der Dateisystem-Größe verwendet. Der Wert 0.4% ist in der Manual Page zu crfs dokumentiert.

Aber, wie groß ist denn der interne JFS2 Log gerade?

Diese Information liefert das Kommando dumpfs. Es erwartet als Argument entweder den Mount-Punkt eines JFS2 Dateisystems oder die Geräte-Datei des unterliegenden Logical Volumes. Das Kommando listet den Superblock, sowie eine Reihe weiterer Verwaltungs-Informationen auf. Die Ausgabe kann bei größeren Dateisystemen sehr lang sein. Da wir nur an dem JFS2 Log interessiert sind, empfiehlt es sich die Ausgabe durch das Kommando grep zu filtern:

# dumpfs /data | grep -i log
aggregate block size    4096            log2 of aggregate block size    12
LVM I/O Transfer size   512             log2 of LVM transfer  size      9
log2 of block size/transfer size        3
Aggregate attributes    J2_GROUPCOMMIT J2_INLINELOG
log device      0x8000002700000001 log serial number    0x26
Inline Log: 541065216 (132096); 1024
fsck Service Log number of blocks: 50
Extendfs Inline Log Working Space: 541065216 (132096); 1024
#

Der letzte Wert in der Zeile „Inline Log:“ gibt die Größe des internen Logs in Blöcken an. Die Blockgröße des Dateisystems findet man in der Zeile „aggregate block size“. In unserem Falle hat der interne Log eine Größe von 1024 Blöcken, zu jeweils 4096 Bytes. Dies ergibt eine Größe von 4 MB (1024 * 4 KB).

Für den Fall das ein externer Log verwendet wird, sieht die Ausgabe wie folgt aus:

# dumpfs / | grep -i log
aggregate block size    4096            log2 of aggregate block size    12
LVM I/O Transfer size   512             log2 of LVM transfer  size      9
log2 of block size/transfer size        3
log device      0x8000000a00000003 log serial number    0xb
Inline Log: 0 (0); 0
fsck Service Log number of blocks: 50
Extendfs Inline Log Working Space: 0 (0); 0
#

Der interne Log hat die Größe 0 Blöcke.

Allerdings ist dies nicht die einfachste Möglichkeit. Chris Gibson weist auf die Option „-q“ des Kommando lsfs hin, welche für JFS und JFS2 Dateisysteme zusätzliche Informationen anzeigt:

# lsfs -q /filesystem
Name            Nodename   Mount Pt               VFS   Size    Options    Auto Accounting
/dev/fslv01     --         /filesystem            jfs2  1048576 --         no   no
  (lv size: 1048576, fs size: 1048576, block size: 4096, sparse files: yes, inline log: yes, inline log size: 4, EAformat: v1, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no)
#

Die Größe des Inline Logs wird dort direkt in MB angegeben (inline log size: 4).

Die Größe des internen JFS2 Log festzustellen ist also mit dem richtigen Kommando (dumpfs lsfs) kein Problem!

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
$

YUM mit NIMHTTP

Ab AIX 7.2 unterstützt NIM die Verwendung von  HTTP. Hierzu gibt es den neuen NIM-Service Handler nimhttp (Port 4901). Dies bietet die Möglichkeit YUM Repositories auf einem NIM-Server mit Hilfe dieses NIM-Service Handlers zur Verfügung zu stellen. Die Repositories müssen hierzu unterhalb des Document-Root (standardmäßig /export/nim) abgespeichert werden. Der Zugriff von einem AIX-Client aus kann dann über HTTP erfolgen.

Die Repositories müssen dazu auf dem AIX-Client unter /opt/freeware/etc/yum/yum.conf oder /opt/freeware/etc/yum/repos.d konfiguriert werden. Alle verfügbaren YUM Operationen werden auf diesem Wege unterstützt.

Wird auf dem NIM-Server ohnehin nimhttp genutzt, entsteht hierdurch kein zusätzlicher Aufwand.

Im Folgenden ist die Konfiguration für die Verwendung von YUM mit nimhttp gezeigt.

Voraussetzung ist zunächst das der NIM-Service Handler nimhttp auf dem NIM-Server aktiv ist:

aixnim # lssrc -s nimhttp
Subsystem         Group            PID          Status
 nimhttp                           19136996     active
aixnim #

Sollte nimhttp noch nicht aktiviert worden sein, kann dies im einfachsten Fall mit Hilfe des Kommandos nimconfig auf dem NIM-Server nachgeholt werden:

aixnim # nimconfig -h
0513-077 Subsystem has been changed.
0513-059 The nimhttp Subsystem has been started. Subsystem PID is 19136996.
aixnim #

Hinweis: Die Konfiguration von nimhttp wird an anderer Stelle gezeigt.

Für Testzwecke legen wir unter /export/nim (Document-Root) eine kleine Text-Datei auf dem NIM-Server an:

aixnim # echo "testfile for nimhttp" >/export/nim/testfile
aixnim #

Als nächstes überprüfen wir auf dem NIM-Client die Funktionalität indem wir mit dem NIM-Client Kommando nimhttp die angelegte Test-Datei vom NIM-Server herunterladen:

aix01 # nimhttp -f testfile -o dest=/tmp -v
nimhttp: (source)       testfile
nimhttp: (dest_dir)     /tmp
nimhttp: (verbose)      debug
nimhttp: (master_ip)    aixnim
nimhttp: (master_port)  4901

sending to master...
size= 46
pull_request= "GET /testfile HTTP/1.1
Connection: close

"
Writing 21 bytes of data to /tmp/testfile
Total size of datalen is 21. Content_length size is 21.
aix01 #

(Die Option ‚-v‘ sorgt für den gezeigten Debugging-Output.)

Die Testdatei wurde unter /tmp/testfile abgespeichert.

Ein weiterer Test mit dem Kommando curl (verfügbar über die AIX-Toolbox) zeigt ebenfalls das nimhttp erfolgreich für den Download von Daten verwendet werden kann:

aix01 # curl http://aixnim:4901/testfile
testfile for nimhttp
aix01 #

Die Verwendung von nimhttp für den Zugriff auf YUM-Repositories sollte also prinzipiell möglich sein.

Wir haben Kopien der von IBM bereitgestellten Repositories der AIX-Toolbox auf unserem NIM-Server in den folgenden Verzeichnissen abgelegt:

/export/nim/aixtoolbox/RPMS/noarch          AIX_Toolbox_noach (AIX noarch repository)

/export/nim/aixtoolbox/RPMS/ppc               AIX_Toolbox (AIX generic repository)

/export/nim/aixtoolbox/RPMS/ppc-7.1         AIX_Toolbox_71 (AIX 7.1 specific repository)

/export/nim/aixtoolbox/RPMS/ppc-7.2         AIX_Toolbox_72 (AIX 7.2 specific repository)

Damit ein AIX Client System auf diese Repositories zugreifen kann, müssen diese in der YUM Konfiguration hinterlegt sein. Wir haben der Einfachheit halber die Repositories in die Konfigurations-Datei /opt/freeware/etc/yum/yum.conf eingetragen:

aix01 # vi /opt/freeware/etc/yum/yum.conf
[main]
cachedir=/var/cache/yum
keepcache=1
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1

[AIX_Toolbox]
name=AIX generic repository
baseurl=http://aixnim:4901/aixtoolbox/RPMS/ppc/
enabled=1
gpgcheck=0

[AIX_Toolbox_noarch]
name=AIX noarch repository
baseurl=http://aixnim:4901/aixtoolbox/RPMS/noarch/
enabled=1
gpgcheck=0

[AIX_Toolbox_72]
name=AIX 7.2 specific repository
baseurl=http://aixnim:4901/aixtoolbox/RPMS/ppc-7.2/
enabled=1
gpgcheck=0

aix01 #

Alternativ kann für jede Repository auch ein eigenes repoid-File unter /opt/freeware/etc/yum/repos.d angelegt werden.

Der entscheidende Eintrag ist jeweils das Attribut baseurl. Hier wird als URL http verwendet. Dem Hostnamen des NIM-Servers wird mit Doppelpunkt getrennt die Port-Nummer von nimhttp (Port 4901) mitgegeben. Der Pfad ist dann relativ zu /export/nim (Document-Root) auf dem NIM-Server.

Ein Auflisten der verfügbaren YUM-Repositories mit dem Kommando yum zeigt die erwarteten Repositories:

aix01 # yum repolist
repo id                                     repo name                                             status
AIX_Toolbox                                 AIX generic repository                                2740
AIX_Toolbox_72                              AIX 7.2 specific repository                            417
AIX_Toolbox_noarch                          AIX noarch repository                                  301
repolist: 3458
aix01 #

Um zu demonstrieren das auch das Installieren von RPMs auf diesem Wege mit nimhttp möglich ist, zeigen wir die Installation von wget:

aix01 # yum install wget
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package wget.ppc 0:1.21.1-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================
Package              Arch                Version                     Repository                   Size
========================================================================================================
Installing:
wget                 ppc                 1.21.1-1                    AIX_Toolbox                 703 k

Transaction Summary
========================================================================================================
Install       1 Package

Total size: 703 k
Installed size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : wget-1.21.1-1.ppc                                                                    1/1
From wget-1.21.1 onwards, symbolic link of wget in /usr/bin is removed.
The binary is shipped in /opt/freeware/bin. Please use absolute path or
add /opt/freeware/bin in PATH environment variable to use the binary.

Installed:
  wget.ppc 0:1.21.1-1                                                                                  

Complete!

aix01 #

Das AIX-System muss nicht zwingend ein NIM-Client sein, da YUM nicht auf NIM zurückgreift. YUM verwendet lediglich den vom NIM-Master bereitgestellten http-Server. Die AIX-Version spielt ebenfalls keine Rolle, der AIX-Client kann unter AIX 7.1 oder AIX 7.2 laufen.

Hinweis: Für AIX 7.3 wird anstelle von YUM der Dandified YUM (DNF) verwendet.

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.

Hinzufügen von logischen SR-IOV Ports

SR-IOV Ethernet port with internal switch and 3 logical ports.

Damit eine PowerVM LPAR eine virtuelle Funktion eines SR-IOV Adapters benutzen kann, muß für die LPAR ein sogenannter logischer Port erzeugt werden. Welche logischen Ports es schon gibt, lässt sich mit dem Kommando „ms lssriov“ mit der Option „-l“ (logical port) anzeigen:

$ ms lssriov -l ms03
LOCATION_CODE  ADAPTER  PPORT  LPORT  LPAR  CAPACITY  CURR_MAC_ADDR  CLIENTS
$

Da die SR-IOV Adapter gerade erst auf Shared umgestellt wurden, gibt es natürlich bisher noch keine logischen Ports. Um einer LPAR einen logischen SR-IOV Port hinzuzufügen, wird das Kommando „lpar addsriov“ (add SR-IOV logical port) verwendet. Es muß neben der LPAR die Adapter-ID und die Port-ID des physikalischen Ports angegeben werden. Alternativ kann aber auch ein eindeutiger Suffix des Physical Location Codes des physikalischen Port angegeben werden:

$ lpar addsriov aix22 P1-C11-T1
$

Das Erzeugen kann einige wenige Sekunden dauern. Eine kurze Überprüfung zeigt, das tatsächlich ein logischer Port angelegt wurde:

$ ms lssriov -l ms03
LOCATION_CODE                   ADAPTER  PPORT  LPORT     LPAR   CAPACITY  CURR_MAC_ADDR  CLIENTS
U78AA.001.VYRGU0Q-P1-C11-T1-S1  1        0      27004001  aix22  2.0       a1b586737e00   -
$

Ähnlich wie bei einem Managed System für virtuelles Ethernet ist auch auf den SR-IOV Adaptern für jeden physikalischen Ethernet Port ein interner Switch implementiert, siehe Bild oben. Jedem logischen Port ist dabei eine der virtuellen Funktionen zugeordnet. Die zugehörigen LPARs greifen auf die logischen Ports über den PCI Express Bus (PCIe-Switch) direkt zu.

Eine LPAR kann ohne weiteres mehrere logischen SR-IOV Ports besitzen. Mit dem Kommando „lpar lssriov“ (list SR-IOV logical ports) lassen sich alle logischen Ports einer LPAR anzeigen:

$ lpar lssriov aix22
LPORT     REQ  ADAPTER  PPORT  CONFIG_ID  CAPACITY  MAX_CAPACITY  PVID  VLANS  CURR_MAC_ADDR  CLIENTS
27004001  Yes  1        0      0          2.0       100.0         0     all    a1b586737e00   -
$

Es gibt eine ganze Reihe von Attributen die für einen logischen Port gleich beim Anlegen angegeben werden können. Unter Anderem können die folgenden Eigenschaften konfiguriert werden:

    • capacity – die garantierte Kapazität für den logischen Port.
    • port_vlan_id – die VLAN-ID für nicht getaggte Pakete oder 0 um VLAN-Tagging auszuschalten.
    • promisc_mode – promiscous Mode ein- oder ausschalten.

Die vollständige List der Attribute und ihre möglichen Werte kann man der Online Hilfe („lpar help addsriov“) entnehmen.

Als Beispiel fügen wir der LPAR aix22 einen weiteren logischen Port mit Port VLAN-ID 55 und einer Kapazität von 20% hinzu:

$ lpar addsriov aix22 P1-C4-T2 port_vlan_id=55 capacity=20
$

Der erzeugte logische Port bekommt damit einen garantierten Anteil von 20% an der Bandbreite des physikalischen Ports P1-C4-T2! Die LPAR hat damit jetzt 2 logische SR-IOV Ports:

$ lpar lssriov aix22
LPORT     REQ  ADAPTER  PPORT  CONFIG_ID  CAPACITY  MAX_CAPACITY  PVID  VLANS  CURR_MAC_ADDR  CLIENTS
27004001  Yes  1        0      0          2.0       100.0         0     all    a1b586737e00   -
2700c003  Yes  3        2      1          20.0      100.0         55    all    a1b586737e01   -
$

Nachdem die logischen Ports mittels PowerVM Hypervisor der LPAR hinzugefügt wurden, erscheinen diese im Zustand Defined. Die logischen Ports tauchen unter AIX als ent-Devices auf, wie alle anderen Ethernet Adapter auch!

aix22 # lsdev -l ent\*
ent0 Available       Virtual I/O Ethernet Adapter (l-lan)
ent1 Defined   00-00 PCIe2 10GbE SFP+ SR 4-port Converged Network Adapter VF (df1028e214100f04)
ent2 Defined   01-00 PCIe2 100/1000 Base-TX 4-port Converged Network Adapter VF (df1028e214103c04)
aix22 #

Nach einem Lauf des Config-Managers sind die neuen ent-Devices im Zustand Available und können genau so benutzt werden, wie alle anderen Ethernet Adapter.

7.6. SR-IOV

7.6.1. Aktivieren des Shared Modes

7.6.2. Konfiguration der physikalischen SR-IOV Ports

7.6.3. Hinzufügen von logischen SR-IOV Ports

7.6.4. Ändern eines logischen SR-IOV Ports

7.6.5. Wegnehmen von logischen SR-IOV Ports

7.6.6. SR-IOV Adapter von Shared zurück auf Dedicated setzen

Hinzufügen eines virtuellen Ethernet Adapters

Delivery of tagged packets, here for the VLAN 200.

Soll in einer PowerVM Umgebung einer aktiven LPAR ein virtueller Ethernet Adapter hinzugefügt werden, muß die LPAR eine aktive RMC-Verbindung zu einer HMC haben. Dies setzt einen aktiven Ethernet Adapter (physikalisch oder virtuell) voraus. Für den virtuellen Ethernet Adapter wird ein freier virtueller Slot benötigt.

$ lpar lsvslot aix22
SLOT  REQ  ADAPTER_TYPE   STATE  DATA
0     Yes  serial/server  1      remote: (any)/any connect_status=unavailable hmc=1
1     Yes  serial/server  1      remote: (any)/any connect_status=unavailable hmc=1
5     No   eth            1      PVID=100 VLANS= ETHERNET0 1DC8DB485D1E
10    No   fc/client      1      remote: ms03-vio1(1)/5 c05076030aba0002,c05076030aba0003
20    No   fc/client      1      remote: ms03-vio2(2)/4 c05076030aba0000,c05076030aba0001
$

Der virtuelle Slot 6 ist bei der LPAR aix22 noch unbenutzt. Das Hinzufügen eines virtuellen Ethernet Adapters kann mit dem Kommando „lpar addeth“ durchgeführt werden. Es muß mindestens die gewünschte virtuelle Slot-Nummer für den Adapter und die gewünschte Port-VLAN-ID angegeben werden:

$ lpar addeth aix22 6 900
$

Im Beispiel wurde ein virtueller Ethernet Adapter für aix22 mit der Port-VLAN-ID 900 im Slot 6 angelegt. Spielt die Slot-Nummer keine Rolle, dann kann anstelle einer Nummer auch das Schlüsselwort auto angegeben werden, das LPAR-Tool vergibt dann automatisch eine freie Slot-Nummer. Der virtuelle Adapter steht sofort zur Verfügung, muß aber erst noch dem Betriebssystem bekannt gemacht werden. Wie das genau geschieht, hängt vom verwendeten Betriebssystem ab. Im Falle von AIX gibt es hierzu das Kommando cfgmgr.

Nachdem der virtuelle Ethernet Adapter hinzugefügt wurde und bevor ein Lauf von cfgmgr gestartet wird, ist dem AIX Betriebssystem der LPAR aix22 nur der virtuelle Ethernet Adapter ent0 bekannt:

aix22 # lscfg -l ent*
  ent0             U9009.22A.8991971-V30-C5-T1  Virtual I/O Ethernet Adapter (l-lan)
aix22 #

Nach einem Lauf von cfgmgr erscheint dann der neu hinzugefügte virtuelle Ethernet Adapter als ent1:

aix22 # cfgmgr
aix22 # lscfg -l ent*
  ent0             U9009.22A.8991971-V30-C5-T1  Virtual I/O Ethernet Adapter (l-lan)
  ent1             U9009.22A.8991971-V30-C6-T1  Virtual I/O Ethernet Adapter (l-lan)
aix22 #

Hinweis: Unter AIX ist anhand des Gerätenamens für einen Ethernet Adapter nicht der Typ erkennbar. Unabhängig davon, ob ein Ethernet Adapter physikalisch oder virtuell oder eine Virtual Function eines SR-IOV Adapters ist, wird immer der Gerätename ent mit einer aufsteigenden Instanz-Nummer verwendet.

Soll ein IEEE 802.1q kompatibler virtueller Ethernet Adapter mit zusätzlichen VLAN-IDs angelegt werden, muß die Option „-i“ (IEEE 802.1q compatible adapter) verwendet werden. Alternativ kann aber auch das Attribut ieee_virtual_eth=1 angegeben werden. Die zusätzlichen VLAN-IDs werden als kommaseparierte Liste angegeben:

$ lpar addeth -i aix22 7 900 100,200,300
$

Die Port-VLAN-ID ist die 900, und die zusätzlichen VLAN-IDs sind 100, 200 und 300.

Hat eine LPAR keine aktive RMC-Verbindung oder ist nicht aktiv, dann kann ein virtueller Ethernet Adapter nur einem der Profile der LPAR hinzugefügt werden. Dies ist z.B. immer der Fall, wenn die LPAR gerade neu angelegt wurde und noch nicht installiert ist.

In diesem Fall muß bei den gezeigten Kommandos lediglich die Option „-p“ mit einem Profil-Namen verwendet werden. Welche Profile eine LPAR besitzt kann mittels „lpar lsprof“ (list profiles) einfach herausgefunden werden:

$ lpar lsprof aix22
NAME                      MEM_MODE  MEM   PROC_MODE  PROCS  PROC_COMPAT
standard                  ded       7168  ded        2      default
last*valid*configuration  ded       7168  ded        2      default
$

(Im Profil mit dem Namen last*valid*configuration ist die letzte aktive Konfiguration hinterlegt.)

Die im Profil standard definierten virtuellen Adapter lassen sich dann unter Angabe des Profil-Namens mit „lpar lsvslot“ anzeigen:

$ lpar -p standard lsvslot aix22
SLOT  REQ  ADAPTER_TYPE   DATA
0     Yes  serial/server  remote: (any)/any connect_status= hmc=1
1     Yes  serial/server  remote: (any)/any connect_status= hmc=1
5     No   eth            PVID=100 VLANS= ETHERNET0 
6     No   eth            PVID=900 VLANS= ETHERNET0 
7     No   eth            IEEE PVID=900 VLANS=100,200,300 ETHERNET0 
10    No   fc/client      remote: ms03-vio1(1)/5 c05076030aba0002,c05076030aba0003
20    No   fc/client      remote: ms03-vio2(2)/4 c05076030aba0000,c05076030aba0001
$

Beim Hinzufügen des Adapters muß lediglich der entsprechende Profil-Name angegeben werden, ansonsten sieht das Kommando genauso aus, wie oben gezeigt:

$ lpar -p standard addeth -i aix22 8 950 150,250
$

Um den neuen Adapter in Slot 8 verfügbar zu machen, muß die LPAR unter Angabe des Profil-Namens standard neu aktiviert werden.

7.3. Virtual Ethernet

7.3.1. VLANs und VLAN-Tagging

7.3.2. Hinzufügen eines virtuellen Ethernet Adapters

7.3.3. Virtuelle Ethernet Switches

7.3.4. Virtual Ethernet Bridge Mode (VEB)

7.3.5. Virtual Ethernet Port Aggregator Mode (VEPA)

7.3.6. Virtuelle Netzwerke

7.3.7. Einem Adapter VLANs hinzufügen/wegnehmen

7.3.8. Ändern von Attributen eines virtuellen Ethernet Adapters

7.3.9. Wegnehmen eines virtuellen Ethernet Adapters