Verwenden des Exchange 2010-Transportservers zur Vermittlung von SMTP-Datenverkehr des Anwendungsservers

Exchange 2010
 

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

Letztes Änderungsdatum des Themas: 2012-01-16

In Microsoft Exchange Server 2010 gibt es im Vergleich zu Exchange Server 2007 keine Änderungen am Empfangsconnector und den Lastenausgleichskonzepten. Hier finden Sie einen kompakten Überblick über die Konzepte. In Exchange 2007 werden Empfangsconnectors verwendet, um eingehende Nachrichten anzunehmen. Wenn ein Exchange Server 2007-Hub-Transport-Server eine E-Mail-Nachricht mittels SMTP über den TCP-Port 25 empfängt, wird sie standardmäßig vom Empfangsconnector "Standardempfangsconnector" verarbeitet.

Zudem erfolgt in Exchange 2007 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.

Weitere Informationen zum Konfigurieren des Lastenausgleichs für Nachrichten, die von Nicht-Exchange-Quellen empfangen werden, finden Sie unter Grundlegendes zu SMTP-Failover und Lastenausgleich im Transport.

Wenn Sie eine Lastenausgleichslösung vor Ihren Hub-Transport-Servern platzieren, müssen Sie 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.

In Exchange 2010 wird die Shadow-Redundanz eingeführt, die während der gesamten Übertragungszeit Redundanz für Nachrichten bereitstellt. Mit der Shadow-Redundanz wird das Löschen einer Nachricht aus den Transportdatenbanken verzögert, bis der Transportserver sichergestellt hat, dass die jeweilige Nachricht an alle nächsten Hops vollständig zugestellt wurde.

Weil die Shadow-Redundanz eine Exchange 2010-Funktion ist, wird sie nur von Exchange 2010-Servern unterstützt. Wenn ein Exchange 2010-Transportserver Nachrichten von einer früheren Exchange Server-Version oder einer Nicht-Exchange-Quelle empfängt, kann der Quellserver den erwarteten XSHADOW-Befehl nicht senden. Daher wird die Shadow-Redundanz nicht verwendet. Nicht-Exchange-Quellen umfassen externe E-Mail-Server, Antispam- oder Antivirenlösungen von Drittanbietern, beliebige interne E-Mail-Server außerhalb der Exchange-Organisation oder Branchenanwendung des Quellservers.

Wenn ein Exchange 2010-Transportserver jedoch eine Nachricht von einer Nicht-Exchange 2010-Quelle empfängt, versucht Exchange, Shadow-Redundanz zu erreichen, indem die Bestätigung an den sendenden Server verzögert wird, bis sichergestellt ist, dass die Nachricht erfolgreich intern an alle nächsten Hops zugestellt wurde. Auf diese Weise geht der sendende Server bei einem Ausfall des Exchange 2010-Servers davon aus, dass die Nachricht nicht an Exchange zugestellt wurde, und übermittelt die Nachricht erneut.

Das Timeout für die verzögerte Bestätigung wird über das Attribut "MaxAcknowledgementDelay" jedes Empfangsconnectors gesteuert. Die Standardeinstellung ist 30 Sekunden.

Weitere Informationen zur Shadow-Redundanz finden Sie unter Grundlegendes zur Shadow-Redundanz.

Kunden, die ein Upgrade von Exchange 2007 auf Exchange 2010 durchgeführt haben und dedizierte Empfangsconnectors zur Weiterleitung von Nachrichten aus Quellen, beispielsweise Branchenanwendungen, mittels Relay verwenden, werden eine erhebliche Leistungseinbuße beim SMTP-Durchsatz feststellen. Dieser geringere Durchsatz wird durch den standardmäßigen Timeoutwert für die verzögerte Bestätigung von 30 Sekunden verursacht, der für einen Empfangsconnector konfiguriert wurde. Zum Erhöhen des SMTP-Durchsatzes für den Relay-Empfangsconnector wird empfohlen, den Timeoutwert für das verzögerte Bestätigungsattribut zu verringern oder vollständig zu deaktivieren. Ob Sie den Timeoutwert verringern oder deaktivieren sollten, hängt von der Anzahl der Nachrichten ab, die durch den Relay-Empfangsconnector verarbeitet werden. Eine gute Vorgehensweise ist, erst den Wert zu verringern und anschließend zu überprüfen, ob beim SMTP-Durchsatz noch immer Leistungseinbußen auftreten. In diesem Fall sollten Sie die Funktion vollständig deaktivieren.

WichtigWichtig:
Zwar erhöht sich der SMTP-Durchsatz durch die Deaktivierung der verzögerten Bestätigung für einen Empfangsconnector, aber Sie können dann nicht mehr von den Vorteilen der Shadow-Redundanz profitieren. Aus diesem Grund wird empfohlen, Hardwareredundanz für Transportserver, deren verzögerte Bestätigung deaktiviert wurde, zu verwenden.

Bevor Sie dieses Verfahren ausführen können, müssen Ihnen die entsprechenden Berechtigungen zugewiesen werden. Welche Berechtigungen Sie benötigen, können Sie dem Eintrag "Empfangsconnectors" im Thema Transportberechtigungen entnehmen.

HinweisHinweis:
Die Exchange-Verwaltungskonsole kann nicht zum Konfigurieren der maximalen Bestätigungsverzögerung auf einem Empfangsconnector verwendet werden.

In diesem Beispiel wird der Timeoutwert für den Empfangsconnector namens "SMTP-Anwendungsrelay" von 30 auf 15 Sekunden verringert.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 15

In diesem Beispiel wird die verzögerte Bestätigung auf dem Empfangsconnector deaktiviert.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 0
WichtigWichtig:
Es ist nicht möglich, die Shadow-Redundanz für einen Empfangsconnector zu deaktivieren. Stattdessen müssen Sie sie auf Ebene der Exchange-Organisation deaktivieren. Ausführliche Informationen zu Syntax und Parametern finden Sie unter Set-TransportConfig.

Bei der Weiterleitung von SMTP-Datenverkehr auf dem Anwendungsserver durch einen Exchange 2010-Transportserver gibt es spezielle Optionen für Nachrichteneinschränkungsrichtlinien im Empfangsconnector, die möglicherweise angepasst werden müssen, sodass es nicht zu Leistungseinbußen des SMTP-Gesamtdurchsatzes kommt. Beispielsweise gibt der Parameter MessageRateLimit die maximale Anzahl von Nachrichten an, die ein Empfangsconnector von einer einzigen IP-Adresse pro Minute annimmt. Auf Hub-Transport-Servern ist dieser Parameter auf den Wert "Unbegrenzt" festgelegt, das heißt, der SMTP-Durchsatz wird nicht beeinflusst. Auf einem Edge-Transport-Server ist der Wert jedoch auf 600 Nachrichten pro Minute festgelegt. Je nach SMTP-Datenverkehr auf dem Relay-Anwendungsserver in Ihrer Umgebung müssen Sie diesen Grenzwert erhöhen.

In diesem Beispiel wird der Grenzwert für die Nachrichtenrate für den Empfangsconnector namens "SMTP-Anwendungsrelay" von 600 auf 2000 Nachrichten erhöht.

Set-ReceiveConnector "SMTP Application relay" -MessageRateLimit 2000

Eine weitere für den Empfangsconnector spezifische Option, die Einfluss auf den SMTP-Gesamtdurchsatz von einem Relay-Anwendungsserver haben kann, wird im Wert des Parameters MessageRateSource ausgedrückt. Dieser Parameter gibt an, wie die Nachrichtenübermittlungsrate berechnet wird. Er kann auf "None", "IPAddress", "User" oder "All" festgelegt werden. Standardmäßig ist der Parameter auf "IPAddress" festgelegt, das heißt, die Nachrichtenübermittlungsrate wird für sendende Hosts berechnet. Wenn dieser Parameter den SMTP-Durchsatz von dem Relay-Anwendungsserver negativ beeinflusst, sollten Sie in Betracht ziehen, den Wert auf "None" festzulegen.

In diesem Beispiel wird der Parameter MessageRateSource für einen Empfangsconnector namens "SMTP-Anwendungsrelay" deaktiviert.

Set-ReceiveConnector "SMTP Application relay" -MessageRateSource None 

Wenn Sie die Verwendung eines dedizierten Transportservers für SMTP-Datenverkehr auf dem Relay-Anwendungsserver planen, sollten Sie eine Erhöhung der maximalen Anzahl von Verbindungen in Betracht ziehen, die gleichzeitig von einem Empfangsconnector über eine einzige IP-Adresse verarbeitet werden. Dies erfolgt mithilfe des Parameters MaxInboundConnectionPercentagePerSource. Der Wert dieses Parameters wird als Prozentsatz der verbleibenden verfügbaren Verbindungen auf einem Empfangsconnector ausgedrückt. Standardmäßig ist der Wert auf "2 Prozent" festgelegt.

In diesem Beispiel wird der Wert "MaxInboundConnectionPercentagePerSource" für den Empfangsconnector namens "SMTP-Anwendungsrelay" von 2 auf 30 Prozent geändert.

Set-ReceiveConnector "SMTP Application relay" - MaxInboundConnectionPercentagePerSource 30 

Ausführliche Informationen zu Syntax und Parametern der oben genannten, für Empfangsconnectors spezifischen Parameter finden Sie unter Set-ReceiveConnector.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Anzeigen: