Schulze-EDV-Service Home - AIX Support - Neuigkeiten

LVM, SSA und Disk Management

Logical Volume Manager - LVM

Der LVM ist einer der Bestandteile von AIX, der dieses Unix zu den besten Unixen macht, die es gibt. Mit der Robustheit des journaled filesystem und den vielen Möglichkeiten Plattenplatz dynamisch zu verwalten schlägt es andere Unixe um Welten. Im Zusammenspiel mit SSA ist es nahezu unschlagbar.

Anlegen einer VG - Details

Der folgende Tip nur für AIX V4. Wenn man eine neue VG mit SMIT anlegt, wird per default davon ausgegangen, daß eine solche VG aus bis zu 32 hdisk devices bestehen kann. Für jede dieser 32 Reservierungen wird 1MB Plattenplatz benötigt. Indem man eine VG von der Kommandozeile anlegt, z.B. mit
# mkvg -d 4 hdisk0 hdisk1

erstellt man eine VG, die aus maximal 4 hdisk devices bestehen kann (und spart sich so 28MB Plattenplatz). Die Option -d existiert bei AIX V5.3 oder höher nicht mehr.

Standard JFS Log-Datei

Beim anlegen einer vg sollte unbedingt vorher ein jfs-log miterstellt werden. Das FS sollte erst nach dem jfslog angelegt werden, weil die Dateisysteme nur dann die jfslogs auch benutzen! Ansonsten ist mit chfs ein nachträgliches zuordnen von jfslog zu LV möglich.

# chlv -n newlv lv

# logform /dev/loglvxyz

Zuordnung von jfs-log auf fs ändern:

# chfs -a log=/dev/loglvxyz fs

Danach muß das Dateisystem neu gemountet werden, damit die Änderung wirksam wird.

Top

Anlegen von lv - Details

Das Anlegen von lv in einer vg ist an sich keine große Sache. Interessant wird es jedoch in Umgebung mit SSA / Fibre-Channel Platten, insbesondere wenn gespiegelte Platten über mehrere Orte verteilt sind. Wenn man unter AIX ein fs vergrößert und dazu den Befehl chfs (smitty fs) verwendet, dann ist AIX zwar in der Lage, sich den freien Platz zusammenzusuchen und dabei auch Spiegelkopien auf separate pv zu legen. AIX kann aber nicht entscheiden, in welchem SSA-Drawer / welcher ESS Shark etc. die pv genutzt werden. Daraus folgt, daß der Administrator dafür sorgen muß, daß die Daten später auf den richtigen Platten liegen. Gezielt auswählen kann man den Ort für die PP unter AIX nur, indem man zunächst das lv vergrößert und anschließend das darinliegende fs.

Das folgende Beispiel entstammt einer Installation mit zwei ESS Shark E20, die jeweils 9 Platten für eine gespiegelte vg zur Verfügung stellt (insgesamt also 18 beteiligte Festplatten).

Zunächst identifiziert man die zur vg gehörenden Platten

# lspv |grep UILP

hdisk16 005090da9c0ac18c testvgESS

hdisk17 005090da3084886b testvgESS

hdisk18 005090da30848b78 testvgESS

hdisk19 005090da30848e6f testvgESS

hdisk21 005090da6c704e39 testvgESS

hdisk22 005090da6c705116 testvgESS

hdisk23 005090da6c7053ea testvgESS

hdisk24 005090da6c7056db testvgESS

hdisk25 005090da6c7059d8 testvgESS

hdisk38 005090da5963e92d testvgESS

hdisk39 005090da2f9e1db2 testvgESS

hdisk40 005090da2f9e209f testvgESS

hdisk41 005090da2f9e2394 testvgESS

hdisk43 005090da6c705ccd testvgESS

hdisk44 005090da6c705fc2 testvgESS

hdisk45 005090da6c7062af testvgESS

hdisk46 005090da6c706594 testvgESS

hdisk47 005090da6c706879 testvgESS

root@aixSAP1 //

Jetzt kennen wir die Festplatten, wissen aber weder ob darauf noch Platz frei ist, noch in welcher ESS sich die Platten befinden. Wir suchen als nächstes Platten, mit freien pp.

# for i in $(lspv |grep testvgESS |awk '{print $1}') ; do lspv -M $i |grep-v testvgESS ; done

hdisk16:1-55

hdisk16:358-450

hdisk16:521-575

hdisk16:594-595

hdisk18:459-595

hdisk23:1-357

hdisk25:1-119

hdisk25:239-256

hdisk25:358-595

hdisk38:1-55

hdisk38:445-592

hdisk38:594-595

hdisk39:1-357

hdisk40:459-595

hdisk41:1-119

hdisk41:239-256

hdisk41:358-595

root@aixSAP1 //

#

Wir sehen an Ihrem location code (SCSI Schnittstelle) zu welcher ESS die Platten gehören.

# for i in $(lspv |grep testvgESS |awk '{print $1}') ; do lsdev -Ccdisk

|grep $i ; done

hdisk16 Available 30-70-01 IBM FC 2105E20

hdisk17 Available 30-70-01 IBM FC 2105E20

hdisk18 Available 30-70-01 IBM FC 2105E20

hdisk19 Available 30-70-01 IBM FC 2105E20

hdisk21 Available 30-70-01 IBM FC 2105E20

hdisk22 Available 30-70-01 IBM FC 2105E20

hdisk23 Available 30-70-01 IBM FC 2105E20

hdisk24 Available 30-70-01 IBM FC 2105E20

hdisk25 Available 30-70-01 IBM FC 2105E20

hdisk38 Available 40-60-01 IBM FC 2105E20

hdisk39 Available 40-60-01 IBM FC 2105E20

hdisk40 Available 40-60-01 IBM FC 2105E20

hdisk41 Available 40-60-01 IBM FC 2105E20

hdisk43 Available 40-60-01 IBM FC 2105E20

hdisk44 Available 40-60-01 IBM FC 2105E20

hdisk45 Available 40-60-01 IBM FC 2105E20

hdisk46 Available 40-60-01 IBM FC 2105E20

hdisk47 Available 40-60-01 IBM FC 2105E20

Die freien Platten habe ich zur besseren Darstellung farbig markiert. Mit diesen Information kann man nun 2, 4, 6, etc. Platten aussuchen (zu Pärchen gruppieren), von denen jeweils eine unter 30-70-01 an der einen bzw. unter 40-60-01 an der anderen Shark hängen. In der Regel wird der Datentransfer schneller, wenn mehr (physikalische) Platten gleichzeitig beteiligt sind.

Top

Anlegen von LV - Probleme mit der mount Reihenfolge

Top

Exportieren von volume-groups

Nach Möglichkeit sollte man vor dem export einer VG einen reboot durchführen, da ein exportvg zwar die Einträge aus der /etc/filesystems entfernt aber nicht die mountpoints.

Top

Verkleinern eines lv bei AIX 4.3

Der LVM bis AIX 4.3 kann kein Dateisystem im laufenden Betrieb verkleinern, da keine Möglichkeit besteht, den Superblock des Dateisystem zu aktualisieren. Es ist aber möglich mit zwei low-level Befehlen ein logical volume zu verkleinern. Auch aus diesem Grund ist es sinnvoll beim Vergrößern eines Dateisystems zunächst das darunterliegende logical volume zu vergrößern und erst danach das Dateisystem.

Der Befehl zum verkleinern eines logical volumes ist

# lreducelv -l <vg_minor_number> -s <size> filename

Size sind die Anzahl der PP, die entfernt werden sollen. Filename enthält die Deallocation Map. Bevor man lreducelv benutzt, sollte man mit defragfs das Dateisystem defragmentieren. Mit dem Befehl

# lquerylv -L <LVid> -r > mapfile

bekommt man ein mapfile. In diesem map file dürfen nur diejenigen partitionen enthalten sein, die man entfernen möchte. Danach muß mit putlvcb -n der lvcb neu geschrieben werden. Anschließend muß noch die ODM aktualisiert werden.

Beispiel, bei dem die 32 letzten PP des LV abgeschnitten werden.

# lquerylv -L 00354fca00004c00000000fd94d5df50.22 -r |tail -32 >applv.map

# lreducelv -l 00354fca00004c00000000fd94d5df50.22 -s 32 applv.map

# putlvcb -n 32 applv

# synclvodm datavg

Top

Umbenennen einer Volume Group

Zunächst wird der Name aus der ODM getilgt. Bei diesem Kommando wird der Inhalt der phys. Platten nicht verändert.

# exportvg <VG_alter_name>

dann

# importvg -y <VG_neuer_name>

Top

Neuanlegen einer rootvg bei ODM Problemen im lfd. Betrieb

Das folgende Skript dient als Anhalt, wie eine rootvg bei ODM Problemen im lfd. Betrieb exportiert und dann neu importiert wird. Ablauf ist wie folgt: alle Referenzen auf rootvg werden aus er ODM gelöscht. Anschließend wird ein importvg auf eine hdisk der rootvg gemacht und danach ein varyonvg.

#!/usr/bin/ksh

# Troubleshooting ODM Problems with the rootvg

# Write down the volumegroup's name and major number

# Identify at least on intact disk of the vg

# Export the VG the undocumented way (with odmdelete)

# Re-import the VG from the disk identified.

# (Ignore warning messages, works anyway)

# It is not necessary to unmount a file system

# or to stop processes!

MajorNumber=10

PV=/dev/ipldevice

VG=rootvg

lqueryvg -Lp $PV | awk '{ print $2 }' | while read LVname; do

odmdelete -q "name = $LVname" -o CuAt

odmdelete -q "name = $LVname" -o CuDv

odmdelete -q "value3 = $LVname" -o CuDvDr

done

odmdelete -q "name = $VG" -o CuAt

odmdelete -q "parent = $VG" -o CuDv

odmdelete -q "name = $VG" -o CuDv

odmdelete -q "name = $VG" -o CuDep

odmdelete -q "dependency = $VG" -o CuDep

if [ "$VG" = rootvg ]

then

odmdelete -q "value1 = $MajorNumber" -o CuDvDr

else

odmdelete -q "value1 = $VG" -o CuDvDr

fi

odmdelete -q "value3 = $VG" -o CuDvDr

importvg -y $VG $PV # ignore lvaryoffvg errors

varyonvg $VG

synclvodm -v $VG

savebase

Das war das Original aus der AIX 4.3 Doku:

http://publib16.boulder.ibm.com/pseries/en_US/infocenter/base/43_docs/aixprob/prbslvgd/reintrootvg.htm

Top

Defekte VGDA im lfd. Betrieb reparieren

Praxistip: Das einfachste Reparaturprogramm für Volume Groups ist das Kommando varyonvg selbst.

# varyonvg fehlervg

Top

VGDA auslesen

Es gibt von IBM ein kleines (inoffizielles) tool, mit dem man Informationen über die volume group descriptor area auslesen kann. Es heißt vgda_read.

Ab AIX 5L gibt es /usr/sbin/readvgda, das in etwa dasselbe leistet (wahrscheinlich eine Weiterentwicklung des inoffiziellen vgda_read.)

# /usr/sbin/readvgda /dev/hdisk0 | more

Um den VGDA selbst jetzt z.B. zu IBM schicken zu können, wird der folgende Befehl verwendet:

# dd if=/dev/hdisk0 of=/tmp/hdisk0.vgda count=2*vgda_len+2*vgsa_len

Die Information über vgda_len und vgsa_len wird von den beiden vorgestellten tools angegeben.

Top

PVID auf hdisk neu schreiben

Die hexadezimale ID des PV (aus zweier-Pärchen) in Octalzahlen übersetzen:

Aus z.B. 00 12 a3 e4 2b c9 08 f3 wird 000 022 243 344 053 311 010 363. Anschließend schreibt man die binäre Version der PVID mit dd auf die physikalische Platte, dabei wird jeder Octalzahl noch „\0“ (Backslash und Null). Es dürfen keine Leerzeichen etc. dazwischen sein. Am Abschluß kommt ein „\c“ (verhindert einen harten Return).

# echo "\0000\0022\0243\0344\0053\0311\0010\0363\c" |dd of=/dev/hdisk0 bs=1 seek=128

Leicht abgeänderte Variante:

# echo " \000\000\0122\043\0110\0170\0137\0223\000\000\000\000\000\000\000\000" | dd of=/dev/hdisk0 seek=8 count=1 bs=16c

Top

Defekten LVCB reparieren

Der LVCB belegt die ersten 512 Byte eines LVs. Wird er beschädigt oder überschrieben, dann kann man ihn vollständig wiederherstellen, solange die korrespondierende Information in der ODM noch vorhanden ist. Dazu bedient man sich eines Skriptes updatelv, das mit AIX 4.3.3 mitgeliefert wird. In Version 5L wurde es offenbar nicht mehr beigelegt, es funktioniert aber unverändert zumindest noch unter 5.1 (getestet) und wahrscheinlich noch unter 5.2 (ausprobieren).

Man erstellt zunächst ein LV in derselben VG (Größe 1 PP reicht vollkommen).

# dd if=/dev/<mytemplv> bs=1b count=1 of=/dev/<damagedlv>

# /usr/sbin/updatelv <damagedlv> <VGname>

Danach kann das temporäre LV wieder gelöscht werden. Den Inhalt des LVCB kann man sich mit

# getlvcb -AT <ex-damagedlv>

anzeigen lassen. Wer sich für die Low-Level Befehle des LVM interessiert, dem sei der AIX-Survival Guide von Andreas Siegert oder das LVM Redbook empfohlen.

Beispiel für eine kombinierte Reparatur von Superblock und LVCB.

Top

Defekten Dateisystem Superblock reparieren

Praxis Tip: wenn Sie nur einen von zwei Superblocks verloren haben, einer also noch in Ordnung ist, dann sollten Sie zunächst versuchen den Superblock durch fsck reparieren zu lassen. Diese Möglichkeit bietet fsck ab AIX V4.

# fsck -p /dev/kaputtes_lv

Um den Zustand eines LV oder auch das Ergebnis dieser Reparatur zu prüfen setzen Sie fsck ohne Parameter auf das LV an.

Eine zweite, etwas rustikalere Lösung ist die manuelle Reparaturvariante. Der Superblock liegt in jedem LV zweimal vor, bei jfs einmal im Block 1, eine Kopie im Block 31. Auch die manuelle Methode setzt voraus, daß eine unbeschädigte Kopie des Superblock zur Verfügung steht. Aus dieser Kopie kann er einen defekten Block 1 überschreiben und so (ähnlich wie bei der Reparatur des LVCB) reparieren.

# dd count=1 bs=4k skip=31 seek=1 if=/dev/damagedlv of=/dev/damagedlv

1+0 records in.

1+0 records out.

Danach Dateisystem mit fsck überprüfen.

Beispiel für eine kombinierte Reparatur von Superblock und LVCB.

Top

Testen ob von pv gelesen werden kann

# lquerypv -h /dev/hdiskx

Von IBM selbst gibt es ein (nicht offizielles) Tool namens VGDA_read, mit dem der vgda eines hdisk devices gelesen werden kann.

Top

SCSI - Disk Reservierung brechen

Manchmal bleibt das SCSI Disk Reservierungsbit auf den hdisk oder vpath devices bestehen, so daß sie nicht mehr in Zugriff genommen werden können. Um dem abzuhelfen wird mit HACMP ein kleines Hilfsprogramm mitgeliefert, das die Reservierung gewaltsam bricht. Beispiel:

# /usr/es/sbin/cluster/utilities/cl_SCSIdiskreset /dev/vpathx

Alternativ gibt es ein low-level tool, das dasselbe leistet: lquerypr

Für den SCSI Rest von EMC devices gibt es ein Tool von EMC

Top

Persistent Key Reservation Problem

aserver #lquerypr -Vh /dev/hdisk4

connection type: fscsi0

open dev: /dev/hdisk4

Attempt to read reservation key...

*> ioctl(PR_READ) error; errno = 5 (I/O error)

*> status_validity=0x1, scsi_bus_status=0x2

Attempt to read reservation key...

Attempt to read registration keys...

Read Keys parameter

Generation : 2

Additional Length: 32

Key0 : 52a34d02

Key1 : 52a34d02

Key2 : 52a34d02

Key3 : 52a34d02

Reserve Key provided by current host = c83aeb03

Reserve Key on the device: 52a34d02

aserver #lspv

hdisk0 00c83beae0d299e6 rootvg active

hdisk1 00c83beae0f92a07 None

hdisk2 00c83beae1c81809 rootvg active

hdisk3 00c83beae1c81a1d None

hdisk4 none None

hdisk5 none None

hdisk6 none None

hdisk7 none None

hdisk8 none None

hdisk9 none None

hdisk27 none None

[...]

vpath0 none None

vpath1 none None

vpath2 none None

vpath3 none None

vpath4 none None

vpath5 none None

vpath6 none None

vpath7 none None

vpath8 none None

vpath9 none None

vpath10 none None

vpath11 none None

aserver #lquerypr -Vh /dev/vpath0

open device /dev/vpath0

setkey.compcode = 0

setkey.returncode = 1

52a34d02

Reserved with different key 52a34d02, current host key c83aeb03

aserver #

lquerypr -ph /dev/vpath0

lquerypr -Vh /dev/vpath0

lspv | grep vpath

lspv | grep vpath |cut -f1 -d" "

lspv | grep vpath |cut -f1 -d" " | while read vp ; do lquerypr -ph /dev/$vp; done

lspv | grep vpath |cut -f1 -d" " | while read vp ; do lquerypr -Vh /dev/$vp; done

sync

rmdev -dl dpo -R; rmdev -dl pci6 -R

cfgmgr -v

lspv

importvg

importvg -y sapdata1vg -V100 0052a34de5e4caef

Top

Verändern von volumegroup Definitionen bei laufendem HACMP Cluster

Die hier beschriebene Methode bezieht sich auf Standard VGs mit SCSI2 Reservierung, wie sie unter HACMP V4 genutzt werden. Unter HACMP V5+ trifft es nur zu, wenn nicht mit ECM VG gearbeitet wird. Wenn eine RS6000 eine volumegroup varyon hat, kann ein zweites System nicht darauf zugreifen weil die vg reserviert ist. Seit AIX 4.2.1 (bos.rte.lvm 4.2.1.4 oder höher) ist es aber möglich, an der reservierten vg vorgenommene Änderungen dem zweiten System beizubringen ohne die Platten vom ersten System abzuhängen. Das geschieht mit dem importvg -L Befehl. Mit der -L Option verhält sich der importvg anders als gewöhnlich, es wird zum sog. Learning Import. Normalerweise wird mit importvg eine unbekannte volumegroup dem System bekanntgegeben. Importvg -L setzt jedoch im Gegensatz dazu voraus, daß die vg bereits bekannt ist. Es ist also falsch, vor dem import die vg mit exportvg zu exportieren. Ein importvg -L ist dann nicht mehr möglich. Der 'learn' Modus prüft eine bekannte vg online auf Veränderungen, ohne sie varyon zu nehmen.

Auf dem System, das die kennenzulernende vg gerade im Betrieb hat, muß die blockierende Reservierung aufgehoben werden. Man kann zuvor den vg-Zeitstempel aktualisieren, dies beschleunigt eine Übernahme.

#  /usr/es/sbin/cluster/utilities/clvgdats /dev/hdisk<aus_vg> > /usr/es/sbin/cluster/etc/vg/<vg_name>

# varyonvg -b -u externvg

Auf dem zweiten System wird dann der import im learning mode durchgeführt. Dabei reicht es, dem Befehl eines einzigen pv mitzugeben, das zur vg gehört, da sich in dessen vgda die komplette Beschreibung der vg befindet.

# importvg -L externvg hdisk9

Auch hier kann man den Zeitstempel aktualisieren um die Übernahme zu beschleunigen.

#  /usr/es/sbin/cluster/utilities/clvgdats /dev/hdisk<aus_vg> > /usr/es/sbin/cluster/etc/vg/<vg_name>

Anschließend muß auf dem ersten Knoten die Blockierung wieder durch ein einfaches varyonvg gesetzt werden.

# varyonvg -n externvg

Aus den genannten Voraussetzungen für importvg -L folgt, daß der Befehl nicht zu gebrauchen ist, wenn exportvg durchgeführt wurde oder wenn es sich um eine gänzlich neue vg handelt. Ab AIX 4.3.2 (ev. auch schon 4.3.1) kann man in solchen Fällen anders vorgehen. Wieder muß zunächst die Reservierung aufgehoben werden. Danach wird ein regulärer import durchgeführt, importvg aber explizit angewiesen, die vg nicht varyon zu nehmen oder zu reservieren. Dies kann wieder im lfd. Betrieb erfolgen.

Reservierung aufheben auf System 1

# varyonvg -b -u externvg

Daten der vg importieren auf System 2

# importvg -Vmajornumber -yVGname -c -n -F /dev/hdisk9

Woher kommt aber die majornumber? Die Kenntnis dieser Zahl ist z.B. unabdingbar in einem HACMP Cluster, der NFS nutzt, da die shared vg auf allen Knoten des Clusters mit identischen majornumbers bekannt sein müssen. Man liest sie aus mit ls -al /dev/hdiskx und kann sie anschließend mit der Option -V beim import setzen.

# ls -al /dev/hdisk9

brw------- 1 root system 52, 1 Dec 12 23:54 /dev/hdisk1

#

In diesem Beispiel ist die lvmajor die 52. Um herauszufinden, welche lvmajor in einem System noch frei ist (und in einem HACMP Cluster verwendet werden soll / kann) muß man auf allen beteiligten (zukünftigen) Knoten prüfen, welche Nummern noch nicht vergeben sind. Das geschieht mit dem Befehl: lvlstmajor.

# lvlstmajor

52...

#

Die Option -c ist zuständig für concurrent capable vg in einem HACMP Cluster, -F beschleunigt den import indem es die gelesenen Werte nicht über alle pv der vg abgleicht. Die Option -n ist besonders wichtig, sie sorgt dafür, daß die vg nicht varyon genommen wird. Solche Details finden sich in der AIX-Doku. Ab AIX 5L kann eine vg schreibgeschützt varyon genommen werden mit -r.

Wenn das importvg abgeschlossen ist, wird die freigegebene vg auf dem ersten System durch ein einfaches varyonvg wieder reserviert und gegen fremde Zugriffe blockiert.

# varyonvg externvg

Top

SSA

Zwei Tools, die die Arbeit mit SSA-Systemen sehr erleichtern, sind die Programme maymap und storx. Beide Programme bilden eine bestehende SSA-Installation (die loop) ab, identifizieren dabei die SSA-Platten bzw. Adapteranschlüsse und zeigen auch, wo die loop offen ist. Beide Programme gehören leide nicht zum AIX Betriebssystem, man findet aber zumindest maymap, das in der shell läuft, noch sehr häufig 'in freier Wildbahn'.

Storx erledigt dasselbe noch etwas komfortabler unter der MS Windows GUI, bietet einen Live-Viewer, mit dem man sehen kann, was die SSA-Installation gerade macht (z.B. wenn wg. tech. Fehler dauernd die Verbindungen neu ausgehandelt werden) und einen SSA-Planer. Aus beiden Anwendungen können BMP bzw. GIFs erstellt werden, die sich wegen ihrer Übersichtlichkeit in Dokumentationen sehr bewährt haben.

Von storx gibt es eine 60-Tage Testversion, nach Eingabe von ein paar Informationen in ein Registrierungsformular soll man auf eine Download-Seite weitergeleitet werden. Diese Möglichkeit funktioniert leider seit Frühjahr 2001 nicht mehr, auf der Seite mit dem Formular wird man unmittelbar aufgefordert einen Benutzernamen mit Kennwort einzugeben. Wer nicht bereits registriert ist, hat Pech. An die Testversion kommt man dennoch, und zwar über die Seite mit den Storx-Fixes. Siehe u. AIX-Links. Der sog. Fix ist eine vollständige Version, die keine bestehende storx-Installation voraussetzt.

Bei Planung einer neuen SSA-Installation beginnt man am besten mit der Adapter-Verkabelung und erst danach mit den nötigen Platten.

http://www.storage.ibm.com/hardsoft/products/ssa/

SSA-Adapter Documentation: http://www.storage.ibm.com/hardsoft/products/ssa/docs/index.html

Top

SSA-Adapter Kompatibilität

http://www.storage.ibm.com/hardsoft/products/ssa/docs/config_rules.html#compatability

Top

SSA-Adapter / SSA-Festplatten

Jeder SSA-Adapter und jede SSA-Festplatte hat eine eigene MAC Adresse (die nicht der pvid entspricht), ein SSA-Adapter jedoch nur eine einzige MAC-Adresse für A UND B Loop. Deshalb darf man A und B Loop eines Adapters nicht mischen.

Man darf auch nicht jeden SSA-Adapter mit jedem anderen SSA-Adapter in eine Loop bringen, zum Teil funktionieren sie überhaupt nicht miteinander, z.T. funktionieren sie dann (RAID) nur wenn max. 2 Adapter zusammengeschaltet sind. Hier hat sich IBM leider nicht besonders viel Mühe gegeben, bzw. einen Quell ewigen Ärgers geschaffen. Besonderes Augenmerk muß man auf Typ und Microcode-Level der Adapter richten, wenn es um HACMP-Cluster geht. Wenn es nicht um HACMP Cluster geht, ist es jedoch möglich Adapter mit identischem Microcode unter verschiedenen AIX Versionen zu nutzen. Kurzfristig geht das auch unter HACMP, z.B. für den Zeitraum eines BOS Upgrade der cluster nodes.

Den Microcode-Level bekommt man mit lscfg -vl ssa0 angezeigt, es ist der Eintrag ROS Level and ID. Mit AIX 4.3.3 (konkret auf CDs seit Okt. 2000, bzw. im Internet) gibt es den sog. Inventory Scout (invscout), der die RS6000 durchsucht, mittels Java einen Report an einen Rechner von IBM hochlädt und anschließend fällige updates zurückmeldet. Das ist die bequemste Möglichkeit alles auf dem neuesten Stand zu halten, vorausgesetzt die RS6000 ist am Internet angebunden.

Die MAC-Adresse der Festplatten wird außerdem zur logischen Anordnung der Platten je Adapter verwendet. Das kann dann problematisch werden, wenn man eine SSA-Platte austauscht und nun eine 'jüngere' MAC Adresse vor den 'alten' MAC Adressen steht. Es kommt erschwerend hinzu, daß seit AIX 4.3.3 der cfgmgr für alle child-devices desselben Typs nicht mehr sequentiell, sondern parallel abarbeitet (aus Geschwindigkeitsgründen). Deshalb sollte man nach einer Neuinstallation alle SSA-Platten (hdisk und pdisks!) löschen und dann mit cfgmgr -S -vl ssar wieder neu (seriell) einlesen lassen.

Innerhalb einer SSA-loop sollten max. 3 dummy disks in Folge gesteckt sein, da die dummies keine Signalverstärkung haben und dies wie ein Bruch im loop wirken kann. Innerhalb eines SSA-drawers sollten aber auch keine dummies herausgezogen werden (= keine slots frei sein), da sonst die Kühlung des drawers nicht richtig funktioniert.

Top

Austausch einer defekten pdisk

Nachdem ein in der Diagnose bzw. im errpt angezeigter Fehler des SSA Subsystems repariert wurde, muß diese Reparatur dem System bekannt gegeben werden. Andernfalls melden die aus der root crontab laufenden Diagnose Routinen weiterhin den Fehler obwohl er beseitigt wurde:

# SSA warning : Deleting the next two lines may cause errors in redundant hardware to go undetected.

01 5 * * * /usr/lpp/diagnostics/bin/run_ssa_ela 1>/dev/null 2>/dev/null

0 * * * * /usr/lpp/diagnostics/bin/run_ssa_healthcheck 1>/dev/null 2>/dev/null

# SSA warning : Deleting the next line may allow enclosure hardware errors to go undetected

30 * * * * /usr/lpp/diagnostics/bin/run_ssa_encl_healthcheck 1>/dev/null 2>/dev/null

# SSA warning : Deleting the next line may allow link speed exceptions to go undetected

30 4 * * * /usr/lpp/diagnostics/bin/run_ssa_link_speed 1>/dev/null 2>/dev/null

#

Die Benachrichtigung wird in der Diagnose vorgenommen:

# smitty diag

   Current Shell Diagnosttics

   Task Selection (Diagnostics, Advanced Diagnostics, Service Aids, etc.)

   Log Repair Action

     <Betroffenes device auswählen, mit F7 bestätigen>

Top

SSA Fehlermeldungen (AIX error logger)

IDENTIFIER DESCRIPTION

================================================================

SSA_LINK_ERROR       SSA serial link failures

SSA_LINK_OPEN        SSA serial link open

SSA_DETECTED_ERROR   SSA detected failures

SSA_DEVICE_ERROR     SSA device failures

SSA_DEGRADED_ERROR   SSA Degraded Condition

SSA_HDW_ERROR        SSA Hardware Error Condition

SSA_HDW_RECOVERED    Recovered SSA Hardware Error

SSA_SOFTWARE_ERROR   SSA Software or microcode errors

SSA_LOGGING_ERROR    Unable to log against a pdisk

SSA_ARRAY_ERROR      SSA RAID Array detected error

SSA_SETUP_ERROR      SSA configuration error

SSA_CACHE_ERROR      SSA cache error

SSA_DISK_ERR1        DASD Detected Software Error

SSA_DISK_ERR2        DASD statistical data

SSA_DISK_ERR3        Recovered SSA Disk Media Error

SSA_DISK_ERR4        Physical Volume Hardware Error

Top

PV missing nach Ausfall fibre channel adapter in E20

Eine E20 (ESS Shark) ist im Prinzip nichts anderes als zwei F50 mit zwei SSA Stapeln in einem Schrank, die wie ein HACMP Cluster verkabelt sind. Intern läuft die E20 auf einem abgespeckten AIX 4.3.2 Betriebssystem. Aus diesem Aufbau rühren viele Gemeinsamkeiten bei der Bedienung aber auch bei den Problemen her. Ist die fibre channel Verkabelung z.B. nicht über einen FC Switch geführt (also nicht redundant ausgelegt), sondern nur als point-to-point Verbindung realisiert, gehen bei Problemen mit dem Kabel oder dem FC Adapter die angeschlossenen SSA-Platten in den Zustand missing. (Dasselbe gilt natürlich auch für den Fall des Austausches eines (der vier) FC Adapter in der E20, für den mindestens 2 Bays stillgelegt werden müssen). Wenn das Verbindungsproblem nur eine kurze Unterbrechung war, quasi ein Schluckauf in der Verbindung, dann kann es trotzdem sein, daß die Platten zunächst nicht mehr angesprochen werden können und alle mirrors als open/stale markiert werden. Theoretisch reicht es den cfgmgr über die FC-Adapter des angeschlossenen Servers laufen zu lassen und anschließend die betroffenen vg wieder varyon zu nehmen. In der Praxis kann es aber vorkommen, daß diese Funktion erst nach eineinhalb bis zwei Stunden erfolgreich ausgeführt werden kann.

# cfgmgr -vl fcs0

# varyonvg missingvg  (wenn Synchronisation nicht gleich ausgeführt werden soll ?-n? Schalter setzen).

Top

Quorum

Bei allen AIX oslevel < 5.3 TL 07 konnte das Quorum nur aktiviert werden, indem man die betroffene VG nach der Änderung der Einstellung varyoff und anschließend wieder varyon genommen hat. Für die rootvg bedeutete dies jedesmal einen reboot. Das Unangenehmste bei der Änderung des Quorum mittels

# chvg -Qn <myvg>

war dabei, daß man mit

# lsvg <myvg>

nur sehen konnte, ob die Einstellung gesetzt wurde - nicht jedoch, ob sie bereits im Treiber aktiv ist. Es war deshalb möglich, daß eine VG vom LVM nach Wegfall eines Spiegels die VG abgeschaltet wurde, ohne daß man diese Gefahr durch eine entsprechende Überprüfung ausschließen konnte.

Im Dezember 2007 wurde ein lowlevel Kommando um die Möglichkeit erweitert, den Status des Treibers auf aktives bzw. inaktives Quorum abzufragen. Konkret ist das möglich ab 5.2 ML 10, 5.3 TL 06+.

#  lqueryvg -p <hdisk> -Q

0

Eine "0" bedeutet: Quorum der zu dieser hdisk gehörenden VG ist aus, eine "1" hingegen bedeutet Quorum ist an. Die Erweiterung des lqueryvg Kommandos ist nicht dokumentiert, Hinweise finden sich nur in den entsprechenden APARs (5200-10 - AIX APAR IZ00121; 5300-06 - AIX APAR IY97594; 5300-07 - AIX APAR IY98763)

Ab 5.3 TL 07 bzw. AIX 6.1 kann das Quorum im lfd. Betrieb ein- oder ausgeschaltet werden. Ein varyoffvg/varynvg ist dann nicht mehr nötig.

Top

Reorganisation von ESS Platten

Anzeigen - (Um-)Konfigurieren - devices vereinheitlichen

Auf einer ESS werden virtuelle hdisks aus realen hdisks abgebildet. Dabei kann eine virtuelle hdisk ein Teil (chunk) einer realen Festplatte sein, oder aber auch aus vielen realen Platten bestehen, wodurch solche devices sehr groß werden können. Vorteile solcher Platten sind neben ihrer schieren Größe auch, daß die Daten über mehrere Platten gleichzeitig gestript sind, wodurch die Lese- und Schreibgeschwindigkeit i.d.R. deutlich höher ist, als von einer einzelnen Platte. Meist kommt bei solchen Systemen RAID 5 zum Einsatz.

AIX wird solche devices meist über den Datapath Optimizer ansprechen, den DPO. Dieser verwaltet die Wege zu den Platten, die, falls die Platten z.B. über einen Fibre-Channel-Switch angeschlossen sind, aus zwei oder mehr virtuellen Pfaden (vpath) bestehen. Fällt ein Pfad aus, ist die Platte noch über den/die anderen Pfade zu erreichen. Das hat natürlich zur Folge, daß ein und dieselbe Platte 'mehrmals' bei den devices angezeigt wird, jedesmal mit einer anderen hdisk Nummer. Umgekehrt macht der Einsatz des DPO natürlich keinen Sinn, wenn die Platten direkt angeschlossen sind, es also nur einen Pfad pro Platte gibt. In diesem Fall kann man die hdisk devices direkt ansprechen und braucht den Umweg über die vpath nicht.

Anzeigen lassen kann man sich die vpath Zuordnung zu den hdisk mit

# lsvpcfg

Andere mögliche Abfragen kann man über den datapath Befehl machen:

# datapath query device

# datapath query devstats

# datapath query adapter

# datapath query adaptstats

Probleme beim (Um-)Konfigurieren von vpath devices

Problematisch werden die virtuellen hdisks dann, wenn sie umkonfiguriert werden. Sie können in Teile zerlegt werden (und bilden neue kleinere hdisks) oder aus mehreren Teilen zusammengefaßt (und bilden größere/große hdisks). Sie können aber auch ganz gelöscht oder um ganz neue hdisks ergänzt werden. In solchen Fällen ist eine Neukonfiguration der devices notwendig, da z.B. nach dem Zerschlagen von kleinen virtuellen hdisks und dem zusammenschalten zu wenigen großen hdisks deren pvid geändert und oder gelöscht und neu angelegt werden. Dadurch kann es passieren, daß das System in einen Zustand gerät, bei dem die Informationen über Volumegroups, Logical Volumes und Filesystems  in den Flatfiles und der ODM nicht mehr zu den Daten auf den physikalischen Medien selbst passen. Ein möglicher Fehler wird sich dann z.B. darin äußern, daß keine neuen Volumegroups auf Platten, die auf ?non None?stehen, mehr angelegt werden können, oder daß bekannte Volumegroups nicht mehr importiert werden können (weder ganz noch mit Learning Import). Befehle wie lspv geben z.B. nur Nullen als pvid aus, während ein low-level Kommando wie lquervg oder lquerylv brav die pvid anzeigen. In solchen Fällen hilft das folgende Verfahren, welches sich zunutze macht, daß ungeachtet der Konfusion zwischen ODM und Medien die Zuordnung der Platten zur ESS eindeutig geblieben ist:

Zunächst hängt man alle filesystems ab:

# umount <fs_name>

Danach löst man die Abhängigkeit der Volumegroups zu den vpath auf:

# vp2hd <vg_name>

Nutzt man keine vpath devices, dann empfiehlt es sich zunächst den umgekehrten Weg einzuschlagen und alle hdisk devices in vpath zu konvertieren (# hd2vp <vg_name>) und dann wieder rückgängig zu machen.

Danach hängt man alle ESS Volumegroups ab

# varyoffvg <vg_name>

Anschließend löscht man alle vpath devices, indem man das DPO device von oben nach unten aus System und ODM entfernt:

# rmdev -dl dpo -R

Danach entfernt man alle dazugehörigen hdisk (2105) devices:

# rmdev -dl <hdisk#>

Wenn das getan ist, wird i.d.R. nur die rootvg sichtbar sein. Nun läßt man den Configuration Manager über jeden einzelnen Fibrechannel Adapter laufen (wichtig bei FC-Switch, also wenn von mehr als einem Adapter ein Weg zu jeweils derselben Platte exisitert!), z.B. bei vier Adaptern 0-3:

# for i in 0 1 2 3 ; do cfgmgr -l fcs$i ; done

Danach wird nochmals das DPO devices rausgeworfen:

# rmdev -l dpo -R

und dann bringt man die vpath devices zurück ins System:

# smitty datapath_cfgall

Bei dem beschriebenen Prozeß können mehrere Sachen passieren. So ist es möglich, daß eine Reihe von hdisks auftauchen, die auf defined stehen und nach dem Löschen nicht mehr auftauchen, wenn ESS hdisks zu einer oder mehreren größeren hdisks zusammengefaßt wurden (da sich die Anzahl der Platten für das System ja verringert hat). Nach dem Umkonfigurieren werden dann insgesamt 'weniger' hdisks zu sehen sein (obwohl der Speicherplatz gleich geblieben sein kann).

Beim Einsatz von vpath devices muß nach der Aktion jedem vpath eine pvid zugeordnet sein, dann können sie auch wieder korrekt importiert werden. Umgekeht müssen die pvid der hdisk korrekt wiedergeben werden, wenn nicht mit vpath gearbeitet wird. In diesem Fall läßt man nach dem importvg nochmal

# hd2vp <vg_name>

laufen.

Voraussetzung für den Erfolg ist, daß die Identifizierung der ESS devices korrekt funktioniert und daß von den physikalischen Medien korrekt gelesen werden kann. Wenn das gegeben ist, kann man auf die beschriebene Art und Weise eine verstruwelte ODM einmal von vorne nach hinten und zurück bürsten und somit alle Fehler (bei der hdisk Identifizierung) rauswerfen.

Top

vpath und hdisk devices treten zusammen im System auf

Wenn die ESS Platten ansonsten sauber erkannt werden, behilft man sich am schnellsten mit einem zu diesem Zweck mitgelieferten IBM Skript:

# dpovgfix

Top

lsess und ls2105 verwenden

Die beiden Skripte lsess und ls2105 werten eine Tabelle aus, die beim booten des Servers jedesmal neu erzeugt wird. Nach Änderungen an der ESS (ohne reboot des Servers) geben diese Skripte zunächst mal falsche Informationen wieder. Um die Tabelle manuell zu aktualisieren verwendet man

# /usr/lib/methods/cfallvpath -2

# /usr/lib/methods/fcmap >> /var/adm/essmap.out

Top

Entfernen von SDD

Zuerst müssen alle zu SDD gehörende Geräte entfernt werden, dann der sddsrv gestoppt und dann die Software deinstalliert.

# varyoffvg <vpathvg>

# lspv | grep vpath | awk '{print $3}' | while read vp; do /usr/sbin/vp2hd $vp; done

# rmdev -dl dpo -R

# stopsrc -s sddsrv

# lsdev -cadapter | grep ^fcs | cut -f1 -d" " | while read a; do lsdev -l $a -F parent | while read s;do rmdev -dl $s -R; done ; done

Je nach genutzter hardware Software entfernen.

installp -ugX devices.fcp.disk.ibm.rte

installp -ugX ibm2105.rte

installp -ugX devices.sdd.53.rte

Danach sollte man den Server neu starten. Falls SDD entfernt wurde, um z.B. SDDPCM zu installieren, kann dieser Schritt unmittelbar angeschlossen werden und der Neustart nach diesem Schritt erfolgen.

# mount /installverzeichnis

# installp -acXg -d /software/ibm/SDDPCM/SDDPCM_AIX_53_2.5.0.0 devices.sddpcm.53.rte

# shutdown -Fr now

Top

ESS Konsole nutzen

Die Bedienung der ESS über das Java Interface ist sehr unkomfortabel. Die Reaktion ist extrem langsam und Funktionen sind manchmal nicht ausführbar. Deshalb macht es Sinn, die Konsole der ESS zu benutzen, auch wenn das 'normalerweise' nur die Service Techniker machen. Dazu schließt man entweder ein IBM3151 Terminal, einen Terminalserver oder einen Notebook mit einer IBM3151 Terminal Emulation an den linken mittleren seriellen Port an. Terminaleinstellungen sind 8N1 bei 9600bps, ein passenden serielles Kabel liegt in der Regel bereits in der ESS. Beim Login gibt man als Benutzer ?service? ein, die ESS generiert dann automatisch jedesmal ein neues Paßwort, das im linken LCD angezeigt wird. Nach der Eingabe des Paßwort steht ein SMIT mit verschiedenen Funktionen zur Verfügung.

Top

ESS Fehlermeldungen

1199 - 1870 -

Error 1199: Information Server Problem. Heißt: Der Information Server (ESS interner HTTPServer) läuft nicht. Es ist keine Konfigurationsänderung am System möglich. Starten/Stoppen des Information Server nur über IBM Service möglich.

Error 1870: The following volume assignement requests failed. Meist ein Folgefehler von Error 1199.

Top

Top

FC Switch migrieren

Ein Migration von ESS Platten von einem Switch auf einen anderen ist immer eine Störung im normalen Betrieb, sogar wenn SDD installiert ist. Der Grund dafür ist, daß die Domänen ID und der Switch Port geändert werden. Eine solche Operation kann dazu führen, daß der FC Adapter im Zustand ?degraded? endet. Um den FC Adapter über diese Änderung zu informieren ist ein rmdev des Adapters notwendig. Solange aber ESS hdisks mit dem Adapter angeschlossen sind, kann er nicht entfernt werden. Die hdisks wiederum können nicht entfernt werden, da sie Teil der vpath Konfiguration sind. Das korrekte Vorgehen ist also:

  1. Stop I/O über den betroffenen FC-Adapter
  2. umount fs
  3. varyoffvg <vgname>
  4. rmdev vpaths, hdisks, fcs und fscsi
  5. umstecken der FC Kabel auf den neuen Switch
  6. cfgmgr
  7. varyonvg <vgname>
  8. mount fs
  9. Start I/O über den betroffenen FC-Adapter.

Top

DS4000 Controller Kommandozeile

Enable_remote login:

- über SMclient / Controller A (oder B) markieren

- Menue: Controller/Change/Network Configuration/Advanced

- Enable remote login - markieren

- IP-Adresse muß über /etc/hosts aufgelöst werden

- über TTY: rsh <IP des aktivierten Controllers>

- pwd: infiniti

Top

Wo finde ich die WWPN?

Eine Übersicht, wo die WWPN bei den verschiedenen Total Storage Systemen DS3000, DS4000, DS5000, DS6000, V7000, ESS,m DS8000, SVC, XIV  ist, findet sich hier

Top

Fehlermeldungen

0514-047 Cannot access a device.

Diese Meldung bedeutet nicht zwangsläufig, daß ein device nicht (mehr) vorhanden ist, sondern tritt auch auf, wenn auf ein device nicht zugegriffen kann, weil es an anderer Stelle bereits durch einen Zugriff gelockt ist. Dies tritt gerne im SAN Umfeld auf. Z.B. bei einem VIO Server, der hdisk devices als shared storage aus einem SAN an einen Cluster durchreicht.

Method error (/usr/lib/methods/cfg_vt_scdisk):0514-047 Cannot access a device.

Ein Hinweis kann auch sein, daß man von einer hdisk zwar "sieht", daß sie vorhanden ist, aber auf die Oberfläche nicht zugegriffen werden kann (also z.B. die PVID nicht angezeigt werden kann obwohl sie vorhanden ist. (Anzeige: hdiskxy None none). Um an das device heranzukommen muß es ggf. bis zum device parent gelöscht werden. Bei shared devices muß dies ggf. auf allen beteiligten Systemen geschehen, die das device im Zugriff haben. Auf einem VIOS muß also das vhost mapping aufgelöst werden (und damit quasi das SCSI Kabel abgezogen werden) indem man z.B. ei n rmdev -vtd vtscsixy abgesetzt wird.

0516-008 varyonvg: LVM system call returned an unknown error code (3).

In der ODM befinden sich (noch) widersprüchliche Informationen, z.B. nach einem fehlgeschlagenen rmdev auf eine hdisk (rmdev auf alte hdisk, während Ersatzplatte bereits eingebaut und von cfgmgr erkannt ist). Wegen der Widersprüche schlägt das LVM Kommando (z.B. varyonvg etc) fehl.

Top

0516-362 putlvodm: Unknown Object Data Manager error: 0.

Diese ODM bezogenen Fehler können darauf hinweisen, daß / zu 100% voll ist.

[aixserver:root] /home/root > mklvcopy loglv02 2 hdisk10

0516-362 putlvodm: Unknown Object Data Manager error: 0.

0516-842 mklvcopy: Unable to make logical partition copies for logical volume.

[aixserver:root] /home/root > synclvodm sapvg

0516-508 synclvodm: Warning, unable to update device configuration database for physical volume hdisk8.

Top

0516-1397 extendvg: The physical volume hdiskx, will not be added to the volume group.

Dieser Fehler tritt z.B zusammen auf mit: 0516-792 extendvg: Unable to extend volume group. Abhilfe: man überschreibt den "owning volume manager" des hdisk devices mit

# chpv -C <hdisk>

und probiert den extendvg/mkvg danach noch einmal.

Top

++++++++++++++++++++++++++++++++++++++++++++++++++

Copyright © Schulze-EDV-Service 2011; http://www.schulze-edv.de/

Das direkte Linken meiner Seiten ist nur auf Seiten ohne Werbung gestattet.My pages must not be linked directly to pages and/or frame-sets containing ads. Copyright © 1998-2011 Andreas Schulze. German and European copyright law applicable. Alle Rechte vorbehalten. All rights reserved.

Content of my pages and its presentation is entirely mine. It is illegal to use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform and display Content (in whole or in part) and /or to incorporate it in other works in any form, media, or technology now known or later developed without written consensus of the author. If you do not agree with these terms, you have to delete my pages / its content in whole from you (IT-) systems. In this case you are not allowed to keep any kind of backup of it (neither in whole nor in part).

Alle hier genannten Produkte sind eingetragene Marken oder Marken der jeweiligen Eigentümer. Inhalte verlinkter Seiten machen wir uns nicht zu eigen und befürworten sie auch nicht.