Vannak helyzetek, amikor az ember elkezd azon agyalni, hogy a hivatalos utakon kívűl vannak e mások is.. Utak, amiken szintén el lehet indulni, és amin keresztül el lehet jutni A-ból B pontba.. Lehetőleg még gyorsabban is, vagy kevésbé fájdalmasan 1-1 issue alkalmával..
És vannak alkalmak amikor az ember igen is az ilyen utakon akar járni, főleg ha rájön, hogy azok sokkalta kifizetődőbbek, mint a hivatalosak. Na ez az eset pontosan ilyen volt :)
A szituáció adott: Van egy JFS2 filesystem, kellemes kis 2 TB-os mérettel, alatta "egy pár" LUN-al (diszkkel), és egy csúnya üzenettel az errpt-ben, miszerint:
server # errpt |head -2
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
E86653C3 0723123112 P H LVDD I/O ERROR DETECTED BY LVM
Nem kell sokat találgatnotok -> Igen, az az I/O error az adott 2 TB-os FS-re jött.. Tekintve, hogy az FS DS8K-s LUN-okra építkezik így ez még viccesebbé teszi a helyzetet, mivel ez csak az alábbi scenario-k között jöhet létre:
- Disk management issue (ez esetben a driver szopat)
- Fibre adapter issue (már ha nincs normális redundancia)
- Disk locking issue (ha ne adj isten a LUN több helyre van kizónázva, és más is használja az adott LUN-t, főleg ha még írni is akar rá)
- SAN box oldali issue (a DS oldali kötet hibás ottani adapter, vagy diszk hiba miatt)
Egyik se kellemes, mit ne mondjak..
Az első amit ilyenkor tudnunk kell, hogy a hiba milyen körülmények között jön elő. Jelen esetben annyit kell még tudni, hogy csak 1 LUN-ja jött a hiba, de arra állandóan, így az első 2 hibalehetőséget nyomban ki is lehet zárni (a driver CSAK 1 diszket nem köhög meg, hanem akkor konzisztensen szívatja az összeset, a HBA meg dettó nem hajlamos kispécizni magának LUN-okat :)).
A másik 2 lehetőség felderítéséhez meg a Storage szerveren kell turkálni ami meg jelen esetben másik team hatásköre volt, ám némi kis nyomozás után kiderült, hogy a zónázással nincs gond, viszont a kiosztott LUN alatt lévő fizikai réteg bizony kehés, ergo azt ők gyorsan orvosolják..
Egy részről ez jó mert egy elég komoly hibát sikerül megoldani, más részről viszont kliens oldalon (igen, nálam) még mindig ott az a fránya kis probléma, minek eredete, hogy nem férek hozzá az adatomhoz, és esélyes, hogy a javítás után se tudnék, ergo ezt nekem is valahogy orvosolni kéne..
A kérdés persze, hogy hogyan.. A probléma ugyan is az, hogy van minimum 1 blokkom a diszken, amit garantáltan nem tudok olvasni, azt kitiltani nem tudom, migrálni szintúgy nem (pont az olvasási hiba miatt), szóval 2 szék között sikerült a pad alá kerülnöm.. Ilyen esetben a hivatalos megoldás az lenne, hogy töröljem az FS-t, hozzam létre újra (és figyeljek, hogy az a LUN véletlenül se legyen ismét része az új FS-nek), majd backup-ból restore-oljam.. Ok, de 2 TB adatról beszélünk, a restore sok idő, a downtime meg drága..
Így hát adott a kérdés - hogy a francba minimalizáljuk a downtime-ot? Ez a kis leírás kb egy scenario-t mutat be arra amit sikerült kiötlenem :)
Na szóval.. Mondtam, hogy a migrálás zsákutca.. Ezt persze nem hasra ütés alapján merem kijelenteni, hanem fájdalmas tapasztalatból, ugyan is sikerült így járjak az adott LUN-al:
server # migratepv vpath59 vpath91
0516-076 lmigratelv: Cannot remove last good copy of stale partition.
Resynchronize the partitions with syncvg and try again.
0516-812 migratepv: Warning, migratepv did not completely succeed;
all physical partitions have not been moved off the PV.
őő.. Egen.. Egy próbát megért, be is bukott.. (akinek a vpath nem lenne ismerős -> tekintve, hogy DS-ről beszélünk, így SDD driver megy az AIX alatt, ami meg hdisk-ek helyett vpath-okat használ) Megnézve a VG/LV adatokat meg ilyen randaságok jöttek szembe:
server # lsvg -l appvg |grep applv
0516-1147 : Warning - logical volume applv may be partially mirrored.
applv jfs2 8192 9216 9 open/stale /appdata
A VG PP size-a 256 MB, az FS pont 2 TB (8192 PP), és 9216 PP-nyi hely van felhasználva, tekintve, hogy az egyik PV-t épp át akartuk migrálni egy 9. 256 GB méretű LUN-ra (ami alapjáraton a LUN mirrorozását jelenti). Sajna a partíció open/stale helyzetben van, és ezen egy syncvg se segít
server # syncvg -l applv
0516-934 /usr/sbin/syncvg: Unable to synchronize logical volume applvg.
Ez a helyzet már magában is vicces, mivel nyomban plusz egy problémát hoz be a képbe, miszerint "Hogy a francba szedjem le a mirrort arról a LUN-ról".. unmirrorvg nem segít, az teljes VG-re van, rmlvcopy se, mert az meg teljesen kimirrorozott LV-re használható csak (itt meg csak 2 PV van "mirrorban" a 9ből), más hivatalos módszer meg nincs (vagy csak nekem nem jut eszembe)..
Ha viszont még valaki emlékszik, akkor én
írtam egy módszerről anno, hogy hogy is lehet LV-t csökkenteni Na.. Ez a módszer most épp kapóra jön, csak kicsit másként kell használni, de a recept hasonló:
- Olvassuk ki az LV mappolását egy külön file-ba
- Szűrjük le, hogy mit akarunk kiszedni az LV alól
- Umountoljuk az FS-t (és tegyük closed-ba így az LV-t)
- Dobjuk ki ami nem kell
Ez kb így nézett nálam ki:
server # lquerylv -L $(getlvodm -l applv) -r > /tmp/mapfile
server # grep $(lspv |grep -w vpath91|awk '{print $2}') /tmp/mapfile >/tmp/mapfile2
server # wc -l /tmp/mapfile2
1024 /tmp/mapfile2
server # umount /appdata
server # lreducelv -l $(getlvodm -l applv) -s 1024 /tmp/mapfile2
Ezt még persze megfejelhetjük egy fsck-val mount előtt, de itt még nem lesz probléma garantáltan.. Viszont innentől az FS visszaáll open/syncd-be :)
server # lsvg -l appvg |grep applv
applv jfs2 8192 8192 8 open/syncd /appdata
Ezzel egy problémát megoldottunk, viszont az eredeti még mindig megvan.. Viszont a fenti koktél némileg másként keverve itt is segíteni tud -> a módszer használható PP-k/LP-k teljes "lecserélésére" is ha összekombózzuk az lextendlv-vel :) A módszer kb így néz ki:
- 1x is pakoljunk át mindent amit tudunk a hibás LUN-ról (diszkről, ha úgy jobban tetszik) egy másik használható LUN-ra
- A pakolás közben 1, vagy több LP garantáltan nem fog átmenni, de nem is kell, elég ha a használható adat átballag a másik helyre
- Miután megvan, hogy mely LP-k nem teljesen elérhetőek, azokat kidobjuk a fenti módon
- Majd ezután ugyan annyi LP-t adunk az új diszkről, csupán az LP számozásra kell figyeljünk
Ennek a módszernek egyik nagy előnye, hogy nem kell a teljes FS-t backupból visszahozni, a másik oldalról viszont az elvesztett PP-ket üres PP-vel fogjuk feltölteni, ami meg elég durva adatvesztést/adatinkonzisztenciát jelent, amit viszont valahogy le kell kezelni. Tekintve, hogy az adat már most se nagyon elérhető, így ez még mindig a leghasználhatóbb útvonal a hiba javításához (lehet dönteni, hogy az adat nem elérhető, vagy 0-val van feltöltve -> restore mind a 2 esetben kell).
Ehhez persze tudni kell, hogy mely file-ok lesznek érintettek, ergo be kell vetni még 1-2 plusz lépést, hogy tudjuk mi és merre.. A legegyszerűbb erre az, hogy a file-okból egy checksum-ot generálunk (az legalább végigmegy a file-okon, és nem az attribútumok alapján próbál tájékozódni) a művelet előtt, majd utána, aztán összevetjük a kettőt egy diff-el, majd ami változott azt visszahozzuk backupból. Ez alapján a fenti terv az alábbi módon módosul:
- Checksum generálás minden FS-ben lévő file-ról
- LP-k migrálása egy másik LUN-ra (vpath91 a mi esetünkben) az eredeti LUN-ról (vpath59)
- FS umountolása (LV closed-ba tétele)
- Hibás PP-k/LP-k kidobása (azaz, ami marad a migráció után)
- Új "üres" PP/LP hozzáadása az LV-hez
- Újabb checksum generálás a file-okról
- A 2 checksum kimenet összevetése
- TSM restore a változott file-okról
Parancsokra lebontva ez az alábbi módon néz ki:
server # find /appdata -type f -exec sum {} \; >/tmp/checksum1
server # lslv -m applv |grep vpath59 > /tmp/applv_lslv_out
server # for i in $(awk '{print $1}' /tmp/applv_lslv_out);do migratelp applv/${i}/1 vpath91;done
....
server # lquerylv -L $(getlvodm -l applv) -r |grep $(lspv |grep -w vpath59|awk '{print $2}') > /tmp/mapfile_remove
server # umount /appdata
server # export LP_ERRORS=$(wc -l /tmp/mapfile_remove|awk '{print $1}')
server # lreducelv -l $(getlvodm -l applv) -s ${LP_ERRORS} /tmp/mapfile_remove
server # sed "s/$(lspv |grep -w vpath59 |awk '{print $2}')/$(lspv |grep -w vpath91|awk '{print $2}')/g" /tmp/mapfile_remove > /tmp/mapfile_add
server # lslv -m applv |grep -w vpath91 |awk '{print $2}' |sort -n|tail -1
1022
# Azon LP-k száma, amit sikerült átmigrálnunk a migratelp-vel a vpath91re
server # vi /tmp/mapfile_add
# Itt kell átírjuk az LP számozást, nehogy ütközzön az előzővel (tehát a 2 LP-nk (Ennyi volt az $LP_ERRORS nálam) száma 1022 fölött kell legyen.
# Én maradtam az 1023 és az 1024-nél :)
server # lextendlv -l $(getlvodm -l applv) -s ${LP_ERRORS} /tmp/mapfile_add
server # fsck /dev/applv
The current volume is: /dev/applv
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
server # mount /appdata
server # find /appdata -type f -exec sum {} \; >/tmp/checksum2
server # diff /tmp/checksum1 /tmp/checksum2 > /tmp/checksum_difference
server # for FILE in $(awk '/^</ {print $3}' /tmp/checksum_difference);do dsmc rest $FILE;done
... PROFIT ...
# A folyamat persze feltételezi azt, hogy az FS alatt nem történik ilyenkor más változás, ergo az applikációs team-et a folyamat alatt illik távol tartani.. Viszont ez a módszer egész türhetően levitte számomra a visszaállítandó adat mennyiségét 2 TB-ról 3,2 GBra (2 db 256 MB-os PP sérülés volt az adott PV-n, azok közül az egyik meg pont egy nagyobb file-ban, ergo azt teljesen vissza kellett állítani)
Mi is történt? Kicseréltünk 2 LP-t 1 LV alól, úgy hogy azt a hivatalos módszerekkel elvileg meg se lehet oldani (legalább is nem ilyen módon). Mindebben pedig a legszebb, hogy az egészből az FS szinte alig vesz észre valamit, max némi adat nullázódik ki, de azt meg TSM-ről visszahozzuk..
Azt azért persze hozzá kell tennem, hogy
ez a módszer véletlenül se támogatott hivatalosan, és ha az IBM support észreveszi, hogy nem a normál módon járunk el, akkor az ebből fakadó hibákra semmiféle felelősséget nem vállal, szóval óvatosan játszadozzon ezzel a módszerrel bárki is, és csak is saját felelősségre!
***********
Némi kis bónusz - ha az lvextend előtt kérjük le az LV állapotát, akkor ilyen kellemes helyzetben találhatjuk magunkat :))
server # lsvg -l appvg |grep applv
0516-1147 : Warning - logical volume applv may be partially mirrored.
applv jfs2 8192 8190 8 open/stale /appdata
Kezdjük is a kernellel, ha már a gyanúsítgatásnál tartunk ("Ahol a kormány, ott van a gáz.."). Aki olvasta eddig a blogomat annak ez a fordulat azt hiszem nem lesz komolyabb meglepetés :)
Akinek még is, annak javaslom az itt emlegetett módszerek és parancsok áttanulmányozását a folytatás előtt
Na szóval.. a netstat megsúgta nekünk, hogy a f10006000243c398-es dugi csokira jár rá a kis szellemünk, úgy hogy kezdjünk el az után nyomozni első körben:
