Hochverfügbarkeit in Exchange 2013 – was ändert, was bleibt gleich?

Die neueste Generation der marktführenden Collaboration Software hat im Oktober 2012 den «Release to Manufacturing (RTM)»-Status erreicht. In diesem Artikel möchte ich Ihnen eine Übersicht geben über die neuen bzw. verbesserten Features von Exchange Server 2013 im Bereich der Hochverfügbarkeit.

Meine IT-Karriere startete in einer Zeit, als die Mailsysteme noch als geschäftsunkritisch betrachtet wurden. Diese Ansicht ändere sich allerdings jeweils beim Eintreten eines Störungsfalls: Nach spätestens zehn Minuten liefen im Service Desk die Drähte heiss.

Heutzutage weiss man zwar, dass die Systeme ausfallsicher sein sollten, doch oft gibt es keine offiziellen Service Level Agreements (SLA) oder besser Operational Level Agreements (OLA). Deshalb mein Tipp: Anforderungen an die Verfügbarkeit definieren, niederschreiben und absegnen lassen. Nur so lassen sich die richtigen Optionen wählen und konfigurieren.

Betrachten wir kurz die High-Availability-Komponenten des Vorgängers Exchange Server 2010. Für die Mailbox-Server-Rolle können Database Availability Groups (DAG) verwendet werden. Die Client-Access-Server-Rolle nutzt das CAS Array und eine Load-Balancing-Lösung (WNLB oder Hardware LB) und in der Hub-Transport-Server-Rolle sorgen die Shadow Redundancy und der Transport Dumpster dafür, dass es zu keinem Datenverlust führt, wenn ein Server ausfällt.

Schauen wir uns die verschiedenen Rollen mal genauer an. Die Rollen laufen am besten konsolidiert auf dem gleichen Server. Es gibt eine Ausnahme, auf die ich beim Thema Load Balancing zu sprechen komme.

Die Mailbox-Server-Rolle

Exchange Server 2013 verwendet immer noch DAG, um die Maibox-Datenbanken hochverfügbar zu machen. Daran hat sich soweit nichts geändert. Neu ist aber, dass auch Public Folder dieses Feature nutzen und keinen eigenen Replikationsmechanismus mehr. Dies ist eine praktische Vereinfachung, die allerdings ihren Preis hat: Bis und mit Exchange Server 2010 konnten alle Repliken einer Public-Folder-Datenbank für den Zugriff genutzt werden. Bei Exchange Server 2013 liegen sie hingegen in der gleichen Datenbank wie die Mailboxen, d.h. nur die aktive Replik kommt zum Zug.

• Bislang liefen alle Datenbanken im gleichen Prozess store.exe. Jetzt hat jede ihren eigenen Prozess. Diese Entkoppelung führt zu einer verbesserten Verfügbarkeit.
• Das neue Feature «Managed Availability» überwacht ständig verschiedene Aspekte der Exchange-Infrastruktur und kann Recovery-Aktionen eigenständig durchführen. Dafür existieren drei Komponenten: Probe, Monitor und Responder. Wichtig dabei: Es werden keine Services überwacht, sondern der Zugriff aus Sicht des Benutzers.
• Der Gesundheitszustand einer Datenbank aus Sicht der «Managed Availability» wird auch bei der Auswahl (Best Copy Selection) einer Kopie beim Failover von der Komponente «Active Manager» als Kriterium verwendet.
• «Automatic Reseed» kann ein als Spare definiertes Volume (Disk/LUN) nutzen, um nach einem Ausfall innerhalb des DAG automatisch eine neue Kopie der Datenbank anzulegen. Der Administrator muss nur noch die Disk auswechseln und als neuen Spare definieren.

Die Client-Access-Server-Rolle

Hier treffen wir auf die grösste Veränderung: Die CAS-Rolle beinhaltet keine Business-Logik mehr, sondern ist nur für Authentifikation des Benutzers und die Weiterleitung der Verbindung zuständig. Die Auswirkungen sind folgende:

• Es gibt kein CAS Array mehr. Dem Client ist es egal, auf welchem CAS Server er landet – sogar wenn dieser in einer anderen AD Site liegt. Dadurch vereinfacht sich auch das Site-Failover.
• Die Protokolle brauchen keine Affinität auf dem Load Balancer. Dies vereinfacht die Konfiguration erheblich.
• Obschon Windows Network Loadbalancing (WNLB) weiterhin unterstützt wird, rate ich davon ab, es zu verwenden, da dann zwingend die Rollen separiert werden müssen (Failover Clustering des DAG und WNLB schliessen sich aus) und keine Überwachung der Dienste möglich ist. Nur der Ausfall eines ganzen CAS Servers wird abgedeckt. Es gibt inzwischen preislich attraktive Hardware Load Balancer, die weit mehr Funktionalität bieten. Übrigens: SSL Offloading wird in der RTM-Version von Exchange 2013 noch nicht unterstützt.
• Weil die Public Folder jetzt auch in einer Mailbox-Datenbank liegen, läuft aller Verkehr über den CAS Server. Ausserdem wird immer HTTP/HTTPS verwendet. Eine RPC-Verbindung für MAPI von Outlook wird nicht mehr unterstützt!

Der Transport Service

Der Titel dieses Abschnitts nimmt eine wichtige Veränderung schon vorweg: Die Hub-Transport-Rolle gibt es nicht mehr – den Transport Service hingegen schon. Wir sprechen also nicht mehr von einer Rolle. Der Service wurde auf die noch verbleibenden Client-Access- und Mailbox-Server-Rollen verteilt. Für unsere Betrachtung der Hochverfügbarkeit ist das aber nicht relevant.

Die beiden Features der Vorgängerversion wurden verfeinert:

• Shadow Redundancy verwendet AD Site oder neu den DAG als Grenze, um eine zweite Kopie eines eingehenden Mails zu erstellen.
• Der Transport Dumpster wurde umbenannt in Safety Net. Neu konfiguriert man nicht mehr die Grösse der Datenbank, in der das Feature erhaltene Mails zwischenspeichert, sondern die Zeitdauer, während der die Mails darin zur Verfügung gestellt werden. Standardmässig sind das zwei Tage.

Shadow Redundancy und Safety Net arbeiten Hand in Hand: Mails, die gerade durchlaufen, werden durch Shadow Redundancy geschützt, ausgelieferte Mails durch Safety Net.

Architektur

Exchange Server 2013 und auch die Vorgängerversion wurden spezifisch darauf ausgelegt, mit lokalem und damit günstigem Storage betrieben werden zu können. Dadurch rechtfertigt sich auch die Konfiguration von mehreren Kopien pro Datenbank. Oft erlebe ich die Situation, dass die Exchange-Daten zwingend auf SAN LUNs liegen müssen (damit man die teure Hardware auch wirklich nutzt) und deshalb mehrere Kopien der gleichen Daten unerwünscht sind. Übrigens müssen natürlich auch die Datenbankkopien auf separater Hardware zu liegen kommen – nicht nur Disk Array, sondern separater Controller und Enclosure. Sonst ergibt sich wieder ein Single Point of Failure!

Wie schon erwähnt ist die Verwendung von Multi-Role Servern am sinnvollsten – je mehr Kopien einer Datenbank, desto besser. Hier hilft es, die anfangs erwähnten SLA/OLA zur Hand zu haben, um die optimale Anzahl zu ermitteln.

Ebenfalls relevant für das Design ist die Frage, ob ich mehrere AD Sites und/oder geografische Orte abdecken muss und wo der Zugriff der Benutzer stattfindet. Falls an mehreren Standorten Benutzer auch im Falle eines WAN-Unterbruchs ihre Mailbox verwenden müssen, reicht ein DAG nicht mehr! Dies wird oft übersehen.

Fazit

Es gibt also einige Verbesserungen in der neuen Exchange-Version, die sich schon in der Design-Phase der Lösung einplanen lassen. Meine Liste ist natürlich nicht abschliessend. Exchange Server 2013 bietet noch weit mehr. Weitere Informationen zur Konfiguration der Features und zur Planung einer Exchange-Server-2013-Umgebung erhalten Sie in unseren neuen Kursen zu Exchange 2013.