Exchange 2007 Rollen
Erstmals mit Exchange 2007 wird das Konzept der funktionalen Rollen grundlegend verändert. Mit Exchange 2000 und 2003 ist es auch schon möglich, bestimmte Funktionen auf einige Server zu verteilen (z.B.: Frontend/Backend, Connector-Server, OAB-Server, Public Folder Server etc.). Aber jeder Exchange Server enthält doch fast immer den kompletten Funktionsumfang und einige der Funktionen werden einfach nicht mehr verwendet.
Die fünf Rollen
Anders wird dies mit Exchange 2007, welches folgende Rollen unterscheidet. Die genauen Namen der einzelnen Rollen ist noch nicht fixiert.
- Mailbox/Public Folder/Datenbank (Mailbox
Server)
Diese Rolle betreibt die Exchange Datenbank mit den Inhalten. Manche trennen die Funktion "Mailbox" und "PublicFolder" als eigenständige Rollen. Fakt ist aber, dass öffentliche Ordner mit Exchange 2007 und Outlook 2007 nicht mehr erforderlich sind. - Hub/Transport (Hub/Transport)
Diese Rolle ist für die komplette Übertragung der Nachrichten von einem Postfach zum anderen Postfach zuständig. Selbst wenn Absender und Empfänger in der gleichen Datenbank sind, muss diese Rolle aktiv werden. - Client Access (Clientaccess)
Die Clients (Outlook Web Access, WAP, ActiveSync, Outlook) greifen auf diese Rolle zu, die dann ihrerseits auf die Mailboxfunktion zugreift. - Unified Messaging (UM)
Exchange 2007 wird die Funktion enthalten, Sprachnachrichten aufzuzeichnen, per Sprache gesteuert zu werden und Faxnachrichten zu übermitteln. Dies ist auf Aufgabe dieser Rolle. - Edge (Edge)
Diese Funktion ist zwar Teil von "Exchange" als Produkt aber hat keinerlei innige Verbindung zu den anderen Rollen oder gar dem Active Directory. Edge stellt ein System dar, welches zwischen dem Internet und den internen Systemen vermittelt und stellt faktisch ein dediziertes SMTP-Relay mit möglichst wenig Angriffsflächen dar. Das beginnt schon damit, dass der SMTP-Stack nicht mit dem SMTP-Code von Windows oder Exchange identisch ist.
Bei der Zuordnung von Rollen auf Server gibt es zwei Ausnahmen zu beachten:
- Edge
Diese Rolle ist eine "exklusive" Rolle, d.h. kann nicht mit anderen Rollen kombiniert werden. Das ist aber sowieso by Design der Fall, das diese Rolle die Mails aus dem Internet annimmt. Es ist auch nicht zwingend erforderlich, die Edge-Funktion überhaupt zu installieren - Transport/Hub
Diese Rolle ist nicht Clustertauglich. Wenn Sie als die Exchange Mailboxrollen als Cluster installieren, dann muss die Transport Rolle auf einen anderen Server installiert werden. Dies bedeutet aber auch, dass in einem Cluster die Mails immer über den anderen Server gehen, auch wenn Sender und Empfänger in der gleichen Datenbank arbeiten würden.
Auf der anderen Seite bedeutet dies, dass es nicht mehr erforderlich ist, auf jedem Exchange Server auch zwingend einen IIS installieren zu müssen. Das kommt auf jeden Fall der Sicherheit der Systeme zugute. Zudem können mit Ausnahme der Mailbox-Rolle alle anderen Rollen auf mehreren Servern parallel und damit höher verfügbar und skalierbar ausgeführt werden. Die Mailbox-Rolle hingegen kann weiterhin nur mittels Cluster höher verfügbar bereitgestellt werden, Wobei auch hier eine Weiterentwicklung stattfindet.
So arbeiten die Rollen zusammen
All diese fünf Rollen sind natürlich nicht losgelöst zu sehen, sondern arbeiten in einem Verbund miteinander.
Die Trennung der Rollen hat natürlich auch seine Gründe. Hier die wichtigsten:
- Sicherheit
Ein Server ist um so weniger verletzbar, je weniger dienste darauf laufen. Vielen Exchange Administratoren war es daher ein Anliegen, dass auf Exchange nicht mehr alle Dienste erforderlich sind. Durch die Aufteilung ist es nur noch auf dem Server mit der "Client Access Role" erforderlich einen IIS zu installieren. Speziell die Mailboxserver benötigen daher weder einen Webserver noch einen SMTP-Server - Skalierbarkeit
Durch die Verteilung der Rollen verteilt sich natürlich auch die Arbeit. Während der Mailboxserver den Betrieb der Datenbank optimieren kann, sorgt die Transportrolle für die Übermittlung der Nachrichten, die Pufferung in Warteschlangen, das Auffächern von Verteilern etc. Auch die Client Access Rolle konvertiert nun die Inhalte, die dieser Server vom Mailboxserver holt selbständig in HTML/XML. Diese Arbeit hab bei Exchange 2003 immer der Backend Server gemacht. - Optimierung
Die Trennung erlaubt auch die Hardware und deren Anbindung zu optimieren. Schnelle Festplatten für die Mailboxrolle. Hohe Verfügbarkeit der anderen Rollen z.B. durch NLB etc. Ebenso kann ein Mailboxserver viel mehr Speicher zum Cache erhalten, während andere Server mit weniger Speicher auskommen. Teilweise können diese zukünftig sogar virtualisiert werden. - Vereinfachung
Auch die Installation ist ein Stück weit einfacher geworden. Man muss nicht mehr nachträglich Dienste stoppen oder wegnehmen, sondern es werden von vorne herein nur die Rollen und Komponenten installiert, die benötigt werden. - Eigene Entwicklungen
Gerade Exchange 2007 erlaubt viel mehr Eigenentwicklungen. So können Sie in die Transport Rolle mit .NET komplett eigene Businessprozesse abbilden. Bei Exchange 2003 müssten Sie dies auf dem Mailboxserver tun. Das trauen sich viele nicht (ob ihr Code vielleicht nicht stabil genug ist ?) bzw. es war gar nicht einfach möglich, Mails abzufangen.
Rollen und Konflikte
Auch wenn das alles einfach und logisch aussieht, so muss man bedenken, dass es doch Rollen gibt, die sich gegenseitig ausschließen oder zumindest behindern. Es kann eben doch nicht alles mit allem kombiniert werden. Hier ein paar Stichpunkte, was sich schlecht oder gar nicht verträgt:
- Edge muss immer allein sein
Eine Mischform mit anderen Rollen ist nicht möglich - Edge auf Member-Server der Exchange Domäne ist nicht möglich
Der Server mit der Edge-Rolle darf nicht in einer Domäne des Exchange Forests sein. - Edge auf Member-Server oder DC ist nur in anderem Forest möglich
Aber eben nur, wenn die Domäne NICHT zugleich Teil des Exchange Forrest ist. - OAB für PF muss auch PF-Server sein
Damit ein Exchange 2007 Server ein Offline Adressbuch für "alte" Clients erstellen kann, muss er auch die Mailboxrolle tragen und einen Public Folder Store haben - CCR kann OAB generieren
Auch ein CCR Cluster kann ein OAB erzeugen und aktualisieren. Für "alte Clients" muss er dazu aber einen Public Folder Store haben. - CCR muss aber einziger PF sein
Ein CCR, der öffentliche Informationsspeicher hat, muss der einzige Public Folder Store in der gesamten Organisation sein, da ansonsten die PF-Replikation aktiv ist und CCR bei einem "lossy Failover" die Datenbank nicht mehr online schaltet - CAS-Server mit MB kann PF anlegen
Man kann einen Server, der primäre als CAS/HT arbeitet, auch noch eine Mailboxrolle verpassen und damit als OAB-Generations Server mit öffentlichen Ordnern dienen. - CAS mit MB ist kein "echter" Frontend" mehr
Ein CAS-Server, kann dann aber nicht mehr korrekt alte Exchange 2003 Clients auf ihren Server umleiten. (redirect)
Sie sehen also dass es durchaus zu überlegen ist, welche Rollen auf wie vielen Servern verteilt werden müssen, denn neben den fünf Rollen gibt es eine noch größere Anzahl an Funktionen der Rollen, deren Abhängigkeiten auch noch berücksichtigt werden müssen. Die Liste ist sicher nicht vollständig.
Platzbedarf
Es ist eigentlich nicht sinnvoll, den Platzbedarf der einzelnen Rollen aufzuführen, da man heutige Server sicher nie so knapp bemessen würde, dass es eng wird. Dazu sind Gigabytes zu "billig". Aber für Test und VM-Umgebungen ist es schon wieder ein Unterschied, ob der Server 10 oder 20 GB virtuell zugeteilt bekommt. Auch wer seine Festplatten partitioniert, um Bereich voneinander abzutrennen braucht ein paar Hinweise.
Die folgenden Daten wurden von dem Setupfenster extrahiert, in dem man die Rollen einzeln anwählen kann. Der Bedarf für die erforderlichen Komponente wie MMC3.Powershell, IIS ist nicht gesondert aufgeführt.
| Rolle | Platzbedarf der Rolle |
|---|---|
| Mailbox, (Single, CCR) | 334 MB |
| Client Access | 298 MB |
| Hubt/Transport | 179 MB |
| Edge | 308 MB |
| Unified Communication | 412 MB |
| Management Tools | 389 MB |
Beachten Sie, dass die Management Tools immer mit installiert werden müssen. Die Werte sind als Minimalwerte der Installation zu verstehen und der Platzbedarf wird natürlich nicht nur durch die Datenbanken, sondern auch durch Transaktionsprotokolle, das Messagetracking, IIS-Logs, Queues etc. weiter wachsen. Und sicher wird das ein oder andere Sprachpakete für Unified Messaging noch mehr Platz benötigen.
Weitere Links
-
Microsoft Exchange Server 2007 > Planning and Architecture > Technical
Architecture Server Roles
http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/e22b66af-06d3-49d4-91af-2156e9dcf21e.mspx - Exchange 12 Server Roles and Disk IO
http://blogs.technet.com/b/exchange/archive/2006/04/07/424645.aspx - Understanding Exchange Server 2007 server roles.
http://blogs.technet.com/b/exchange/archive/2006/09/12/428880.aspx
