Lastenausgleich

Gilt für: Exchange Server 2013

Der Lastenausgleich ist eine Möglichkeit, um zu verwalten, welche Ihrer Server Datenverkehr empfangen. Der Lastenausgleich hilft bei der Verteilung eingehender Clientverbindungen über verschiedene Endpunkte (z. B. Clientzugriffsserver), um sicherzustellen, dass kein Endpunkt einen unproportionalen Anteil der Last übernimmt. Der Lastenausgleich kann auch Failoverredundanz für den Fall bereitstellen, dass mindestens ein Endpunkt fehlschlägt. Durch die Verwendung des Lastenausgleichs mit Exchange Server 2013 stellen Sie sicher, dass Ihre Benutzer im Falle eines Computerfehlers weiterhin Exchange Dienst erhalten. Mithilfe des Lastenausgleichs kann Ihre Bereitstellung auch mehr Datenverkehr verarbeiten, der von einem Server verarbeitet werden kann, während gleichzeitig ein einzelner Hostname für Ihre Clients angeboten wird.

Der Lastenausgleich dient in erster Linie zwei Zwecken. Dadurch werden die Auswirkungen eines einzelnen Clientzugriffsserverfehlers innerhalb eines Ihrer Active Directory-Standorte reduziert. Außerdem stellt der Lastenausgleich sicher, dass die Last auf jedem Clientzugriffsserver gleichmäßig verteilt wird.

Exchange 2013 umfasst auch die folgenden Lösungen für Switchover- und Failoverredundanz:

  • Hohe Verfügbarkeit: Exchange 2013 verwendet Datenbankverfügbarkeitsgruppen (Database Availability Groups, DAGs), um mehrere Kopien Ihrer Postfächer auf verschiedenen Servern synchronisiert zu halten. Auf diese Weise können Benutzer, wenn eine Postfachdatenbank auf einem Server einen Fehler verursacht, eine Verbindung mit einer synchronisierten Kopie der Datenbank auf einem anderen Server herstellen.

  • Ausfallsicherheit von Standorten: Sie können zwei Active Directory-Standorte an separaten geografischen Standorten bereitstellen, die Postfachdaten zwischen den beiden synchronisieren und einen der Standorte die gesamte Last übernehmen lassen, wenn der andere fehlschlägt.

  • Verschieben von Onlinepostfächern: Bei der Verschiebung eines Onlinepostfachs können Benutzer während der Verschiebung auf ihre E-Mail-Konten zugreifen. Benutzer werden am Ende des Prozesses, wenn die endgültige Synchronisierung erfolgt, nur für kurze Zeit von ihren Konten gesperrt. Sie können Onlinepostfächer über Gesamtstrukturen oder in derselben Gesamtstruktur verschieben.

  • Schattenredundanz: Schattenredundanz schützt die Verfügbarkeit und Wiederherstellbarkeit von Nachrichten während der Übertragung. Bei Schattenredundanz wird das Löschen einer Nachricht aus den Transportdatenbanken verzögert, bis der Transportserver überprüft, ob alle nächsten Hops für diese Nachricht abgeschlossen sind. Wenn einer der nächsten Hops fehlschlägt, bevor eine erfolgreiche Zustellung gemeldet wird, wird die Nachricht zur Übermittlung an den Hop erneut übermittelt, der nicht abgeschlossen wurde.

Architekturänderungen beim Lastenausgleich für Exchange Server 2013

In Exchange Server 2010 wurden Clientverbindungen und -verarbeitung von der Clientzugriffsserverrolle verarbeitet. Diese Funktionalität erforderte, dass sowohl externe als auch interne Outlook-Verbindungen sowie mobile Geräte- und Drittanbieter-Clientverbindungen über das Array von Clientzugriffsservern in einer Bereitstellung hinweg lastenausgleicht werden mussten, um Fehlertoleranz und eine effiziente Auslastung von Servern zu erzielen. Viele Exchange 2010-Clientzugriffsprotokolle erfordern Affinität: eine Beziehung zwischen dem Client und einem bestimmten Clientzugriffsserver. Insbesondere Outlook Web App, die Exchange Systemsteuerung, Exchange Webdienste, Outlook Anywhere, Outlook TCP/IP-MAPI-Verbindungen, Exchange ActiveSync, die Exchange Adressbuchdienst und Remote-PowerShell sind entweder erforderlich oder profitieren von der Client-zu-Client-Zugriffsserveraffinität. Die Lastenausgleichsoptionen in Exchange 2010 umfassten die folgenden Features:

  • Windows Netzwerklastenausgleich mit Quell-IP-Affinität

  • Hardwarelastenausgleich

Aufgrund der unterschiedlichen Anforderungen von Clientprotokollen in Exchange 2010 empfehlen wir die Verwendung einer Layer 7-Lastenausgleichslösung. Layer 7, auch bekannt als Lastenausgleich auf Anwendungsebene, ermöglichte es der Lastenausgleichslösung, komplexe Regeln zu verwenden, um zu bestimmen, wie die einzelnen Anforderungen, die in das System gelangen, ausgeglichen werden können, da die gesamte Unterhaltung zwischen Client und Server für die Logik zum Lastenausgleich verfügbar wäre. Diese komplexen Regeln stellen sicher, dass alle Anforderungen von einem bestimmten Client an den gleichen Clientzugriffsserver-Endpunkt gesendet wurden. Wenn in Exchange 2010 nicht alle Anforderungen von einem bestimmten Client für Protokolle, die eine Affinität erfordern, an denselben Endpunkt gesendet wurden, würde sich dies negativ auf die Benutzererfahrung auswirken. Weitere Informationen zu Exchange 2010-Lastenausgleichsoptionen finden Sie unter Grundlegendes zum Lastenausgleich in Exchange 2010.

In Exchange Server 2013 gibt es zwei primäre Servertypen: den Clientzugriffsserver und den Postfachserver. Die Clientzugriffsserver in Exchange 2013 dienen als einfache, statuslose Proxyserver, sodass Clients eine Verbindung mit Exchange 2013-Postfachservern herstellen können. Exchange 2013-Clientzugriffsserver bieten einen einheitlichen Namespace und eine einheitliche Authentifizierung. Darüber hinaus Exchange 2013-Clientzugriffsserver:

  • Unterstützt Proxy- und Umleitungslogik für Clientprotokolle.

  • Unterstützen Sie die Verwendung von Layer 4-Lastenausgleich.

Mit Sitzungsaffinität und Layer 7-Lastenausgleich werden alle Anforderungen zwischen dem Client und dem Server an den gleichen Endpunkt gesendet, wie von verschiedenen Protokollen benötigt. Anforderungen werden auf der Anwendungsebene verteilt. Beim Lastenausgleich der Ebene 4 werden die Anforderungen auf der Transportschicht verteilt. Die Lastenausgleichslösung verteilt Anforderungen vom Client, die eine einzelne IP-Adresse (manchmal auch als virtuelle IP-Adresse oder VIP bezeichnet) kennen, an eine Gruppe von Servern, die die Arbeit ausführen. Die Verbindung zwischen dem Client und dem Server muss hergestellt werden, bevor der Inhalt der Anforderung bestimmt wird, sodass der Lastenausgleich einen Server auswählt, der die Anforderung empfängt, bevor der Inhalt der Anforderung überprüft wird. Die Auswahl des Zielservers kann auf verschiedene Arten erfolgen, z. B. "Roundrobin", bei dem jede eingehende Verbindung in einer Kreisliste an den nächsten Zielserver gesendet wird, oder "geringste Verbindungen", bei denen der Lastenausgleich jede neue Verbindung an den Server sendet, der zu diesem Zeitpunkt die wenigsten hergestellten Verbindungen aufweist. Da nun keine Sitzungsaffinität erforderlich ist, haben Sie mehr Flexibilität, Auswahl und Einfachheit in Bezug auf die bereitgestellte Lastenausgleichsarchitektur. Mithilfe des Lastenausgleichs ohne Sitzungsaffinität können Sie die Kapazität und Auslastung des Lastenausgleichs erhöhen, da die Verarbeitung nicht verwendet wird, um komplexere Affinitätsoptionen wie cookiebasierten Lastenausgleich oder SSL-Sitzungs-ID (Secure Sockets Layer) beizubehalten.

Clientzugriffsserverarrays und Exchange 2013

In Exchange 2010 haben wir das Konzept eines Clientzugriffsarrays eingeführt. Nachdem ein Clientzugriffsarray für einen Active Directory-Standort konfiguriert wurde, wurden alle Clientzugriffsserver am Standort automatisch Mitglieder des Arrays. In aktuellen Builds von Exchange 2013 ist keine Konfiguration eines Clientzugriffsarrays erforderlich, da die Bereitstellung eines Lastenausgleichs- und hoch verfügbaren Diensts viel einfacher ist.

Lastenausgleichslösungen

Die Verwendung von Hardwaregerät zum Lastenausgleich wird für Exchange 2013 weiterhin unterstützt. Informationen zu hardwarebasierten Lastenausgleichslösungen, die lösungstests mit Exchange 2010 abgeschlossen haben und wahrscheinlich auch mit Exchange 2013 funktionieren, finden Sie unter Exchange Server 2010 Load Balancer Deployment. Beachten Sie, dass auf dieser Seite die komplexere Layer-7-Konfiguration von Hardwaregerät zum Lastenausgleich mit Exchange 2010 angezeigt wird. Der Lastenausgleich Exchange 2013-Datenverkehr kann aufgrund der zuvor in diesem Thema behandelten Architekturänderungen wesentlich einfacher sein. Anstatt die Sitzungsaffinität für jedes der Exchange Protokolle zu konfigurieren, können eingehende Verbindungen mit Exchange 2013-Clientzugriffsservern vom Lastenausgleichsmodul zu einem verfügbaren Server geleitet werden, ohne dass eine weitere Affinitätsverarbeitung erforderlich ist. Der Hardwaregerät zum Lastenausgleich spielt weiterhin eine wichtige Rolle bei der Bereitstellung der hohen Verfügbarkeit des Exchange Diensts, da er erkennen kann, wann ein bestimmter Clientzugriffsserver nicht mehr verfügbar ist, und ihn aus dem Serversatz zu entfernen, der eingehende Verbindungen verarbeitet.

Windows-Netzwerklastenausgleich

Windows Netzwerklastenausgleich (Network Load Balancing, WNLB) ist ein gängiges Softwaregerät zum Lastenausgleich, das für Exchange Server verwendet wird. Bei der Bereitstellung von WNLB mit Microsoft Exchange gibt es mehrere Einschränkungen.

  • WNLB kann nicht auf Exchange Servern verwendet werden, auf denen auch Postfach-DAGs verwendet werden, da WNLB mit Windows Failoverclustering nicht kompatibel ist. Wenn Sie eine Exchange 2013 DAG verwenden und WNLB verwenden möchten, müssen die Clientzugriffsserverrolle und die Postfachserverrolle auf separaten Servern ausgeführt werden.

  • WNLB erkennt keine Dienstausfälle. WNLB erkennt serverausfälle nur nach IP-Adresse. Dies bedeutet, dass WNLB den Fehler nicht erkennt, wenn ein bestimmter Webdienst, z. B. Outlook Web App, fehlschlägt, der Server aber weiterhin funktioniert, und Anforderungen trotzdem an diesen Clientzugriffsserver weiterleitet. Manuelles Eingreifen ist erforderlich, um den Clientzugriffsserver, auf dem der Ausfall auftritt, aus dem Lastenausgleichspool zu entfernen.

  • Die Verwendung von WNLB kann zu Portüberschwemmungen führen, wodurch Netzwerke überlastet werden können.

  • Da WNLB nur Clientaffinität mithilfe der Quell-IP-Adresse durchführt, ist es keine effektive Lösung, wenn der Quell-IP-Pool klein ist. Dies kann auftreten, wenn der Quell-IP-Pool aus einem Remotenetzwerksubnetz stammt oder wenn Ihre Organisation die Netzwerkadressübersetzung verwendet.