HACMP failover issue - Unable to unmount the filesystem

Az ember egy idő után már hajlamos azt hiszi, hogy azért nem lehet könnyen meglepni, ha már egy csomó szívást átélt, meg már a kdb-s bugyrokat is megjárta.. Hiába tudjuk, hogy Murphy csak az ilyen jelekre vár, mindig azt hisszük, hogy fel tudjuk venni vele a kesztyűt.. Aztán az ember szembe kap egy általánosnak tűnő problémát, elkezdi a saját kis módján investigálni, majd akkor koppan amikor rájön, hogy valami mégse úgy megy ahogy kéne, vagy valami még így is van amire nem gondolt előzőleg.

Ez se volt most másként.. Felhívtak kollégák, hogy lenne egy HACMP failover probléma: Szegény RG nem tud átállni, és meg kéne már nézni, hogy mi a rákért nem..
Hát jó.. hacmp.out túrás , és elég gyorsan szembejön az első gyanús jel:

***************************
Nov 3 2012 19:42:13 !!!!!!!!!! ERROR !!!!!!!!!!
***************************
Nov 3 2012 19:42:13 cl_deactivate_vgs: Failed varyoff of appvg.

Aham.. na jó.. nézzük mi van még itt, ami miatt ez előjöhetett:

+app_rg:cl_deactivate_vgs(5.910):appvg[vgs_varyoff+282] varyoffvg appvg
0516-012 lvaryoffvg: Logical volume must be closed.  If the logical
        volume contains a filesystem, the umount command will close
        the LV device.
0516-942 varyoffvg: Unable to vary off volume group appvg.

Ahh.. haladunk.. Mi törpént az FS-el?

+app_rg:cl_deactivate_fs(.160)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy
+app_rg:cl_deactivate_fs(2.160)[fs_umount+66] : At this point, unmount of /var/mqm/RGmount has not worked. So,
+app_rg:cl_deactivate_fs(2.160)[fs_umount+67] : Send a SIGKILL to all processes having open file
+app_rg:cl_deactivate_fs(2.160)[fs_umount+68] : descriptors within this logical volume to allow
+app_rg:cl_deactivate_fs(2.160)[fs_umount+69] : the umount to succeed.
+app_rg:cl_deactivate_fs(2.160)[fs_umount+71] date '+%h %d %H:%M:%S.000'
Nov 03 19:38:46.000
+app_rg:cl_deactivate_fs(2.160)[fs_umount+72] fuser -k -u -x /dev/RG_LV
/dev/RG_LV:   782460(wasRGuser)  782460(wasRGuser)  868596(wasRGuser)  868596(wasRGuser)  938078(wasRGuser)  938078(wasRGuser) 1081448(wasRGuser) 1081448(wasRGuser)
+app_rg:cl_deactivate_fs(2.740)[fs_umount+73] fuser -c -k -u -x /var/mqm/RGmount
/var/mqm/RGmount:
+app_rg:cl_deactivate_fs(3.260)[fs_umount+74] date '+%h %d %H:%M:%S.000'
Nov 03 19:38:47.000
+app_rg:cl_deactivate_fs(3.260)[fs_umount+77] : Wait 2 seconds for the kills to be effective
+app_rg:cl_deactivate_fs(3.260)[fs_umount+79] sleep 2
+app_rg:cl_deactivate_fs(5.260)[fs_umount+82] : Unmount of /var/mqm/RGmount failed. If the force option can be used, try it here.
+app_rg:cl_deactivate_fs(5.260)[fs_umount+84] [[ -n '' ]]
+app_rg:cl_deactivate_fs(5.260)[fs_umount+99] (( 0 == 57 ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+123] (( 0 == 60 ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+52] ((count++ ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+52] (( count <= 60))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+55] : Try to unmount the file system
+app_rg:cl_deactivate_fs(5.270)[fs_umount+56] date '+%h %d %H:%M:%S.000'
+app_rg:cl_deactivate_fs(5.270)[fs_umount+56] : Attempt 2 of 61 to unmount at Nov 03 19:38:49.000
+app_rg:cl_deactivate_fs(5.270)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy.

Ez a fázis már az application stop után van, ergo a HACMP joggal van felháborodva, hogy miért nem szabad már a device, ha ő azt át akarja adni a másik node-na.. Sebaj, 5.3 óta fel van készítve a HA erre is, gyenge fuser -kux az LV-re megoldja.. fuser -ckux után látszik, hogy tényleg nem maradt process ami használná az FS-t, úgy hogy semmi gáz, mehet az umount..
De álj.. Megint device busy?? Na innen indul a vicces rész.. Főleg amikor az ember eljut a logban eddig:

+app_rg:cl_deactivate_fs(194.630)[fs_umount+56] : Attempt 61 of 61 to unmount at Nov 03 19:41:58.000
+app_rg:cl_deactivate_fs(194.630)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy
+app_rg:cl_deactivate_fs(194.760)[fs_umount+66] : At this point, unmount of /var/mqm/RGmount has not worked. So,
+app_rg:cl_deactivate_fs(194.760)[fs_umount+67] : Send a SIGKILL to all processes having open file
+app_rg:cl_deactivate_fs(194.760)[fs_umount+68] : descriptors within this logical volume to allow
+app_rg:cl_deactivate_fs(194.760)[fs_umount+69] : the umount to succeed.
+app_rg:cl_deactivate_fs(194.760)[fs_umount+71] date '+%h %d %H:%M:%S.000'
Nov 03 19:41:58.000
+app_rg:cl_deactivate_fs(194.770)[fs_umount+72] fuser -k -u -x /dev/RG_LV
/dev/RG_LV:
+app_rg:cl_deactivate_fs(195.300)[fs_umount+73] fuser -c -k -u -x /var/mqm/RGmount
/var/mqm/RGmount:
+app_rg:cl_deactivate_fs(195.810)[fs_umount+74] date '+%h %d %H:%M:%S.000'
Nov 03 19:41:59.000
+app_rg:cl_deactivate_fs(195.810)[fs_umount+77] : Wait 2 seconds for the kills to be effective
+app_rg:cl_deactivate_fs(195.810)[fs_umount+79] sleep 2
+app_rg:cl_deactivate_fs(197.810)[fs_umount+82] : Unmount of /var/mqm/RGmount failed. If the force option can be used, try it here.
+app_rg:cl_deactivate_fs(197.810)[fs_umount+84] [[ -n '' ]]
+app_rg:cl_deactivate_fs(197.810)[fs_umount+99] (( 60 == 57 ))
+app_rg:cl_deactivate_fs(197.810)[fs_umount+123] (( 60 == 60 ))
+app_rg:cl_deactivate_fs(197.810)[fs_umount+126] : Out of retries to unmount /var/mqm/RGmount. Game over, man, game over.
+app_rg:cl_deactivate_fs(197.810)[fs_umount+128] cl_echo 25 'cl_deactivate_fs: Failed umount of /var/mqm/RGmount.\n' cl_deactivate_fs /var/mqm/RGmount

A "Game over, man, game over" kedves kis üzenet a fejlesztőktől, és meg meg is mosolyogtatna ha nem látnám, hogy szegény HA-m 61x próbálta meg lenyomni a szerencsétlen FS-t de mind végig Device busy-t kapott.

OS oldalról elnézve az FS valóban ott van a mount alatt, és ha én akarom leszedni akkor ugyan azt kapom:

server@root:/ # mount |grep RGmount
         /dev/RG_LV     /var/mqm/RGmount   jfs2   Nov 03 19:22 rw,log=INLINE
server@root:/ # fuser -cux /dev/RG_LV
server@root:/ # umount /var/mqm/RGmount
umount: 0506-349 Cannot unmount /dev/RG_LV: The requested resource is busy.

Na akkor áljunk meg itt picit.. Mi az amit érdemes megnézni ilyenkor?
- Használja e valami az FS-t

- Megtettem, nem dobott semmit..

- Haszmálja e az LV-t valami?

- Ez az amit a HACMP is megnézett, és aminek amúgy több értelme is van, mint az FS-t nézni -> van 1-2 olyan parancs ami az LV-ket cseszteti direktben, ergo ha a /dev/LV-re ráengedünk egy fuser-t akkor azokat is meg tudjuk fogni.. A HA 1x ezeket le is gyilkolta, viszont utána már nem talált semmit

- Nincs e submount az adott FS alatt

- Amennyiben egy másik FS van a lemountolandó alá felhúzva, úgy persze, hogy a kernel nem engedi nekünk az umountot (Ilyenkor a submountot kell első körben leszedni). Ezt könnyen ellenőrizhetjük is a mount paranccsal, de itt sajna ez se játszik, mivel nem volt egy submount se

- AIO/CIO használatban van?

- Ezen a rendszeren konkrétan pont egyik sincs, viszont ezek is képesek ilyen szintű lockokat összehozni. Viszont a HA épp ezért is próbálkozik 61x (ami itt közel 3 percig ment is), hogy az ilyen dolgokkal se legyen gáz, ha ne adj isten az AIO/CIO nem volt elég gyors adott pillanatban. Mint látható ez itt szintén nem jött be.

- Named Pipe?

- Egzotikum, viszont nem szabad figyelmen kívül hagyni.. Alapvetően Inter-process communication célokra szolgál olyan esetekben ahol a jogosultság szeparáció nem teszi lehetővé a normális IPC kommunikációt direkt memórián keresztül (Hozzáteszem, hogy ez inkább a régebbi appoknál bevett eljárá. Az AIX jó ideje tud direktben memóriában adatot átadni különböző jogosultsági szinteken futó alkalmazásoknak Shared Memory-n keresztül (szintén az IPC része). Ilyen esetekben az applikáció képes egy ilyen "pipe" file-t létrehozni, és sima chmod-os/ACL-es megoldással másik user alatt futó applikációnak átadni az adatot direktben. A probléma ezekkel viszont annyi, hogy nincs tényleges file írás/olvasás, mivel az egész hóbelebancot az AIX memórián belül képes lezongorázni, így meg a fuser se veszi észre, hogy a háttérben szopatják a népet, mivel az fopen/fwrite/fclose és hasonló eventekre figyel főként.

Persze kérdés, hogy hogy járunk ezeknek utána.

- Egyik módszer a http://p1ngw1n.blogspot.hu/2012/02/fuser-nemileg-maskent.html-ban felvázolt módszer

- Másik meg az lsof :)

Mivel az első módszert anno már lefedtem, így maradjunk az egyszerűbbnél, és nézzük, hogy az lsof-el mit is látunk ilyenkor :)

server@root:/ # lsof |grep /var/mqm/RGmount
runmqlsr_  933958 wasRGuser    6u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/ccc.933958
runmqlsr_  933958 wasRGuser    9u  unix 0xf100020000837c08             0t1728                     /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
runmqlsr_  933958 wasRGuser   12u  unix 0xf100020000736408             0t1852                     /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
amqzmgr0  1093830 wasRGuser    8u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe
amqzmgr0  1200368 wasRGuser    8u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
runmqlsr_ 1605678 wasRGuser    6u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/ccc.1605678
runmqlsr_ 1605678 wasRGuser    9u  unix 0xf100020002275408             0t1728                     /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe
runmqlsr_ 1605678 wasRGuser   12u  unix 0xf100020001ee7808             0t1852                     /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe

BINGO.. Innen már akkor csak akkor gyilkolásznunk kell :)

server@root:/ # kill -9 933958 1093830 1200368 1605678
server@root:/ # umount /var/mqm/RGmount
server@root:/ #

Innen pedig tovább lehet akkor lökni a HA-t is a túloldalra

A történet tanulsága:
- lusta embereknek kötelező az lsof (az experteknek meg a kdb :))
- A HACMP (attól függetlenül, hogy az idők során szinte mindenre próbálták felkészíteni) se tud mindent lekezelni
- A fejlesztőknek is van humora :)
- Murphy lehet, hogy köcsög mindig, de valahogy még is az ilyen szívásokkal tanulja meg az ember, hogy mennyire is halandó, és lényegében így tanulja csak meg azokat a leckéket, amikre más nem lenne képes megtanítani (se iskola, se oktatás, se certifikációk)

Murphy és a "jó" design

Elég mozgalmas volt ez az április, így nem sok időm volt blogolni bármiről is, de azért egy "emlékezetes" issue úgy érzem megérdemel annyit, hogy megmaradjon az utókornak.

Hol volt, hol nem volt (az óperenciás rendszeren is túl) volt egy szerver, aminek a design-ját okos emberek kialakították, és megítélendék jónak. Persze az okos emberek teljesen másra szánták a gépet mint amire azt később a customer nevű állatfaj elképzelte. Így alakulnak ki a természetben az olyan félvér állatfajok, amik inkább csak a hibáikkal tűnnek ki, mint sem a használhatóságukkal, és tuti biztos, hogy a lelkes adminisztrátorok előbb utóbb rájönnek, hogy az ilyen szerverek is inkább csak elrettentő példának jók, min tsem produktív dolgok futtatására, de hát a customert ez a legkisebb mértékben se szokta érdekelni, neki csak az a fontos, hogy az über-fontos dolgok menjenek a gépen..

Na most.. Ha még vannak olvasók akik nálam jobb emlékezettel vannak megáldva, akkor nekik lehet dereng valami a múltból, amikor a design hibákat ecsetelgettem, és már akkor is elmondtam, hogy az adott architect-nek jó rejszolást kívánok egy sajtreszelő társaságában, hogy ezt a design-t képes volt megálmodni

Hogy, hogy nem, most Áprilisban jött el az ideje annak, hogy Murphy ismét szórakozni akarjon, és kitalálta, hogy ez az igen fontos gép amúgy is billeg a szakadék szélén, hát miért ne lökjön rajta egy kicsit.. Persze ha már ott van, akkor a mentőalakulatok útjába is felállít 1-2 csapdát, mert az úgy még is csak nagyobb a FUN faktor.

A valóságban mindez a következőképp realizálódott:
Első körben a fenti design-ban szereplő RAID 5 tömb alól 2 diszk úgy gondolta, hogy őt már nem becsülik meg eléggé, így Seppuku-t hajt végre. "Mázlira" csak az Egyik diszk volt aktív, a másik csak Hotspare, így elméletben még itt nem kéne nagy problémának lennie. Így hát új diszk beszerez, hotplug manager elő, aztán cseréljük on-the-fly a temetőbe szánt Hotplug diszket, ahogy az a nagykönyvben is meg van írva.

Sajna azonban a Nagykönyvekkel mindig az a baj, hogy az emberek elfogadják a benne leírtakat egyfajta axiómának, ami -ha Murphy is a képben van- általában nem teljesen szokta lefedni a valóságot: Így hát persze így se minden úgy működött ahogy kellett volna.. Történt ugyan is, hogy a teljesen szabályosan kicserélt új diszket a rendszer nem volt képes lekezelni, mivel a régi konnekciós azonosítót valamiért nem akarta felszámolni.
Hogy szemléletesebb legyen a dolog, kb ezt látja a szerencsétlen adminisztrátor:

# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Degraded    RAID 5 Array            1135GB                 
 pdisk0   00000200  Failed      Array Member           283.8GB                 
 pdisk1   00000300  Active      Array Member           283.8GB                 
 pdisk3   00000500  Active      Array Member           283.8GB                 
 pdisk2   00000400  Active      Array Member           283.8GB                 
 pdisk4   00000600  Active      Array Member           283.8GB                 

*unknwn*  00000700  RWProtected Array Candidate            N/A                 
pdisk5    00000700  Missing     Disk                   283.8GB

Na szóval.. Vagy egy hdisk3 néven létező RAID 5 tömbünk, ami épp Degrad állapotban leledzik, mindez a sissas5 adapteren. Van 2 halott diszkünk (pdisk0,pdisk5), ami közül pdisk5-öt igyekszünk épp kicserélni, ami jelenleg épp Missing státuszban leledzik. A pdisk5 kapcsolati címén (00000700) azonban van még egy diszk, ami épp RWProtected, amúgy meg unknown (tehát a rendszer nem tud róla semmit). Így meg persze még neki se lehet állni új Hotspare-t definiálni (hogy aztán azt majd bedobjuk a pdisk0 helyére)

Na ez az a rész, amiről a nagykönyv nem ír semmit (Murphy viszont a Pop-corn egy részét már elfogyasztotta).. Ergo akkor nincs más, csak kidobni a vak hitet, és menni az ember saját feje után.
Első körben az előzőleg kicserélt diszk-et kivéve a slotból lehetőség nyílt az unknown device "elvesztésére" ám a rendszer pofátlan módon ragaszkodott a pdisk5 jelenlétéhez, attól függetlenül, hogy az már közel, s távol nem volt a gépben. Külön poénként ezt a meggyőződését még akkor se volt hajlandó elfelejteni amikor a pdisk5-öt 'rmdev -dl'-el lelőttem, majd a config managert (cfgmgr) futtattam, mivelhogy az rendkívül ragaszkodóan visszahozta a pdisk5-öt "Available" státuszban (a RAID vezérlő persze még mindig Missing-nek látta).

Na akkor itt álljunk meg egy picit.. Felmerül a kérdés -gondolom- az olvasóban, hogy biztosan a jó diszk lett kihúzva? Igen, ez volt az első felmerülő kérdés bennem is, de többszöri vizsgálat után is csak az jött ki, hogy valóban a jó diszket piszkálom és az AIX (VIO, de a lényegen semmit nem változtat) az aki foggal körömmel ragaszkodik ahhoz a diszkhez.

Fejvakarás, cseresznyefák, és wattafák.. Avagy csak fák.. Kinek mi esik jól.. Murphy közben a Pop-corn mellett már elindította a háttérben a Kokaku Kidotai (Ghost in the Shell) OST-t is, mert ehhez a jelenethez ez illik a legjobban..

Adminisztrátor részről persze teljes értetlenség, keresés, látott e már valaki valami ilyesmit? Aztán szembejön ez a bug, és fény gyúlik a katakombákban : IZ72353 - SAS PDISK DISPLAYED AS *UNKNWN* AFTER REPLACE/REBUILD APPLIES TO AIX 6100-03

Jah hogy úgy... Hát úgy.. A gáz csak annyi, hogy a patch magában nem elérhető (mivel VIO-ról beszélünk, így csak VIO frissítéssel együtt oldható meg a csótányirtás), így (mivel már mindenki a hátunk mögött van, és a messzeségben már a mesterlövészek is a mi monitorunkat lesik a fejünk mellett) a leggyorsabb megoldás a restart marad. Persze előtte minden kliens azonnal állj, addig a VIO se mozduljon semerre..

Restart, öröm és boduttá.. A pdisk5 végre defined-ban jön fel, sőt az újonnan beletett vinyót is már látja a rendszer.. Sínen vagyunk mint József Attila..
HotPlug diszk megformáz 528 Byte Szektor mérettel, majd a pdisk0 kipöccintése után nyomban be is áll a helyére az immár hamvaiból feltámadt pdisk5 Főnix madár, indulhat az Array Rebuild, semmi ok a pánikra, minden a Ctrl billentyű alatt van

Hátradőlünk, és szépen várjuk, hogy a tömb újjáépítése befejeződjön. A háttérben viszont Murphy ráadást követel, így hát újabb szám zendül fel a hangszórókból.

A moziban ilyenkor kezdenének el villogni a piros villogók, felharsognának a szirénák, és valami kis rangú emberke kétségbe esve megszólalna, hogy "Sir, Something is wrong!" (Thank you, Caption obvious). A valóságban azonban az embert csak egy ilyen hibaüzenet fogadja a fekete putty ablak mögött:

# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Failed      RAID 5 Array            1135GB Rebuild Failed 04
 pdisk5   00000700  Failed      Array Member           283.8GB                 
 pdisk4   00000600  RWProtected Array Member           283.8GB                 
 pdisk3   00000500  RWProtected Array Member           283.8GB                 
 pdisk2   00000400  RWProtected Array Member           283.8GB                 
 pdisk1   00000300  Failed      Array Member           283.8GB                 

pdisk0    00000200  RWProtected Array Candidate        283.8GB

Őőő.. 'nyádat... Újratervezés..
- A pdisk5 most lett kicserélve, leformázva, leellenőrizve, így az garantáltan nem lehet halott (hacsak nem a vezérlő halt meg, de akkor már az ima is édeskevés lesz)
- A pdisk1re eddig nem jött egy hibajelentés se, így azt vessük górcső alá.
- Az errpt entry-jeit elnézegetve (54E8A127 error code (DEVICE OR MEDIA ERROR), ha valakit érdekel) az összes hibajegy a pdisk1-el megegyező Serial ID-ra jön, így tételezzük fel, hogy a pdisk5 Failed státusza az újraépítés során tapasztalt pdisk1 hibájának mellékhatása csak.

Ezzel viszont egy újabb probléma üti fel a fejét: A RAID5 tömb egyszerre csak 1 aktív diszk halált bír ki, kettőt már nem. Amennyiben a pdisk1-et is ki kell cserélni, akkor kalap,kabát, búcsút lehet mondani az adatainknak, mert 3 diszkből már nem engedi a vezérlő se helyreállítani a tömböt (Én megpróbáltam, de hát ez nem linux).
Egy mázli volt - amennyiben az ember újraindítja ebben a fázisban a VIO-t, akkor a SAS RAID vezérlő újra megpróbálja a tömböt össze-eszkábálni, ami viszont kitűnő alkalmat teremt arra, hogy az ember megpróbálja menteni ami menthető.

És itt most álljunk meg ismét egy pillanatra.
- Adott egy fél lábbal már a sírban lévő RAID5 tömb
- A tömbön lévő adatok egy része már garantáltan nem elérhető, tehát a disaster recovery elkerülhetetlen (ugye van disaster recovery plan? :) Megsúgom, az ilyen rendszereknél rendszerint nincs.. Itt a remek alkalom, hogy most fejben összeüss egyet, és imádkozz, hogy az a minimális backup process ami eddig volt elégséges legyen :D )
- Ha mindenképpen kell DR, akkor minek akarok én menteni bármit is?

Nos, a válasz némileg komikus: Az egyik kliens egy Linux rendszer (SLES 10), amely system VG-je 1 VIO-n található LV-re lett ráhúzva (az LVM kell, ha az ember normálisan akarja skálázni a meglévő erőforrásokat, szóval ez még érthető is). Ahhoz, hogy ezt visszaimádkozzuk 3 út maradt:
- Csinálni egy low level mentést byte szinten a "Guest" System VG-jét tartalmazó PV-ről (azaz a VIO-n lévő LV-ről) valahova a RAID tömbön kívűl, és azt megpróbálni visszatölteni amint az új RAID tömbünket kénytelenek voltunk újra kreálni
- Csinálni egy FS szintű backupot (SLES gyárilag tud ilyet), a RAID tömb 0ról való építése után pedig felhúzni egy alap SLES rendszert, és arra visszatölteni az itt készült backup-ot
- Megpróbálni csinálni egy bootolható ISO file-t, azt odaadni a VIO-nak, majd mint CD/DVD-t kiallokálni a kliens felé, és arról visszatölteni az adatokat (Standard Linux környezetben ez szépen megy is, de amúgy vannak direkt erre a célra elkészített programok is, mint pl a Mondo Rescue)

A baj csak az volt, hogy mind3 út buktatókkal volt kikövezve:
- Bootolható ISO készítés: Az elmélet jó, de az egyik verzióban fel kéne raknom a Mondo Rescue (vagy azzal egyenértékű) progit, ami sajna PPC-re nem elérhető. A Debian féle módszer még működne is, de sajna a pSeries gépeken a boot loader nem grub, hanem Yaboot, ami meg nyomban úgy kezdi, hogy külön FAT16 típusú partíció neki, ami az ISO image-em szempontjából így nem járható.
- Az FS szintű backup azért necces, mert egy teljesen új rendszer felinstallálása szükséges hozzá, ami meg iszonyat nagy macera.
- A low-level (dd) szintű backup tűnt a legjobbnak (és akkor még az LVM struktúra is megmarad), ám amennyiben a RAID5 tömb ezen belül hibásodott meg, akkor meg megint ott vagyok ahol a part szakad..

Nem volt mit tenni: Úgy döntöttem, hogy amit lehet menteni kell (lehetőleg minél többféle képen), mivel a jelenlegi állapotot tutira újra is kell építeni. Tehát csináltam egy dd szintű mentést (LPAR lekapcsolva természetesen), meg egy FS szintűt is, felkészülve a legrosszabbra (az applikációs adatokért nem tudtam semmit se tenni, azt majd remélhetőleg a standard backup process által készített backup lefedi az adat visszaállítás során)

Ez után jött a másik 2 diszk cseréje (pdisk0, pdisk1), majd a halott RAID tömb törlése, és egy új készítése. Mindeközben sűrű miatyánk Mekka irányába..
Amint az új RAID tömb elkészült (immár hiba nélkül) lehetett visszahozni a régi LVM struktúrát, majd nekilendülni az adat visszaállításnak..
És igen.. Mázlim volt.. nettó 40 perc alatt a ~100 GB-os system VG-ről készített dd backup visszatöltődött (yaboot-al együtt), és az LPAR képes volt felbootolni (igaz RC 2ig nem jutott el, de ezen már lehetett segíteni), ergo már csak a tényleges applikációs adatok visszatöltése maradt vissza (meglepő módon azok visszatöltése közben nem nagyon akadt probléma)

Tapasztalatok a jövőre nézve:
- Ha tényleg über fontos adatról/alkalmazásról beszélünk, akkor erőltessük már meg magunkat, és a környezetet tényleg redundánsan alakítsuk már ki
- A RAID 5 addig jó, amíg kevés diszk van alatta. A tömb növekedésével együtt növekszik a teljes tömb meghalásának esélye is (mivel nagyobb az esélye, hogy 1 időn belül 2 aktív diszk hal ki, ahogy itt is történt (nagy eséllyel a használt diszkek ugyan abból a sorozatból valóak, ergo közel ugyan annyi idő alatt is halnak meg))
- Disaster recovery plan még akkor se árt ha van, ha amúgy a rendszer nem indokolja azt meg. A probléma a jelen setuppal az, hogy nem nagyon lehet rá 100%-os plan-t készíteni (ami effektíven használható lenne), a bootolható backup hiánya miatt (személyes véleményem szerint SLES pSeries-re nem való)
- Nagykönyv lehet, hogy létezik, de inkább tekintsünk rá amolyan "Kalóz Kódexként" ami inkább csak útmutatás, mintsem sérthetetlen szabály.. Valami úgy is valamikor el fog romlani, amire persze hogy nem leszünk felkészülve
- A szokásos halandzsa - update, update, update. Tudom, hogy az überfontos applikáció überfontos uptime-al kell üzemeljen, de kalkuláljunk már maintenance window-t is a rendszerhez, hogy az ilyen hülye önszopatásoktól megkíméljük magunkat.
- Murphy sose alszik, és mindig pörgős zenét hallgat :)

NFS mount rejtelmek

Mai nap esett meg velem a következő: Mountolni akartam egy távoli NFS-en keresztül kiosztott FS-t, de Murphy épp nevetős kedvében volt és az alábbi üzenettel örvendeztetett meg:

client # mount server:/export /mnt
nfsmnthelp: 1831-019 9.149.40.8: System call error number -1.

mount: 1831-008 giving up on:
server:/export
System call error number -1.

Hát jó.. akkor induljunk neki a szokásos problem determinationnek:
- Az NFS mountolás során első körben az alábbi dolgok történnek (a teljesség igénye nélkül):
A kliens lekéri az NFS szerver IP címét (mivel ugye nem IP-vel akartunk csatlakozni) a géptől. Ennek pontos módja ugye a /etc/netsvc.conf-ban, illetve a /etc/resolv.conf-ban van tárolva.
Ha sikerül neki feloldani az IP címet, akkor megpróbál a távoli géppel egy standard RPC kommunikációt kiépíteni (port 111), majd az adott erőforráshoz (amit én hülye mountolni akarok) hozzáférni. Ezt persze vagy hagyja a szerver vagy sem. Ettől függetlenül azért ez nem egy lépéses játék -> csak az előbb felsorolt dolgokat 3 főbb pontra bontanám:
- IP feloldás
- RPC kommunikáció
- Resource hozzáférés (ide kapcsolnám az authentikációt is)

Persze ezek mellett még van jó pár dolog, de most így első körben azokkal nem törődök.. Nézzük át, hogy a fenti folyamatokhoz szükséges beállítások hogy is vannak:
- Nézzük meg, hogy a /etc/netsvc.conf hogy is próbálkozik a név feloldással:

client # grep -v ^# /etc/netsvc.conf
hosts = local,bind4
server # grep -v ^# /etc/netsvc.conf
hosts = local,bind4

Aham.. szóval ez jónak tűnik. Mind a szerver, mind a kliens a /etc/hosts-ot nézi első körben (local), majd megy a bind felé (IPv4en), ahogy az szerver esetén várható is.
Akkor nézzük tovább. van e bármiféle IP feloldás

client # host server
server is 192.168.1.10
server # host client
client is 10.1.0.20

A host szerint van (ne feledjük el, hogy a host parancs a /etc/netsvc.conf szabályain keresztül nézi ki az IP-t, ahogy azt általában az alkalmazások is teszik). Tekintve, hogy az alkalmazásoknak amúgy is a local felé kell fordulniuk 1x, így ezeket az IP-ket kénytelenek leszünk elfogadni (persze azért nem árt ellenőrizni, hogy a 2 IP valós e - ergo, hogy nincs e elszúrva a /etc/hosts-unk)

Akkor ezek után nézzük meg, hogy a standard hálózat él e mondjuk (sima ICMP, de a teszt erejéig jó lesz)

client # ping -c1 server
PING server (192.168.1.10) 56(84) bytes of data.
64 bytes from server (192.168.1.10): icmp_seq=1 ttl=243 time=75.6 ms

--- server ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 75.690/75.690/75.690/0.000 ms

server # ping -c1 client
PING client (10.1.0.20) 56(84) bytes of data.
64 bytes from client (10.1.0.20): icmp_seq=1 ttl=243 time=75.6 ms

--- client ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 75.690/75.690/75.690/0.000 ms

Az ICMP csomagok szépen átmennek, ergo a 2 gép eléri egymást.
# Note - jelen esetben a 2 gép 2 külön hálón van, viszont rálátnak egymás hálózataira, így ennek nem szabadna hibának lennie.

Persze lehet hogy van még tűzfal a 2 között, így nem árt ellenőrizni azt se, hogy a kliens rálát e a szerverre, és annak szolgáltatásaira:

client # showmount -e 192.168.1.10
Export list for 192.168.1.10:
/export (everyone)
client # rpcinfo -p 192.168.1.10
program vers proto port service
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
200006 1 udp 2049
200006 4 udp 2049
200006 1 tcp 2049
200006 4 tcp 2049
100024 1 tcp 37470 status
100024 1 udp 50261 status
100133 1 tcp 37470
100133 1 udp 50261
200001 1 tcp 37470
200001 1 udp 50261
200001 2 tcp 37470
200001 2 udp 50261
100021 1 udp 50344 nlockmgr
100021 2 udp 50344 nlockmgr
100021 3 udp 50344 nlockmgr
100021 4 udp 50344 nlockmgr
100021 1 tcp 37472 nlockmgr
100021 2 tcp 37472 nlockmgr
100021 3 tcp 37472 nlockmgr
100021 4 tcp 37472 nlockmgr
100005 1 tcp 37711 mountd
100005 2 tcp 37711 mountd
100005 3 tcp 37711 mountd
100005 1 udp 50432 mountd
100005 2 udp 50432 mountd
100005 3 udp 50432 mountd
400005 1 udp 50433

Ez alapján én azt mondanám, hogy gyönyörűen látja a kliens amit kell. Ráadásul a showmount kimenetéből láthatjuk azt is, hogy az adott megosztás mindenki számára elérhetőnek kéne lennie.. Ezt azért ha lehet nem árt tényleg leellenőrizni is:

server # lsnfsexp
/export -rw

Ez alapján tényleg azt mondom, hogy ennek így jónak kéne lennie. (ha ezek közül valami nem megy, akkor nyomban gyanakodhatunk firewall/routing, vagy valami network típusú hibára )

2. lépésben szoktam nézni a rendszer (jelen esetben AIX) specifikus függőségeket.
Az egyik ilyen alap függőség, hogy az adott mappa (ahova mountolni akarunk) létezik e (tudom triviális, még is sokszor megszivatja az embert ,ha figyelmetlen):

server # ls -ld /mnt
drwxrwxrwx 229 root system 20480 07 Jun 13:05 /mnt

Persze általában ezt nem nézzük ennyire be, így a következő amire figyelni kell az az NFS beállítások mind a kliens, mind a szerver oldalon. Ezek közül is 2 van, ami az authentikációért felelhet (az NFS szabályokon felül) olyan módon, hogy kötötté teszik a standard portok használatát:

client # nfso -a |grep port
nfs_use_reserved_ports = 0
portcheck = 0
server # nfso -a |grep port
nfs_use_reserved_ports = 0
portcheck = 0

Általában illik a szerver és a kliens oldalnak ezen beállításokban egyezniük, mert ha nem az simán okozhat ilyesmi hibát. Sajna azonban itt nem ez a helyzet.
Ha ezek után se szokott menni, akkor szoktam azt a randa játékot játszani, hogy azt hiszem, hogy nem én, hanem az NFS szerver a hülye, így simán megpróbálom törölni, majd újra létrehozni az NFS megosztást ( tudom, Windows-os beütés, de néha működik)

server # smitty rmnfsexp
server # smitty mknfsexp

A probléma ott van, hogy nálam ezek után se működött a dolog, így végső kétségbeesésként megpróbálkoztam egy teljes NFS restartal :) - ki tudja, hátha beragadt valami:

server # stopsrc -g nfs
server # stopsrc -s portmap
server # rm -rf /etc/state /etc/rmtab /etc/xtab
server # startsrc -s portmap
server # startsrc -g nfs
server # exportfs -a

A gáz onnan indult, hogy még ezek után se ment a játék.. Más kliensek gond nélkül fel tudták csatolni a megosztást, de ez az 1 makacsul nem engedett.
Ekkor döntöttem el, hogy akkor nézzük meg mélyebbről is a játékost - tracelgessünk kicsit:

client # startsrc -s iptrace -a "-a -b /tmp/iptrace.bin"
client # mount 192.168.1.10:/export /mnt
client # stopsrc -s iptrace
client # ipreport -rnvs /tmp/iptrace.bin > /tmp/iptrace.bin.out

A problémám ott kezdődött, amikor konstatálnom kellett, hogy az egyetlen gyengécske nyom kb ennyiben nyilvánult meg:

Packet Number 260
ETH: ====( 86 bytes received on interface en0 )==== 13:12:00.036155006
ETH: [ 00:0f:90:aa:ea:ff -> 00:02:55:33:ec:e5 ] type 800 (IP)
IP: < SRC = 192.168.1.10 > (server)
IP: < DST = 10.1.0.20 > (client)
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=72, ip_id=17465, ip_off=0
IP: ip_ttl=57, ip_sum=f220, ip_p = 6 (TCP)
TCP:
TCP: th_seq=3365614187, th_ack=44423836
TCP: th_off=5, flags
TCP: th_win=65535, th_sum=5ee7, th_urp=0
RPC: Record Marker: Size = 28, Last Fragment (0x8000001c)
RPC: **REPLY** XID=1310050721
RPC: 100005(MOUNTPROG) 1(MOUNTPROC3_MNT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS
MNT: Status=Protocol Error, Bad mnt_stats (-1)

Fejvakarás, töprengés... Wattafák... Vissza az alapokhoz..
Az stimt, hogy a kapcsolat kialakításához kell egy IP kapcsolat (ami megy is az előző lekérések alapján), viszont belegondolva van az NFS-nek egy olyan funkciója, hogy "reverse name lookup". Ez a funkció elvileg arra hivatott, hogy garantálja, hogy a kliens a szerverrel, illetve a szerver a kliensel beszél az által, hogy a kapcsolat felépítésekkor leelenőrzi azt, hogy a kiépülendő kapcsoalat valóban a 2 fél között jönne e létre.
Ezt valahogy úgy próbálja megcsinálni, hogy:
- A kliens valahogy feloldja a szerver IP címét, majd erre megpróbál csatalakozni
- A kapcsolat során elküldi azt, hogy ő kicsoda, illetve mi is az IP címe
- A szerver reigsztrálja a kérést, majd megnézi, hogy a kliens az ő névfeloldása alapján valóban az e, akinek állítja magát (ergo csinál vissza fele is egy névfeloldást)
- Amennyiben a feloldott IP egyezik azzal, ahonnét jött a kapcsolat akkor megy tovább a kapcsolat kiépítésével
- Természetesen a kliens is eljátsza ugyan ezt (hiszen RPC kommunikációról beszélünk), és ha már ott jár, akkor a szervertől kapott azonosítóval megnézni, hogy valóban jó géppel akar e autholni

Ez security oldalról tényleg értelmes dolog.. Hiába van egy világnak megosztott NFS megosztásom, attól még nem akarom, hogy ezt valaki kihasználva bármi csúnyaságot csináljon. Szerver esetében ugye átalában a netsvc.conf alatt a local az elsődleges rule, így ez miatt erősen ajánlott, hogy mind a kliens, mind a szerver tudjon a másik pontos címéről a /etc/hosts alatt.

A probléma az, hogy ugye ezt ellenőriztük fentebb.. Őőő.. vagyis nem teljesen.. Mint mondtam a vissza azonosítás oda vissza irányul -> Kell az is, hogy a gép önmagáról is "hiteles" adatot küldjön.. És itt volt a kutya elásva: A szerver oldalon a 'server' más IP címmel volt felvéve a /etc/hosts alatt (az ok egyszerű: A 'server' alapból egy másik alhálózatért felel, és azokat a kapcsolatokat meg csak ezen keresztül érheti el).

Ez miatt viszont az egész reverse name lookup meghiusul, mi meg nézhetjük a földön gyülekező hajtömegetet és a ráncokat a tükörbe..
A megoldás ezek után adná magát: Írjuk át a szervernél a /etc/hosts-ban a 'server' IP címét.. A probléma az, hogy ebben a környezetben, ahol a szerver másik alhálóért is felel (vagy inkább azt tekinti elsődlegesnek) ezt nem teheti meg az ember, mert a végén másik kliensel szúr ki.

Akkor viszont marad a másik útvonal: Ki kéne kapcsolni ezt a biztonsági funkciót.. A kérdés csak, hogy hogyan.

Nos.. a vicc a következő: A mountolás ezen fázisában ezért a funkcióért az rpc.mountd felel a szerver oldalon.. Ennek meg a vicc kedvéért van egy nem nagyon dokumentált kapcsolója, amit az ODM alá felvéve gyönyörűen lehet semlegesíteni ezt a működést. Az átállítás módja kb így néz ki:

server # stopsrc -s rpc.mountd
server # chssys -s rpc.mountd -a "-x"
server # startsrc -s rpc.mountd

Ez után, akkor próbálkozunk újra:

client # mount server:/export /mnt
client # mount |grep mnt
server /export /mnt nfs3 12 Jul 08:59

Öröm és bóduttá...

XIV_ID-k és XIV_LUNID-k

Te hogy kérdezed le egy XiV-ról kapott LUN ID-ját, illetve, hogy melyik XiV-ról is jön az adott LUN?
Nos.. Az alapvető válasz egyszerű: A HAK csomagon belül elérhető az xiv_devlist parancs, amit megfelelően felparaméterezve ('xiv_devlist -o all', vagy 'xiv_devlist -v') kidobja nekünk az összes XIV-hez csatolt LUN információját, abból meg kedvünk szerint szűrhetünk grep-el, awk-al, akármivel.. Nincs is ezzel baj.. Na jó... egy kicsi még is - ez a módszer iszonyat de lassú (de legalább színes),főleg ha scripteléshez is szeretnénk valamely adatot használni, arról ne is beszéljünk mi van akkor, ha sok diszkünk van az XiV-hez csatolva (lassú == csiga)
Úgy hogy kicsit elkezdtem turni, hogy hogy is lehetne ezt sokkal gyorsabban megvalósítani.. Nos.. VAN MEGOLDÁS.. Bár jól eldugták..
Az utat ahogy eddig eljutottam nem írom le (legyen elég annyi, hogy szívatós, főleg ha rászámolom, hogy a nyomozás egyik szakaszában a teljes rootvg-t végiggreppeltem az adott string után kutatva :)), úgy is inkább az eredmény érdekli az embereket..
Akkor lássuk hát:
Alapjáraton megszoktam, hogy mind SDD,SDDPCM,MPIO drivereknél az adott LUN ID-ja kinyerhető az ODM-ből.. Erre szolgál ugyan is az unique_id attributum (odmget-el, vagy lsattr-al lekérhető). XiV-s diszknél (hiába támaszkodik félig meddig az MPIO-ra) ez mintha mégse lenne így meg (az elején legalább is nagyon nem így tünt). De nézzük meg közelebbről ezt a stringet..

# odmget -q "name=hdisk10 and attribute=unique_id" CuAt |awk -F "=" '/value/{print $2}'
"261120017380005660F32072810XIV03IBMfcp"

Annyit tudtam alapjáraton is, hogy a LUN-om a 6001382-ös XiV-ről jön, illetve hogy a LUN ID-ja 3890:

# xiv_devlist |grep -w hdisk10
/dev/hdisk10 34.4GB 18/18 Vol1 3890 6001382 test_server

Az adott ODM attributumban persze semmi hasonló nincs.. Egészen addig amíg az ember el nem kezdi boncolgatni.. Mint kiderült: Ott van az.. Csak nézzük kicsit másként azt a stringet:
261120017380005660F32072810XIV03IBMfcp
Na akkor mit is bányászhatunk ki:
0566 - Ez az XiV boxunk azonosítójának utolsó 4 jegye (jelen esetben) hexában tárolva -> 1382
0F32 - Ez pedig a LUNID-nk szintén hexában tárolva -> 3890
/* Azt majd még meg kéne nézni, hogy a 0-ák a string elején mennyire konstansak, de jelen esetben nálam erre nem volt szükség */
Ergo akkor némi kis scripteléssek ki lehet szedni az aktuális azonosítókat, immár kifejezetten gyorsabban:

#!/usr/bin/ksh
DISK=hdisk10
UNIQUE_ID=$(odmget -q "name=$DISK and attribute=unique_id" CuAt |awk -F "=" '/value/{print $2}')
XIV_ID=$(echo "600$(echo "ibase=16; $(echo $UNIQUE_ID|cut -c 15-18)"|bc)")
XIV_LUNID=$(echo "ibase=16; $(echo $UNIQUE_ID|cut -c 19-22)"|bc)

#Edit:
Az ODM entry-ben lévő '2810XIV' utal arra, hogy XiV-s LUN-ról van szó. Ugyan ez DS8k box esetében is megtalálható, csak akkor a '2107900'-es stringre kell figyeljünk

Hátlapát...

.. annak a baromnak aki ezt a szerver design-t kitalálta (avagy architect epic fail)
Adott egy Power6os box (p570), amelyen a következő setup-ot alkották meg az "okosok":
- Mivel a gép bírja, így pakoltak bele egy csomó diszket meg 1-2 SAS RAID controllert, mert miért ne.. Fiber Channelt persze minek..
- A gépen létrehoztak 2 VIO szervert, ahogy az a nagy könyvben meg van írva.. Egyedül annyi a gáz, hogy valszeg a nagy könyv első 20 oldala lehet csak meg, mert se a network-ot, se a storage-ot, de még a VIO-kat se csinálták redundánsra!
- Na de akkor minek a VIO - Fogták a 2 VIO szervert, majd 1-1 RAID controllert hozzájuk rendeltek. A gépben lévő megannyi szép nagy vinyókat meg pdiskenként bebaxták egy 1-1 nagyobbacska RAID5 tömbbe
- Ebből következik, hogy mint redundancia olyan nincs, mert a RAID kártyákat nem lehet több LPAR-hoz is hozzárendelni, ergo innentől van 2 külön VIO-nk 2 külön RAID5 tömbbel.. Na de mire kell ez?
- A megoldás egyszerű: Fogták magunkat, létre hoztak egy nagy VG-t a RAID tömbben, majd a VG-n belül létrehozott LV-ket Virtual Diszkként kiosztották az LPAR-oknak, hogy azok boldogan magukévá tehessék az immáron új diszkeket.. A probléma persze csak az, hogy mivel a RAID tömbök VIO-nként egyediek, így véletlenül se tudjuk ugyan azt a kiosztást megcsinálni mind2 VIO-nál, ergo a Virtual diszkek csak az 1ik VIO-n keresztül érhetőek el => A 2 VIO csak külön-külön LPAR-okat tud kiszolgálni!
Problémák ezzel a felállással:
- Nehezen bővíthető: Ha elfogy a RAID5 alól a hely, akkor aztán így járás, mert egy idő után a diszkek is elfogynak
- Mivel RAID5ről beszélünk, így a teljes RAID tömbben csak egy VG van. Ennek annyi előnye van, hogy 1 LPAR gond nélkül el tudja vinni a teljes kapacitást a többi elől, ha ő úgy akarja (és mivel applikáció is fut rajta, így persze, hogy úgy akarja )
- Redundancia mint olyan sehol nincs, sőt nem is nagyon lehet úgy átépíteni a rendszert, hogy legyen (az alapoktól újra kéne építeni).
- A vicc kedvéért az LPAR-okhoz használható NIM szerver ugyan azon boxon belül található, mint az LPAR-ok, így aztán komolyabb HW failure esetén (lehal a box) esélye nincs bárkinek is restore-olni az LPAR-okat..
- MINEK MINDEHHEZ VIO????