WTF - Megváltozott filerendszer mount pointok migrálás után

Aki már migrált valaha bármilyen régebbi rendszert bármilyen újra, az kb tudhatja hogy változatosabbnál változatosabb csapdákba futhat bele az ember időnként. Ez most se volt másként...

Adott egy régi Power4es szerver amin épp egy 5.2es AIX futkározik. Tekintve hogy ez a HW már jó ideje nem támogatott, sok helyet is foglal, meg amúgy is lassú, így fent az a döntés született, hogy konszolidálni kéne a szervert egy modernebb Power7es infrastruktúrába.
Hogy hogyan is? Hát van több fajta megoldás, csak tudni kell kiválasztani melyik a legcélravezetőbb:
- Live Partition Mobility: Ha a forrás és a cél rendszerek mind szépen virtualizálva vannak, és a szükséges feltételek mind adottak, akkor kiesés nélkül át lehet költöztetni az LPARt 2 fizikai rendszer között
- Lift and Shift: Ha a rendszer és az adatok is külső SAN-on vannak, akkor minimális leállás után át lehet zónázni a LUN-okat egy másik gépre és ott használni őket.
- Backup and restore: Ez esetben minimum a rendszer belsős lemezekre lett telepítve, így annak költöztetése csak egy mksysb backup segítségével megoldható, amit a távoli gépen aztán vissza lehet tölteni (akár WPAR-ba is). Ha mázlink van, akkor az adatok SAN-on helyezkednek el, így a specifikus LUN-okat át lehet simán zónázni a cél géphez; ha viszont nincs mázlink, akkor ezt is hálózaton keresztül valahogy át kell juttatni a cél gép felé (savevg, GLVM, vagy sima tar+ssh pipe)
- Rebuild from scratch: Ebben az esetben az alap rendszert (illetve opcionálisan a Middleware, Applikációt is) teljesen nulláról építjük újra, majd a szolgáltatáshoz szükséges további adatot átemeljük a forrás rendszerről és beillesztjük az újonnan felépített struktúrába.

Lehet meglepő, de régebbi rendszereknél az utóbbi sokszor a legcélravezetőbb, mivel ezeknél valószínű nem csak a rendszer régi, hanem annak komponensei is, így egy-egy ilyen migráció kiváló alkalmat ad arra, hogy az ember végre kidobálja a régi legacy szutykokat, és egy támogatott megoldással helyettesítse őket.

Ebben az esetben a legcélravezetőbbnek az utolsó 2 megoldás keveréke bizonyult a legjobbnak: Az alaprendszert nem volt értelme átköltöztetni, a régi -már nem támogatott- middleware komponenseket egy részét szerencsére volt lehetőség támogatottra cserélni, más komponenseket viszont simán át lehetett emelni a régi rendszerről a szükséges LUN-ok újrazónázásával.

A tényleges lépésekre most nem térek ki, -a bejegyzés szempontjából érdektelenek- egyet kivéve: Miután a LUN-okat az ember átzónázza Volume Groupot ismét be kell importálni a rendszerbe, hogy az adathoz hozzá lehessen férni. A folyamat részeként a teljes LVM struktúra importálódik a fájlrendszerekkel egyetemben. Igen ám, de volt egy kisebb probléma.. Az importálás után a legtöbb fájlrendszer szépen vissza is került a helyére, viszont volt 1-2 aminek a mount pointja megváltozott (ettől eltekintve az adat szépen a helyén volt). A kérdés adott volt: Miért?

No, a technikai része a blog bejegyzésnek kb. innen indul :)) Lássuk mi és hogy zajlik le egy ilyen importálás során:
- Az importálás során az importvg szépen felolvassa a megjelölt diszk VGDA adatait
- A VGDA adatok alapján ellenőrzi a VG-hez szükséges PV-k elérhetőségét (PVID alapján), illetve összeveti azok VGDA adatait (VG_ID) a többi PV-n találhatóakkal.
- Amennyiben az összes PV elérhető, és a VGDA is konzisztensen azonos adatot mutat, úgy felolvassa a teljes LVM struktúrát
- A struktúra része az adott LV-k definiciói (típus, név, méret, upper bound), azok elhelyezkedése (LP/PP-k elhelyezkedése PV-re lebontva), illetve 1-2 további metaadat (létrehozási idő, utolsó módosítási idő, label, vfs specifikus adatok)
- Miután a teljes struktúrát feltérképezte létrehozza a szükséges bejegyzéseket az ODM-ben, illetve a /etc/filesystems-ben, majd ezek alapján aktiválja a VG-t

Nem tudom kinek tűnik fel, de fájlrendszer specifikus adatokat az importvg nem olvas fel, még is módosítja a /etc/filesystems file-t.. Hogy van ez?

Na igen. Itt van a kutya elásva. Igaz, hogy FS specifikus adatot nem olvas fel, viszont nem is kell neki: A metaadatokban ott van minden amire szüksége van ahhoz, hogy egy fájlrendszert mountolni lehessen.

Itt egy pelda a /home FS (hd1 LV) LVM descriptorának elejéről:

3D8220000   41495820 4C564342 00006A66 73320000  |AIX LVCB..jfs2..| # LVM Control Block, LV type
3D8220010   00000000 00000000 00000000 00000000  |................|
3D8220020   00000000 00000000 00003030 63306164  |..........00c0ad| # LV serial ID
3D8220030   31653030 30303463 30303030 30303031  |1e00004c00000001|
3D8220040   34320068 64310000 00000000 00000000  |42.hd1..........|
3D8220050   00000000 00000000 00000000 00000000  |................|
3D8220060   00000000 00000000 00000000 00000000  |................|
3D8220070   00000000 00000000 00000000 00000000  |................|
3D8220080   00000053 756E204E 6F762031 30203231  |...Sun Nov 10 21| # Creation date
3D8220090   3A30393A 34382032 3031330A 00000000  |:09:48 2013.....|
3D82200A0   00576564 204A756C 20323320 30393A31  |.Wed Jul 23 09:1| # Last modification date
3D82200B0   353A3338 20323031 340A0000 00000030  |5:38 2014......0|
3D82200C0   41443145 34433030 00796D63 00790020  |AD1E4C00.ymc.y. |
3D82200D0   00010001 2F686F6D 65000000 00000000  |..../home.......| # Label
3D82200E0   00000000 00000000 00000000 00000000  |................|
3D82200F0   00000000 00000000 00000000 00000000  |................|
3D8220100   00000000 00000000 00000000 00000000  |................|
3D8220110   00000000 00000000 00000000 00000000  |................|
3D8220120   00000000 00000000 00000000 00000000  |................|
3D8220130   00000000 00000000 00000000 00000000  |................|
3D8220140   00000000 00000000 00000000 00000000  |................|
3D8220150   00000000 7666733D 6A667332 3A6C6F67  |....vfs=jfs2:log| # VFS data
3D8220160   3D2F6465 762F6864 383A6D6F 756E743D  |=/dev/hd8:mount=|
3D8220170   74727565 3A636865 636B3D74 7275653A  |true:check=true:|
3D8220180   766F6C3D 2F686F6D 653A6672 65653D66  |vol=/home:free=f|
3D8220190   616C7365 3A71756F 74613D75 73657271  |alse:quota=userq|
3D82201A0   756F7461 2C67726F 75707175 6F746100  |uota,groupquota.|

Mielőtt valaki nekem ugrik, hogy de ezek fájlrendszer adatok: Nem, az 8000(h) blokkal arrébb van:

3D8228000   4A324653 00000002 00000000 527FF623  |J2FS........R..#| 
3D8228010   00000000 00000000 00000000 00002F68  |............../h|
3D8228020   6F6D6500 00000000 00000000 00000000  |ome.............|

Jó. De ha ott megtalálható az adat, akkor miért nem az alapján dolgozik az importvg? A válasz erre nagyon egyszerű: Mert ott az se a mount point :)

De akkor várjunk csak egy pillanatot.. Itt van 2 olyan példa is, ahol egyértelműen látszik, hogy ott van a /home, de ez mégse a mount point? Hülyén hangzik, mi? :)) Nézzünk egy másik példát, és akkor már talán tisztább lesz. Legyen a példa a /var/adm/ras/livedump filerendszer (livedump LV):

LVM descriptor eleje:

1BC220000   41495820 4C564342 00006A66 73320000  |AIX LVCB..jfs2..| # LVM Control Block, LV type
1BC220010   00000000 00000000 00000000 00000000  |................|
1BC220020   00000000 00000000 00003030 63306164  |..........00c0ad| # LV serial ID
1BC220030   31653030 30303463 30303030 30303031  |1e00004c00000001|
1BC220040   3432006C 69766564 756D7000 00000000  |42.livedump.....|
1BC220050   00000000 00000000 00000000 00000000  |................|
1BC220060   00000000 00000000 00000000 00000000  |................|
1BC220070   00000000 00000000 00000000 00000000  |................|
1BC220080   00000053 756E204E 6F762031 30203231  |...Sun Nov 10 21| # Creation date
1BC220090   3A30393A 35302032 3031330A 00000000  |:09:50 2013.....|
1BC2200A0   0053756E 204E6F76 20313020 32313A31  |.Sun Nov 10 21:1| # Last modification date
1BC2200B0   313A3530 20323031 330A0000 00000030  |1:50 2013......0|
1BC2200C0   41443145 34433030 00796D6D 00790020  |AD1E4C00.ymm.y. |
1BC2200D0   00040001 2F766172 2F61646D 2F726173  |..../var/adm/ras| # Label
1BC2200E0   2F6C6976 6564756D 70000000 00000000  |/livedump.......|
1BC2200F0   00000000 00000000 00000000 00000000  |................|
1BC220100   00000000 00000000 00000000 00000000  |................|
1BC220110   00000000 00000000 00000000 00000000  |................|
1BC220120   00000000 00000000 00000000 00000000  |................|
1BC220130   00000000 00000000 00000000 00000000  |................|
1BC220140   00000000 00000000 00000000 00000000  |................|
1BC220150   00000000 7666733D 6A667332 3A6C6F67  |....vfs=jfs2:log| # VFS data
1BC220160   3D2F6465 762F6864 383A6D6F 756E743D  |=/dev/hd8:mount=|
1BC220170   74727565 3A616363 6F756E74 3D66616C  |true:account=fal|
1BC220180   73653A71 756F7461 3D6E6F00 00000000  |se:quota=no.....|
1BC220190   00000000 00000000 00000000 00000000  |................|
1BC2201A0   00000000 00000000 00000000 00000000  |................|
1BC2201B0   00000000 00000000 00000000 00000000  |................|
1BC2201C0   00000000 00000000 00000000 00000000  |................|
1BC2201D0   00000000 00000000 00003433 64393432  |..........43d942|
1BC2201E0   62342E31 31000000 00000000 00000000  |b4.11...........|
1BC2201F0   00000000 00000000 00000000 00000000  |................|

FS descriptor eleje:

1BC228000   4A324653 00000002 00000000 527FF62C  |J2FS........R..,|
1BC228010   00000000 00000000 00000000 00002F76  |............../v|
1BC228020   61722F61 00000000 00000000 00000000  |ar/a............|

Na, ki veszi észre mi a hiba az utóbbi példában? :) Igen, az FS descriptorban lévő adat nem egyezik meg az LVM descriptorban lévő labellel. Hogy miért? Azért mert az FS descriptorban lévő adat csak 6 karakter hosszú minden eseteben.
Jó, következő kérdés: Ennek így mi értelme? Nos, az AIX a boot folyamán ezt a 6 karaktert használja a boot során (Step 2, nem összekeverni az rc2-vel!) hogy visszaellenőrizze az FS-t adatait (felmerült már bárkiben, hogy a rendszer indításához szükséges fájlrendszerek mount pointja miért olyan rövid mindig? :))
Na jó.. Innentől a kérdés már csak az, hogy a mount pointok akkor hol vannak letárolva? Hát ez az.. A /etc/filesystems file alatt. És csak ott. Minden más csak "tájékoztató jellegű", kb. mint a MÁV menetrendje.

Visszatérve az eredeti szálra már látszik, hogy milyen csapdáról beszéltem: Az importálás során ezek a definíciók nem elérhetőek a /etc/filesystems alatt, az FS descriptorra se lehet támaszkodni ilyenkor, így hát marad az LVM descriptorban lévő Label.
Igen ám, de mi van akkor ha valaki megváltoztatja egy FS mount pointját és ehhez nem a megfelelő chfs parancsot használja, hanem manuálisan szerkeszti a /etc/filesystems filet? Pontosan.. Inkonzisztencia.. Minden szépen működni is fog egészen addig, amíg az ember egy ehhez hasonló VG importot nem akar végrehajtani (hisz a rendszer minden boot során ezen file alapján fogja bootolni a filerendszereket), amikor is az importvg/recreatevg neme egyszerűséggel felülvágja a /etc/filesystems-ben található adatokat a Label-ben található adatokkal.

Jó.. már értem.. Azt hiszem.. Hogy tudok meggyőződni arról, hogy nálam ilyen nem fordul elő?
A legegyszerűbben az lslv kimenetéből tudod megnézni a Label-t. Ha abban a szerencsétlen helyzetben találod magad, hogy nem tudod lslv-vel lekérdezni az LV-ket, de a diszkek még elérhetőek (és nem akarsz egy importvg-t megkockáztatni), akkor ezzel a kis scripttel le tudod kérni direktben a diszkekről a label-eket:

Példa kimenet:

# read_labels_directly_from_disk.sh hdisk0
hdisk0 / smallvg / 64 MB PP size
*******************
....primary_bootlv.............................. / hd5 - 64 MB / 1 (220000) / hdisk0
....None........................................ / hd6 - 512 MB / 104 (19C220000) / hdisk0
....None........................................ / hd8 - 64 MB / 206 (334220000) / hdisk0
..../........................................... / hd4 - 192 MB / 207 (338220000) / hdisk0
.#../usr........................................ / hd2 - 2240 MB / 210 (344220000) / hdisk0
..../var........................................ / hd9var - 256 MB / 241 (3C0220000) / hdisk0
..../tmp........................................ / hd3 - 768 MB / 245 (3D0220000) / hdisk0
..../home....................................... / hd1 - 64 MB / 247 (3D8220000) / hdisk0
..../opt........................................ / hd10opt - 384 MB / 248 (3DC220000) / hdisk0
..../admin...................................... / hd11admin - 128 MB / 250 (3E4220000) / hdisk0
..../var/adm/ras/livedump....................... / livedump - 256 MB / 112 (1BC220000) / hdisk0
....None........................................ / dumplv - 1280 MB / 479 (778220000) / hdisk0
....None........................................ / dumplv2 - 1280 MB / 269 (430220000) / hdisk0

# Érdekesség: A módszer kicsit más és más VG típusonként, így aki érdeklődik a tényleges struktúra után, az nyugodtan kukkantson bele a scriptbe :) (kis matek tudás azért nem fog ártani)

Gondosan Levezényelhető Vontatott Migráció (GLVM)

Nem tudom ti hogy vagytok vele, de én személy szerint szeretem ha kollégák néha érdekes elméleti kérdésekkel lepnek meg. *

* Bár néha én lepem meg őket olyan furcsa kérdésekkel, mint "Hogy lehet ütemezni egy jobot cronban úgy, hogy az adott hónap 6. hetének szombatján fusson le 02:00-kor szerver idő szerint". Eddig még kevesen jöttek rá a megoldásra :)

Ezen bejegyzést egyik kolléga kérdése ihlette, aki annak szeretett volna utána járni, hogy egy támogatott rendszert hogy lehetne a leghatékonyabban migrálni (mozgatni) 2 GEO lokáció között (legyen az ország, vagy akár kontinens).
A feltételek természetesen a szokásosak (mint minden migrációnál):
- Lehetőség szerint a szolgáltatások elérhetőségét maximalizáljuk (avagy fordítva: a kiesés legyen minimális)
- A migráció emberi időn belül legyen kész (tegnapra, mert a customernek mindig minden tegnapra kell - az is amire ma még nem is gondolt)
- A migráció a meglévő eszközökkel elvégezhető legyen ("Nem veszünk semmit!")
- Elsőre sikerülnie kell mindennek (mert azt nem köszönöd meg amit kapsz ha esetleg mégsem... )

Arra viszonylag gyorsan rájöttünk, hogy lehetőség egy csomó van, de ezeket az igényeket nem elégíti egyik se teljes mértékben:
- Szerviz leállít, majd az adatot hálózaton keresztül áttolni a cél gépre valamilyen mentés formájában (filerendszer, vagy blokk (FS/LV/VG) szinten - utóbbi kötelező ha van RAW kötet is a forrás gépen) -> A szolgáltatásban nagy a kiesés, az adat mozgatása időigényes (mennyi idő áttolni 2 TB-ot 2 kontinens között? :)), illetve hálózati hiba esetén az egészet lehet elölről kezdeni
- Szerviz leállít, majd a gépet fizikailag átköltöztetni a cél helyre és ott beüzemelni -> körülményes és a fene se akar fuvarozni/megreptetni egy szervert, főleg hogy lehet nem is szükségszerűen kivitelezhető (törpék próbálkozhatnak a sokból 1 virtuális gépet kibányászni csákánnyal a gépből, de félek hogy nem fog menni) - bár tény és való, hogy egy csomó merevlemezzel megrakott teherautó/repülőgép sávszélességét nem szabad lebecsülni.
- Csinálni egy konzisztens mentést a meglévő adatokról, azt valahogy eljuttatni a célgépre, majd a különbségeket szinkronizálni hálózaton keresztül egy szerviz leállítás után -> Elméletileg még kivitelezhető is lenne, de sok a buktató (ha file szinten akarja az ember csinálni, akkor minden megváltozott file-t át kell teljesen tölteni ismét (mondjuk rsync-el) - ez esetben a szinkronizálás a megváltozott adatmennyiség és a hálózat sebességének a függvénye ; blokk szintű szinkronizálásnál meg semmit nem nyerünk, tekintve, hogy az összehasonlításhoz a teljes adatmennyiséget ismét át kell küldeni (csak hogy össze tudjuk hasonlítani, hogy hol a különbség) - különben is.. csináljon ilyet az akinek 2 anyja van!)

Anno a beszélgetésünk itt kb abban is maradt (főként mert volt más tenni való), de ez a probléma úgy szöget ütött a fejemben, és mint ahogy az lenni szokott munka után (szabadidőben) jött a felismerés, miszerint az egész problémát teljesen rossz oldalról közelítettük meg: Teljesen felesleges a célgépen lévő adatot egybe kezelni, amikor azt külön lehet bontani rendszerre, illetve minden másra.
Persze a kérdés jogos: És ez miért olyan nagy különbség? A válasz pedig az, hogy míg a rendszer a rootvg-n helyezkedik el, addig a futtatott szerviz azon kívül (általában valami appvg-ben) és hogy-hogy nem az utóbbi foglalja a hely többségét (a rootvg általában megáll 30 GB alatt, feltételezve hogy valaki barom nem telepítette a rootvg-be az middleware-t meg az applikációt is (aki ilyet tesz az ne csodálkozzon, ha egy bizonyos hozzátartozója gyakran csuklik)).
Ha ez még mindig nem elégséges indok, akkor felhívom a figyelmet arra, hogy míg a rootvg bootolható kell legyen, addig az appvg véletlenül se, ami viszont nyomban lehetővé teszi egy viszonylag ritkán használt technika alkalmazását amit úgy hívnak hogy GLVM.

Aki esetleg még nem találkozott ezzel a technológiával annak az alábbi leírások átfutását javaslom: 1 2 3 4

Amit kiemelnék:
- Kliens <-> szerver alapú megvalósítás
- A technológiára a PowerHA_XD meglehetősen komolyan épít, viszont a technológia része az alap AIX-nek is(bár gyárilag nem települ, viszont megtalálható a telepítő lemezen)
- A technológia lehetővé teszi 1 PV (lényegében diszk) megosztását hálózaton keresztül (kb mint egy iSCSI)
- A GLVM a távoli diszk elérését vezérli, ezen felül minden mást az AIX-os LVM managel le, mint egy normál PV esetében (Kiegészítésként azért meg kell jegyezni, hogy a GLVM-nek is van egy pár megkötése az LVM-en belüli VG-k/LV-k beállításait illetően (mint például a superstrict allocation policy))

Na akkor innen indul a buli. A migráció innentől fogva a következő fázisokra osztható fel:
1) A cél szerverhez előre ki kell allokálni a megfelelő mennyiségű (és méretű) PV-ket, amit aztán a forrás gép számára RPV-n keresztül elérhetővé kell tenni
2) A forrás oldalon ezeket a diszkeket fel kell konfigurálni, majd betolni a non-rootvg(k) alá.
3) Amint a szükséges mennyiségű extra tárhely elérhető a VG-ken belül (2x annyi, mint amekkora eredetileg volt) gond nélkül el is kezdhetjük tükrözni a VG(ke)t bármiféle kiess nélkül (az adatmennyiség mértékétől függően ez eltarthat egy darabig)
4) Miután a tükrök felépültek (és szépen szinkronban is vannak) lényegében szabad az út a migrálás elkezdéséhez, csupán a pontos időt kell leegyeztetni a customerrel
5) Amikor is eljön a nagy nap, akkor a forrás oldalon annyi a dolgunk, hogy rootvg-ről készítünk egy mksysb backupot (ezt mondjuk még mindig kénytelenek leszünk áttolni a hálózaton keresztül aznap), majd leállítunk mindent, megtörjük az elkészített tükröt, és lekapcsoljuk a gépet
6) A cél oldalon pedig vissza kell állítsuk az mksysb-nket (preferáltan egy NIM szerver bevonásával), majd a tükör lokális példányából visszaépíteni a non-rootvg adatait
7) Amennyiben szükséges, úgy még 1-2 utó konfigurációs munkát el lehet végezni (igényeknek megfelelően), aztán mindent lehet is szépen visszaindítani

Nézzük meg akkor ezeket a lépéseket közelebbről is:

1) RPV szerver allokáció
A diszk allokálást nem fogom részletezni, a diszkek kiajánlásába viszont érdemes kicsit belemenni. Tekintve, hogy alapértelmezetten a szükséges csomagok nincsenek telepítve, így mindenki kapja elő a 6.1/7.1es alap telepítő DVD/CD-ket és telepítse fel a 'glvm.rpv' bff csomagot (ebben megtalálhatóak a glvm.rpv.server, glvm.rpv.client, glvm.rpv.util LPP csomagok).
Amint ez megvan, meg kell adjuk az RPV szerverünk nevét. Ezt a smitty rpvservername_edit_dialog (fastpath), avagy a smitty rpvserver / Remote Physical Volume Server Site Name Configuration / Define/Change/Show Remote Physical Volume Server Site Name menüpontja alatt tehetjük meg Ha ez megvan, akkor el is kezdhetjük kiallokálni a diszkjeinket a smitty rpvserveradd_select (fastpath), avagy a smitty rpvserver / Add Remote Physical Volume Servers menüpont alatt

  Physical Volume Identifiers       000dd32daa568b07
* Remote Physical Volume Client Internet Address  [1.2.3.4] 
  Configure Automatically at System Restart?   [yes]
  Start New Devices Immediately?      [yes] 

# A 'Remote Physical Volume Client Internet Address'-nél a távoli gép IP-je kell, viszont azért én azt is hozzátenném, hogy az IP DNS neve legyen feloldható is (vagy DNS szerver, vagy /etc/hosts alapján)

Parancssori alternatíva (ha tudunk minden adatot (rpvs_pvid, client_addr)):
/usr/sbin/mkdev -c rpvserver -s rpvserver -t rpvstype -a rpvs_pvid=000dd32daa568b07 -a client_addr=1.2.3.4 -a auto_online=y

Ezt mint mondtam el kell játsszuk az összes migrálásra szánt PV-re, viszont itt azért felhívnám a figyelmet arra, hogy hiába rendelünk 1-1 rpvserver-t minden egyes diszkhez, az AIX attól még nem foglalja le az original diszket, így simán előfordulhat, hogy véletlenül (oda nem figyelés), vagy csak más kollégák "segítsége" miatt a diszket más kezdi el időközben használni, így én azt is javasolnám, hogy valahogy ezeket a diszkeket jelöljük meg (vagy rendev-vel nevezzük át őket, vagy simán csak hozzunk létre rajtuk egy VG-t (pl. migrationvg1 - ezzel is feltüntetve, hogy a diszkek a migrációhoz lesznek felhasználva)

2) RPV kliens konfiguráció és VG extension
Felkonfigurálni a kiosztott diszkeket se lesz nehezebb, mint kiosztani őket, bár a 6192es portot lehet át kell engedni a szerver és a kliens között a tűzfalon. Ha a glvm.rpv.client csomagot még nem telepítettük, akkor itt az ideje, ellenkező esetben smitty rpvclientadd_select_ip (fastpath) avagy a smitty rpvclient / Add Remote Physical Volume Clients menü alatt fel is vehetjük az első pontban kiosztott diszkeket.

  Remote Physical Volume Server Internet Address  2.3.4.5
  Remote Physical Volume Local Internet Address  1.2.3.4
  Physical Volume Identifiers       000dd32daa568b07
  I/O Timeout Interval (Seconds)      [180]
  Start New Devices Immediately?      [yes] 

Parancssori alternatíva (ha tudunk minden adatot (pvid, server_addr, local_addr)):
/usr/sbin/mkdev -c disk -s remote_disk -t rpvclient -a pvid=000dd32daa568b070000000000000000 -a server_addr=2.3.4.5 -a local_addr=1.2.3.4 -a io_timeout=180

Ahogy az rpvserver-eket is külön-külön kellett kiosztani, így az rpvclient-eket is egyesével kell felkonfiguráljuk.
Ha sikerült mindegyiket szépen berángatni, akkor még vissza van az, hogy az új diszkeket betoljuk a VG alá.
Alapjáraton ugye erre egy sima 'extendvg $VG $HDISK' elég lenne, viszont mivel hogy itt egy teljes tükröt akarunk csinálni, így mielőtt még ebbe bárki belefogna melegen ajánlanám, hogy nézze meg, hogy minden diszk bele fog e férni a VG alá (Ha a MAX PVs /2 kissebb, mint a "TOTAL PVs" akkor garantáltan nem fog beleférni ; Ez mellett még figyeljük arra is, hogy a MAX PPs per PV * PP SIZE se érje el a diszkünk aktuális méretét (különben nem fog bele férni a VG-be)). Amennyiben itt problémába ütközünk, úgy simán előfordulhat, hogy a VG-nél factor-t kell állítani, vagy a VG-t át kell konvertálni (BigVG-be avagy ScalableVG-be attól függően hogy épp milyen VG-nk van, viszont azt tessék észben tartani, hogy Normal - BigVG konverziót lehet online csinálni (már ha nem Concurrent VG-nk van), míg Scalable-be csak offline (varyoffvg után) tudnánk, így itt még némi extra outage befigyelhet).
Amennyiben ilyen problémába nem ütközünk bele, úgy simán mehet az extendvg.

# Megjegyzés: Ha előzőleg a diszkekre létrehoztunk egy külön VG-t (hogy megjelöljük a diszkeket), úgy az extendvg-nél szükség lesz a -f kapcsolóra, de ez esetben figyelmesen járjunk el és bizonyosodjunk meg róla, hogy tényleg jó diszket piszkálunk, mielőtt egy rossz diszk VGDA-ját vágnánk felül.

3) VG tükör létrehozás
Itt jön most az, hogy tükrözni kéne, ugye :) Ha ezt eszetlenül meg is kíséreljük ebben a fázisban, akkor a legtöbb esetben szembe is jön ez a hiba:

# mirrorvg appvg
0516-404 allocp: This system cannot fulfill the allocation request.
        There are not enough free partitions or not enough physical volumes
        to keep strictness and satisfy allocation requests.  The command
        should be retried with different allocation characteristics.
0516-1517 mklvcopy: Failed to create a valid partition allocation.
0516-842 mklvcopy: Unable to make logical partition copies for
        logical volume.
0516-1199 mirrorvg: Failed to create logical partition copies
        for logical volume applv.
0516-1200 mirrorvg: Failed to mirror the volume group.

Noh kérem, ez azért van mert mint fentebb említettem a GLVM azért megkövetel 1-2 LV beállítást, mielőtt az RPV-t ténylegesen a VG részeként kezelné. A szükséges beállítások a következők:
- A szerver IP címe itt se árt ha feloldható (reverse DNS lookup), így -ahogy azt már fentebb is kiemeltem- érdemes az IP-t a /etc/hosts alá felvenni.
- A VG alatt lévő összes LV allocation policy-je Superstrict kell legyen. Ezt a 'chlv -s s -u 32 $LV' paranccsal tudjuk online állítani
# Megjegyzés: a -u 32 az upperbound limitet jelöli, ami több PV-n szétterülő LV-k esetén lehet nagyobb is mint 32; viszont nincs értelme magasabbra állítani, mint a VG-ben lévő PVk száma.
- Az VG alatt lévő összes LV inter-policy-je legyen minimumon. Ezt a 'chlv -e m $LV' paranccsal online tudjuk állítani

Ha ezek megvannak, akkor kezdhetjük is a tükrözést, bár itt felhívnám a figyelmet arra, hogy mivel meglehetősen sok adatot készülünk áttolni a hálózaton, így érdemes elgondolkodni azon, hogy pontosan hogy is akarjuk a mirrort összehozni:
- Minden LV-t külön-külön (esetleg csoportokban) tükrözünk meg az 'mklvcopy -s s $LV 2 $HDISK' paranccsal (ez esetben a hálózati terhelést megpróbálhatjuk korlátozni a szerviz időn kívülre némileg, bár ha egy LV mirror-t elindítottunk, akkor azt onnan ne akarja senki se leállítani :) Továbbá érdemes szem előtt tartani, hogy az mklvcopy az előtérben fut, így a console-unk egy ideig valószínű használhatatlan lesz (már amíg a türközés be nem fejeződik)
- A teljes VG-t egyben a mirrorvg paranccsal (ez esetben javasolnám a -S kapcsoló használatát azon oknál fogva, mert így a mirror a háttérben fog folyni, és nem fogja megakasztani az lsvg, lslv parancsokat (mivel nem lesz konstans lock a VGDA-n). Ez a módszer akkor jó, ha az rpvserver, rpvclientek által használt hálózat szeparált a customer networktől, így a hálózati kommunikáció nagyon nem fog bezavarni az ügyfél ügyes-bajos dolgaiba.

Bármelyik módszer mellett is döntünk, arra azért legyünk felkészülve, hogy egy jó ideig el fog tartani a folyamat. Kb az alábbi dolgok befolyásolják a szükséges időt:
- Hálózati sávszélesség (ha van valami izmosabb gigabites kapcsolat, vagy esetleg valami link-aggregation akkor a jumbo-frame-ekkel itt garantáltan jól járunk). Ha viszont Virtualizált a network, akkor készüljünk fel, hogy a PVID-ra ráakaszkodott más LPAR-ok is beleszólhatnak a játékba (illetve vice-versa: a mi kliens LPAR-unk is beleszólhat az ő játékaikba :))
- Kliens oldali I/O terheltség (attól függően hogy az alkalmazások mennyire pörgetik a diszkeket)
- Kliens/szerver oldali I/O adatátviteli sebesség

Érdemes a tényleges mirror előtt egy tesztet csinálni, ha ki is akarjuk deríteni hogy pontosan milyen sebességet is tudunk elérni a 2 gép között, hogy legalább hozzávetőlegesen meg tudjuk becsülni a szükséges időt a tükör felépítéséhez.

4) Checkpoint, VG tükör fenntartása
A tükör felépültét, illetve épségét az 'lsvg -l $VG ' paranccsal tudjuk a legkönnyebben monitorozni -> ha az összes LV open/syncd-be van (és az PPs száma dupla az LPs-nek) akkor örülhetünk, mert az adat mozgatás nagyja már meg is volt, ráadásul úgy hogy eddig (elméletben) 1 perc kiesés nem volt. Itt az ideje lebeszélni a customerrel, hogy pontosan mikor is lehet a szervert költöztetni.
Amennyiben a megállapodott időpont a nem túl közeli jövőben lenne, úgy figyeljünk arra, hogy a tükör ép is maradjon (ne nagyon indítgassunk újra dolgokat, illetve imádkozzunk, hogy ne nagyon legyen hálózati probléma). Amennyiben a kapcsolat ideiglenesen bármilyen oknál fogva time out-ra futna, akkor a hálózati hiba elhárítása után az rpvclient-eket manuálisan kell ismét felhúzzuk, majd a tükröt helyre állítsuk (immár kevesebb időbe fog telni, mint egy full remirror, de azért ez is eltarthat egy darabig).
Azt viszont tessék észben tartani, hogy ettől a ponttól kezdve minden diszkre történő írás mind a 2 oldalon kell érvényesüljön, így a hálózat képes lehet az I/O loadot némileg visszafogni (szóval nagyon I/O write intenzív alkalmazás lehet hogy nem fogja magát túl jól érezni egy ilyen környezetben)

5) Létrehozott tükör felhasználása/megtörése
Ha eljött az idő a migrálásra, akkor először is győződjünk meg róla, hogy a tükör/tükrök még mindig jó állapotban vannak, ez után készítsünk a rootvg-ről egy mksysb-t (ha 6.1 TL9, vagy 7.1 TL3 SP1-en avagy afölött vagyunk, akkor a -T kapcsolóval egy meglehetősen probléma mentes backup készíthető, hála a snapshotingnak :)), amit aztán másoljunk át a hálózaton keresztül a távoli NIM szerverre.
Ha ez megvan, akkor választás előtt állunk: Mit is akarunk kezdeni a felépített tükrünkkel? 2 féle lehetőség adódik ugyan is:
- Megtörhetjük a tükröt a splitvg paranccsal
- Felhasználhatjuk a tükör felét a recreatevg paranccsal

A 2 módszer célja kb azonos, viszont a kivitelezés merőben eltér egymástól, így érdemes belemenni, hogy melyiknél mire is kell számoljunk:

a) A splitvg esetén (ajánlom a -i kapcsolót) az RPV diszkekre készített mirror copy-t le tudjuk választani az eredeti VG-ről, ezzel egy új (és szép konstans) VG-t hozva létre. Az új VG nevét mi állítjuk be, viszont az esetleges LV név és FS mount ütközést elkerülendő az AIX automatikusan hozzá fog csapni minden LV-hez egy fs prefixet (tehát lv01-ből lesz egy fslv01), illetve az eredeti mount point helyett a /fs/$ORIGINAL_MOUNT lesz az alapértelmezett mount (/app/log helyett /fs/app/log). Ez kapásból azt is jelenti, hogy:
- Ezeket a változásokat a cél helyen majd vissza kell kézzel csináljuk
- Az LV név változtatás bizonyos helyzetekben lehet macerás lesz, főleg ha van olyan LV a VG alatt ami alapjáraton 15 karakter hosszú (default maximum) ami a splitvg eredménytelen lefutását eredményezi (tekintve, hogy a splitvg nem lesz képes a prefixel megtoldani az LV nevet). Ezeket az LV-ket még a splitvg előtt át kell így nevezni, ám ha az érintett LV pont egy RAW kötet/container, akkor ott komoly problémáink lehetnek (tekintve, hogy az adatbázisok hajlamosak a /dev/$LV_NAME-re ráakaszkodni, ergo amíg az adatbázis az LV-t használja, addig nem is lehet azt átnevezni)

b) A recreatevg esetén a tükröt nem a forrás oldalon törjük meg, hanem a cél szerver oldalon -> a recreatevg képes a tükör feléből visszaépíteni a VG-t (immáron mirroring nélkül), ami annyiból jó, hogy (ha jól van felparaméterezve) nem kell szöszölni az LV nevek és FS mount pointok utólagos állítgatásával a cél oldalon, viszont cserébe ha valamilyen oknál fogva vissza szeretnénk állni az eredeti szerverre, akkor abban a problémában fogjuk magunkat találni, hogy mivel a recreatevg belenyúlt a VGDA-ba (és új vg_id-t generált), így a source oldalon felépített tükrünk nem hogy törött lesz, hanem egyenesen használhatatlan (amit egy újabb recreatevg-vel tudunk csak helyrepofozni, immár ismét tükör nélkül, ergo az egész játékot lehet kezdeni elölről).
Továbbá érdemes megjegyezni, hogy ha ezt a módszert szeretnénk használni, akkor érdemes a Quorum-ot is kikapcsolni a 'chvg -Qn $VG' parancsal :)

Én személy szerint eléggé megbarátkoztam már a recreatevg-vel ahhoz, hogy különösebb szív problémák nélkül merjem használni, de az aki inkább a biztosabb konzisztencia irányába szeretne elmenni, az inkább ne ezt a módszert használja.

Miután sikerült eldöntenünk, hogy melyik módszer mellett tesszük le a voksunkat (én maradok a recreatevg-nél :)) szépen mountoljuk le a filerendszereinket, tegyük a VG-t varyoffba, és biztos ami biztos még engedjünk el egy 'sync;sync;sync'-et hogy minden konzisztens is legyen. Ezután a forrás gépet lényegében le lehet állítani.

6) Migráció véglegesítése a cél gépen.
Miután a NIM szerverről visszatöltöttük az előzőleg elkészült mksysb-t, már csak annyi a dolgunk, hogy visszarángassuk az appvg-(in)ket az ODM-be. Ehhez első körben el kell távolítsuk az rpvserver device-okat, majd attól függően hogy az 5. pontban melyik módszer mellett döntöttünk használhatjuk ..
.. az importvg-t: ez esetben elég ha az importvg-nek egy diszket megadunk (importvg -y $VGNAME $HDISK) , a parancs automatikusan kiolvassa a VG-t alkotó diszkek PVID-ját, és végigellenőrzi, hogy mind megtalálható e a rendszer alatt, majd beimportálja a VG-t a rendszer alá. Ne felejtsük el visszaállítani az eredeti mount pointokat, illetve LV neveket (plusz az FS-ek loglv nevét) ez után
.. a recreatevg-t: ez esetben nekünk kell kézzel megadni, hogy a VG mely diszkekből épül fel pontosan (recreatevg -y $VGNAME -Y NA -L / -f $HDISK1 $HDISK2 $HDISKN). A sikeres futtatás után a rendszer egy új VG-t épít fel a VGDA-ban elérhető adatok alapján, amit aztán további módosítások után szabadon is használhatunk

***********************
Ezzel a módszerrel (optimális esetben) pár óra kieséssel megoldható egy szerver költöztetés, úgy hogy az előkészületeket már jóval a költöztetés kezdete előtt megkezdi az ember. A módszernek persze ára van, cserébe a customer dédelgetett szolgáltatása (némi kis performance veszteség árán) képes folyamatosan üzemelni és ellátni a "kritikus" (!!!) feladatait.