von Redaktion IT-A…
Lesezeit
3 Minuten
Exchange 2019 Preferred Architecture (2)
Exchange ist ein äußerst komplexes Produkt, das verschiedenste Konfigurationsmöglichkeiten kennt. Dieser Workshop bringt Ihnen einige Empfehlungen zur Konfiguration von Exchange 2019 näher, damit Sie sich bei der Entwicklung Ihrer Umgebung besser an den Vorgaben von Microsoft orientieren können. Dabei gehen wir unter anderem auf Server, Storage, Lastenverteilung und DNS-Namen ein. In der zweiten Folge beschäftigen wir uns damit, was sich bei den Serverrollen, der Ausfallsicherheit und der Lastenverteilung geändert hat.
Alle Rollen auf allen Servern
Exchange 2016 arbeitete nur noch mit einer Rolle, in der die früheren Rollen Hub Transport, Client Access und Unified Messaging (UM) aufgegangen sind. Exchange 2019 arbeitet auch weiterhin nur mit einer Rolle, aber aus dieser verabschieden sich nun die Unified-Messaging-Bestandteile. Für Umgebungen, bei denen UM im Einsatz ist, kann das ein Show Stopper für eine Migration sein. Microsoft empfiehlt hier die Nutzung von Clouddiensten. Der Fokus von Exchange liegt somit auf einem performanten Enterprise-Messaging-System und nicht auf Collaboration.
Mit nur einer Rolle kommen immer der gleiche Installationsprozess und die gleiche Konfiguration zum Einsatz. Durch diese Vereinheitlichung soll sich auch die Administration vereinfachen lassen. Weiterhin steht durch diesen Schritt ein größerer Pool an Servern für jede Aufgabe zur Verfügung, sodass die Last besser verteilt und die Ausfallsicherheit weiter erhöht wird.
Ausfallsicherheit und Lastenverteilung neu aufgelegt
Die Auswirkungen des Ausfalls eines Clientzugriffsservers (CAS) an einem Standort kompensieren Sie üblicherweise über Loadbalancing-Mechanismen. Unter Exchange 2010 wurde meist eine Clientzugriffsserver-Array zusammen mit einem Hard-/Software-Loadbalancer bereitgestellt, um Fehlertoleranz und eine effiziente Auslastung von Servern zu erzielen. Die Loadbalancer mussten dabei eine Sitzung zwischen dem Client und einem bestimmten Clientzugriffsserver herstellen und halten (Sitzungsaffinität). Durch diese Voraussetzung war bei Exchange 2010 die Verwendung einer Layer-7-Lastenausgleichslösung Voraussetzung, die als "Lastenausgleich auf Anwendungsebene" bekannt ist.
Seit Exchange 2013 ist dies nicht mehr nötig. Der CAS arbeitet als statusloser Lightweight-Proxyserver, über den Clients eine Verbindung zu Exchange-Postfachservern herstellen. Sitzungsaffinität ist keine Voraussetzung mehr und eingehende Verbindungen werden an einen verfügbaren Mailboxserver umgeleitet. Die Lastenausgleichsarchitektur ist dadurch flexibler, bietet mehr Auswahl und ist weniger komplex.
Zur Auswahl standen bisher nur Windows Network Loadbalancing (WNLB) oder Hard-/Software-Loadbalancer. Gegen WNLB sprachen vor allem die fehlende Diensteprüfung und die fehlende Kompatibilität des Windows-Netzwerklastenausgleichs mit Windows-Failoverclustering, das die Voraussetzung für Database Availability Groups (DAG) ist. Da sich WLNB nicht auf einem DAG-Server einrichten lässt, sind zusätzliche Server zu installieren, was die Komplexität deutlich erhöht. Ein Ausfall eines Webdienstes auf einem Exchange-Server wird durch WLNB nicht erkannt und Anfragen werden weitergeleitet, solange die IP-Adresse des Servers erreichbar ist.
Die Gründe, die gegen WLNB sprechen, sprechen für Loadbalancer: Diensteprüfung und die Nutzung von Multi-Role-Servern. Mit der beschriebenen Architekturveränderung ab Exchange 2013 können Sie in Exchange 2019 DNS Round Robin als zusätzliche Option nutzen. Gerade in Hinblick auf die Vereinfachung ist dies der empfohlene Weg von Microsoft. Hierüber erfolgt keine Lastenverteilung, aber eine erhöhte Verfügbarkeit ist gegeben. Browser und Outlook-Clients wenden diese Art der Auflösung nahezu ohne Einschränkungen an und finden ohne Probleme das richtige Ziel, selbst wenn ein CAS nicht erreichbar ist. Loadbalancer sind weiterhin eine nützliche Ergänzung, im Exchange-Umfeld spielen Sie aber eine untergeordnete Rolle.
Über interne und externe Namensbereiche
Eine der großen Diskussionen bei der Planung einer Exchange-Umgebung ist immer wieder die Festlegung der DNS-Namen. Microsoft empfiehlt die Nutzung des gleichen Namensbereiches für die interne und externe Anbindung. Sofern die interne Domain nicht dem externen Domainnamen entspricht, führen Sie ein Split-DNS in Ihrer Domain ein. Beim Split-DNS richten Sie eine lokale Zone ein, die mit den passenden Namen auf die internen IP-Adressen referenziert. Dies ist auch notwendig, da offizielle Zertifikatstellen zukünftig keine internen Domänennamen beziehungsweise IP-Adressen in neuen Zertifikaten hinterlegen, sodass Sie um eine einheitliche Benennung kaum herumkommen.
Für ein Split-DNS legen Sie zunächst im DNS eine zusätzliche Reverse Lookup Zone mit dem öffentlichen Domänenamen an. Im Anschluss erstellen Sie A-Records für die externen Namen mit den IP-Adressen der internen Server. Sollte der Name Ihrer Website der E-Mail-Domäne entsprechen, wird die Auflösung der Website intern zunächst nicht mehr funktionieren.
Richten Sie zur Fehlerbeseitigung einen zusätzlichen A-Record mit dem Namen www ein und geben Sie diesem Eintrag die IP-Adresse der externen Website. Die IP-Adresse der Website erhalten Sie über eine nslookup-Abfrage von einem Client, der noch Zugriff auf die Domain hat:
ln/dr/Christian Schulenburg
[3] www.petenetlive.com/KB/Article/0000830.htm
Exchange 2016 arbeitete nur noch mit einer Rolle, in der die früheren Rollen Hub Transport, Client Access und Unified Messaging (UM) aufgegangen sind. Exchange 2019 arbeitet auch weiterhin nur mit einer Rolle, aber aus dieser verabschieden sich nun die Unified-Messaging-Bestandteile. Für Umgebungen, bei denen UM im Einsatz ist, kann das ein Show Stopper für eine Migration sein. Microsoft empfiehlt hier die Nutzung von Clouddiensten. Der Fokus von Exchange liegt somit auf einem performanten Enterprise-Messaging-System und nicht auf Collaboration.
Mit nur einer Rolle kommen immer der gleiche Installationsprozess und die gleiche Konfiguration zum Einsatz. Durch diese Vereinheitlichung soll sich auch die Administration vereinfachen lassen. Weiterhin steht durch diesen Schritt ein größerer Pool an Servern für jede Aufgabe zur Verfügung, sodass die Last besser verteilt und die Ausfallsicherheit weiter erhöht wird.
Ausfallsicherheit und Lastenverteilung neu aufgelegt
Die Auswirkungen des Ausfalls eines Clientzugriffsservers (CAS) an einem Standort kompensieren Sie üblicherweise über Loadbalancing-Mechanismen. Unter Exchange 2010 wurde meist eine Clientzugriffsserver-Array zusammen mit einem Hard-/Software-Loadbalancer bereitgestellt, um Fehlertoleranz und eine effiziente Auslastung von Servern zu erzielen. Die Loadbalancer mussten dabei eine Sitzung zwischen dem Client und einem bestimmten Clientzugriffsserver herstellen und halten (Sitzungsaffinität). Durch diese Voraussetzung war bei Exchange 2010 die Verwendung einer Layer-7-Lastenausgleichslösung Voraussetzung, die als "Lastenausgleich auf Anwendungsebene" bekannt ist.
Seit Exchange 2013 ist dies nicht mehr nötig. Der CAS arbeitet als statusloser Lightweight-Proxyserver, über den Clients eine Verbindung zu Exchange-Postfachservern herstellen. Sitzungsaffinität ist keine Voraussetzung mehr und eingehende Verbindungen werden an einen verfügbaren Mailboxserver umgeleitet. Die Lastenausgleichsarchitektur ist dadurch flexibler, bietet mehr Auswahl und ist weniger komplex.
Zur Auswahl standen bisher nur Windows Network Loadbalancing (WNLB) oder Hard-/Software-Loadbalancer. Gegen WNLB sprachen vor allem die fehlende Diensteprüfung und die fehlende Kompatibilität des Windows-Netzwerklastenausgleichs mit Windows-Failoverclustering, das die Voraussetzung für Database Availability Groups (DAG) ist. Da sich WLNB nicht auf einem DAG-Server einrichten lässt, sind zusätzliche Server zu installieren, was die Komplexität deutlich erhöht. Ein Ausfall eines Webdienstes auf einem Exchange-Server wird durch WLNB nicht erkannt und Anfragen werden weitergeleitet, solange die IP-Adresse des Servers erreichbar ist.
Die Gründe, die gegen WLNB sprechen, sprechen für Loadbalancer: Diensteprüfung und die Nutzung von Multi-Role-Servern. Mit der beschriebenen Architekturveränderung ab Exchange 2013 können Sie in Exchange 2019 DNS Round Robin als zusätzliche Option nutzen. Gerade in Hinblick auf die Vereinfachung ist dies der empfohlene Weg von Microsoft. Hierüber erfolgt keine Lastenverteilung, aber eine erhöhte Verfügbarkeit ist gegeben. Browser und Outlook-Clients wenden diese Art der Auflösung nahezu ohne Einschränkungen an und finden ohne Probleme das richtige Ziel, selbst wenn ein CAS nicht erreichbar ist. Loadbalancer sind weiterhin eine nützliche Ergänzung, im Exchange-Umfeld spielen Sie aber eine untergeordnete Rolle.
Über interne und externe Namensbereiche
Eine der großen Diskussionen bei der Planung einer Exchange-Umgebung ist immer wieder die Festlegung der DNS-Namen. Microsoft empfiehlt die Nutzung des gleichen Namensbereiches für die interne und externe Anbindung. Sofern die interne Domain nicht dem externen Domainnamen entspricht, führen Sie ein Split-DNS in Ihrer Domain ein. Beim Split-DNS richten Sie eine lokale Zone ein, die mit den passenden Namen auf die internen IP-Adressen referenziert. Dies ist auch notwendig, da offizielle Zertifikatstellen zukünftig keine internen Domänennamen beziehungsweise IP-Adressen in neuen Zertifikaten hinterlegen, sodass Sie um eine einheitliche Benennung kaum herumkommen.
Bild 1: In Exchange 2019 lautet die Empfehlung, dass interne und externe Namensbereiche identisch sind.
Die Konfiguration nehmen Sie über das EAC oder die PowerShell vor.
Die Konfiguration nehmen Sie über das EAC oder die PowerShell vor.
Für ein Split-DNS legen Sie zunächst im DNS eine zusätzliche Reverse Lookup Zone mit dem öffentlichen Domänenamen an. Im Anschluss erstellen Sie A-Records für die externen Namen mit den IP-Adressen der internen Server. Sollte der Name Ihrer Website der E-Mail-Domäne entsprechen, wird die Auflösung der Website intern zunächst nicht mehr funktionieren.
Richten Sie zur Fehlerbeseitigung einen zusätzlichen A-Record mit dem Namen www ein und geben Sie diesem Eintrag die IP-Adresse der externen Website. Die IP-Adresse der Website erhalten Sie über eine nslookup-Abfrage von einem Client, der noch Zugriff auf die Domain hat:
nslookup <www.domäne.de>Eine ausführliche Beschreibung zur Einrichtung eines Split-DNS finden Sie unter [3] in Internet.
Im ersten Teil
des Workshops erklären wir, warum Microsoft mit Exchange 2019 den Pfad
der Virtualisierung verlassen hat und wie der Storage-Unterbau aussehen
sollte. In der zweiten Folge gehen wir darauf ein, was sich bei den Serverrollen, der Ausfallsicherheit und der Lastenverteilung geändert hat. Im dritten Teil erläutern wir die Bestimmung des DNS-Namens und wie Sie die DAG richtig konfigurieren.
ln/dr/Christian Schulenburg
[3] www.petenetlive.com/KB/Article/0000830.htm
