Exchange 2013 – Ausfallsicherheit mit 3 Datacenters

Im April hat Ross Smith IV an der Microsoft Exchange Conference in Austin die neue bevorzugte Architektur für Exchange 2013 vorgestellt.

Autor Markus Hengstler
Datum 09.07.2014
Lesezeit 9 Minuten

Im April hat Ross Smith IV an der Microsoft Exchange Conference in Austin die neue bevorzugte Architektur für Exchange 2013 vorgestellt. Eine Aufnahme dieser Session können Sie sich auf Channel 9 anschauen. Als Alternative oder Ergänzung gibt es auch einen Blog-Artikel auf dem Exchange Team Blog. Ich zeige Ihnen in diesem Beitrag die Vorteile des neuen Designs. 

Mailbox Server

Eine wichtige Komponente der Architektur ist natürlich die Database Availability Group (DAG), die idealerweise zwei Datacenters umfassen sollte, damit der Verlust eines Standorts den Zugriff aufs Mail nicht beeinträchtigt. In der Vergangenheit war der knifflige Punkt die Lokation des File Share Witnesses (FSW) bei DAGs mit gerader Anzahl Knoten, da dieser im Falle eines Netzwerkunterbruchs zwischen den Standorten das Quorum bestimmt. Nur diejenigen Server im DAG, die das Quorum noch bilden können, dürfen Datenbanken bereitstellen. Das Ziel dieses Features ist es, ein sogenanntes Split-Brain-Syndrom zu verhindern, bei dem zwei Kopien einer Datenbank gleichzeitig aktiv sind und der Inhalt divergiert.

Microsoft Exchange Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Nun ist es leider so, dass im Falle eines Verlusts des Datacenters mit dem File Share Witness ein manueller Eingriff nötig ist, um für die verbleibenden Knoten des DAGs das Quorum zu forcieren. Viele Administratoren bemängeln diesen Umstand. Jedoch gibt es einen guten Grund dafür: Ein Automatismus kann nicht feststellen, ob der Standort, der eigentlich das Quorum hätte, wirklich ausgefallen ist, oder ob nur die Netzwerkverbindung betroffen ist. Im zweiten Fall müssen zuerst im primären Standort alle Mailbox Server heruntergefahren werden, bevor der Datacenter Switchover ausgeführt werden kann.

Mit Exchange 2013 wird nun von Microsoft unterstützt (und im Rahmen der bevorzugten Architektur empfohlen), den File Share Witness in ein drittes Datacenter zu verschieben. Um Ihnen zu zeigen, welche Voraussetzungen und Konfigurationen dazu nötig sind, habe ich in meiner Testumgebung die benötigte Infrastruktur aufgesetzt. In der nachfolgenden Illustration sehen Sie die Komponenten im Überblick:

1

Wie Sie sehen, besteht die Umgebung aus einem DAG mit vier Knoten, der die AD Sites ONE und TWO überspannt. In beiden Standorten existiert noch je ein Domain Controller und ein virtueller Loadbalancer der Firma Kemp, der auch fähig ist, als GEO Loadbalancer die Anfragen der Clients über beide Standorte zu verteilen. In der dritten AD Site THREE ist nur ein einziger Server, der als File Share Witness konfiguriert ist. Das Routing zwischen den Sites wird von Windows-basierten Routern übernommen. Der wichtige Punkt hier ist, dass die Verbindungen zwischen den Datacentern redundant sein müssen. Es wäre eine schlechte Idee, zum Beispiel Site-to-Site VPNs über einen einzigen Provider oder über MPLS zu verwenden, da potenziell alle Verbindungen betroffen sein können; dann kann nirgends das Quorum gebildet werden.

Ein paar Punkte, die es zu beachten gilt:

    • Wenn der File Share Witness nicht auf einem Exchange Server konfiguriert werden kann, da nur Multi-Role Server im Einsatz sind, muss die Gruppe Exchange Trusted Subsystem Mitglied der lokalen Administratorgruppe auf dem Server sein, die File-Server-Rolle muss installiert sein und WMI muss eingehend durch die Windows Firewall erlaubt sein.
    • Es gibt einen Bug in allen Exchange 2013 Builds bis und mit CU5, der den Index der Datenbanken in einen ungesunden Zustand bringt, da der verantwortliche Service nach einer inexistenten AD-Gruppe sucht. Am Besten ist es, von Beginn weg den Workaround in folgendem Artikel zu konfigurieren: http://support.microsoft.com/kb%5C2807668/EN-US
    • Bei Änderungen in der Exchange-Konfiguration dürfen Sie die Replikationslatenz des Active Directories nicht vergessen, da die meisten Einstellungen in der Partition Configuration gespeichert sind. Der kleinste Intervall, der für die Replikation zwischen AD Sites eingestellt werden kann, ist 15 Minuten. Allerdings gibt es einen Weg, stattdessen den gleichen Mechanismus zu verwenden wie für die Replikation innerhalb der Site, was die Latenz auf ein paar wenige Sekunden reduziert:2
    • Für eine Umgebung mit so vielen Datenbankkopien wie in meinem Beispiel sollte Exchange Native Data Protection, JBOD als Speicherort und Continous Replication Circular Logging (CRCL) in Erwägung gezogen werden.3Achtung: Circular logging darf erst aktiviert werden, nachdem mehrere Kopien der Datenbank angelegt sind – andernfalls wird Jet circular logging verwendet statt CRCL.

Mit dem 4-Knoten-DAG im Beispiel und ebenfalls 4 Kopien der Datenbanken lassen sich folgende Ausfallszenarien abdecken:

Scenario Resultat
Ausfall von bis zu 3 Exchange Server Die Datenbanken werden auf einem verbleibenden Server aktiviert. Solange sie nicht gleichzeitig stattfinden, erlaubt Dynamic Quorum in Windows 2012 R2 mehrere Ausfälle.
Ausfall eines Standorts Die Datenbanken werden im verbleibenden Standort aktiviert.
Ausfall von bis zu 2 Verbindungen zwischen den Standorten (Isolierung eines Standorts) oder eines öffentlichen Zugangs Die verbleibenden Standorte behalten das Quorum.
Ausfall des File Share Witness Der FSW wird nur benötigt, wenn das Quorum gebildet werden muss.

Client Access

In älteren Exchange-Versionen fand die Kommunikation zwischen der Client-Access- und der Mailbox-Rolle über RPC statt – ein Protokoll, dem Netzwerklatenz besonders zusetzt. Deswegen wurde wenn irgend möglich darauf verzichtet, diese Art von Verkehr über WAN-Links zuzulassen. Also wurde zum Beispiel bei Zugriff auf eine Mailbox in Europa über den US Datacenter CAS ein Redirect zurückgeschickt, der den Client zuerst mit einem europäischen CAS verband. In Exchange 2013 ist dies nicht mehr nötig, da auch die Kommunikation zwischen CAS und MBX über HTTP/HTTPS geschieht.

Exchange 2010                                                                 Exchange 2013

4             5

 

Mit dieser Änderung geht nun auch die Empfehlung einher, einen einzigen, globalen Namen für den Zugriff zu verwenden. Dies kann erreicht werden, indem der FQDN der externen URL des OWA- und ECP-Verzeichnisses gar nicht gesetzt ist oder jeweils gleich ist in allen Standorten, wie im unten abgebildeten Screenshot:

6

Damit dieses Design funktioniert, muss der Verkehr über einen Loadbalancer nicht nur innerhalb des Standorts verteilt werden, sondern auch zwischen den Standorten. Dazu kann theoretisch DNS Round Robin verwendet werden. Allerdings gibt es dann keinen Health Check und der Client versucht auch Server/Standorte zu erreichen, die nicht mehr verfügbar sind. Daraus ergibt sich eine längere Failover-Zeit, die dem Timeout des ersten Requests entspricht. Besser ist die Verwendung eines GEO Loadbalancers, der eigentlicht nichts anderes ist, als ein intelligenter DNS Server. Er gibt je nach Standort des Clients und Gesundheitszustands der Server andere IP-Adressen zurück.

Die folgenden Abbildungen zeigen das Beispiel einer Konfiguration in Kemp Loadmaster:

7

Die IP-Adressen im 10er-Netz sind die öffentlich zugänglichen, die der Loadmaster als DNS Server zurückgibt, während die 192er-Adressen der virtuellen IP eines Arrays von Servern in einem Standort entsprechen.

8

Der nächste Screenshot zeigt den virtuellen Service für einen Standort, der 2 Backend-Server beinhaltet.

9

Durch dieses Design können die folgenden Ausfälle abgefangen werden:

Scenario Result
Ausfall von bis zu 3 Exchange Servern Die Loadbalancer leiten den Verkehr auf die oder den verbleibenden Server.
Ausfall eines Standorts Die GEO-Loadbalancing-Komponente retourniert nur noch die IP-Adresse des funktionierenden Datacenters.
Ausfall von bis zu 2 Verbindungen zwischen den Standorten (Isolierung eines Standorts) oder eines öffentlichen Zugangs Die Loadbalancer leiten den Verkehr auf die oder den verbleibenden Server.
Ausfall eines Loadbalancers DNS-Abfragen werden dank mehreren Name Server Records (NS) automatisch an den verbleibenden Loadbalancer geschickt

 

Zusammenfassung

Das bevorzugte Design, das Microsoft vorgestellt hat, besticht durch höhere Verfügbarkeit der Mail-Infrastruktur, automatisiertem Failover und einer simpleren Konfiguration. Falls Sie mehr darüber erfahren möchten, besuchen Sie einen der folgenden Kurse:


Über den Autor

Markus Hengstler

Markus Hengstler arbeitet bei der UMB AG als Senior Systems Engineer in den Bereichen Exchange, Windows und Citrix. Dank seiner Erfahrungen in diesen Bereichen ist er zertifizierter «MCSE: Server Infrastructure». Ausserdem ist er einer von drei «MCSM: Messaging» in der Schweiz. Seit 2001 unterrichtet er als Microsoft Certified Trainer und seit 2010 als Citrix Certified Instructor bei Digicomp.