Mai "sikersztori" - HA rendszerű NIM szerverünk upgrade-je után a NIM alatt lévő node-ok néha nem voltak elérhetőek (random).. Kb az alábbi probléma jelentkezett az összesen:
Ergo néha ment a kapcsolat, néha nem (most tekintsünk el attól, hogy rsh-t használok a teszthez, ssh-nál ugyan ez volt a gebax)
Sajnos a pontos megoldást a környezet ismertetése nélkül nem közölhetem. Annyit tudok elmondani, hogy az összes feltétel adott a kommunikáció kiépüléséhez, és se a truss-al gyűjtött adatok, se az iptrace nem szolgál bizonyítékul a hiba forrását illetően.
Viszont egy szimpla kis tippet azért adnék annak, aki egy ilyen hibába fut bele: Tessék megnézni a routingot!! Főleg ha azonos rooting bejegyzések vannak azonos hálóra/hostra különböző adaptereken (és különböző IP-n), ami HA-nál könnyen megeshet :)
Úgy nézem ez a Július tele lesz finomságokkal..
Mai nap például pont ez jött szembe:
server # errpt |head
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
16F35C72 0714150111 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714150111 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714145911 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714145911 P H hdisk1 DISK OPERATION ERROR
Ohh, hát ezt ismerjük... Nézzük használjuk e:
server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c psvg1 active
Használjuk.. szupi.. Akkor nézzük a szokásos mókát: Lebontom a tükröt, kiveszem a diszket a VG alól, aztán majd valamikor cseréljük a diszket.. De ehhez persze tudnom kell, hogy a tükör ép e.. Hát nézzük:
server # lsvg -p psvg1
0516-062 : Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
őőő.. állj.. ez így már nem vicces..
server # lspv |grep -w psvg1
hdisk1 0050db3a8c87dd2c psvg1 active
Ja hogy nincs tükör??? Extra mód nem vicces.. Nézzük mi volt alatta, ha ne adj isten restore-olni kéne:
Ohh.. mázli.. szal csak egy paging.. Szívroham el, de attól még él a probléma.. Nézzük akkor hogy is állunk:
server # lslv paging00
LOGICAL VOLUME: paging00 VOLUME GROUP: psvg1
LV IDENTIFIER: 0050db3a00004c00000000fc2d691d85.1 PERMISSION: ?
VG STATE: active/complete LV STATE: ?
TYPE: paging WRITE VERIFY: ?
MAX LPs: ? PP SIZE: ?
COPIES: ? SCHED POLICY: ?
LPs: ? PPs: ?
STALE PPs: ? BB POLICY: ?
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: center UPPER BOUND: 32
MOUNT POINT: N/A LABEL: None
MIRROR WRITE CONSISTENCY: ?
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: ?
server # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging01 hdisk2 psvg2 17344MB 1 yes yes lv
0516-062 : Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
hd6 hdisk0 rootvg 3072MB 1 yes yes lv
Na erre szoktam mondani, hogy annyira nem biztató.. Na mind1.. tudjuk az LV (innentől fogva a Paging nevét) nevét, szedjük le róla a paginget..
server # chps -a n paging00 server # rmps paging00
0517-062 rmps: Paging space paging00 is active.
0517-061 rmps: Cannot remove paging space paging00.
server # swapoff /dev/paging00 server # rmps paging00
0516-062 lqueryvg: Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
0516-912 rmlv: Unable to remove logical volume paging00.
0517-061 rmps: Cannot remove paging space paging00.
Ilyenkor jön az, hogy elevenítsük fel az "I love to say fuck" c. számot, mert bizony ez kibaxás...
Na mind1.. Ha nincs más, akkor csak az előre: Elő a hegesztő pákát, és hegesszük ki a rendszer alól az LV-t:
server # varyoffvg psvg1
0516-062 lqueryvg: Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
Na most akkor ment, vagy nem ment?
server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c psvg1
Hoppá!! Nem aktív.. Fény az alagút végén :))
server # exportvg psvg1 server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c None
Szuper :) Akkor nézzük a paginget is :
server # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging01 hdisk2 psvg2 17344MB 1 yes yes lv
hd6 hdisk0 rootvg 3072MB 1 yes yes lv
Éljen a magyar :)) Megy minden szépen tovább :) No outage, no issue :))
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:
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:
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:
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
