Untersuchen der Lastausgleichsoptionen für Exchange 2013

In einem früheren Artikel haben wir uns einige angesehen Grundlagen des Lastenausgleichs für Exchange 2013. Jetzt ist es an der Zeit, die verschiedenen Lastausgleichsoptionen, die für Exchange 2013 verfügbar sind, sowie die Vor- und Nachteile der einzelnen Optionen zu untersuchen.

Szenario 1: Schicht 4, einzelne IP-Adresse

Dies ist das grundlegendste Lastausgleichsszenario für Exchange 2013. Wenn Sie es implementieren, werden alle Exchange 2013-Workloads so konfiguriert, dass sie eine einzige IP-Adresse verwenden. Dies bedeutet, dass Sie zwar für jede Workload unterschiedliche Hostnamen konfigurieren können (z. B. OWA, OAB, EWS usw.), diese jedoch im Wesentlichen auf dieselbe IP-Adresse verweisen.
Die größte Einschränkung ist die Tatsache, dass nur eine einzige Integritätsprüfung für alle Exchange-Workloads möglich ist. Daher ist die Auswahl des richtigen Gesundheitschecks sehr wichtig. Lassen Sie uns dieses Verhalten anhand eines einfachen Beispiels untersuchen.
Das logische Setup dieses Szenarios ähnelt dem in Abbildung 1. Wenn die Integritätsprüfung für eine Workload fehlschlägt, wird der gesamte Server aus dem Pool ignoriert und erhält keine neuen Verbindungen – unabhängig von der Art des Datenverkehrs. bis das Problem gelöst ist.

Schicht 4, einzelne IP-Adresse Exchange 2013-Lastausgleichs-Setup

Abbildung 1. Ein Blick auf ein Layer 4-Exchange 2013-Setup für den Lastenausgleich mit einer einzelnen IP-Adresse.

Während es in Ordnung sein kann, wenn der Server ausfällt, verschwenden Sie effektiv Ressourcen, wenn nur eine einzige ausgefallene Komponente auf diesem Server vorhanden ist. Dies kann beispielsweise der Fall sein, wenn die Integritätsprüfung so konfiguriert ist, dass festgestellt wird, ob das virtuelle OWA-Verzeichnis aktiv ist oder nicht. Wenn der OWA-App-Pool abstürzt, führt dies zu einem Fehler bei der Integritätsprüfung, obwohl andere Komponenten wie Outlook Anywhere weiterhin ordnungsgemäß funktionieren.
Positiv zu vermerken ist, dass dieses Szenario die Anforderungen an den Load Balancer recht niedrig hält. Es muss nur Datenverkehr an das Ziel weiterleiten, basierend auf dem virtuellen Dienst, der die Verbindung des Clients akzeptiert hat. Abhängig von der Größe Ihrer Umgebung bedeutet dies, dass Sie entweder einen Load Balancer der unteren Preisklasse oder möglicherweise sogar einen Windows Network Load Balancing (WNLB) verwenden können.

Szenario 2: Schicht 7, einzelne IP-Adresse

In Szenario 2 haben wir Layer 4 gegen Layer 7 ausgetauscht. Da die meisten Workloads von Exchange verwendet werden SSLmuss der Load Balancer den eingehenden Datenverkehr entschlüsseln, lesen und auf dem Weg nach draußen erneut verschlüsseln. Dies bedeutet, dass WNLB keine Option mehr ist und Sie die zusätzliche Last beim Kauf eines Load Balancers berücksichtigen müssen.
Heutzutage können Sie mit den meisten Load Balancern Routing-Entscheidungen basierend auf dem Verkehrsinhalt treffen. Dies bedeutet, dass der Load Balancer den an eine einzelne IP-Adresse gesendeten Datenverkehr durch Lesen des Inhaltsstroms unterscheiden kann. Dies wird durch Betrachten der URLs erreicht, an die ein Client Datenverkehr sendet.
Wie Sie sehen, gibt es keinen großen Unterschied zwischen dem zweiten und dem ersten Lastausgleichsszenario. Da wir jedoch auf Schicht 7 arbeiten, können wir eine Routing-Logik basierend auf dem Inhalt konfigurieren, die – in den meisten Load Balancern – durch die Definition subvirtueller Dienste erreicht wird. Wenn Sie mit dem Begriff noch nicht vertraut sind, sind subvirtuelle Dienste genau das, wonach sie klingen, virtuelle Dienste innerhalb eines größeren virtuellen Dienstes.
Der Datenverkehr wird dann basierend auf dem Inhalt (URL) an einen der subvirtuellen Dienste weitergeleitet. Dies wird auch als Inhaltsumschaltung bezeichnet.
In Abbildung 2 sehen Sie, was ich beschreibe.

  Schicht 7, einzelne IP-Adresse Exchange 2013-Lastausgleichs-Setup

Abbildung 2. Ein Blick auf ein Layer 7-Exchange 2013-Setup für den Lastenausgleich mit einer einzelnen IP-Adresse.

Der Vorteil dieses Setups besteht darin, dass jeder subvirtuelle Dienst über eine eigene Integritätsprüfung verfügt. Wenn beispielsweise eine OWA-Integritätsprüfung fehlschlägt, wird der Server aus dem Pool für OWA nicht berücksichtigt, erhält jedoch weiterhin Datenverkehr für Outlook Anywhere oder Exchange Web Services (EWS). Ein weiterer Vorteil besteht darin, dass das Load-Balancing-Setup jetzt auch effektiv darstellt, wie Exchange die Dinge sieht.
Beispielsweise merkt Managed Availability – eine in Exchange 2013 integrierte Selbstüberwachungskomponente – auch, wenn OWA auf einem Server abstürzt, verwendet diesen Server jedoch weiterhin für andere Workloads.
Der Nachteil in diesem Szenario besteht darin, dass Sie einen teureren Load Balancer kaufen müssen und dessen Konfiguration wahrscheinlich erheblich komplexer ist als im ersten Szenario.

Szenario 3: Schicht 4, mehrere IP-Adressen

Ich beschreibe dieses Szenario gerne als das Beste aus beiden Welten. Es kombiniert die Einfachheit von Layer 4 mit den erweiterten Funktionen von Layer 7, erfordert jedoch keinen High-End-Load-Balancer. Es klingt fast zu schön um wahr zu sein, nicht wahr? Nun, es gibt einen kleinen Kompromiss.
Wie Sie wissen, wird ein virtueller Dienst durch eine eindeutige Kombination aus einer IP-Adresse und einem TCP-Port definiert. In diesem Szenario müssen wir für jede Exchange-Workload einen virtuellen Dienst erstellen, da wir keine Inhaltsumschaltung durchführen können. Dies bedeutet, dass Sie für jede Arbeitslast eine andere IP-Adresse benötigen.
Dies stellt normalerweise kein Problem für interne Bereitstellungen dar. Die Tatsache, dass Sie mehrere externe IP-Adressen verwenden müssen, bedeutet jedoch, dass Sie wahrscheinlich zusätzliche IP-Adressen erwerben müssen. Sie müssen Ihrem Zertifikat auch alle zusätzlichen Namen hinzufügen, was auch die Kosten für das Zertifikat erhöht.

Schicht 4, mehrere IP-Adressen Einrichtung des Exchange 2013-Lastausgleichs

Abbildung 3. Ein Blick auf ein Layer 4-Setup mit mehreren IP-Adressen für den Exchange 2013-Lastenausgleich.

Abbildung 3 zeigt dieses Szenario detailliert:
Dieses Szenario erfordert immer noch eine einzige Integritätsprüfung pro virtuellem Dienst. Da jede Arbeitslast jetzt über einen eigenen virtuellen Dienst verfügt, wirken sie sich in keiner Weise gegenseitig aus. Das Ergebnis ist dieselbe Granularität wie beim Layer 7-Lastausgleich, ohne dass subvirtuelle Dienste konfiguriert oder die Verkehrsentschlüsselung durchgeführt werden muss.

Szenario 4: DNS-Round-Robin

Die letzte Option besteht darin, das DNS-Round-Robin (Domain Name System) als Exchange 2013-Lastausgleichsmechanismus zu verwenden. Obwohl vollständig unterstützt, bedeutet die Verwendung von DNS-Round-Robin, dass Sie die meisten Vorteile eines Load Balancers aufgeben. In der Regel werden Kosten gespart.
Die Idee hier ist ziemlich einfach: Für jede Arbeitslast (in diesem Fall Hostname) erstellen Sie mehrere Einträge in DNS, die auf jeden der Server im Array verweisen.
Schauen Sie sich zum Beispiel Tabelle 1 an.

HostnameServerArt
Owa.domain.com192.168.10.110EIN
Owa.domain.com192.168.10.111EIN
Owa.domain.com192.168.10.112EIN

Tabelle 1. DNS-Einträge.
Wenn der Client den DNS trifft, um den Hostnamen in eine IP-Adresse zu übersetzen, werden die drei IP-Adressen zurückgegeben. Bei jeder Anforderung, die den DNS erreicht, wird jeder Eintrag um einen Steckplatz verschoben.
Die erste Anfrage würde beispielsweise folgendermaßen aussehen:

  1. 192.168.10.110
  2. 192.168.10.111
  3. 192.168.10.112

Und die zweite Anfrage würde so aussehen:

  1. 192.168.10.111
  2. 192.168.10.112
  3. 192.168.10.110

Infolgedessen stellt jeder Client zuerst eine Verbindung zu einem anderen Clientzugriffsserver her, bis der DNS die Liste der Einträge durchläuft und erneut beginnt.
Das Problem hierbei ist, was passiert, nachdem ein Server- oder Dienstfehler aufgetreten ist. Da DNS keine Integritätsprüfungen durchführt, weiß es nicht, wann die IP-Adresse eines bestimmten Servers ausgegeben werden soll und wann nicht. Dies führt dazu, dass Clients möglicherweise immer noch eine Verbindung zu einem Server herstellen, selbst wenn einer der Dienste nicht verfügbar ist. Das Ergebnis ist zwangsläufig eine Ausfallzeit für den Endbenutzer. Die Antwort hier besteht darin, den Eintrag manuell aus dem DNS zu entfernen und zu warten, bis der lokale Cache des Clients abgelaufen ist, damit er die Einträge erneut vom DNS-Server anfordert.
Die Zeit, die der Datensatz auf dem Client abläuft, wird durch die Lebensdauer des Datensatzes gesteuert. Der Standardwert beträgt 3.600 Sekunden. Wenn Sie jedoch DNS-Round-Robin für den tatsächlichen Lastausgleich verwenden, ist es eine gute Idee, ihn auf 300 Sekunden zu senken. Wenn Sie dies nicht tun, riskieren Sie, dass Clients bis zu einer Stunde warten, bevor sie erneut auf DNS klicken.
Sobald die Clients zu DNS zurückkehren, enthält die Liste, die der Client erhalten hat, nicht mehr den Server mit dem fehlgeschlagenen Dienst, und alles ist in Ordnung. Das funktioniert, aber es ist keine sehr gute Benutzererfahrung, oder?
Bei einem vollständigen Serverausfall wird es verrückter. Jeder Client, der eine Antwort von DNS erhält (mit diesem Server als erstem Eintrag), hat ein Problem. Jeder Server versucht, eine Verbindung zum Server herzustellen, erhält jedoch keine Antwort. Der HTTP-Stack im Betriebssystem (mit dem die Verbindung zum Server hergestellt wird) erkennt dies und versucht es mit dem zweiten Server in der Liste.
Vor dem Versuch einer zweiten Verbindung wird jedoch auf eine Zeitüberschreitung gewartet. Dies kann einige Sekunden bis eine Minute oder sogar länger dauern. Während des Wartens auf das Zeitlimit bleibt der Endbenutzer in Outlook von Exchange getrennt. Um die Sache noch schlimmer zu machen, muss der Administrator immer noch in DNS gehen und den Eintrag für den ausgefallenen Server entfernen, um zu verhindern, dass bei anderen Clients etwas Ähnliches passiert. Nach der Wiederherstellung des Servers muss der Eintrag manuell erneut zu DNS hinzugefügt werden.
Positiv zu vermerken ist, dass dieses Setup eine Art automatischen Failover-Mechanismus bietet. Es besteht auch kein Zweifel daran, dass das Round-Robin-System für Domain-Namen der billigste Weg ist, um eine höhere Verfügbarkeit für Exchange 2013 zu erreichen, selbst wenn es nur in den kleinsten Bereitstellungen verwendet werden kann.
Trotzdem kommt dieses Setup nicht an die Effizienz heran, die ein Load Balancer bieten kann.

Abschließende Gedanken

Nachfolgend finden Sie eine Tabelle, die Sie als Kurzreferenz für jedes der besprochenen Szenarien verwenden können, sowie die Vor- und Nachteile für jedes:

TopologieVorteileNachteile
Schicht 4, einzelne IP
  • Einfach
  • Benötigt nur eine einzige IP
  • Preiswert
  • Keine detaillierten Gesundheitsprüfungen
Schicht 7
  • Nur eine einzige IP erforderlich
  • Granulare Gesundheitsprüfungen
  • Teurer
  • Kann komplizierter einzurichten sein
Schicht 4, mehrere IP
  • Granulare Gesundheitsprüfungen
  • Relativ einfach
  • Weitere Namen auf Zertifikaten
  • Es werden mehrere IP-Adressen benötigt
  • Kann sich aufgrund der Zertifikat- und IP-Anforderungen als teurer als erwartet erweisen
DNS Round Robin
  • Failover nicht immer nahtlos, manuelle Interaktion erforderlich
  • Abhängig von clientseitigen Funktionen / Logik (Timeout)
  • Keine Gesundheitskontrollen

Über den Autor:
Michael Van Horenbeeck ist ein Technologieberater, Microsoft Certified Trainer und Exchange MVP aus Belgien, der hauptsächlich mit Exchange Server, Office 365, Active Directory und etwas Lync arbeitet. Er ist seit 12 Jahren in der Branche tätig und ein häufiger Blogger, Mitglied der belgischen Unified Communications-Benutzergruppe Pro-Exchange und regelmäßiger Mitarbeiter von The UC Architects Podcast.

Similar Posts

Leave a Reply