von Redaktion IT-A…
Lesezeit
4 Minuten
Exchange 2019 Preferred Architecture (3)
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. Im dritten Teil erläutern wir die Bestimmung des DNS-Namens und wie Sie die DAG richtig konfigurieren.
So bestimmen Sie den DNS-Namen
Nachdem geklärt ist, dass interne und externe Namen identisch sind, stellt sich die Frage, welche Namen zur Anwendung kommen und damit in das Zertifikat müssen. Zunächst einige Hintergrundaspekte: Beim Namen wählen Sie ein ungebundenen Namensbereich für Ihre Rechenzentren, sofern Sie über verschiedenen Zugangspunkte aus dem Internet verfügen. Im Gegensatz zum gebundenen Namensbereich findet ein Name für alle Rechenzentren Verwendung. Die öffentlichen IP-Adressen der verschiedenen Zugriffspunkte werden über den gleichen Namen im öffentlichen DNS registriert und die Auflösung erfolgt, wie bereits beschrieben, extern über DNS Round Robin.
Auf diesem Weg erhalten anfragende Clients abwechselnd eine andere IP-Adresse zurück. Der Netzwerkverkehr wird infolge auf beide Rechenzentren verteilt und circa 50 Prozent der Anfragen werden zwischen den Datacentern weitergeleitet. Die Namensentscheidung ist auch von der Netzwerktopologie abhängig und es kann Sinn ergeben, einen gebundenen Namensbereich zu nutzen. Dies ist zum Beispiel der Fall, wenn ein Datencenter in Europa und eines in Nordamerika angesiedelt ist und Sie den Traffic zwischen den Locations begrenzen wollen.
Zum Einsatz kommt also nur ein Name für sämtliche Clientzugriffe auf allen Servern einer Umgebung: "mail.domain.de". Neben dem Zugriffspunkt für die Clients erstellen Sie als zweiten DNS-Eintrag ein Autodiscover-Eintrag: "autodiscover. domain.de". Optional richten Sie noch Namen für andere Dienste ein, etwa "imap.domain.de" oder "smtp.domain.de".
Die Namen der Webzugriffe ändern Sie im Exchange Administration Center unter dem Punkt "Server / Virtuelle Verzeichnisse". Als weitere Möglichkeit zur Einrichtung der URLs steht Ihnen die PowerShell mit den folgenden Befehlen und den Parametern "InternalUrl" und "ExternalUrl" zur Verfügung:
DAG richtig konfiguriert
Seit Exchange 2010 gehören DAGs zum festen Bestandteil von Exchange und sind der einfachste Weg, um Mailbox-Server abzusichern. Dabei werden Datenbankkopien über die Windows-Cluster-Technologien auf bis zu 16 verschiedene Mailbox-Server verteilt, um eine passive Kopie kurzfristig zu aktivieren. Die Einrichtung erfolgt dabei komplett über Exchange, ohne dass Sie sich mit dem Failovercluster-Manager näher beschäftigen.
Bei der Nutzung einer DAG laufen alle DAG-Mitglieder unter der gleichen Betriebssystemversion und weisen die gleiche Verzeichnisstruktur für die Datenbanken auf. Darüber hinaus verfügen alle Member-Server einer DAG über die gleiche Exchange-Version. Bis Exchange 2013 benötigte jede DAG ein Cluster Name Object (CNO). Dabei handelt es sich um ein AD-Objekt, das Exchange für die interne Cluster-Kommunikation nutzt. Der Name der DAG entspricht dem CNO.
Bei Exchange 2013 vor dem SP1 mussten Sie zunächst das CNO vorbereiten. Mit dem Update auf Exchange 2013 SP1 und in Verbindung mit Windows 2012 R2 führt Microsoft die AD-unabhängige Cluster-Konfiguration ein. Damit sind auch keine IP-Adressen aus den Subnetzen der DAG-Mitglieder mehr nötig. Ein Pre-Staging des CNOs ist somit nicht mehr erforderlich und die Einrichtung fällt deutlich leichter. Eine DAG neuen Typs richten Sie mit folgendem Befehl ein:
Beim Hinzufügen eines Servers zur DAG wird auch weiterhin automatisch das Failovercluster-Feature installiert. Im Unterschied zu einer klassischen DAG werden Ihnen im Failovercluster-Manager zur DAG beziehungsweise zum Cluster keine Informationen mehr angezeigt. Wundern Sie sich nicht, wenn Sie zukünftig einen Blick in den Manager werfen und Ihnen augenscheinlich Informationen fehlen.
Im nächsten Schritt fügen Sie die Server der DAG hinzu und verteilen die Mailboxdatenbanken auf die Exchange-Server. Hier gibt es keine Änderungen zum bisherigen Vorgehen. Im folgenden Beispiel fügen wir den Server LABEX161 der DAG01 hinzu und richten auf dem Server LABEX162 eine Kopie der Datenbank DB01 ein:
DAG-Netzwerk und Zeugenserver
DAG-Netzwerke werden bei der Einrichtung einer DAG automatisch angelegt und für den Replikations- oder MAPI-Verkehr verwendet. Jede DAG enthält maximal ein MAPI-Netzwerk und beliebige Replikationsnetzwerke. Bei Exchange 2010 war die Trennung zwischen Clientzugriffs- und das Replikationsnetz noch Best Practice, während Microsoft von der logischen Trennung zu Gunsten der Vereinfachung ab Exchange 2013 abrückt. Dies ist zum einen der höheren Netzwerkbandbreiten geschuldet – 10 GBit verbreitet sich immer mehr – sodass Performance-Engpässe der Vergangenheit angehören.
Zum anderen nutzt Exchange meist die gleiche Netzwerkinfrastruktur, sodass eine Trennung aus Sicherheitsgründen wenig Sinn ergibt. Ein Fehler des Servers oder im Netzwerkbereich führt immer zur Aktivierung einer Kopie eines anderen DAG-Mitglieds und eine Vereinfachung der Konfiguration ist zu empfehlen. Eine manuelle Konfiguration ist nicht notwendig. Ein Eingriff ist nur bei iSCSI-Netzwerken nötig. Deaktivieren Sie diese, sofern diese vorhanden sind:
Fazit
Bei der Konfiguration von Microsoft Exchange 2019 hat sich nur wenig verändert.
Vor allem durch das Tiering mit SSD-Festplatten für MCDB müssen Sie bei der Festplattenkonfiguration einmal genauer hinschauen. Dem Weg zurück auf physische Server mit einfachen Festplatten bleibt Microsoft treu. Das Mantra "einfacher ist besser" ist stark spürbar und erleichtert die Arbeit der Administratoren deutlich.
ln/dr/Christian Schulenburg
Nachdem geklärt ist, dass interne und externe Namen identisch sind, stellt sich die Frage, welche Namen zur Anwendung kommen und damit in das Zertifikat müssen. Zunächst einige Hintergrundaspekte: Beim Namen wählen Sie ein ungebundenen Namensbereich für Ihre Rechenzentren, sofern Sie über verschiedenen Zugangspunkte aus dem Internet verfügen. Im Gegensatz zum gebundenen Namensbereich findet ein Name für alle Rechenzentren Verwendung. Die öffentlichen IP-Adressen der verschiedenen Zugriffspunkte werden über den gleichen Namen im öffentlichen DNS registriert und die Auflösung erfolgt, wie bereits beschrieben, extern über DNS Round Robin.
Auf diesem Weg erhalten anfragende Clients abwechselnd eine andere IP-Adresse zurück. Der Netzwerkverkehr wird infolge auf beide Rechenzentren verteilt und circa 50 Prozent der Anfragen werden zwischen den Datacentern weitergeleitet. Die Namensentscheidung ist auch von der Netzwerktopologie abhängig und es kann Sinn ergeben, einen gebundenen Namensbereich zu nutzen. Dies ist zum Beispiel der Fall, wenn ein Datencenter in Europa und eines in Nordamerika angesiedelt ist und Sie den Traffic zwischen den Locations begrenzen wollen.
Bild 2: Sofern es mehrere Rechenzentren gibt, verwenden Sie einen einheitlichen DNS-Namen.
Zum Einsatz kommt also nur ein Name für sämtliche Clientzugriffe auf allen Servern einer Umgebung: "mail.domain.de". Neben dem Zugriffspunkt für die Clients erstellen Sie als zweiten DNS-Eintrag ein Autodiscover-Eintrag: "autodiscover. domain.de". Optional richten Sie noch Namen für andere Dienste ein, etwa "imap.domain.de" oder "smtp.domain.de".
Die Namen der Webzugriffe ändern Sie im Exchange Administration Center unter dem Punkt "Server / Virtuelle Verzeichnisse". Als weitere Möglichkeit zur Einrichtung der URLs steht Ihnen die PowerShell mit den folgenden Befehlen und den Parametern "InternalUrl" und "ExternalUrl" zur Verfügung:
Set-ActiveSyncVirtualDirectory Set-WebServicesVirtualDirectory Set-OabVirtualDirectory Set-OwaVirtualDirectory Set-EcpVirtualDirectory Set-PowerShellVirtualDirectory Get-MapiVirtualDirectoryEinzig die Autodiscover-URL richten Sie direkt über den Server ein:
Set-ClientAccessServer -Identity LABEX19 -AutoDiscoverService -InternalUri https://autodiscover.<domäne.de>/Autodiscover/Autodiscover.xml
DAG richtig konfiguriert
Seit Exchange 2010 gehören DAGs zum festen Bestandteil von Exchange und sind der einfachste Weg, um Mailbox-Server abzusichern. Dabei werden Datenbankkopien über die Windows-Cluster-Technologien auf bis zu 16 verschiedene Mailbox-Server verteilt, um eine passive Kopie kurzfristig zu aktivieren. Die Einrichtung erfolgt dabei komplett über Exchange, ohne dass Sie sich mit dem Failovercluster-Manager näher beschäftigen.
Bei der Nutzung einer DAG laufen alle DAG-Mitglieder unter der gleichen Betriebssystemversion und weisen die gleiche Verzeichnisstruktur für die Datenbanken auf. Darüber hinaus verfügen alle Member-Server einer DAG über die gleiche Exchange-Version. Bis Exchange 2013 benötigte jede DAG ein Cluster Name Object (CNO). Dabei handelt es sich um ein AD-Objekt, das Exchange für die interne Cluster-Kommunikation nutzt. Der Name der DAG entspricht dem CNO.
Bei Exchange 2013 vor dem SP1 mussten Sie zunächst das CNO vorbereiten. Mit dem Update auf Exchange 2013 SP1 und in Verbindung mit Windows 2012 R2 führt Microsoft die AD-unabhängige Cluster-Konfiguration ein. Damit sind auch keine IP-Adressen aus den Subnetzen der DAG-Mitglieder mehr nötig. Ein Pre-Staging des CNOs ist somit nicht mehr erforderlich und die Einrichtung fällt deutlich leichter. Eine DAG neuen Typs richten Sie mit folgendem Befehl ein:
New-DatabaseAvailabilityGroup -Name DAG01 -DatabaseAvailabilityGroupEine AD-unabhängige DAG können Sie ebenfalls über die EAC einrichten. Fügen Sie bei der Erstellung einfach die DAGIP-Adresse 255.255.255.255 in der Konfigurationsmaske hinzu.
-IpAddresses ([system.net.ipaddress])::none
Beim Hinzufügen eines Servers zur DAG wird auch weiterhin automatisch das Failovercluster-Feature installiert. Im Unterschied zu einer klassischen DAG werden Ihnen im Failovercluster-Manager zur DAG beziehungsweise zum Cluster keine Informationen mehr angezeigt. Wundern Sie sich nicht, wenn Sie zukünftig einen Blick in den Manager werfen und Ihnen augenscheinlich Informationen fehlen.
Im nächsten Schritt fügen Sie die Server der DAG hinzu und verteilen die Mailboxdatenbanken auf die Exchange-Server. Hier gibt es keine Änderungen zum bisherigen Vorgehen. Im folgenden Beispiel fügen wir den Server LABEX161 der DAG01 hinzu und richten auf dem Server LABEX162 eine Kopie der Datenbank DB01 ein:
Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer LABEX161Dieses Vorgehen stellt ein weiterer Schritt zur Vereinfachung der Architektur dar und beschleunigt die Einrichtung einer DAG deutlich.
Add-MailboxDatabaseCopy -Identity DB01 -MailboxServer LABEX162
-ActivationPreference 2
DAG-Netzwerk und Zeugenserver
DAG-Netzwerke werden bei der Einrichtung einer DAG automatisch angelegt und für den Replikations- oder MAPI-Verkehr verwendet. Jede DAG enthält maximal ein MAPI-Netzwerk und beliebige Replikationsnetzwerke. Bei Exchange 2010 war die Trennung zwischen Clientzugriffs- und das Replikationsnetz noch Best Practice, während Microsoft von der logischen Trennung zu Gunsten der Vereinfachung ab Exchange 2013 abrückt. Dies ist zum einen der höheren Netzwerkbandbreiten geschuldet – 10 GBit verbreitet sich immer mehr – sodass Performance-Engpässe der Vergangenheit angehören.
Zum anderen nutzt Exchange meist die gleiche Netzwerkinfrastruktur, sodass eine Trennung aus Sicherheitsgründen wenig Sinn ergibt. Ein Fehler des Servers oder im Netzwerkbereich führt immer zur Aktivierung einer Kopie eines anderen DAG-Mitglieds und eine Vereinfachung der Konfiguration ist zu empfehlen. Eine manuelle Konfiguration ist nicht notwendig. Ein Eingriff ist nur bei iSCSI-Netzwerken nötig. Deaktivieren Sie diese, sofern diese vorhanden sind:
Set-DatabaseAvailabilityGroupNetwork -Identity DAG10\DAGNetwork02Zeugenserver kommen weiterhin nur dann zur Anwendung, wenn eine gerade Anzahl von Mitgliedern in der DAG vorliegt. Ist eine DAG über zwei Standorte verteilt und kommt ein Witness-Server zum Einsatz, sollte der Server nach Möglichkeit in einem dritten Standort liegen. Sofern keine dritte Lokation vorhanden ist, bietet sich auch die Nutzung von Microsoft Azure an. Voraussetzung ist, dass ein Netzwerkfehler zwischen den primären Standorten keinen Einfluss auf den dritten Standort hat. Dadurch kann immer ein automatischer Failover erfolgen, egal welches Rechenzentrum betroffen ist.
-ReplicationEnabled:$false -IgnoreNetwork:$true
Fazit
Bei der Konfiguration von Microsoft Exchange 2019 hat sich nur wenig verändert.
Vor allem durch das Tiering mit SSD-Festplatten für MCDB müssen Sie bei der Festplattenkonfiguration einmal genauer hinschauen. Dem Weg zurück auf physische Server mit einfachen Festplatten bleibt Microsoft treu. Das Mantra "einfacher ist besser" ist stark spürbar und erleichtert die Arbeit der Administratoren deutlich.
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
