Exchange Server-Lastenausgleich und Failover


Lastausgleich und Failover Exchange Server 01
www.microsoft.com

Der Lastausgleich und die Ausfallsicherheit von Exchange Server werden auf verschiedene Weise bereitgestellt, und die meisten hören hauptsächlich von der Database Availability Group (DAG).… Aber wenn es sich um eine Datenbank handelt, wie können Clientverbindungen ausgeglichen werden? Welche sofort einsatzbereiten Tools bietet Exchange, um Redundanz für CAS-Arrays bereitzustellen?

Die Antwort ist einfach und banal – keine. Aus diesem Grund gibt es im Internet in dieser Hinsicht so viele verschiedene Ansätze und “Life Hacks”, dass häufig sehr zweifelhafte Entscheidungen getroffen werden. Einer von ihnen wurde kürzlich in den Technet-Foren in einem interessanten Thema diskutiert Thema.


Weitere Informationen zum Einrichten und Verwalten von Exchange 2013 finden Sie in meinem Blog im Hauptthema Artikel – Exchange 2013 – Installation, Konfiguration, Verwaltung.


Exchange Server-Lastenausgleich und Failover

Das Wesentliche ist wie folgt: Ist es möglich, die DAG-IP-Adresse als Hauptadresse für Clientverbindungen zu verwenden? Antwort: Es ist möglich, aber nicht notwendig.

Im Einzelnen ist die technische Verwendung der DAG-Adresse durchaus möglich und sogar alles wird für Sie funktionieren. Aus praktischer Sicht ist es jedoch besser, dies nicht zu tun, und warum genau, lesen Sie weiter.

Beginnen wir wie immer mit einer soliden Dosis Theorie.

Wie funktioniert die DAG?

An der Spitze der DAG-Hierarchie befindet sich der Hostserver für die PAM-Rolle (Primary Active Manager) … Es bestimmt, welche Kopien der Datenbanken auf welchem ​​Server aktiv und welche passiv sind. Es ist der Server mit der PAM-Rolle, der das Cluster-Quorum enthält und der einzige in der Verfügbarkeitsgruppe ist.

Hinweis: Übrigens ist es die Rolle von PAM, die direkt am Best Copy Selection-Mechanismus beteiligt ist.

Auf allen verbleibenden Servern wird anstelle von PAM die Rolle von SAM (Standby Active Manager) ausgeführt, die andere lokale Dienste darüber informiert, welche Basis wo aktiv ist, und somit der Datenverkehr an die entsprechenden Server umgeleitet wird.

Wenn der Server, der die PAM-Rolle innehat, plötzlich ausfällt, werden seine Aufgaben von einem der SAM-Server abgefangen und die Arbeit fortgesetzt.

Wenn Sie einen DAG-Cluster erstellen, müssen Sie seine IP-Adresse angeben. Dies ist der einzelne Administratorzugriffspunkt (AAP), an den der Netzwerkname des Clusters gebunden wird (der vollständig mit dem Namen des Clusters selbst identisch ist) Sie geben beim Erstellen der DAG an) …

Hinweis: Ich möchte, dass Sie wissen, dass es mit der Version von Exchange SP1 in Kombination mit Windows Server 2012 R2 möglich wurde, eine DAG ohne IP-Adresse zu erstellen. Diese Konfiguration vereinfacht laut den Entwicklern die Verwaltung erheblich und reduziert die Angriffsfläche für Angreifer. Dies ist jedoch alles Theorie, und wir sind an dem Moment interessiert, in dem Exchange in diesem Fall bereits viel weniger an die Rolle des Windows-Failoverclusters gebunden ist und die DAG tatsächlich als von dieser Rolle unabhängigen Dienst bereitstellt. Für diejenigen, die gerne experimentieren, möchte ich Sie daran erinnern, dass die DAG-Verwaltung über das Failover-Cluster-Snap-In kategorisch nicht unterstützt wird!

Und natürlich wird diese IP-Adresse von dem Host gehalten, auf dem die PAM-Rolle ausgeführt wird. Das heißt, Sie können diese Adresse anpingen, eine Verbindung zu ihr herstellen und alle anderen Vorgänge ausführen, die für die am häufigsten mit dem Server verknüpfte Adresse verfügbar sind.

Diese Adresse versuchen sie als Verbindungspunkt für Clients zu verwenden.

Warum solltest du das nicht tun?

Schauen wir uns nun die Hauptgründe an.

Grund Nr. 1: Lastausgleich

Dies ist der offensichtlichste Punkt von allen. Da sich die DAG-Adresse nur auf einem Server befinden kann, ist es logisch, dies anzunehmen dass alle Clientverbindungen von einem einzigen Server bedient werden… Alle anderen Ekschi, egal wie viele, werden teilweise oder vollständig untätig sein.

Diese Situation ist für ein Serverpaar in einer DAG nicht so dramatisch, aber bei mehr als vier Servern wird alles anders (als die Lösungsarchitektur ursprünglich nicht so konzipiert war, dass ein Server hypothetisch in der Lage ist, der gesamten Last standzuhalten).

Grund Nr. 2: Wechseln zwischen Servern

Nach dem Verschieben der DAG-IP auf einen anderen Server eine Lawine von Kunden wird hinter ihm her sein und es ist weit davon entfernt, dass sie keine Verbindungsprobleme haben werden. In diesem Fall ist es nicht einmal so wichtig, ob die beiden Server unterschiedliche Subnetze haben oder nicht.

Grund 3: Verschiedene Subnetze auf Servern

Um diese Situation zu verstehen, müssen Sie eine Einschränkung klären: Tatsache ist, dass es häufig Infrastrukturen gibt, in denen sich Exchange-Server in verschiedenen Subnetzen befinden, z. B. zwischen Rechenzentren. In diesem Fall kann sich der Server aus Subnetz A keine Adresse aus dem Subnetz von Server B zuweisen (ja, selbst wenn dies möglich wäre, wäre dies immer noch von geringem Nutzen). Um dieses Problem zu beheben, fügen Sie der DAG mehrere Adressen hinzu, die basierend auf dem Server zugewiesen werden, auf dem sich das Quorum befindet.

Lastausgleich und Failover Exchange Server 02

Hinweis: Wenn Sie plötzlich vor der Aufgabe stehen, einen Exchange-Server in ein anderes Subnetz zu verschieben, empfehlen wir Ihnen, meinen Artikel Verschieben eines Exchange 2013-Servers zu lesen.

Am Ende bekommen Sie ständig wechselnder A-Datensatz einer Clusterressource und Probleme mit veraltetem Client-Cache.

Ja, das Verschieben der IP-DAG auf einen anderen Server ist möglicherweise kein häufiges Ereignis, aber Sie werden nicht viel Angenehmes erleben.

Grund Nr. 4: Die DAG-IP kann offline geschaltet werden

Es gibt Referenzen dass DAG kann offline gehen, aber die Exchange-Server selbst funktionieren einwandfrei. Ich habe dieses Verhalten nicht getestet und präsentiere es Ihnen so wie es ist.

Grund Nr. 5: Die Lösung wird nicht unterstützt

Nirgendwo in den offiziellen Handbüchern wird erwähnt, dass DAG ip als Adresse für Clientverbindungen verwendet wird.

Dies führt zu einer unangenehmen Schlussfolgerung – herumspielen und Sie selbst müssen sich mit den Konsequenzen Ihrer architektonischen Entscheidung auseinandersetzenund andere können nur mit Ratschlägen helfen, alles menschlich neu zu gestalten, und sie werden Recht haben.

Wie macht man

Der Kern dieses Artikels besteht darin, Ihnen zu erklären, wie es geht nicht es ist notwendig, aber ich kann dich trotzdem nicht allein lassen und dich nicht auf den wahren Weg lenken. Daher jetzt kurz über die Best Practice, ohne auf technische Nuancen einzugehen.

Die einfachste und verständlichste Lösung für den Kundenausgleich ist die Verwendung des bekannten Round Robin. Es funktioniert hervorragend und Outlook unterstützt es sofort.

Hinweis: Ich möchte darauf hinweisen, dass es so einfach wie das Schälen von Birnen ist, einen kostenlosen Load Balancer mit Linux + HAProxy / Nginx-Bundle einzurichten. Es ist noch einfacher, es fehlertolerant zu machen, indem Sie einen Klonserver auf einer anderen Hardware bereitstellen und die Failover-IP auf dieser Hardware erhöhen. Übrigens habe ich eine solche Lösung im Artikel Der einfachste fehlertolerante Layer 4-Balancer ausführlich besprochen.

Die Lösung für große Büros sind kostenpflichtige Hardware- / Software-Balancer, vorzugsweise in einer fehlertoleranten Konfiguration.

So gleichen Sie externe Verbindungen aus

Wenn Sie einen Server haben, wird eine Weiterleitung von einer externen Unternehmens-IP an diesen Server gesendet. Es ist einfach.

Wenn Sie zwei Server haben, können Sie zwei Weiterleitungen durchführen. Outlook kann hervorragend mit RR.1 arbeiten

Umgang mit OWA-Kunden

Bei OWA-Clients müssen Sie sich jedoch ohnehin mit externen Konnektivitätsproblemen befassen, da Browser normalerweise nicht wissen, wie sie mit RR arbeiten sollen.

Hinweis: Wenn Sie zwei Server haben, von denen jeder eine Weiterleitung von externen Adressen erhält, wechseln sich Client-Browser (je nach Problem des DNS-Servers) ab, wenn ein Server ausfällt, und brechen an einer Adresse und dann an einer anderen ab. In dem Moment, in dem sie mit einem inaktiven Server weitergeleitet werden, erhalten sie keine Antwort. Dies ist Option a. in der Abbildung unten.

Die einzige Option ist zu verwenden ausfallsicher Balancer (Option b. im Bild oben), den ich oben erwähnt habe.

In diesem Fall bleibt OWA für externe Clients verfügbar, wenn ein Server ausfällt.

Kommentare bereitgestellt von HyperComments

Leave a Reply

Your email address will not be published. Required fields are marked *