Month: April 2009

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:

Exchange 2010 Beta

Megjelent a következő Exchange első publikus beta verziója, amiről bővebben itt olvashatunk.

Ezzel együtt megjelent a hozzá tartozó nyelvi csomag, ami innen tölthető le (ez nem a Unified Messaging nyelvi csomagja). Ezentúl még két érdekes dolog került ki a Microsoft új nyitott kommunikációs stratégiájának jegyében:

A teljes protokol dokumentáció

És a felhasznált kommunikációs szabványok dokumentációja

Én a fenti csomagból személy szerint egyetlen dolgot hiányolok ebben a pillanatban. A 32bites verziót. Ma már egyre kevesebbeknek okoz ez fejfájást, ugyanakkor aki desktop gépen virtuális környezetben szeretne az új Exchange-el ismerkedni, annak még ma sincs igazán lehetősége a 64bites platform használatára.

Event Sink -> Transport Agent, vagy mégse

A Technet fórumon volt egy kérdés ami egy Outlook hibára vonatkozott (megosztott postafiókban a jogosult nem látja a privátnak jelölt levelet még akkor sem, ha ezt megengedtük neki). A környezet Exchange 2003. Egy megoldási javaslatként (vagyis inkább a hiba megkerüléseként) feldobtam, hogy írok egy Event Sink-et ami leveszi a megosztott postafiókba beeső levelekről a privát jelzést.

Útközben kiderült, hogy éppen Exchange 2007-re migrálnak. Ó, semmi gond, akkor nem Event Sink-et írunk, hanem Transport Agent-et. Vagy mégsem?

Az Exchange 2007-ben létezik a Transport Rule intézménye. Meg lehet oldani a fenti problémát ezzel?

Próbáljuk meg!

Itt van az a EMS Script ami a megoldást adja:

$DGOU = "test.local/Users"
$NoSensitiveDGName = "No Sensitive Message"
$NoSensitiveDGAccount = "nsdg"
New-DistributionGroup -Name $NoSensitiveDGName -OrganizationalUnit $DGOU -SAMAccountName $NoSensitiveDGAccount -Type "Distribution"
$condition = Get-TransportRulePredicate SentToMemberOf
$condition.Addresses = @(( Get-DistributionGroup $NoSensitiveDGName ))
$action = Get-TransportRuleAction RemoveHeader
$action.MessageHeader = "Sensitivity"
New-TransportRule -Name "RemoveSensitivity" -Conditions @($condition) -Action @($action) -Enabled: $true

Az eredeti feladatnál kicsit tovább mentem. a fenti script létrehoz egy disztribuciós listát. Aki ennek a listának a tagja lesz annak a bejövő leveleiről lekerül a privát jelzés (valamint a Personal és a Confidential is).

A fenti feladat kapcsán eszembe jutott egy régi Event Sink. Karsai Peti írta valamikor a távoli múltban. Ez a Sink képes Exchange 2003 alatt leszedni a levelekről az olvasási értesítőt, ami sokakat zavar.

Kicsit átírtam az előző EMS scriptet, így alkalmas lett olvasási értesítők eltávolítására. Természetesen ez is egy disztribúciós lista tagsággal kontrollálható:

$DGOU = "test.local/Users"
$NoReceiptDGName = "No Read Receipt"
$NoReceiptDGAccount = "nrr"
New-DistributionGroup -Name $NoReceiptDGName -OrganizationalUnit $DGOU -SAMAccountName $NoReceiptDGAccount -Type "Distribution"
$condition = Get-TransportRulePredicate SentToMemberOf
$condition.Addresses = @(( Get-DistributionGroup $NoSensitiveDGName ))
$action1 = Get-TransportRuleAction RemoveHeader
$action1.MessageHeader = "Disposition-Notification-To"
$action2 = Get-TransportRuleAction RemoveHeader
$action2.MessageHeader = "Read-Receipt-To"
New-TransportRule -Name "RemoveReadReceipt1" -Conditions @($condition) -Action @($action1) -Enabled: $true
New-TransportRule -Name "RemoveReadReceipt2" -Conditions @($condition) -Action @($action2) -Enabled: $true