Ändern der PVID eines Physical Volumes

Jedes Physical Volume das vom AIX LVM verwendet wird, besitzt eine eindeutige Physical Volume ID, kurz PVID. Die PVID ist eine Software-generierte ID, die im Header Bereich einer Platte (Block 0) abgespeichert wird. Wenn eine neue Platte einem AIX System hinzugefügt wird, dann besitzt das neue Physical Volume noch keine PVID. Sobald ein Physical Volume einer Volume Group hinzugefügt wird, wird eine PVID generiert, wenn das Physical Volume noch keine PVID haben sollte. Eine schon existierende PVID wird übernommen.

Eine PVID kann auch manuell mit Hilfe des Kommandos chdev erzeugt werden. Dabei wird das Attribut pv auf den Wert yes gesetzt:

# chdev -l hdisk3 -a pv=yes
hdisk3 changed
#

Die gesetzte PVID kann entweder mit dem Kommando lsattr oder auch einfach mit lspv angezeigt werden:

$ lsattr -El hdisk3 -a pvid -F value
00c276b0084049750000000000000000
$
$ lspv |grep hdisk3
hdisk3          00c276b008404975                    None                       
$

Eine PVID kann auch wieder entfernt werden. Dazu darf das Physical Volume allerdings nicht in Verwendung sein (.z.B. als Teil einer Volume Group).

Um eine PVID eines Physical Volumes zu löschen, kann das Attribut pv auf den Wert clear gesetzt werden:

# chdev -l hdisk3 -a pv=clear
hdisk3 changed
#

Die PVID wurde entfernt, wie die nachfolgenden Aussagen zeigen:

$ lsattr -El hdisk3 -a pvid -F value
none
$
$ lspv |grep hdisk3
hdisk3          none                                None                       
$

Der Versuch die PVID eines Physical Volumes zu löschen, das in Verwendung ist, führt zu der folgenden Fehlermeldung:

# chdev -l hdisk0 -a pv=clear
Method error (/usr/lib/methods/chgdisk):
        0514-062 Cannot perform the requested function because the
                 specified device is busy.
     pv    

#

 

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

ProbeVue in Action: Überwachen der „Queue Depth“ von Platten

Platten und Storage Systeme unterstützen Tagged Command Queueing, d.h. angeschlossene Server können mehrere I/O Aufträge an die Platte oder das Storage-System senden ohne zu Warten das ältere I/O-Aufträge fertig sind. Wieviele I/O-Aufträge man an eine Platte senden darf, bevor man warten muss das ältere I/O-Aufträge abgeschlossen wurden, kann über das hdisk Attribut queue_depth unter AIX konfiguriert werden. Für viele hdisk Typen ist der Wert 20 für die queue_depth der Default-Wert. In der Regel erlauben die meisten Storage-Systeme aber noch größere Werte für die Queue-Depth.

Mit Hilfe von ProbeVue lässt sich die Auslastung der Platten-Queue sehr leicht beobachten.

Ab AIX 7.1 TL4 bzw. AIX 7.2 TL0 unterstützt AIX den I/O Probe Manager. Damit lassen sich auf einfache Weise Ereignisse im I/O Stack von AIX tracen. Wird ein I/O vom Platten-Treiber gestartet, so geschieht dies über die Funktion iostart im Kernel, der Request wird an den Adapter-Treiber weitergegeben und geht dann über den Host-Bus-Adapter an das Storage-System. Das Bearbeiten der Antwort wird von der Funktion iodone im Kernel übernommen. Der I/O Probe-Manager unterstützt (unter anderem) Proben an diesen Stellen:

@@io:disk:iostart:read:<filter>
@@io::disk:iostart:write:<filter>
@@io:disk:iodone:read:<filter>
@@io::disk:iodone:write:<filter>

Als Filter kann z.B. ein Hdisk Name wie hdisk2 angegeben werden. Die Proben-Punkte lösen dann nur Ereignisse für die Platte hdisk2 aus. Damit lässt sich schon einmal eine Aktion durchführen wann immer ein I/O für eine Hdisk beginnt oder endet. Damit könnte man z.B. messen wie lange eine I/O Operation dauert oder auch einfach nur mitzählen wieviele I/Os ausgeführt werden. In unserem Beispiel waren wir aber an der Auslastung der Platten-Queue interessiert, d.h. der Anzahl I/Os die an die Platte gesendet aber noch nicht abgeschlossen wurden. Der I/O Probe-Manager besitzt für die I/O Ereignisse  iostart und iodone die Builtin-Variable __diskinfo mit den folgenden Feldern (https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.genprogc/probevue_man_io.htm):

name          char*     Name der Platte
…
queue_depth   int       Die Queue-Depth der Platte (Wert aus der ODM)
cmds_out      int       Anzahl der ausstehenden I/Os
…

Das Feld cmds_out gibt an wieviele I/Os an die Platte gesendet wurden, für die das I/O noch nicht abgeschlossen ist (Antwort ist noch nicht beim Server angekommen).

Mit dem folgenden Code-Abschnitt ermitteln wir die minimale, maximale und durchschnittliche Anzahl an Einträgen in der Platten-Queue:

@@io:disk:iostart:*:hdisk0     // Nur I/Os für hdisk0 berücksichtigen
{
   queue = __iopath->cmds_out; // Anzahl ausstehende I/Os in Variable queue festhalten
   ++numIO;                    // Anzahl I/Os in der Variablen numIO mitzählen (wegen Durchschnittsbildung)
   avg += queue;               // Variable avg um Anzahl ausstehende I/Os erhöhen
   if ( queue < min )
      min = queue;             // Überprüfen auf Minimum und gegebenenfalls setzen
   if ( queue > max )
      max = queue;             // Überprüfen auf Maximum und gegebenenfalls setzen
}

Die ermittelten Werte geben wir dann einmal pro Sekunde mit Hilfe des Intervall Probe-Managers aus:

@@interval:*:clock:1000
{
   if ( numIO == 0 )
      numIO = 1;    // Verhindert Division durch 0 bei der Durchschnittsbildung
   if ( min > max )
      min = max;
   printf( "%5d  %5d  %5d\n" , min , avg/numIO , max );
   min = 100000;   // Zurücksetzen der Variablen für das nächste Intervall
   avg = 0;
   max = 0;
   numIO = 0;
}

Das vollständige Skript ist auf unserer Webseite zum Download verfügbar: ioqueue.e.

Hier ein Beispiel-Lauf des Skriptes für die Platte hdisk13:

# ./ioqueue.e hdisk13
  min    avg    max
    1      1      2
    1      1      9
    1      1      2
    1      1      8
    1      1      2
    1      1      2
    1      1      8
    1      1     10
    1      1      2
    1      1      1
    1      1     10
    1      1      2
    1      1     11
...

Das Skript erwartet die Angabe einer hdisk als Argument und gibt dann einmal pro Sekunde die ermittelten Werte für die angegebene hdisk aus.

In der Beispiel-Ausgabe sieht man das die maximale Anzahl der Einträge in der Platten-Queue 11 ist. Eine Erhöhung des Attributes queue_depth macht daher aus Performance-Sicht keinen Sinn.

Hier ein anderes Beispiel:

# ./ioqueue.e hdisk21
  min    avg    max
    9     15     20
   11     17     20
   15     19     20
   13     19     20
   14     19     20
   17     18     20
   18     18     19
   16     19     20
   13     18     20
   18     19     19
   17     19     20
   18     19     20
   17     19     19
...

In diesem Fall wird der maximale Wert 20 (die hdisk21 hat eine queue_depth von 20) regelmäßig erreicht. Eine Erhöhung der queue_depth kann in diesem Fall zu einer Verbesserung des Durchsatzes führen.

Das Beispiel-Skript lässt sich natürlich noch beliebig erweitern, man könnte z.B. noch den Durchsatz erfassen, oder die Wartezeit von I/Os in der Wait-Queue oder auch die Position und Größe jedes I/Os auf der Platte. Das dargestellte Beispiel zeigt wie einfach man Informationen zu I/Os mit Hilfe von ProbeVue ermitteln kann.

Weitere Artikel zum Thema ProbeVue

ProbeVue: Praktische Einführung

ProveVue: Praktische Einführung II

ProbeVue in Action: Identifizieren eines Abstürzenden Prozesses

ProbeVue in Action: Überwachen der „Queue Depth“ von Platten