Egy hardver hiba tanulságai.

Avagy bénázásunk története.

Történt ugyanis, hogy hardver hiba miatt összeomlott egy x345 -os 2 rack unit magas szerverünk. A szerveren Windows 2003, fut, és SAN-on keresztül felcsatolva egy 500Gb-os meghajtó.

Nem tudom ki menyire ismerős a Lotus Domino világában akár kliens akár szerver vonatkozásban ?
Én kliens oldalon jobban képben vagyok mint a szerver oldalon. Elég annyit tudni, hogy a könyvtár struktúrája úgy néz ki, hogy vannak a bináris programok, és annak a könyvtára ez windows -on általában “C:\Program Files\Lotus\Domino” ha szerver,  “C:\Program Files\Lotus\Notes” ha kliensről beszélünk. Illetve van egy úgynevezett data könyvtár amit mindegy, hogy hogy nevezünk a lényeg, hogy az előbb említett bináris könyvtárban lévő notes.ini file -ban meg kell adni a notesdata könyvtár teljes elérési útját. Ebben a data könyvtárban tárolja az adatbázisokat, mailboxokat a program.

A szerver olyan szinten omlott össze, hogy a be sem boot-olt. Szerencsére volt egy konfigurációra teljesen ugyan olyan másik x345-ös szerverünk is. Ebből lett volna később egy Lotus Domino kluszter. RAM, Proceszor, Wincheszter minden ugyan olyan, és akkora volt mint az összeomlott gépben. Természetesen nem kell teljesen ugyan olyan legyen, ahhoz hogy klasztert építsünk, de fontosnak tartottam megjegyezni, mert ez fontos információval bír a későbbiekben.

Ismét csak szerencsére, SAN disk-en volt a domino-nak a data könyvtára, így adatvesztés nem lehet , persze ha lokális vinyón lett volna akkor is csak ki kellet volna szerelni, és betenni a másik szerverbe. De a notesdata könyvtár még külön TSM-el is mentve volt, igaz ez nem file szinten, hanem a TSM-nek a TDP (Tivoli Data Protection)-el.  A bináris állományok, illetve a windows teljes könyvtára, tehát a teljes C  meghajtó a Symantec Livestate Recovery termékével volt mentve. Erről esetleg még írok egyszer egy rövid kis bemutató blog-ot.

Tehát fogtuk a régi szerverből a SAN kártyát és beletettük az új szerverbe, hogy ne keljen újra zónázni a SAN switch-et. Most térült meg hogy alias-okat adtunk a SAN zona-hoz, mivel a másik szerver egy másik épület másik SAN switch-éhez kapcsolódik. Így elkerültük hogy a SAN-hoz hozzá kelljen nyúlni.

Murphy törvényét igazolva mindez éjjel 1 kor kezdődőt.

Történt ugyanis, hogy a kollégám aki állította vissza a Symantec  Livestate Recovery-vel a meghajtókat, nem tudta, illetve nem vette észre, hogy ahova vissza állít az igazából a SAN-os meghajt, és annak rendje és módja szerint szépen felülírta azt. Itt jegyezném meg, hogy valószínűleg a Symantec bootcd összekeverte a meghajtókat, és nem a kollégám hibázott. Azért ennek a lépésnek is van két tanulsága:

1. Már boot-olás közben is van SAN, hiszen van aki úgy használja, hogy arra telepíti az OP rendszert, és az csak úgy megy ha tényleg látszik már bootolás közben is.
2. Legközelebb ha ilyet csinálunk akkor kihúzzuk a SAN kártya portjait, hogy még véletlenül se fordulhasson ez elő még egyszer.

Tehát az adatok a SAN-os meghajtóról eltűntek. Semmi gond van TSM mentés ! Körülbelül egy ~280Gb adatott kellet vissza állítani hálózaton keresztül, mindezt úgy, hogy a TSM szerver közben csinálta a többi szerveröl a biztonsági mentést. Ez az adatmenyiség amíg átjött hálózaton eltelt ~6 óra. Már rég rendes munkaidőben voltunk, úgyhogy a hibát nem sikerült úgy visszaállítani, hogy az ügyfeleket ne érintse, sőt arra a napra nem is volt elérhető a szolgáltatás.

Vissza állítottuk a TSM TDP-vel az adatbázisokat, és a mailboxokat. És ekkor jött a következő csapás, mármint számunkra, (Ez a Murphy tudhat valamit), Ugyanis nem sikerült a log-okat is visszaállítani, mert a TDP közölte, hogy ez egy másik szerver, és hogy ezt így nem lehet. Pedig mint említettem minden ugyanaz volt a hardver, a host név, a TSM-hez a “node” név, szóval elvileg minden ugyanaz. Vagy ha már az adatbázisokat visszahozta “szó nélkül” akkor a logokat miért nem ?

Itt azoknak akik nincsenek képben a a Domino-val , mint például én is, azoknak elárulom, hogy itt nem sima logokról van szó hanem tranzakciós logokról. Elvileg ezeknek a logoknak a segítségével vissza tudnánk állni bármelyik előbbi pillanatára egy adatbázisban vagy egy mailboxban.

A mentési stratégia úgy volt megtervezve, hogy hétvégenként csinált a TDP egy fullos mentést ami azt jelentette, hogy a teljes adatbázisokat lementette, és a hétközben pedig a tranzakciós logokat mentetette minden változáskor. Tehát ebben az állapotban a fullos mentést tudtuk vissza hozni és az azóta kezelt adatokat pedig elveszni látszottak. Ez természetesen a management-ünknek elfogadhatatlan volt, megjegyzem szerencsére. Megoldás számunkra az maradt, hogy a régi gépet működő képes állapotba hozzuk , és azon állítjuk vissza a TDP segítségével az adatokat. Nem volt egyszerű és főleg elég idő igényes, de végtére is ez volt a jobb megoldás, és így már nem kellet attól tartsunk, hogy “ez egy másik gép” , és nem is emlegette többet fel nekünk a TDP.

ÉS LÁSS CSODÁT  SIKERÜLT.

Másik tanulsága dolognak az, hogy nem kellet volna olyan hamar keresztet vetnünk a “régi, rossz” gépre, valószínűleg úgy 24 órával hamarabb készen lettünk volna, de mentségünkre szóljon, hogy ha nem “törlődőt” volna le a SAN-ról az adat akkor meg az egész pár órát tartott volna.

Ha jobban megnézitek akkor láthatjátok, hogy szó volt itt Windows-ról , Symantec-ről, Lotus Domino-ról, SAN-ról, TSM-ről, és ezekből nekema SAN-hoz és a TSM-hez van közöm, úgy munka szempontjából, mint tudás szempontjából. Azért írtam ezt meg, mert hátha sikerül valakinek egy hasonló esetben elkerülni a mi baklövéseinket.

Hát így telt nálunk a cégnél Augusztus 20-ika.