A modern üzleti környezetben az információhoz való folyamatos hozzáférés alapvető fontosságú. Az e-mail kommunikáció, mint az egyik legkritikusabb üzleti alkalmazás, nem engedheti meg magának a leállást. Az Exchange Server, mint a Microsoft vezető üzenetküldő platformja, éppen ezért kiemelt figyelmet fordít a magas rendelkezésre állásra és a katasztrófa-helyreállításra. Ezen a területen a Database Availability Group (DAG) technológia jelenti az Exchange Server gerincét, biztosítva az adatok folyamatos elérhetőségét és védelmét még súlyos hardverhibák vagy akár teljes adatközpont-kiesés esetén is.
A DAG bevezetése az Exchange Server 2010-ben forradalmasította az Exchange környezetek magas rendelkezésre állásának megközelítését. Előtte a cluster megoldások bonyolultabbak voltak, és nem biztosítottak ilyen szintű integrált adatbázis-replikációt. A DAG lényegében egy magas rendelkezésre állású és helyreállítási keretrendszer, amely lehetővé teszi az Exchange Server adatbázisok másolatainak létrehozását és fenntartását több kiszolgálón. Ezáltal, ha egy kiszolgáló vagy egy adatbázis meghibásodik, a felhasználók továbbra is hozzáférhetnek postaládáikhoz egy másik, működő másolaton keresztül, gyakorlatilag észrevétlenül.
A DAG alapvető célja az adatbázisok redundanciájának megteremtése. Ez azt jelenti, hogy minden egyes postaláda-adatbázisnak lehet több másolata, melyek különböző Exchange kiszolgálókon helyezkednek el. Ezek a másolatok folyamatosan szinkronban vannak tartva, biztosítva az adatok integritását és aktuális állapotát. A technológia középpontjában a Microsoft Cluster Service (MSCS) áll, melyet az Exchange Server speciális módon használ fel az adatbázisok és azok állapotának kezelésére.
A DAG alapvető működési elve és komponensei
Ahhoz, hogy megértsük a DAG teljes potenciálját, elengedhetetlen a működési elvének és kulcskomponenseinek részletes áttekintése. A DAG nem csupán egy szoftveres réteg, hanem egy komplex rendszer, amely több összetevő szoros együttműködésén alapul.
Postaláda-adatbázis másolatok (Mailbox Database Copies)
A DAG legfontosabb eleme a postaláda-adatbázis másolata. Minden adatbázisnak lehet egy aktív másolata és egy vagy több passzív másolata.
- Aktív másolat: Ez az a másolat, amelyet a felhasználók éppen használnak. Az összes írási művelet ide történik, és ez a másolat tartalmazza a legfrissebb adatokat. Egy DAG-on belül egy adott időpontban csak egy aktív másolat létezhet egy adatbázisból.
- Passzív másolat: Ezek az aktív másolat pontos másolatai, amelyek készen állnak arra, hogy átvegyék az aktív szerepét hiba esetén. A passzív másolatok folyamatosan fogadják az aktív másolatból származó tranzakciós naplókat, és visszajátsszák azokat, hogy szinkronban maradjanak. Amikor egy passzív másolat teljesen szinkronban van az aktívval, az egészségesnek minősül.
Az adatbázis másolatok számát az üzleti igények és a rendelkezésre állási célok határozzák meg. Minél több másolat van, annál nagyobb a redundancia, de annál több erőforrást is igényel a rendszer.
Tranzakciós naplók és replikáció
A DAG működésének alapja a folyamatos replikáció (Continuous Replication). Az Exchange Server minden módosítást, legyen az egy új e-mail küldése, egy naptárbejegyzés módosítása vagy egy elem törlése, először tranzakciós naplóba ír. Ezek a naplófájlok rendkívül fontosak, mivel tartalmazzák az adatbázisban történt összes változást.
- Napló szállítás (Log Shipping): Amikor az aktív adatbázis tranzakciós naplókat hoz létre, ezek a naplófájlok automatikusan átmásolódnak az összes passzív másolatot tároló kiszolgálóra. Ez a folyamat szinte valós időben történik.
- Napló visszajátszás (Log Replay): Miután a passzív kiszolgáló megkapta a naplófájlokat, a beépített replikációs szolgáltatás visszajátssza azokat a helyi passzív adatbázisba. Ez biztosítja, hogy a passzív másolat állapota megegyezzen az aktív másolatéval.
A replikációs folyamat rendkívül robusztus és hatékony. Hiba esetén a rendszer képes felismerni a hiányzó naplókat, és automatikusan pótolni azokat. A hálózati sávszélesség kritikus tényező a replikáció hatékonyságában, különösen több másolat vagy nagyméretű adatbázisok esetén.
Quórum modell és Tanúsító szerver (Witness Server)
A DAG, mint minden Windows Server Failover Cluster (WSFC) alapú megoldás, egy quórum mechanizmust használ a klaszter tagjainak és az erőforrások állapotának meghatározására. A quórum biztosítja, hogy a klaszter csak akkor működjön, ha a tagok többsége elérhető, ezzel elkerülve az „agyhalál” (split-brain) forgatókönyveket, amikor a klaszter több független részre oszlik, és mindegyik azt hiszi, hogy ő az aktív.
- Páratlan számú DAG tag (Node Majority): Ha a DAG tagok száma páratlan (pl. 3 vagy 5 kiszolgáló), a quórum Node Majority módban működik. Ahhoz, hogy a klaszter működőképes legyen, a tagok több mint felének online állapotban kell lennie. Például egy 3 tagú DAG esetén 2 tagnak kell elérhetőnek lennie.
- Páros számú DAG tag és Tanúsító szerver (Node and File Share Majority): Ha a DAG tagok száma páros (pl. 2, 4 vagy 6 kiszolgáló), szükség van egy kiegészítő erőforrásra, a Tanúsító szerverre (Witness Server). Ez általában egy különálló fájlkiszolgáló, amelyen egy megosztott mappa található. Ez a megosztott mappa „szavazatként” funkcionál, így a klaszternek lesz egy páratlan számú szavazata. Egy 2 tagú DAG esetén a tanúsító szerver nélkül, ha az egyik tag kiesik, a másik nem tudja eldönteni, hogy ő az egyetlen életben maradt, vagy a hálózat szakadt meg. A tanúsító szerverrel együtt azonban már 1 tag + tanúsító szerver szavazata elegendő a quórumhoz.
A Database Availability Group (DAG) a Microsoft Exchange Server legfontosabb magas rendelkezésre állási és katasztrófa-helyreállítási technológiája, amely adatbázis-szintű redundanciát biztosít a tranzakciós naplók folyamatos replikációján keresztül, garantálva a felhasználói postaládák folyamatos elérhetőségét még szerverhibák vagy adatközpont-kiesés esetén is.
A tanúsító szerver kiválasztása kritikus. Ideális esetben ez egy különálló kiszolgáló, amely nem maga is DAG tag, és lehetőleg egy másik hibatartományban helyezkedik el, mint a DAG tagok. Ez biztosítja, hogy egy teljes adatközpont-kiesés esetén is legyen egy elérhető quórum szavazat.
DAG hálózatok
A DAG-ok hatékony működéséhez elengedhetetlen a megfelelő hálózati infrastruktúra. Két fő hálózati típus létezik egy DAG-on belül:
- MAPI hálózat: Ez az a hálózat, amelyet a kliensek (pl. Outlook) használnak az Exchange kiszolgálókhoz való csatlakozáshoz. Ezen a hálózaton keresztül történik a felhasználói forgalom.
- Replikációs hálózat: Ez a hálózat kizárólag az adatbázis replikációs forgalmát szolgálja ki (tranzakciós naplók szállítása és seeding). Erősen ajánlott, hogy ez a hálózat fizikai vagy logikai elkülönítést kapjon a MAPI hálózattól a teljesítmény és a biztonság optimalizálása érdekében. Ezáltal a replikációs forgalom nem terheli feleslegesen a kliensforgalmat, és fordítva.
Több replikációs hálózat is konfigurálható a redundancia növelése érdekében. Ha az egyik replikációs hálózat kiesik, a forgalom automatikusan átterelődik a másikra.
A DAG tervezése és implementációja
A DAG sikeres bevezetése alapos tervezést igényel, amely figyelembe veszi a szervezet igényeit, a rendelkezésre álló infrastruktúrát és a jövőbeli növekedési terveket.
Kapacitástervezés és méretezés
Mielőtt egy DAG-ot létrehoznánk, elengedhetetlen a kapacitástervezés. Ez magában foglalja a következőket:
- Postaládák száma és mérete: Hány felhasználó lesz, és mekkora lesz az átlagos postaláda méret? Ez közvetlenül befolyásolja a szükséges tárhelyet.
- IOPS (Input/Output Operations Per Second) igény: Az Exchange Server adatbázisok erősen I/O-intenzívek. Meg kell becsülni a szükséges IOPS-t a felhasználói profilok alapján, és ehhez méretezni a tárolórendszert.
- CPU és memória: Minden DAG tagnak elegendő processzor- és memóriateljesítménnyel kell rendelkeznie ahhoz, hogy ne csak az aktív, hanem potenciálisan a passzív adatbázisokat is kiszolgálja átvétel esetén.
- Hálózati sávszélesség: A replikációs forgalom jelentős lehet, különösen, ha nagy mennyiségű adat változik, vagy ha kezdeti seeding történik. Győződjünk meg arról, hogy a dedikált replikációs hálózat elegendő sávszélességgel rendelkezik.
A Microsoft Exchange Server Sizing Calculator egy rendkívül hasznos eszköz a kapacitástervezéshez, amely segít meghatározni a szükséges erőforrásokat a megadott paraméterek alapján.
Hálózati tervezés
A hálózati tervezés a DAG egyik legkritikusabb eleme. Ahogy említettük, a MAPI és replikációs hálózatok szétválasztása erősen ajánlott. Ez elérhető fizikai hálózati adapterek és kapcsolók szétválasztásával, vagy virtuális LAN-ok (VLAN-ok) használatával. Minden DAG tagnak rendelkeznie kell legalább két hálózati adapterrel: egy a MAPI hálózathoz és egy a replikációs hálózathoz.
- IP címek: Minden hálózati adapternek saját, statikus IP címmel kell rendelkeznie. A DAG-nak is szüksége van egy vagy több IP címre, amelyek a Cluster Administrative Access Point (CAAP) számára vannak fenntartva. Ezek az IP címek a DAG virtuális objektumához tartoznak az Active Directoryban, és lehetővé teszik a klaszter távoli kezelését.
- DNS regisztráció: Győződjön meg róla, hogy a DAG IP címei és a DAG tagok nevei megfelelően regisztrálva vannak a DNS-ben.
Tanúsító szerver elhelyezése
A tanúsító szerver elhelyezése kulcsfontosságú, különösen több adatközpontot magában foglaló DAG esetén.
- Különálló kiszolgáló: Soha ne helyezze a tanúsító szervert egy DAG tagra.
- Másik hibatartomány: Ha lehetséges, helyezze a tanúsító szervert egy harmadik, különálló adatközpontba vagy egy olyan helyre, amely független a DAG tagok adatközpontjaitól. Ez biztosítja, hogy egy teljes adatközpont-kiesés esetén is megmaradjon a quórum.
- Hálózati elérhetőség: A tanúsító szervernek folyamatosan elérhetőnek kell lennie az összes DAG tag számára a replikációs hálózaton keresztül.
A tanúsító szervernek nem kell Exchange Servernek lennie. Egy egyszerű Windows fájlkiszolgáló is tökéletesen megfelel a célnak.
Tárhely tervezés
A DAG-ok rugalmasak a tárhely tekintetében. Használható Direct Attached Storage (DAS), Storage Area Network (SAN) vagy akár Network Attached Storage (NAS) is, bár utóbbi kevésbé elterjedt Exchange környezetekben.
- JBOD (Just a Bunch Of Disks): Az Exchange Server 2010 óta a JBOD konfigurációk (helyi merevlemezek) is támogatottak a DAG-okkal. Ez csökkentheti a költségeket, de a lemezek szintjén nem biztosít hardveres redundanciát, ezért a DAG-nak kell gondoskodnia a replikációról.
- SAN/NAS: A SAN vagy NAS megoldások hardveres redundanciát biztosítanak a lemezszinten (RAID), ami tovább növeli a megbízhatóságot. Fontos, hogy a tárolórendszer megfelelő IOPS teljesítményt nyújtson.
Minden adatbázis másolatnak saját, dedikált lemezterületre van szüksége a DAG tagokon.
A DAG létrehozásának lépései
A DAG létrehozása viszonylag egyszerű folyamat, de a sikeres működéshez az előfeltételeknek teljesülniük kell.
- Előfeltételek:
- Minden DAG tagnak ugyanazon az Exchange Server verziónak és kumulatív frissítésnek (CU) kell futnia.
- A Windows Server Failover Clustering funkciót telepíteni kell minden DAG tagra.
- Minden DAG tagnak ugyanabban az Active Directory tartományban kell lennie.
- A DAG IP címét előre le kell foglalni.
- A tanúsító szervernek és a megosztott mappának léteznie kell (páros számú tag esetén).
- DAG létrehozása:
A DAG létrehozható az Exchange Admin Center (EAC) felületén vagy a PowerShell segítségével. A PowerShell használata rugalmasabb és automatizálhatóbb.
New-DatabaseAvailabilityGroup -Name DAG01 -WitnessServer FS01 -WitnessDirectory C:\DAGWitness -DatabaseAvailabilityGroupIpAddresses 192.168.1.100Ez a parancs létrehozza a DAG01 nevű DAG-ot, beállítja az FS01 szervert tanúsító szervernek, megadja a tanúsító könyvtárat, és hozzárendeli a megadott IP címet.
- Postaláda-kiszolgálók hozzáadása a DAG-hoz:
Miután a DAG létrejött, hozzá kell adni a postaláda-kiszolgálókat tagként.
Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer EXCH01Ezt a parancsot minden hozzáadni kívánt Exchange postaláda-kiszolgálóra meg kell ismételni.
- Adatbázis másolatok hozzáadása:
A kiszolgálók hozzáadása után hozzáadhatók az adatbázis másolatok. Ez a lépés indítja el a replikációs folyamatot.
Add-MailboxDatabaseCopy -Identity MBXDB01 -MailboxServer EXCH02 -ActivationPreference 2Ez a parancs hozzáadja az MBXDB01 adatbázis másolatát az EXCH02 szerverre, és beállítja az aktiválási preferenciát 2-re (az alacsonyabb szám a magasabb preferenciát jelenti).
Az aktiválási preferenciát minden másolatra be kell állítani. Az aktív másolat preferenciája mindig 1. Ez a beállítás segít a rendszernek eldönteni, melyik passzív másolatot aktiválja hiba esetén.
- Hálózati beállítások konfigurálása:
A DAG hálózatok konfigurálása kulcsfontosságú. Győződjön meg róla, hogy a MAPI és replikációs hálózatok megfelelően vannak beállítva és priorizálva.
Set-DatabaseAvailabilityGroupNetwork -Identity DAG01\DAGNetwork01 -ReplicationEnabled $true Set-DatabaseAvailabilityGroupNetwork -Identity DAG01\DAGNetwork02 -ReplicationEnabled $falseEzek a parancsok lehetővé teszik vagy letiltják a replikációt az adott DAG hálózaton. Általában egy hálózatot dedikálnak a replikációra, a többit pedig a MAPI forgalomra.
A DAG kezelése és karbantartása
A DAG bevezetése után a rendszeres felügyelet és karbantartás elengedhetetlen a folyamatos, magas rendelkezésre állás biztosításához.
Monitorozás
A DAG állapotának monitorozása kulcsfontosságú. Számos eszköz áll rendelkezésre ehhez:
- Exchange Admin Center (EAC): Az EAC grafikus felületén keresztül könnyen ellenőrizhető a DAG és az adatbázis másolatok állapota. Látható, melyik adatbázis aktív, melyek a passzívak, és milyen az egészségi állapotuk.
- PowerShell: A PowerShell parancsmagok részletesebb információkat nyújtanak és automatizálhatók.
-
Get-DatabaseAvailabilityGroup -Identity DAG01 -Status | fl -
Get-MailboxDatabaseCopyStatus -Identity MBXDB01\* | fl -
Test-ReplicationHealth -Identity EXCH01
Ezek a parancsok információt szolgáltatnak a DAG tagok, adatbázis másolatok és a replikációs egészség állapotáról.
-
- Teljesítményfigyelő (Performance Monitor): A Windows Teljesítményfigyelővel nyomon követhetők a kulcsfontosságú teljesítménymutatók, mint például a lemez I/O, hálózati forgalom, CPU és memória használat, amelyek mind befolyásolják a DAG teljesítményét.
- Harmadik féltől származó monitoring eszközök: Számos monitoring megoldás létezik, amelyek specifikusan az Exchange és DAG környezetek felügyeletére lettek kifejlesztve, riasztásokat küldve problémák esetén.
Adatbázis másolatok kezelése
Az adatbázis másolatok kezelése magában foglalja a felfüggesztést, folytatást és eltávolítást.
- Felfüggesztés (Suspend): Karbantartási feladatok, például operációs rendszer frissítések vagy hardvercsere előtt ajánlott felfüggeszteni az adatbázis másolatok replikációját.
Suspend-MailboxDatabaseCopy -Identity MBXDB01\EXCH01 -ActivationOnlyAz `-ActivationOnly` kapcsoló megakadályozza az adatbázis automatikus aktiválását a megadott szerveren, de továbbra is engedélyezi a replikációt.
- Folytatás (Resume): A karbantartás befejezése után a replikációt folytatni kell.
Resume-MailboxDatabaseCopy -Identity MBXDB01\EXCH01 - Eltávolítás (Remove): Ha egy adatbázis másolatra már nincs szükség, vagy egy szerver kikerül a DAG-ból, a másolat eltávolítható.
Remove-MailboxDatabaseCopy -Identity MBXDB01\EXCH01Fontos, hogy az eltávolítás után fizikailag is töröljük az adatbázis és napló fájlokat a kiszolgálóról.
Tervezett karbantartás
A DAG lehetővé teszi a tervezett karbantartási feladatok végrehajtását anélkül, hogy a felhasználók észrevennék a szolgáltatás megszakadását.
- Szerver frissítések: Mielőtt egy DAG tagot frissítenénk (pl. Windows Update, Exchange CU), először vigyük át az összes aktív adatbázist más tagokra, majd állítsuk karbantartási módba a szervert.
Move-ActiveMailboxDatabase -Server EXCH01 -ActivateOnServer EXCH02 Start-ServerMaintenance -Server EXCH01 -BypassDrainOnAutoDagA karbantartás befejezése után kapcsoljuk ki a karbantartási módot, és szükség esetén mozgassuk vissza az adatbázisokat.
Stop-ServerMaintenance -Server EXCH01 - Adatbázis áthelyezés (Switchover): Az adatbázisok aktív szerepét bármikor át lehet helyezni egy másik DAG tagra manuálisan, például terheléselosztás vagy tervezett karbantartás céljából.
Move-ActiveMailboxDatabase -Identity MBXDB01 -ActivateOnServer EXCH02
Katasztrófa-helyreállítás DAG-okkal
A DAG elsődleges célja a magas rendelkezésre állás, de rendkívül hatékony eszköz a katasztrófa-helyreállításban is, különösen több adatközpontot felölelő (multi-site) konfigurációk esetén.
Adatközpont-aktiválás (Datacenter Activation)
Egy teljes adatközpont kiesése esetén a DAG képes helyreállni egy másik adatközpontban, feltéve, hogy a DAG tagok és a tanúsító szerver megfelelően vannak elosztva. A folyamat a következő:
- Meghibásodott adatközpont elszigetelése: Győződjünk meg róla, hogy a meghibásodott adatközpontban lévő DAG tagok nem próbálkoznak a quórum megszerzésével.
- DAG tagok kényszerítése új quórumra: A megmaradt adatközpontban lévő DAG tagokat kényszeríteni kell a klaszter elindítására.
Stop-DatabaseAvailabilityGroup -Identity DAG01 -ActiveDirectorySite SiteAEz a parancs leállítja a DAG-ot a SiteA-ban, jelezve, hogy az adatközpont kiesett.
Restore-DatabaseAvailabilityGroup -Identity DAG01 -ActiveDirectorySite SiteBEz a parancs elindítja a DAG-ot a SiteB-ben, és megpróbálja a lehető legtöbb adatbázist aktiválni.
- Adatbázisok aktiválása: Miután a DAG elindult az új adatközpontban, manuálisan aktiválni kell az adatbázisokat.
Move-ActiveMailboxDatabase -Identity MBXDB01 -ActivateOnServer EXCH03 -MountDialOverride BestAvailability
Fontos megjegyezni, hogy a multi-site DAG-okhoz gondos tervezés szükséges a hálózati késleltetés, a sávszélesség és a tanúsító szerver elhelyezése szempontjából.
DAC (Datacenter Activation Coordination) mód
Az Exchange Server 2010 SP1-től kezdve elérhető a Datacenter Activation Coordination (DAC) mód. Ez egy opcionális, de erősen ajánlott beállítás a multi-site DAG-okhoz. A DAC mód megakadályozza az „agyhalál” forgatókönyveket egy adatközpont-kiesés esetén, és leegyszerűsíti a helyreállítási folyamatot.
A DAC mód bekapcsolásával a DAG automatikusan kezeli a klaszter tagok leállítását és indítását adatközpont-kiesés esetén, csökkentve a manuális beavatkozás szükségességét és a hibák kockázatát. A DAC mód bekapcsolása előtt győződjön meg arról, hogy a DAG tagok páros száma van, és a tanúsító szerver megfelelően van konfigurálva.
Set-DatabaseAvailabilityGroup -Identity DAG01 -DatacenterActivationMode DagOnlyA DAC mód megköveteli, hogy minden DAG tagnak legalább két hálózati adaptere legyen, és a hálózatok megfelelően legyenek konfigurálva.
DAG-ok és biztonsági mentés
Bár a DAG magas rendelkezésre állást és adatbázis szintű redundanciát biztosít, nem helyettesíti a hagyományos biztonsági mentést. A DAG védelmet nyújt hardverhibák, adatbázis sérülések és szerver kiesések ellen, de nem véd a logikai hibák, például véletlen törlések vagy rosszindulatú szoftverek okozta adatsérülések ellen.
A biztonsági mentést mindig az aktív adatbázis másolatról kell elvégezni. Az Exchange beépített VSS (Volume Shadow Copy Service) integrációja lehetővé teszi az online biztonsági mentést, amely nem befolyásolja a felhasználói hozzáférést. A legtöbb modern biztonsági mentési szoftver támogatja az Exchange DAG-okat, és képes felismerni az aktív másolatot a mentés végrehajtásához.
Haladó DAG koncepciók és funkciók
Az Exchange Server folyamatosan fejlődik, és a DAG funkciói is bővültek az idők során.
AutoDagAutoReseed
Az Exchange Server 2013-tól kezdve elérhető az AutoDagAutoReseed funkció, amely automatizálja a sérült adatbázis másolatok újrakonfigurálását és újbóli seedelését. Ha egy lemez meghibásodik, és az adatbázis másolat olvashatatlanná válik, az AutoDagAutoReseed automatikusan elindítja a folyamatot egy tartalék lemezre, minimalizálva a manuális beavatkozás szükségességét.
Ehhez a funkcióhoz előre konfigurált tartalék lemezterületre van szükség minden DAG tagon. A lemezeket az Exchange által elvárt módon kell elnevezni és formázni. Az AutoDagAutoReseed jelentősen javítja a helyreállítási időt (RTO) lemezhibák esetén.
Set-DatabaseAvailabilityGroup -Identity DAG01 -AutoDagAutoReseedEnabled $trueKésleltetett adatbázis másolatok (Lagged Database Copies)
A késleltetett adatbázis másolatok olyan passzív másolatok, amelyek szándékosan késleltetik a tranzakciós naplók visszajátszását. Ez védelmet nyújthat a logikai sérülések, például a véletlen törlések vagy a rosszindulatú szoftverek által okozott adatsérülések ellen. Ha egy hiba történik az aktív adatbázison, ami azonnal replikálódna az összes passzív másolatra, egy késleltetett másolat még tartalmazhatja az adatokat a hiba előtti állapotban.
Add-MailboxDatabaseCopy -Identity MBXDB01 -MailboxServer EXCH04 -ReplayLagTime 1.00:00:00 -ActivationPreference 3Ez a parancs létrehoz egy másolatot 24 órás visszajátszási késleltetéssel.
Fontos figyelembe venni, hogy a késleltetett másolatok nagyobb adatvesztést (RPO) jelenthetnek egy hiba esetén, mivel az utolsó X órában történt változások elveszhetnek. A késleltetési időt gondosan meg kell választani az üzleti igények és a helyreállítási célok alapján.
Replay Lag Manager
Az Exchange Server 2013-tól kezdve a Replay Lag Manager automatikusan aktiválhatja a késleltetett másolatokat bizonyos feltételek teljesülése esetén. Például, ha az aktív adatbázis és az összes nem késleltetett passzív másolat meghibásodik, a Replay Lag Manager megpróbálja aktiválni a késleltetett másolatot, még akkor is, ha az nincs teljesen szinkronban.
Ez a funkció további védelmet nyújt, de fontos, hogy a késleltetett másolatok kezelését és monitorozását kiemelten kezeljük.
Gyakori problémák és hibaelhárítás
Bár a DAG robusztus technológia, előfordulhatnak problémák. A hatékony hibaelhárítás kulcsfontosságú a gyors helyreállításhoz.
Replikációs hibák
A replikációs hibák a leggyakoribb problémák közé tartoznak.
- Okok: Hálózati problémák (sávszélesség, késleltetés, szakadozás), lemez I/O problémák, sérült naplófájlok, biztonsági mentési szoftverek interferenciája.
- Hibaelhárítás:
- Ellenőrizze a hálózati kapcsolatot a DAG tagok között.
- Használja a
Test-ReplicationHealthparancsmagot.
- Ellenőrizze az eseménynaplókat (Application és System logs) a DAG tagokon.
- Indítsa újra az Exchange Replication szolgáltatást.
- Szükség esetén végezzen teljes seedinget (lásd alább).
Quórum problémák
A quórum problémák akkor merülnek fel, ha a klaszter nem tudja elérni a szavazatok többségét.
- Okok: Túl sok DAG tag kiesése, tanúsító szerver elérhetetlensége.
- Hibaelhárítás:
- Ellenőrizze a tanúsító szerver elérhetőségét és a fájlmegosztás jogosultságait.
- Győződjön meg róla, hogy a DAG tagok közötti hálózati kapcsolat stabil.
- Szükség esetén manuálisan kényszerítse a klaszter online állapotba kerülését (csak végső megoldásként, és csak akkor, ha biztos abban, hogy a többi tag nem aktív).
Adatbázis aktiválási hibák
Előfordulhat, hogy egy adatbázis nem aktiválódik automatikusan egy hiba után.
- Okok: Nem egészséges passzív másolat, nem megfelelő aktiválási preferenciák, lemezterület hiánya, Mount Dial Override beállítások.
- Hibaelhárítás:
- Ellenőrizze a
Get-MailboxDatabaseCopyStatuskimenetét.
- Győződjön meg róla, hogy a célkiszolgálón van elegendő szabad lemezterület.
- Próbálja meg manuálisan aktiválni az adatbázist a
Move-ActiveMailboxDatabaseparancsmaggal, szükség esetén a `-MountDialOverride` paraméterrel.
- Ellenőrizze a
Seeding (Adatbázis másolat kezdeti szinkronizálása)
A seeding a folyamat, amely során egy új adatbázis másolatot hoznak létre, vagy egy sérült másolatot szinkronizálnak az aktív adatbázissal. Ez lehet automatikus (AutoDagAutoReseed esetén) vagy manuális.
- Manuális Seeding:
Update-MailboxDatabaseCopy -Identity MBXDB01\EXCH02 -CatalogOnlyA `-CatalogOnly` kapcsoló csak a tartalom index katalógusát seedeli, ami gyorsabb lehet. Teljes seedinghez el kell távolítani a másolatot, és újra hozzáadni, vagy használni a
Update-MailboxDatabaseCopyparancsmagot kapcsoló nélkül.
- Problémák a seedinggel: Hálózati problémák, jogosultsági problémák, tűzfalak, lemezterület hiánya.
Bevált gyakorlatok DAG-okhoz
A DAG-ok optimális működéséhez és a maximális rendelkezésre állás eléréséhez érdemes betartani néhány bevált gyakorlatot.
- Dedikált hálózatok: Mindig használjon külön hálózatokat a MAPI és a replikációs forgalomhoz. Ez javítja a teljesítményt és a megbízhatóságot.
- Tanúsító szerver redundancia és elhelyezés: Páros számú DAG tag esetén gondoskodjon egy robusztus és elérhető tanúsító szerverről, lehetőleg egy harmadik hibatartományban. Ha a tanúsító szerver egyetlen pontja a meghibásodásnak, fontolja meg a DAC mód használatát.
- Rendszeres monitorozás: Aktívan figyelje a DAG és az adatbázis másolatok állapotát. Rendszeres
Test-ReplicationHealthfuttatás és a teljesítménymutatók ellenőrzése elengedhetetlen.
- Tesztelt átállások (Failover Testing): Rendszeresen tesztelje a tervezett és nem tervezett átállásokat. Ez segít azonosítani a potenciális problémákat, és biztosítja, hogy a csapat felkészült legyen egy valós vészhelyzetre.
- Megfelelő méretezés: Ne méretezze alul a DAG tagokat és a tárolórendszert. A megfelelő CPU, memória és I/O kapacitás létfontosságú a stabil működéshez.
- Exchange CU frissítések: Tartsa naprakészen az Exchange Server kumulatív frissítéseit. Ezek gyakran tartalmaznak hibajavításokat és teljesítménybeli fejlesztéseket.
- Dokumentáció: Dokumentálja részletesen a DAG konfigurációját, beleértve az IP címeket, hálózatokat, tanúsító szervert és az aktiválási preferenciákat.
- Biztonsági mentés: Ne feledje, hogy a DAG nem helyettesíti a biztonsági mentést. Rendszeresen készítsen biztonsági másolatot az aktív adatbázisokról.
- Active Directory Site elhelyezés: Több adatközpont esetén győződjön meg róla, hogy a DAG tagok az Active Directory megfelelő site-jaiban vannak, és a site-ok közötti kapcsolatok optimálisak.
- Szerepkörök szétválasztása: Bár az Exchange egyesített szerepköröket használ, a DAG tagoknak csak a Mailbox szerepkörrel kell rendelkezniük. A Edge Transport vagy Client Access szerepkörök telepítése ugyanarra a szerverre nem ajánlott a teljesítmény és a biztonság szempontjából.
A DAG evolúciója az Exchange Server verziókban
A DAG technológia az Exchange Server 2010-ben debütált, és azóta folyamatosan fejlődött, alkalmazkodva a változó infrastruktúra és üzleti igényekhez.
Exchange Server 2010
A 2010-es verzióban a DAG volt az első olyan integrált magas rendelkezésre állási megoldás, amely a Windows Server Failover Clusteringet használta az adatbázisok replikálásához. Ez jelentős előrelépést jelentett a korábbi, bonyolultabb cluster megoldásokhoz képest. Bevezette a folyamatos replikációt, a seedinget és az adatbázis másolatok koncepcióját.
Exchange Server 2013
Az Exchange 2013 továbbfejlesztette a DAG-ot, bevezetve az AutoDagAutoReseed funkciót, amely automatizálta a lemezhibák kezelését. Ezenkívül a DAC mód is kiforrottabbá vált, és a Replay Lag Manager is megjelent. A 2013-as verzióban az Exchange architektúrája is egyszerűsödött, egyesítve a korábbi Client Access és Hub Transport szerepköröket, ami megkönnyítette a DAG implementációját és kezelését.
Exchange Server 2016 és 2019
Az Exchange 2016 és 2019 tovább finomította a DAG működését, optimalizálva a teljesítményt és a stabilitást. Ezek a verziók a felhőhöz való közeledést is tükrözik, ahol a DAG technológia alapvető fontosságú az Office 365 Exchange Online szolgáltatásában is. A főbb fejlesztések a háttérben történtek, javítva a robusztusságot, a teljesítményt és a hibaelhárítási képességeket, de az alapvető DAG koncepciók változatlanok maradtak.
Az Exchange Server 2019-ben a DAG továbbra is a magas rendelkezésre állás sarokköve. A Microsoft folyamatosan fejleszti a technológiát, hogy megfeleljen a modern, hibrid és felhőalapú környezetek igényeinek, ahol a nulla állásidő és az azonnali helyreállítás elengedhetetlen.
Összességében a Database Availability Group (DAG) egy rendkívül kifinomult és hatékony technológia, amely lehetővé teszi az Exchange Server környezetek számára, hogy megfeleljenek a legszigorúbb rendelkezésre állási és katasztrófa-helyreállítási követelményeknek. A megfelelő tervezéssel, implementációval és folyamatos karbantartással a DAG biztosítja, hogy a felhasználók mindig hozzáférjenek postaládáikhoz, még a legváratlanabb események esetén is.