Tento článek patří do série, která vychází z mých poznámek při migraci Exchange organizace z verze 2010 na 2016. Nejde o kompletní postup, ale o popis hlavních bodů a oblastí. Příklady se týkají určitého daného designu, ale většinou se dají zobecnit. Stejně tak, i když jde o popis migrace, tak se informace hodí i pro novou instalaci či správu.
Starší verzi DAGu jsem popisoval v článku Exchange 2010 CAS Array a DAG mezi Sites.
Plánování topologie a instalace DAG
Dříve než si začneme popisovat, co to je Database Availability Group, jak funguje a konfiguruje se, tak navážeme na předchozí díly a nakreslíme si ukázkovou topologii. Při plánování adres služeb (Namespaces) v prvním díle jsme si vytvářeli tabulky a schémata pro plánované nasazení. Pokud se rozhodneme využít DAG, tak bychom měli doplnit další sítě a adresy. Případně také naplánovat databáze a kde budou primárně aktivní.
Obecný postup nasazení
- připravíme jednotlivé servery, většinou asi půjde o VM, a nastavíme síťové adresy
- na servery nainstalujeme Exchange Mailbox role a provedeme základní konfiguraci
- vytvoříme DAG (Database Availability Group)
- jednotlivé Mailbox servery zařadíme do DAGu (jako uzly Nodes - Member Servers)
- (volitelně) zrušíme staré databáze a vytvoříme nové databáze schránek
- k databázím přídáme DB kopie na dalších serverech
DAG - Database Availability Group
Dokumentace Database availability groups, Manage database availability groups, Plan for high availability and site resilience
DAG zajišťuje vysokou dostupnost Mailbox DB tím, že vytváří kopie (Mailbox Database Copies) na dalších serverech (členech DAGu) a ty udržuje aktuální pomocí replikací (Continuous Replication). Jedna kopie (na jednom serveru) je aktivní (Active Mounted) a ostatní jsou neaktivní (Passive). V případě problémů na serveru se aktivuje DB kopie na jiném, tedy dojde k automatickému failover. Ruční přepnutí (aktivování) databáze se nazývá switchover. Monitoring a přepínání řeší komponenta Active Manager (součást služby Exchange Replication). DAG je skupina až 16 Mailbox serverů, všechny musí mít stejnou verzi Exchange (tedy nejde 2016 a 2010 dohromady) a být ve stejné doméně. Pokud dojde k switchover nebo failover, tak jsou klienti téměř okamžitě přesměrováni k nové DB.
Od Exchange 2013 SP1 CU4 (minimálně na Windows Server 2012 R2) můžeme vytvořit DAG bez IP adresy, jinak řečeno bez cluster administrative access point (CAAP). Pak se nepřiřazuje IP adresa, nevytváří síťové jméno ani DNS, nevytváří se Cluster Name Object (CNO) v AD DS. Celkově to zjednodušuje řešení clusteru. Ale cluster se pak nedá spravovat pomocí Failover Cluster Management nástroje, ale pouze pomocí Exchange Management Shell.
Velký dopad je pro zálohování, kdy některé nástroje využívají CAAP a bez něj nedokáží DAG zazálohovat. Proto je nejprve třeba zkontrolovat zálohovací SW. Microsoft SCDPM 2012 R2 UR9 podporuje zálohování Exchange 2016, včetně DAGu bez IP adresy. DPM can now backup Exchange 2016
MS doporučuje použít DAG bez administrative access point (pro Exchange 2016 nebo 2019 na minimálně Windows Server 2012 R2). Pouze pokud používáme nějaký 3rd party aplikaci, která se připojuje na cluster/DAG (pro normální provoz to není třeba).
Fungování DAGu
DAG používá nepřetržité replikace (Continuous Replication - block mode nebo file mode) a část technologie Windows Failover Clustering k zajištění vysoké dostupnosti (High Availability) a odolnosti lokalit (Site Resilience).
DAG využívá Windows Failover Cluster, ten využívá princip kvóra (quorum). Pokud jsou servery ve více lokalitách a dojde k výpadku spojení, tak se zajistí, aby běžela pouze jedna strana. Na základě souhlasu (konsenzu) voličů je pouze jedna skupina členů clusteru aktivní. Pokud má DAG sudý počet členů, tak je třeba Quorum Witness Resource, aby se zabránilo split brain syndrome. Členové DAGu komunikují s Witness Server a mohou zamknout soubor witness.log pomocí SMB. Člen DAGu, který zamknul Witness Server, označuje se Locking Node, má hlas navíc a členové, kteří s ním komunikují, mají většinu.
Podle počtu členů clusteru (node) se využívá Quorum Model:
- Node Majority - lichý počet
- Node and File Share Majority - sudý počet
Vytvoření DAGu
Musíme si připravit Witness server, kde bude sdílená složka (případně se může použít i druhý (záložní) Witness server). Sice, když máme 3 Mailbox servery, tak se Witness nebude používat, ale nastavit při konfiguraci jej musíme (kdyby se změnil počet členů DAGu). Na Witness serveru musíme do skupiny lokálních administrátorů zařadit doménovou skupinu Exchange Trusted Subsystem.
Pozn.: Na Exchange 2016 je možno vše okolo DAGu spravovat pomocí Exchange Management Shell, ale hodně věcí lze provést i v Exchange Admin Center. V článku si často uvádíme pouze jednu možnost.
Vytvoříme DAG bez IP adresy. Vždy je důležité unikátní jméno pro DAG. Založení je jednoduché.
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- klikneme na plus - New
- zadáme jméno, adresu serveru a složku pro Witness, nezadáme žádnou IP adresu
Pozn.: Standardně využívá DAG, pro síťový provoz mezi subnety, šifrování a kompresi. V nastavení DAGu můžeme změnit. Exchange servery mezi sebou využívají Kerberos autentizaci.
Přidání serveru do DAGu
Postupně přidáme první, a pak další členy DAGu, tedy jednotlivé Mailbox servery.
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- zvolíme náš DAG a klikneme na ikonu počítače s ozubeným kolečkem - Manage DAG membership
- v novém okně klikneme na plus - Add
- přidáme server a potvrdíme Save
Při přidání prvního serveru se provede
- instalace komponenty Windows Failover Clustering (pokud již nemáme nainstalovanou)
- vytvoří se Failover Cluster pro DAG se zadaným jménem
- server se přidá do DAG objektu v AD DS
- cluster database se aktualizuje údaji o databázích, které jsou mount na přidaném serveru
Protože máme DAG bez IP, tak se neprovede
- nevytvoří se Cluster Name Object (CNO) v default Computers kontejneru AD DS
- registrace jména DAG/cluster v DNS
- nepřiřadí se jméno sítě ke clusteru
Pozn.: Než přidáme druhý server do DAGu, tak musím počkat na proběhnutí replikací AD
Při přidání druhého serveru do DAGu provede
- přidání serveru do Failover Cluster
- vytvoří se witness directory and share
- server se přidá do DAG objektu v AD DS
- cluster database se aktualizuje údaji o databázích, které jsou mount na přidaném serveru
Kontrola DAGu
Po přidání serveru do DAGu je třeba provést kontrolu, protože se může zdát vše v pořádku, ale server se nepřidá správně a není aktivní. Pro hlavní kontrolu může použít Exchange Management Shell, Failover Cluster PowerShell nebo Failover Cluster řádkový příkaz.
[PS] C:\>Get-DatabaseAvailabilityGroup -Identity MailDAG -Status
Name Member Servers Operational Servers
---- -------------- -------------------
MailDAG {MAIL2, MAIL1, MAIL3} {MAIL1, MAIL2, MAIL3}
[PS] C:\>Get-Cluster
Name
----
MailDAG
[PS] C:\>Get-ClusterNode
Name ID State
---- -- -----
mail1 1 Up
mail2 2 Up
mail3 3 Up
[PS] C:\>cluster node
Listing status for all available nodes:
Node Node ID Status
-------------- ------- ---------------------
mail1 1 Up
mail3 2 Up
mail2 3 Up
Musíme ověřit, že jsou jednotlivé členské servery (member / node) nahoře (up) a v provozním stavu (Operational). Tento stav vidíme i v Exchange Admin Center, pokud zvolíme editaci DAGu. V PowerShellu si můžeme zobrazit více detailů.
Get-DatabaseAvailabilityGroup -Identity MailDAG -Status | FL *
Také můžeme spustit test celkového zdraví DAGu.
Test-ReplicationHealth
Pozn.: Jeden server mi nešel přidat do DAGu, buď při přidání vrátil chybu, nebo po úspěšném přidání nefungoval. Dlouho jsem to ladil a nakonec vytvořil nový virtuál a nově instalovat Exchange a od té doby bylo vše OK.
Podívat se můžeme na log o přidání člena DAGu v cestě C:\ExchangeSetupLogs\DagTasks. Pak můžeme použít Event Viewer, kde se logují Operational informace - Applications and Services Logs - Microsoft - Exchange - HighAvailability - Operational. Zjistil jsem, že problémy byly s vlastním Failover Cluster. Služba Cluster Service (ClusSvc) byla Disabled a nešla nastartovat. Registry HKEY_LOCAL_MACHINE\Cluster byly neúplné. Soubory jsou v C:\Windows\Cluster.
DAG Network - sítě
DAG network je soubor jednoho nebo více subnetů, které se používají pro replikaci nebo MAPI provoz. DAG musí mít jednu MAPI síť a může mít více replikačních sítí. Je podporováno použití jedné sítě (jednoho adaptéru) pro MAPI i replikaci dohromady. Doporučuje se minimálně dvě sítě a oddělit MAPI a replikace. Pro replikace může být více sítí.
Síť pro replikaci by neměla mít nastavenu default gateway a doporučuje se vypnout Client for Microsoft Networks, File and Printer Sharing for Microsoft Networks a Register this connection's addresses in DNS. Členové DAGu musí mít stejné síťové adaptéry, každý adaptér musí mít nastavenu IPv4 adresu (pokud má server více adaptérů, tak každý musí mít adresu z jiného subnetu). Pokud na MAPI síti vypneme replikace, tak zde stejně mohou probíhat, pokud bude nedostupná síť pro replikace.
MS přímo uvádí, že na Exchange 2010 se sítě často musely konfigurovat ručně. Nyní probíhá konfigurace automaticky systémem. Když si chceme vypsat sítě, tak můžeme použít následující cmdlet, ale pokud jsem jej spustil bez parametru, tak jsem dostal chybu.
[PS] C:\>Get-DatabaseAvailabilityGroupNetwork Could not load file or assembly 'Microsoft.Exchange.Data, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Řešení je zavolat s parametrem, kde zadáme jméno serveru Exchange 2016
[PS] C:\>Get-DatabaseAvailabilityGroupNetwork -Server mail1
Identity ReplicationEnabled Subnets
-------- ------------------ -------
MailDAG\MapiDagNetwork True {{10.0.0.0/24,Up}}
MailDAG\ReplicationDagNetwork01 True {{192.168.0.0/24,Up}}
Systém asi většinou vytvoří (rozumně) sítě MapiDagNetwork a ReplicationDagNetwork01, pokud máme dva adaptéry. Na MapiDagNetwork zapne MAPI access i Replication, na ReplicationDagNetwork01 pouze Replication. Pokud chceme provést nějaké manuální změny sítí či ručně vytvořit sítě, tak musíme na DAGu zapnout možnost manuální konfigurace (lze i v EAC).
Set-DatabaseAvailabilityGroup MailDAG -ManualDagNetworkConfiguration $true
Patrně budeme chtít na MAPI síti vypnout replikace
Set-DatabaseAvailabilityGroupNetwork -Identity MailDAG\MapiDagNetwork -ReplicationEnabled:$false
Když do DAGu přidáme server z jiné Site, a tedy jiného subnetu pro MAPI, tak se označuje jako multi-subnet DAG. Na rozdíl od Exchange 2010, zvládne Exchange 2016 správně automaticky přidat subnety do sítí.
[PS] C:\>Get-DatabaseAvailabilityGroupNetwork -Server mail1
Identity ReplicationEnabled Subnets
-------- ------------------ -------
MailDAG\MapiDagNetwork False {{10.0.0.0/24,Up}, {10.10.0.0/24,Up}}
MailDAG\ReplicationDagNetwork01 True {{192.168.0.0/24,Up}}
DAG Network můžeme nyní spravovat i z EAC.
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- přidání sítě - zvolíme náš DAG a klikneme na ikonu počítače s plus - New DAG network
- úprava existující - zvolíme náš DAG a vpravo vidíme DAG Network se seznamem a akcemi
Správa kopií databáze schránek
Dokumentace Manage mailbox database copies.
Když jsme vytvořili DAG a zařadili do něj členské servery, tak můžeme k existujícím databázím (Mailbox DB) vytvářet jejich synchronizované kopie a pracovat s nimi.
Vytvoření kopie databáze v rámci DAGu
Když vytvoříme kopii databáze, tak na zvoleném serveru vznikne pasivní kopie DB a aktivují se replikace (continuous replication). Databázové kopie mají přiřazen identifikátor ve formátu Databáze\Server, například DB1\MAIL1. Při vytváření kopie DB se použijí stejné cesty pro datové soubory i logy. Na serverech tedy musí existovat stejné (použité) disky. Aby se mohla vytvořit kopie DB, tak se nesmí používat Circular Logging (odmazávání logů).
- EAC - Exchange Admin Center
- Servers - Databases
- vybereme DB, klikneme na tři tečky - More - Add database copy
- zvolíme server, kam chceme kopii umístit
- případně můžeme upravit prioritu kopie - Activation preference number
- další volitelná možnost jsou zpožděné replikace - Replay lag time
Samozřejmě můžeme přidání kopie provést v Exchange Management Shell.
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MAIL1 -ActivationPreference 2
Kontrola stavu databázových kopií
Přímo v seznamu databází v EAC vidíme seznam a stav jednotlivých kopií.
- EAC - Exchange Admin Center
- Servers - Databases
- vybereme DB a vpravo vidíme údaje, včetně kopií
- pro kopii můžeme využít View Detail
Obdobně si můžeme vypsat v PowerShellu. Zde je vidět, že probíhá prvotní synchronizace po přidání na server MAIL3.
[PS] C:\>Get-MailboxDatabaseCopyStatus DB1
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
---- ------ --------- ----------- -------------------- ------------
DB1\MAIL1 Mounted 0 0 Healthy
DB1\MAIL2 Healthy 0 0 15.11.2018 18:54:13 Healthy
DB1\MAIL3 Resynchronizing 28083 0 Suspended
Správa databázových kopií, přepínání
S databázovými kopiemi můžeme provádět různé operace. Nejčastější je asi manuální přepnutí na pasivní kopii, tedy aktivace kopie (Activate Database Copy), Microsoft to označuje jako Database switchovers (Switchovers and failovers). Aktivní kopie DB se odpojí (dismount) na jednom serveru a pasivní kopie se připojí (mounted) jako nová aktivní na jiném. Další možnosti jsou odstranění (Remove) DB kopie, pozastavení (Suspend) a obnova (Resume) a aktualizace (Seed, Update).
- EAC - Exchange Admin Center
- Servers - Databases
- vybereme DB, vpravo vidíme kopií a u nich dostupné příkazy
Aktivace DB kopie pomocí Exchange Management Shell nabízí různé přepínače a někdy je nutné je použít.
Move-ActiveMailboxDatabase DB1 -ActivateOnServer MAIL2 -SkipMoveSuppressionChecks
Rozložení aktivních DB kopií na servery, DAG Failback
Když máme více Mailbox serverů a DAG, tak máme vyřešeno High Availability a Fault Tolerance, protože pokud dojde k nějaké chybě serveru, tak se aktivují data na druhém. Ale asi by bylo škoda využívat servery ve stylu Active-passive, kdy jeden vykonává všechnu práci a na ostatní se pouze synchronizují data. Proto můžeme využít Active-active (Load Balancing), kdy jsou všechny servery aktivní a obsluhují klienty. Toho dosáhneme tak, že vytvoříme více mailbox DB a nastavíme je aktivní na různých serverech (a využijeme Activation preference number).
Když se provádí plánované (switchover) nebo neplánované (failover) aktivace databázových kopií, tak je výsledkem nevyvážený stav rozložení aktivních DB kopií na servery (oproti úvodnímu stavu). Stejně, jako na Exchange 2010, můžeme využít skript RedistributeActiveDatabases.ps1, který aktivuje DB na serverech podle čísla Activation Preference. Ale od Exchange Server 2016 CU2 není třeba používat, protože balancování DB kopií probíhá automaticky každý zadaný čas (default 1 hodina) pro DAG PreferenceMoveFrequency (Get-DatabaseAvailabilityGroup | FT Name,PreferenceMoveFrequency).
Údržba serveru v DAGu
Než začneme provádět nějakou údržbu serveru nebo instalaci aktualizací, tak je doporučeno přepnout server do Maintenance Mode. Ten přesune aktivní databáze a funkce na ostatní servery. Podrobný popis Performing maintenance on DAG members. Můžeme využít skripty, které jsou součástí instalace Exchange serveru.
cd $ExScripts .\StartDagServerMaintenance.ps1 -ServerName <ServerName> .\StopDagServerMaintenance.ps1 -serverName <ServerName>
Server Switchover
Pomocí EAC můžeme jednoduše provést Server Switchover, který aktivuje kopie DB na jiném serveru.To se doporučuje provést před každým restartem Exchange serveru, který je členem DAGu.
- EAC - Exchange Admin Center
- Servers - Servers
- vybereme server, ze kterého chceme přesunout aktivní DB, vpravo klikneme na Server Switchover
Datacenter Activation Coordination (DAC) mode
Defaultně je vypnutý, ale MS jej doporučuje zapnout. Při startu serveru kontroluje, zda je možno aktivovat databázi, pokud máme více datových center a byla aktivována kopie v druhém datovém centru. Má zabránit Split Brain, tedy aby nám aktivně běžely dvě kopie stejné DB. Například, pokud v primárním DC dojde k výpadku proudu a všechny servery padnou. Aktivuje se nám záložní DC a zde kopie DB. V primárním centru se obnoví napájení, server nastartuje, ale nemá komunikaci se záložním. Pak standardně aktivuje DB. Více info Datacenter Activation Coordination mode.
Set-DatabaseAvailabilityGroup -Identity mailDAG -DatacenterActivationMode DagOnly
Pokud používáme DAC mode, tak můžeme využít příkazy pro přepnutí datových center.
Stop-DatabaseAvailabilityGroup Restore-DatabaseAvailabilityGroup Start-DatabaseAvailabilityGroup
Client Access Server (CAS) Array
Dříve se po vysokou dostupnost (High Availability) využíval DAG a CAS Array. Ještě byla otázka, jestli máme pouze jednu lokalitu/datové centrum/Site nebo více. Při výpadku lokality nefungovalo CAS Array pro automatické přepnutí. Exchange 2016 již CAS Array vůbec nepoužívá.
CAS Array sloužil pro MAPI/RPC připojení klienta Outlook na Client Access Server. Na Exchange 2016 se MAPI/RPC nepoužívá, místo toho buď MAPI/HTTP (MAPI over HTTP) nebo Outlook Anywhere (MAPI/RPC over HTTP).
Na databázích si můžeme vypsat údaj RpcClientAccessServer, kde je buď adresa serveru, nebo adresa CAS Array, pokud jsme jej používali. I po zrušení všech Exchange 2010 serverů zůstane tento atribut nastaven, ale to nevadí, protože se nepoužívá.
Get-MailboxDatabase | Select Name,RpcClientAccessServer
Odolnosti lokalit - Site Resilience
To znamená DAG přes více lokalit / datových center. Dokumentace Site resilience. Souvisí s popisem Namespaces v prvním článku série.
Exchange 2016 přináší změnu, že automaticky funguje přepnutí na servery v jiné lokalitě (datacentru/Site). Dříve se musel ručně měnit namespace. Klientská spojení jsou nyní pomocí HTTPS (i z Outlooku) a může být přiřazeno více IP adres, které se postupně zkouší. Přímé připojení přes MAPI již není povoleno. Na Exchange 2016 se klient může připojit k libovolnému Mailbox serveru a je zajištěn prostup požadavku na server, kde je aktivní databáze pro danou schránku. Můžeme využít DNS round robin, vytvoříme jeden DNS záznam, který bude obsahovat IP adresy všech serverů.
Řešení problémů a chyb
Oprava sítí DAG Network, odstranění neexistující
Sítě a subnety se přidávají samy, ale již se neodstraňují, když třeba odstraníme servery, které byly v jiné lokalitě. Je dobré občas spustit test a případně provést opravy. Úpravy se mohou dělat Exchange Management Shell i v EAC, kde je například jednodušší editace subnetu.
[PS] C:\>Test-ReplicationHealth
Server Check Result Error
------ ----- ------ -----
MAIL1 ClusterService Passed
MAIL1 ReplayService Passed
MAIL1 ActiveManager Passed
MAIL1 TasksRpcListener Passed
MAIL1 TcpListener Passed
MAIL1 ServerLocatorService Passed
MAIL1 DagMembersUp Passed
MAIL1 MonitoringService Passed
MAIL1 ClusterNetwork *FAILED* Subnet '10.0.0.0/24' on network 'MapiDagNetwork' is not Up.
Current state is 'Misconfigured'.
Subnet '10.0.0.0/24' on network 'MapiDagNetwork' is not Up.
Current state is 'Misconfigured'.
Subnet '10.10.0.0/24' on network 'MapiDagNetwork' is not Up.
Current state is 'Misconfigured'.
Subnet '10.10.0.0/24' on network 'MapiDagNetwork' is not Up.
Current state is 'Misconfigured'.
MAIL1 QuorumGroup Passed
MAIL1 FileShareQuorum Passed
MAIL1 DatabaseRedundancy Passed
MAIL1 DatabaseAvailability Passed
MAIL1 DBCopySuspended Passed
MAIL1 DBCopyFailed Passed
MAIL1 DBInitializing Passed
MAIL1 DBDisconnected Passed
MAIL1 DBLogCopyKeepingUp Passed
MAIL1 DBLogReplayKeepingUp Passed
Test ukazuje chybu na MAPI síti (píše dokonce, že není nahoře, ale ona v tuto chvíli normálně fungovala). Tak si vypíšeme DAG Network.
[PS] C:\>Get-DatabaseAvailabilityGroupNetwork
Identity ReplicationEnabled Subnets
-------- ------------------ -------
MailDAG\MapiDagNetwork False {{10.0.0.0/24,Misconfigured}, {10.10.0.0/24,Misconfigured}}
MailDAG\ReplicationDagNetwork01 True {{192.168.0.0/24,Up}}
MailDAG\ReplicationDagNetwork02 False {{fe80::/64,Misconfigured}}
U sítě MapiDagNetwork a ReplicationDagNetwork02 vidíme chybu, stav je Misconfigured. MAPI síť hlásí chybu, protože jediný server v druhé lokalitě (síť 10.10.0.0) byl zrušen. Je tedy potřeba editovat síť a odstranit nepoužívaný subnet.
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- zvolíme náš DAG, vpravo vidíme DAG Network, kde najdeme požadovanou síť
- klikneme na View details
- zde vidíme přiřazené subnety, můžeme je editovat, odstraňovat i přidávat
Pozn.: Odstranění subnetu nebo sítě trvá delší dobu. Takže subnet/síť se přestane zobrazovat až po několika minutách.
Replikační síť 2 vznikla nějak automaticky pro nepoužívanou IPv6 adresu. Potřebujeme celou síť odstranit. Když to zkusíme, tak dostaneme chybu, že je třeba nejprve odstranit subnety.
[PS] C:\>Remove-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02 DatabaseAvailabilityGroupNetwork 'ReplicationDagNetwork02' can't be removed because it contains active subnets. To remove the network, all active subnets must first be assigned to other networks. If you want to disable the use of the network, consider using the Set-DatabaseAvailabilityGroupNetwork cmdlet with the -IgnoreNetwork or -ReplicationEnabled parameters. + CategoryInfo : InvalidArgument: (:) [Remove-DatabaseAvailabilityGroupNetwork], DagNetworkManagementException + FullyQualifiedErrorId : [Server=MAIL1,RequestId=46104fdf-ef9f-4c67-b991-7dba758fe4f9,TimeStamp=19.02.2019 18:16:28] [FailureCategory=Cmdlet-DagNetworkManagementException] 7B8813CC,Microsoft.Exchange.Management.SystemConfigurationTasks. RemoveDatabaseAvailabilityGroupNetwork + PSComputerName : mail1.firma.local [PS] C:\>Set-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02 -Subnets $none
Odstraníme všechny subnety, když si hned vypíšeme údaje o síti, tak v ní pořád subnety uvidíme. Musíme několik minut počkat a zkusit to znovu.
[PS] C:\>Get-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02
Identity ReplicationEnabled Subnets
-------- ------------------ -------
MailDAG\ReplicationDagNetwork02 False {}
Pak již odstranění sítě proběhne
[PS] C:\>Remove-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02 Confirm Are you sure you want to perform this action? Removing database availability group network "MailDAG\ReplicationDagNetwork02". [Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y
Content index ve stavu Failed - DB kopie
Docela často se může stát, že když se podíváme (EMS nebo EAC) na stav pasivní kopie DB, tak je zde Content index state: Failed. V tu chvíli se nám nepovede přepnout tuto kopii na aktivní. Tato situace nastává například vždy po restartu některého serveru. Návod na opravu je popsán třeba v Repairing a Failed Content Index in Exchange Server 2016. Ale ukázalo se, že většinou stačí nějakou dobu počkat (třeba 15 minut) a tato chyba sama zmizí.
Problém s aktivací databázové kopie
Chtěl jsem udělat Database switchovers, tedy aktivovat DB kopii na jiném serveru. Operace proběhla, aniž by se zobrazila nějaká chyba. Ale když jsem se na databázi po chvilce podíval, tak byla znovu aktivní na původním serveru. Při dalším pokusu se zobrazila chyba, že je příliš mnoho logs to inspect and replay.
An Active Manager operation failed. Error: The database action failed. Error: An error occurred while trying to validate the specified database copy for possible activation. Error: mail1: Database copy 'DB2' on server 'mail1' has 124 logs to inspect and replay, which is higher than maximum allowed replay queue length of 10. If you need to activate this database copy, you can use the Move-ActiveMailboxDatabase cmdlet with the -SkipLagChecks and -MountDialOverride parameters to forcibly activate the database copy. If the database does not automatically mount after running Move-ActiveMailboxDatabase successfully, use the Mount-Database cmdlet to mount the database.
K tomu si můžeme zobrazit aktuální detaily o stavu DB kopií:
[PS] C:\>Get-MailboxDatabaseCopyStatus * | sort name | Select name, status, contentindexstate, ReplayQueueLength Name Status ContentIndexState ReplayQueueLength ---- ------ ----------------- ----------------- DB2\MAIL1 Healthy Failed 46 DB2\MAIL2 Mounted Healthy 0
Zde vidíme frontu logů (ReplayQueueLength) a také stav Content Index jako Failed. Když nějakou dobu počkáme, tak se fronta vyprázdní a stav vrátí na Healthy. Pak můžeme znovu přesunout (aktivovat) DB kopii, ale dopadne to stejně. Po několika pokusech se již aktivace kopie nepodaří a dostaneme chybu:
An Active Manager operation failed. Error: The database action failed. Error: Move for database 'DB2' was suppressed because too many moves have happened recently. 4 moves
Pokud chceme v tuto chvíli udělat přesun (aktivaci), tak musíme využít Exchange Management Shell a přidat atribut:
Move-ActiveMailboxDatabase DB2 -ActivateOnServer MAIL1 –SkipMoveSuppressionChecks
Ale stále se kopie neaktivuje na novém serveru. Při prohlížení aplikačního logu událostí na cílovém serveru jsem nalezl příčinu:
EventID 121 ExchangeStoreDB At '23.02.2019 18:45:40' the Exchange store database 'DB2' copy on this server appears to have failed due to insufficient memory. For more details about the failure, consult the Event log on the server for other "ExchangeStoreDb" events. Recovery was not attempted.
Na serveru byl přihlášen uživatel (správce) a obsazoval asi 1,5 GB operační paměti. Po jeho odhlášení začalo vše fungovat.
Zatím zde nejsou žádné komentáře.