Lastenausgleich

  • Artikel

Gilt für: Exchange Server 2013

Der Lastenausgleich ist eine Möglichkeit, zu verwalten, welcher Ihrer Server Datenverkehr empfängt. Der Lastenausgleich hilft dabei, eingehende Clientverbindungen auf verschiedene Endpunkte (z. B. Clientzugriffsserver) zu verteilen, um sicherzustellen, dass kein Endpunkt einen unproportionalen Teil der Last übernimmt. Der Lastenausgleich kann auch Failoverredundanz für den Fall bereitstellen, dass ein oder mehrere Endpunkte ausfällt. Durch die Verwendung des Lastenausgleichs mit Exchange Server 2013 stellen Sie sicher, dass Ihre Benutzer im Falle eines Computerausfalls weiterhin den Exchange-Dienst erhalten. Der Lastenausgleich ermöglicht es Ihrer Bereitstellung auch, mehr Datenverkehr zu verarbeiten, als ein Server verarbeiten kann, während sie einen einzelnen Hostnamen für Ihre Clients anbietet.

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

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

  • Hochverfügbarkeit: Exchange 2013 verwendet Datenbankverfügbarkeitsgruppen (DAGs), um mehrere Kopien Ihrer Postfächer auf verschiedenen Servern zu synchronisieren. Wenn eine Postfachdatenbank auf einem Server ausfällt, können Benutzer auf diese Weise eine Verbindung mit einer synchronisierten Kopie der Datenbank auf einem anderen Server herstellen.

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

  • Onlinepostfachverschiebungen: Bei einer Onlinepostfachverschiebung 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 ausgeschlossen. Sie können Onlinepostfachverschiebungen zwischen Gesamtstrukturen oder in derselben Gesamtstruktur durchführen.

  • 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 wurden. Wenn einer der nächsten Hops fehlschlägt, bevor eine erfolgreiche Übermittlung gemeldet wird, wird die Nachricht erneut zur Übermittlung an den Hop gesendet, der nicht abgeschlossen wurde.

Architekturänderungen beim Lastenausgleich für Exchange Server 2013

In Exchange Server 2010 wurden Clientverbindungen und die Verarbeitung von der Clientzugriffsserverrolle verarbeitet. Diese Funktionalität erforderte sowohl externe als auch interne Outlook-Verbindungen, und mobile Geräte- und Clientverbindungen von Drittanbietern erforderten einen Lastenausgleich über das Array von Clientzugriffsservern in einer Bereitstellung, um Fehlertoleranz und eine effiziente Nutzung der Server zu erreichen. Viele Exchange 2010-Clientzugriffsprotokolle erfordern Affinität: eine Beziehung zwischen dem Client und einem bestimmten Clientzugriffsserver. Insbesondere Outlook Web App, exchange Systemsteuerung, Exchange Web Services, Outlook Anywhere, Outlook TCP/IP MAPI-Verbindungen, Exchange ActiveSync, exchange Address Book Service und Remote-PowerShell erforderlich oder profitierten von der Serveraffinität zwischen Client-zu-Client-Zugriff. Die Lastenausgleichsoptionen in Exchange 2010 enthielten die folgenden Features:

  • Windows-Netzwerklastenausgleich mit Quell-IP-Affinität

  • Hardwarelastenausgleich

Aufgrund der unterschiedlichen Anforderungen von Clientprotokollen in Exchange 2010 wird die Verwendung einer Layer 7-Lastenausgleichslösung empfohlen. Ebene 7, auch als Lastenausgleich auf Anwendungsebene bezeichnet, ermöglichte es der Lastenausgleichslösung, komplexe Regeln zu verwenden, um zu bestimmen, wie die einzelnen Anforderungen ausgeglichen werden, die in das System eingehen, da die gesamte Konversation zwischen Client und Server für die Lastenausgleichslogik verfügbar wäre. Diese komplexen Regeln stellen sicher, dass alle Anforderungen von einem bestimmten Client an denselben Clientzugriffsserverendpunkt gesendet wurden. Wenn in Exchange 2010 nicht alle Anforderungen von einem bestimmten Client für Protokolle, die Affinität erfordern, an denselben Endpunkt gesendet würden, würde sich die Benutzererfahrung negativ 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, zustandslose 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 können Exchange 2013-Clientzugriffsserver:

  • Unterstützung von Proxy- und Umleitungslogik für Clientprotokolle.

  • Unterstützung der Verwendung des Layer 4-Lastenausgleichs.

Mit Sitzungsaffinität und Layer-7-Lastenausgleich werden alle Anforderungen zwischen dem Client und dem Server an denselben Endpunkt gesendet, wie dies für verschiedene Protokolle erforderlich ist. Anforderungen werden auf der Anwendungsebene verteilt. Beim Lastenausgleich der Ebene 4 werden die Anforderungen auf der Transportebene verteilt. Die Lastenausgleichslösung verteilt Anforderungen vom Client, der sich einer einzelnen IP-Adresse (manchmal auch als virtuelle IP-Adresse oder VIP bezeichnet) bewusst ist, an eine Gruppe von Servern, die die Arbeit ausführen. Die Verbindung zwischen Client und Server muss hergestellt werden, bevor der Inhalt der Anforderung bestimmt wird. Daher wählt der Lastenausgleich einen Server aus, der die Anforderung empfangen soll, bevor der Inhalt der Anforderung überprüft wird. Die Auswahl des Zielservers kann auf verschiedene Arten erfolgen, z. B. auf "Roundrobin", bei dem jede eingehende Verbindung an den nächsten Zielserver in einer zirkulären Liste geht, oder "geringste Verbindungen", bei denen der Lastenausgleich jede neue Verbindung an den Server sendet, der zu diesem Zeitpunkt die wenigsten Verbindungen hergestellt hat. Da nun keine Sitzungsaffinität erforderlich ist, haben Sie mehr Flexibilität, Auswahl und Einfachheit in Bezug auf die von Ihnen bereitgestellte Lastenausgleichsarchitektur. Mit dem Lastenausgleich 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 cookiebasierter 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 Diensts mit Lastenausgleich und hochverfügbaren Diensten wesentlich einfacher ist.

Lastenausgleichslösungen

Die Verwendung von Hardwarelastenausgleichsmodulen wird für Exchange 2013 weiterhin unterstützt. Informationen zu den Hardwarelastenausgleichslösungen, die die Lösungstests mit Exchange 2010 abgeschlossen haben und wahrscheinlich auch mit Exchange 2013 funktionieren, finden Sie unter Exchange Server 2010 Load Balancer-Bereitstellung. Beachten Sie, dass auf dieser Seite die komplexere Layer-7-Konfiguration von Hardwarelastenausgleichsmodulen mit Exchange 2010 angezeigt wird. Der Lastenausgleich für Exchange 2013-Datenverkehr kann angesichts der weiter oben in diesem Thema erläuterten Architekturänderungen viel einfacher sein. Anstatt die Sitzungsaffinität für jedes Exchange-Protokoll zu konfigurieren, können eingehende Verbindungen mit Exchange 2013-Clientzugriffsservern vom Lastenausgleich an einen verfügbaren Server weitergeleitet werden, ohne dass eine weitere Affinitätsverarbeitung erforderlich ist. Der Hardwarelastenausgleich hat weiterhin eine wichtige Rolle bei der Bereitstellung von Hochverfügbarkeit des Exchange-Diensts, da er erkennen kann, wann ein bestimmter Clientzugriffsserver nicht mehr verfügbar ist, und ihn von den Servern entfernen kann, die eingehende Verbindungen verarbeiten.

Windows-Netzwerklastenausgleich

Der Windows-Netzwerklastenausgleich (WNLB) ist ein gängiger Softwarelastenausgleich, der 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 nicht mit Dem Windows-Failoverclustering kompatibel ist. Wenn Sie eine Exchange 2013-DAG verwenden und WNLB verwenden möchten, müssen die Serverrolle Clientzugriff und die Postfachserverrolle auf separaten Servern ausgeführt werden.

  • WNLB erkennt keine Dienstausfälle. WNLB erkennt Serverausfälle nur anhand der IP-Adresse. Dies bedeutet, dass WNLB den Fehler nicht erkennt, wenn ein bestimmter Webdienst, z. B. Outlook Web App, ausfällt, aber der Server weiterhin funktioniert, den Fehler nicht erkennt und weiterhin Anforderungen an diesen Clientzugriffsserver weiter leitet. Ein manueller Eingriff ist erforderlich, um den Ausfall des Clientzugriffsservers aus dem Lastenausgleichspool zu entfernen.

  • Die Verwendung von WNLB kann zu Portüberflutungen führen, die Netzwerke überlasten können.

  • Da WNLB die Clientaffinität nur mithilfe der Quell-IP-Adresse ausführt, ist dies 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.