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)