Exchange és backup… nem dúl közöttük a barátság. Pedig a backup látszólag nem túl bonyolult dolog: egy adott állapotról másolatot kell készíteni. Már az Exchange 5.5 is tudta, hogy amikor elindult a mentés, akkor “befagyasztotta” az adatbázisokat, ezeket lementette, a mentés alatti adatforgalmat ideiglenes adatállományban tárolta, majd a mentés végén az ideiglenes állomány tartalmát rámásolta az élesre. Ennyi.
Mi lehet a baj?
A tudományos fejlődés.
Az hagyján, hogy a tervezők rájöttek arra, hogy a logfájlokkal rengeteg kunsztot lehet bemutatni: full/copy/inkrementális/differenciális backup… ezek régi dolgok. De a cluster koncepció megváltozása, a tranzakciós logokkal bűvészkedő replikációs fürtök már belecsaptak rendesen a lecsóba. Nem is beszélve a fájlmegfogást megkerülő shadow copy-ról, melynél már nem kell vacakolni ideiglenes állományokkal, a VSS writer tud írni akkor is, ha meg van kötve a keze.
Csak éppen maga a folyamat annyira bonyolult lett, annyira sérülékeny, hogy bármilyen kis rendellenesség hetekig tartó kilengéseket képes produkálni. Gondoljunk bele: egyrészt a Windows 2008-ból eltűnt az Exchange mentés lehetősége, később persze visszajött, de bénán: csak egész kötetet enged menteni. Ha ennél finomabb eljárásra van szükségünk, akkor jöhetnek a külső gyártók. Figyeltél? Külső gyártók. Na, innen indul el a totális káosz. Van egy érzékeny, ráadásul a Rollup Packokkal sűrűn változó rendszer, meg a tipikusan lomha és ügyfélérzéketlen külső gyártó. Pusztán csak idő kérdése, hogy jöjjön az a bizonyos apró rendellenesség, melytől hetekig leng a rendszered.
Mi is az, hogy leng? Ha nem megy a mentés, nem törlődnek a logok, ha betelik a logpartíció, megáll a levelezés, ha törlöd a logokat, megáll a cluster replikáció. Egyáltalán nem véletlen, hogy az Exchange team már évek óta azért küzd népnevelésügyileg, hogy felejtsük már el azt a nyűves backupot, próbáljuk meg kiváltani más technológiákkal.
Csak éppen ebben a népművelésben kicsit sok még a köd. Oké, csinálj clustert (CCR, DAG). Ezzel kivédted a katasztrófát. Ha geoclustert csinálsz, akkor elviseled még a telephelyed megsemmisülését is. Great. De mi van a törölt adatokkal? Használd a dumpstert. Remek számítások vannak arra nézve, hogy akár egy évnyi(!) dumpster mennyivel növeli meg az adattárolási kapacitást. Igaz, az Exchange 2010 alá már közértben vásárolható vinyók is jók, de a hosszútávú dumpster egy átlagos felhasználónál durván évi 1,5 GB növekményt jelent. Oké, természetesen lehet trükközni még az archiv postafiókkal is, de azért itt már komolyan neki kell állni számolgatni, mi is az olcsóbb. Azt ugyanis nem szabad elfelejteni, hogy értelmes összegből akkor lesz egy rendszer backupless, ha eleve annak is tervezik. A legtöbbször már van egy SAN, benne egy vagy két rohadt drága storage, azt mondani, hogy ezt innentől tessék nyugodtan kidobni… elég necces. Brutálisan felbővíteni… szintén.
Itt eredetileg egy eszmefuttatás lett volna arról, hogy és akkor mit csinálunk a módosított adatokkal? Ehelyett meaculpa van. Utánaolvastam, és most már tudom, hogy a dumpster 2.0 verziózni is tud. Persze ekkor megint visszajutottunk oda, hogy tárterület, lapátszámra. Különösen, ha egy cégnek mondjuk 5 évre visszamenőleg kell megőriznie a levelezését.
Illetve gondoljunk át még egy szempontot. Ha nincs backup, mi takarítja el a logokat? A Köztisztasági Vállalat nem fogja. Mi is volt a logika a mentés utáni logtörlésekben? Az adatoknak minimum két helyen meg kell lenniük. Eredetileg ez az adatbázis (RAM+HDD) és a log, a mentés után az adatbázis (HDD) és a szalag. Azaz lehet törölni a logot. Ha nincs backup, nincs törlés. Nyilván utánaolvasol, azt találod – de nem túl hangosan reklámozva – hogy használj 3 node-ból álló DAG-ot (mert ekkor nem kell RAID sem, jó a JBOD), ha van rá pénzed, legyen egy lagged copy is, és ha nem akarsz menteni, akkor kapcsold be a cirkuláris logolást. Az Exchange adminok itt kapnak a szívükhöz: 13 éve azt hallják, hogy négy láb jó, két láb rossz, cirkuláris logolás meg a legrosszabb. Elfogadom, tudnunk kell kigondolkozni a dobozból, de valahogy még mindig meglehetősen el vannak rejtve az infók.
Egyáltalán nem meglepő, hogy egy átlagos informatikus – nem beszélve az átlagos IT vezetőről – sokkal inkább azt mondja, hogy backup.
Akit esetleg mélyebben érdekel a dolog, itt talál egy nagyon részletes négyrészes írást Henrik Walthertől. Kötelező darab a tisztánlátáshoz. De a végén tessenek elgondolkodni, mi is a feltétele a 4. részben leírt visszaállításnak.
Na, a hosszú bevezetés után jöjjön a sztori.
Előzmény. Az egyik adatbázis – kampányszerű üzleti tevékenység miatt – bevadult. A logfájlok kihízták a logpartíciót, adatbázis megállt. (Olyan gyors volt a feltelés, hogy bár a figyelő rendszer beriasztott, de mire beavatkozhattunk volna, már fejre is állt minden.) Oké, a logkönyvtárat a már ismert módon áttettük máshová, adatbázis visszaindult.
Nem sokkal később a CCR/SCR rendszerben volt egy failover, majd valamivel később egy failback. A backup külső gyártó szoftverével volt megoldva, méghozzá úgy, hogy a passzív node-ról – és csak arról – ment VSS backup-pal. Egy bibi volt, a szoftver képtelen lekövetni, melyik node a passzív, így azt tudtuk csak beállítani, hogy arról a node-ról mentsen, amelyik az idő nagyobb részében a passzív node. Ez borult fel a pár napos csere miatt és a backup szoftver teljesen bele is zavarodott.
Közben a szerelők felpumpálták a korábbi adatbázis logpartícióját, lehetett visszarakni a logokat. A művelet teljesen hasonlóan zajlott, az eredmény viszont lesújtó lett: az adatbázist ugyan fel lehetett csatolni, de a replikáció failed állapotba került.
Több évnyi tapasztalat után határozottan ki merem jelenteni, hogy az esetek 90%-ában ilyenkor semmi más nem segít, csak a reseed. Nos, most belefutottunk abba a bizonyos 10%-ba: a reseed sem segített. Fejvakarás. Az eventlog szerint hiányzik egy csomó tranzakciós log, és mindenki az anyja életére esküdött, hogy nem ő dugta el. Ekkor derült ki, hogy nem megy a backup, azaz folyamatosan telik fel az összes logpartíció. Miközben reménytelenül nem megy az egyik adatbázisra a logreplikáció. Nem túl biztató a helyzet.
Kipróbáltunk ezt-azt, ahogy az ilyenkor szokás. Nyilván volt közte néhány failover/failback is. Az egyik különösen izgalmasra sikerült, hosszú percekig nem történt semmi, aztán egyszer csak beröffent a cluster. Aznap nem is mertünk hozzányúlni többet.
Másnap összegyűlt a válságstáb. A partíciók monoton teltek befelé, ötlete meg senkinek sem volt. Pontosabban, nekem volt még egy, de azt mondtuk, hogy ha ez sem jön be, akkor eszkalálunk az MS felé.
De mielőtt nekiállhattunk volna, jött az SMS az üzemeltetőtől, hogy reggel ránézett a rendszerre és teljesen váratlanul megjavult a backup. Magától.
Pár hajam azért égnek állt. Megnéztem, és tényleg. Az összes logpartíció tiszta volt… kivéve a replikálatlan adatbázisét.
Huh. Ezt megúsztuk. Bár a fene tudja, hogyan. Én összeraktam ugyan egy elméletet, miszerint a hosszú failoverbe belehülyült a backup szoftver és nem vette észre a failback-et. Emiatt próbálkozott folyamatosan az akkor már aktív node-on, de ez a backup szoftver meg arra képtelen. (Ezeknek a próbálkozásoknak a nyomait láthattuk is.) Ez ment addig, amíg az egyik failback után hirtelen nem realizálta, hogy jé, failback történt. (Ez lett volna az az idegesítően hosszú failback.)
Hülye elmélet, de nem találtunk jobbat.
Kihasználva a lendületet, aznap délután ráküldtem a renitens adatbázisra is egy reseed-et. Hátha ma olyan nap van, hogy minden sikerül. Nem jött be. Másfél óra szuttyogás, aztán a suspend után ugyanúgy ott vigyorgott a failed.
Másnap éppen nagy paláver volt, a sok futó ügy mellett rátértünk erre az esetre is. Sok jót nem tudtam mondani. A logok replikációja a CCR vérkeringése, ha kiesik belőle egy logdarab, azt a replikációt az életben nem rázzuk gatyába. Legegyszerűbb javításnak azt javasoltam, hogy hozzunk létre egy új adatbázist, mozgassunk át mindenkit, majd töröljük a sérült replikációjút. Erre mindenki rá is bólintott, az üzemeltetők elkezdtek teszt postafiókokat mozgatni. (Mert ekkor éppen nem jutott eszembe a disable-storagegroupcopy parancs.)
Délután két üzenetet is kaptam. Az egyik az volt, hogy nincs semmi gond a postafiók-mozgatással. A másik az, hogy nézzek már rá a storage groupra, mert gyanúsan és makacsul úgy néz ki, mint aki egészséges. Ránéztem… és tényleg.
Na, ilyen nincs. Ekkor kerültek bele a fognyomaim az asztallapba. A többi mellé. Ugyanaz a történet, és már másodszor fordul elő, hogy miután fekete színekkel ecseteltem a jövőt, váratlanul megjavult a rendszer. Magától.
Szerencsére elméletgyártásból borzasztó jó vagyok, egy kis idő után itt is találtam valószínűnek tűnő magyarázatot.
Kapkodtam. Amikor ráküldtem a reseed-et, nem vártam eleget. Ha csináltál már ilyesmit, akkor tudod, hogy egy suspend/resume páros után a replikáció mindig healthy állapotot mutat, majd 1-2 perc várakozás és egy refresh után mondja csak meg az igazi értéket. Na, én éppen fordítva jártam, failed értéket mutatott a reseed után, aztán pár perc múlva váltott át healthy-be. Csakhogy akkor én már éppen hazafelé utaztam. (Hogy ne hidd azt, hogy én a fantáziámból élek. A passzív node-on lévő logok dátum értékéből ki tudtam olvasni, mikor röffent be a replikáció. Ebből tudtam, hogy pár perccel később, mint ahogy előző nap bezártam a terminálablakot.)
Na, mindegy, vészforgatókönyv lefújva. Tulajdonképpen minden rendben. Megy a backup, megy a replikáció, madarak ülnek vérebekhez. Eltekintve attól a szépséghibától, hogy a passzív node-on 1 napnyi log volt, az aktívon meg egy heti. De mivel mind a replikáció, mind a backup ment, meg voltam győződve róla, hogy ez a baki hamarosan rendeződni fog.
Nem így történt.
Eltelt két nap, a backup ment, a replikáció szintén… de a logok csak gyűltek. Alapvetően egy Exchange admin élete nem túl bonyolult, csináltam egy újabb reseed-et. Simán lepucolta a logokat a passzív node-ról. Alakul. Az aktív node-ról elmozgattam máshová a replikáció beindulása előtti logokat (ezek biztosan nem játszanak a replikációban), majd trükköztem egyet. Failover. Ekkor az aktívból lett passzív node. Újabb reseed. Innen is lepucolódtak a logok. Failback.
Elégedetten dőltem hátra. Kifogtam a rendszeren… és végre valamit én javítottam meg, a saját agyammal. Replikáció szépen megy, mindkét node-on üres a logpartíció, copyquelength, replayqueuelength értékek masszívan nullák. Tökély.
Persze az abszolút megnyugvás akkor következik be, ha este lemegy a backup és törli is a logfájlokat.
Nem törölte.
Ha láttál már gyilkos tekintetet… akkor szorozd be kettővel. A jelek szerint minden tökéletesen működik… csak éppen a backup nem törli a logokat. Mivel a szituáció egyfelől nagyon általános, másfelől nagyon speciális, esély sincs megoldást találni a guglin.
Marad a szörfözés az eventlogban. Jegyzetfüzet, plajbász, göngyölítsük fel, mi is történik a mentés során. Semmi rendkivüli. A VSS writer megkapja a kérést, összekészíti az adatbázist, a mentő szoftver elviszi, majd jelzi az ESE-nek, hogy a részéről mehet a log file truncation. Az ESE visszaszól, hogy oké, ahogy születik az új loggeneráció, törli a régit. Majd pár órával később egy replikációs lépés során megemlíti az aktuális generáció számát, mely jóval magasabb, mint amit korábban jelzett. Azaz megtörtént a generációváltás – és minden igérete ellenére, az ESE nem törölte a logokat. Őrület.
Gondolkodósarok. Mikor nem törlődnek a logok? Amikor a replikációnak még szüksége van rá. (Emiatt van az, hogy hiába állítod cirkulárisra a logolást egy CCR rendszerben, amíg nem történik meg a logok replikációja, addig nem harap saját farkába a kígyó.) Jó… de ezzel beljebb vagyunk? A replikáció tökéletesen megy. Két ablakban egymás mellé téve a könyvtárakat, akár még animációnak is elmegy, ahogy keletkeznek, vándorolnak.
Kész, itt adtam fel. Egyrészt volt mellette más, igen sürgős munkám, másrészt meg elfogyott a puskapor. Látszólag minden tökéletes, gyakorlatilag meg nem. Hogyan keressek hibát, ha nincs semmilyen nyom?
Hiba volt feladni. Légyszives olvasd el alaposan az eddig írtakat. Minden információ ott van benne, ami a megoldáshoz szükségeltetik. Lehet, én is megtaláltam volna(1), ha nem azon a bizonyos másik munkán járt volna már nagyobbrészt az agyam.
Mindenesetre a beavatkozás nem tűrt halasztást, a logfájlok megint gyarapodtak, a logpartíció szépen telt, telegetett. Microsoft PSS. Leírtam szépen mindent, amit az esettel kapcsolatban tudtam, az üzemeltető kolléga lett a kontakt, én maradtam cc-ben.
Rögtön az első felvetés beletalált a tizes körbe. Ez ugyanis nem szimplán CCR, hanem SCR rendszer is. Csak éppen azzal a szerencsétlen SCR szerverrel soha nem foglalkozik a kutya sem. Azaz ha egyszer, csak úgy véletlenül, beírtam volna a get-storagegroupcopystatus parancs paraméterei közé a -standbyserver kapcsolót, rögtön kiugrott volna, hogy az SCR replikáció még failed állapotban van azon a bizonyos adatbázison. Emiatt volt még szükség a régi tranzakciós logokra, emiatt nem törölte azokat az ESE. Természetesen rögtön nekiugrottunk annak is egy reseed-del, majd amint helyreállt a replikáció, az esti mentés törölte is a logfájlokat. Ahogy kellett.
(1) Különösen úgy, hogy egyszer már ki is írtam magamnak figyelmeztetésként. Azóta egy másik ügyfélnél csináltunk egy katasztrófa utáni visszaállítás-tesztet, és amikor elővettem a korábbi jegyzeteimet, ott vigyorgott az egyikben a kiemelés:
If the SCR source is a clustered mailbox server (CMS) in a CCR environment, the log truncation logic includes successfully copying and inspecting the log files by all SCR targets. This means that if an SCR target is not available, log truncation does not occur on the SCR source even if backups are taken.
http://technet.microsoft.com/en-us/library/bb676465(EXCHG.80).aspx
Recent Comments