Zugriff auf das Ablaufdatum des Update Access Keys von AIX aus

Im Zuge der Einführung von POWER8 Systemen hat IBM auch den „Update Access Key“ eingeführt, der für das Durchführen von Firmware Updates des Managed Systems notwendig ist. Neu ausgelieferte System haben standardmäßig einen Update Access Key der in der Regel nach 3 Jahren abläuft. Danach kann der Update Access Key bei bestehen eines Wartungsvertrages jeweils um ein halbes Jahr verlängert werden (https://www.ibm.com/servers/eserver/ess/index.wss).

Wann der aktuelle Update Access Key abläuft lässt sich natürlich leicht über die HMC herausfinden, GUI oder CLI. Man kann das Ablaufdatum aber auch über das Kommando lscfg von AIX aus anzeigen:

Im Falle von AIX 7.1 sieht dies so aus:

$ lscfg -vpl sysplanar0 | grep -p "System Firmware"
      System Firmware:
...
        Microcode Image.............SV860_138 SV860_103 SV860_138
        Microcode Level.............FW860.42 FW860.30 FW860.42
        Microcode Build Date........20180101 20170628 20180101
        Microcode Entitlement Date..20190825
        Hardware Location Code......U8284.22A.XXXXXXX-Y1
      Physical Location: U8284.22A.XXXXXXX-Y1

Im Falle von AIX 7.2 ist die Ausgabe geringfügig anders:

$ lscfg -vpl sysplanar0 |grep -p "System Firmware"
      System Firmware:
...
        Microcode Image.............SV860_138 SV860_103 SV860_138
        Microcode Level.............FW860.42 FW860.30 FW860.42
        Microcode Build Date........20180101 20170628 20180101
        Update Access Key Exp Date..20190825
        Hardware Location Code......U8284.22A.XXXXXXX-Y1
      Physical Location: U8284.22A.XXXXXXX-Y1

Relevant sind die Zeilen „Microcode Entitlement Date“ bzw. „Update Access Key Exp Date„.

Besonderheiten von NFSv4 Mounts

Viele AIX Administratoren verwenden NFSv4 genauso wie zuvor NFSv3 und NFSv2. Beim Exportieren und Mounten wird die Version 4 angegeben, ansonsten wird alles wie bisher gemacht. Das funktioniert zwar in den meisten Fällen, verhindert aber gleichzeitig die Nutzung einiger interessanter Eigenschaften von NFSv4.

Der erste bedeutende Unterschied zwischen NFSv4 und seinen Vorgängern besteht schon beim Mounten. Bei NFSv2 und NFSv3 wird hierzu ein separates MOUNT-Protokoll verwendet. Soll beispielsweise der folgende NFS-Mount ausgeführt werden:

clientv3 # mount aixnim:/export/data /mnt
clientv3 #

dann wird eine RPC-Anfrage and den rpc.mountd auf dem NFS-Server gesendet, um ein NFS-Filehandle für das Dateisystem/Verzeichnis /export/data zu bekommen. Bei allen NFS-Operationen muß immer ein NFS-Filehandle angegeben werden, welches auf dem NFS-Server eindeutig eine Datei oder Verzeichnis identifiziert. Das allererste Filehandle wird über das MOUNT-Protokoll erfragt.

Im Falle von NFSv4 sieht dies ganz anders aus, es wird kein separates MOUNT-Protokoll benötigt. Anstelle dessen wird ein sogenanntes root-Filehandle verwendet, dieses ist über den NFS-Standard definiert und muß nicht über ein separates Protokoll in Erfahrung gebracht werden. Bei dem folgenden NFSv4-Mount

clientv4 # mount –o vers=4 aixnim:/export/data /mnt
clientv4 #

Startet der Client ein NFS-LOOKUP, wobei er das wohlbekannte (vom NFS-Standard definierte) root-Filehandle angibt, sowie den dazu relativen Pfad „export/data“, dann liefert der NFS-Server das zugehörige Filehandle zurück. Dies läßt sich mit Hilfe von tcpdump leicht verfolgen, was wir aus Platzgründen aber hier nicht getan haben.

Ein für viele Administratoren überraschender (und vielleicht nicht immer verstandener) Nebeneffekt ist, das man mit „showmount –e“ nicht die mit NFSv4 exportierten Filesysteme sehen kann. Das liegt aber einfach daran das es kein MOUNT-Protokoll für NFSv4 gibt. Damit kann man auf dem NFS-Client nicht so ohne weiteres herausfinden welche Filesysteme der NFS-Server für NFSv4 exportiert hat.

clientv4 # showmount -e aixnim
no exported file systems for aixnim
clientv4 #

Das Kommando „showmount –e“ zeigt keine exportierten Filesysteme, obwohl wir oben erfolgreich mittels NFSv4 mounten konnten. Wir kommen später noch einmal darauf zurück.

Der zweite bedeutende Unterschied ist das für NFSv4 der NFS-Server für jeden NFSv4 Client ein Pseudo-Filesystem erzeugt. Dieses Filesystem startet bei dem nfsroot-Verzeichnis (per Default ist das /) und beinhaltet alle darunter liegenden, für den Client exportierten, Verzeichnisse und Dateien. Das Pseudo-Filesystem wird auch dann erzeugt, wenn es für den Client kein exportiertes Filesystem gibt das er mounten könnte!

Zur Demonstration haben wir auf unserem NFS-Server aixnim keine exportieren Filesysteme zur Verfügung gestellt:

aixnim # lsnfsexp
aixnim #

Obwohl für den NFS-Client noch nichts exportiert wurde, kann das für den Client generierte Pseudo-Filesystem trotzdem mittels NFSv4 gemountet werden:

clientv4 # mount -o vers=4 aixnim:/ /mnt
clientv4 # ls -il /mnt
total 0
clientv4 #

Das gemountete Filesystem ist natürlich leer, da ja noch nichts exportiert wurde. Wir hängen das gemountete Filesystem wieder aus (hier nicht gezeigt) und exportieren auf dem NFS-Server aixnim das Verzeichnis /var/adm:

aixnim # mknfsexp -d /var/adm -v 4 -r clientv4
aixnim # lsnfsexp
/var/adm -vers=4,root=clientv4
aixnim #

Wir mounten nun erneut das Pseudo-Filesystem ab /:

clientv4 # mount -o vers=4 aixnim:/ /mnt
clientv4 #

Um die Unterschiede zu NFSv2 und NFSv3 leichter illustrieren zu können, zeigen wir kurz noch das nützliche Kommando nfs4cl für den NFSv4-Client:

clientv4 # nfs4cl showfs

Server      Remote Path          fsid                 Local Path        
--------    ---------------      ---------------      ---------------   
aixnim    /                    0:42949672964        /mnt              
clientv4 #

Das Kommando zeigt das von aixnim gemountete Pseudo-Filesystem /, das unter /mnt gemountet ist. Wir schauen nun kurz mit dem Kommando ls in das Verzeichnis /mnt

clientv4 # ls -il /mnt
total 1
    2 dr-xr-xr-x    2 root     system            3 May 21 07:34 var
clientv4 #

In dem vom NFS-Server generierten Pseudo-Filesystem ist nur die Pfad-Komponente /var sichtbar. Diese Pfad-Komponente ist ein Prefix des exportierten Verzeichnisses /var/adm. Andere Verzeichnisse wie /opt oder /usr sind im Pseudo-Filesystem nicht sichtbar, da diese nicht Prefix eines exportierten Pfades sind. Wir werfen einen Blick auf /mnt/var:

clientv4 # ls -il /mnt/var   
total 8
   32 drwxrwxr-x   15 root     adm            4096 May  2 11:30 adm
clientv4 #

Auch unter var ist nur das Verzeichnis adm sichtbar, da nur /var/adm ein Prefix eines exportierten Pfades ist. Das Pseudo-Filesystem ist natürlich an den Stellen die nicht exportiert wurden unveränderbar, wie der Versuch eine Datei unter /mnt/var anzulegen zeigt:

clientv4 # touch /mnt/var/file
touch: /mnt/var/file cannot create
clientv4 #

Ab /mnt/var/adm sieht dann alles wie von NFSv2 und NFSv3 gewohnt aus, man hat Zugriff auf die exportierten Daten:

clientv4 # ls -il /mnt/var/adm
total 704
  110 drw-r-----    2 root     system          256 May 20 14:33 SRC
4165 drwxrwxr-x    2 adm      adm             256 Apr 17 08:07 acct
   70 drwx------    4 root     system          256 Apr 17 07:50 config
4133 drwx------    2 root     system          256 Apr 17 08:03 corrals
...
4   33 -rw-rw-r--    1 adm      adm          337608 May 20 09:30 wtmp
clientv4 #

Schauen wir uns jetzt noch einmal die Ausgabe des Kommandos “nfs4cl showfs” an:

Clientv4 # nfs4cl showfs

Server      Remote Path          fsid                 Local Path        
--------    ---------------      ---------------      ---------------   
aixnim   /var                 0:42949672966        /mnt/var          
aixnim   /                    0:42949672964        /mnt        
clientv4 #

Für jedes physikalische Filesystem auf dem Server wird ein eigenes Pseudo-Filesystem erzeugt. Das jeweilige Pseudo-Filesystem gewährt Zugriff auf exportierte Verzeichnisse des unterliegenden physikalischen Filesystems und generiert für Pfad-Prefixe von exportierten Verzeichnissen read-only Verzeichnisse.

Wir exportieren auf dem NFS-Server aixnim noch das Verzeichnis /usr/share für den Client:

aixnim # mknfsexp -d /usr/share -v 4 -r clientv4
aixnim # lsnfsexp
/var/adm -vers=4,root=clientv4
/usr/share -vers=4,root=clientv4
aixnim #

Auf dem Client führen wir dieses Mal keinen umount und erneuten Mount aus, sondern greifen mittels ls einfach noch einmal auf den Mountpunkt /mnt zu:

clientv4 # ls -il /mnt
total 2
    2 dr-xr-xr-x    2 root     system            3 May 21 08:13 usr
    2 dr-xr-xr-x    2 root     system            3 May 21 07:34 var
clientv4 #

Der Pfad-Prefix usr des gerade exportierte Verzeichnisses /usr/share taucht auf dem Client auf, ohne das wir explizit gemountet haben. Ein Blick nach /mnt/usr zeigt das wie erwartet das Verzeichnis share auftaucht:

clientv4 # ls -il /mnt/usr

total 0

16390 drwxr-xr-x    8 bin      bin             256 Apr 17 08:31 share

clientv4 #

Und unter /mnt/usr/share befinden sich dann wie erwartet die exportierten Daten:

clientv4 # ls -il /mnt/usr/share
total 24
74212 drwxr-xr-x    2 bin      bin             256 Apr 17 08:24 X11
49162 drwxr-xr-x    2 bin      bin             256 Nov  3 2015  dict
16391 drwxr-xr-x   12 bin      bin            4096 Apr 17 08:22 lib
17762 lrwxrwxrwx    1 root     system           26 Apr 17 08:31 locale -> /opt/freeware/share/locale
20653 drwxr-xr-x    5 root     system          256 Apr 24 15:46 lpp
16911 drwxr-xr-x   11 bin      bin            4096 May 20 14:25 man
45096 drwxr-xr-x    2 bin      bin            4096 Apr 17 08:03 modems
clientv4 #

Das Kommando „nfs4cl showfs“ zeigt nun 3 Filesysteme:

Clientv4 # nfs4cl showfs

Server      Remote Path          fsid                 Local Path        
--------    ---------------      ---------------      ---------------   
aixnim /usr                 0:42949672965        /mnt/usr          
aixnim /var                 0:42949672966        /mnt/var          
aixnim /                    0:42949672964        /mnt              
clientv4 #

Das letzte Beispiel zeigt das im Falle von NFSv4 neue Filesysteme nicht zwangsläufig manuell auf dem Client gemountet werden müssen. Werden weitere Filesysteme auf dem NFS-Server für einen NFSv4-Client exportiert, dann kann der Client einfach auf das neue Filesystem zugreifen. Voraussetzung ist allerdings das der Pfad für das neue Filesystem Bestandteil des vom Client gemounteten Pseudo-Filesystems ist. Da wir das komplette Pseudo-Filesystem ab dem nfsroot gemountet hatten, ist dies trivialerweise der Fall. Hätten wir aber lediglich /var vom NFS-Server gemountet, dann wäre /usr/share nicht Bestandteil des Pseudo-Filesystems von /var und es wäre ein separater Mount erforderlich gewesen.

Das weitere Filesysteme wie gerade gezeigt ohne explizites Mounten verfügbar sind, liegt in einem dritten Unterschied von NFSv4 zu seinen Vorgängern. Bei NFSv2 und NFSv3 sind alle Filehandle persistent, das heißt unveränderlich. Mit NFSv4 wurden volatile (zerbrechliche) Filehandle zusätzlich zu den persistent Filehandles eingeführt. Die vom Pseudo-Filesystem verwendeten Filehandle sind volatile. Das heißt der Client muß damit rechnen das sich ein solches Filehandle ändern kann. Dies ist der Fall wenn ein weiterer Pfad auf dem NFS-Server exportiert wurde, die Filehandles für die Pfad-Prefixe im Pseudo-Filesystem ändern sich dann, der Client bekommt dies nach kurzer Zeit mit und reagiert entsprechend.

Abschließend sei noch auf ein kleines Problem hingewiesen: wir hatten einen Mount durchgeführt, das Kommando „nfs4cl showfs“ hat allerdings gezeigt das hierbei zuletzt 3 Filesysteme beteiligt waren. Es ist aber nur ein Filesystem gemountet, wie df zeigt:

clientv4 # df -g
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4           1.00      0.86   15%     8367     5% /
/dev/hd2           6.12      2.90   53%    65563     9% /usr
/dev/hd9var        2.00      1.81   10%     1770     1% /var
/dev/hd3           2.00      1.89    6%      452     1% /tmp
/dev/hd1           1.00      0.88   12%      454     1% /home
/dev/hd11admin      0.50      0.50    1%       15     1% /admin
/proc                 -         -    -        -      - /proc
/dev/hd10opt       2.00      0.94   54%    22460    10% /opt
/dev/livedump      1.00      1.00    1%        4     1% /var/adm/ras/livedump
/dev/varadmloglv      2.00      1.85    8%      275     1% /var/adm/log
aixnim:/       0.38      0.20   47%    12644    22% /mnt
clientv4 #

Das unter /mnt gemountete Filesystem ist 0.38 GB groß. Auf dem NFS-Server wurden /usr/share und /var/adm exportiert, ein df zeigt hier die folgenden Größen:

aixnim # df –g / /usr/share /var/adm
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4           0.38      0.20   47%    12644    22% /
/dev/hd2           2.06      0.23   89%    39236    41% /usr
/dev/hd9var        0.50      0.45   10%      614     1% /var
aixnim #

Offensichtlich werden beim Client die Werte des Filesystems / des NFS-Servers verwendet! Unter /usr und damit auch /usr/share wären noch knapp 2 GB verfügbarer Platz, was allerdings beim Kommando df auf dem Client nicht angezeigt wird. Es dürfte auch schwierig sein auf dem Client Werte anzugeben, da auf dem NFS-Server mehrere Filesysteme involviert sind. Das Kommando df zeigt hier einfach die Daten des dem gemounteten Pseudo-Filesystem unterliegenden physikalischen Filesystems an. In unserem Falle ist dies das root-Filesystem des NFS-Servers. Helfen kann hier wieder das Kommando nfs4cl, dieses besitzt ein Subkommando zum Anzeigen von Filesystem-Informationen ähnlich zu df:

clientv4 # nfs4cl showstat

Filesystem       512-blocks        Free  %Used       Iused %Iused  Mounted on
aixnim:/usr     4325376      482752    89%       39236    41% /mnt/usr  
aixnim:/var     1048576      947064    10%         614     1% /mnt/var  
aixnim:/      786432      417944    47%       12644    22% /mnt     
clientv4 #

Dies ist identisch zu den Werten die bei df auf dem NFS-Server angezeigt werden.

Aber auch mit dem Standard-df von AIX kann man diese Information bekommen, wie die folgende Ausgabe zeigt:

clientv4 # df -g /mnt /mnt/usr /mnt/usr/share /mnt/var /mnt/var/adm
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
aixnim:/           0.38      0.20   47%    12644    22% /mnt
[NFSv4]            2.06      0.23   89%    39236    41% /mnt/usr
[NFSv4]            2.06      0.23   89%    39236    41% /mnt/usr/share
[NFSv4]            0.50      0.45   10%      614     1% /mnt/var
[NFSv4]            0.50      0.45   10%      614     1% /mnt/var/adm
clientv4 #

Es gibt natürlich noch eine Reihe weiterer Unterschiede, die aber hier nicht mehr angeschaut werden sollen. Vielleicht wird es noch einen weiteren Artikel zu dem Thema geben.

Nützlich sind die oben dargestellten Vorteile insbesondere bei hierarchischen Mounts. Bei NFSv4 muß man nur einen Mount durchführen und sich damit nicht mehr um die Reihenfolge der Mounts kümmern.

Das Verstehen der Funktionsweise des Pseudo-Filesystems für den NFSv4-Client hilft beim Ermitteln der exportierten Filesysteme auf dem Client. Anstelle „showmount -e“ wie bisher bei NFSv2 und NFSv3 zu benutzen (was bei NFSv4 kein Resultat erzielt), kann man einfach alles ab / mounten und dann mit cd und ls herausfinden was der NFS-Server exportiert hat.

 

Extrem schnell wachsendes /var/adm/wtmp

Kürzlich hatten wir auf einem unserer AIX SAP-Systeme ein volles /var-Filesystem. Es stellte sich heraus das ein auf 1.9 GB angewachsenes /var/adm/wtmp-File die Ursache war. Diese Datei war innerhalb kurzer Zeit auf fast 2 GB angewachsen. Es stellte sich die Frage was die extrem vielen Einträge produzierte. Um dies festzustellen wurde erst einmal der Inhalt der Datei in ASCII-Form angezeigt:

# cat /var/adm/wtmp  | /usr/sbin/acct/fwtmp
         ac02                         8 25690134 0000 0177 1558338990                                  Mon May 20 09:56:30 DFT 2019
         ac01                         8 27525310 0000 0177 1558338990                                  Mon May 20 09:56:30 DFT 2019
         ac00                         8 27525308 0000 0177 1558338990                                  Mon May 20 09:56:30 DFT 2019
ac00     ac00                         5 7864366 0000 0000 1558338990                                  Mon May 20 09:56:30 DFT 2019
ac01     ac01                         5 7864368 0000 0000 1558338990                                  Mon May 20 09:56:30 DFT 2019
ac02     ac02                         5 7864370 0000 0000 1558338990                                  Mon May 20 09:56:30 DFT 2019
         ac01                         8 7864368 0000 0177 1558338990                                  Mon May 20 09:56:30 DFT 2019
         ac00                         8 7864366 0000 0177 1558338990                                  Mon May 20 09:56:30 DFT 2019
…
#

Diese Einträge wiederholten sich endlos, teilweise gab es mehr als 50 Einträge innerhalb einer Sekunde! Die Zeichenketten „ac00“, „ac01“ und „ac02“ sind IDs aus der /etc/inittab. In der Spalte 2 bzw. 3 steht der Typ des Eintrags, hier 5 und 8. Die Bedeutung lässt sich über die Header-Datei /usr/include/utmp.h herausfinden:

# cat /usr/include/utmp.h
…
/*      Definitions for ut_type                                         */
…
#define INIT_PROCESS    5       /* Process spawned by "init" */
…
#define DEAD_PROCESS    8
…

Die Prozesse wurden von /etc/init gestartet und sind dann aber sofort wieder verstorben. Es sieht so aus, als würden hier Prozesse mit der Aktion „respawn“ gestartet, welche dann aufgrund eines Fehlers sofort wieder beendet werden. Wir schauen uns die zugeörigen inittab-Einträge an:

#  lsitab ac00    
ac00:2345:respawn:/oracle/NW1/acs/acsgen -D
#  lsitab ac01
ac01:2345:respawn:/oracle/NW1/acs/acsd
#  lsitab ac02
ac02:2345:respawn:/oracle/NW1/acs/fcmcli -D
#

Es handelt sich hier um Einträge von Oracle, die offensichtlich nicht wie beabsichtigt funktionieren.

In unserem Falle existierten schlicht die Binaries nicht an der angegebenen Stelle:

#  ls -l /oracle/NW1/acs/acsgen /oracle/NW1/acs/acsd /oracle/NW1/acs/fcmcli
ls: 0653-341 The file /oracle/NW1/acs/acsgen does not exist.
ls: 0653-341 The file /oracle/NW1/acs/acsd does not exist.
ls: 0653-341 The file /oracle/NW1/acs/fcmcli does not exist.
#

In Absprache mit den Oracle-Kollegen wurden die Einträge aus der /etc/inittab entfernt und damit das Problem behoben:

# rmitab ac00
# rmitab ac01
# rmitab ac02
#

Fehlerhafte Einträge in der /etc/inittab können eine schnell wachsende /var/adm/wtmp zur Folge haben.

 

AIX: Anwendungen des namefs-Filesystems

Gelegentlich benötigt man ein Verzeichnis (oder ein Filesystem) an einer anderen Stelle im Filesystem oder vielleicht sogar an mehreren verschiedenen Stellen im Filesystem. Anstatt das Problem mit symbolischen Links zu lösen, kann man elegant das namefs-Filesystem zum Einsatz bringen.

In folgenden Beispie wird /data/in an anderer Stelle benötigt:

# ls -l /data/in
total 16
-rw-r--r--    1 root     system          554 May 14 16:10 file1
-rw-r--r--    1 root     system          381 May 14 16:10 file2
# ls -l /other/place
total 0
#

Mounten des Directories an die gewünschte Stelle /other/place:

# mount -v namefs /data/in /other/place
# ls -l /other/place
total 16
-rw-r--r--    1 root     system          554 May 14 16:10 file1
-rw-r--r--    1 root     system          381 May 14 16:10 file2
#

Der Mount mit dem namefs-Filesystem bietet zusätzlich die Möglichkeit Mount-Optionen anzugeben, die dann nur für das Verzeichnis gelten. Man kann damit z.B. ein Verzeichnis auch mit Direct-I/O Mounten, obwohl das ursprüngliche Verzeichnis nicht mit Direct-I/O gemountet wurde:

# mount -v namefs -o dio /data/in /other/place
# mount
  node       mounted        mounted over    vfs       date        options     
-------- ---------------  ---------------  ------ ------------ ---------------
         /dev/hd4         /                jfs2   May 02 11:30 rw,log=/dev/hd8
...
         /data/in         /other/place     namefs May 14 16:14 rw,dio         
#

Bei Zugriffen auf die Dateien unterhalb /other/place wird nun Direct-I/O verwendet, greift man aber über die „Originale“ unter /data/in zu, wird kein Direct-I/O verwendet!

Der Zugriff auf Dateien ist allerdings wie bei NFS auf das unterliegende physikalische Filesystem beschränkt. Dies läßt sich leicht anhand des Filesystems / demonstrieren. Wir mounten / per namefs unter /mnt und schauen uns /mnt/usr und /mnt/var an:

# mount -v namefs / /mnt
# ls -l /mnt/usr /mnt/var
/mnt/usr:
total 0
lrwxrwxrwx    1 root     system           11 Apr 17 07:49 lib -> /../usr/lib

/mnt/var:
total 0
#

Die Verzeichnisse sind leer bzw. enthalten einen symbolischen Link, /usr und /var sehen etwas anders aus!

Dies kann man natürlich auch ausnutzen, z.B. in Fällen bei denen interessante Daten übermountet wurden. Wir haben unterhalb von /home eine Datei abgelegt, bevor /dev/hd1 auf /home gemountet wurde. Über das gerade auf /mnt gemountet root-Filesystem kann man auf diese übermounteten Daten zugreifen:

# ls -l /mnt/home
total 0
-rw-r--r--    1 root     system            0 May 14 17:48 overmounted_file
#

Eine weitere Anwendung besteht darin ein Verzeichnis vor überschreiben zu schützen. Wir demonstrieren dies am Verzeichnis /data mit 2 Test-Dateien:

# ls -l /data
total 16
-rw-r--r--    1 root     system          554 May 14 17:52 file1
-rw-r--r--    1 root     system          381 May 14 17:52 file2
# cp /etc/hosts /data
# ls -l /data
total 24
-rw-r--r--    1 root     system          554 May 14 17:52 file1
-rw-r--r--    1 root     system          381 May 14 17:52 file2
-rw-r--r--    1 root     system         2075 May 14 17:54 hosts
#

Überschreiben oder Ändern von Daten ist aktuell noch möglich, wie das erfolgreiche cp-Kommando zeigt. Jetzt schützen wir die Daten, indem wir einen Mount mit dem namefs-Filesystem und der Option ro (Read-Only) durchführen:

# mount -v namefs -o ro /data /data
# cp /etc/services /data
cp: /data/services: Read-only file system
#

Die Daten können offensichtlich nicht mehr geändert werden. Hier haben wir /data mit einer Read-only Version von sich selbst übermountet!

Mounts mit dem Pseudo-Filesystem namefs können nicht nur auf jfs2-Filesystemen, sondern auch für NFS-Filesysteme oder das procfs-Filesystem durchgeführt werden.

Als Letztes zeigen wir noch das Mounten einer Datei an einer anderen Stelle des Filesystems. Wir wollen die Datei /etc/hosts über den Namen /hosts verfügbar machen. Dazu legen wir zunächst eine leere Datei /hosts an und mounten dann die Datei /etc/hosts über diese leere Datei:

# touch /hosts
# ls -l /hosts
-rw-r--r--    1 root     system            0 May 14 17:59 /hosts
# mount -v namefs /etc/hosts /hosts
# ls -l /hosts
-rw-rw-r--    1 root     system         2075 Apr 26 10:47 /hosts
#

Vor dem Mount ist /hosts 0 Bytes groß, nach dem Mount 2075 Bytes!

Das namefs-Filesystem bietet also einige interessante Möglichkeiten, die bei einige Problemstellungen nützlich sein können.

 

 

 

FC NPIV Client Durchsatz-Statistiken

Bei Verwendung von NPIV teilen sich mehrere Client-LPARs einen physikalischen FC-Port eines Virtual-I/O-Servers. Für Performance-Untersuchungen wäre es natürlich schön, wenn man den Durchsatz der einzelnen Client-LPARs leicht feststellen könnte um diese vergleichend anzuschauen. Damit könnten Fragen wie

  • wieviel Durchsatz erzielt eine bestimmte LPAR gerade
  • welche LPARs haben den höchsten Durchsatz und produzieren den meisten FC-Verkehr
  • treten Resource-Engpässe auf

beantwortet werden.

Es gibt natürlich verschiedene Möglichkeiten diese Daten zu gewinnen. Eine besonders einfache Möglichkeit stellt der Virtual-I/O-Server über das padmin Kommando ‚fcstat‚ bereit. Das Kommando erlaubt die Ausgabe von NPIV-Client-Statistiken bei Verwendung der Option ‚-client‚:

(0)padmin@aixvio1:/home/padmin> fcstat -client
              hostname   dev                wwpn     inreqs    outreqs ctrlreqs          inbytes         outbytes  DMA_errs Elem_errs Comm_errs

               aixvio1  fcs0  0x100000XXXXXXXXXX 49467894179 50422150679 947794529 1861712755360927 1451335312750576         0         0         0
     C050760YYYYYYYYY
                                    0          0        0                0                0         0         0         0
     C050760ZZZZZZZZZ
                                    0          0        0                0                0         0         0         0
                 aix01  fcs0  0xC050760XXXXXXXXX   22685402  101956075 10065757     699512617896    1572578056704         0         0         0
                 aix02  fcs0  0xC050760XXXXXXXXX   28200473   82295158 12051365     387847746448     626772151808         0         0         0
                 aix03  fcs0  0xC050760XXXXXXXXX  376500672  255163053 21583628   22619424512608    3786990844928         0         0         0
                 aix04  fcs0  0xC050760XXXXXXXXX  116450405  504688524 14020031    4037786527400    9929289617408         0         0         0
          blbprodora22  fcs0  0xC050760XXXXXXXXX 1341092479  580673554 37458927   44288566807072   12166718497792         0         0         0
...
               aixvio1  fcs1  0x100000XXXXXXXXXX  391131484 1090556094 156294130   71031615240217   87642294572864         0         0         0
              aixtsm01  fcs2  0xC050760XXXXXXXXX  334020900  785597352 74659821   62072552942128   83284555980288         0         0         0
              aixtsm02  fcs0  0xC050760XXXXXXXXX    2943054   40921231 11617552     107317697968     289142333440         0         0         0

               aixvio1  fcs2  0x210000XXXXXXXXXX  403180246 5877180796   236998  105482699300998 1540608710446612         0         0         0
              aixtsm01  fcs6  0xC050760XXXXXXXXX  146492419  392365162    74250   38378099796342  102844775468007         0         0         0
              aixtsm02  fcs2  0xC050760XXXXXXXXX         19     192848       20             1090      50551063184         0         0         0

               aixvio1  fcs3  0x210000XXXXXXXXXX  405673338 7371951499   260575  105969796271246 1932388891128304         0         0         0
              aixtsm02  fcs3  0xC050760XXXXXXXXX          0          0        4                0                0         0         0         0
                 aix02  fcs7  0xC050760XXXXXXXXX      42624 2677470211    34211          2382280  701864613402184         0         0         0
...
Invalid initiator world wide name
Invalid initiator world wide name
(0)padmin@aixvio1:/home/padmin>

Die Zeile mit der WWPN C050760YYYYYYYYY und C050760ZZZZZZZZZ gehören zu NPIV-Adaptern von nicht aktivierten LPARs. Daher werden als Zähler auch nur Nullen angezeigt. Für jeden physikalischen (NPIV-fähigen) FC-Port des Virtual-I/O-Servers wird der physikalische FC-Port, sowie die NPIV Client-LPARs angezeigt. Anhand des fett-markierten Blocks soll hier kurz die Ausgabe beschrieben werden. Als erstes wird immer der physikalische Port des Virtual-I/O-Servers ausgegeben, hier aixvio1 und FC-Port fcs1. In den darauffolgenden Zeilen kommen dann die NPIV-Clients, jeweils mit dem LPAR-Namen und dem zugehörigen virtuellen FC-Port der LPAR, hier aixtsm01 und aixtsm02. Die virtuellen FC-Ports der LPARs fcs2 (aixtsm01) und fcs0 (aixtsm02) sind auf den physikalischen FC-Port fcs1 von aixvio1 gemappt. Nach einer Leerzeile kommt der nächste physikalische FC-Port des Virtual-I/O-Servers.

In den Spalten werden die WWPN der physikalischen bzw. virtuellen FC-Ports augelistet. Außerdem werden die Anzahl der Ein- und Ausgehenden Requests, sowie die übertragenen Bytes, ebenfalls ein- und ausgehend, aufgelistet. In den 3 verbleibenden Spalten werden Fehler aufgeführt. Gibt es für einen Request keinen DMA Puffer mehr, wird DMA_errs hochgezählt, ist die Queue des FC-Adapters voll, wird Elem_errs hochgezählt, bei Übertragungs-Fehlern wird Comm_errs hochgezählt. Tauchen regelmäßig Zähler bei DMA_errs oder Elem_errs auf, kann das ein Hinweis auf zu kleine Werte bei einigen Tuning-Attributen sein.

Aufgrund der Länge der Ausgabe und den absoluten Zählern die ausgegeben werden, ist die Ausgabe etwas unübersichtlich. Mit einem kleinen Skript kann man aber leicht Delta-Werte errechnen und die Ausgabe auf MB pro Sekunde skalieren. Mit dem nachfolgenden Beispiel-Skript haben wir dies getan:

$ cat npivstat
#! /bin/ksh93
#
# Copyright (c) 2019 by PowerCampus 01 GmbH
# Author: Dr. Armin Schmidt
#

delta=5 # seconds

typeset -A dataInreqs
typeset -A dataOutreqs
typeset -A dataInbytes
typeset -A dataOutbytes
typeset -A dataDMA_errs
typeset -A dataElem_errs
typeset -A dataComm_errs

bc |& # start bc as coroutine
print -p "scale=2"

# get first sample

/usr/ios/cli/ioscli fcstat -client 2>/dev/null | \
while read hostname dev wwpn inreqs outreqs ctrlreqs inbytes outbytes DMA_errs Elem_errs Comm_errs rest
do
case "$wwpn" in
0x*)
dataInreqs[${hostname}_${dev}]=$inreqs
dataOutreqs[${hostname}_${dev}]=$outreqs
dataInbytes[${hostname}_${dev}]=$inbytes
dataOutbytes[${hostname}_${dev}]=$outbytes
dataDMA_errs[${hostname}_${dev}]=$DMA_errs
dataElem_errs[${hostname}_${dev}]=$Elem_errs
dataComm_errs[${hostname}_${dev}]=$Comm_errs
;;
esac
done
sleep $delta

while true
do
/usr/ios/cli/ioscli fcstat -client 2>/dev/null | \
while read hostname dev wwpn inreqs outreqs ctrlreqs inbytes outbytes DMA_errs Elem_errs Comm_errs rest
do
case "$wwpn" in
0x*)
prevInreqs=${dataInreqs[${hostname}_${dev}]}
prevOutreqs=${dataOutreqs[${hostname}_${dev}]}
prevInbytes=${dataInbytes[${hostname}_${dev}]}
prevOutbytes=${dataOutbytes[${hostname}_${dev}]}
prevDMA_errs=${dataDMA_errs[${hostname}_${dev}]}
prevElem_errs=${dataElem_errs[${hostname}_${dev}]}
prevComm_errs=${dataComm_errs[${hostname}_${dev}]}
dataInreqs[${hostname}_${dev}]=$inreqs
dataOutreqs[${hostname}_${dev}]=$outreqs
dataInbytes[${hostname}_${dev}]=$inbytes
dataOutbytes[${hostname}_${dev}]=$outbytes
dataDMA_errs[${hostname}_${dev}]=$DMA_errs
dataElem_errs[${hostname}_${dev}]=$Elem_errs
dataComm_errs[${hostname}_${dev}]=$Comm_errs

print -p "(${inreqs}-${prevInreqs})/$delta"
read -p inreqs
print -p "(${outreqs}-${prevOutreqs})/$delta"
read -p outreqs
print -p "(${inbytes}-${prevInbytes})/${delta}/1024/1024"
read -p inbytes
print -p "(${outbytes}-${prevOutbytes})/${delta}/1024/1024"
read -p outbytes
print -p "(${DMA_errs}-${prevDMA_errs})/$delta"
read -p DMA_errs
print -p "(${Elem_errs}-${prevElem_errs})/$delta"
read -p Elem_errs
print -p "(${Comm_errs}-${prevComm_errs})/$delta"
read -p Comm_errs

printf "%15s %5s %16s %6.2f %7.2f %7.2f %8.2f %8.2f %9.2f %9.2f\n" "$hostname" "$dev" "$wwpn" "$inreqs" "$outreqs" \
"$inbytes" "$outbytes" "$DMA_errs" "$Elem_errs" "$Comm_errs"
;;
"wwpn")
printf "%15s %5s %16s %6s %7s %7s %8s %8s %9s %9s\n" "$hostname" "$dev" "$wwpn" "$inreqs" "$outreqs" \
"$inbytes" "$outbytes" "$DMA_errs" "$Elem_errs" "$Comm_errs"
;;
"")
[ -n "$hostname" ] && continue
printf "%15s %5s %16s %6s %7s %7s %8s %8s %9s %9s\n" "$hostname" "$dev" "$wwpn" "$inreqs" "$outreqs" \
"$inbytes" "$outbytes" "$DMA_errs" "$Elem_errs" "$Comm_errs"
;;
esac
done
print

sleep $delta
done

$

Das Skript steht zum Download in unserem Download-Bereich zur Verfügung.

Hier noch ein Auszug von einem Lauf des Skriptes (stark gekürzt, nur einer der physikalischen Ports ist dargestellt):

aixvio1 # ./npivstat
       hostname    dev              wwpn  inreqs  outreqs  inbytes  outbytes  DMA_errs  Elem_errs  Comm_errs
...                                                                                                          
        aixvio1   fcs2  0x210000XXXXXXXXXX    0.00  1019.00     0.00    254.75      0.00       0.00       0.00
       aixtsm01   fcs6  0xC0507605E5890074    0.00     0.00     0.00      0.00      0.00       0.00       0.00
       aixtsm02   fcs2  0xC0507609A6C70004    0.00     0.00     0.00      0.00      0.00       0.00       0.00
          aix05   fcs6  0xC0507609A6C7001C    0.00  1018.20     0.00    254.55      0.00       0.00       0.00
...                                                                                                          
        aixvio1   fcs2  0x210000XXXXXXXXXX    0.00  1020.20     0.00    255.05      0.00       0.00       0.00
       aixtsm01   fcs6  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
       aixtsm02   fcs2  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
          aix05   fcs6  0xC050760XXXXXXXXX    0.00  1019.80     0.00    254.95      0.00       0.00       0.00
...                                                                                                           
        aixvio1   fcs2  0x210000XXXXXXXXXX    0.00   984.80     0.00    246.20      0.00       0.00       0.00
       aixtsm01   fcs6  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
       aixtsm02   fcs2  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
          aix05   fcs6  0xC050760XXXXXXXXX    0.00   985.00     0.00    246.25      0.00       0.00       0.00
...
^Caixvio1 # 

Im obigen Beispiel generiert der NPIV-Client aix05 ca 250 MB/s an Daten, wärend die anderen beiden NPIV-Clients aixtsm01 und aixtsm02 während dieser Zeit keinen FC-Verkehr produzieren.

Das Skript muss als root auf einem Virtual-I/O-Server gestartet werden. Natürlich kann man das Skript auf die eigenen Bedürfnisse anpassen.

Migration nach AIX PCM kombiniert mit OS-Update

Bei den meisten AIX Systemen wird wahrscheinlich in regelmäßigen Abständen der SP- oder TL-Level aktualisiert. Es bietet sich an, bei einem solchen Update, die Migration von SDDPCM nach AIX PCM mit durchzuführen. Dies spart Zeit und einige Reboots, die ansonsten extra wegen der Multipathing Migration durchgeführt werden müssen.

In unserem Blog-Beitrag „Migration von SDDPCM nach AIX-PCM“ hatten wir die Migration für Standalone Systeme schon gezeigt.

Hier soll die Migration von SDDPCM nach AIX-PCM im Rahmen eines OS-Updates gezeigt werden, wobei das Alternate Disk Copy Verfahren zum Einsatz kommt. Der Ablauf ist im groben der folgende:

  1. Entspiegeln der rootvg um eine freie Platte für Alternate Disk Copy zu gewinnen.
  2. Ändern des Path Control Moduls (PCM) auf AIX PCM.
  3. Erzeugen der altinst_rootvg.
  4. Entfernen von Fixes in der altinst_rootvg.
  5. Durchführen des OS-Updates auf der altinst_rootvg.
  6. Installation von Fixes in der altinst_rootvg.
  7. Hinzufügen eines firstboot-Skripts um Platten-Attribute zu setzen.
  8. Ändern des Path Control Moduls (PCM) zurück auf SDDPCM.
  9. Booten von der altinst_rootvg.

Auf unserem Beispiel-System ist AIX 7.1 TL5 SP2 installiert, die Platten sind SVC-Platten, die über virtual FC Adapter angebunden sind. SDDPCM ist der aktuell aktive Multipathing-Treiber:

# oslevel -s
7100-05-02-1810
# lsdev -l hdisk0 -F uniquetype
disk/fcp/2145
aix01:/root> lsattr -El hdisk0 -a PCM -F value
PCM/friend/sddpcm
#

Wie schon im oben genannten Blog-Beitrag ausgeführt, ändern sich einige Platten-Attribute bei der Migration auf AIX PCM. Daher sollte man sich die aktuellen Attribute genau anschauen, um diese gegebenenfalls später zu übernehmen (zumindest teilweise). Exemplarisch schauen wir uns hier nur das Attribut queue_depth an, welches aktuell den Wert 120 hat:

# lsattr -El hdisk0 -a queue_depth -F value
120
#

Unser System besitzt eine gespiegelte rootvg:

# lsvg -p rootvg
rootvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk3            active            399         232         00..01..71..80..80
hdisk0            active            399         240         00..01..79..80..80
#

Das System wurde von der hdisk0 gebootet:

# bootinfo -b
hdisk0
#

Daher lassen wir die hdisk0 in der rootvg und entfernen die hdisk3 aus der rootvg, um eine freie Platte für Alternate Disk Copy zu gewinnen.

# unmirrorvg rootvg hdisk3
0516-1246 rmlvcopy: If hd5 is the boot logical volume, please run 'chpv -c <diskname>'
        as root user to clear the boot record and avoid a potential boot
        off an old boot image that may reside on the disk from which this
        logical volume is moved/removed.
0516-1804 chvg: The quorum change takes effect immediately.
0516-1144 unmirrorvg: rootvg successfully unmirrored, user should perform
        bosboot of system to reinitialize boot records.  Then, user must modify
        bootlist to just include:  hdisk0.
# reducevg rootvg hdisk3
# chpv -c hdisk3
# bootlist -m normal hdisk0
#

Bevor wir nun mittels Alternate Disk Copy eine Kopie der rootvg erzeugen, stellen wir das System temporär auf AIX PCM um, ohne allerdings zu rebooten. Wird dann anschließend die altinst_rootvg erzeugt, dann ist in dieser die Umstellung auf AIX PCM schon vorgenommen!

# manage_disk_drivers -d IBMSVC -o AIX_AAPCM
********************** ATTENTION *************************
  For the change to take effect the system must be rebooted
#

Am Ende des OS-Updates machen wir diese Umstellung dann auf der rootvg wieder rückgängig, um den Original-Zustand mit SDDPCM zu haben.

Nach diesen Vorbereitungen starten wir nun das alt_disk_copy Kommando:

# alt_disk_copy -d hdisk3 -B
Calling mkszfile to create new /image.data file.
Checking disk sizes.
Creating cloned rootvg volume group and associated logical volumes.
Creating logical volume alt_hd5.
Creating logical volume alt_hd6.
Creating logical volume alt_hd8.
…
#

Auf dem System sind einige EFixes installiert, die wir vor dem Update noch aus der altinst_rootvg entfernen:

# emgr -l
ID  STATE LABEL      INSTALL TIME      UPDATED BY ABSTRACT
=== ===== ========== ================= ========== ======================================
1    S    102m_ifix  10/14/18 10:48:18            IFIX for Openssl CVE on 1.0.2m       
2    S    IJ03121s0a 10/14/18 10:49:04            IJ03121 for AIX 7.1 TL5 SP00         
3    S    IJ05822s2a 10/14/18 10:49:18            a potential security issue exists    
…
#

Aktivieren der altinst_rootvg:

# alt_rootvg_op -W -d hdisk3
Waking up altinst_rootvg volume group ...
#

Und entfernen der EFixes:

# INUCLIENTS=1 /usr/sbin/chroot /alt_inst /usr/sbin/emgr –r -n 3
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Accessing efix metadata ...
Processing efix label "IJ05822s2a" ...
…
Operation Summary
+-----------------------------------------------------------------------------+
Log file is /var/adm/ras/emgr.log

EFIX NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 IJ05822s2a          REMOVE                 SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 2
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 1
…

(Hinweis: Bitte nicht die Variable INUCLIENTS vergessen, diese signalisiert das die Operation in einem Alternate Boot Environment stattfindet!)

Wir mounten nun die LPP-Source für den OS-Update per NFS von unserem NIM-Server:

# mount aixnim:/export/nim/lpps/aix710503lpp /mnt
#

Nun kann der OS-Update in der altinst_rootvg durchgeführt werden:

# alt_rootvg_op -C -b update_all -l /mnt
Installing optional filesets or updates into altinst_rootvg...
install_all_updates: Initializing system parameters.
install_all_updates: Log file is /var/adm/ras/install_all_updates.log
install_all_updates: Checking for updated install utilities on media.
…
installp:  * * * A T T E N T I O N ! ! !
        Software changes processed during this session require
        any diskless/dataless clients to which this SPOT is
        currently allocated to be rebooted.
install_all_updates: Log file is /var/adm/ras/install_all_updates.log
install_all_updates: Result = SUCCESS
#

Abschließend installieren wir noch einige EFixes, dazu mounten wir zunächst das Verzeichnis /mnt mit den Fixes in die altinst_rootvg:

# mount -v namefs /mnt /alt_inst/mnt
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/102p_fix.181127.epkg.Z
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Efix package file is: /mnt/emgr/ppc/102p_fix.181127.epkg.Z
…
EPKG NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 102p_fix            INSTALL                SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ09621s3a.181001.epkg.Z
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ11545s0a.181127.epkg.Z
…
# umount /alt_inst/mnt
#

Um die gewünschten Platten-Attribute zu setzen und um SDDPCM zu deinstallieren verwenden wir ein firstboot-Skript:

# cat /alt_inst/etc/firstboot
#! /bin/ksh

print "INFO: adjust hdisk attributes"
chdev -Pl hdisk0 -a queue_depth=120

print "INFO: uninstalling SDDPCM"
installp -u devices.sddpcm.$(uname -v)$(uname -r).rte devices.fcp.disk.ibm.mpio.rte

print "INFO: perform reboot"
reboot

# chmod a+x /alt_inst/etc/firstboot
#

Das Skript sollte, falls man es verwendet, auf die eigenen Bedürfnisse angepaßt werden und man sollte dort alle gewünschten Platten-Attribute anpassen (queue_depth, reserve_policy,…). Das Beispiel-Skript hier soll nur andeuten was man alles machen könnte!

Die altinst_rootvg ist nun aktualisiert und auf AIX PCM umgestellt. Wir deaktivieren die altinst_rootvg, damit von dieser gebootet werden kann.

# alt_rootvg_op –S -t
Putting volume group altinst_rootvg to sleep ...
forced unmount of /alt_inst/var/adm/ras/livedump
…
forced unmount of /alt_inst
Fixing LV control blocks...
Fixing file system superblocks...
#

(Hinweis: Bitte nicht die Option “-t” vergessen, diese erzeugt ein neues Boot-Image!)

Bevor wir jedoch nun von der altinst_rootvg booten, stellen wir auf der rootvg den Multipathing Treiber wieder zurück auf SDDPCM!

# manage_disk_drivers -d IBMSVC -o NO_OVERRIDE
********************** ATTENTION *************************
  For the change to take effect the system must be rebooted
#

Abschließend stellen wir noch die Bootliste auf die altinst_rootvg (hdisk3) um:

# bootlist -m normal hdisk3
#

Und als Letztes rebooten wir nun:

# shutdown –r now

SHUTDOWN PROGRAM
Tue Apr 16 19:49:08 CEST 2019

Broadcast message from root@aix01 (tty) at 19:49:08 ...

PLEASE LOG OFF NOW ! ! !
System maintenance in progress.
All processes will be killed now.
…

-------------------------------------------------------------------------------
                                Welcome to AIX.
                   boot image timestamp: 19:45:08 04/16/2019
                 The current time and date: 19:51:11 04/16/2019
        processor count: 2;  memory size: 4096MB;  kernel size: 36847630
       boot device: /vdevice/vfc-client@3000000a/disk@5005076XXXXXXXXX:2
-------------------------------------------------------------------------------
…
Multi-user initialization completed
INFO: adjust hdisk attributes
hdisk0 changed
INFO: uninstalling SDDPCM
…
Installation Summary
--------------------
Name                        Level           Part        Event       Result
-------------------------------------------------------------------------------
devices.sddpcm.71.rte       2.7.1.1         ROOT        DEINSTALL   SUCCESS   
devices.sddpcm.71.rte       2.7.1.1         USR         DEINSTALL   SUCCESS   
devices.fcp.disk.ibm.mpio.r 1.0.0.25        USR         DEINSTALL   SUCCESS   
INFO: perform reboot
Rebooting . . .
…

AIX Version 7
Copyright IBM Corporation, 1982, 2018.
Console login:

(In der Ausgabe kann man die Aktionen des firstboot-Skriptes sehen: Änderung Plattenattribute, Deinstallation SDDPCM und Reboot.)

Nach dem Einloggen überprüfen wir die OS-Version, den verwendeten Multipathing Treiber und ein paar Platten-Attributes:

# oslevel -s
7100-05-03-1846
# lsdev -l hdisk0 -F uniquetype
disk/fcp/mpioosdisk
# lsattr -El hdisk0 -a PCM -F value
PCM/friend/fcpother
# lsattr -El hdisk0 -a queue_depth -F value
120
# genkex|grep pcm
         5ae0000    60000 /usr/lib/drivers/aixdiskpcmke
# lslpp -l|grep sddpcm
#

Damit haben wir die Migration von SDDPCM nach AIX PCM zusammen mit einem OS-Update erfolgreich durchgeführt. Durch Verskripten lässt sich dies noch automatisieren.

Wir haben dies für AIX 7.1 und AIX 7.2 getestet. Ein Test für PowerHA konnten wir bisher aus zeitlichen Gründen noch nicht durchführen.

Wussten Sie, das die HMC Status und Konfigurationsänderungen für etwa 2 Monate speichert?

Status und Konfigurationsänderungen von LPARs und Managed Systems werden auf den HMCs für ca 2 Monate gespeichert. Damit lässt sich nachträglich ohne Probleme herausfinden, wann z.B. ein Managed System heruntergefahren wurde, wann ein Service Prozessor Failover stattfand, oder wann der Speicher einer LPAR erweitert wurde, zumindest wenn das Ereignis nicht länger als 2 Monate zurück liegt.

Die Statusänderungen eines Managed Systems lassen sich mit dem Kommando „lslparutil -r sys -m <managed-system> -s h –startyear 1970 –filter event_types=state_change“ auflisten, oder alternativ mit dem LPAR-Tool Kommando „ms history <managed-system>„.

linux $ ms history ms04
TIME                  PRIMARY_STATE         DETAILED_STATE
03/14/2019 08:45:13   Started               None
03/14/2019 08:36:52   Not Available         Unknown
02/17/2019 01:51:55   Started               None
02/17/2019 01:44:00   Not Available         Unknown
02/12/2019 09:32:57   Started               None
02/12/2019 09:28:02   Started               Service Processor Failover
02/12/2019 09:27:07   Started               None
02/12/2019 09:24:42   Standby               None
02/12/2019 09:21:25   Starting              None
02/12/2019 09:22:59   Stopped               None
02/12/2019 09:21:58   Not Available         Unknown
02/12/2019 09:09:45   Stopped               None
02/12/2019 09:07:53   Stopping              None
linux $

Konfigurationsänderungen (Prozessor, Memory) eines Managed Systems lassen sich mit „lslparutil -r sys -m <managed-system> -s h –startyear 1970 –filter event_types=config_change“ anzeigen, oder alternativ wieder mit dem LPAR-Tool:

linux $ ms history -c ms02
                                PROCUNIS              MEMORY
TIME                  CONFIGURABLE  AVAILABLE  CONFIGURABLE  AVAILABLE  FIRMWARE
04/16/2019 12:15:51      20.0          5.05       1048576       249344     25856
04/11/2019 11:17:39      20.0          5.25       1048576       253696     25600
04/02/2019 13:24:35      20.0          4.85       1048576       249344     25856
03/29/2019 14:29:14      20.0          5.25       1048576       253696     25600
03/15/2019 15:37:08      20.0          4.85       1048576       249344     25856
03/15/2019 11:36:57      20.0          4.95       1048576       249344     25856
...
linux $

Die gleichen Informationen kann man sich auch für LPARs anzeigen lassen.

Die letzten Statusänderungen einer LPAR können mit „lpar history <lpar>“ aufgelistet werden:

linux $ lpar history lpar02
TIME                  PRIMARY_STATE         DETAILED_STATE
04/17/2019 05:42:43   Started               None
04/17/2019 05:41:24   Waiting For Input     Open Firmware
04/16/2019 12:01:54   Started               None
04/16/2019 12:01:29   Stopped               None
02/15/2019 11:30:48   Stopped               None
02/01/2019 12:23:34   Not Available         Unknown
02/01/2019 12:22:50   Relocating            None
...

Dies entspricht dem Kommando „lslparutil -r lpar -m ms03 -s h –startyear 1970 –filter event_types=state_change,lpar_names=lpar02“ auf der HMC Kommandozeile.

Aus der Ausgabe ist ersichtlich, dass die LPAR mit LPM verschoben wurde, gestoppt wurde und neu gestartet wurde und sich im Open Firmware-Modus befunden hat.

Und zuletzt kann man sich natürlich auch die letzten Konfigurationsänderungen einer LPAR anschauen, das Kommando auf der HMC CLI ist „lslparutil -r lpar -m ms03 -s h –startyear 1970 –filter event_types=config_change,lpar_names=lpar02„. Die Ausgabe des LPAR-Tools ist etwas übersichtlicher:

linux $ lpar history -c lpar02
TIME                  PROC_MODE  PROCS  PROCUNITS  SHARING  UNCAP_WEIGHT  PROCPOOL         MEM_MODE  MEM
04/23/2019 18:49:43   shared    1      0.7        uncap    10          DefaultPool      ded       4096
04/23/2019 18:49:17   shared    1      0.7        uncap    5           DefaultPool      ded       4096
04/23/2019 18:48:44   shared    1      0.3        uncap    5           DefaultPool      ded       4096
04/09/2019 08:04:25   shared    1      0.3        uncap    5           DefaultPool      ded       3072
03/14/2019 12:37:32   shared    1      0.1        uncap    5           DefaultPool      ded       3072
02/26/2019 09:34:28   shared    1      0.1        uncap    5           DefaultPool      ded       3072
02/20/2019 06:51:57   shared    1      0.3        uncap    5           DefaultPool      ded       3072
01/31/2019 08:12:58   shared    1      0.3        uncap    5           DefaultPool      ded       3072
..

Anhand der Ausgabe kann man sehen, dass die Anzahl der Processing Units mehrmals geändert wurde, das uncapped_weight geändert wurde und der Speicher erweitert wurde.

Änderungen der letzten beiden Monate stehen also jederzeit abrufbereit zur Verfügung!

Interim Fixes und Alternate Disk Copy

Bei Verwendung des Alternate Disk Copy Verfahrens für AIX Updates kommt es gelegentlich vor das installierte Fixes einen erfolgreichen Update verhindern. Hier bietet es sich an, die installierten Fixes direkt in der altinst_rootvg zu deinstalieren. Dazu kann das emgr Kommando mittels chroot direkt in der altinst_rootvg aufgerufen werden.

Nach dem Erstellen der altinst_rootvg, z.B. mit dem Kommando alt_disk_copy, muß die altinst_rootvg zunächst ersteinmal aktiviert werden:

# alt_rootvg_op -W -d hdisk3
Waking up altinst_rootvg volume group ...
#

Die installierten Fixes kann man sich dann wie folgt auflisten lassen:

# /usr/sbin/chroot /alt_inst /usr/sbin/emgr –l

ID  STATE LABEL      INSTALL TIME      UPDATED BY ABSTRACT
=== ===== ========== ================= ========== ======================================
1    S    102m_ifix  10/14/18 10:48:18            IFIX for Openssl CVE on 1.0.2m       
2    S    IJ03121s0a 10/14/18 10:49:04            IJ03121 for AIX 7.1 TL5 SP00         
3    S    IJ05822s2a 10/14/18 10:49:18            a potential security issue exists    
…

Beim Entfernen von Fixes in der altinst_rootvg ist die Umgebungsvariable INUCLIENTS wichtig. Diese signalisiert dem emgr Kommando keine Dienste zu restarten und keine Geräte dynamisch zu ändern. Ohne das Setzen dieser Variablen schlägt die Deinstallation einiger Fixes in der altinst_rootvg fehl!

# INUCLIENTS=1 /usr/sbin/chroot /alt_inst /usr/sbin/emgr –r -n 3
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Accessing efix metadata ...
Processing efix label "IJ05822s2a" ...
...
Operation Summary
+-----------------------------------------------------------------------------+
Log file is /var/adm/ras/emgr.log

EFIX NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 IJ05822s2a          REMOVE                 SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 2
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 1
…

Nun stehen einem OS-Update keine Fixes mehr im Weg!

Nach dem OS-Update können auf ähnliche Weise neue Fixes noch vor dem Reboot in der altinst_rootvg installiert werden. Wir mounten zunächst das Verzeichnis mit den Fixes unter /alt_inst/mnt:

# mount aixnim:/export/nim/lpps/aix710503lpp /alt_inst/mnt
#

Und installieren anschließend die Fixes wieder mit Hilfe von chroot und INUCLIENTS direkt in der altinst_rootvg:

# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/102p_fix.181127.epkg.Z
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Efix package file is: /mnt/emgr/ppc/102p_fix.181127.epkg.Z
…
EPKG NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 102p_fix            INSTALL                SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ09621s3a.181001.epkg.Z
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ11545s0a.181127.epkg.Z
…

Als letztes muß die altinst_rootvg dann noch deaktiviert werden, hierbei sollte man auf jeden Fall noch einmal ein neues Boot-Image in der altinst_rootvg erzeugen, ansonsten bleibt das System beim Booten der altinst_rootvg hängen!

# alt_rootvg_op –S -t
Putting volume group altinst_rootvg to sleep ...
forced unmount of /alt_inst/var/adm/ras/livedump
…
forced unmount of /alt_inst
Fixing LV control blocks...
Fixing file system superblocks...
#

(Hinweis: Die Option ‚-t‚ erzwingt das Erzeugen eines neuen Boot-Images!)

Nun kann wie gewohnt die Boot-Liste umgestellt werden und das System nach dem Update rebootet werden.

 

PowerVM: Kennen Sie das Profil „last*valid*configuration“?

Vielleicht hat sich der Ein oder Andere schon mal gefragt, wie und wo die aktuelle Konfiguration einer LPAR abgespeichert ist. Sind aktuelle Konfiguration und Profil nicht miteinander synchronisiert, ergeben sich schnell Unterschiede. Wird eine LPAR heruntergefahren und deaktiviert, bleibt die letzte aktuelle Konfiguration erhalten. Beim Aktivieren der LPAR ist diese Konfiguration neben den Profilen der LPAR als „current configuration“ im GUI verfügbar. Wählt man diese aus, so besitzt die LPAR nach dem Aktivieren die gleiche Konfiguration wie vor dem Deaktivieren. Bei einer neu angelegten LPAR ist diese Auswahl hingegen beim Aktivieren nicht verfügbar. Der Unterschied äußert sich auch auf der HMC-Kommandozeile: die schon mal aktivierte LPAR kann ohne Angabe eines Profils aktiviert werden, die neu angelegte LPAR kann nur durch Angabe eines Profils aktiviert werden. Das schauen wir uns nun einmal genauer an.

(Kurzer Hinweis: Die Kommandos auf der HMC-Kommandozeile wurden direkt auf der HMC hmc01 ausgeführt.Bei den Beispiel-Ausgaben mit dem LPAR-Tool wurden die Kommandos von einem Linux-Sprungserver aus gestartet. Alle Kommandos sind immer mit beiden Varianten gezeigt!)

Wir haben hierzu die LPAR aix01 mit dem Profil „standard“ aktiviert und gebootet. Dynamische Änderungen haben wir noch keine vorgenommen. Wir schauen kurz den Status der LPAR an und überprüfen ob eine RMC-Verbindung zur HMC besteht:

hscroot@hmc01:~> lssyscfg -m p710 -r lpar --filter lpar_names=aix01 --header -F name lpar_env state curr_profile rmc_state os_version
name lpar_env state curr_profile rmc_state os_version
aix01 aixlinux Running standard active "AIX 7.1 7100-04-00-0000"
hscroot@hmc01:~>
linux $ lpar status aix01
NAME  ID      TYPE   STATUS  PROFILE    RMC   PROCS  PROCUNITS MEMORY  OS
aix01  5  aixlinux  Running  standard  active   1       -      3072    AIX 7.1 7100-04-00-0000
linux $

Um die Auswirkung einer dynamischen Änderung zu sehen, schauen wir uns den Ist-Zustand und das Profil „standard“ noch an:

hscroot@hmc01:~> lshwres -m p710 -r mem --level lpar --filter lpar_names=aix01 -F curr_mem
3072
hscroot@hmc01:~> lssyscfg -m p710 -r prof --filter profile_names=standard,lpar_names=aix01 -F desired_mem
3072
hscroot@hmc01:~>
linux $ lpar mem aix01
      MEMORY            MEMORY           HUGEPAGES
NAME   MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded    -   2048   3072  8192    0     0    0
linux $ lpar -p standard mem aix01
      MEMORY            MEMORY           HUGEPAGES
NAME   MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded    -   2048   3072  8192    0     0    0
linux $

Die LPAR hat aktuell 3072 MB Hauptspeicher, die auch im Profil „standard“ hinterlegt sind.

Nun fügen wir 1024 MB Hauptspeicher dynamisch (DLPAR) hinzu:

hscroot@hmc01:~> chhwres -m p710 -r mem -o a -p aix01 -q 1024
hscroot@hmc01:~>
linux $ lpar -d addmem aix01 1024
linux $

Jetzt schauen wir uns die resultierenden Speicher Resourcen der LPAR an:

hscroot@hmc01:~> lshwres -m p710 -r mem --level lpar --filter lpar_names=aix01 -F curr_mem
4096
hscroot@hmc01:~>
linux $ lpar mem aix01
     MEMORY            MEMORY          HUGEPAGES
NAME  MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded   -   2048   4096  8192    0     0    0
linux $

Die LPAR hat wie erwartet nun 4096 MB RAM. Doch wie sieht das Profile „standard“ aus?

hscroot@hmc01:~> lssyscfg -m p710 -r prof --filter profile_names=standard,lpar_names=aix01 -F desired_mem
3072
hscroot@hmc01:~>
linux $ lpar -p standard mem aix01
     MEMORY            MEMORY          HUGEPAGES
NAME  MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded   -   2048   3072  8192    0     0    0
linux $

Das Profile hat sich nicht geändert, beim Aktivieren mit diesem Profil würde das System mit 3072 MB gestartet werden.

Die aktuelle Konfiguration wird immer im speziellen Profil „last*valid*configuration“ gespeichert:

hscroot@hmc01:~> lssyscfg -m p710 -r prof --filter profile_names=last*valid*configuration,lpar_names=aix01 -F desired_mem
4096
hscroot@hmc01:~>
linux $ lpar -p last*valid*configuration mem aix01
     MEMORY            MEMORY          HUGEPAGES
NAME  MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded   -   2048   4096  8192    0     0    0
linux $

Hier ist der Wert von 4096 MB zu finden, übereinstimmend mit dem aktuell verfügbaren Speicher in der LPAR.

Jede dynamische Aenderung an einer LPAR wird zum Einen per DLPAR-Operation auf der LPAR umgesetzt und zum Anderen in diesem speziellen Profil hinterlegt! Wird ein Profil manuell oder automatisch synchronisiert, dann wird letztlich dieses spezielle Profil mit dem gewünschten Profil synchronisiert.

Die Existenz und Handhabung des speziellen Profils „last*valid*configuration“ macht auch einige Möglichkeiten bei LPM leichter verständlich. Damit werden wir uns in einem späteren Blog-Beitrag noch einmal beschäftigen.