Exchange 2013 Serverrollen

Lange wurde uns mit Exchange 2007/2010 erzählt, dass die Trennung in Rollen der Sicherheit, Skalierbarkeit und Vereinfachung dient. CAS, HUB, MAILBOX waren schön zu trennen und in idealen Umgebungen (ohne Public Folder) musste man für Outlook Clients nur das CASArray erreichbar machen. Das Mailbox-Backend als Cluster konnte komplett versteckt sein.

Diese Trennung hatte aber auch Nachteile, z.B. dass man viele Server benötigt hat, dass ein Loadbalancer den Client immer zum gleichen CAS-Server lenken musste und dass es bei einer Kombination von 4 Rollen insgesamt 2^4-1 = 15 mögliche Kombinationen allein auf einem Server gab. Nicht gerade einen "Wunschtraum" für Qualitätstester von Abhängigkeiten. Zudem muss der Client immer auf dem gleichen CAS-Server bleiben, der MOMT bereit gestellt hat, was zusätzliche Anforderungen an Loadbalancer stellt.

Um es kurz zu machen: Es wird nur noch zwei "Rollen" geben, was auch im Setup zu sehen ist:

Die Management Rolls ist per Default immer aktiv

  • Mailbox (eigentlich Backend)
    Dies ist ein Server, der bislang alle Rollen (außer Edge) vereint, d.h. er stellt Datenbanken, MAPI-Dienste, OWA-Dienste und Transportdienste bereit. Und kann im Cluster laufen. Erstmals ist der Information Store komplett neu als Managed Code geschrieben worden. Hoffen wir, dass die Codequalität ausreichend gut ist.
  • Client Access (Frontend)
    Hinzu kommt nun aber ein "intelligenter" Reverse Proxy. Die Clients verbinden sich gegen den oder die Frontend-Server, die aber nicht viel mehr machen, als den Backendserver zu suchen, auf dem die aktive Datenbank des Benutzers liegt. Es ist also egal, über welchen Frontend der Client letztlich zugreift, da dieser die Verbindung einfach zum Backend gibt. Eine Art TCP-Proxy für Client-Traffic, SMTP, SIP, welche die Anfragen an den aktiven Backend weiter geben.

Das Ergebnis dieser Änderung ist, dass jeder Server in sich autark und eigenständig ist. Der Ausfall eines Server würde nur die Postfächer auf diesem Server betreffen und selbst dann kann per Cluster ein anderer Server diese Funktion übernehmen und die Frontend-Server leiten die Anfragen zum neuen Server. Zudem gibt es sehr viel weniger Server-Server Verbindungen, da der Client quasi die CAS-Rolle auf dem Server erreicht, der auch die Mailbox hostet. Das ist Vorteil gegenüber der alten Exchange 2010 DAG mit auf dem Cluster installierten CAS-Rollen und Loadbalancer davor. Hier könnte es sein, dass ein Client durch den Loadbalancer auf dem einen CAS landet, der dann aber zum anderen Knoten muss, weil dort die Datenbank online ist.

Der Frontend ist nun ein Weichensteller, der den Status der Dienste kennt. Wer natürlich weiterhin mehrere dieser Server aus Gründen der Verfügbarkeit und Skalierung aufstellt, benötigt weiterhin eine Technik zum Verteilen der Client. Das kann NLB oder ein Loadbalancer sein. Vermutlich wird aber auch hier DNS-Loadbalancing möglich werden. Die Grenzen von DNS-Loadbalancing sind aber, dass Anwendungen eben selbständig die alternativen Adressen versuchen müssen. Outlook wird das zukünftig vermutlich können, aber eine Browser (OWA) oder ein SMTP/POP/IMAP-Client eher nicht.

Mein Tipp: Planen sie daher einen Loadbalancer ein, der aber nun nur noch Layer 4 ohne komplexe Affinität oder SSL-Offloading bereit stellen muss und daher weniger leistungsfähig und damit günstiger sein kann.

Weitere Links