(0) exportieren Drucken
Alle erweitern
Verwandte Hilfethemen
Loading
Keine Ressourcen gefunden
Verwandte Blog-Artikel
Loading
Keine Ressourcen gefunden
Erweitern Minimieren

Grundlegendes zu SMTP-Failover und Lastenausgleich im Transport

Exchange 2010
 

Gilt für: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Letztes Änderungsdatum des Themas: 2012-01-13

Wenn in Ihrer Organisation mehrere Hub-Transport-Server vorhanden sind, verteilt Exchange den E-Mail-Verkehr automatisch auf alle Hub-Transport-Server in der Organisation. Die Last kann gleichmäßig verteilt werden, wenn alle Server verfügbar sind. Wenn jedoch mindestens ein Server nicht verfügbar ist, wird die Lastverteilung auf den übrigen Servern möglicherweise ungleichmäßig, insbesondere, wenn die Organisation auf mehrere Active Directory-Standorte verteilt ist.

In Microsoft Exchange Server 2010 Service Pack 1 (SP1) wurden verschiedene Verbesserungen am Entscheidungsmechanismus für die Lastverteilung zwischen Hub-Transport-Servern vorgenommen.

Möchten Sie wissen, welche Verwaltungsaufgaben es im Zusammenhang mit dem Nachrichtenrouting gibt? Informationen hierzu finden Sie unter Verwalten von Nachrichtenrouting.

Inhalt

Verhaltensweisen von Exchange Server 2010 RTM

Verbesserungen an Exchange 2010 SP1

Windows-Netzwerklastenausgleichs- oder Drittanbieter-Lastenausgleichslösungen mit Transportservern

In der RTM-Version (Release to Manufacturing) von Exchange 2010 bestimmt anfänglich der Server den nächsten Hop für Nachrichten, die von einem Transportserver zum selben Ziel weitergeleitet werden müssen. Wenn mehrere Zielserver für diesen nächsten Hop vorhanden sind, führt er mithilfe des Roundrobin-Verfahrens des erweiterten DNS (Domain Name System) einen Lastenausgleich der Verbindung durch, die für die gleichmäßige Zustellung von Nachrichten auf Zielservern verwendet wird. Stellen Sie sich beispielsweise eine Topologie mit zwei Active Directory-Standorten und je drei Hub-Transport-Servern vor (wie in der folgenden Abbildung gezeigt). Wenn ein Hub-Transport-Server an Standort A, beispielsweise Hub02, eine Nachricht an Standort B senden muss, ist der nächste Hop für diese Nachricht Standort B. Es gibt drei mögliche Ziele für den nächsten Hop: Hub04, Hub05 und Hub06. Der Server verteilt die Anzahl an Verbindungen gleichmäßig auf diese drei Ziele, wie in der folgenden Abbildung gezeigt. Diese Aktion führt mit der Zeit zu einer gleichmäßigen Verteilung von Nachrichten pro Verbindung.

Lastenausgleich in Exchange Server 2010 RTM

Transportlastenausgleich in Exchange 2010 RTM

Genauso verteilen Hub-Transport-Server an Standort B die Anzahl von Nachrichten, die an Empfänger an Standort A gesendet wurden, gleichmäßig auf Hub01, Hub02 und Hub03. Da "Edge01" Standort A abonniert hat, sind die Ziele für den nächsten Hop für an das Internet gesendete Nachrichten Hub01, Hub02 und Hub03.

Es tritt ein Problem auf, wenn mindestens ein Server im nächsten Hop nicht verfügbar ist. Angenommen, Hub04 ist beispielsweise an Standort B nicht für eine geplante Wartung verfügbar. Die Server an Standort A überwachen nicht die Verfügbarkeit der Server an Standort B. Die Server an Standort A verteilen die Last für Standort B auf die drei Hub-Transport-Server an diesem Standort. Etwa ein Drittel dieser Verbindungen wird jedoch ohne Erfolg an Hub04 gesendet. Für diese Verbindungen wird ein Failover auf den nächsten verfügbaren Server durchgeführt, und einer der Hub-Transport-Server an Standort B wird erheblich mehr Last als die anderen Server verarbeiten, wie in der folgenden Abbildung dargestellt.

Ungleicher Lastenausgleich

Unausgewogener Lastenausgleich in Exchange 2010 RTM

Dieses unerwünschte Verhalten tritt möglicherweise auf, wenn ein Server im nächsten Hop, der typischerweise mehr als zwei Ziele hat, nicht verfügbar ist. Der nächste Hop kann ein anderer Active Directory-Standort, wie im vorherigen Beispiel dargestellt, oder ein Connector sein, für den mehrere Hub-Transport-Server als Quellserver aufgelistet werden (beispielsweise der Sendeconnector zum abonnierten Edge-Transport-Server in der Topologie, die in den vorherigen Abbildungen dargestellt ist).

Dies stellt kein Problem für E-Mail-Übertragungen von Postfachservern dar. Der E-Mail-Übertragungsdienst erkennt nicht verfügbare Hub-Transport-Server am Standort und unterlässt die Zustellung an diese Server. In dem zuvor gezeigten Beispiel muss einer der Hub-Transport-Server an Standort B zwar möglicherweise eine höhere Last aus dem standortübergreifenden Datenverkehr verarbeiten, doch die von den Postfachservern an Standort B generierte Last wird gleichmäßig zwischen Hub05 und Hub06 aufgeteilt.

Verhaltensweisen von Exchange Server 2010 RTM

Zur Behebung der im vorherigen Abschnitt beschriebenen Probleme wurde eine neue Komponente namens Selektor fehlerfreier Server in Exchange 2010 SP1 eingeführt. Der Selektor fehlerfreier Server führt eine Liste mit nicht verfügbaren Servern. Die Liste wird vom erweiterten DNS verwendet, um nicht verfügbare Server bei der Anwendung von Roundrobin-Logik für den Lastenausgleich zu filtern. Stellen Sie anhand der in der vorherigen Abbildung gezeigten problematischen Situation dar, wie der Selektor fehlerfreier Server beim Lastenausgleich unterstützt. In Exchange 2010 SP1 wird vom erweiterten DNS zunächst eine Liste möglicher Ziele im nächsten Hop, Standort B, erstellt. Anschließend wird der Selektor fehlerfreier Server aufgefordert, die Liste zu filtern. Der Selektor fehlerfreier Server berichtet, dass Hub04 für den nächsten Hop, Standort B, fehlerhaft ist. Das erweiterte DNS entfernt Hub04 aus der Liste möglicher Ziele für den nächsten Hop, Standort B, und verwendet den Roundrobin-Lastenausgleich nur zwischen Hub05 und Hub06, wie in der folgenden Abbildung gezeigt wird.

Lastenausgleich mit dem Selektor fehlerfreier Server

Lastenausgleich mit Selektor fehlerfreier Server

In seiner einfachsten Form überwacht der Selektor möglicherweise fehlerhafte Server, um diese Server beim Roundrobin-Lastenausgleich nicht zu berücksichtigen. Aus der Sicht des Selektors fehlerfreier Server wird ein fehlerhafter Server als Server definiert, der bei einem Verbindungsversuch einen beliebigen Windows Sockets-Fehlercode (Winsock) zurückgibt.

Für jeden fehlerhaften Server speichert der Selektor fehlerfreier Server die folgenden Informationen:

  • Server-IP-Adresse

  • Anzahl von Wiederholungen

  • Zeitpunkt der letzten Wiederholung

Wenn ein Server als fehlerhaft markiert ist, stellt der Selektor fehlerfreier Server sicher, dass die Verbindungsversuche zu diesem bestimmten Server wiederholt werden, wenn der Server wieder online ist. Der Selektor fehlerfreier Server verwendet die folgenden Einstellungen, um zu bestimmen, wie häufig die Verbindungsversuche zu einem fehlerhaften Server wiederholt werden.

  • QueueGlitchRetryInterval und QueueGlitchRetryCount   Diese Einstellungen bestimmen, wie oft und in welchem Intervall der Selektor fehlerfreier Server einen Verbindungsversuch zu bestimmten Servern wiederholt, wenn diese als fehlerhaft markiert wurden. Diese Einstellungen werden in der Datei "EdgeTransport.exe.config" konfiguriert. Die Standardwerte für diese Einstellungen sind 1 Minute und 4 Wiederholungen. Diese Werte sagen aus, dass in der Standardkonfiguration ein Verbindungsversuch zu einem fehlerhaften Server jede Minute insgesamt vier Mal wiederholt wird.

  • TransientFailureRetryInterval und TransientFailureRetryCount   Wenn ein fehlerhafter Server nicht verfügbar ist, werden diese Einstellungen vom Selektor fehlerfreier Server verwendet, um die Frequenz für den nächsten Satz an Wiederholungen zu bestimmen. Diese Einstellungen werden für jeden Transportserver konfiguriert. Die Standardwerte sind 5 Minuten (10 Minuten auf einem Edge-Transport-Server) und 6 Wiederholungen. Diese Werte sagen aus, dass in der Standardkonfiguration ein Verbindungsversuch zu einem fehlerhaften Server alle fünf Minuten insgesamt sechs Mal nach den ersten vier Minuten wiederholt wird.

  • OutboundConnectionFailureRetryInterval   Wenn ein fehlerhafter Server nicht verfügbar ist, wiederholt der Selektor fehlerfreier Server einen Verbindungsversuch in der durch diesen Parameter vorgegebenen Frequenz. Diese Einstellung wird für jeden Transportserver konfiguriert. Der Standardwert beträgt 10 Minuten (30 Minuten auf einem Edge-Transport-Server). Das heißt, dass in der Standardkonfiguration ein Verbindungsversuch zu einem fehlerhaften Server alle zehn Minuten nach den ersten 34 Minuten wiederholt wird.

Schrittweise Anleitungen zum Konfigurieren dieser Einstellungen finden Sie unter Konfigurieren von Wiederholungsintervallen, Intervallen für die erneute Übermittlung und Ablaufintervallen für Nachrichten.

Wenn es Zeit für die Wiederholung eines Verbindungsversuchs ist, lässt der Selektor fehlerfreier Server nur einen Verbindungsversuch zu einem fehlerhaften Server zu. Wenn diese Verbindung erfolgreich ist, benachrichtigt die von SMTP ausgehende Komponente den Selektor fehlerfreier Server. Zu diesem Zeitpunkt entfernt der Selektor fehlerfreier Server den Server aus der Liste fehlerhafter Server.

Die Komponente für Shadow-Redundanz des Transports umfasst eine Taktfunktion. Der Takt ist eine einfache SMTP-Verbindung, die verwendet wird, um den Status von zuvor an den Zielserver übermittelten Nachrichten abzufragen. Die Filterung des Selektors fehlerfreier Server verhindert nicht, dass der Shadow-Redundanz-Manager Taktverbindungsversuche durchführt. Wenn ein Server über Shadow-Nachrichten verfügt, die an einen fehlerhaften Server übermittelt wurden, wird versucht, eine Taktverbindung mit diesem Server herzustellen. Ist eine solche Taktverbindung zu einem fehlerhaften Server erfolgreich, wird dieser Zielserver sofort vom Selektor fehlerfreier Server aus der Liste der fehlerhaften Server entfernt.

Weitere Informationen zu Shadow-Redundanz und Takt finden Sie unter Grundlegendes zur Shadow-Redundanz.

In Exchange 2010 SP1 enthalten Konnektivitätsprotokolle Diagnoseinformationen für den Selektor fehlerfreier Server und erweiterte Lastenausgleichsfunktionen. Wenn ein Server der Liste fehlerhafter Server hinzugefügt wird, wird dieses Ereignis im Konnektivitätsprotokoll protokolliert. Suchen Sie den Ausdruck MarkedUnhealthy im Konnektivitätsprotokoll, um dieses Ereignis zu ermitteln. In der Zeile mit diesem Ausdruck finden Sie die folgenden Informationen:

  • IP-Adresse des Zielhosts

  • Vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) des Zielhosts

  • Empfangener Winsock-Fehler

  • Status: MarkedUnhealthy

  • Aktuelle Fehleranzahl

  • Zeitpunkt der nächsten Wiederholung

Die Analyse des in diesem Eintrag angegebenen Winsock-Fehlercodes lässt Sie die Ursache des Fehlers erkennen. Eine vollständige Liste von Winsock-Fehlercodes und den zugehörigen Definitionen finden Sie unter Windows Sockets-Fehlercodes (möglicherweise in englischer Sprache).

Sie können außerdem bestimmen, wie viele Verbindungsversuche fehlgeschlagen sind, und wann der nächste geplante Verbindungsversuch zum Zielserver stattfinden soll, indem Sie die Felder Current Failure Count und Next Retry Time analysieren.

Sie müssen die Konnektivitätsprotokollierung auf den Transportservern aktivieren, um die Diagnoseinformationen anzeigen zu können. Konnektivitätsprotokolle sind auf Hub-Transport- und Edge-Transport-Servern standardmäßig deaktiviert. Weitere Informationen zum Konfigurieren der Konnektivitätsprotokollierung finden Sie unter Konfigurieren der Konnektivitätsprotokollierung.

Verhaltensweisen von Exchange Server 2010 RTM

Wie weiter oben in diesem Thema beschrieben, erfolgt in Exchange 2010 für den gesamten organisationsinternen Nachrichtenverkehr zwischen Edge-Transport-, Hub-Transport- und Postfachservern automatisch der Lastenausgleich mittels erweitertem DNS. Diese Funktionalität deckt jedoch nicht den Lastenausgleich für Nachrichten ab, die von Exchange-fremden Quellen empfangen werden, beispielsweise externen E-Mail-Servern, Antispam- oder Antivirenlösungen von Drittanbietern, beliebigen internen E-Mail-Servern außerhalb der Exchange-Organisation, Branchenanwendungen und POP- oder IMAP-basierten E-Mail-Clients.

Wenn Sie eine oder mehrere dieser E-Mail-Quellen verwenden, haben Sie die Möglichkeit, für den Lastenausgleich des eingehenden SMTP-Nachrichtenverkehrs einen einheitlichen SMTP-Namespace (beispielsweise "smtp.contoso.com") zu nutzen, um externe E-Mail-Nachrichten auf die Transport-Server innerhalb der Organisation zu verteilen. Es werden sowohl der Windows-Netzwerklastenausgleich als auch hardwarebasierte Lastenausgleichslösungen von Drittanbietern unterstützt. Eine Liste mit Lastenausgleichslösungen, die vom Anbieter getestet wurden und für die von Microsoft überprüft wurde, dass sie die Anforderungen von Exchange 2010 erfüllen, finden Sie unter Bereitstellung des Microsoft Unified Communications-Lastenausgleichs (möglicherweise in englischer Sprache).

WichtigWichtig:
Die Verwendung einer Lastenausgleichslösung zur Verteilung des Nachrichtenverkehrs zwischen den Exchange-Servern in Ihrer Organisation wird nicht unterstützt. Der Nachrichtenverkehr zwischen den Exchange-Servern muss von jeder in Ihrer Umgebung bereitgestellten Lastenausgleichslösung ausgeschlossen werden.

Der gängigste Fall ist die Verarbeitung eingehender Nachrichten aus dem Internet. Es ist nicht nötig, eine Lastenausgleichslösung bereitzustellen, um die Last auf Ihre Edge-Transport-Server zu verteilen. Sie erreichen dies, wie in der folgenden Abbildung gezeigt, mithilfe von DNS-Roundrobin- und MX-Einträgen (Mail-Exchanger), die den gleichen Präferenzwert aufweisen.

Lastenausgleich für Nachrichten aus dem Internet mithilfe von DNS-Roundrobin- und MX-Einträgen

Lastenausgleich mithilfe von MX-Einträgen

Wenn Sie sich dafür entscheiden, den Windows-Netzwerklastenausgleich oder eine hardwarebasierte Lastenausgleichslösung für die Verteilung von Nachrichten zu verwenden, die aus dem Internet eingehen, müssen Sie einen einzelnen MX-Eintrag veröffentlichen, der auf die Lastenausgleichslösung verweist. Die Lastenausgleichslösung verteilt eingehende Nachrichten daraufhin an alle in der Konfiguration aufgeführten Edge-Transport-Server, wie in der folgenden Abbildung gezeigt wird.

Verteilen von Nachrichten aus dem Internet mithilfe einer Lastenausgleichslösung

Lastenausgleich für Internetnachrichten per Hardwarelastenausgleich

Von Exchange 2010 werden zum Akzeptieren eingehender Nachrichten Empfangsconnectors verwendet. Wenn ein Exchange 2010-Hub-Transport-Server eine E-Mail-Nachricht mittels SMTP über den TCP-Port 25 empfängt, wird sie standardmäßig von dem Empfangsconnector "Standardempfangsconnector" verarbeitet.

Wenn ein POP- oder IMAP-Client eine E-Mail-Nachricht an einen Exchange 2010-Hub-Transport-Server übermittelt, wird die Nachricht standardmäßig über den TCP-Port 587 übermittelt. Das bedeutet, dass E-Mail-Nachrichten, die von POP- oder IMAP-Clients übermittelt werden, von dem separaten Empfangsconnector "Standard-Clientempfangsconnector" verarbeitet werden.

Wenn Sie beabsichtigen, eine Lastenausgleichslösung vor Ihren Hub-Transport-Servern zu platzieren, sollten Sie hierfür einen separaten Empfangsconnector erstellen und sicherstellen, dass der Lastenausgleich nur für Nachrichtenverkehr erfolgt, der von diesem speziellen Connector verarbeitet wird. Sie erreichen dies, indem Sie eine zusätzliche IP-Adresse zum Hub-Transport-Server hinzufügen und diese IP-Adresse dem neuen Empfangsconnector zuordnen. Darüber hinaus sollte am Empfangsconnector die Option Exchange Server-Authentifizierung deaktiviert werden, damit sichergestellt ist, dass Exchange-Verkehr nicht über diesen Connector weitergeleitet wird. In der folgenden Abbildung ist eine Konfiguration dargestellt, in der eine Lastenausgleichslösung verwendet wird, um Nachrichten von POP3- oder IMAP4-Clients und Exchange-fremden SMTP-Servern auf zwei Hub-Transport-Server aufzuteilen.

Lastenausgleich bei Exchange-fremden Nachrichten für Hub-Transport-Server

Lastenausgleich für Hub-Transport-Server per Hardwarelastenausgleich

Der Windows-Netzwerklastenausgleich ist die gängigste softwarebasierte Lastenausgleichslösung für Exchange-Server. Die Bereitstellung des Windows-Netzwerklastenausgleichs für Exchange 2010-Hub-Transport-Server ist mit einigen Einschränkungen verbunden:

  • Der Windows-Netzwerklastenausgleich kann nicht auf Exchange-Servern verwendet werden, wenn sowohl die Hub-Transport- als auch die Postfachserverrolle auf dem Server ausgeführt werden und der Server auch einer Database Availability Group (DAG) angehört.

    Dies liegt daran, dass der Windows-Netzwerklastenausgleich nicht mit der Windows-Failoverclusterfunktion kompatibel ist. Wenn Sie eine Exchange 2010-DAG verwenden und den Windows-Netzwerklastenausgleich verwenden möchten, müssen Hub-Transport-Serverrolle und Postfachserverrolle auf separaten Computern ausgeführt werden. Darüber hinaus wirkt sich der Windows-Netzwerklastenausgleich auf das Nachrichtenrouting aus, wenn sich das DAG-Mitglied und die Hub-Transport-Serverrolle auf dem gleichen Server befinden. Weitere Informationen finden Sie unter Koexistenz von Hub-Transport- und Postfachserverrollen bei Verwendung von Datenbankverfügbarkeitsgruppen.

  • Es wird davon abgeraten, mehr als acht Hub-Transport-Server in einem Array mit Windows-Netzwerklastenausgleich zu platzieren. Wenn der Lastenausgleich für mehr als acht Hub-Transport-Server notwendig ist, sollten Sie eine hardwarebasierte Lösung bereitstellen.

  • Der Windows-Netzwerklastenausgleich erkennt keine Dienstausfälle.

    Es werden nur Serverausfälle anhand der IP-Adresse erkannt. Wenn der Exchange-Transportdienst ausfällt, der Server jedoch noch funktioniert, erkennt der Windows-Netzwerklastenausgleich den Ausfall nicht und leitet eingehende E-Mail-Nachrichten weiterhin an diesen Hub-Transport-Server weiter. Ein Benutzereingriff ist erforderlich, um den von dem Ausfall betroffenen Hub-Transport-Server aus dem Lastenausgleichspool zu entfernen.

  • Die Konfiguration des Windows-Netzwerklastenausgleichs kann zur Überflutung von Ports und damit zur Überlastung von Netzwerken führen.

    Dies ist darauf zurückzuführen, dass der Windows-Netzwerklastenausgleich so konzipiert ist, dass alle eingehenden Clientpakete gleichzeitig an alle Switchports zugestellt werden. Obwohl dieses Verhalten die Zustellung eines hohen Durchsatzes durch den Windows-Netzwerklastenausgleich ermöglicht, kann es zu einer hohen Switchbelegung führen.

Genaue Anweisungen zum Konfigurieren des Windows-Netzwerklastenausgleichs finden Sie unter Konfigurieren des Windows-Netzwerklastenausgleichs für Hub-Transport-Server.

Wenn Sie mehr als acht Hub-Transport-Server nutzen, für die Sie den Lastenausgleich für Exchange-fremden Nachrichtenverkehr verwenden möchten, benötigen Sie eine Lastenausgleichslösung, die besser skalierbar ist. Obwohl es zuverlässige Softwarelösungen für den Lastenausgleich gibt, bietet eine hardwarebasierte Lastenausgleichslösung die größte Kapazität.

Anders als der Windows-Netzwerklastenausgleich, der nur Serverausfälle anhand der IP-Adresse erkennt, kann eine hardwarebasierte Lastenausgleichslösung so konfiguriert werden, dass der Ausfall des Exchange-Transportdiensts erkannt wird und eingehende E-Mail-Nachrichten an andere Hub-Transport-Server weitergeleitet werden können, ohne dass ein Benutzereingriff erforderlich ist.

Genaue Anweisungen zum Konfigurieren einer hardwarebasierten Lastenausgleichslösung finden Sie unter Konfigurieren des Hardwarelastenausgleichs für Hub-Transport-Server.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft