Tétova cluster

Exchange 2007 CCR cluster Windows 2008 NFSM cluster alapokon… izgalmas dolgok ezek. Nyilván össze is dobtam egy tesztrendszert, hogy nézegessem, simogassam, babusgassam. Na meg időnként agyon is vágjam.
A cluster, mint egy hiperaktív kisbaba, szépen felállt minden fejberúgás után, működött rendesen. Ide-oda terelgettem az aktív node-ot, tette a dolgát. (Már ahogy.)

Aztán eltelt egy hét, úgy, hogy nem nyúltam hozzá. Volt dolgom épp elég, máshol.

A hosszú álldogálás után újra beléptem, barátságosan hátbaszúrtam az aktív node-ot, figyeltem a failovert… mely nem következett be. Közölte, hogy az egyik Storage Group nem állt vissza online-ba, tehát a virtuális szervernek is Sándor. Néztem, mint Rozi a moziban. Oké, failback. Az működött.
Eljátszottam néhányszor ezt a failover/failback testcselt, de az eredmény mindig ugyanaz volt. Remek. Még jó, hogy a tesztrendszeren jött elő. Meg hát az amerikaiak úgyis azon aggódtak, hogy nem fogunk érteni a clusterhez…. nos, akkor itt a lehetőség, hogy kipróbáljam magam: rendbe tudom-e rakni ezt a rakoncátlankodó clustert. Mondjuk elsőre séróból, google nélkül.

Event viewer. Semmi. Annyit mond csak, hogy nem működött a failover – de ezt nélküle is tudtuk. Cluster.log… nos, az már nincs. (Illetve van, de egyelőre ugye google nélkül nyomjuk.) Nézzük, mi a helyzet az EMC-ből. Azt mondja, hogy a storage group adatbázisa (ugye, csak egy lehet) mountolva van, viszont a replikáció státusza: suspended. Hoppá… ez ledőlt pihenni. De miért? Resume, az anyád mindenit. És egyből healthy is lett. Kábé 10 másodpercig, mert utána megint elfáradt.
Nézzük a node-okat: látszólag minden rendben. Megvannak a könyvtárak, hely van bőven a vinyón… akkor mi a francért nem éled fel a passzív node adatbázisa?

Ismételjük át a tananyagot. Hogyan lehet életre lehelni egy hibás adatbázist CCR clusteren?

• Ha az aktív node-on sérült az adatbázis, akkor eleve nem lehet felmountolni. Ilyenkor a ‘Recover database’ segít, az aktív node-on kiadva: ekkor a passzív node-ról történik egy visszamásolás. Jelen esetben ugye nem ez a helyzet, a Recover menüpontot választva az Exchange csak visszamorog, hogy ‘hülye vagy Ödön’.
• Amennyiben a passzív node-on lévő példány sérül meg, akkor jön az ‘Update database’, de a passzív node-on kiadva. (Egyébként el sem ronthatjuk, az aktív node grafikus felületén nincs update opció és vica-versa.) De ha már durvulunk, legyünk extra durvák: jelöjük be, hogy mindent töröljön, ami az adatbázishoz tartozik. Ez a tuti. Ilyenkor a passzív node-ról törli a hibás adatbázist, törli a hozzátartozó checkfile-t és a logokat, majd újraseed-eli az adatbázist.

Naná, hogy az utóbbi segített.

Ami a jó hír a történetben, hogy el tudtam bánni a hibával, szolgáltatás nem esett ki. A rossz hír, hogy nem tudom, mi történt. Egy hétig hozzá sem nyúltam a rendszerhez, ment minden… és csak az EMC konzolban lehetett volna észrevenni – ha valaki rendszeresen rá-ránézett volna – hogy az egyik adatbázisra nem megy a háttérben a replikáció. Természetesen ez egész addig nem tűnik fel senkinek, amíg nem történik valami, mely failovert indikálna. Mely ugye ebben az esetben előre nem látott körülmény miatt elmarad. És ekkor már a reseed sem segít, hiszen pont az aktív node dőlt le.

Erre bizony hamarosan megoldást kell találnunk.