Loadbalancing in Exchange 2013/2016

Eine Frage der Balance

Sobald mehr als ein Client Access Server in der Exchange-Organisation existiert, treten Themen wie Namespace-Design und Lastverteilung auf den Plan. Exchange hat sich zu einer wahren Cloud-Applikation mit der dafür typischen horizontalen Skalierung entwickelt. Das erlaubt Ihnen, viele aus dem Betrieb von Webserver-Farmen bekannte Verfahren auch für die Bereitstellung von Exchange zu nutzen.
Eine Vielzahl mobiler Endgeräte sowie immer mehr Internet-of-Things-Devices bevölkern die Unternehmensnetze. Für Administratoren bedeutet dies, einen wahren ... (mehr)

Mit der in Exchange 2010 eingeführten Database Availability Group hat Microsoft die Hochverfügbarkeit im Backend elegant gelöst. Im Frontend hat Exchange zwar eine extreme Konsolidierung der Protokolle erfahren, denn neben HTTPS kommen lediglich SMTP, IMAP4 und POP3 zum Einsatz.

Um den Client-Zugriff aber tatsächlich hochverfügbar zu machen, müssen Sie sich externer Mittel bedienen. Die gute Nachricht: Sie können dabei auf den großen Erfahrungsschatz der Webserver-Bereitstellung zurückgreifen, denn die aufgeführten Standardprotokolle verhalten sich inzwischen sehr kooperativ, was Lastverteilung angeht.

Sitzungspersistenz sicherstellen

Welche Dienste sind bei Exchange also mit Lastverteilung zu versehen? Allem voran ist Exchange nach wie vor ein Mailserver und bedient die Standard-Protokolle SMTP, IMAP4 und POP3. Möchten Sie für diese Protokolle einen einheitlichen Namensraum anbieten (etwa smtp.meinefirma.de), beachten Sie bitte, dass die Protokolle keine Verlagerung einer bereits ausgehandelten Verbindung auf einen anderen Server unterstützen. Die sogenannte Sitzungspersistenz muss hier unbedingt gewahrt bleiben.

Alle anderen Exchange-Dienste (OWA und ECP, Autodiscover, EWS, OAB, PowerShell, ActiveSync und auch die Outlook-Protokolle RPC und MAPI) sind im Frontend als zustandsloser Proxy ausgeführt. Die Anforderung der Persistenz besteht hier also nicht, sodass sich beispielsweise eine offene OWA-Sitzung auf einen anderen Server schwenken lässt, ohne dass der Benutzer dies merkt oder sich neu authentifizieren muss. All das funktioniert sowohl mit einem einheitlichen Namensraum (der aufgerufene FQDN bleibt gleich, zwischen den Diensten wird nur anhand des virtuellen Verzeichnisses unterschieden) als auch mit separaten Namensräumen. Hier wäre zum Beispiel OWA über "https://owa.meinefirma.de/owa" und EWS über "https://ews.meinefirma.de/EWS/

...

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019