Exchange 2013 Ressourcenplanung - Teil 2: Rollenverteilung und Hochverfügbarkeit

In den letzten Monaten haben wir im ESC zusammen mit Administratoren verschiedener Hochschulen deren Exchange-Umgebung auf Exchange Server 2013 migriert oder die Ressourcenplanung für eine noch bevorstehende Migration durchgeführt. Die Nutzung von Postfächern unterscheidet sich stark zwischen Studenten einer Hochschule und Mitarbeitern in einem Unternehmen. Eine Analyse verschiedener Hochschulumgebungen zeigt, dass Studenten ihre Postfächer zwar seltener nutzen, dafür aber auf vielen verschiedenen Wegen darauf zugreifen wollen. Dank des Microsoft Education Programms ergibt sich durch die deutlich geringen Lizenzkosten zudem Einsparpotential bei der Hardwareanschaffung. In dieser Reihe von Blogbeiträgen finden Sie viele Informationen zur Planung Ihrer Exchange 2013 Umgebung und wertvolle Tipps speziell für die Anforderungen einer Universität.

 

Teil 2: Rollenverteilung und Hochverfügbarkeit

Rollenverteilung

Sie werden sicherlich schon festgestellt haben, dass sich die Rollenvielfalt bei Exchange 2013 im Gegensatz zu den Versionen von 2007 und 2010 etwas verkleinert hat. Lediglich 3 Rollen stehen zur Installation zur Verfügung:

  1. Mailbox-Rolle (MBX)

  2. Client Access-Rolle (CAS)

  3. Edge-Rolle (EDGE)

Deutlich interessanter als das Wegfallen von Unified Messaging und Hub Transport als eigene Rollen ist allerdings das Verschieben von Zuständigkeiten von der Client Access-Rolle hin zur Mailbox-Rolle. Während der CAS in Exchange 2007/2010 die Kommunikation und Darstellung von Inhalten für Benutzer vollständig übernommen hat, ist er in Exchange 2013 lediglich für das Weiterleiten einer Benutzeranfrage an den korrekten Mailbox-Server zuständig. Das Rendern der OWA-Oberfläche und verarbeiten der Benutzereingaben findet direkt auf dem Mailbox-Server statt.

Diese Entwicklung ist auf die ungeschickte Ressourcennutzung bei der Rollenaufteilung in Exchange 2007/2010 zurückzuführen. Der CAS benötigte viel CPU und Arbeitsspeicher, während er die in vielen Serversystemen verbauten SAS-Festplatten überhaupt nicht beanspruchte. Auf der anderen Seite brauchte ein MBX-Server einen großen und schnellen Datenspeicher, wohingegen seine CPU und sein Arbeitsspeicher überhaupt nicht ausgenutzt wurden. Auch das Caching von externen Anfragen (LDAP, RPC) hat durch diese Trennung nicht gut funktioniert, da ein Benutzer viele aktive Sitzungen auf verschiedenen CAS-Servern haben kann, die dann jeweils die gleichen Daten anfragen. In Exchange 2013 passiert all dies auf dem selben MBX-Server, der somit alle bereits angefragten Werte aus dem Cache laden kann.

Auch hier spielt natürlich das Thema Virtualisierung bei der Rollenverteilung und der daraus resultierenden Ressourcenauslastung eine große Rolle. Einen Blogeintrag zur richtigen Virtualisierungsstrategie finden Sie im Rahmen dieser Blog-Serie.

 

Hochverfügbarkeit und die Auswirkungen auf die Rollenverteilung

Bei der DAG und somit der Hochverfügbarkeit von Postfächern bleibt im Vergleich zu Exchange 2010 alles beim alten. Neu ist lediglich ein stark verbessertes und automatisiertes Failover zwischen Serverinstanzen, die in verschiedenen Rechenzentren gehostet werden. In einem weiteren Blogeintrag zum Thema Speicherlösungen wird näher auf die DAG eingegangen.

Bei der Lastverteilung zwischen den CAS-Servern hat sich allerdings einiges geändert. Bei Exchange 2007/2010 waren Benutzeranfragen an einen CAS-Server unterschiedlich groß. Es macht einen großen Unterschied, ob ich lediglich eine kurze Aktualisierung meines Outlook-Postfaches anfrage oder ob ich eine längere OWA-Sitzung auf dem CAS-Server habe. Deshalb reichte ein einfaches Round-Robin Verfahren nicht aus, um die Anfragelast gleichmäßig zwischen mehreren CAS-Servern zu verteilen. Viele Hochschulen nutzten hierfür den kostenlosen Windows Network Load Balancer, der eine ordentliche Lastverteilung und Ausfallsicherheit bietet.

Bei Exchange 2013 hat sich die Art der Anfragen an einen CAS-Server grundlegend geändert. Die Anfragen sind alle nahezu gleich groß, da der CAS-Server die Anfrage lediglich an den MBX-Server weiterleitet, auf dem gerade die aktive Kopie der Datenbank bereitgestellt wird, auf der das Postfach des Benutzers liegt.

Somit ist eine gute Lastverteilung zwischen den CAS-Servern bereits durch den Einsatz von DNS-Round-Robin gewährleistet. Hierzu setzt man einfach den InternalHostName von Outlook Anywhere bei allen CAS-Servern auf den gleichen DNS-Alias, beispielsweise mail.contoso.com. Das in Exchange 2010 eingeführte Client Access Array, ein Verbund aus mehreren CAS-Servern, ist in Exchange 2013 nicht mehr vorhanden. Ein Hardware Load-Balancer ist zwar nicht wirklich erforderlich, falls er aber bereits vorhanden oder ausdrücklich erwünscht ist, kann er mit Exchange 2013 verwendet werden.

Während Microsoft zum Start von Exchange Server 2013 noch das Aufteilen der Rollen auf verschiedene Server empfahl, findet man nun viele Blogeinträge, die zum Installieren beider Rollen auf allen Servern raten.

 

Vorteile der Rollentrennung:

1) Übersicht: Die Aufteilung erlaubt eine saubere und logische Trennung der Aufgaben zwischen den Servern. Dies erleichtert im Fehlerfall die Suche nach der Ursache und hilft beim Überwachen von Ressourcen ud Verbindungen.

2) Flexibilität: Hatte man bei Exchange 2010 seinen CAS-Server durch diverse Einstellungen zerschossen, war eine Neuinstallation der Rolle meist innerhalb einer Stunde abgeschlossen und alles funktionierte wieder. Wurden auf einem Exchange Server 2013 die Rollen CAS und MBX installiert, kann Exchange nur komplett deinstalliert werden. Die Deinstallation einer einzelnen Rolle ist nicht möglich.

3) Gewohnheit: Wenn Sie bereits ältere Exchange-Installationen mit dieser Rollentrennung administriert haben, fällt der Umstieg zu Exchange 2013 leichter, wenn die gewohnte Trennung beibehalten wird.

4) Windows NLB: Falls Sie auch in Ihrer Exchange 2013 Umgebung nicht auf den Network Load Balancer verzichten wollen, müssen Sie eine Rollentrennung vornehmen. Der Network Load Balancer kann nicht auf einem Server installiert werden, der das Feature Failover-Cluster installiert hat. Dieses ist aber eine Grundvorraussetzung für die Verwendung eines MBX-Servers in einer DAG.

 

Nachteile der Rollentrennung:

1) Ressourcenauslastung: Ein CAS-Server in Exchange 2013 verbraucht so gut wie keine Ressourcen. Es ist nahezu unmöglich, ein Serversystem nur durch die CAS-Rolle auszulasten. (Einen Blogeintrag zum Ressourcenverbrauch finden Sie unter ??) Dieser Nachteil existiert allerdings nur auf physikalischen Maschinen. Falls Sie Ihre Exchange Umgebung virtualisieren, fällt dieser Nachteil selbstverständlich weg.

2) Serverzahl: Eine höhere Anzahl an Servern führt logischerweise zu einem größeren Verwaltungsaufwand. Updates, Änderungen oder Hardwareausfälle müssen bei einer größeren Anzahl an Servern getätigt werden.

3) Kosten: Durch die höhere Anzahl der Server steigen auch die Beschaffungskosten. Die Hardwareempfehlungen für einen Mailbox-Server bleiben fast gleich, egal ob die CAS-Rolle zusätzlich installiert wird oder nicht. Die Anschaffung der Hardware für CAS-Server sind also reine Zusatzkosten.

4) Administration: Jeder Exchange Server durchläuft die exakt gleiche Installation und hat die gleichen Konfigurationsmöglichkeiten. Fällt ein Server aus, kann er leicht durch eine automatisierte Installation ersetzt werden. Gibt es Performanceprobleme, kann ein neuer Server mit minimalem Konfigurationsaufwand in die DAG aufgenommen werden. Dies erleichtert die Administration der Server enorm.

 

Aus den bisherigen Projekten hat sich folgende Empfehlung entwickelt:

Wird die Exchange Umgebung komplett auf physikalischen Maschinen betrieben, macht eine Rollentrennung aus meiner Sicht wenig Sinn. Laufen die Server virtuell sind die Nachteile der Rollentrennung lange nicht so gravierend, sodass ich hier eher zu einer Verteilung der Rollen tendiere.

Zum Abschluss noch eine kurze Erläuterung zum Thema "Hochverfügbarkeit und automatisches Failover zwischen Standorten". Unter dem Stichwort "Site Resilience" kann man in vielen Blogeinträgen lesen, dass es für Exchange 2013 (dringend) empfohlen wird, die Server auf zwei (genauer gesagt sogar drei) Standorte zu verteilen. Die Vorteile von mehreren Standorten im Bezug auf die Hochverfügbarkeit liegen auf der Hand. Es erreichten uns allerdings viele Anfragen von Administratoren, die diese Empfehlung als Best Practice oder sogar Vorraussetzung verstanden. Dies ist sicher nicht der Fall. Wenn in Ihrer derzeitigen Umgebung keine Notwendigkeit für eine Verteilung der Server auf mehrere Standorte besteht, dann gilt das auch, wenn Sie diese Umgebung auf Exchange Server 2013 migrieren.

In Exchange 2010 gab es kein automatisiertes Failover zwischen Standorten, da durch das Wegfallen der Verbindung zum anderen Standort kein komplettes Failover des Standortes ausgelöst werden konnte. Man musste den Failover nach Feststellen des Problems sozusagen manuell durchführen. Dies ist mit Exchange 2013 nun möglich. Somit kann Exchange 2013 mit der richtigen Konfiguration auch beim Ausfall eines kompletten Standortes weiter für alle Benutzer verfügbar bleiben.

 

Hierzu wird folgende Verteilung der Server empfohlen:

An jedem Standort befindet sich eine gerade Anzahl an DAG-Membern. An einem dritten Standort steht ein von den anderen Standorten aus erreichbarer Witness-Server. Beim Ausfall eines Standortes stehen somit immernoch mehr als die Hälfte der DAG-Member (inkl. des Witness Server) zur Verfügung um die DAG zu betreiben. Hierbei ist darauf zu achten, das sich an jedem Standort mindestens eine Kopie jeder Datenbank befindet.

Dieser Blogeintrag ist Teil der Serie: Exchange 2013 Ressourcenplanung

Teil 1: Vorraussetzungen für Exchange 2013
Teil 2: Rollenverteilung und Hochverfügbarkeit
Teil 3: Die Gretchenfrage der Virtualisierung – Glaubst du an die Vorteile?
Teil 4: Speicherlösungen – DAS oder SAN?
Teil 5: Berechnung der Ressourcen

UNSERE NÄCHSTEN SCHULUNGEN

Exchange ServerAlexander WachtelExchange Server 2013, Ressourcenplanung