Dies ist meine Präsentation zum aOS Community Event 2019 in Aachen. In dieser Präsentation erfahren Sie, warum es für Exchange Server 2019 eine empfohlene Architektur (Preferred Architecure) für einen sicheren und stabilen Betrieb gibt.

1. aOS Aachen
8. Oktober 2019
Exchange Server 2019 - Wie macht man es richtig
Was ist die Preferred Architecture?
@stensitzki

2. aOS Aachen
8. Oktober 2019
Thomas Stensitzki
Geschäftsführer
Granikos GmbH & Co. KG
MVP | MCT | MCSM
Thomas.Stensitzki@Granikos.eu
www.Granikos.eu
blog.Exchange-Doktor.de
@stensitzki

3. aOS Aachen
8. Oktober 2019
Agenda
Warum gibt es die Preferred Architecture?
Was ist die Preferred Architecture?
Was sind die Alternativen?
Fazit

4. aOS Aachen
8. Oktober 2019
Warum gibt es die Preferred Architecture?
@stensitzki

5. aOS Aachen
8. Oktober 2019
Warum gibt es die Preferred Architecture?
Empfehlung der Exchange Server Produktgruppe zur optimalen
Implementierung von Exchange Server
Erste Veröffentlichung für Exchange Server 2013
Hervorgegangen aus den Erfahrungen im täglichen Betrieb bei
Microsoft und Kunden
Berücksichtigung von besonderen Supportereignissen bei Kunden
Weiterentwicklung für Exchange Server 2016 und 2019

6. • Exchange Online
Standardisiert
• Exchange On-Premises Preferred Architecture Design
Strukturiert
• Exchange On-Premises Best Practices Design
Empfohlen
• Exchange On-Premises angepasstes Design
Unterstützt
• Exchange On-Premises nicht unterstütztes Design
Funktioniert
Optimaler Betrieb
Auf dem
richtigen Weg
Technische
Mindestanforderung
Implementierung

7. aOS Aachen
September 3rd 2018
Was ist die Preferred Architecture?
@stensitzki

8. aOS Aachen
8. Oktober 2019
Was ist die Preferred Architecture?
Namespace Design
Site Resilient Data Center Design
Server Design
Database Availability Group Design
 Verzicht auf Komplexität und redundante Komponenten wo möglich
 Einfaches und voraussagbares Recovery-Modell

9. aOS Aachen
8. Oktober 2019
Namespace Design
Namespace
Load Balancing Principles
Bound Namespace
Unbound Namespace
Split-DNS

10. aOS Aachen
8. Oktober 2019
Namespace Design
Namespace – Der Namensraum
Der Namensraum definiert alle Hostnamen über die Exchange Server
Funktionen intern und extern bereitgestellt werden
Zwei Hostnamen sind ausreichend
 mail.varunagroup.de
 autodiscover.varunagroup.de

11. aOS Aachen
8. Oktober 2019
Namespace Design
Load Balancer Principles (1)
Keine Session-Affinity für Load Balancer
Konfiguration der Health-Proben für healthcheck.htm
Load Balancer Konfiguration und Health-Proben müssen ins
Namespace Design passen
Empfehlung für einen einzelnen Namensraum mit Layer 7 Load
Balancing

12. aOS Aachen
8. Oktober 2019
Empfehlung für Load Balancer-Verbindungen
 Round Robin
Round Robin hat eine langsame Konvergenzzeit für lang-laufende
Verbindungen (RPC/HTTP)
MAPI/HTTP ist davon nicht betroffen
 Least Connections
Least Connections bietet eine kurze Konvergenzzeit
Least Connections kann zu einer Instabilität des Servers führen, wenn zu
schnell zu viele Client-Verbindungen auf den Server geführt werden
„Slow Start“-Option des Load Balancers verhindert eine Instabilität
Namespace Design
Load Balancer Principles (2)

13. aOS Aachen
8. Oktober 2019
DAG1
DAG2
Passiv
Aktiv
Aktiv
Passiv
IP-Adresse RZ2
DNS-Namensauflösung
IP-Adresse RZ1
rz2.varunagroup.de
rz1.varunagroup.de
Namespace Design
Bound Namespace

14. aOS Aachen
8. Oktober 2019
DAG1
DAG2
DNS-Namensauflösung
IP-Adresse RZ2
mail.varunagroup.de
IP-Adresse RZ1
Namespace Design
Unbound Namespace
Aktiv Aktiv
AktivAktiv

15. aOS Aachen
8. Oktober 2019
Eine einheitliche DNS-Domäne für interne und externe Hostnamen
Getrennte DNS-Zonen für interne und externe Namensauflösung
 Interner DNS-Server ist Bestandteil der Active Directory Gesamtstruktur
 Externer DNS-Server wird meist vom Domänenanbieter gehostet
Die korrekte Konfiguration der DNS-Einträge ist entscheidend
 für den sicheren Versand und Empfang von E-Mail-Nachrichten
 für die automatischen Konfiguration und Verbindung von E-Mail-Clients
Namespace Design
Split-DNS

16. aOS Aachen
8. Oktober 2019
Site Resilient Data Center Design
Eine Active Directory Site je Data Center oder Serverraum
 Resilienz für Nachrichtentransport mit Shadow Redundancy und
SafetyNet erfordert DAG-Mitgliedsserver in unterschiedlichen Sites
 Separate Active Directory Sites für Subnetze mit einer Latenz größer
10ms
Erweiterte Active Directory Sites sind unterstützt aber nicht empfohlen

17. aOS Aachen
8. Oktober 2019
Server Design
Physische Server mit lokalem Datenspeicher sind virtualisierten Server
vorzuziehen
Server Skalierung für 80% Auslastung im Fehlerfall
Virtualisierung bringt Performanceeinbußen
Virtualisierung erfordert zusätzliche Verwaltung
Virtualisierung erhöht die Komplexität im Betrieb
Virtualisierung erhöht die Zahl der Fehlerdomänen
Virtualisierung erfordert zusätzliche Wiederherstellungsprozesse
ohne Mehrwert

18. aOS Aachen
8. Oktober 2019
Server Design
Standard-Server
2 Höheneinheiten, Dual-Sockel, bis zu 48 physischen Prozessor-Cores
Bis zu 256GB Arbeitsspeicher
Batteriegepufferter Schreib-Cache-Controller
12 oder mehr Laufwerkplätze im Servergehäuse
Gleichzeitiger Betrieb von traditionellen Festplatten und Solid-State-
Drives im gleichen Server Gehäuse
Skalierung der Plattform durch Scale-Out, nicht durch Scale-Up

19. aOS Aachen
8. Oktober 2019
Database Availability Group Design
Jede DAG in einem resilienten Data Center Paar ist für einen
ungebundenen Namensraum konfiguriert
Nutzung der MetaCache-Datenbanken zur Performancesteigerung
Alle aktiven Datenbankkopien sind gleichmäßig über alle DAG-
Mitgliedsserver verteilt
Jeder Server stellt alle Funktionsdienste zur Verfügung
Im Fehlerfall ausgewogene Lastverteilung über die verbliebenen
Server
Vorhersehbare Erhöhung der Ressourcennutzung je Server im
Fehlerfall

20. aOS Aachen
8. Oktober 2019
Database Availability Group Design
DAG Netzwerk Design
Eine Netzwerkschnittstelle ohne Teaming
Nutzung für Clientzugriffe und Datenreplikation
Fehlerunabhängiger Standardprozess zur Wiederherstellung
Witness-Server Platzierung
Idealerweise in dritter Active Directory Site
Keine Unterstützung für Failover-Cluster „Cloud Witness“-Funktion

21. aOS Aachen
8. Oktober 2019
Database Availability Group Design
Data Resiliency
Schutz gegen zufällige oder absichtliche Löschung von Objekten durch
Single Item Recovery oder In-Place Hold
Zeitfenster zur Wiederherstellung von gelöschten Objekten muss dem
individuellen SLA zur Objekt-Wiederherstellung angepasst werden
Schutz gegen systemweite oder schwere logische Datenkorruption
durch verzögerte Datenbankkopie

22. aOS Aachen
8. Oktober 2019
Database Availability Group Design
Office Online Server Design
Office Online Server Farm mit mindestens zwei Nodes in jedem Data
Center mit Exchange Server 2019 Systemen
Mindestens 8 Prozessor-Cores
Mindestens 32GB Arbeitsspeicher
Mindestens 40GB Festplattenplatz für Protokolldateien
Konfiguration der Exchange Server 2019 Server zur Nutzung der Office
Online Server im lokalen Data Center
Sicherstellung einer niedrigen Latenz und hoher Bandbreite zwischen
den Servern

23. aOS Aachen
8. Oktober 2019
Was sind die Alternativen?
@stensitzki

24. aOS Aachen
8. Oktober 2019
Was sind die Alternativen?
Vermeiden Sie große Abweichungen von der Preferred Architecture
Folgen Sie mindestens den Best Practices für den Betrieb von Exchange
Server 2019
Die Funktionen zur Hochverfügbarkeit sind im Produkt integriert
Prüfen Sie eine Nutzung von Exchange Online

25. aOS Aachen
8. Oktober 2019
Fazit
@stensitzki

26. aOS Aachen
8. Oktober 2019
Fazit
Standardisierter Betrieb von Exchange Server 2019
Hochverfügbarkeit auf Applikationsebene
Physische Server
Einfache Wiederherstellung im Fehlerfall
Alternative Exchange Online
Supportende von Exchange Server 2010
13. Oktober 2020
https://go.granikos.eu/E14EndOfSupport

27. aOS Aachen
8. Oktober 2019

28. aOS Aachen
8. Oktober 2019
Thomas.Stensitzki@Granikos.eu
www.Granikos.eu
blog.Exchange-Doktor.de
@stensitzki

29. aOS Aachen
8. Oktober 2019
Ressourcen
Die richtige Exchange Architektur
Virtualisierung von Exchange Server 2019 in Zeiten von 48 Cores und MetaCache-
Datenbank
Pro und Contra von "Floating"-Postfachdatenbanken
Exchange 2019 preferred architecture
The Exchange 2016 Preferred Architecture
DAG: Beyond the “A”
Exchange Native Data Protection
Load Balancing in Exchange 2016