Routing mit Exchange 2007/2010
Diese Seite ist nur relevant, wenn Sie mehr als einen Exchange Server und mehrere Active Directory Standorte betreiben.
Exchange 2007 ändert im Vergleich zu Exchange 2000/2003 das Routingschema erneut komplett. Mittlerweile haben auch die Microsoft Entwickler gemerkt, dass die meisten Administratoren die gleiche Arbeit doppelt haben: Sie pflegen Active Directory Standorte und bislang auch noch Exchange Routinggruppen und entsprechende Connectoren. Dabei sind beide Konfigurationen in den meisten Fällen übereinstimmend. Denn eine Grundregel für beide Welten besagt, dass ein gutes Design Connectoren entlang der WAN-Verbindungen vorsieht.
Exchange 2007 nutzt diese Information, die im Active Directory sowieso schon vorhanden ist und ermittelt daraus seine Leitwege. Allerdings hat sich auch das Routing selbst geändert. Zwischenstationen können übersprungen werden. Doch eins nach dem anderen:
Ermittlung der Route
Für die Verständnis der folgenden Abschnitte ist folgendes wichtig:
- Kein Linkstate = Kein "Up/Down"
Exchange 2007 unterstützt nicht mehr das LinkState-Protokolle. Exchange führt daher keine Tabelle über den Status der Connectoren mit. Dies betrifft aber nur externe Connectoren, da die internen Routinggroup-Connectoren nicht mehr vorhanden sind. - Statisches Routing = kein Rerouting
Das bedeutet aber auch, dass Exchange alle Sitelinks und Connectoren als "immer verfügbar" ansieht. Sollte eine Verbindung also gar nicht mehr möglich sein, dann werden die Mails in einer Queue gepuffert aber nicht über andere Weg umgeleitet. Bei längerfristigen Ausfällen müssen Sie also manuell gegensteuern. (z.B.: Kosten von Sitelinks teurer machen) - Vorhersagbarer Leitweg
Exchange ermittelt anhand der Konfiguration den Weg, den eine Mail nehmen wird. Davon wird dann auch nicht abgewichen..
Es gibt viele Artikel, warum Microsoft das getan hat und das neue Routing hat seine Vor und Nachteile. Fakt ist aber, dass es nun mal so ist und wir damit umgehen müssen. Wie ermittelt Exchange 2007 denn nun den Leitweg für eine Mails ?
- Adressraum
Zuerst schaut Exchange, wohin die Mail muss. Bei Mails an externe Systeme, die über einen Connector angebunden sind, ist der Adressraum entscheidend. Der Connector mit dem "passendsten" Adressraum gewinnt zuerst - Kosten
Gibt es dann noch die Wahl zwischen mehreren Connectoren, dann werden die Kosten herangezogen. Kosten des Connectors im Adressraum und AD-Sitelink-Kosten des Wegs dorthin werden aufaddiert. Der günstigste Weg wird gewählt - Hops
Aber auch hier kann es ja noch mehrere gleich teure und gleich gute Wege geben. Dann werden die Anzahl der AD-Sites einbezogen, die zum Connector durchlaufen werden. Je näher ein Connector ist, desto besser. - Name
Wenn dann noch zwei Wege "gleich" sind, dann wird der Connector gewählt, dessen AD-Site vom Namen her weiter vorne im Alphabet steht.
Über diese Logik wird immer 100% sichergestellt, dass es genau einen vorhersagbaren Leitweg gibt. Das Exchange Team hat die Gründe auf ihrem Blog dargelegt
- Motivations für the Exchange Server 2007 transport redesign
http://blogs.technet.com/b/exchange/archive/2006/11/10/431454.aspx
Solange eine Mail mit mehreren Empfängern den gleichen Weg hat, bleibt sie auch "zusammen". Hubsites habe ich hier noch nicht berücksichtigt. Natürlich gibt es schon eine Lastverteilung und Failoverstrategie innerhalb der AD-Sites mit mehreren HT-Servern, aber wenn ein Connector oder eine AD-Site komplett ausfällt, dann könnte Queueing auftreten. Eine Überwachung von Exchange ist daher schon wichtig.
Routing zwischen zwei Standorten
Das einfachste Bild besteht aus zwei Active Directory Standorten mit einem Sitelink und einer Mail von A nach B. Wie nicht anders zu erwarten, wird der Server die Mail direkt zustellen.
Routing mit drei Standorten
Die erste Veränderung erkennen Sie, wenn Sie nun drei Standorte in einer Kette betrachten und eine Mail von A nach C senden. Im Gegensatz zu Exchange 2000/2003 wird Exchange 2007 versuchen, die Mail direkt zuzustellen.
Der Hintergedanken dabei ist der, dass bei dieser Aufgabenstellung eine Nutzung der Zwischenstation nur Kosten verursacht aber sonst keinen Vorteil bringt. Das Volumen der WAN-Leitung würde nicht verringert werden aber die Zwischenstation müsste CPU und Ressourcen für den Empfang und die Weiterleitung aufbringen. Zudem wäre die Mail auch noch etwas langsamer. Exchange 2003 würde in diesem Fall die Mail über B übertragen,
Routing mit drei Standorten und CC-Mail
Interessant wird das Verhalten aber beim Versand einer Mail an mehrere Empfänger. Wenn in dem Beispiel hier eine Mail von A nach B und C gesendet wird, dann wäre eine Aufteilung der Mail bei A natürlich ungünstig. A müsste die Mail über die Verbindung A-B nach B übertragen und dann noch einmal über A-B/B-C zu C. Die Leitung A-B würde daher doppelt beaufschlagt.
Exchange 2007 leitet daher eine Mail mit beiden Empfängern erst an Server B, welcher die Mail ja sowieso für B empfangen muss und sendet dann die Mail an C weiter. So würde das Verhalten auch Exchange 2000/2003 entsprechen.
Routing mit Ausfall
Den Umweg über einen Zwischenserver (hier B) nimmt Exchange 2007 noch in einem anderen Fall. Exchange 2007 versucht zwar immer erst eine direkte Zustellung, aber wenn die nicht funktioniert (Im Bild ist Leitung B-C down und keine Redundanz durch Router gegeben), dann versucht Exchange 2007 den am Ziel am nächsten stehenden Exchange Server zu erreichen. Dies ist in diesem Fall der Server B, welcher die Mail natürlich zwischenspeichern muss.
Damit ist die Mail schon "nahe" am Ziel und die Wahrscheinlichkeit der Zustellung steigt. Das Verhalten ist aber nicht nur hinsichtlich des Routings unterschiedlich zu Exchange 2003, sondern auch bezüglich der Aktivität. Exchange 2000/2003 lässt eine Mail "liegen", wenn es keinen gültigen Leitweg gibt. Dieses Verhalten war eine große Verbesserung gegenüber Exchange 5.5, welches in solchen Fällen ja Mehrfachübertragungen bis zu Schleifen produziert hat. Exchange 2007 hingegen stellt die Mail immer möglichst nahe an das Ziel zu. Eine Teilstrecke ist in den meisten Fällen daher schon geschafft.
Routing mit Ausfall und CC
Der Vollständigkeit halber schauen wir das gleiche Beispiel noch mit einer Mail an zwei Empfänger an. Sie wissen ja schon, dass A gar nicht direkt zu C zustellen wird, da es in diesem Fall günstiger ist, die Mail an B zuzustellen und B leitet die Mail dann weiter.
Ist nun die Leitung wie im Beispiel "Down", dann bleibt die Mail eben bei B in der Warteschlange, bis es wieder einen direkten oder kürzeren Weg gibt. Übrigens hat Exchange die Mails schon an der Quelle "aufgeteilt". Stichwort "Bifurcation".
Redundanz über IP-Routing
Exchange 2007 erlaubt wie auch Exchange 2000/2003 eine redundante Verbindung zwischen Standorten über andere Standorte. Wenn z.B. ein direkter Weg nicht erreichbar ist, dann würde Exchange natürlich die Mail einen dem Ziel näher stehenden Server senden. Das ist hier aber nicht gemeint. Dieses Beispiel beschreibt den Fall, dass die direkte TCP-Verbindung zwischen den Standorten down ist.
Exchange 2007 fragt natürlich nicht die Router nach dem Status der WAN-Verbindungen, sondern versucht wieder direkt den Zielserver zu erreichen. Wenn es nun redundante Wege von Site.A zu Site-C gibt und die Router danke RIP, OSPB, BGP o.ä. die IP-Pakete umleiten, dann kann der Server A direkt mit seinem Ziel, dem Server C, kommunizieren. Dass die IP-Pakete nun vielleicht aber über andere AD-Sites laufen, bemerkt Exchange nicht. Der Exchange Server wird dabei nicht als Relay o.ä. genutzt, sondern es ist allein eine Sache der Router, hier die Daten korrekt zu übertragen.
Was passiert aber, wenn dies nicht "korrekt" konfiguriert ist ?. Exchange würde versuchen die Gegenstelle zu erreichen. Dies ist nicht möglich und dann stellt sich die Frage ob die Kosten von "Sitelink 3" günstiger sind als die Kosten von "Sitelink 1". Wenn dies der Fall ist, dann sendet Exchange die Mail an den Server, der vermeintlich "günstiger" die Mails weitergeben kann.
Die "Failover"-Funktionen von Exchange 2007 sind daher prinzipiell unterschiedlich als die Lösung des LinkState-Routings von Exchange 2000/2003 (Siehe Routing2000). Wenn es daher von einem Standort zu einem anderen Standort mehrere physikalische Verbindungen gibt, dann müssen Sie ihre Router so einstellen, dass Sie die IP-Pakete auch entsprechend umleiten. Die Anwendung selbst kann nicht bestimmen, über welchen Weg die Mails laufen.
Hub Sites
Auch wenn Exchange 2007 normal versucht, den Zielserver direkt zu erreichen, kann es doch erforderlich oder wünschenswert sein, dass Exchange über Relaystandorte geht. So kann eine Firma an der Stelle z.B.: zentral einen Virenscanner oder Archivlösungen abbinden. Auch kann es ja sein, dass entfernte Standorte nur zeitweise "online" sind und die Mails dann bis zu einer zentralen Hubsite zugestellt werden sollen (z.B. Exchange auf Schiffen) oder einfach die direkte Zustellung unterbunden werden muss.
In diesem Fall kann eine Active Directory Site als "HUB-Site" definiert werden. Mangels grafischer Oberfläche ist die PowerShell zu bemühen
Set-ADSite -Identity Sitename -HubSiteEnabled $true Set-ADSite -Identity Sitename -HubSiteEnabled $false
Ein einfaches "Get-ADSite" liefert die aktuellen Einstellungen als Tabelle.
Get-ADSite Name HubSiteEnabled ---- -------------- Paderborn False
Die entsprechenden Einstellungen sind im Attribut "msExchTransportSiteFlags=1" direkt auf der Site eingetragen. Ein Eintrag "msExchTransportSiteFlags=0" bedeutet, dass es keine Hubsite ist. Zusätzlich speichert Exchange 2007 im Attribut "msExchVersion" noch die Nummer "4535486012416" als Version.
Abweichende Kosten
Exchange nutzt ebenfalls die Kosten der Active Directory Sitelinks zwischen den Active Directory Standorten. Auch hier kann man manuell in die Konfiguration eingreifen und abweichende Kosten für Exchange definieren. Leider gibt es auch hierfür keine grafische Oberfläche, sondern nur die PowerShell:
set-ADSitelink ` -identity DEFAULTIPSITELINK ` -ExchangeCost 100
Auch hier liefert ein get-adsitelink eine Liste der Links und der damit verbundenen Kosten
Name ADCost ExchangeCost Sites ---- ------ ------------ ----- DEFAULTIPSITELINK 100 100 {Paderborn}
Allerdings liefert die Liste so nur die konfigurierten Sitelinks und keine Info über die Kosten zwischen zwei Sites. Ein Sitelink kann ja mehrere Sites als Partner enthalten. Einen "Netzwerkplan" kann man so nicht erstellen.
Die entsprechenden Einstellungen sind im Attribut "cost" bzw. für Exchange abweichende Kosten sind in "msExchCost" des jeweiligen Sitelinks hinterlegt. Zusätzlich speichert Exchange 2007 im Attribut "msExchVersion" noch die Nummer "4535486012416" als Version.
Mixed Umgebung mit Exchange 20007/2003
Wenn Sie Exchange 2007 in einer gemischten Umgebung mit Exchange 2000/2003 einsetzen und mehr als nur die zwei Routingruppen haben, dann sollten Sie prüfen, ob Sie LinkState nicht besser abschalten. Da Exchange 2007 dieses Statusmeldungen nicht unterstützt, können die Exchange 20007/2003 Server nicht erkennen, ob die Verbindungen zwischen den Servern verfügbar sind. Dies kann zu Mailschleifen und unzustellbaren Nachrichten führen, besonders wenn die Mails zwischen zwei Exchange 2000/2003 Routinggruppen "durch die Exchange 2007 Routinggruppe müssen.
- How to Set the SuppressStateChanges Registry Value
http://technet.microsoft.com/en-us/library/875ae7f8-446d-4786-85d2-719ac7093cf6.aspx - Routing Engine: SuppressStateChanges parameter is non-default
http://technet.microsoft.com/en-us/library/aa997564.aspx - Festlegen des Registrierungswerts „SuppressStateChanges“
http://www.microsoft.com/.../exchange/de/guides/E2k3Perf_ScalGuide/875ae7f8-446d-4786-85d2-719ac7093cf6.mspx - 271996 SMTP / Routing Group connector state changes cause needless connector state toggling in Exchange 2000 Server
- 888231 Exchange 2003 cannot control link state Updates that are caused by User version changes
- 832281 Link state issues and routing issues in Exchange 2000 Server and in Exchange Server 2003
Debugging
Durch den Wegfall des "LinkState"-Routings funktioniert mit Exchange 2007 auch das Programm WINROUTE nicht mehr. Aber Exchange 2007 schreibt die aktuelle Konfiguration in eine XML-Datei an folgenden Platz
<lw>:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\Routing
Hier finden Sie mehre Menge XML-Dateien, die die Routingkonfiguration zu dem Zeitpunkt enthalten. Die Auswertung ist ab Exchange 2007 SP1 mit dem Routing Log Viewer möglich.
Weitere Links
- Get-Routingtable Ausgabe der Exchange 2007/2010 Routingeinträge als Tabelle vergleichbar zu ROUTE PRINT
- Routing Log Viewer
- Routinggruppen
- Routing und Kosten
- Routing mit GWART und Link2State
- Routing2000
- Migration 200x auf 2007
- Routingvergleich
- WINROUTE
-
How to smoothly survive the transition from Linkstate to Exchange 2007
routing
http://blogs.technet.com/b/exchange/archive/2006/11/01/430185.aspx - Thoughts on Stale Link State information (Part 1)
http://blogs.technet.com/b/exchange/archive/2004/03/10/87622.aspx - How to smoothly survive the transition from Linkstate to Exchange
2007 routing
http://blogs.technet.com/b/exchange/archive/2006/11/01/430185.aspx - Exchange Server 2007 Active Directory Site and Connector Selection
Algorithms
http://blogs.technet.com/b/exchange/archive/2006/09/14/428920.aspx - Exchange Server 2007 routing load balancing and fault tolerance
http://blogs.technet.com/b/exchange/archive/2007/01/04/432069.aspx - Active Directory Site Links – Naming & Costing
http://briandesmond.com/blog/archive/2007/11/29/active-directory-site-links-naming-costing.aspx - Motivations für the Exchange Server 2007 transport redesign
http://blogs.technet.com/b/exchange/archive/2006/11/10/431454.aspx - Exchange Server 2007 Active Directory Site and Connector Selection
Algorithms
http://blogs.technet.com/b/exchange/archive/2006/09/14/428920.aspx - Exchange Server 2007 routing load balancing and fault tolerance
http://blogs.technet.com/b/exchange/archive/2007/01/04/3397650.aspx