Database Availability Group

Egy kicsit felpezsdült az élet, ahogy kijött az Exchange 2010 béta. Szép lassan körbe is lehet járni az újdonságait.

Kezdem a DAG-gal, mert számomra ez jelenti a legnagyobb strukturális változást.

Régebben voltak ugye az adatbázisok, ezek storage groupokban helyezkedtek el, a tranzakciós logok pedig SG-khez voltak rendelve. Az adatbázisok és a storage group-ok nevei szerverszinten kellett, hogy egyediek legyenek. (Ugye, a sok Mailbox Database a First Storage Group-ban.)
A magas rendelkezésre állást SG, illetve szerverszinten valósítottuk meg, attól függően, hogy melyik technológiát használtuk. Az adatbázisok ettől még konkrétan szerverekhez tartoztak, ha egy SCR failover miatt váltanunk kellett, akkor át kellett ‘home’-olni a felhasználókat a másik szerverre. (Ez az aktív-aktív jellegű SCR-re vonatkozik.)

Exchange 2010-ben némileg megváltoztak a dolgok. Például tokkal-vonóval ki lett dobva a Storage Group fogalom. Az adatbázisok pőrén léteznek a szervereken. A tranzakciós logok szerverekhez rendeltek, de adatbázis szintűek. (Igen, ez nekem is zavaros egy kicsit, de egyelőre a részletekről nincs túl sok infó.)
Értelemszerűen a redundancia is adatbázis szintű. Ez a DAG.

Kezdjük ott, hogy feltelepítünk egy Exchange 2010 szervert, értelemszerűen – a DAG miatt – Windows Server 2008 Enterprise szerverre. Magát a Failover Cluster szolgáltatást nem is kell telepíteni. Később feltelepítünk egy másik szervert, hasonló felállásban. Az első alkalommal, amikor azt mondjuk, hogy és most szeretnénk egy DAG-ot erre a két szerverre, akkor a Failover Cluster szolgáltatás automatikusan települ, anélkül, hogy külön értesítene minket. Nincs lehetőségünk, hogy nekiálljunk válogatni, CCR vagy SCR technikát szeretnénk. Maga a technológia bekerült a motortérbe, a vezetőülésből már nem látjuk.

A mi dolgunk az lesz, hogy meghatározzuk, hogyan oszoljanak el az adatbázisaink a DAG-ban. Melyikből legyen másolat a másik szerveren? (Több szerver esetén nyilván ennél bonyolultabb figurákat is össze tudunk rakni.) Illetve azt is meg tudjuk adni, hogy a felhasználók mely adatbázisokat milyen prioritással használjanak.

Kíváncsi vagyok, kinél csengetett a vészcsengő? Több szerver? Hiszen eddig a CCR két szerverre korlátozódott? Immár nem.

Folytassuk. Az gondolom látszik, hogy ebbe a struktúrába a hagyományos SCC cluster nem fog beleférni. Béke poraira. Az Exchange 2010 már nem fogja támogatni.

Jó hír a kisebb cégeknek. Immár a magas rendelkezésre állás nem zárja ki azt, hogy más szerepkör is rákerüljön a Mailbox szerverre. Szabad a pálya – így gyakorlatilag két szerverrel megoldható minden.

Logikus következmény, hogy DAG esetén az adatbázisokat már nem szerverhez kell rendelnünk, hanem organizációhoz. Hiszen már több szerveren is előfordulhat. Ebből következően az adatbázis nevének organizáció szinten kell egyedinek lennie.

Létezik egy olyan tendencia az Exchange fejlesztői csapatban, melyet úgy neveznek: Backupless Configuration. Azaz az Exchange szabadulni akar a backup/restore mocsárból. A DAG ebben is nagyot segít, hiszen azzal, hogy több szerveren is megtalálható ugyanannak az adatbázisnak ugyanolyan változatú példánya, az adatvesztés meglehetős nagy eséllyel kizárható. Oké, mondhatnád, de mi van akkor, ha valaki töröl egy elemet, majd később azt kell visszaállítani? Nos, lehetőségünk van késleltetésre is. Ez azt jelenti, hogy megadhatjuk egy DAG-on belül, hogy egy istenhátamögötti, alacsony prioritású adatbázisra a logok csak bizonyos késéssel játszódjanak rá. A késleltetés maximális értéke 14 nap. (Ehhez kell még hozzáadni azt az időt, melyet a Dumpster nyújt.)

Megjegyzés:
Maradjunk annyiban, hogy ezen a téren szkeptikus vagyok. Nagyon. Sok cégnél éveken átnyúló archiválási előírások vannak. Oké, hogy az Archive Mailbox (AMBX) ezen sokat fog segíteni (persze merevlemezterület beáldozásával, szalagra ugye nem tud dolgozni), de mi van, hogyha valaki ebből az AMBX postaládából töröl ki mondjuk egy egyéves levelet? Nem mondhatjuk azt, hogy ‘márpedig ilyen nálunk nem fog előfordulni’. Érzem az Exchange csapat erőfeszítéseit, a lehetőségek 90-95%-át már le is tudták fedni – de a levelek visszakereshetőségének a megadott intervallumra kötelezően 100%-osnak kell lennie. Más nem fogadható el, még a kis cégeknél sem.

Vissza a DAG-hoz. Van-e valamilyen megkötés a két szerver elérhetőségére nézve?
Van. Mindkettőnek azonos címtárban kell lennie. (Nyilván az azonos organizáció a fő követelmény.) Ezen belül a szerverek tetszőleges AD site-on, tetszőleges alhálózaton lehetnek – egy követelmény létezik csak: a szerverek közti késleltetés nem lehet nagyobb, mint 250 ms.

Az írás végére néhány link:

Leave a Reply

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