Nebudeme se zde příliš věnovat vlastnímu principu technologií DAG a CAS Array, ale pouze řešit omezení, problémy a nastavení pro danou topologii. Více informací o daných technologiích nalezneme na internetu, třeba na MS v High Availability and Site Resilience a Understanding Load Balancing in Exchange 2010.

Můj názor je, že DAG je věc, která dobře funguje, a až na pár detailů, které nejsou nikde moc popsané, je srozumitelná a jasná. Naproti tomu řešení CAS mezi Sites je velmi problematická a docela málo funkční oblast. Vypadá to, že nikdo v ní nemá moc jasno. Z různých míst jsem našel kusé informace, které třeba často dávaly smysl. Ale když jsem provedl praktický test, tak se ukázalo, že celá věc funguje jinak. Navíc MS mění chování i mezi různými verzemi Service Pack.

Tím chci také poznamenat, že neručím za všechny informace zde uvedené. Několikrát jsem myslel, že chápu funkčnost dané technologie, ale pak se při určité praktické situaci ukázalo, že to funguje jinak.

Pozn.: Níže uvedený popis je pro Exchange Server 2010 SP2 Enterprise. To má vliv například na možnosti, které se dají konfigurovat pomocí EMC.

Topologie

Různé příklady topologií dle Microsoftu, například v článku Database Availability Group Design Examples, jsou jistě zajímavé, ale kdo si je v našem prostředí může dovolit? Vyznačují se tím, že téměř vždy oddělují jednotlivé role, hlavně CAS a Mailbox. A potom také tím, že používají velké množství serverů, a i když máme více Site, tak v každé je umístěno několik serverů.

Zde se podíváme na mnohem střídmější topologii. Na Exchange serveru se vždy nachází všechny role. Máme centrálu v Praze, kde jsou dva Exchange servery (teoreticky by mohl být i jeden) a pak máme pobočku v Brně, kde je pouze jeden Exchange. A chceme řešit vysokou dostupnost jak v rámci primární Site, tak při výpadku serveru na pobočce. Tedy aby se veškerá data (mailboxy) nacházela na všech Exchange serverech a při nedostupnosti serveru na pobočce se klienti připojili do centrály.

Client Access Server (CAS) Array

Na Exchange 2010 se klienti nepřipojují přímo na mailbox server, ale přistupují přes Client Access Server. Uživatelova schránka je umístěna v určité databázi, tento údaj se nachází v AD u uživatelského účtu. Každá databáze má přiřazen nějaký doporučený CAS server, který uživatelé běžně využívají pro připojení. Pokud je tento server nedostupný, tak klient ztratí spojení. Proto je tu technologie CAS Array, kdy více serverů spojíme do jednoho pole.

Bohužel technologie CAS Array je udělána tak, že se může použít pouze v rámci Site. Takže pole můžeme vyrobit pouze v rámci centrály a při výpadku serveru na pobočce bude třeba provést manuální zásah.

Pro Load Balancing (CAS Array) v rámci pole můžeme využít HW nebo SW Load Balancer, NLB (Network Load Balancing, ten není kompatibilní s Failover Clusterem, takže jej nemůžeme použít, pokud máme CAS a Mailbox roli na stejném serveru a využíváme DAG) nebo DNS Round Robin. Zde využijeme nejlevnější a přitom funkční metodu DNS Round Robin. To znamená, že na interním DNS serveru vytvoříme nové jméno cas1.firma.local a pro něj několik A záznamů s IP adresou každého CAS (zde tedy pro 10.0.0.10 a 10.0.0.20).

Na Exchange serveru potom můžeme vyrobit CAS Array pouze příkazem v PowerShellu. Kde zadáme vytvořené DNS jméno (FQDN) a jméno Site, ve které se naše servery nachází, volitelně také jméno pole.

New-ClientAccessArray -Fqdn cas1.firma.cz -Site "Praha" -Name "cas1.firma.cz"

Do pole se automaticky zařadí CAS servery, které se nachází v uvedené Site. Jak vytvořené pole vypadá, se můžeme podívat dalším příkazem.

Get-ClientAccessArray

Name                Site                 Fqdn                           Members
----                ----                 ----                           -------
cas1.firma.local    Praha                cas1.firma.local               {Exch01, Exch02}

Pokud nyní vytvoříme novou databázi na serveru, který je členem pole, tak se jako adresa CAS serveru vloží adresa pole. Pokud máme již databázi vytvořenou, tak je tam uvedena adresa serveru. Podívat se na tuto hodnotu můžeme dalším příkazem.

Get-MailboxDatabase DB01 | FT Name, RpcClientAccessServer

Name                           RpcClientAccessServer
----                           ---------------------
DB01                           cas1.firma.local

Samozřejmě tuto hodnotu můžeme ručně změnit. To potřebujeme provést na existující databázi, jinak nám nebude fungovat CAS Load Balancing pro mailboxy v této databázi. A pokud by nám padnul jediný Exchange na pobočce, tak musíme provést tuto změnu na DB, která byla aktivní na pobočce, aby klienti nalezli nový server pro připojení v centrále.

Set-MailboxDatabase DB01 -RpcClientAccessServer CAS1.firma.local

Připojení Outlooku na CAS - různé Sites

CAS Array, spolu s dále popsaným DAGem, funguje bezproblémově v rámci jedné Site. Ale mnohem složitější je situace, která odpovídá naší topologii. Jde o to, jak Outlook získává konfiguraci v interní síti. Využívá se technologie Autodiscover, což je služba na CAS serveru, která nám vrátí informace pro konfiguraci. Ale nejprve klient musí zjistit jaký CAS má použít pro připojení k Autodiscover. V interní síti je první krok pohled do Active Directory, kde má každý CAS server uložen SCP záznam s cestou. K tomu se ale ještě připočítává vlastnost Site Affinity, kdy pokud existuje nějaký CAS ve stejné Site jako klient, tak se použije pouze tento (nebo náhodně některý, pokud jich je více).

Pokud získáme XML konfiguraci z Autodiscoveru, tak mimo různých adres je zde také údaj Server, který odpovídá hodnotě RpcClientAccessServer popisované výše. K tomuto serveru se Outlook snaží připojit pomocí RPC, ale opět nemusí využívat pouze tento. Pokud se podíváme, kam je náš Outlook připojen (kliknutím na ikonu Outlooku na liště vedle hodin Ctrl + pravé tlačítko, a volba Connection Status), tak jsou zde dva typy připojení Directory a Mail. A obě spojení nemusí směrovat na stejný server.

Podle výše uvedeného je pro naši topologii dost důležité, ke kterým Autodiscover serverům se může Outlook připojit. Pokud bude nedostupný náš jediný server na pobočce, tak má místní klient smůlu. Proto je potřeba se podívat na nastavení AutoDiscoverSiteScope pro jednotlivé servery.

Get-ClientAccessServer | FT Name, AutoDiscoverSiteScope

Name                         AutoDiscoverSiteScope
----                         ---------------------
Exch01                       {Praha}
Exch02                       {Praha}
Exch03                       {Brno}

A upravit jej, aby při výpadku měl klient k dispozici další server.

Set-ClientAccessServer Exch01 -AutoDiscoverSiteScope Praha, Brno

Bohužel, v naší topologii znamená výpadek serveru na pobočce, výpadek pro uživatele minimálně několik desítek minut. Databáze se nám díky DAGu v pořádku přepne, ale problém je s CASem. Nejprve musíme změnit nastavení hodnoty RpcClientAccessServer na databázi, aby klient z Autodiscoveru získal adresu serveru v centrále. Když ale zkusíme v Outlooku stáhnout novou konfiguraci (Test E-mail AutoConfiguration), tak se nám pořád nabízí starý server. Je to protože se xml soubor kešuje a nový se stahuje až po nějaké době. Ale i potom co se stáhnou nové údaje z Autodiscover (třeba po smazání kešovaného souboru v profilu uživatele), tak se nám Outlook hned nepřepne, ale trvá to třeba 20 minut. Přitom pokud vytvoříme nový profil v Outlooku, tak ten již korektně identifikuje server a hned máme dostupnou schránku.

Database Availability Group (DAG)

Pomocí CAS Array jsme řešili přístup klientů. Database Availability Group (DAG) nám řeší dostupnost dat/databáze. Jednoduše řečeno to funguje tak, že databáze je na jednom Exchange serveru aktivní a na ostatní, které jsou členy DAGu a je zde nastavena kopie, se provádí kopírování do neaktivní DB (to můžeme nastavit i s nějakým zpožděním). Pokud dojde k výpadku serveru, tak se stává aktivní některá z kopií, která je určena speciálním algoritmem. Přepínání řeší komponenta zvaná Active Manager. Jinak DAG běží na Mailbox serveru a je založen na Windows Failover Cluster. Vhodné je mít více mailbox databází a rozdělit, která je na kterém serveru aktivní, tím řešíme rozložení zátěže.

Pozn.: Přepíná databáze DAGu probíhá pouze při havárii, ne když si systém myslí, že jsme to udělali úmyslně. Například když provádíme update, který zastaví služby, tak se databáze nepřepne. Musíme to dopředu udělat sami.

Na rozdíl od CAS Array je již DAG oficiálně podporovaný i mezi servery v různých Site. Takže můžeme vytvořit jeden DAG pro naši topologii a do něj pak zařadit všechny DB. Je třeba si ale uvědomit princip failover clusteru, který řeší například situaci, kdy se rozpojí síť mezi centrálou a pobočkou, tak aby neběžely nezávisle systémy na obou stranách a pak nedošlo k nekonzistenci. Takže v tom případě funguje pouze jedna strana a druhá se vypne. Využívá se k tomu tzv. Quorum, podle kterého se rozhoduje, kdo bude běžet. Jednoduše jde o většinu. V našem případě máme 3 servery, takže 2 jsou potřeba pro vítězství a může být nedostupný pouze jeden (při sudém počtu se zapojí Fileshare Witness). Pokud nám padnou oba servery v centrále, tak se databáze nepřepne na server na pobočce, ale ten naopak přestane fungovat také.

Protože máme všechny role na jednom serveru (jinak by se mohl automaticky použít nějaký Hub Transport server), tak potřebujeme pro vytvoření DAGu specifikovat také Witness server. Jde vlastně o sdílený adresář na libovolném serveru (nedoporučuje se DC kvůli oprávněním), který by měl být v primární síti. Na Witness serveru musíme do skupiny lokálních administrátorů zařadit doménovou skupinu Exchange Trusted Subsystem. Sice, když máme 3 Mailbox servery, tak by se Witness neměl použít, ale nastavit jej musíme.

Stejně jako pro jiné clustery je doporučeno mít na serverech dvě sítě, jednu pro provoz, označíme ji MAPI, a druhou pro replikace (funkce clusteru), označíme ji Replication. Popisu k těmto sítím není nikde moc, například otázka, na které síti se má nacházet Witness server, ale logicky asi bude správné umístění v MAPI síti. Stejně tak spíše dedukuji, že Replication síť má být uzavřená a neroutovaná (tedy může být i bez brány) s ostatními, nemá ani žádný DNS záznam (potažmo DNS server).

Dále budeme potřebovat virtuální IP adresu pro DAG. To je další oblast, o které se nenaleznou téměř žádné informace. Pravděpodobně se defaultně získává adresa automaticky z DHCP, to ale často u serverů nevyužíváme, takže ji můžeme definovat i ručně. Pokud máme servery v jednom subnetu, tak není s nastavováním adres ani sítí žádný problém, protože ale zde používáme 2 subnety (potažmo 4), tak jsem narazil na řadu chyb a možných řešení (buď použití více adres nebo úprava sítí, viz. další popis).

Vytvoření DAGu

Konfiguraci DAGu můžeme provést pomocí PowerShellu nebo Exchange Management Console (EMC), tam ale nedokážeme nastavit úplně všechny hodnoty. Postup v EMC:

• EMC – Organization Configuration – Mailbox – Database Availability Groups – New Database Availability Group…
• jméno: DAG1, Witness Server: Witness.firma.local, Witness Directory: c:\DAG1 (složka se automaticky vytvoří)

Tím se nám vytvořil prázdný DAG. Nyní mu musíme nastavit virtuální IP adresu. Otevřeme vytvořený DAG a přepneme se na záložku IP Adresses a přidáme virtuální adresu 10.0.0.50. To vše můžeme nastavit v PowerShellu jedním příkazem:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer Witness -WitnessDirectory C:\DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.50

Při prvních pokusech mi selhával některý z následných kroků a zobrazoval chybu, že neví jak komunikovat se serverem na pobočce. V některých materiálech se zmiňuje, že pokud jsou servery v různých subnetech, tak se musí do DAGu zadat virtuální IP v každém z nich. To by znamenalo přidat třeba 10.0.1.50 (a naprosto nikde jsem nenalezl, jestli se zde mají uvažovat i subnety z Replication sítě). Ale potom se mi povedlo provést celé nastavení i bez této adresy (která se stejně nikde nevyužívala). Bylo ale potřeba provést úpravu sítí, kterou uvedu dále.

Dalším krokem je zařazení Exchange serverů do DAGu. V EMC zvolíme DAG1 a klikneme na Manage Database Availability Group Membership. Nebo použijeme PowerShell. Nejprve přidáme dva servery v centrále.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer Exch01
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer Exch02

Hned jak jsme zařadili první server, tak se provedlo několik operací. V Active Directory se vytvořil objekt typu Computer s názvem DAGu. Na DNS serveru se zaregistroval název DAGu s jeho virtuální IP  (tato adresa odpovídá i na ping). Také se v DAGu vytvořili sítě Database Availability Group Network se jmény DAGNetwork01 a DAGNetwork02. Jedna síť je pro MAPI a druhá Replication, automaticky se nastaví subnety. Můžeme se na ně podívat v EMC kliknutím na DAG a v dolním okně Networks nebo PowerShellem.

Get-DatabaseAvailabilityGroupNetwork

Identity                       ReplicationEnabled                Subnets
--------                       ------------------                -------
DAG1\DAGNetwork01              True                              {{10.0.0.0/24,Up}}
DAG1\DAGNetwork02              True                              {{192.168.0.0/24,Up}}

Kdybychom někdy chtěli sítě znovu automaticky vygenerovat, tak můžeme použít příkaz.

Set-DatabaseAvailabilityGroup -DiscoverNetworks

Nyní je dobré (řekl bych přímo nutné) automatické sítě upravit. Síť, kde je subnet 10.0.0.0/24, si pojmenujeme MAPI a vypneme na ní replikace. Stejně pokud není dostupná síť Replication, tak se automaticky využije MAPI pro replikace. Replikace translačních logů funguje na jiném principu než v Exchange 2007, nyní je komunikace přes jeden TCP port 64327. Potom k MAPI síti přidáme subnet 10.0.1.0/24. Tento krok bychom nemuseli provést nyní, ale vyhneme se tak některým chybám a problémům. Pokud tak neučiníme, tak se po přidání serveru z pobočky vytvoří další síť a tu pak stejně musíme zrušit (nejprve přesunout subnet do MAPI sítě) - toto je v některých materiálech označováno jako Collapsing DAG Networks.

Síť se subnetem 192.168.0.0/24 pojmenujeme Replication a jinak nemusíme měnit. Ještě je doporučeno nastavit MAPI síť jako první v seznamu sítí ve Windows (Network Connections - Advanced settings).

Potom přidáme poslední Exchange serveru, opět buď v EMC nebo PowerShellem.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer Exch03

Vlastní DAG tedy již máme hotový. Můžeme si jej prohlédnout v EMC, ale mnohem více informací nám řekne PowerShell. Zde je důležité, pokud chceme získat všechny informace jako je OperationalServers, PrimaryActiveManager, NetworkNames a další, tak v řadě situaci musíme použít přepínač Status. Dále je zjednodušený příklad, pro plný výpis samozřejmě doplníme | FL *.

Get-DatabaseAvailabilityGroup

Name        Member Servers                     Operational Servers
----        --------------                     -------------------
DAG1        {Exch01, Exch02, Exch03}

Get-DatabaseAvailabilityGroup -Status

Name        Member Servers                     Operational Servers
----        --------------                     -------------------
DAG1        {Exch01, Exch02, Exch03}           {Exch01, Exch02, Exch03}

Vytvoření kopií databází

Nyní buď vytvoříme novou databázi nebo ji již máme hotovu na některém serveru. Takže pro ni vytvoříme kopii na jednom nebo všech členech DAGu. V EMC - Organization Configuration – Mailbox – Database Management – pravým tlačítkem klikneme na DB a zvolíme Add Mailbox Database Copy. Relativně důležitou hodnotou je i možnost specifikovat Activation Preference (něco jako prioritu, ale není to nejdůležitější hodnota při výběru, kam se DB přepne).

Add-MailboxDatabaseCopy -Identity DB01 -MailboxServer Exch03 -ActivationPreference 3

DAG Failback

Databáze je vždy aktivní na jednom serveru. Na začátku je to ten, kde jsme ji vytvořili. Při výpadku serveru se přepne na jiný. Bohužel zde není vlastnost Failback, tedy aby se databáze stala aktivní na primárním serveru, pokud je opět dostupný. To je problém hlavně, když se při krátkém výpadku spojení s pobočkou, přepne pobočková DB do centrály. Situaci musíme řešit nějakým skriptem, který budeme třeba spouštět v nějakém intervalu nebo reagovat na událost. Přímo na Exchange serveru je k dispozici skript, který provede aktivaci databází podle nějakých parametrů, hlavně asi Activation Preference.

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\RedistributeActiveDatabases.ps1 -DagName DAG1 
-BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution -Confirm:$false 

Aktivovat databázi na jiném serveru samozřejmě můžeme ručně. V EMC na záložce Database Management vybereme databázi a v okně Database Copies klikneme pravým tlačítkem na kopii, kterou chceme aktivovat a zvolíme Activate Database Copy. Pak ještě můžeme změnit nastavení, za jakých podmínek se může kopie aktivovat (kolik dat se může ztratit).

Move-ActiveMailboxDatabase DB01 -ActivateOnServer Exch02 -MountDialOverride:BestAvailability

Datacenter Activation Coordination Mode

Pouze jako krátkou si zmínku uvedeme možnost přepnout DAG do Datacenter Activation Coordination Mode (DAC). To souvisí s tím, že máme DAG přes dvě Sites. Jak jsme si uvedli výše, pokud nám přestanou fungovat oba servery v centrále, tak se odpojí i databáze na pobočce. Pokud by nastala krizová situace, kdy bychom potřebovali zprovoznit server na pobočce, tak to manuálně můžeme provést. Ale pokud by se obnovil server v centrále, tak ten by si myslel, že má být aktivní (má Quorum). Tím bychom se dostali do stavu, že by byla databáze aktivní na dvou serverech, to se označuje jako Split brain syndrome. Řešením je zapnutí DAC na DAG.

Set-DatabaseAvailabilityGroup DAG1 –DatacenterActivationMode DagOnly

A poslední poznámka na tomto místě. Microsoft plánoval s SP1 přinést nový parametr AllowCrossSiteRpcClientAccess pro DAG. Tento atribut opravdu u DAGu vidíme, můžeme ho i nastavit, ale nic se nestane. MS jej označuje (stále, když již máme SP2), že je připraven pro budoucí použití. Otázka je, co by měl způsobit. Protože při praktických pokusech připojování Outlooku k CASu, kdy byla DB umístěna v různých Sites, se Outlook připojuje opravdu různě.

Ověření replikací

Když máme vše nastaveno, tak můžeme zkontrolovat, která síť se používá pro replikace.

Get-MailboxDatabaseCopyStatus -ConnectionStatus | FL Name, Status, OutgoingConnections, IncomingLogCopyingNetwork

Name                      : DB01\Exch01
Status                    : Mounted
OutgoingConnections       : {{Exch03,Replication}, {Exch02,Replication}}
IncomingLogCopyingNetwork :

Stejně tak se můžeme podívat přímo na síťová spojení.

netstat -an | findstr 64327

Chyby při vytváření DAGu

V praxi mi řada operací skončila chybou, která byla ale spíše informativní, protože vše proběhlo v pořádku. Například při některých operacích nastavení DAGu se zobrazuje:

The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server 
witness.firma.local.

Přestože jsou práva nastavena správně. Při přidávání serveru do DAGu se zobrazovali chyby:

No static address matched networks 'Cluster Network 3'. Specified static addresses: '10.0.0.50'

Network name 'DAG1' is not online. Please check that the IP address configuration for the database availability 
group is correct.

Nebo také při vytváření databáze nebo její kopie.

Couldn't communicate with the Microsoft Exchange Replication service on server "Exch4.firma.local" to pick up new 
configuration changes for database "DB01". Make sure that the service is running and that the server has network 
connectivity. Error: A server-side administrative operation has failed. The database operation failed.
Error: Could not find a valid configuration for database 

Nalezení údajů pro mailbox

Pouze jednoduché zopakování, pokud pro určitého uživatele potřebujeme najít používaný server (nejprve nalezneme DB, kde má schránku, potom, kde je tato DB aktivní a jaký má přiřazený CAS).

Get-Mailbox username | FL Database 

Database : DB01 

Get-MailboxDatabase DB01 | FT Name, Server, RpcClientAccessServer

Name         Server          RpcClientAccessServer
----         ------          ---------------------
DB01         Exch01          cas1.firma.local