Milyen már, amikor a katasztrófa-visszaállítási teszt során következik be a katasztrófa?

Elmesélem a sztorit. Tanulságos. Először ugyanis elböktük, aztán viszont kimásztunk belőle.

Mivel egy komplett datacentert kellett visszaállítanunk, mondanom sem kell, egy csomó ember nyüzsgött a munkán. Az én feladatom meglehetősen korlátozott volt, a levelezésnek kellett mennie a visszaállítás után, oszt jónapot.
Egy teljesen klasszikus CCR/SCR rendszerről van szó, többször is végigjátszottam már ilyen teszteket, bent volt egy dossziéban a szükséges egységcsomag. Nem mondhatnám, hogy túlzottan ideges voltam. A CCR/SCR replikációra ránéztem még a teszt előtt, normálisan ment.

Aztán egyik délután kilőtték a jelzőrakétát, elvágták a vezetéket a két telephely között. Másnap reggel megkérdeztem a PM-et, hogy tényleg elvágták-e a kábelt. Ja.
Oké, a disable-storagegroupcopy paranccsal kiirtottam az irmagját is a standby node-nak az éles rendszerből, majd vártam, mikor szólnak, hogy mehetek a DR telephelyre, stoppolni. (A kiirtás nagyon fontos: mint nemrég is írtam, ha fizikailag elérhetetlenné válik az SCR, akkor a backup nem törli a logokat, így viszont hamar feltelnek a logpartíciók.)

Eltelt pár nap, szóltak.

Kezdtem az első lépéssel, az adatbázisok macerálásával.

Itt most egy kis kitérő jön. Legyen már szakmai anyag is az írásban, ne csak egy szívás története.
Az SCR node az egy furcsa lény. Felkerülnek rá az Exchange dll-ek, lesz rajta konzol és shell… de Exchange szerver, az nem. Nem fogod látni sehol sem a konzolban. De még a shellben sem. A jelenlétéről is csak akkor fogsz tudni, ha néhány parancsnál használod a -standbymachine kapcsolót.
Ennek ellenére vannak rajta adatbázisok. (Még szép, hiszen ez az egész elv lényege.) Information Store, az nincs. Viszont van Microsoft Exchange Replication szolgáltatás.

Na most, mire is lehet használni egy ilyen szervert?

  • Database portability
    Valamilyen oknál fogva egy adatbázisodat egy másik szerveren szeretnéd felcsatolni. Lehet, hogy kidőlt az SCR forrásod alól a diszk alegység, lehet, hogy kidőlt a CCR-ed alól az az egy SAN, amelyiken mindkét adatbázispéldányok laktak (ugye-ugye), lehet, hogy át akarsz vinni egy adatbázist egy tesztkörnyezetbe. Nos, erre az SCR adatbázisok tökéletesek.
  • Site Resilience
    Az SCR forrásod elpárolgott. Semmivé lett. Te pedig szeretnél máshol, más telephelyen, az előzővel egyező néven létrehozni egy új szervert, majd ez alá felcsatolni az SCR adatbázisokat.

Akármelyik esetről is legyen szó – jelenleg ugye a második játszik – az első lépés az adatbázisok preparációja. Rájuk kell játszatni a logokat – és egyáltalán, olyan állapotba kell hozni, hogy az adatbázis felcsatolható legyen.
Erre szolgál a recover-storagegroupcopy parancs, méghozzá a következő szintaktikával:

recover-storagegroupcopy -identity server\sg -standbymachine scrname -force

Térjünk vissza a konkrét történethez. Kiadtam a fenti parancsot – és azt mondta az a gonosz EMS, hogy nincs ilyen nevű SCR szerverem. Nyilván begépeltem még néhányszor, hátha elütöttem egy karaktert, beírtam a teljes DNS nevével, adtam meg -domaincontroller értéket… hiába. Próbálkoztam a guglival is, de csak annyi választ kaptam, hogy ha ezt írja ki, akkor tényleg nincs a rendszerben ilyen nevű SCR.
Hát ez meg hogyan lehet?

Úgy, hogy – most nem részletezendő okok miatt – még rögtön a teszt elején pár percre összenyitották a két telephelyet. Mi történt? A címtár konfigurációs névtere egyből lereplikálódott a DR telephelyre. Benne az az információ, hogy én akkor már lebontottam az SCR kapcsolatot – azaz nincs SCR a rendszerben. Szépen vagyunk. A DR telephelyen nincs más, amiből építkezhetnénk, csak az SCR node. Ami jelenleg nincs.

Vegyük sorra a lehetőségeket.

  • Húzzunk fel egy kamu clustert az élessel megegyező névvel a DR telephelyen, majd építsünk ki egy SCR kapcsolatot? Az égegyadta világon semmi értelme sincs.
  • Tegyük vissza az SCR szervert az éles környezetbe és építsük ki újra az SCR replikációt? Ez megoldás lenne, de DR teszt során még csak gondolni sem szabad ilyesmire. Nincs éles környezet.
  • Egy korábbi system state mentésből töltsük vissza a konfigurációs névteret – azon belül is az Exchange ágat – autoritatív módon a DR telephelyen? Ez akár még működhetne is, csak éppen ekkor már az összes felesleges DC ki volt irtva a DR címtárból, a meglévők meg már annyira el voltak állítva, hogy esélytelen volt a visszatöltés.
  • Próbáljuk meg Eseutil-lal feljátszatni a logokat? Biztos, hogy a restore-storagegroupcopy csak ennyit csinál? Itt ugyanis az a gond, hogy ha mégsem, akkor nagyot bukunk, mivel a különbség nem itt derül ki, hanem egy későbbi lépésben. Ahonnan már nincs visszaút. És akkor már nincsenek adatbázisok sem, ergo bedőlt a DR teszt levelezési része, az meg azért túl nagy blamázs lenne.

Maradt a jó öreg magyaros megoldás, a buhera. Amit biztosan tudtam, az az, hogy az SCR beállításai a címtár konfigurációs névterében laknak, méghozzá az Exchange Services ág alatt. Mi lenne, ha megkeresném ezeket és úgy csinálnék, mintha lenne még SCR node a rendszerben?
Az első probléma ott volt, hogy honnan találom ki, hol vannak ezek az értékek? A DR telephelyen már nem volt SCR, de az élesen sem. Szerencsére volt hozzáférésem más, hasonló rendszerhez, beléptem, turkáltam. Hadd ne mondjam végig a folyamatot… itt van az eredmény. A beállítások a Storage Group objektumokon vannak (mindegyiken egyenként), méghozzá az MsExchangeStandByCopyMachine nevű változóban, a következő kódolással:

scrname.domain.name;1;xx:xx:xx;yy:yy:yy

Ahol az xx:xx:xx a replaylagtime, az yy:yy:yy pedig a truncationlagtime. Az 1-es értékét nem tudom – de őszintén szólva, nem is érdekel. Nem szándékoztam működő SCR-t létrehozni, csak behazudni a címtárnak, hogy az scrname nevű gépem valóban SCR target volt.

Óvnék mindenkit, hogy éles rendszerben ezeket az értékeket módosítsa. A Microsoft hivatalos álláspontja szerint az SCR replikáció paramétereit csak úgy lehet megváltoztatni, ha lebontjuk a replikációt, majd az új paraméterekkel újra létrehozzuk. Nyilván okuk van rá.

Hozzáteszem, a kockázat most is megvolt. De csökkent! Ha Eseutil-lal esek neki, akkor esély sincs rá, hogy a restore-storagegroupcopy esetleges plusz műveletei lemenjenek. Ha viszont behazudok egy SCR-t, akkor lehet, lefut a restore-storagegroupcopy, a továbbiakban meg már kell a fenének az SCR.

Kiválasztottam egy adatbázist, preparáltam, majd lefuttattam rá a restore-storagegroupcopy parancsot. Molyolt, molyolt… majd a várt 1 warning helyett kettő dobott. Ennek azért nem örültem olyan nagyon, tekintve, hogy a plusz figyelmeztetést olyan szinten voltam képtelen értelmezni, hogy még az se derült ki belőle, hogy lefutott-e a parancs? Vadul nekiálltam túrni a netet, de nem találtam megnyugtató választ. Lefuttattam még egyszer a parancsot… erre megint azt mondta, hogy nincs SCR. Háteztmeghogyan? Hiszen éppen az előbb hazudtam be, hogy van?
Vissza az adsieditbe… és tényleg nem volt ott a beírás. Valaki törölte. Tehát van egy érthetetlen warning-om és belefutottam egy önvédelmi mechanizmusba. Nem túl biztató.

Elvonultam gondolkozni.

A kulcs az, hogy a warning ellenére tényleg megcsinálta-e mindazt, amit tennie kellett? És csak utána törölte-e ki az általam beírt adatokat a védelme?
A törlés biztosan utólag történt, mert hibaüzenetet csak az újabb futtatáskor kaptam. De az a warning… Ráküldtem a parancsot a -verbose paraméterrel. Nem lettem okosabb. Végül úgy döntöttem, hogy ha tényleg képtelen lett volna elvégezni a dolgát – akár egy kezdeti ellenőrzés után is – akkor itt hibaüzenet lett volna, nem figyelmeztetés. Meg egyébként sincs más esélyem, csak ez.
Behazudtam a fenti string-et az összes storage group-nál, beírtam az alábbi parancsot, és malmoztam.

get-storagegroup | restore-storagegroupcopy -standbymachine scrname -force

Jó jel volt, hogy nagyon sokáig dolgozott.

Aztán nagy levegő, gyerünk tovább. DNS preparáció, AD jogosultságok állítása, majd jöhet a vízpróba. Cluster telepítése, a recovercms kapcsolóval. Prerequisit-ek ellenőrzése. 10 perc. Az életemből a tízszeresét vette el. Végül átszaladt rajta. Most jött a döntő pillanat: az első adatbázis felcsatolása.
Sikerült. Aztán szépen egyenként az összes.

Innentől meg már a jól ismert ösvényen mentünk tovább.