In het eerste deel van deze blog hebben we gekeken naar de theorie en enkele voorbeelden. In deze blog gaan we verder met het configureren en beheren van een DAG.

In deze situatie hebben we twee multirole Exchange 2013 servers. Omdat dit een even aantal is hebben we ook een file share witness nodig. Idealiter zou deze file share witness geplaatst worden op een andere Exchange server (bijvoorbeeld een CAS) maar deze kan ook op een generieke server worden geplaatst.

De eerste stap is het maken van de FSW. Het is van belang dat de Exchange Trusted Subsystem lid is van de local administrator groep van de server. Dit omdat Exchange deze account onderwater gebruikt om de nodigde acties uit te voeren.

Als de server niet de File Server feature bevat dan dient deze geïnstalleerd te worden m.b.v. het volgende cmdlet:

Add-WindowsFeature FS-FileServer

Als deze acties zijn uitgevoerd kunnen we verder gaan met het configureren van de DAG.

Als je bekend met met de DAG van Exchange 2010 dien je op te letten voor de volgende stap. Je dient namelijk het Cluster Name Object (CNO) van te voren aan te maken. Open ADUC en maak een computeraccount aan die gelijk is aan de naam van de DAG, bijvoorbeeld DAG01. Nadat het object is aangemaakt dient het object uitgeschakeld te worden en dienen de eigenschappen van het object opgevraagd te worden. Select de security tab en voeg de computeraccount van de computer die als eerst aan de DAG wordt toegevoegd toe. Herhaal deze stap voor de Exchange Trusted Subsystem beveiligings groep.

Natuurlijk kun je dit ook met een script doen. Mede The UC Architects lid Michel de Rooij heeft een script gemaakt wat hier gevonden kan worden.

De volgende stap is het aanmaken van de DAG, we gebruiken hiervoor de Exchange Management Shell:

New-DatabaseAvailabilityGroup -Name Exchange_DAG01 -WitnessServer FS01 -WitnessDirectory C:\Exchange_DAG01  -DatabaseAvailabilityGroupIpAddresses 192.168.1.90

Door gebruik te maken van het bovenstaande cmdlet maken we een DAG aan met de naam DAG01 en wijzen we FS01 toe als witness server. Op de FS01 wordt een directory aangemaakt Exchange_DAG01. Als laatste stap wijzen we een IP adres aan de DAG toe 192.168.1.90.

Als de DAG is aangemaakt is het tijd om de mailbox servers toe te voegen. Dit kan gedaan worden door gebruik te maken van het Add-DatabaseAvailabilityGroupServer cmdlet:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer EX01

Opmerking: wanneer de Windows Failover Clustering componenten ontbreken dan zal het cmdlet deze automatisch toevoegen. Houd er rekening mee dat de Exchange server misschien herstart moet worden. Dit server moet hierna mogelijk herstart worden. In dit geval is het noodzakelijk om het cmdlet nogmaals uit te voeren. Uit de praktijk weet ik dat het soms niet nodig is om te herstarten. In dat geval wordt de server direct aan de DAG toegevoegd.

Zodra de eerste server is toegevoegd dient deze stap nogmaals uitgevoerd te worden voor de andere server:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer EX02

Om de configuratie van de DAG aft e ronden dienen we de additionele kopieën toe te voegen van de databases. Om additionele kopieën toe te voegen maken we gebruik van het Add-MailboxDatabaseCopy cmdlet:

Add-MailboxDatabaseCopy -Identity MBDB01 -MailboxServer EX02 -ActivationPreference 2

Nadat de copy is toegevoegd dient de Microsoft Exchange Information Store service herstart te worden op de server waar de kopie is toegevoegd. Dit heeft te maken met de  ”Managed Store” zoals deze geïntroduceerd is in Exchange 2013. Collega Exchange MVP Tony Redmond heeft een mooie blog hierover gepubliceerd. Dus als je wil weten waarom dit daadwerkelijk nodig is bezoek dan deze site.

In dit geval wordt een kopie van de database MBDB01 toegevoegd op de server EX02 met aan activation preference van 2.

Herhaal de stappen voor de database gehost by EX02:

Add-MailboxDatabaseCopy -Identity MBDB02 -MailboxServer EX01 -ActivationPreference 2

Zodra deze cmdlets zijn uitgevoerd kun je gebruik maken van het Get-MailboxDatabaseCopyStatus cmdlet om de status van de databases en kopieën te controleren.

In het bovenstaande voorbeeld is te zien dat de eerste kopie is gemount en de content index healthy is. De kopie van de database heeft echter een content index status van FailedAndSuspended. In dit voorbeeld zal een *over als gevolg hebben dat de gebruikers problemen zullen ondervinden met het zoeken in de mailbox.

Om dit probleem op te lossen dien je gebruik te maken van het Update-MailboxDatabaseCopy cmdlet:

Update-MailboxDatabaseCopy -Identity MBDB01\EX02 –CatalogOnly

Nadat je bevestigd dat catalog geupdate dient te worden zal de catalog bijgewerkt worden op de tweede kopie:

Laten we kijken naar nog een issue:

In dit geval zijn zowel de database als content index van de tweede kopie in verkeerde status:

Update-MailboxDatabaseCopy -Identity MBDB02\EX01

Na de bevestiging zullen zowel de database als de content index gereseed worden en zullen beide de status healthy krijgen.

Wanneer we onderhoud uit willen voeren op één van de DAG servers zullen we de server in maintenance mode moeten plaatsen. Dit kan gedaan worden door gebruik te maken van het StartDagServerMaintenance script wat gevonden kan worden in de standaard scripting directory van Exchange.

Door de parameter Server toe te voegen kunnen we de server opgeven die we in onderhoud willen nemen. Als het script wordt uitgevoerd zal het controleren of de server de PAM rol bezit en welke databases geactiveerd zijn op de server en deze vervolgens verplaatsen naar een andere DAG server.

Als het onderhoud aan de EX02 klaar is kunnen we de server terug in productie nemen. Dit kan gedaan worden door gebruik te maken van het StopDagServerMaintenance script:

.\StopDagServerMaitenance.ps 1 –Server EX02

Als het script is uitgevoerd is het verstandig om de status van de database te controleren met het Get-MailboxDatabaseCopyStatus cmdlet. Het script zal overigens niet de databases automatisch opnieuw verdelen dit zal handmatig gedaan moeten worden. Om een actieve database te verplaatsen dienen we het Move-ActiveDatabase cmdlet te gebruiken:

Move-ActiveMailboxDatabase MBDB02 –ActivateOnServer EX02

Nadat we dit hebt bevestigd zal de database geactiveerd worden op de EX02.

Hier eindigt het tweede deel van het Exchange Alfabet over Database Availability Groups. In dit deel hebben we gekeken hoe we een DAG kunnen maken en hoe we diverse cmdlets kunnen gebruiken om de DAG te beheren.

In een eerder blog hebben we al kort even gekeken naar de (DAG) van Exchange 2013. In deze blog gaan duiken we de diepte in en gaan we kijken hoe een DAG nu daadwerkelijk werkt en hoe je er één kunt maken.

De DAG functionaliteit werd geintroduceerd in Exchange 2010 om alle voorgaande cluster methods van Exchange 2007 te vervangen. Door gebruik te maken van een DAG is het mogelijk om meerdere kopieën van een data aan te maken binnen een DAG. Dit is gelimiteerd tot 16 kopieën per database wat ik persoonlijk nog nooit heb gezien tijdens implementaties.

Database kopieën Database Copies can have several statuses which are displayed in the table below:

Wanneer je onder de motorkap van de DAG kijkt zal je zien dat deze gebruik maakt van windows clustering. De componenten worden automatisch geïnstalleerd wanneer je een server lid maakt van een DAG. Wat belangrijk is om te weten is dat dit wel vereist dat het OS Windows 2008 R2 Enterprise is in geval van Windows 2007 R2. Wanneer je gebruik maakt van Windows 2012 maakt het niet meer uit omdat zowel de standard als datacenter editie beschikken over de failover feature. Alhoewel er gebruik maakt wordt van de failover feature is het niet aan te raden om aanpassingen te maken m.b.v. de failover cluster manager.

Binnen de DAG is er  één server die de primary active manager (PAM) rol krijgt toegewezen. Deze server maakt de beslissingen welke kopieën actief zijn en welke passief. Wanneer er een problem optreed met de actieve copy dan is het de verantwoordelijkheid van de PAM om overige servers hiervan op de hoogte te brengen en om te reageren. De server die de PAM rol heeft is ook direct de eigenaar van de cluster quorum group. Wanneer de server die beschikt over de PAM rol bezit en niet meer beschikbaar is dan zal de cluster group automatisch failoveren naar één van de overgebleven DAG leden.

Naast de PAM rol bestaat er nog een rol de standalone active manager (SAM). Deze rol is op alle servers binnen de DAG actief op de server die beschikt over de PAM rol zullen de taken die normaliter worden uitgevoerd door de SAM uitgevoerd worden door de PAM. De SAM rol is verantwoordelijk voor het detecteren van locale database en locale Information Store problemen en acties te ondernemen die worden geïnitieerd door de PAM.

Zoals je misschien al is opgevallen hebben we gesproken over het quorum. Dit is erg belangrijk om te begrijpen. Als je bekend bent met clustering moet het al een bekende term zijn. Omdat de DAG een sort van clustering is maakt het ook gebruik van quorum om problemen zoals een split-brain te voorkomen. Binnen een DAG zijn er twee opties om quorum te krijgen. Je kunt ervoor kiezen om een oneven aantal DAG leden te hebben, bijvoorbeeld 3. Of je kan beslissen om een Failover Witness Share te implementeren. In dit laatste geval dient er een file share aangemaakt te worden op een andere server die nog geen lid is van de DAG. Als je bijvoorbeeld twee DAG leden hebt dan is het nodig om een failover witness share te installeren t.b.v. het quorum.

Om te berekenen hoeveel van de DAG leden tenminste online moeten zijn kun je gebruik maken van de volgende formule (n / 2) + 1 waar n het aantal DAG nodes is binnen de DAG. Wanneer je bijvoorbeeld 3 DAG leden resulteerd dit in (3/2) + 1=2.5 Omdat we niet met halve nodes kunnen werken ronden we dit af naar 2. Dit betekend dat er tenminste 2 leden online moeten zijn om de DAG beschikbaar te houden. Leden kunnen of beide mailbox servers zijn of een mix van een mailbox server en de FSW. Maar stel dat we 6 DAG leden hebben dan krijgen we (6/2)+1=4 wat even is . In dit geval zullen we ervoor moeten zorgen dat er tenminste 4 leden online zijn. In dit laatste geval is overigens een FSW nodig t.b.v. het quorum.

We hebben het al over meerdere kopieën van een database gehad maar hoe werkt dit? Elke copy van een database krijgt een activation preference. De initiële database heeft de activation prefence 1. Alle additionele kopieën krijgen een unique ID toegewezen. Bijvoorbeeld de tweede copy krijgt als activation preference 2 etc. De preference is één van de parameters die wordt gebruikt door de PAM om te beslissen welke copy geactiveerd moet worden in het geval van een failover.

Voorbeelden

OK genoeg theorie laten we eens naar wat voorbeelden kijken. Het eenvoudige voorbeeld is een DAG binnen een datacenter bestaande uit 3 multirole Exchange servers. Elke server bevat een copy van elke database. De activation preferences zijn zo ingesteld dat tijdens een normale operatie elke server maar  één actieve database bevat:

Stel dat we nu één node in onderhoud moeten nemen. Geen problem zet de node in maintenance en zorg ervoor dat de PAM naar een andere server wordt verplaatst.

Nadat de maintenance is voltooid kan deze uit maintenance mode gehaald. De andere servers zullen zien dat de node weer terug is en zullen ervoor zorgen dat de  kopieën up-to-date gebracht worden. Een handmatige actie is vereist om de databases weer te activeren op hun originele server.

In het volgende voorbeeld hebben we onze DAG members verdeeld over twee verschillende datacenters. Elk datacenter bevindt zich in een aparte AD site. We hebben nogsteeds 3 multirole servers in onze Exchange 2013 omgeving. Het enige verschil vergeleken met het eerste voorbeeld is dat we twee servers plaatsen in het primaire data center en de derde in het tweede datacenter Het tweede datacenter wordt alleen gebruikt voor disaster recovery doeleinden:

Stel dat nu de WAN link down gaat in dit scenario. Denk even aan de formule wat gaat er nu gebeuren? Juist de gebruikers hebben nogsteeds toegang tot hun mailbox. De formule is namelijk als volgt (3/2)+1 = 2.5 afgerond naar beneden 2. Dit betekend dat we tenminste twee mailbox servers of een combinatie van één mailbox server en één FSW online moeten zijn.

Zoals al vermeld kan een DAG members bevatten in één of meerdere AD sites. In dit laatste geval is het bepalen van de locatie van de file share witness (FSW) erg belangrijk. In de meeste gevallen zal men ervoor kiezen om de primaire site te laten overleven.

In het geval van de WAN link tussen twee sites betekend dit dat de site met het quorum zal overleven. Om de DR site weer in de lucht te krijgen zullen we een alternate/standby FSW moeten introduceren om de DAG weer online te brengen.

Hier eindigt deel één van het blog over database availability groups. In dit artikel hebben we vooral gekeken naar de theorie achter de DAG en enkele voorbeeld configuraties. In deel twee zullen we ook daadwerkelijk een DAG gaan bouwen.