Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

aOS Aachen 2019 - Exchange Server 2019 - Wie macht man es richtig?

91 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

aOS Aachen 2019 - Exchange Server 2019 - Wie macht man es richtig?

  1. 1. aOS Aachen 8. Oktober 2019 Exchange Server 2019 - Wie macht man es richtig Was ist die Preferred Architecture? @stensitzki
  2. 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. 3. aOS Aachen 8. Oktober 2019 Agenda Warum gibt es die Preferred Architecture? Was ist die Preferred Architecture? Was sind die Alternativen? Fazit
  4. 4. aOS Aachen 8. Oktober 2019 Warum gibt es die Preferred Architecture? @stensitzki
  5. 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. 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. 7. aOS Aachen September 3rd 2018 Was ist die Preferred Architecture? @stensitzki
  8. 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. 9. aOS Aachen 8. Oktober 2019 Namespace Design Namespace Load Balancing Principles Bound Namespace Unbound Namespace Split-DNS
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 23. aOS Aachen 8. Oktober 2019 Was sind die Alternativen? @stensitzki
  24. 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. 25. aOS Aachen 8. Oktober 2019 Fazit @stensitzki
  26. 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. 27. aOS Aachen 8. Oktober 2019
  28. 28. aOS Aachen 8. Oktober 2019 Thomas.Stensitzki@Granikos.eu www.Granikos.eu blog.Exchange-Doktor.de @stensitzki
  29. 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

×