Exchange DAG – FSW und DAC

Der gebräuchliche Begriff im IT-Umfeld ist hier „Node Majority“.

Der Exchange in RZ1 hat eine Stimme und das FSW ebenfalls, somit dürfen die Datenbanken aktiv geschaltet werden.

Situation 3 – RZ1 offline

So weit, so gut. Doch was, wenn das RZ1 ausfällt? Schließlich liegt in diesem ja auch mein FSW!

Im Hinterkopf wissen wir: Jeder Server und das FSW haben eine Stimme! Nun ist RZ1 vollständig ausgefallen:

• der Exchange Server ist aus
• das FSW ist nicht erreichbar
• die Netzwerkkommunikation ist ausgefallen
• Exchnage RZ2 ist online

Daraus ergibt sich, dass die Datenbanken in RZ2 NIEMALS online sein werden, denn 50% +1 ist nicht erreicht und die Exchange-Organisation ist ausgefallen.

Was allerdings passieren kann, ist, dass ein Administrator die Datenbanken in Rz2 dennoch in den Status „Online“ bringt. Durch ein alternatives FSW oder dadurch, dass mehrere Exchange DAG-Mitglieder im RZ2 stehen oder durch welche Situation auch immer! Damit wären im RZ2 die Datenbanken aktiv. Was aber, wenn RZ1 ohne WAN / LAN Verbindung zum RZ2 wieder online geht?

Split-Brain-Syndrom!!! –> Dazu bitte weiterlesen!

Situation 4 – Exchange in RZ1 offline

Diese Situation ist identisch mit Situation 1. Ist nur ein Server offline, aber 50% +1 erreicht, sind die Datenbanken auf dem Exchange in RZ2 online!

Situation 5 – Ungerade Anzahl Knoten

Diese Situation ist nun eigentlich relativ einfach. Hier wird kein FSW benötigt, denn ich habe immer 50%+1, jeder Knoten in der  DAG hat eine Stimme.

Und fallen bei drei Exchange Servern in der DAG zwei aus, ist dann alles offline? Beispiel: Die Server in RZ1 und RZ2 sind ausgefallen, der Server in RZ3 funktioniert –> Datenbanken offline?

JEIN – denn je nachdem, welches Betriebssystem ausgeführt wird, entscheidet das Failover Cluster. Bei Windows Server 2008 R2 sind die Datenbanken heruntergefahren. Bei Windows Server 2012  und aufwärts NICHT – dank Dynamic Quorum!

Jeder Node erhält im Dynamic Quorum einen zusätzlichen Wert: DynamicWeight! Fällt ein Node in der DAG aus, so wird diesem die Stimme entzogen. Das bedeutet bei einer Drei-Server-DAG haben nur noch zwei Server eine Stimme + FSW, welches beim Erstellen der DAG angegeben werden MUSS!

Fällt ein weiterer Server aus und es ist nur noch einer von dreien aktiv, wird auch diesem die Stimme entzogen und ich habe ein Node+FSW – Cluster bzw. DAG sind aktiv!   – Server 2012 und höher!

Maßnahmen

Um einen Ausfall zu verhindern, kann Folgendes getan werden:

Sprechen wir in großen Umgebungen von mehreren RZs, ist auch Virtualisierung ein Thema. Einen Ausfall des FSW verhindere ich am besten, indem dieses auf einem virtuellen Computer liegt. Dieser wird im Falle eines RZ-Ausfalls durch Vmotion oder Hyper-V Replica im zweiten RZ gestartet und:

• FSW ist online
• Mehrheit erreicht
• Datenbanken können online gehen

Split-Brain-Syndrom / Datacenter Activation Coordination

Wie oben in Situation 3 bereits anfänglich beschrieben, gilt es dies zu verhindern. Es darf nicht passieren, dass durch einen RZ-Ausfall und manuellen Eingriff des Administrators in beiden RZs die Datenbanken als aktiv gestartet werden.

Zunächst in Bildern das Standardverhalten ohne Aktivierung des Datacenter Activation Modes:

1. RZ1 ist vollständig ausgefallen und ein Administrator aktiviert die Datenbanken in RZ2
2. Nun wird das Rechenzentrum 1 wieder online geschaltet, jedoch ohne die Datenverbindung zu RZ2. Da die Exchange-DAG über eine Mehrheit verfügt, werden die Datenbanken aktiv online gesetzt:
3. Split Brain-Syndrom eingetreten. Ehrlich gesagt: Diesen Zustand will kein Administrator vorfinden!

Um Split Brain zu verhindern, kann in der Exchange-DAG der „Datacenter Activation Mode“ aktiviert werden. Dieser verhindert über das eigens entwickelte Protokoll „Datacenter Activiation Coordination Protocol“, kurz DACP, das automatische Bereitstellen von Datenbanken, auch dann, wenn die Mehrheit an Stimmen erreicht wurde.

Man kann es sich wie eine zusätzliche Stimme des DAG-Mitglieds vorstellen, das heißt jeder Server der DAG mit konfiguriertem DAC erhält eine zusätzliche Stimme. Startet nun der Exchange Server im Rechenzentrum 1 und das FSW ist ebenfalls wieder online, so hat dieser die Mehrheit an Stimmen. Doch die zusätzliche Stimme des DAC, standardmäßig „0“, verhindert das Bereitstellen der Datenbanken. Erst nach dem erfolgreichen Verbinden zu einem weiteren Server in der DAG und der Abfrage, ob dieser einen Wert von 1 aufweist, dürfen Datenbanken bereitgestellt werden. Als passive Kopie!

DACP-Bit auf 0 bedeutet das Bereitstellen der Datenbanken ist untersagt.

DACP-Bit auf 1 bedeutet das Bereitstellen der Datenbanken ist erlaubt.

Datacenter Activation Coordination wird mit folgendem Befehl aktiviert:

Set-DatabaseAvailabilityGroup -DatacenterActivationMode DAGOnly

Doch wie verhält sich DAC:

• Rechenzentrum 1 und 2 sind netzwerktechnisch noch getrennt
• FSW und Exchange sind online
• DAC ist aktiv
• Aktive Datenbanken in RZ2
• Datenbank-Bereitstellung ist aufgrund der Nichterreichbarkeit des RZ2 in RZ1 nicht möglich! DACP-Bit sei Dank!

Wird jedoch die Netzwerkverbindung zwischen den RZs wieder hergestellt, passiert Folgendes:

• Rechenzentren 1 und 2 sind wieder verbunden
• FSW und  Exchange sind online
• DAC ist aktiv
• Aktive Datenbanken in RZ2
• Passive Datenbankbereitstellung aufgrund von Netzwerkkonnektivität in RZ1 möglich, DACP-Bit jeweils auf 1.

DAC in einer Zwei-Server-DAG

So weit, so gut. Doch was passiert eigentlich mit aktivierten DAC in einer Zwei-Server-DAG? Schließlich muss ein Exchange Server zwecks Wartung / Updates auch mal neu gestartet werden!

Wichtig ist der Startzeitpunkt des Servers / Zeugenservers. Wird das DACP-Bit des Exchange Servers in RZ1 gesetzt und der Zeitpunkt liegt vor dem Startzeitpunkt des Zeugenservers, so wird die Datenbank nicht bereitgestellt. Der Exchange Server nimmt an, dass sowohl Zeugenserver als auch DAG-Mitglied zur selben Zeit neu gestartet wurden, folglich werden keine Datenbanken eingebunden.

Liegt der Startzeitpunkt des Zeugenservers in der Vergangenheit, so geht das DAG-Mitglied davon aus, den Neustart aus Wartungszwecken erhalten zu haben. Folglich dürfen die Datenbanken eingebunden werden.

Dass ich empfehle, DAC zu aktivieren, muss ich nicht erwähnen, oder?

Administrative Grüße aus Bielefeld

Andi