unixwerkAIX-Migration von 5.2 nach 5.3 mit minimaler Downtime
»Die NIM-Methode »Alternate Disk Migration«
Inhalt
- Einleitung
- Voraussetzungen auf dem NIM-Server
- Die LPP-Source
- Der Spot
- Definition des Clients
- Vorbereitung des Clients
- Die Migration
- Starten des migrierten Systems
- Wiederherstellung des Spiegels
- Weiterführende Literatur
1. Einleitung
"Never touch a running system" - dieser Leitsatz gilt ganz besonders sicherlich bei unternehmenskritischen Servern. Doch von Zeit zu Zeit müssen auch diese mal eine Auffrischung des Betriebssystems erfahren. Nun dauert so eine Migrations-Installation durchaus schon mal ein paar Stunden. Diese Stunden multipliziert mit der Anzahl zu migrierender Server darf der arme Admin dann auch noch im eisgekühlten Rechenzentrum verbringen - nur um von Zeit zu Zeit mal eine CD zu tauschen. Grund genug sich nach Alternativen umzuschauen.
Um eine solche Alternative geht es in diesem Artikel: Die Migration der vorhandenen AIX Installation auf den neuesten Stand, während
das alte System aktiv bleibt. Angestoßen wird diese Migration von einem NIM Server durch die »Alternate Disk Migration«-Methode. Bei
diesem Verfahren reduziert sich die Downtime auf die Zeit, die ein LPAR-Neustart in Anspruch nimmt.
2. Voraussetzungen auf dem NIM-Server
Ganz ohne Aufenthalt im Rechenzentrum geht es allerdings doch nicht. Der Grund ist der NIM-Server selbst. Dieser muss nämlich zunächst
einmal händisch auf den neuesten Stand gebracht werden. Wie das elegant gemacht wird, steht z.B. in einem
unixwerk-Artikel aus dem Jahre 2004
(
Alternate Disk Migration ohne NIM-Server). Dies ist nötig, da
ein NIM-Server keinen niedrigeren Softwarestand aufweisen darf als er bedienen soll.
Desweiteren müssen eine Reihe von NIM-Objekten definiert werden. Die folgenden Abschnitte 3 bis 5 beschreiben dies im Detail.
3. Die LPP-Source
Im Folgenden wollen wir eine LPP-Source kreieren, die bereits unseren gewünschten Technology-Level und das gewünschte Service-Pack enthält. Unsere LPP-Source soll im Verzeichnis /export/nim/lpp_source/aix53 liegen
Die Base-Level-Filesets gibt's nur auf CD oder DVD - diese lesen wir vom Medium ein:
nimserver# smitty bffcreate
[Entry Fields]
* INPUT device / directory for software [/dev/cd0] +
* SOFTWARE package to copy [all] +
* DIRECTORY for storing software package [/export/nim/lpp_source/aix53]
DIRECTORY for temporary storage during copying [/tmp]
EXTEND file systems if space needed? yes +
Process multiple volumes? yes +
Nachdem die Base-Level-Filesets kopiert sind, fahren wir mit den Technology-Level fort. Diesen haben wir von der IBM-Seite z.B. in das Verzeichnis /tmp/5300-05 heruntergeladen. Sie werden in das gleiche Verzeichnis kopiert, in dem sich bereits die Base-Level-Filesets befinden:
nimserver# smitty bffcreate
[Entry Fields]
* INPUT device / directory for software [/tmp/5300-05] +
* SOFTWARE package to copy [all] +
* DIRECTORY for storing software package [/export/nim/lpp_source/aix53]
DIRECTORY for temporary storage during copying [/tmp]
EXTEND file systems if space needed? yes +
Process multiple volumes? yes +
Zu guter Letzt wird dann das Service-Pack kopiert. Angenommen dieses haben wir von der IBM-Seite in das Verzeichnis /tmp/5300-05-01 heruntergeladen:
nimserver# smitty bffcreate
[Entry Fields]
* INPUT device / directory for software [/tmp/5300-05-01] +
* SOFTWARE package to copy [all] +
* DIRECTORY for storing software package [/export/nim/lpp_source/aix53]
DIRECTORY for temporary storage during copying [/tmp]
EXTEND file systems if space needed? yes +
Process multiple volumes? yes +
Nachdem alles an seinem Platz ist, bleibt uns nur noch das entsprechende NIM-Objekt zu definieren:
nimserver# nim -o define -t lpp_source \
-a server=master \
-a location=/export/nim/lpp_source/aix53 \
-a comments='Full AIX 5.3.0 source including TL5 SP1' \
lpp_aix53
Mit dem obigen Befehl haben wir ein NIM-Objekt des Typs lpp_source mit dem Namen lpp_aix53 definiert. Mit lsnim können wir uns noch einmal das Objekt anzeigen lassen:
nimserver# lsnim -l lpp_aix53 lpp_aix53: class = resources type = lpp_source comments = Full AIX 5.3.0 source including TL5 SP1 arch = power Rstate = ready for use prev_state = unavailable for use location = /export/nim/lpp_source/aix53 simages = yes alloc_count = 1 server = master
Durch das Kopieren von Filesets aus drei verschiedenen Quellen gibt es eine Reihe überflüssiger Filesets, die nichts weiter als Platz wegnehmen - in unserem konkreten Fall ca. 400 MB. Diese überflüssigen Filesets können aus der LPP-Source entfernt werden:
nimserver# smitty nim_lppmgr
Dann geben wir die LPP-Source an und bekommen folgende Maske:
[Entry Fields]
TARGET lpp_source lpp_aix53
PREVIEW only? no +
REMOVE DUPLICATE software yes +
REMOVE SUPERSEDED updates yes +
REMOVE LANGUAGE software no +
PRESERVE language [en_US]
REMOVE NON-SIMAGES software no +
SAVE removed files no +
DIRECTORY for storing saved files []
EXTEND filesystems if space needed? yes +
4. Der Spot
Als nächstes müssen wir einen Spot erstellen, der aus der im vorigen Abschnitt erzeugten LPP-Source gespeist wird:
nimserver# nim -o define -t spot \
-a server=master \
-a source=lpp_aix53 \
-a location=/export/nim/spot \
-a comments='Spot created from AIX 5.3-TL5-SP1' \
spot_aix53
Bis der Spot zur Verfügung steht, dauert es eine ganze Weile, da alle Basis-Filesets und Gerätetreiber in den Spot installiert werden - diese entspricht dem Vorgang einer gewöhnlichen AIX-Installation.
An dieser Stelle sei angemerkt, dass für location - anders als dies bei der LPP-Source der Fall ist - kein weiterer Pfadanteil für den Spot angegeben werden sollte, da automatisch der Objektname (also spot_aix53) angehängt wird. Dies sehen wir, wenn wir uns das NIM-Objekt mit lsnim anschauen:
nimserver# lsnim -l spot_aix53
spot_aix53:
class = resources
type = spot
comments = Spot created from AIX 5.3-TL5-SP1
plat_defined = chrp
arch = power
bos_license = yes
Rstate = ready for use
prev_state = verification is being performed
location = /export/nim/spot/spot_aix53/usr
version = 5
release = 3
mod = 0
oslevel_r = 5300-05
alloc_count = 0
server = master
if_supported = chrp.mp ent
Rstate_result = success
Damit wir eine »Alternate Disk Migration« durchführen können, muss das Fileset bos.alt_disk_install im Spot enthalten sein - ist es aber nicht. Wir müssen dieses manuell nachinstallieren. Dies tun wir am besten mit SMIT:
nimserver# smitty nim_inst_latest
Dann geben wir Spot und LPP-Source an und bekommen folgende Maske, in deren drittes Feld wir das nachzuinstallierende Fileset eintragen:
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* Installation Target spot_aix53
* LPP_SOURCE lpp_aix53
* Software to Install [bos.alt_disk_install.rte]
Customization SCRIPT to run after installation [] +
(not applicable to SPOTs)
Force no +
installp Flags
PREVIEW only? [no] +
COMMIT software updates? [yes] +
SAVE replaced files? [no] +
AUTOMATICALLY install requisite software? [yes] +
EXTEND filesystems if space needed? [yes] +
OVERWRITE same or newer versions? [no] +
VERIFY install and check file sizes? [no] +
ACCEPT new license agreements? [no] +
(AIX V5 and higher machines and resources)
Preview new LICENSE agreements? [no] +
5. Definition des Clients
Die Clients sollten eigentlich schon definiert sein, da dies normalerweise bei der ersten Installation getan wird. Der Einfachheit halber soll unser Client auf den Namen client hören. Wir überprüfen, ob eine Definition verhanden ist, mit lsnim:
nimserver# lsnim -l client client machines standalone
Sollten Sie stattdessen allerdings folgende Antwort erhalten -
nimserver# lsnim -l client 0042-053 lsnim: there is no NIM object named "client"
muss der Client neu oder re-definiert werden. Dies geschieht mit:
nimserver# nim -o define -t standalone \
-a platform=chrp \
-a netboot_kernel=mp \
-a if1="network client mac-address ent" \
-a cable_type1=tp \
client
Für network muss das entsprechende NIM-Objekt gesetzt werden. Wir finden alle Objekte dieses Typs mit:
nimserver# lsnim -t ent -l masternet: class = networks type = ent Nstate = ready for use prev_state = information is missing from this object's definition net_addr = 198.162.1.0 snm = 255.255.255.0 routing1 = default 198.162.1.1
Für mac-address müssen wir die MAC-Adresse des Bootadapters setzen - diese findet sich z.B. mit
nimserver# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en3 1500 link#2 0.2.55.52.67.a9 352475085 0 178951250 3 0
en3 1500 198.162.1 client 352475085 0 178951250 3 0
Mit diesen Informationen wird der Client dann definiert:
nimserver# nim -o define -t standalone \
-a platform=chrp \
-a netboot_kernel=mp \
-a if1="masternet client 0002555387a9 ent" \
-a cable_type1=tp \
client
6. Vorbereitung des Clients
Im Folgenden gehen wir davon aus, dass der zu migrierende Client über eine gespiegelte rootvg verfügt. Für die Migration wird dieser Spiegel temporär aufgebrochen
client# unmirrorvg rootvg hdisk1
Trotz Entfernen aller gespiegelten LVs von der zweiten Platte, können sich dort noch einzelne ungespiegelte LVs befinden, z.B. ein zweites Dump-Device. Wir überprüfen dies mit
client# lspv -l hdisk1 hdisk1: LV NAME LPs PPs DISTRIBUTION MOUNT POINT dump2 8 8 00..08..00..00..00 N/A
Alles, was dort noch liegt, sollte dann auf hdisk0 migriert werden - freie PPs natürlich vorausgesetzt:
client# migratepv hdisk1 hdisk0und wir können endlich die zweite Platte aus der rootvg lösen:
client# reducevg rootvg hdisk1
Möchten Sie Ihre alte Message Of The Day behalten, sichern Sie diese jetzt - die wird nämlich bei der Migration überschrieben:
client# cp /etc/motd /etc/motd.alt
7. Die Migration
Zunächst müssen wir den Remote-Zugang des NIM-Servers ermöglichen, dafür legen wir die Datei /.rhosts mit folgendem Inhalt an:
nimserver root
In der Datei /etc/inetd.conf akivieren wir den rshd, indem wir gegebenfalls
den Hash (#) vor dem entsprechenden Eintrag entfernen:
shell stream tcp6 nowait root /usr/sbin/rshd rshdund den Internet-Superserver neu starten:
client# refresh -s inetd 0513-095 The request for subsystem refresh was completed successfully.
Damit sind die Arbeiten auf dem Client abgeschlossen und wir können vom NIM-Server aus die Migration starten:
nimserver# nimadm -c client -l lpp_aix53 -s spot_aix53 -d hdisk1 -Y
Dieser Befehl stößt zunächst den Prozess des Klonens der rootvg an und danach die Migrations-Installation auf AIX 5.3. Dabei werden 12 Phasen durchschritten, auf die ich hier nicht weiter eingehen will. Insgesamt dauert das Ganze gut und gerne einige Stunden, in denen eine Reihe von Bildschirmausgaben erscheinen.
Auf dem Client sehen wir während der Migration neue Dateisysteme:
client# df Filesystem 512-blocks Free %Used Iused %Iused Mounted on nimserver:/export/nim/lpp_source/aix53 66846720 39144896 42% 20261 1% /ALT_MIG_IMAGES nimserver:/export/nim/spot/spot_aix53/usr 66846720 39144896 42% 20261 1% /ALT_MIG_SPOT /dev/alt_hd4 262144 109808 59% 3874 6% /alt_inst /dev/alt_hd1 524288 264336 50% 897 2% /alt_inst/home /dev/alt_ibmlv 262144 203488 23% 181 1% /alt_inst/ibm /dev/alt_hd10opt 262144 203144 23% 715 3% /alt_inst/opt /dev/alt_hd3 1310720 1241488 6% 124 1% /alt_inst/tmp /dev/alt_hd2 3014656 413976 87% 29867 8% /alt_inst/usr /dev/alt_hd9var 655360 158992 76% 1324 2% /alt_inst/var
Nach Abschluss der Phase 12 ist die Migration dann abgeschlossen und wir müssen uns noch einmal dem Client zuwenden: Die Änderungen für den rsh-Zugang (/.rhosts, /etc/inetd.conf) machen wir noch schnell rückgängig und dann rebooten wir die LPAR. Da die Bootliste durch den NIM-Prozess bereits auf die migrierte Installation zeigt, brauchen wir nichts weiter als ein beherztes
client# shutdown -Fr
8. Starten des migrierten Systems
Nachdem das System wieder gestartet ist, sollte es AIX 5.3 TL5 SP1. Wir überprüfen dies mit
client# oslevel -s 5300-05-01
Auch auf dem migrierten System müssen wir gegebenfalls die Änderungen in den Dateien /.rhosts und /etc/inetd.conf zurücknehmen und den Internet-Superserver neu starten:
client# refresh -s inetd 0513-095 The request for subsystem refresh was completed successfully.
9. Wiederherstellung des Spiegels
Für eine Weile wird man die Möglichkeit aufrecht erhalten wollen, auf die alte AIX-Version zurückschalten zu können, doch irgendwann kommt der Tag, an dem das Vertrauen in die neue Version hoch genug ist, um die alte Installation zu löschen und die rootvg wieder zu spiegeln.
Zunächst löschen wir die alte Installation:
client# alt_disk_install -X old_rootvg
Die alte Installation kann auch anders heißen - dies passiert z.B. wenn man die old_rootvg einmal aufweckt und dann wieder schlafen legt - dabei wird sie dann in altinst_rootvg umgetauft.
Nun steht hdisk0 wieder zur Verfügung und wir können die rootvg spiegeln:
client# extendvg -f rootvg hdisk0 client# mirrorvg -s rootvg hdisk0
Die beiden Befehle synchronisieren die VG noch nicht. Da das Synchronisieren eine sehr hohe I/O-Belastung erzeugt, ist es ratsam zu warten, bis das System weniger belastet ist, also z.B.:
client# echo varyonvg rootvg | at 23:00
Falls Sie unter 6 (Vorbereitung des Clients) ein oder
mehrere LVs auf die andere Platte migrieren mussten, migrieren Sie diese(s) jetzt wieder zurück:
client# migratepv -l mylv hdisk0 hdisk1
Um sicher zu gehen, dass auch beim nächsten Reboot alles gut geht, schreiben wir die beiden BLVs neu:
client# bosboot -ad hdisk0 bosboot: Boot image is 30112 512 byte blocks. client# bosboot -ad hdisk1 bosboot: Boot image is 30112 512 byte blocks.
Zu guter Letzt setzen wir die Bootliste so, dass von beiden Platten gebootet werden kann:
client# bootlist -m normal hdisk0 hdisk1
A. Weiterführende Literatur