Storage bővítés – második rész

Egészen tanulságos feladat végén járok, azt hiszem a mai napon sokat tanultam, és ezt másokkal is érdemes megosztani.
A storage bővítés első, hirtelen félbeszakadt történetét már elmeséltem. Már akkor látszott, hogy a feladat befejezésére legkorábban augusztus végén kerülhet sor, ez van épp most. Péntek délután a megbeszélteknek megfelelően megjelentek a szállító munkatársai, elhozták az EXP700-as sorozatú fiókokat, villámgyorsan kicserélték az EXP710-eseket, és az adattároló lekapcsolása után csont nélkül beillesztették és felélesztették az új, immár kibővített rendszert. Elkezdtük létrehozni a RAID tömböket és a logikai lemezeket, ezzel pedig a fiúk feladata befejeződött. (Később volt még némi riadalom, mert az egyik HBA adapter nem akart elindulni az új szerverünkben, de aztán egy kiveszlek-beteszlek-megigazítalak játék segített a probléma elhárításában.)
 
A munkát szombat délelőtt, 9:30-kor folytattuk. A módszer, amelyet kitaláltunk, nem volt új. Már három évvel ezelőtt is, amikor a mostani storage-ot vettük, hasonló technikával mozgattuk át az adatainkat az akkor leselejtezedő merevlemezekről. Dióhéjban a módszer a következő:
  1. Létre kell hozni az új lemezeket, majd a fürt erőforrásaivá kell tenni.
  2. Le kell állítani az SQL, Exchange stb. szolgáltatásokat, amelyek fognák a fájlokat, majd át kell másolni mindent az új meghajtókra.
  3. Meg kell szüntetni a lemezektől való erőforrás függőségeket.
  4. Még leállított állapotban meg kell szüntetni mind a régi, mind az új lemezerőforrásokat. Restart.
  5. Újraindítás után meghajtó betüjelet kell cserélni az régi és az új lemezek között.
  6. Az újakat fel kell venni ismét lemez erőforrásként és helyre kell állítani az eredeti függőségeket.
  7. El kell indítani a fürtöt és ellenőrizni kell, hogy minden működik-e.

Tényleg csak dióhéjban, mert ugye a lemezeken a betüjelcsere nem egyértelmű fürtök esetén, és ami még inkább izgalmas, a végén el kell távolítani az eredeti lemezeket és újra fel kell használni őket.

Mi jó előre eltervezük, hogy melyik tömböt hogyan hasznosítjuk. Új lemezeket kapott az Exchange adatbázis, az SQL adatbázis és az SQL Index. A régi SQL Indexet odaadtuk az Exchange-nek, hogy a Tranzakciólogokat ott tarthassa, a régi SQL adatbázis lemeztömböt peidg felvágtuk és "adtunk" két-két lemezt az SQL LOG illetve TEMP meghajtójának.

Azt láttuk előre, hogy a másolás viszonylag hosszú lesz. Úgy számoltunk, hogy tíz órától egyig, kettőig is eltarthat, sebaj gondoltuk, addig megismerkedünk a WSUS rejtelmeivel. Amikor elkezdtük a műveletet, és az első percek után megbecsültük a hátralévő időt, már kissé elkedvetlenedtünk. Úgy tűnt, hogy délután négyig is másolni fog a gépünk. Hmm.  Elmentünk hozzánk, kiporoltuk a szőnyegeinket, megebédeltünk, Krisztián kollégámat megkínáltam egy könyvvel és egy kávéval, én pedig nekiálltam lesuvickolni a két napja berakott új műanyag ablakainkat. Közben VPN-en keresztül folyamatosan nézegettük a Windows Intéző kék pöttyöcskéit és úgy találtuk, hogy bár nagyon lassú a másolás, legalább arányos a pöttyök száma az átmásolt adattal. (Bár etekintetben is meg voltunk némileg fogva: a nagy SQL állományokat úgy másolja a Windows, hogy az első másodpercben lefoglalja nekik a területet, majd szépen kitölti őket. Így amikor a lemezterületen 49 GB felhasznált részt láttunk, biztosak lehettünk benne, hogy annál keveebbet másolt még a gép, de csak sejtésünk lehetett, hogy mennyivel.) Egy idő után egybehangzó bólogatással megállapítottuk, hogy a Total Commander másolási ablaka sokkal informatívabb.

 (Néhány érdekes megfigyelést tettünk a másolást jelző "lapdobogató" ablakról. Először is csak akkor írja ki, hogy hány perc van még a másolásból, ha az 240-nél kevesebb. A hátralévő időt másodpercenként becsli méghozzá a performancia adatok alapján. Amint egy kicsit megugrott a sebesség, máris öt perccel kevesebbet mutatott az ablak stb. A húzott kék csík arányos volt és a becsült 240 perc egy-két perces eltéréssel pontosbak bizonyult.)

Délután három körül tértünk vissza, és mivel még mindig sok idő maradt, nekiálltunk a WSUS dokumentáció elolvasásának. Erre most külön nem térek ki, később még lehet róla értekezni bőven. Az olvasgatást este hétig folytattuk, akkora másolt át mindent a Windows Intéző. Egy kis fejszámolás: a lemezalrendszert a mi gépeink 1 Gbit/sec FC csatornán keresztül érik el. Tegyük fel, hogy az elméleti sebesség legfeljebb felét tudjuk kihasználni, ez 512 MBit/Sec vagy 64 MB/sec. Nekünk volt 160 GB-nyi másolnivalónk. Ez esetében ez 163840 MB, amit 64 MB/sec sebesség mellett 2560 másodperc alatt kellett volna teljesíteni. 2560 másodperc az 42,666 perc!!! Hmmm  Mi ezzel szemben végeztünk 8 óra alatt, ez testvérek között 5,68 MB/sec. Itt valami nagyon nem stimmel. Azzal sem lehet védekezni, hogy kicsi állományokat másoltunk volna: 37 GB az elég nagy állomány – szerintem. Na, azt hiszem itt lesz mit keresni. A gyanú kivizsgálását segítendő a másolás végéről készítettem egy performance monitor logot – még akármire jó lehet.

Ha már túlestünk a másoláson, nekiálltunk a lemezek "dobálásának". Az Exchange megkapta "a magáét", az SQL-t pedig rögtön kipróbáltuk közvetlenül az index és az adatbázis lemezeinek betü-csereberéje után. Végül a terveknek megfelelően megszüntettük a korábbi SQL-ADAT RAID tömböt, és a felszabaduló lemezeket felhasználtuk az SQL-LOG és SQL-TEMP bővítésére. Ez a gyakorlatban azt jelentette, hogy meg kellett szüntetni, majd a hozzáadott lemezekkel újra létre kellett hozni a Storage Manager segítségével a LOG és TEMP tömböket.

És ekkor következett a baleset, vagyis inkább a BALESET. Három évvel ezelőtt, amikor a mostani tárolót telepítettük és a tömböket létrehoztuk három egyforma, ugyanolyan nagyságú, ugyanúgy konfiguralált arrayt alkottunk, az SQL-LOG-ot, az SQL-TEMP-et és a LOGIC-ot. Ez utóbbira telepítettük a J.D. Edwarsd ERP rendszer programfájljait – sőt. a lemezcserebere alatt ide tettük a cluster quorumot is. Nos, mint utóbb kiderült, a Storage manager kezelőfelületén a Windows 2000 lemezkezelőhöz képest másképp címkéztük a logikai lemezeket (illetve a Windows 2000-ben a fizikai lemezeket). A storage-ből kitörölt SQL-LOG és SQL-TEMP valójában a Windows SQL-LOG és LOGIC lemezeit pusztította el.

Az állapot a "Delete…" elengedése után: Nincs quorum, nincs fürt, nincs LOGIC lemez, nincs JDE rendszer. A Quorum és a lemezcsereberéről nincs SYSTEM STATE mentés. Enyhén szólva is siralmas, még az sem vígasztalt minket, hogy elvileg egy napunk van még a hétvégéből.

Utolsó mentsvár: a TSM mentés. Korábban már szoftveroszkárt adtam neki, bíztam benne, hogy kihúz minket a csávából. Az első zökkenő a romeltakarításból akkor jött el, amikor kiderült, a LOGIC partíción volt az a dsm.opt állomány is, amely a JDE virtuális szerverünk metését szabályozta. No sebaj: elővettünk egy másik dsm.opt-ot, és mivel az egy TXT állomány, egyszerűen átírtuk a NODENAME paramétert. Rendben. Beléptünk a TSM klienssel… az pedig úgy látta, hogy erről a szerverről NEM készült mentés.

Hideg verejték…

Ez nem lehet igaz!! Megnéztük a TSM szerver oldaláról: 17 GB fityegett kétszer a szalagokon. Ha így van, akkor elő is csaljuk, biztosan a TSM jelszóval volt. Tényleg! Beléptünk "rendesen" a TSM-be és lám, ott volt a LOGIC előző napi mentése. Restore…

A 100 000 fájlból még csak 2400-nál járt a helyreállítás, amikor egyszerre csak vége szakadt. Előszört azt gondoltuk, hogy végzett, és ismét csak elfehéredtünk, amikor kiderült, hogy indíthatatlan a rendszerünk.  Ismét a TSM szerverhez fordulva láttuk, hogy az egyik tape drive produkált I/O hibát. Restart restore…

Amíg az szétesett cluster egyik node-ján a helyreállítással küzdöttünk, a másik node-on a clustert magát próbáltuk életre lehelni. Őszintén szólva nem aggódtam. Tudtam, hogy a quorum legfrissebb, vagy majdnem legfrissebb másodpéldánya minden node-on is megtalálható, így biztosan van egy olyan cluster indítási mód, amely a másodpéldány alapján indul. Volti is ilyen, a

net start clussvc /ResetQuorumLog

pontosan ezt csinálja. Csakhogy ez esetben a kapcsoló nem működött. Azt feltételezi ugyanis, hogy a quorum diszk jó, csak a quorum log sérült meg. Nálunk viszont még a lemez sem volt elérhető (Ilyenkor, ugye, nem a a betüjel számít, hanem a lemez szignatúrája alapján keres a fürt, vagyis hogy volt egy J: meghajtónk, az őt nem hatotta meg.) Ezért aztán egy másik kapcsolóhoz nyúltunk:

net start clussvc /fixquorum

Ez már jobb eredményt adott. Ettől a kapcsolótól "indult be" a helyi másolata a quorumnak. Annyit tettünk, hogy az adatbázis szerinti Quorum helyet megváltoztattuk egy létező lemezre.  A szolgáltatás le- majd felkapcsolása után, lám, újra lett fürtünk

Most már csak a másik node indítására volt szükség, néhány faliover teszt és indult a rendszer. És tényleg elindult. Még hajnali fél négy sem volt, és már mentünk is haza…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: