Exchange 2010: Design-Überlegungen

In meiner Tätigkeit als Consultant und Engineer sehe ich bei Kunden oft ähnliche Exchange 2010 Designs. In diesem Artikel möchte ich einige davon durchleuchten und auf Einschränkungen hinweisen, die manchmal gar nicht erkannt werden.

Ein einzelner virtualisierter Server

Bei diesem Design sind alle Rollen auf einer einzigen virtuellen Maschine installiert. Dieses Bild treffe ich vor allem bei ganz kleinen Kunden an, es kann aber auch in Umgebungen mit ein paar hundert Mailboxen vorkommen.

Zuerst das Positive: Die Lösung ist sehr einfach zu implementieren. Es muss kein DAG (Database Availability Group) und kein Loadbalancing implementiert und verwaltet werden. Dies hat allerdings seinen Preis.

Die Verfügbarkeit leidet darunter und selbst das HA Feature der Virtualisierungsplattform (z.B. Hyper-V oder vSphere) hilft dabei nicht viel. Es kann zwar den Hardware-Ausfall abfangen, aber auch nur crash-consistent, das heisst der Server verhält sich wie nach einem Stromausfall und wird frisch auf einem anderen Knoten gestartet. Sollte hingegen ein einzelner Dienst des Exchange ein Problem aufweisen, hilft bei diesem Design nur schnellstmögliche Benachrichtigung des Administrators, damit dieser das Problem lösen kann. Der Failover Cluster, der einer Database Availability Group zugrunde liegt, würde in den meisten Fällen automatisch eine passive Datenbankkopie aktivieren und so den Unterbruch für die Benutzer kürzer halten als es ein Reboot vermag.

Eine weitere Einschränkung ergibt sich aus der Tatsache, dass die Daten nur einmal vorhanden sind. Sollte die Datenbank ein Problem aufweisen, muss in den meisten Fällen eine Wiederherstellung aus dem Backup ausgeführt werden – potenziell mit Datenverlust und Ausfallzeit. Das Feature «Page Patching» könnte in Zusammenhang mit einer Database Availability Group einzelne korrupte Datenbankseiten automatisch aus einer anderen DB-Kopie wiederherstellen und so die Abhängigkeit von einem Backup verringern.

Zu guter Letzt sind alle Benutzer auf der gleichen Installation. Bei Problemen sind auch immer alle betroffen. Dies gilt auch für Performance-Mängel – häufig anzutreffen bei virtuellen Infrastrukturen von Kleinbetrieben mit wenig Know-how.

Zwei Mailbox-Server in einer DAG und ein virtualisierter CAS/HT Server

Bei dieser Lösung wird eine Database Availability Group mit zwei physischen oder virtualisierten Mailboxservern gebildet und zusätzlich ein virtualiserter CAS/HT Server (Client Access/Hub Transport) implementiert. Eine Variante hiervon vereint die HT-Rolle mit den Mailboxservern statt dem CAS.

Die Verfügbarkeit der Mailboxserver und der Datenbanken ist in diesem Design verbessert. Allerdings hat dies auf die Verfügbarkeit aus Sicht des Endbenutzers keinen Einfluss, da fast alle Zugriffe (auch MAPI über RPC für interne Outlook-Clients) über die CAS-Rolle abgewickelt werden. Für diejenigen, die es ganz genau nehmen: MAPI über RPC auf Public Folder wird in Exchange 2010 noch auf den Mailboxservern terminiert und ist somit die Ausnahme.

Auch die erhöhte Anzahl Lizenzen ist ein Nachteil. Es braucht je drei Betriebssystem- und Exchange-Lizenzen. Dann kommen noch eventuelle Lizenzen für Backup- und Überwachungslösungen hinzu. Die zusätzlichen Server müssen auch gewartet werden, was den Aufwand für diese Lösung nochmals vergrössert. Bezüglich Wartung besteht derselbe Negativ-Punkt wie bei der Ein-Server-Lösung: Arbeiten am CAS Server führt für die Benutzer zu einem spürbaren Unterbruch.

Zwei Mailbox-Server in einer DAG und zwei CAS/HT Server mit Windows NLB

Diese Lösung scheint ideal, da hier die Verfügbarkeit der Mailboxserver und der Client Access/Hub Transport Server berücksichtigt wurde.

Aber es gibt auch hier einige Einschränkungen. Die Anzahl benötigter Lizenzen ist eine davon. Vier Betriebssystem- und ebenso viele Exchange-Lizenzen sind nötig, da sich das für DAG benötigte Feature «Failover Clustering» und «Windows Network Loadbalancing» für die CAS/HT Server gegenseitig ausschliessen. Auch erhöhter Aufwand für Management und Wartung sind eine Folge der vielen Server.

Dann ist WNLB (Windows Network Loadbalancing) keine ideale Lösung für Exchange. Im Gegensatz zu einem Hardware Loadbalancer kann WNLB keine Services überwachen. Solange der CAS Server also Heartbeats schickt, bekommt er auch Client-Anfragen, selbst wenn die Exchange Services gar nicht mehr laufen. Zusätzlich unterstützt WNLB nur Affinität aufgrund der Source IP-Adresse. Das bedeutet, ein Client mit der gleichen IP-Adresse wird bis zum Timeout der Verbindung immer an den gleichen CAS Server weitergeleitet. Dies ist aus zwei Gründen unglücklich: Hinter einem NAT Device (z.B. Firewall, Zugriff aus dem Internet) haben alle Clients die gleiche IP und falls die Adresse oft wechselt (z.B. WLAN Roaming), funktioniert es auch nicht optimal.

Noch ein Wort zu Virtualisierung …

Zwar unterstützt Microsoft die Virtualisierung aller Rollen. Allerdings wird oft vergessen, dass die Ressourcen reserviert sein müssen. Exchange nimmt es einem ganz schön übel, wenn statt der versprochenen 16 GB RAM plötzlich nur noch 4 da sind und der Rest auf die Disks ausgelagert wird.

Weiter wird mit Exchange 2010 kein NAS (Network Attached Storage) als Speicherort für Datenbanken und Transaktionslogs unterstützt – also kein NFS Share, wie er häufig in vSphere-Installationen anzutreffen ist.

Die Verteilung der Rollen muss unbedingt speziell beachtet werden. Szenarien, in denen die VMs mit den gleichen Rollen auf dem gleichen Host laufen, müssen über Anti-Affinitätsregeln ausgeschlossen werden.

Fazit

Die drei Lösungsansätze funktionieren zwar – allerdings mit markanten Einschränkungen. Was ist denn nun das optimale Design? Die folgende Grafik zeigt ein grobes Beispiel.

Weitere Details zur Umsetzung dieser Lösung oder zur Verwaltung von Exchange erhalten Sie in unseren Seminaren zu Exchange.