Lastenausgleichsanforderungen für Exchange-Protokolle

 

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

Letztes Änderungsdatum des Themas: 2011-11-02

Microsoft Exchange-Protokolle und Clientzugriffsdienste weisen unterschiedliche Lastenausgleichsanforderungen auf. Einige Microsoft Exchange-Protokolle und Clientzugriffsdienste erfordern eine Affinität zwischen Client und Clientzugriffsserver. Andere funktionieren auch ohne, zeigen aber Leistungsverbesserungen durch eine solche Affinität. Wiederum andere Exchange-Protokolle erfordern keine Affinität zwischen Client und Clientzugriffsserver, und die Leistung nimmt ohne diese Affinität auch nicht ab.

Inhalt

Exchange-Protokolle, die eine Affinität zwischen Client und Clientzugriffsserver erfordern

Exchange-Protokolle, die von der Affinität zwischen Client und Clientzugriffsserver profitieren

Exchange-Protokolle, die keine Affinität erfordern

Grundlegendes zur IP-Ports

Exchange-Protokolle, die eine Affinität zwischen Client und Clientzugriffsserver erfordern

Die folgenden Exchange-Protokolle erfordern eine Affinität zwischen Client und Clientzugriffsserver. Die Affinität muss während einer Clientsitzung bestehen bleiben.

  • Outlook Web App und die Exchange-Systemsteuerung   Microsoft Office Outlook Web App und die Exchange-Systemsteuerung erfordern eine Affinität zwischen Client und Clientzugriffsserver. Wenn Sie die formularbasierte Authentifizierung verwenden, die die Standardeinstellung in Microsoft Exchange Server 2010 darstellt, müssen sowohl Outlook Web App als auch die Exchange-Systemsteuerung eine Affinität zu demselben Clientzugriffsserver aufweisen. Das liegt daran, dass sie denselben Cookie für die Authentifizierung verwenden und dass dieser Cookie nur von einem bestimmten Clientzugriffsserver entschlüsselt werden kann.

  • Exchange-Webdienste   Nur eine Teilmenge der Exchange-Webdienste erfordert eine Affinität. Verfügbarkeitsdienstanforderungen erfordern keine Affinität, während dies aber bei Abonnements der Fall ist. Alle Aspekte der Exchange-Webdienste erfahren Leistungsverbesserungen durch die Affinität. Wir unterstützen die Verwendung von Exchange-Webdiensten ohne Affinität nicht.

  • Outlook-RPC über TCP im Intranet   Outlook-Clients im Intranet setzen voraus, dass alle RPC-Verbindungen mit demselben Server hergestellt werden. Outlook verwendet mehrere Sitzungen pro Benutzer und nimmt dabei an, dass alle Sitzungen eine Verbindung mit demselben Server herstellen.

Exchange-Protokolle, die von der Affinität zwischen Client und Clientzugriffsserver profitieren

Die folgenden Exchange-Protokolle und -Dienste funktionieren ohne Affinität. Ihre Leistung ist jedoch deutlich geringer, wenn sie ohne Affinität bereitgestellt werden.

  • Outlook Anywhere   Outlook Anywhere-Verbindungen sind unidirektional und unterteilen eine einzelne RPC-Datenverbindung in zwei HTTP-Verbindungen. Eine Verbindung wird für eingehende Daten und eine für ausgehende Daten verwendet. Wenn zwischen diesen beiden Verbindungstypen keine Affinität besteht, versucht Outlook Anywhere die Verbindungen durch Koordination mit anderen Mitgliedern des Clientzugriffsserver-Arrays zu korrelieren. Dadurch wird der Datenverkehr zwischen den Clientzugriffsservern für ein zwei Server umfassendes Array um ungefähr 50 % und für ein Array mit einer großen Anzahl von Servern um bis zu 100 % erhöht.

  • Exchange ActiveSync   Microsoft Exchange ActiveSync übermittelt neue E-Mail-Benachrichtigungen zu den Clients über eine dauerhafte HTTPS-Anforderung vom Client zum Server. Wenn ein Exchange ActiveSync-Client einem neuen Clientzugriffsserver zugewiesen wird, muss dieser Server das Benachrichtigungsabonnement für das Postfach des Benutzers neu erstellen. Dies führt zu erheblichen Leistungseinbußen.

  • Exchange-Adressbuchdienst   Dies ist ein neuer Dienst in Exchange 2010, der den Verzeichniszugriff für Clients bereitstellt. Wenn die Affinität nicht verwendet wird, führt dies zu wesentlich mehr Kommunikation zwischen dem Client und den Clientzugriffsservern.

  • Remote-PowerShell Ohne Affinität müssen sich die Benutzer erneut authentifizieren, wenn eine Verbindung unterbrochen wird.

Exchange-Protokolle, die keine Affinität erfordern

Es gibt verschiedene Exchange-Protokolle und -Dienste, die keine Affinität erfordern, da es sich um Transaktionsprotokolle oder -dienste handelt. Das bedeutet, die Verbindung wird hergestellt, die Transaktion wird abgeschlossen und die Verbindung wird wieder geschlossen. Diese Protokolle erfahren keine Leistungsvorteile durch die Affinität.

  • Offlineadressbuch

  • AutoErmittlungsdienst

  • POP3

  • IMAP4

Grundlegendes zur IP-Ports

Die meisten Exchange 2010-Dienste setzen auf HTTP auf und verwenden Port 443 für den SSL-Zugriff (Secure Sockets Layer) sowie Port 80 für den Nicht-SSL-Zugriff. Bei Outlook Web App, Exchange ActiveSync, Outlook Anywhere und den Exchange-Webdiensten handelt es sich um solche Dienste. POP3 und IMAP4 verwenden die Ports 110 bzw. 143, wenn keine SSL-Verschlüsselung erfolgt und die Ports 995 bzw. 993, wenn SSL-Verschlüsselung erfolgt.

Andere Exchange-Dienste wie der RPC-Clientzugriffsdienst und der Exchange-Adressbuchdienst sind RPC-Dienste. Wenn ein Outlook-Client mithilfe dieser Protokolle eine direkte Verbindung zum Clientzugriffsserver herstellt, anstatt Outlook Anywhere zu verwenden, werden die TCP-Endpunktports für diese Dienste vom RPC-Endpunkt-Manager zugeordnet. Die Zuordnung erfolgt, wenn die Dienste gestartet werden. Dies erfordert eine breite Palette an Zielports, die für den Lastenausgleich konfiguriert werden müssen, ohne über die Möglichkeit zu verfügen, den Datenverkehr auf Basis der Portnummer speziell für diese Dienste zu planen. Sie können diese Dienste statisch bestimmten Portnummern zuordnen, um den Lastenausgleich zu vereinfachen. Wenn die Ports für diese Dienste statisch zugeordnet werden, wird der Datenverkehr auf Port 135 und die beiden speziellen Ports beschränkt, die für diese Dienste ausgewählt wurden.

Konfigurieren der statischen Portzuordnung für RPC-basierte Dienste

Der statische Port für den RPC-Clientzugriffsdienst wird in der Registrierung konfiguriert. Der folgende Registrierungsschlüssel sollte auf jedem Clientzugriffsserver konfiguriert werden. Legen Sie für den Schlüssel den Wert des Ports fest, den Sie für TCP-Verbindungen zum RPC-Clientzugriffsdienst verwenden möchten.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Value: TCP/IP Port
Type: DWORD

Hinweis

Diese Änderung betrifft nur interne Verbindungen über TCP und keine Outlook Anywhere-Verbindungen, die RPC/HTTP-Tunneling verwenden. Outlook Anywhere-Verbindungen zum RPC-Clientzugriffsdienst treten an Port 6001 auf. Dies ist nicht konfigurierbar.

Dieser Prozess sollte auch auf allen Öffentliche Ordner-Servern in Ihrer Organisation ausgeführt werden.

Die statischen Ports für die beiden RPC-Endpunkte, deren Verwaltung durch den Exchange-Adressbuchdienst erfolgt, werden in der Datei namens "Microsoft.Exchange.AddressBook.Service.Exe.config" konfiguriert. Diese Datei befindet sich auf jedem Clientzugriffsserver im Installationspfad von Exchange im Verzeichnis bin. Für den Wert RpcTcpPort in der Konfigurationsdatei sollte der Wert des Ports festgelegt werden, den Sie für TCP-Verbindungen für diesen Dienst verwenden möchten. Dieser Port bearbeitet Verbindungen für den Adressbuchverweis (ABREF) und für die NSPI (Name Service Provider Interface).

Hinweis

Ändern Sie nicht die Werte für die Konfigurationsoptionen NspiHTTPPort und RfrHTTPPort. Standardmäßig ist Outlook für die Verwendung dieser Ports konfiguriert. Das Ändern dieser Werte führt zu einer unerwünschten Verzögerung, wenn die Clients versuchen, Outlook Anywhere-Verbindungen einzurichten. Die Standardports sind 6002 für NspiHTTPPort und 6004 für RfrHTTPPort.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.