TechNet Magazine > Home > Alle Ausgaben > 2008 > Juli >  EXCHANGE FRAGEN & ANTWORTEN: Lastenausgleich, E...
Exchange Fragen & Antworten Lastenausgleich, Edge-Transport und mehr
Henrik Walther


F. Wir haben mehrere Server in der Produktionsumgebung unseres Unternehmens, die auf Microsoft® Office SharePoint® Server ausgeführt werden. Jeder einzelne Server muss ausgehende Nachrichten über die Hubtransport (HT)-Server in unserer neu bereitgestellten Exchange Server 2007-Infrastruktur weiterleiten. Da wir bei einem SharePoint-Server nur den vollqualifizierten Domänennamen (FQDN) eines einzelnen SMTP (Exchange)-Servers auf der Seite „Zentraladministration | Vorgänge | Einstellungen für ausgehende E-Mail-Nachrichten“ angeben können, wie in Abbildung 1 dargestellt, würde ich gerne wissen, wie wir diese einzelne Fehlerquelle beseitigen können?
Abbildung 1 Einstellungen für ausgehende E-Mail-Nachrichten auf der SharePoint-Seite „Zentraladministration“ (Klicken Sie auf das Bild, um es zu vergrößern)
A. Dies ist eine sehr gute Frage, da hohe Verfügbarkeit in sehr vielen Organisationen wichtig ist, sodass eine einzelne Fehlerquelle in den Produktionsumgebungen des Unternehmens nicht akzeptabel ist. Dies gilt besonders für die Messaging-Dienste und Dienste zur Zusammenarbeit.
Exchange 2007 HT-Server sind standardmäßig stabil. D. h., wenn mehr als ein HT-Server an einem Active Directory®-Standort bereitgestellt wird, und ein HT-Server an diesem Active Directory-Standort nicht verfügbar ist, verwendet der Quell-HT-Server, der versucht, die Nachricht zu übermitteln, den nächsten verfügbaren HT-Server an dem Active Directory-Standort. Dies erfolgt mithilfe von Roundrobin-DNS-Methoden (wenn der erste HT-Server auf der Liste nicht reagiert, wird es mit dem nächsten versucht).
Was die gesamte HT-zu-HT- und Postfachserver-zu-HT-Kommunikation (also die unternehmensinterne Kommunikation) betrifft, ist hohe Verfügbarkeit (oder der Lastenausgleich an sich) nicht wichtig, da es eine systemeigene Exchange 2007-Funktion ist. Doch wenn Sie die HT-Serverrolle auf einem Computer installieren, auf dem auch die Postfachserverrolle installiert ist, sollten Sie bedenken, dass die Postfachserverrolle beim Senden von Nachrichten über den Microsoft Exchange-Mailübergabedienst immer den lokalen HT-Server gegenüber anderen HT-Servern an einem Active Directory-Standort bevorzugt (selbst wenn der lokal installierte HT-Server nicht verfügbar ist).
Die vorstehenden Informationen sind wenig nützlich in Bezug auf SharePoint-Server, doch es ist wichtig, dies zu wissen, bevor wir fortfahren. Da ein HT-Server standardmäßig stabil ist, wird der Lastenausgleich bei unternehmensinterner Kommunikation zwischen den HT-Servern in Exchange 2007 mithilfe des Hardwarelastenausgleichs oder der Windows® Netzwerklastenausgleichsfunktion (WNLB) nicht unterstützt.
Tatsächlich gab es basierend auf der Exchange 2007 RTM-Version keinerlei Unterstützung für den Lastenausgleich von eingehendem SMTP-Datenverkehr zu HT-Servern. Doch Exchange 2007 SP1 ändert dies. Mit SP1 ist der Lastenausgleich der unternehmensinternen Kommunikation mithilfe des Hardwarelastenausgleichs oder der WNLB-Funktion weiterhin nicht möglich (und warum sollte dies auch möglich sein?), doch der Lastenausgleich von eingehendem SMTP-Datenverkehr aus Nicht-Exchange-Quellen (z. B. SharePoint-Servern) und von Exchange-Clients wie IMAP-oder POP-Clients, die ausgehende Nachrichten an die Exchange 2007-Organisation mithilfe des standardmäßigen Clientempfangsconnectors auf dem HT-Server senden, ist möglich.
Um also einen SharePoint-Server so zu konfigurieren, dass er Nachrichten über eine Exchange 2007 SP1-Organisation sendet, können Sie einfach einen DNS-Datensatz in Ihrem Active Directory-DNS erstellen und auf einen Hardwarelastenausgleich verweisen, der den Datenverkehr unter mehreren HT-Servern verteilen kann. Alternativ kann dazu die WNLB-Funktion verwendet werden. Zum Verwenden der letztgenannten Methode konfigurieren Sie das WNLB-Cluster mit einer virtuellen IP-Adresse und FQDN (z. B. mail.contoso.com) und fügen Port 25 (eingehender SMTP-Datenverkehr von Nicht-Exchange-Servern) und 587 (eingehender SMTP-Datenverkehr von Exchange-Clients wie IMAP und POP) auf der Registerkarte „Portregeln“ hinzu. Abbildung 2 zeigt, wie Ihre Registerkarte „Portregeln“ bei dieser Konfiguration aussieht. Möglicherweise möchten Sie auch sicherstellen, dass die spezifische virtuelle NLB-Cluster-IP-Adresse beiden Regeln zugewiesen wird, statt alle IP-Adressen auszuwählen.
Abbildung 2 Definierte Portregeln (Klicken Sie auf das Bild, um es zu vergrößern)
Wenn das NLB-Cluster konfiguriert wurde, müssen Sie einen neuen Empfangsconnector erstellen, der so konfiguriert werden sollte, dass er auf Port 25 abhört und es nur den Servern ermöglicht, Nachrichten mithilfe dieses Connectors zu übertragen, bei denen dies erforderlich ist. Zudem sollten Sie sichergehen, dass dieser Connector die virtuelle NLB-Cluster-IP-Adresse verwendet, die zuvor erstellt wurde.

F. Unsere Messaginginfrastruktur basiert auf Exchange Server 2007. Um unsere Exchange 2007-Postfachserver sowohl auf der Hardware- als auch Speicherebene redundant einzurichten, handelt es sich bei allen um gruppierte Postfachserver auf der Grundlage fortlaufender Clusterreplikations-Technologie (CCR). Sowohl der aktive als auch der passive Knoten in jedem CCR-Cluster befindet sich in demselben physischen Datencenter. Nach dem Aktualisieren unserer Exchange 2007-Server auf SP1 möchten wir die Dienst- und Datenverfügbarkeit durch Replizieren von Postfachdatenbanken auf Postfachservern an einem zweiten Standort mithilfe der neuen, in Exchange 2007 SP1 enthaltenen, fortlaufenden Standbyreplikations (SCR)-Technologie nutzen.
Wir wissen, dass die SCR-Quellen entweder eigenständige Exchange 2007 SP1-Postfachserver oder Postfachclusterserver (CMS) auf der Grundlage der CCR- oder Einzelkopiecluster -Technologie (SCC) sein können. Doch wie sieht es mit den SCR-Zielservern aus?
A. Bei den SCR-Zielservern (auch als SCR-Endpunkte bezeichnet) muss es sich entweder um einen eigenständigen Postfachserver ohne fortlaufende lokale Replikation (LCR) handeln, der für beliebige Speichergruppen aktiviert ist, oder um einen passiven Knoten in einem Windows-Failovercluster (früher als Microsoft Cluster Server bezeichnet), in dem die Postfachserverrolle installiert ist. Dies bedeutet, dass Sie Ihr Failovercluster erstellen und dann die Postfachserverrolle auf einem passiven Knoten in diesem Failovercluster installieren können, doch Sie können keinen gruppierten Postfachserver als SCR-Ziel verwenden.

F. Unsere Organisation verwendet Exchange 2007 als Messagingplattform. Wir haben sogar beschlossen, unsere alte Antispam-/Antiviruslösung im Umkreisnetzwerk durch eine Lösung auf der Grundlage von Exchange 2007-Edge-Transport-Servern mit installierter Forefront™ Security für Exchange zu ersetzen, sodass wir von den mehrfachen Schichten für Nachrichtenschutz und Sicherheit profitieren können. Wir planen, in naher Zukunft mindestens zwei weitere Edge-Transport-Server bereitzustellen.
Das führt mich zu meiner Frage. Wie können wir den Lastenausgleich für eingehende SMTP-Verbindungen zu unserer Nachrichtenschutzlösung, die auf Exchange 2007 Edge-Transport basiert, herstellen und dadurch die Last verteilen und vollständig redundant machen?
A. Wenn es sich bei den Edge-Transport-Servern in Ihrem Umkreisnetzwerk um die mit dem Internet verbundenen SMTP-Server handelt, können Sie einen Ansatz verwenden, der dem in der Microsoft Information Technology-Gruppe (Microsoft IT) verwendeten ähnelt. Microsoft IT hat sechs Edge-Transport-Server bereitgestellt (drei in Redmond und drei im Silicon Valley), die über 16 Millionen eingehende Nachrichten pro Tag verarbeiten (und mehr als 13 Millionen Nachrichten werden als Spam gefiltert).
Microsoft IT hat insgesamt drei MX-Datensätze (Mail Exchange) für die Microsoft.com-Domäne. Dies sind: maila.microsoft.com, mailb.microsoft.com und mailc.microsoft.com (siehe Abbildung 3). Jeder MX-Datensatz wurde mit einer Einstellung von 10 konfiguriert, sodass er mithilfe eines DNS-Roundrobin-Verfahrens zufällig ausgewählt wird. Zusätzlich sind jedem MX-Datensatz zwei IP-Adressen (E-Mail-Hosts) zugeordnet.
Abbildung 3 MX-Datensätze und Internet-Mailhosts für Microsoft.com (Klicken Sie auf das Bild, um es zu vergrößern)
Warum zwei IP-Adressen pro MX-Datensatz? Weil einige MTAs (Message Transfer Agent) immer denselben MX-Datensatz auswählen, unabhängig davon, wie viele MX-Datensätze für eine Domäne konfiguriert wurden. In Bezug auf Exchange Server ist dies seit vielen Jahren (seit Exchange 2000) kein Problem, doch leider gibt es noch immer MTAs, die diesen Entwurfsfehler aufweisen. Unabhängig davon, welcher MTA versucht, eine Nachricht an eine Microsoft.com-Adresse zu liefern, sind also alle SMTP-Verbindungen mithilfe einer Kombination aus DNS-Roundrobin und Lastenausgleich verteilt.

F. Unsere Active Directory-Domäne basiert auf Windows Server® 2003-Domänencontrollern (DCs). Wir sind derzeit in der Planungsphase für den Übergang unserer Windows Server 2003-DCs auf Windows Server 2008 und unserer Exchange 2003-Messagingumgebung auf Exchange Server 2007. Kann dieser Übergang von unserer Active Directory-Domäne auf Windows Server 2008 durch Aktualisieren aller Server, auf denen Windows Server 2003 ausgeführt wird, auf Windows Server 2008 erfolgen, bevor der Übergang der Messagingumgebung von Exchange Server 2003 auf Exchange 2007 erfolgt?
A. Ja, Exchange Server 2003 SP2 wird in einer Active Directory-Domäne, die ganz aus Windows Server 2008-DCs besteht, vollständig unterstützt, sodass Sie Ihren Plan in die Tat umsetzen können. Bedenken Sie jedoch Folgendes: Wenn Sie planen, Windows Server 2008 Read-Only-Domänencontroller (RODCs) zu verwenden, sollten Sie den Empfängeraktualisierungsdienst (RUS) von Exchange so aktualisieren, dass er einen RODC verwendet.

Henrik Walther ist ein Microsoft-zertifizierter Architekt: MVP für Messaging (Auszubildender) und Exchange mit über 14 Jahren Erfahrung im IT-Bereich. Er ist als Technologieentwickler für Interprise Consulting und als Autor technischer Artikel für Biblioso Corp. tätig.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.
Page view tracker