Datacenter Activation Coordination

Onlangs moest ik voor een klant een ontwerp schrijven voor een hoog beschikbare Exchange 2010 omgeving. De Exchange 2010 omgeving moest vanwege de eisen voor hoog beschikbaarheid verspreid worden over meerdere datacenters. Ieder datacenter vertegenwoordigde een Active Directory Site. Tijdens het bespreken van het hoofdstuk “hoog beschikbaarheid van de mailbox servers” kwam ik samen met de klant in een interessante discussie: Wat gebeurt er nu wanneer de verbinding tussen beide datacenters wegvalt? Het verhaal dat ik als antwoord bij deze klant heb gegeven wil ik graag toelichten in deze blog.

Een Database Availability Group

Met de komst van Exchange 2010 is ook de Database Availability Group (DAG) geïntroduceerd. De DAG is een doorontwikkeling van het Continuous Replication principe dat in Exchange 2007 werd geïntroduceerd. Een DAG maakt het mogelijk om een mailbox database hoog beschikbaar te maken binnen je organisatie. Dit wordt bereikt door één of meerdere (maximaal 16) kopieën van een mailbox database aan te maken. Anders dan bij Continuous Replication in Exchange 2007 kan ik in Exchange 2010 mijn actieve databases nu ook verdelen over mijn bestaande mailbox servers. Hierdoor kan ik ook aan load verdeling doen. Een DAG met vijf servers kan er als volgt uitzien:

De bovenstaande DAG heeft vijf actieve databases en iedere database heeft twee kopieën.

De servers die onderdeel uit maken van een DAG kunnen over meerdere datacenters verspreid worden. Dit was bij de bewuste klant ook het geval. Zoals gezegd moest er vanwege de vereiste beschikbaarheid gebruik gemaakt worden van meerdere datacenters. Clients hebben netwerk technisch gezien toegang tot beide datacenters. In beide datacenters kunnen dan ook actieve componenten zijn. Zo ook met de mailboxservers.

In datacenter A bevinden zich twee mailbox servers met ieder één actieve mailbox database en drie passieve mailbox databases. Zo ook in datacenter B: twee mailbox servers waarbij iedere mailbox server één actieve mailbox database heeft en drie passieve mailbox databases.

Door middel van Continuous Replication worden de kopie databases up-to-date gehouden. Met andere woorden: iedere wijziging in de actieve database wordt ook doorgevoerd in de passieve database.

De mailbox servers zijn leden van het cluster. In totaal hebben we dus vier leden in het cluster. Nu is het bij een cluster zo dat er altijd een meerderheid aan leden nodig is om het cluster te kunnen starten. Bij een aantal van vier cluster leden zal het cluster al niet meer kunnen starten bij uitval van twee leden. Immers zijn er dan nog maar twee over en dat is geen meerderheid in het totaal van vier leden. Om toch een meerderheid in het cluster te kunnen krijgen voegen we een zogenaamde Witness Server toe aan de ledengroep. Hierdoor komt het aantal leden op vijf. Bij uitval van twee leden zijn er nog drie leden operationeel wat een meerderheid is op het totaal van vijf. Deze opzet noemen we een ‘Node and File Share Majority’ quorum model.

De Active-Manager

In Exchange 2007 is het zo dat de cluster services van Windows het cluster volledig aanstuurt. Databases, de Information Store en de System Attendant zijn voorbeelden van cluster resources die door de cluster services worden aangestuurd. In Exchange 2010 kennen we geen cluster storage resources meer zoals in Exchange 2007. De cluster service wordt nog wel gebruikt om bijvoorbeeld de leden van de DAG bij te houden, om de heartbeat tussen deze leden te managen en voor het quorum, wanneer deze tenminste nodig is.

Het aansturen van het cluster is nu de verantwoordelijkheid van de zogenaamde Active Manager geworden. Deze Active Manager draait als een rol op alle Mailbox servers. Op servers die onderdeel uit maken van een DAG draaien twee Active Manager rollen: Primary Active Manager (PAM) en de Stand-by Active Manager (SAM).

De PAM bepaald binnen een DAG welke database copies actief dan wel passief moeten zijn. Ook is de PAM verantwoordelijk voor bijvoorbeeld het reageren op uitval van een Mailbox server. De DAG server waarop de PAM rol wordt uitgevoerd bezit ook altijd het quorum resource binnen het cluster. Je vraagt je nu misschien wel af hoe nu bepaald wordt op welke server een database kopie actief wordt wanneer de active database crasht? Wel nu, de Active Manager kent een zogenaamd ‘best copy’ selectie dat bepaald welke kopie er het best voorstaat en dus actief kan worden, hierbij kijkt de Active Manager ook naar het ‘activation preference number’ dat ingesteld kan worden op een kopie van een database. Het ‘activation preference number’ kan ingesteld worden op een waarde gelijk aan of groter dan één, waarbij de database met de waarde één de meeste voorkeur heeft (uiteraard moet de database wel een ‘healthy’ status hebben). Heb je drie kopieën dan is drie de hoogste waarde dat ingesteld kan worden. Dit instellen kan met het volgende commando:

Set-MailboxDatabaseCopy -Identity DB01\MBX-02 -ActivationPreference 3

De kopie van DB01 op server MBX-02 heeft dus de minste voorkeur.

De SAM rol voorziet Exchange componenten waar een Active Manager client component draait (bijvoorbeeld RPC Client Access service) van informatie met betrekking tot welke Mailbox server de actieve copy van een database host. Daarnaast detecteert de SAM lokale database crashes en zal de PAM vragen om een failover uit te voeren.

Een mailbox server crasht!

Stel dat je op de server MBX-01 een driver update van de netwerkkaart uitvoert maar dit heeft, hoe ongelukkig ook, een blauw scherm tot gevolg. Gelukkig hebben we een DAG geconfigureerd en zal de mailbox databases DB-01 die actief was op MBX-01, actief worden op MBX-02, MBX-03 of MBX-04. Bij het crashen van MBX-01 hebben we nog 4 stemmen in het cluster over en dus zal het cluster operationeel blijven. Je hebt nu rustig de tijd om de driver update op MBX-01 ongedaan te maken en de server weer operationeel te maken. Zodra de server weer operationeel is kan DB-01 weer actief gemaakt worden op MBX-01.

Een datacenter crasht!

Nu een wat gecompliceerder probleem: Datacenter-A valt uit productie omdat er een brand is ontstaan in het pand waar Datacenter-A zich bevindt. Alle servers in Datacenter-A vallen uit. Door de brand is er vanuit Datacenter-A geen netwerkverbinding meer mogelijk met het client netwerk en met Datacenter-B. Nu is het helaas niet zo dat gebruikers direct over kunnen switchen naar Datacenter-B. In Datacenter-B zijn immers nog maar twee nodes over en dat is een minderheid op het totaal van vijf. We moeten dus eerst een Witness Server in de lucht brengen in Datacenter-B. Nu is dit geen uren werk maar het moet gebeuren om weer een meerderheid in het cluster te krijgen. Voor de witness server gelden wel een paar regels waar we ons aan moeten houden:

- De witness share mag niet op een mailbox server geplaatst worden die onderdeel is van een DAG;

- De witness server moet in hetzelfde Active Directory forest als de DAG zitten;

- De witness server moet uitgevoerd worden op een Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2 of Windows Server 2003 besturingssysteem.

Met het volgende commando kunnen we de Witness server configureren op de server HUB03 (welke in Datacenter-B staat):

Set-DatabaseAvailabilityGroup -Name DAG-01 -WitnessServer HUB03 -WitnessDirectory C:\DAG-01

Zodra de Witness Server operationeel is kan DB-01 actief gemaakt worden op bijvoorbeeld MBX-03 en DB-02 op bijvoorbeeld MBX-04. Zo zijn alle databases weer operationeel en kunnen de herstelwerkzaamheden in Datacenter-A aanvangen.

Zodra de brand meester is worden de servers weer hersteld. De netwerkverbinding is echter nog niet hersteld. In Datacenter-A worden de servers MBX-01, MBX-02 en de Witness Server ook weer gestart. Jawel deze drie servers hebben een meerderheid in het cluster en dus komt het cluster ook online! Dat betekend dat het cluster nu op twee plaatsen online is L. Dit noemen we wel een Split Brain Syndroom.

Wat kunnen we er nu aan doen om te voorkomen dat de servers MBX-01, MBX-02 en de Witness Server zorgen voor een succesvolle start van het gehele cluster? Met andere woorden hoe voorkomen we een Split Brain Syndroom? Zal het productteam van Exchange hier iets voor bedacht hebben?

Datacenter Activation Coordination

Het antwoord op de laatste vraag is: JA ZEKER! En deze oplossing hebben ze de naam Datacenter Activation Coordination mode (afgekort als DAC mode) gegeven. Deze techniek is ingebouwd om een zogenaamd Split-Brain Syndroom te voorkomen. DAC mode controleert het activeren van mailboxdatabases. In de Exchange 2010 RTM versie kan DAC mode gebruikt worden wanneer je voldoet aan de volgende criteria:

· Wanneer je meer dan twee mailbox servers hebt en deze mailbox servers bevinden zich in verschillende Active Directory Sites.

Het Datacenter Activation Coordination Protocol zorgt ervoor dat ondanks dat er een meerderheid in het cluster is er geen databases gemount kan worden. Active Manager slaat een bit op in het geheugen (een 0 of een 1) dat aan de DAG verteld of een lokale database gemount mag worden op een server of niet. Wanneer een DAG in DAC mode draait zal iedere keer wanneer de Active Manager gestart wordt de bit op 0 gezet worden, wat inhoud dat de database niet gemount mag worden. Omdat DAC mode is ingeschakeld zal de server proberen te communiceren met andere leden van de DAG om antwoord te krijgen op de vraag of de lokale database met de status ‘active’ gemount mag worden. Het antwoord wordt gegeven door andere Active Managers in de DAG, wanneer een andere server laat weten dat daar de bit op 1 staat betekend dit dat de server eveneens de bit op 1 kan zetten. Doordat de bit nu op 1 staat kunnen de lokale databases met de status ‘active’ gemount worden.

Wanneer er echter een crash van een datacenter heeft plaats gevonden en de verbinding tussen datacenter A en B nog niet hersteld is, zal de bit van de server in Datacenter-A op 0 blijven staan. De server kan immers niet communiceren met DAG leden die de bit op 1 hebben staan! Zodoende kunnen er geen databases gemount worden in Datacenter-A en ontstaat er geen split-brain situatie.

Nu is het niet zo dat DAC-mode standaard staat ingeschakeld. DAC-mode moet vanuit de Exchange Management Shell ingeschakeld worden. Het commando hiervoor is als volgt:

Set-DatabaseAvailabilityGroup -Identity DAG-01 -DatacenterActivationMode DagOnly

Exchange 2010 Service Pack 1

Met de komst van Service Pack 1 kunnen we DAC ook gebruiken voor een DAG die bestaat uit twee leden waarbij deze twee leden zich bevinden in gescheiden datacenters. Ook is het niet meer noodzakelijk om gescheiden Active Directory sites te hebben in deze datacenters!

Voordat ik dit artikel besluit nog een heel belangrijke tip van Microsoft:

Omdat de opstarttijd van een Witness server bepaald of een DAG member tijdens het starten zijn actieve databases kan mounten of niet, mag je nooit de Witness Server en een DAG member op het zelfde moment herstarten. Wanneer dit wel gebeurd bestaat de mogelijkheid dat de DAG member geen databases kan mounten. Om dit te herstellen moet je dan het commando Restore-DatabaseAvailabilityGroup voor de DAG uitvoeren. Dit commando reset de DACP bit waardoor vervolgens de databases wel weer gemount kunnen worden.

Graag wil ik Johan Veldhuis bedanken voor zijn waardevolle review op dit artikel en de terugkoppeling die hij heeft gegeven. Tevens hoop ik dat ik jullie door middel van dit artikel een goed beeld heb kunnen geven van een wat onderbelichte techniek van Exchange 2010. Mocht je naar aanleiding van dit artikel nog vragen hebben, stel ze dan gerust!