AIX


timing for 32 KB FC-I/O

Maximaler Durchsatz bei FC

Die einzelnen Phasen eines I/Os in einem FC-SAN werden gezeigt. Anschließend wird auf ein Modell mit nur noch 3 Phasen vereingacht. Die tatsächliche Zeitdauer für die einzelnen Phasen wird in einem Diagramm für einige FC-Technologien gezeigt. Als entscheidend für die Dauer eines I/Os stellt sich die Round-Trip-Time heraus. Darauf aufbauend wird der maximal mögliche Durchsatz eines einzelnen I/Os ermittelt und graphisch für verschiedene I/O-Größen in Abhängigkeit von der Round-Trip-Time gezeigt.

 


Troubleshooting problems with extendlv
Troubleshooting problems with extendlv
AIX LVM: Fehlersuche bei Problemen mit extendlv und Dateisystem-Vergrößerung

Beim Vergrößern von Logical Volumes oder Dateisystemen kommt es häufig zum Fehler “0516-404 allocp: This system cannot fulfill the allocation request“. Viele AIX Administratoren sind dann erst einmal etwas ratlos, was die Ursache für das Problem ist: liegt es an max LPS oder upper bound, an der gewählten Strictness oder hat das Problem ganz andere Ursachen. Die Fehlermeldung ist leider nur generisch und sagt nicht was das eigentliche Problem ist. Eine gute Möglichkeit dem Problem auf den Grund zu gehen, ist der alog lvmt, in diesem werden alle LVM Aktionen, insbesondere der Low-Level Kommandos, inklusive Fehlermeldungen mitprotokolliert. Im Folgenden soll anhand von einer Reihe von Beispielen gezeigt werden, wie nützlich dieser Log ist, um in vielen Fällen relativ schnell die Ursache des geschilderten Problems zu finden.


AIX LVM: Mechanik von migratepv (Part I)

Mit dem AIX LVM Kommando migratepv können Physical Volumes in Spiegel-Kopien von Logical Volumes ausgetauscht werden. Wir wollen uns genauer anschauen wie das Kommando migratepv im Detail arbeitet. Anhand einiger Beispiele werden die Fälle ungespiegeltes Logical Volume, gespiegeltes Logical Volume (2 Kopien) und gespiegeltes Logical Volume (3 Kopien) gezeigt.


AIX LVM: Mechanik von migratepv (Part II)

Mit dem AIX LVM Kommando migratepv können Physical Volumes in Spiegel-Kopien von Logical Volumes ausgetauscht werden. Im zweiten Teil wollen wir uns genauer anschauen wie das Kommando migratepv im Falle von gespiegelten Logical Volumes mit 3 Kopien arbeitet.


Mirrored logical volume from practice
Mirrored logical volume from practice
AIX LVM: Mechanik von migratepv (Part III)

Mit dem AIX LVM Kommando migratepv können Physical Volumes in Spiegel-Kopien von Logical Volumes ausgetauscht werden. Im dritten Teil geht es um die Korrektur „falscher“ Spiegelung. Die auftretenden Möglichkeiten werden diskutiert. Anhand eines größeren Beispiels aus der Praxis werden die gezeigten Möglichkeiten demonstriert.


AIX LVM: Mechanik von migratelp

Mit dem AIX LVM Kommando migratelp können einzelne Physical Partitions in einem Logical Volume ausgetauscht werden. Im Artikel soll genauer angeschaut werden, wie das Kommando migratelp arbeitet.

 

 


AIX und Run-Time Linking

Fast alle heutigen Programme unter AIX sind dynamisch gelinkt, d.h. notwendige Bibliotheken werden zur Laufzeit geladen und gebunden (Run-Time Linking). Doch woher weiß ein Programm welche Bibliotheken benötigt werden und in welchem Verzeichnis diese zu finden sind? Was kann man tun, falls eine Bibliothek nicht automatisch gefunden wird? Welche Bedeutung haben die Variablen LIBPATH und LD_LIBRARY_PATH?

 

 


Eigene AIX installp Pakete bauen (Part 1)

Unter AIX ist es leicht installp Pakete selber zu bauen. Hierzu gibt es unter AIX das Kommando mkinstallp. Wir zeigen an einem einfachen Beispiel die Benutzung von mkinstallp. Komplexere Pakete werden in einem spätere Artikel behandelt.


Automatisierung von Inventory Scout

Im Artikel wird beschrieben welche Schritte notwendig sind, um den Inventory Scout automatisiert auf einer Reihe von Systemen laufen zu lassen. Im Anschluß wird ein Skript gezeigt (Download verfügbar), welches diese Schritte komfortabel implementiert. Das Sammeln von Microcode-Ständen auf beliebig vielen Systemen ist dann mit einem Kommando-Aufruf möglich.


Mirror Pools: Einführung

Viele IT-Umgebungen betreiben Ihre Systeme in mehr als einem Rechenzentrum. Um im Falle eines Ausfalls eines kompletten Rechenzentrums trotzdem keinen Datenverlust zu haben, werden die Daten zwischen 2 oder mehr Rechenzentren gespiegelt. Die Spiegelung kann dabei durch das Storage realisiert sein (storage based mirroring) oder durch einen Volume Manager (LVM im Falle von AIX) auf dem Server (host based mirroring). Im Folgenden betrachten wir nur Spiegelungen mittels AIX Logical Volume Manager. Dabei soll gezeigt werden, wie mit Hilfe von Mirror Pools das korrekte Spiegeln von Logical Volumes realisiert werden kann. In größeren Umgebungen mit vielen Physical Volumes ist das Einhalten einer korrekten Spiegelung ohne Mirror Pools schwierig und für den Administrator eine Herausforderung.


Mirror Pools: Verstehen der Mirror Pool Strictness

Die Verwendung von Mirror Pools vereinfacht das korrekte Spiegeln von Logical Volumes zwischen Physical Volumes aus verschiedenen Rechenzentren. Für eine möglichst große Redundanz und Ausfallsicherheit, sollte beim Spiegeln darauf geachtet werden, das alle Physical Volumes einer Spiegel-Kopie aus dem gleichen Rechenzentrum kommen. Dies lässt sich mit Mirror Pools sehr einfach erreichen. Im Folgenden soll die Bedeutung der Mirror Pool Strictness genauer erläutert werden, diese kann für jede Volume Gruppe auf einen der Werte ‚n‘ (no), ‚y‘ (yes) oder ‚s‘ (super-strict) gesetzt werden.