A gépek leállításáról és újraindításáról

Adott három gép: 'gep1', 'gep2' és 'gep3'. Ezeken HP-UX 11i v2 az operációs rendszer. 'gep1' és 'gep2' clustert alkot, melyen SAP fut. 'gep3' a fejlesztői rendszer.
Felmerült az igény arra, hogy az SAP által használt

/usr/sap/trans

könyvtár a fejlesztői gépen is elérhető legyen. Ezokból a rendszergazda felvette az SAP-t futtató 'gep1'-en az

/exports/usr/sap/trans/

könyvtárat az

/etc/exports

file-ba, az

exportfs

parancsot kiadva kiajánlotta azt, majd mountolta a fejlesztői gépen. Hol itt a probléma?

Szóló gép esetén sehol, de mint azt fent említettem, itt egy clusterről beszélünk. Egy HA cluster esetén az alkalmazások bármelyik kijelölt node-on futhatnak, ezért a környezetüket is ennek megfelelően kell konfigurálni. Így van ez az SAP által használt NFS share-ekkel is, melyeket nem a szokott helyükön, hanem a csomag indító scriptjeiben kell beállítani.

------
Megszakítjuk műsorunkat!!!
A HP-UX rendszereken használt MC/ServiceGuard software egy magas rendelkezésre állású, HA clustert valósít meg. Az alkalmazások és a környezetük (filerendszerek, IP cím(ek), maga az alkalmazás plusz egyéb erőforrások) úgynevezett csomagot alkotnak. Egy csomag egyszerre egy gépen futhat (kivétel az Oracle RAC) de a clusterben természetesen több csomag is használható és egy gép is futtathat több csomagot egyszerre, ha azok egyébként nem akadályozzák egymást.
Köszönöm a figyelmet!
------

A fentiekkel nem is volt semmi probléma, amíg a node-okat, köztük a 'gep1'-et újra nem kellett indítani. Újraindításkor az OS az

/etc/exports

alapján ugyan kiajánlotta a beállított könyvtárakat, de azok akkor még nem voltak jelen a rendszerben, mivel azokat az SAP-t futtató csomag aktiválta. Mely csomag aktiválta a benne beállított NFS share-ek kiajánlását is, minden más korábbi beállítást felülbírálva. (megjegyzem, esetünkben ez az elvárt működés)
Ugyan megúszták, de hasonló problémát vetett volna fel, ha a 'gep1' elromlik és a 'gep2' veszi át a munkáját. Ugyanis a 'gép2' semmit nem tudott a fejlesztői gépnek szánt NFS share-ről.

A hibás NFS beállítás és a gépek újraindítása között hónapok teltek el. Aztán egy egyéb okból elvégzett újraindítást követően nem működött az addig jó megosztás és a gyanú rögtön az újraindítás okára terelődött. Miután kiderítettem a valódi okát a problémának és kijavítottam az NFS kiajánlást, újraindítást kértem az SAP-t futtató csomagra, mivel nem akartam elkövetni ugyanazt a hibát, amit az NFS-t konfiguráló ember, jelesen hogy nem ellenőrzöm a csomagindító scripteket. Optimális persze a teljes cluster újraindítása lett volna, de már a csomag újraindítása is megnyugtató eredményt adott.

Tanulságok:
- ismerjük a gondjainkra bízott rendszert
- ne végezzünk ad-hoc módosításokat éles rendszeren
- a konfiguráció módosítása után végezzünk olyan szintű újraindítást, amilyen szinten a módosítást végeztük. Csomag módosítása esetén elég a csomagot újraindítani, serverszintű módosítás esetén az adott servert, cluster szintű módosítás esetén a clustert alkotó összes servert.
- havonta egyszer egy "tervszerű megelőző karbantartás (TMK)" keretében ellenőrizzük le, hogy a környezetünk egy nem tervezett leállást követően is képes önmagától munkába állni.
- hasonlóképp ellenőrizzük, hogy a csomagok minden számukra beállított node-on képesek futni. Akár önállóan, akár más csomagokkal egyszerre.