Exchange 2013 routing
Az elozo két bejegyzéshez kapcsolódóan a mostani is a transzportról, a levéltovábbításról fog szólni. Az Exchange Server 2013 esetében az útválasztás is átalakult. Nem meglepo módon ennek is a hátterében az architektúrális változás, valamint a szerepkörök átalakulása áll.
Exchange Server 2007 / 2010 routing
Exchange Server 2007 / 2010 esetében least-cost routing (a legkisebb költségu útválasztás) van. Ahol a költséget az Active Directory határok között levo Site-Link kapcsolatok határozzák meg.
Nézzünk erre egy példát:
Jellemzok:
- Négy AD telephely van
- SiteA telephelyen van egy DAG aminek két szerver a tagja, valamint van egy önálló kiszolgáló ami nem DAG tag
- SiteA és SiteB között van egy AD SiteLink, aminek a költsége 2
- SiteB és SiteD között van egy AD SiteLink, aminek a költsége 2
- SiteA és SiteC között van egy AD SiteLink, aminek a költsége 1
- SiteC és SiteD között van egy AD SiteLink, aminek a költsége 1
- Mindegyik Exchange kiszolgáló 2010-es
Vajon ha SiteD-n levo felhasználó SiteA-n levo felhasználónak szeretne egy levelet küldeni akkor mi fog történni? Logikus lenne azt képzelni, hogy SiteD-n levo Exchange kiszolgáló a SiteC-re küldi eloször, majd SiteC fogja a levelet SiteA-ra kézbesíteni. De nem ez történik. (az eredeti publikációba itt sajtóhiba került. Cérnabának köszönöm az észrevételt)
Azért gondolhatnánk joggal ezt, mert SiteD és SiteC telephely-kapcsolat költsége 1, míg SiteD és SiteB telephely-kapcsolatának nagyobb az értéke, értsd drágább.
Helyesen azonban ez történik: SiteD-n levo kiszolgáló megpróbálja SiteA telephelyen levo Exchange kiszolgálónak kézbesíteni a levelet. Ha nem sikerül, akkor a levelet a célkiszolgálóhoz legközelebb próbálja eljuttatni ami a fenti példa esetében SiteB vagy SiteC lehet. Azonban itt használjuk a least-cost routing funkciót és az alacsonyabb költségu irányt választjuk. Tehát SiteC-re lesz a levél továbbítva, SiteB-re soha nem továbbítjuk azt. Általános megállapítás: a least-cost routing a back-off esemény idején lép életbe.
Ha azt szeretnénk, hogy SiteD, SiteA-ra úgy küldjön levelet, hogy az mindig SiteC-n menjen keresztül, akkor SiteC-t úgynevezett HUB Site-ként kell konfigurálni. Bovebb információ: Configure a Hub Site
Mellékszál, de mi történne akkor ha SiteB-t neveznénk ki HUB telephelyként? Vajon akkor átmenne a levél SiteB-n függetlenül attól, hogy annak az iránynak magasabb a költsége? A válasz az, hogy nem. A least-cost route itt is játszik.
Kb. megállapítottuk azt, hogy a levél milyen úton megy. Most gondolkodjunk egy kicsit azon, hogy a cél telephelyen mi fog történni, melyik Exchange kiszolgálónak fogjuk küldeni a levelet? Vegyük észre, hogy SiteA telephelyen (cél telephely) három Exchange kiszolgálónk van. Melyiknek fogja SiteD telephelyen levo Exchange kiszolgáló kézbesíteni a levelet?
A küldo Exchange kiszolgáló készít egy listát a vele azonos foverziójú szerverekrol és azok közül véletlenszeruen választ egyet, majd megpróbálja kézbesíteni a levelet. Fontos, hogy foverzióról beszélünk, Exchange Server 2010 csak Exchange Server 2010-nek, Exchange Server 2007 csak Exchange Server 2007-nek fogja küldeni a levelet.
Tehát random.
Exchange Server 2013 routing
Nézzük ugyanezt Exchange Server 2013-al:
Jellemzok:
- Négy AD telephely van
- SiteA telephelyen van egy DAG aminek két szerver a tagja, valamint van egy önálló kiszolgáló ami nem DAG tag
- SiteA és SiteB között van egy AD SiteLink, aminek a költsége 2
- SiteB és SiteD között van egy AD SiteLink, aminek a költsége 2
- SiteA és SiteC között van egy AD SiteLink, aminek a költsége 1
- SiteC és SiteD között van egy AD SiteLink, aminek a költsége 1
- Mindegyik Exchange kiszolgáló 2013-as
A kérdés ugyanaz. Ha SiteD-n levo postaládából SiteA-n levo postaládába küldünk levelet, akkor mi a levéltovábbítás útja? A helyes válasz itt a szokásos tanácsadói válasz: az attól függ. Míg az Exchange Server 2010 esetében random választottunk egyet a cél telephely kiszolgálói között, addig Exchange Server 2013 esetében függ attól, hogy a postaláda hol helyezkedik el.
Egy új fogalom jelenik meg: delivery group. A delivery group az, ahova továbbítjuk a levelet. A delivery group lehet egy DAG, egy Mailbox szerver vagy egy AD telephely. Ha:
- a postaláda egy DAG védett postaláda adatbázisban van, akkor a delivery group a DAG lesz
- a postaláda egy DAG által nem védett postaláda adatbázisban van, akkor a delivery group a Mailbox szerver lesz
- két módon lehet egy postaláda nem DAG védett. Standalone mailbox szerveren van az adatbázis, vagy a mailbox szerver tagja egy DAG-nak, de az adott postaláda adatbázis nincs replikálva
- back-off esemény van, akkor a delivery group egy AD telephely a least-cost routing alapján
Tehát a fentieknek megfeleloen, ha a SiteA telephelyen levo postaláda a DAG-on van, akkor a levelet a SiteD telephelyrol a DAG kiszolgáló valamelyik tagjának (random) fogjuk elküldeni. Ha a Standalone kiszolgálón van, akkor pedig annak küldjük a levelet. Okos dolog ez.
Hub telephely, least-cost routing kiválasztás pontosan ugyanaz mint eddig.
De miért a változás?
Minden változásnak általában van valami fo mozgató rugója. Nem célszeru, ha csak öncélúan változtatunk valamit. Ennek a változtatásnak is megvan a maga oka. Nézzük meg most ezt.
Exchange Server 2007-ben jelent meg eloször a mai DAG-ban is használt úgy nevezett Continues Replication. Ez teszi lehetové azt, hogy az adatbázisokat replikáljuk. A Continues Replication a tranzakciós naplóállományok átmásolása az aktív másolatról a passzív másoltra, majd annak visszajátszása az adatbázisba a passzív másolaton. Azonban ez felvet egy dilemmát. A dilemma a következo: mi történjen abban az esetben, ha az aktív másolatot tartalmazó kiszolgáló leállt és a passzív másolaton hiányoznak tranzakciós logok? Itt két lehetoség van elméletileg:
- a hiányos passzív másolatot aktívvá tesszük – ez azt jelenti, hogy az adatbázis újra elérheto lesz, DE biztosan adatvesztés történik
- a hiányos passzív másolatot nem aktiváljuk – ebben az esetben szolgáltatás kiesés történik, ugyanis az adatbázis dismounted állapotban van, a felhasználók nem érik el a szolgáltatást
A fenti két lehetoség az elmélet. A gyakorlatban ez megint attól függ, hogy hány log hiányzik. Az alapértelmezett beállítások esetében, ha:
- 6 vagy annál kevesebb tranzakciós log hiányzik, akkor felcsatoljuk az adatbázist
- 6-nál több tranzakciós log hiányzik, akkor nem csatoljuk fel az adatbázist
Minden mailbox adatbázisnak van egy AutoDatabaseMountDial értéke. Ezzel szabályozhatjuk azt, hogy hány log hiányzását engedjük meg. Ennek a tulajdonságnak a következo értékei lehetnek:
- LossLess – a megengedett veszteség 0 log
- GoodAvailability – 6 tranzakciós log
- BestAvailability – 12 tranzakciós log
- BestEffort – bármennyi log hiányozhat
Az alapértelmezett beállítás a GoodAvailability:
De mi történik a hiányzó logokkal? Alapértelmezésben 6MB-nyi tranzakciót elvesztünk? Nem teljesen. Ennek a hatásnak a csökkentésére lett kifejlesztve az úgynevezett Transport Dumpster az Exchange Server 2007-ben, ami helyet kapott az Exchange Server 2010-ben is.
A Hub-Transport kiszolgáló az Exchange Server 2007 és 2010 esetében a TransportDumpster területen tárolja a kézbesített leveleket. A Transport Dumpster a queue adatbázis egy speciális táblájában tárolja ezeket a leveleket. Tehát, miután kézbesítette, még megtartja. Felkészülve a veszteséges failover eseményekre. Ugyanis amikor veszteséges failover (bármi amikor hiányzik log) történik, akkor a Mailbox szerepkör és a Hub-Transport szerepkör igazi csapatjátékos. A Mailbox szerver a Hub-Transport szervertol elkéri az elvesztett logokhoz tartozó, már kézbesített leveleket. Ezeket a Hub-Transport szerver a Transport Dumpster-bol újra kézbesíti, így hiába is vesztek el a logok, valójában a levelek meglesznek. Ügyes, nem? Ehhez csak két dolgot kell hozzáfuzni:
- nem minden tranzakció levél – ha egy új mappát, egy új névjegyet hozok létre, az is egy tranzakcó ami a tranzakciós naplóba bekerül, de a Transport Dumpster-be nem. Így hiába is a Transport Dumpster, veszteséges failover esetében minden ami a Transport Dumpster-ben nincs bent, az bizony tényleges adatvesztés.
- a Transport Dumpster határa az Active Directory telephely – a Mailbox szerver csak a saját AD telephelyén belül levo Hub-Transport kiszolgálókhoz fordul
Ne feledjük a fenti muködési mód az Exchange Server 2007 és 2010-re igaz. Exchange Server 2013 esetében a Transport Dumpster funkciót a SafetyNet nevu új funkció váltja fel.
A SafetyNet célja a garantált levélkézbesítés, hasonló módon mint a Transport Dumpster. A Transport Dumpster legnagyobb hátránya az AD telephelyhez való kötodés. A SafetNet hatóköre azonban a delivery group és nem az AD telephely. Gondoljunk csak azokra a DAG kiszolgálókra amik eltéro AD telephelyen vannak és AD telephelyeken átnyúló veszteséges failover történik.
Mindkét telephelyen van 1-1 Hub-Transport, rajta a Transport Dumpster amit nem replikálunk. Ha a SiteB-re történik egy veszteséges failover, akkor csak a SiteB-n levo Transport Dumpster-bol történik a levél újraküldése. Nincs rá garancia, sot nagyon is valószínu, hogy a levelek nem lesznek bent abban a Transport Dumpster-ben.
Mivel a SafetyNet a Delivery Group határához igazodik, ezért a fenti anomália nem fordulhat elo. A delivery group bevezetésének legfontosabb oka ez.
Végszó
Az Exchange Server 2013 esetében a garantált levélkézbesítés kialakítása volt az egyik legfontosabb cél a Transport funkciók átalakításakor. Nem is csoda, hiszen a szolgáltatásunkban (Office365) pénz visszafizetési garancia terhe mellett vállaljuk a szolgáltatást. Az egyik legnagyobb újdonság a Delivery Group bevezetése és a SafetyNet ehhez történo igazítása. A SafetyNet pontos muködését egy késobbi bejegyzésben közelebbrol is megnézzük, ígérem.
Kinek van ilyen komplikált Exchange architektúrája? Lehet, hogy hazánkban a legtöbb Exchange rendszer egy telephelybol áll. Ettol függetlenül érteni, hogy mi hogyan muködik, nem hasztalan.