Éj a Szerverszobában – 01

A háttérben tessék elképzelni az Éj a Kopár Hegyen dallamát. (Ugye, a Sátán fellátogat a Földre, az őt imádó boszorkányok szombatjára.)

Nos, azt mi csak hisszük, hogy amikor estefelé végre becsukjuk a szerverszoba ajtaját és hazaindulunk, akkor a szerverek kismacskaként összekucorodnak és békés dorombolás mellett várják, hogy majd reggel megint eléjük borítjuk az ennivalót. Szervereink – ha jól vannak nevelve – akkor bizony éjszaka sem pihennek. Ilyenkor jön el általában a backup ideje – és természetesen a különböző adatbázis-karbantartásoké is.

A mostani írásban az Exchange szerver adatkarbantartási folyamataival fogok foglalkozni.

A backup-pal speciel nem. Meg később se nagyon. Az Exchange-t illetően jelenleg ez a legképlékenyebb terület, ahol éppen nem technikai megoldások, hanem koncepciók rivalizálnak.

Az adatkarbantartás, azaz nevezzük már nevén, az Online Maintenance, mindig is benne volt a termékben, de soha nem került úgy igazán a reflektorfénybe. Olyan félénk fajta a szentem. Pedig nem kellene szégyenkeznie, mert nagyon fontos szerepe van. Viszont egészen a 2010-es verzióig olyannyira visszafogottan viselkedett, hogy amint nagyobb terhelés érte az adatbázist, rögtön leállt. Azaz hiába időzítettük be adatbázisonként, hogy minden este fusson le, ha ráindítottuk közben a backupot is az adatbázisra, akkor az OM kiszállt a partiból. Majd holnap – gondolta. De ha másnap is jött az erőszakos backup… akkor az OM soha nem futott le végig.

Részletesebben a 2007-es verzióval fogok foglalkozni, de azért vetünk majd egy pillantást a 2010-esre is.

Adatkarbantartás. Mit is takar ez a fogalom? Miket kell csinálni azokkal az adatokkal, hogy karbantartva érezzék magukat?

A következő folyamatokról van szó:

  • Purge Indexes
    A törölt pointerek fizikai eltávolítása az indexfájlból.
  • Tombstone Maintenance
    A törölt elemek törölt státuszát jelző sírkövek menedzselése, lejárat esetén törlése.
  • Dumpster Cleanup
    A törölt elemek – egy beállítható ideig – nem kerülnek törlésre, hanem egy átmeneti tárolóba esnek be. Ezt hívjuk Dumpster-nek. Amint letelik az idő, véglegesen törlődnek.
  • Public Folder Expiry
    A nyilvános mappákban beállítható, meddig ‘élhet’ egy elem. Ezek lejártát vizsgálja a folyamat.
  • Age Folder Tombstone for Public Stores
    Hasonló a korábban említett sírkő kezeléshez. A különbség annyi, hogy nyilvános mappa esetén a public folder replikációt is figyelembe kell venni.
  • Folder Conflict Aging for Public Stores
    Azonos időben módosított nyilvános mappák konfliktusfeloldó folyamatának indítása. (Levelek küldése a két módosítónak.)
  • Update Server Versions for Public Stores
    A nyilvánosmappa replikációkhoz kapcsolódó verziószámok frissítése.
  • Site Folder Check for Public Stores
    Annak ellenőrzése, hogy az Administrative Group-on belül ne legyenek duplikált Site Folderek.
  • Cleanup Deleted Mailboxes for Mailbox Stores
    Azoknak a postafiókoknak a kezelése, melyekhez már nem tartozik tulajdonos felhasználó.
  • Check Messages Table
    Azoknak az elemeknek az eltávolítása, melyekre nem mutat pointer.
  • Online Defregmentation
    Tulajdonképpen ez az a folyamat, amellyel nagyon sokan összekeverik az Online Maintenace folyamatot. Tény, hogy ez a leglátványosabb eleme, de azért bőven nem csak ez játszódik le.
    Az Exchange adatbáziskezelésének a módszeréből következik, hogy a törölt elemek után lyukak maradnak az egy nagy fájlként látszó adatbázisban. Ezek a lyukak későbbi adattárolásra alkalmatlanok. Célszerűen az Online Defregmentation folyamat ezeket a lyukakat (whitespace) rendezi egy helyre, elérve azt, hogy az így kialakuló területek újra részt vehessenek az adattárolásban. Ezzel lehet biztosítani azt, hogy ha már az adatbázis mérete nem csökken, akkor ne is nőjön – feltéve, hogy az újonnan létrejövő elemek száma nem haladja meg jelentősen a töröltekét.
  • Database Checksumming
    Normál Exchange szerver esetén mentés során megtörténik a tranzakciós logok rájátszása az adatbázisra, emellett pedig lefut még egy adatbázis-integritás ellenőrzés is. Amennyiben CCR Exchange clusterünk van, amelynél a passzív node-ról mentünk, akkor az aktív node-on lévő adatbázisokra soha nem fog lefutni az integritás ellenőrzés.
    Ezt lehet úgy kivédeni, hogy engedélyezzük az Online Maintenance folyamatnak – mely ennél a felállásnál szigorúan az aktív node-on fut – hogy menetközben végezzen el egy integritás ellenőrzést is.
  • Database Page Zeroing
    Az Exchange adatbázisban egy elem törlése nem jelenti azt, hogy fizikailag is ki lett radírozva az elem tartalma. Pusztán csak az index jelzi, hogy ott már nincs elem.
    Amennyiben ez nekünk nem megfelelő, beállíthatjuk, hogy az Online Maintenance folyamat során a törölt elemek helyét nullával írja felül az Informaton Store szolgáltatás.

Az utolsó két folyamat csak az Exchange 2007 SP1 utáni rendszerekben működik és alapértelmezésben nincs bekapcsolva.

Mielőtt belecsapnánk a lecsóba, nézzük meg, mi a helyzet az Exchange 2010-ben.

A legnagyobb változás az, hogy kiszedték a karbantartási folyamatok közül az online defregmentálást. Ez innentől kezdve _állandóan_ fut, akármilyen terhelés is éri az adatbázist. Természetesen az Online Maintenance ütemezési lehetőségei továbbra is megmaradnak, csak éppen az elvégzendő feladat mennyisége csökkent.

Megváltozott a Database Checksumming is. Nem csak azért, mert átnevezték Database Scanning-re, hanem egy kicsit erőszakosabbá is tették. Na, nem nagyon, de ha egy adatbázis nem lett 3 napon belül egyszer átvizsgálva, akkor warning keletkezik az eventlogban.
Ennél is fontosabb változás az, hogy kétféle módban futtathatjuk:

  • Beállíthatjuk, hogy ez legyen az utolsó lépés az Online Maintenance folyamatban. Ez azért fontos, mert ha korábban olyan ablakot adtunk egy adatbázisnak, melyben szakadás volt, akkor az újraindulásnál nem az esedékes OM folyamat folytatódott, hanem mindig lefutott egy Database Checksumming. A hivatalos doksi szerint ez a mód főleg a kisebb adatbázisok esetében praktikus.
    Jó kérdés, mi számít kisebb adatbázisnak?

    This option works well for smaller databases that are less than 1 terabyte (TB) in size.

    Aha.

  • Beállíthatjuk azt is, hogy az online defregmentáláshoz hasonlóan a Database Scanning is 7/24-ben menjen.

Oké, térjünk vissza az Exchange 2007-hez.

Mit is tanultunk, mekkora lehet maximum egy Exchange 2007 adatbázis? Attól függ. Általában 100 GB a felső határ, de ettől egy speciális esetben eltérhetünk. Ha ugyanis CCR clustert építünk és elválasztjuk egymástól a két éjszakai orgiát, azaz a backup a passzív node-ról fut, az Online Maintenance meg békésen elpöfög az aktív node-on, akkor a felső határ felugrik 200 GB-re. (Nyilván az egésznek az az értelme, hogy záros időn belül esélye legyen az OM-nek lefutni. Ha a backup állandóan megszakítja, akkor nem lehet nagy az adatbázis.) Értelemszerűen ebben a helyzetben kötelező a Database Checksumming is, hiszen a backup elvégzi ugyan a passzív node-on az adatbázis integritásellenőrzősőt, de az aktív node-on ez nem történik meg.

Kitérő:
Érdekes kérdés, hogy CCR esetében hogyan megy át az OM hatása a passzív node-ra? Addig oké, hogy az aktív node-on buzeráljuk az adatbázist, jobbra-balra pakolgatjuk az adattáblákban az adatokat, döntögetjük a sírköveket, meg ilyesmik – de hogyan gondoskodunk arról, hogy mindez megtörténjen a passzív node-on lévő adatbázissal is? A kulcs: minden OM során elvégzett művelet bekerül a tranzakciós logba, az pedig, mint tudjuk átreplikálódik és előbb-utóbb rá is játszódik a passzív példányra.

Hohó, mondhatja ilyenkor a nagy horgász gyanakvó adminisztrátor, de akkor az OM több szekérderéknyi logot fog generálni! Jó az nekünk? Annyira nem… de ha ügyesek vagyunk, akkor úgy állítjuk be a mentést a passzív node-on, hogy az a konkrét adatbázisnál az OM ablak után nem sokkal induljon, így egyből el is tudjuk tüntetni a rengeteg logot. (Természetesen az OM ablak alatt egy másik adatbázis mentése simán futhat.)
Látható, ez igazából egy nagy csiki-csuki, egy kifejezetten embert próbáló optimalizálási feladat.

Mondjuk, egyszer belőttük. Ülhetünk-e nyugodtan a babérjainkon a továbbiakban? Nyilván nem. Az adatbázisok mérete folyamatosan változik. (Nő.) Igazából nem is ez a baj, hanem az, hogy egymáshoz képest máshogyan nő. Azaz lehet, hogy most a DB01 adatbázisnak kell adnunk a rendelkezésre álló idő 15%-át, mert akkora, de lehet, hogy egy fél év múlva a többi beelőzi és már csak 5% járna neki.

Rossz hírem van. Ezt az optimalizálási folyamatot célszerű negyedévente végigjátszani.

Ezért nem árt, ha kidolgozunk rá egy rögzített folyamatot. Erről fogok írni legközelebb.

Leave a Reply

Your email address will not be published. Required fields are marked *