Grundlegendes zum Lastenausgleich in Exchange 2010
Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Letztes Änderungsdatum des Themas: 2016-11-28
Über den Lastenausgleich können Sie verwalten, welche Ihrer Server Datenverkehr empfangen. Der Lastenausgleich bietet Failoverredundanz, um zu gewährleisten, dass Benutzer den Exchange-Dienst auch bei einem Computerausfall weiter empfangen können. Darüber hinaus kann die Bereitstellung mehr Datenverkehr abwickeln, als ein Server verarbeiten kann, und bietet dabei einen einzelnen Hostnamen für die Clients.
Neben dem Lastenausgleich stellt Microsoft Exchange Server 2010 mehrere Lösungen für Switchover und Failoverredundanz bereit. Hierzu gehören Folgende:
Hochverfügbarkeit und Standortflexibilität Sie können zwei Active Directory-Standorte an geografisch separaten Orten bereitstellen und dafür sorgen, dass die Postfachdaten zwischen beiden Standorten synchronisiert werden und einer der Standorte die gesamte Last des anderen übernimmt, falls dieser ausfallen sollte. Exchange 2010 verwendet Database Availability Groups (DAGs), damit stets mehrere Kopien der Postfächer auf verschiedenen Servern synchronisiert sind.
Onlinepostfachverschiebungen Bei einer Onlinepostfachverschiebung können Endbenutzer während der Verschiebung auf ihre E-Mail-Konten zugreifen. Die Konten der Benutzer werden nur für einen kurzen Zeitraum gegen Ende des Vorgangs, bei der abschließenden Synchronisierung, gesperrt. Onlinepostfachverschiebungen werden zwischen Exchange 2010-Datenbanken und zwischen Datenbanken in Exchange Server 2007 Service Pack 3 (SP3) oder einer höheren Version von Exchange 2007 und Exchange 2010 unterstützt. Sie können die Verschiebung von Onlinepostfächern gesamtstrukturübergreifend oder innerhalb derselben Gesamtstruktur durchführen.
Shadow-Redundanz Durch Shadow-Redundanz wird die Verfügbarkeit und Wiederherstellbarkeit von Nachrichten während der Übertragung geschützt. Mit der Shadow-Redundanz wird das Löschen einer Nachricht aus den Transportdatenbanken verzögert, bis der Transportserver sichergestellt hat, dass die jeweilige Nachricht vollständig an alle nächsten Hops zugestellt wurde. Wenn einer der nächsten Hops einen Fehler verursacht, bevor eine erfolgreiche Zustellung gemeldet wird, wird die Nachricht erneut zur Zustellung an diesen Hop gesendet.
Inhalt
Lastenausgleich (Übersicht)
Grundlegendes zur Datenverkehrslast in Exchange 2010
Grundlegendes zu Lastenausgleichsoptionen
Empfehlungen für den Lastenausgleich
Affinitätsoptionen
Lastenausgleich (Übersicht)
Der Lastenausgleich erfüllt zwei Hauptaufgaben. Er verringert die Auswirkungen des Ausfalls eines Clientzugriffsservers an einem der Active Directory-Standorte. Darüber hinaus gewährleistet der Lastenausgleich, dass die Last gleichmäßig auf die Clientzugriffsserver und Hub-Transport-Computer verteilt wird.
Architektonische Änderungen beim Lastenausgleich in Exchange 2010
Mehrere Änderungen in Exchange 2010 machen den Lastenausgleich zu einer wichtigen Komponente für Ihre Organisation. Der Exchange-RPC-Clientzugriffsdienst und der Exchange-Adressbuchdienst für die Clientzugriffs-Serverrolle verbessern die Benutzerfunktionen bei Postfachfailovern, indem sie die Verbindungspunkte für den Postfachzugriff von Outlook und anderen MAPI-Clients zur Clientzugriffs-Serverrolle statt zur Postfachserverrolle verschieben. In früheren Versionen von Exchange hat Outlook eine direkte Verbindung zum Postfachserver mit dem Postfach des Benutzers hergestellt, und Verzeichnisverbindungen wurden entweder mittels Proxy über die Postfachserverrolle weitergeleitet oder direkt an einen bestimmten globalen Active Directory-Katalogserver verwiesen. Jetzt, wo diese Verbindungen direkt durch die Clientzugriffs-Serverrolle verarbeitet werden, muss für externe wie interne Outlook-Verbindungen ein Lastenausgleich im Clientzugriffsserver-Array einer Bereitstellung erfolgen, um Fehlertoleranz zu gewähren.
Ein Clientzugriffsserver-Array mit Lastenausgleich wird für alle Active Directory-Standorte und alle Exchange-Versionen empfohlen. Es ist nicht möglich, ein Clientzugriffsserver-Array mit Lastenausgleich für mehrere Active Directory-Standorte freizugeben oder verschiedene Exchange- oder Exchange Service Pack-Versionen innerhalb desselben Arrays zu verwenden.
Wenn Sie Exchange 2010 in der vorhandenen Organisation installieren und einen Legacynamespace für die Koexistenz mit vorherigen Versionen von Exchange konfigurieren, stellen Clients automatisch eine Verbindung zum Exchange 2010-Clientzugriffsserver oder -Array her. Vom Exchange 2010-Clientzugriffsserver bzw. Clientzugriffsserver-Array werden Clientanforderungen für Postfächer auf älteren Exchange-Versionen dann mittels Proxy oder Umleitung an Exchange 2003-Front-End-Server oder Exchange 2007-Clientzugriffsserver geleitet, die mit der Postfachversion übereinstimmen. Weitere Informationen finden Sie unter Grundlegendes zum Upgrade auf Exchange 2010.
Hinweis
Sie können QFE-Hotfixes (Quick Fix Engineering) und Updaterollups kombinieren, wenn Sie diese auf das gesamte Array oder Teile davon anwenden. Es wird empfohlen, QFE-Hotfixes und Updaterollups auf alle Computer eines Arrays anzuwenden.
Die Lastenausgleichskonfiguration hat direkte Auswirkungen auf die Hostnamen, die von Ihren Clients zum Herstellen von Verbindungen verwendet werden, sowie auf Ihre SSL-Zertifikate (Secure Sockets Layer). Weitere Informationen zu Exchange 2010-Zertifikaten finden Sie unter Grundlegendes zu digitalen Zertifikaten und SSL.
Konfigurieren des Clientzugriffsserver-Arrays
Sie können jeweils ein Clientzugriffsserver-Array pro Active Directory-Standort konfigurieren. Sobald das Clientzugriffsserver-Array konfiguriert wurde, können Sie die Postfachdatenbank konfigurieren, die das Clientzugriffsserver-Array statt eines bestimmten Clientzugriffsservers als MAPI-Endpunkt verwenden soll.
Weitere Informationen zum Clientzugriffsserver-Array und zum Konfigurieren der Postfachdatenbank für die Verwendung des Clientzugriffsserver-Arrays für den bestimmten Active Directory-Standort finden Sie unter Grundlegendes zum RPC-Clientzugriff.
Grundlegendes zur Datenverkehrslast in Exchange 2010
Vor dem Konfigurieren des Lastenausgleichs sollten Sie die Lasten für einen Exchange 2010-Clientzugriffsserver kennen. Ein Exchange 2010-Clientzugriffsserver empfängt die folgenden drei Arten von Datenverkehr:
Datenverkehr von externen Clients
Datenverkehr von internen Clients
Proxyverkehr von anderen Clientzugriffsservern
Bei Proxyverkehr von anderen Clientzugriffsservern handelt es sich um Datenverkehr, der ursprünglich von einem externen oder internen Client an einen Clientzugriffsserver gesendet, dann jedoch per Proxy an einen anderen Clientzugriffsserver weitergeleitet wird. Dies kann verschiedene Gründe haben, geschieht jedoch im Allgemeinen, weil der ursprüngliche Client keine direkte Verbindung zum Ziel-Clientzugriffsserver herstellen kann. Dies kann passieren, wenn ein Benutzer versucht, aus dem Internet auf ein Postfach zuzugreifen, das Postfach sich jedoch an einem Active Directory-Standort befindet, der nicht mit dem Internet verbunden ist. Weitere Informationen zu Proxyfunktionen finden Sie unter Grundlegendes zu Proxyfunktion und Umleitung.
Alle von Clientzugriffsservern empfangenen Datenverkehrsarten beinhalten Anforderungen aus einer Liste von Protokollen und stammen von Clientgeräten und Computern mit unterschiedlichen Eigenschaften. Diese Unterschiede beeinflussen, welche Lastenausgleichsstrategien verwendet werden können.
Zurück zum Seitenanfang
Grundlegendes zu Lastenausgleichsoptionen
Zwischen den verschiedenen Lösungen für den Lastenausgleich bestehen mehrere wichtige technologische Unterschiede.
Leistung Wie viele Anforderungen pro Sekunde kann die Lösung verarbeiten?
Verwaltbarkeit Wie einfach lässt sich die Lastenausgleichslösung konfigurieren und bereitstellen?
Failoverautomatisierung und -erkennung Wie intelligent ist der Lastenausgleich, wenn es darum geht, den Ausfall eines Clientzugriffsservers oder -diensts zu erkennen?
Affinität Welche Art von Affinität zwischen Client und Clientzugriffsserver unterstützt die Lastenausgleichslösung?
Grundlegendes zur Affinität
Wenn eine Lastenausgleichslösung Affinität zwischen Client und Clientzugriffsserver bereitstellt, bedeutet dies, dass zwischen einem bestimmten Client und einem bestimmten Clientzugriffsserver eine dauerhafte Zuordnung besteht. Bei diesem Client kann es sich um Outlook auf einem Laptop, Microsoft Exchange ActiveSync auf einem mobilen Gerät, Microsoft Office Outlook Web App, Exchange-Webdienste oder eine andere Clientanwendung handeln.
Die dauerhafte Zuordnung bzw. Affinität gewährleistet, dass alle vom Client gesendeten Anforderungen an denselben Clientzugriffsserver gerichtet werden. Für einige Exchange 2010-Protokolle ist Affinität erforderlich, für andere Exchange-Protokolle nicht.
Windows-Netzwerklastenausgleich
Der Windows-Netzwerklastenausgleich ist der gängigste Softwarelastenausgleich für Exchange-Server. Es gibt einige Einschränkungen bei der Bereitstellung des Windows-Netzwerklastenausgleichs mit Microsoft Exchange.
Sie können den Windows-Netzwerklastenausgleich nicht auf Exchange-Servern verwenden, auf denen auch Postfach-DAGs verwendet werden, da der Windows-Netzwerklastenausgleich nicht mit Windows-Failoverclustering kompatibel ist. Wenn Sie eine Exchange 2010-DAG verwenden und den Windows-Netzwerklastenausgleich verwenden möchten, müssen Clientzugriffs-Serverrolle und Postfachserverrolle auf separaten Servern ausgeführt werden.
Aufgrund von Leistungsproblemen sollten Sie nicht mehr als acht Clientzugriffsserver in ein Array mit Windows-Netzwerklastenausgleich platzieren.
Der Windows-Netzwerklastenausgleich erkennt keine Dienstausfälle. Der Windows-Netzwerklastenausgleich erkennt Dienstausfälle nur anhand der IP-Adresse. Wenn also ein bestimmter Webdienst wie Outlook Web App ausfällt, der Server jedoch noch funktioniert, erkennt der Windows-Netzwerklastenausgleich den Ausfall nicht und leitet auch weiterhin Anforderungen an diesen Clientzugriffsserver weiter. Ein Benutzereingriff ist erforderlich, um den von dem Ausfall betroffenen Clientzugriffsserver aus dem Lastenausgleichspool zu entfernen.
Die Konfiguration des Windows-Netzwerklastenausgleichs kann zur Überflutung von Ports und damit zur Überlastung von Netzwerken führen.
Da der Windows-Netzwerklastenausgleich die Clientaffinität mithilfe der Quell-IP-Adresse durchführt, ist diese Lösung bei einem kleinen Quell-IP-Pool nicht effektiv. Dies kann der Fall sein, wenn der Quell-IP-Pool aus dem Subnetz eines Remotenetzwerks stammt oder Ihre Organisation die Netzwerkadressenübersetzung verwendet.
Empfehlungen für den Lastenausgleich
Es gibt mehrere Optionen für den Lastenausgleich. Welche Option Sie verwenden, hängt von der Größe und Konfiguration Ihres Netzwerks ab.
Windows-Netzwerklastenausgleich mit Quell-IP-Affinität
Die erste Option für den Lastenausgleich ist der Windows-Netzwerklastenausgleich mit Quell-IP-Affinität. Diese Lösung ist geeignet, wenn sich an einem Active Directory-Standort zwischen einem und acht Clientzugriffsserver befinden. Die Lösung ist in Windows integriert und erfordert keine zusätzlichen Computer.
Es gibt zwei Szenarien, in denen Sie den Windows-Netzwerklastenausgleich nicht verwenden sollten.
Ihre Organisation verfügt über einen Reverseproxyserver, der nicht über die virtuelle IP-Adresse des Windows-Netzwerklastenausgleichs, sondern direkt mit dem Clientzugriffsserver kommuniziert. Der Reverseproxyserver verbirgt die Client-IP-Adressen vor dem Clientzugriffsserver-Array. Die Quell-IP-Affinität funktioniert daher nicht wie erwartet. Sie können den Windows-Netzwerklastenausgleich jedoch immer noch für den Lastenausgleich des internen Datenverkehrs verwenden.
Zahlreiche Clients in Ihrer Organisation greifen über einen sehr kleinen Satz IP-Adressen auf die Clientzugriffsserver zu. Der Windows-Netzwerklastenausgleich stellt im Allgemeinen eine Affinität zwischen einem ganzen Subnetz der Klasse C und einem Clientzugriffsserver her.
Hardwarelastenausgleich
Wenn sich mehr als acht Clientzugriffsserver an einem Active Directory-Standort befinden, benötigt Ihre Organisation eine robustere Lastenausgleichslösung. Es gibt zwar zuverlässige Softwarelösungen für den Lastenausgleich, doch eine Hardwarelösung für den Lastenausgleich bietet die größte Kapazität. Weitere Informationen zu Lastenausgleichslösungen für Exchange 2010-Server finden Sie unter Microsoft Unified Communications Hardware Load Balancer Deployment (möglicherweise in englischer Sprache).
Hardwarelösungen für den Lastenausgleich unterstützen einen sehr hohen Datenverkehrsdurchsatz und bieten verschiedene Konfigurationsmöglichkeiten. Die meisten Anbieter von Hardwarelösungen für den Lastenausgleich verfügen über eine ausführliche Dokumentation zur Zusammenarbeit ihrer Produkte mit Exchange 2010. Die einfachste Methode zur Konfiguration eines Hardwarelastenausgleichs besteht im Erstellen einer Fallbackliste mit den Affinitätsmethoden, die vom Lastenausgleich angewendet werden sollen. So versucht der Lastenausgleich z. B. zunächst die cookiebasierte Affinität, dann SSL-Sitzungs-ID- und schließlich Quell-IP-Affinität.
Reverseproxylösungen
Wenn Sie über eine Reverseproxylösung verfügen, die einen Lastenausgleich für die im Internet bereitgestellten Server durchführen kann, z. B. Microsoft Forefront Threat Management Gateway (TMG) oder Forefront Unified Access Gateway (UAG), sollten Sie diese verwenden.
Wenn der Netzwerkverkehr den Reverseproxyserver auf dem Weg zu den Clientzugriffsservern passiert, wird die ursprüngliche IP-Adresse des Clients durch die IP-Adresse des Reverseproxyservers ersetzt. Dadurch wird die Quell-IP-Affinität aufgehoben. Dieses Problem lässt sich u. a. durch das Konfigurieren des Reverseproxyservers als Standardgateway für das Subnetz, an das die Proxyweiterleitung erfolgt, lösen.
Die meisten Reverseproxyserver können jedoch einen Lastenausgleich für die im Internet bereitgestellten Dienste durchführen. Diese Reverseproxyserver unterstützen den von der Lastenausgleichslösung erstellten, cookiebasierten Lastenausgleich für die in Frage kommenden Exchange-Dienste. Diese Lösung ist zuverlässiger als der Quell-IP-Lastenausgleich. Zu diesem Zweck muss der Reverseproxyserver den HTTP-Datenstrom lesen und ändern können. Wenn Sie SSL verwenden, muss der Reverseproxyserver den Datenverkehr entschlüsseln, um die Inhalte zu lesen und das Cookie im Datenstrom zu erstellen. In einigen Fällen ist diese Entschlüsselung nicht möglich, z. B. dann, wenn Sie die Clientzertifikatsauthentifizierung verwenden, bei der der Client eine Verbindung zum Clientzugriffsserver herstellt.
Zurück zum Seitenanfang
Affinitätsoptionen
Unterschiedliche Lastenausgleichslösungen bieten unterschiedliche Methoden für das Zuordnen von Clients zu einem bestimmten Clientzugriffsserver. Es gibt mehrere gängige Affinitätstypen in verschiedenen Lastenausgleichsprodukten – Hardware wie Software. Nicht alle Affinitätstypen sind in jeder Lastenausgleichsoption verfügbar, wie folgende Beispiele zeigen:
Der Windows-Lastenausgleich unterstützt nur Quell-IP-Affinität oder keine Affinität.
Ein Softwarelastenausgleich in einem separaten Serverarray kann vom Lastenausgleich erstellte Cookies für die Protokolle verwenden, die diese Cookies unterstützen, sowie Quell-IP-Affinität für die übrigen Protokolle.
Bei einem Hardwarelastenausgleich mit SSL-Verschiebung können Sie ein komplexeres Verhalten konfigurieren. So können Sie beispielsweise einen Satz vorhandener Cookies für die Protokolle konfigurieren, die diese Cookies unterstützen, sowie ein vom Lastenausgleich erstelltes Cookie, SSL-Sitzungs-ID und Quell-IP.
Neben den Optionen, die von den verschiedenen Lastenausgleichslösungen unterstützt werden, können Sie auch einige der Schritte so konfigurieren, dass sie nur für bestimmte Exchange-Protokolle und -Dienste angewendet werden. Da jedes Protokoll ein anderes Verhalten hat, lässt sich dadurch die Leistung optimieren.
Vorhandene Cookies oder HTTP-Header
Die Verwendung vorhandener Cookies oder HTTP-Header ist die zuverlässigste Methode, um einen Client zu identifizieren und einem bestimmten Clientzugriffsserver zuzuordnen. Diese Cookies und Header werden vom Client oder Server als Teil des Kommunikationsprotokolls erstellt. Diese Option erfordert zudem keine Änderung des Datenverkehrs durch den Lastenausgleich, was sich günstig auf die Leistung auswirkt.
Bei Verwenden dieser Affinitätsoption sollten Sie Folgendes beachten:
Ihre Lastenausgleichslösung muss diesen Affinitätstyp unterstützen. Derzeit bieten nur Hardwarelösungen für den Lastenausgleich Unterstützung für diese Affinität.
Diese Affinität funktioniert nur für Protokolle, die Datenverkehr über HTTP übergeben.
Es muss ein Cookie oder Header vorhanden sein, der während der Clientsitzung konstant bleibt und einzigartig ist für den jeweiligen Client bzw. den kleinen Clientsatz im Protokoll.
Die Lastenausgleichslösung muss den HTTP-Datenstrom lesen und interpretieren können. Wenn Sie SSL verwenden, muss der Lastenausgleich den Datenverkehr entschlüsseln, um die Inhalte zu lesen. In manchen Fällen führt dies zu einer erhöhten Last für den Lastenausgleich. Außerdem ist diese Entschlüsselung in einigen Fällen nicht möglich, z. B. dann, wenn Sie die Clientzertifikatsauthentifizierung für die SSL-Sitzung verwenden, bei der der Client eine Verbindung zum Clientzugriffsserver herstellt.
Bei den für den Lastenausgleich geeigneten vorhandenen Cookies und HTTP-Header, die in Exchange 2010-Protokollen zur Verfügung stehen, handelt es sich um folgende:
Autorisierungsheader der HTTP-Standardauthentifizierung Dieser Header funktioniert bei Verwenden der HTTP-Standardauthentifizierung. Die Standardauthentifizierung ist die am häufigsten verwendete Art der Authentifizierung für Exchange ActiveSync. Dieser Header ist für andere Protokolle und Authentifizierungsmethoden unüblich. Der Autorisierungsheader der Standardauthentifizierung sendet den gesamten Datenverkehr, der die Standardauthentifizierung verwendet und von einem bestimmten Benutzer stammt, an denselben Clientzugriffsserver. Dieser Header wird auch verwendet, wenn Outlook-Datenverkehr vollständig über HTTP übermittelt wird und Clients sich hinter einem Reverseproxyserver befinden.
HTTP-Cookie "UserContext" (OWA) Dieses Cookie funktioniert in Outlook Web App, dem einzigen Client, der es verwendet. Wenn Sie die formularbasierte Authentifizierung für Outlook Web App verwenden (die Standardkonfiguration), werden zu Beginn einer Outlook Web App-Sitzung eine kleine Reihe von Anforderungen ausgeführt, bevor das UserContext-Cookie erstellt wird. Damit gewährleistet ist, dass diese Anforderungen Affinität für die Verbindung des Clients mit dem Clientzugriffsserver verwenden, der für die formularbasierte Authentifizierung erforderlich ist, muss bei Verwenden des UserContext-Cookies die Affinitätsoption eines Fallbacks bestehen. Sie sollten SSL-Sitzungs-ID- oder Quell-IP-Affinität als Fallback verwenden, um Affinität für diese ersten Anforderungen bereitzustellen, bevor der Lastenausgleich das UserContext-Cookie zur Verwendung erhält.
Hinweis
Outlook Web App-Anforderungen, die eine explizite Anmeldung für den Zugriff auf ein bestimmtes Postfach verwenden, führen zur Verwendung eines UserContext-Cookies mit anderem Namen und anderer ID. Das Cookie beginnt mit UserContext, jedoch gefolgt von einer Zeichenfolge zur Identifizierung des jeweiligen Postfachs. Dies macht den Lastenausgleich mit dem UserContext-Cookie schwieriger, weil der Lastenausgleich zunächst ein Cookie finden muss, das mit UserContext beginnt. Dies kann zu einer Leistungsverschlechterung führen.
HTTP-Cookie "msExchEcpCanary" (Exchange-Systemsteuerung) Dieses Cookie funktioniert nur für die Exchange-Systemsteuerung.
HTTP-Cookie "OutlookSession" (Outlook 2010) Hardwarelösungen für den Lastenausgleich unterstützen das OutlookSession-Cookie sowie andere generische Cookies. Die folgende Tabelle beschreibt die Voraussetzungen für die OutlookSession-Clientcookieunterstützung für Outlook RPC/HTTP:
Windows XP
Windows Vista
Windows 7
Outlook 2003
Nicht unterstützt
Nicht unterstützt
Nicht unterstützt
Outlook 2007
Nicht unterstützt
Nicht unterstützt
Nicht unterstützt
Outlook 2007 Hostingpaket (KB2544404)
Nicht unterstützt
Unterstützt
Unterstützt
Outlook 2010
Nicht unterstützt
Unterstützt
Unterstützt
Hinweis
Microsoft Outlook bietet bei Ausführung auf Windows XP keine Unterstützung für den OutlookSession-Cookie für den Lastenausgleich. In diesem Szenario wird die Verwendung des IP-Lastenausgleichs empfohlen.
HTTP-Cookie "MS-WSMAN-Cookie" (Remote PowerShell) Diese Methode funktioniert nur für die Remote PowerShell.
Zurück zum Seitenanfang
Vom Lastenausgleich erstellte Cookies
Die zweite zuverlässige Methode der Zuordnung einer Clientsitzung zu einem Clientzugriffsserver besteht in der Verwendung eines Cookies, das vom Lastenausgleich erstellt wurde. Der Lastenausgleich fügt der Konversation zwischen Client- und Serverprotokoll ein HTTP-Cookie hinzu und verwendet dieses Cookie dann, um zu bestimmen, von welchem Clientzugriffsserver eine eingehende Anforderung verarbeitet werden soll. Bei den Exchange 2010-Anwendungen wird diese Methode unterstützt von Outlook Web App, der Exchange-Systemsteuerung und Remote PowerShell. Für diese Art von Cookie gelten verschiedene Einschränkungen.
Die Lastenausgleichslösung muss diese Art von Affinität unterstützen. Aktuell wird diese Affinität nur von Hardwarelösungen sowie Softwarelösungen für den Lastenausgleich unterstützt, die auf einer separaten Serverstufe ausgeführt werden.
Diese Methode funktioniert nur für Protokolle, die Datenverkehr über HTTP übergeben. Sie können diese Methode nicht für den RPC-Clientzugriffsdienst, den Exchange-Adressbuchdienst, POP3 oder IMAP4 verwenden.
Die Lastenausgleichslösung muss den HTTP-Datenstrom lesen und interpretieren können. Wenn Sie SSL verwenden, muss der Lastenausgleich den Datenverkehr entschlüsseln, um die Inhalte zu lesen. In manchen Fällen führt dies zu einer erhöhten Last für den Lastenausgleich. In anderen Fällen kann der Lastenausgleich den HTTP-Datenstrom nicht interpretieren, z. B. dann, wenn Sie die Clientzertifikatsauthentifizierung auf dem Clientzugriffsserver verwenden.
Der Client muss beliebige Cookies vom Server empfangen können und diese Cookies dann in alle Anforderungen aufnehmen, die zukünftig vom Client an den Server gesendet werden. Exchange ActiveSync-Clients, Outlook Anywhere-Clients und einige Exchange-Webdienstclients wie Microsoft Office Communications Server 2007-Geräte bieten hierfür keine Unterstützung.
SSL-Sitzungs-ID
Ein auf der SSL-Sitzungs-ID basierender Lastenausgleich bietet mehr Details als Quell-IP-Affinität und ermöglicht Ihnen das Aufteilen des Datenverkehrs von verschiedenen Clients, auch wenn diese Clients von derselben IP-Adresse ausgehen. Der SSL-Sitzungs-ID-Lastenausgleich bietet zudem den Vorteil, dass Sie einen Lastenausgleich durchführen können, ohne den SSL-Datenverkehr entschlüsseln zu müssen. Dies ist erforderlich, wenn Sie die Clientzertfikatsauthentifizierung verwenden und die SSL-Verbindung am Clientzugriffsserver beenden.
SSL-Sitzungs-ID-Affinität wird in den folgenden beiden Situationen nicht empfohlen:
Einige Clients, z. B. Internet Explorer 8, erstellen ihre SSL-Sitzung für jeden Browserprozess, der auf dem Clientcomputer ausgeführt wird, neu. Das Ergebnis ist eine neue SSL-Sitzung für jedes Outlook Web App-Fenster. Da dadurch die Clientaffinität für Outlook Web App aufgehoben wird, wird diese Methode der Bereitstellung des Lastenausgleichs für Exchange 2010 nicht unterstützt. Einige mobile Geräte, darunter das Apple iPhone, erstellen ebenfalls neue SSL-Sitzungen für Teile ihrer Exchange ActiveSync-Kommunikation mit Exchange.
Hinweis
Bei der Clientauthentifizierung verwenden Browser dieselbe SSL-Sitzung für den gesamten Datenverkehr an einen bestimmten Hostnamen. Solange die Clientzertifikatsauthentifizierung aktiviert ist, ist die SSL-Sitzungs-ID eine gültige Affinitätsoption für Outlook Web App und die Exchange-Systemsteuerung.
Bei Outlook Anywhere verwenden die Clientzugriffsserver die Windows-RPC-Proxykomponente, um RPC_DATA_IN- und RPC_DATA_OUT-Verbindungen zu koppeln. Dies kann die Leistung negativ beeinflussen.
Quell-IP
Die gängigste Methode zur Bereitstellung von Affinität zwischen Clients und Clientzugriffsservern besteht in der Verwendung von Quell-IP-Affinität. Der Lastenausgleich untersucht die IP-Adresse eines Clients und sendet den gesamten Datenverkehr von einer bestimmten Quell-IP an einen bestimmten Clientzugriffsserver. Dies ist die einzige Art von Affinität, die vom Windows-Netzwerklastenausgleich unterstützt wird. Bei der Verwendung der Quell-IP-Affinität gibt es zwei wichtige Aspekte, die Sie berücksichtigen sollten.
Die Affinität wird aufgehoben, wenn der Client die IP-Adresse ändert. Dies kann der Fall sein, wenn ein Laptop von einem verkabelten LAN in ein Wi-Fi-Netzwerk verschoben wird oder zwischen verschiedenen Wi-Fi-Netzwerken wechselt. Wenn der Client die IP-Adresse ändert, wirkt sich dies auf die Benutzer aus. Benutzer, die Outlook Web App verwenden, müssen sich beispielsweise jedes Mal authentifizieren, wenn ihr Computer eine neue IP-Adresse erhält.
Wenn viele Ihrer Clients über dieselbe IP-Adresse auf die Lastenausgleichslösung zugreifen, wird die Lastenverteilung ungleichmäßig. Welche Auswirkungen dies hat, hängt davon ab, wie viele Clients hinter einer bestimmten IP-Adresse maskiert sind. Wenn Sie beispielsweise über vier Clientzugriffsserver verfügen und 50 Prozent der Clients über dieselbe IP-Adresse auf den Lastenausgleich zugreifen, wird mindestens 50 Prozent des Datenverkehrs an einen Clientzugriffsserver geleitet, während der Rest des Datenverkehrs von den anderen drei Clientzugriffsservern übernommen wird. Es gibt zwei Hauptgründe, warum die meisten Clients über eine einzige IP-Adresse auf die Exchange-Organisation zugreifen.
Netzwerkaddressenübersetzung (NAT) oder ausgehende Proxyserver, wie Microsoft Forefront Threat Management Gateway (TMG). Befindet sich zwischen Clients und Clientzugriffsservern eine Netzwerkadressenübersetzung oder ein ausgehender Proxyserver, werden die ursprünglichen Client-IP-Adressen von der IP-Adresse der Netzwerkadressenübersetzung oder des ausgehenden Proxyservers maskiert.
Proxyverkehr von Clientzugriffsserver zu Clientzugriffsserver. In einigen Fällen leitet ein Clientzugriffsserver Datenverkehr per Proxy an einen anderen Clientzugriffsserver weiter. Dies geschieht im Allgemeinen zwischen Active Directory-Standorten, weil ein Client auf einen Clientzugriffsserver am selben Active Directory-Standort wie das Postfach zugreifen muss. Weitere Informationen zu Proxyfunktionen finden Sie unter Grundlegendes zu Proxyfunktion und Umleitung.
Keine Affinität
Die letzte Art von Affinität ist die nicht vorhandene Affinität. Wenn Sie keine Affinität verwenden, wird jede Anforderung eines Clients einem beliebigen Clientzugriffsserver zugewiesen. Diese Option ist nicht empfehlenswert für Protokolle, die Affinität erfordern oder bei denen die Affinität für Leistungsvorteile sorgt.
Sie sollten keine Affinität für Protokolle verwenden, die keine Affinität benötigen, wenn die SSL-Verschiebung konfiguriert ist.
Zurück zum Seitenanfang
Zusammenfassung der Lastenausgleichsoptionen
Die folgende Tabelle enthält eine Übersicht der zur Verfügung stehenden Lastenausgleichsoptionen.
| Lösung | Affinität von Client zu Clientzugriffsserver | Failovermethode | Kapazität | Kosten |
|---|---|---|---|---|
Hardwarelastenausgleich |
Verwenden Sie je nach Protokoll und Client eine der folgenden Fallbackoptionen:
|
Automatisches Failover mit minimaler Clientausfallzeit. Hardwarelösungen für den Lastenausgleich können darüber hinaus Failover für ein bestimmtes Protokoll bereitstellen. |
++++ |
$$$ |
Softwarelastenausgleich in einer separaten Serverschicht Hinweis: TMG und UAG sind die einzigen funktionsfähigen Lösungen für externen Datenverkehr. |
Entweder vom Lastenausgleich erstelltes Cookie oder Quell-IP, je nach Protokoll und Client. |
Automatisches Failover mit minimaler Clientausfallzeit. |
++ |
$$ |
Softwarelastenausgleich in derselben Serverschicht wie der Clientzugriffsserver (Windows-Netzwerklastenausgleich) |
Quell-IP. |
Automatisches Failover mit minimaler Clientausfallzeit. |
+ |
$ |
DNS-Roundrobin |
Jeder Client erhält eine zufällige Clientzugriffsserver-IP-Adresse. |
Manuelle Schritte zum Erkennen von Problemen und zur Wiederherstellung. Das DNS-Cacheverhalten von Browser und Betriebssystem verhindert möglicherweise auch nach der Wiederherstellung durch einen Administrator den Aufbau von Clientverbindungen. Diese Lösung hebt die Affinität für viele Protokolle auf, darunter RPC-Clientzugriff, Outlook Web App, Exchange-Webdienste und Exchange-Systemsteuerung. |
+++ |
$ |
Kein Lastenausgleich |
Separate Hostnamen werden für jeden Clientzugriffsserver manuell zugewiesen. |
Manuelle Schritte zum Erkennen von Problemen und Failover. Client-DNS-Caches bewirken ein langsames Failover. |
+ |
Nicht zutreffend |
Jede dieser Optionen hat mehrere Vor- und Nachteile.
Hardwarelösungen für den Lastenausgleich beinhalten im Allgemeinen Leistungs- und Sicherheitsfunktionen wie SSL-Verschiebung und die Überprüfung des Datenverkehrs.
Softwarelösungen für den Lastenausgleich in einer separaten Serverschicht sind im Allgemeinen Teil eines umfangreicheren Softwarepakets mit Reverseproxyfunktionen wie Vorauthentifizierung, SSL-Verschiebung und umfassender Datenverkehrsüberprüfung. Wenn ein Softwarelastenausgleich eine Vorauthentifizierung von Benutzern durchführt, müssen diese Benutzer sich nicht erneut authentifizieren, wenn der Clientzugriffsserver, zu dem eine Affinität besteht, ausfällt. Einige Softwarelösungen für den Lastenausgleich erfordern jedoch eine Affinität zwischen Client und Reverseproxyserver. In diesem Fall benötigen Sie eine zusätzliche Lastenausgleichsschicht vor den Reverseproxyservern, bevor die Reverseproxyserver Lastenausgleichsaufgaben für die Clientzugriffsserver durchführen können.
© 2010 Microsoft Corporation. Alle Rechte vorbehalten.