Exchange 2019 – Bevorzugte Architektur

Mit jeder neuen Version von Exchange Server für unsere lokalen Kunden aktualisieren wir unsere bevorzugte Architektur und besprechen, welche Änderungen unseren Kunden bekannt sein sollen. Exchange Server 2013 hat uns die erste der bevorzugten Architekturen im Modern Exchange-Verlauf gebracht und wurde dann mit einer Aktualisierung für Exchange Server 2016 gefolgt, indem Erfeindungen für die Änderungen bereitgestellt wurde, die mit der Version 2016 eingeführt wurden. Mit diesem Update für Exchange Server 2019 werden wir die vorherige PA durchlaufen, um die Vorteile neuer Technologien und Verbesserungen zu nutzen.

Die bevorzugte Architektur

Die Pa ist die empfehlung für bewährte Methoden des Exchange Server Engineering-Teams für die unserer Meinung nach beste Bereitstellungsarchitektur für Exchange Server 2019 in einer lokalen Umgebung.

Während Exchange 2019 eine Vielzahl von Architekturoptionen für lokale Bereitstellungen bietet, ist die hier erläuterte Architektur die am meisten überprüfte. Obwohl es andere unterstützte Bereitstellungsarchitekturen gibt, sind sie nicht unsere empfohlene Vorgehensweise.

Das Folgen der Pa hilft Kunden, Mitglied einer Community von Organisationen mit ähnlichen Exchange Server Bereitstellungen zu werden. Diese Strategie ermöglicht eine einfachere Wissensfreigabe und bietet eine schnellere Reaktion auf unvorhergesehene Umstände. Unsere eigene Supportorganisation ist sich bewusst, wie eine Exchange Server PA-Bereitstellung aussehen sollte, und verhindert, dass sie längere Zyklen damit verbringen, die benutzerdefinierte Umgebung eines Kunden zu erlernen und zu verstehen, bevor sie mit ihnen an einer Lösung für Supportfälle arbeitet.

Die Pa wurde unter Berücksichtigung verschiedener geschäftlicher Anforderungen entwickelt, z. B. der Anforderung, dass die Architektur in der Lage sein muss:

  • Hohe Verfügbarkeit innerhalb des Rechenzentrums und Ausfallsicherheit zwischen Rechenzentren

  • Unterstützen mehrerer Kopien jeder Datenbank, wodurch eine schnelle Aktivierung ermöglicht wird

  • Senken der Kosten der Messaginginfrastruktur

  • Erhöhen Sie die Verfügbarkeit, indem Sie Fehlerdomänen optimieren und die Komplexität verringern.

Die spezifische Beschreibung der PA bedeutet, dass nicht jeder Kunde es Wort für Wort bereitstellen kann. Beispielsweise verfügen nicht alle unsere Kunden über mehrere Rechenzentren. Einige unserer Kunden haben möglicherweise unterschiedliche geschäftliche Anforderungen oder interne Richtlinien, die sie einhalten müssen, was eine andere Bereitstellungsarchitektur erforderlich macht. Wenn Sie in diese Kategorien fallen und sie Exchange lokal bereitstellen möchten, gibt es weiterhin Vorteile, sich so eng wie möglich an die Pa zu halten und nur dann abzuweichen, wenn Ihre Anforderungen oder Richtlinien Sie dazu zwingen, sich zu unterscheiden. Alternativ können Sie immer Microsoft 365 oder Office 365 in Betracht ziehen, bei denen Sie keine große Anzahl von Servern mehr bereitstellen oder verwalten müssen.

Die Pa entfernt komplexität und Redundanz, wenn dies erforderlich ist, um die Architektur auf ein vorhersagbares Wiederherstellungsmodell zu übertragen: Wenn ein Fehler auftritt, wird eine weitere Kopie der betroffenen Datenbank aktiviert.

Die Pa deckt die folgenden vier Bereiche ab:

  1. Namespacedesign

  2. Entwurf eines standortsicheren Rechenzentrumspaars

  3. Serverdesign

  4. Entwurf einer Datenbankverfügbarkeitsgruppe

Für Exchange Server 2019 haben wir keine Änderungen in drei der vier Kategorien aus der Exchange Server 2016 Preferred Architecture. In den Bereichen Namespacedesign, Datacenter-Design und DAG-Design werden keine größeren Änderungen vorgenommen. Wir freuen uns über Kundenbereitstellungen, die die pa 2016-Exchange Server genau befolgt haben, und sehen keine Notwendigkeit, von den Empfehlungen in diesen Bereichen abzuweichen.

Die wichtigsten Änderungen im Exchange Server 2019 PA konzentrieren sich auf den Bereich des Serverdesigns aufgrund einiger neuer und spannender Technologien.

Namespacedesign

In den Artikeln zu den Namespaceplanungs- und Lastenausgleichsprinzipien für Exchange Server 2016 erläuterte Smith IV. die verschiedenen Konfigurationsoptionen, die mit Exchange 2016 verfügbar waren, und diese Konzepte gelten weiterhin für Exchange Server 2019. Für den Namespace können Sie entweder einen gebundenen Namespace bereitstellen (wobei den Benutzern die Verwendung eines bestimmten Rechenzentrums vorzuziehen ist) oder einen ungebundenen Namespace (die Benutzer müssen eine Verbindung mit einem beliebigen Rechenzentrum ohne Präferenz herstellen).

Der empfohlene Ansatz besteht darin, das ungebundene Modell zu verwenden, indem ein einzelner Exchange Namespace pro Clientprotokoll für das standortresiliente Rechenzentrumspaar bereitgestellt wird (wobei von jedem Rechenzentrum angenommen wird, dass es seinen eigenen Active Directory-Standort darstellt . Weitere Details hierzu finden Sie weiter unten). Beispiel:

  • Für den AutoErmittlungsdienst: autodiscover.contoso.com

  • Für HTTP-Clients: mail.contoso.com

  • Für IMAP-Clients: imap.contoso.com

  • Für SMTP-Clients: smtp.contoso.com

Jeder Exchange Namespace wird in einer Konfiguration der Ebene 7, die keine Sitzungsaffinität verwendet, in beiden Rechenzentren lastenausgleicht, was dazu führt, dass 50 Prozent des Datenverkehrs zwischen Rechenzentren proxitiert werden. Der Datenverkehr wird über Roundrobin-DNS, Geo-DNS oder andere ähnliche Lösungen gleichmäßig auf die Rechenzentren im standortresilienten Paar verteilt. Aus unserer Sicht ist die einfachere Lösung die am wenigsten komplexe und einfacher zu verwaltende Lösung, daher empfehlen wir die Verwendung von Roundrobin-DNS.

Eine Vorsicht, die wir für Kunden haben, besteht darin, sicherzustellen, dass Sie einen niedrigen TTL-Wert (Time to Live) für jeden DNS-Eintrag zuweisen, der Ihrer Exchange-Architektur zugeordnet ist. Wenn bei Verwendung von Roundrobin-DNS ein vollständiger Rechenzentrumsausfall auftritt, müssen Sie die Möglichkeit haben, Ihre DNS-Einträge schnell zu aktualisieren. Sie müssen die IP-Adressen aus dem Offline-Rechenzentrum entfernen, damit sie für DNS-Abfragen nicht zurückgegeben werden. Wenn Ihre DNS-Einträge beispielsweise einen längeren TTL-Wert von 24 Stunden haben, kann es bis zu einem Tag dauern, bis downstreame DNS-Caches ordnungsgemäß aktualisiert wurden. Wenn Sie diesen Schritt nicht ausführen, stellen Sie möglicherweise fest, dass einige Clients nicht ordnungsgemäß zu den weiterhin verfügbaren IP-Adressen in Ihrem verbleibenden Rechenzentrum wechseln können. Vergessen Sie nicht, die IP-Adressen wieder zu Ihren DNS-Einträgen hinzuzufügen, wenn Ihr zuvor offline-Rechenzentrum wiederhergestellt und wieder zum Hosten von Diensten bereit ist.

Die Rechenzentrumsaffinität ist für die Office Online Server Farmen erforderlich, daher wird pro Rechenzentrum ein Namespace mit dem Lastenausgleich unter Verwendung von Layer 7 bereitgestellt und die Sitzungsaffinität über cookiebasierte Persistenz beibehalten.

Beispiel für Exchange 2019 Org Architecture Layout.

Wenn Sie mehrere standortsichere Rechenzentrumspaare in Ihrer Umgebung haben, müssen Sie entscheiden, ob Sie einen einzigen weltweiten Namespace haben möchten oder ob Sie den Datenverkehr zu jedem bestimmten Rechenzentrum mithilfe von regionalen Namespaces steuern möchten. Ihre Entscheidung hängt von Ihrer Netzwerktopologie und den damit verbundenen Kosten für die Verwendung eines ungebundenen Modells ab. Wenn Sie beispielsweise Rechenzentren in Nordamerika und Südafrika haben, ist die Netzwerkverbindung zwischen diesen Regionen möglicherweise nicht nur kostspielig, sondern kann auch eine hohe Latenz aufweisen, was zu Problemen und betriebsbereiten Problemen führen kann. In diesem Fall ist es sinnvoll, ein gebundenes Modell mit einem separaten Namespace für jede Region bereitzustellen. Optionen wie geografisches DNS bieten Ihnen jedoch die Möglichkeit, einen einzelnen einheitlichen Namespace bereitzustellen, auch wenn Sie kostspielige Netzwerkverbindungen haben. Geo-DNS ermöglicht es Ihnen, Ihre Benutzer basierend auf der IP-Adresse ihres Clients zum nächstgelegenen Rechenzentrum zu leiten.

Entwurf eines standortsicheren Rechenzentrumspaars

Um eine hoch verfügbare und standortresiliente Architektur zu erzielen, benötigen Sie zwei oder mehr Rechenzentren, die gut verbunden sind (im Idealfall möchten Sie eine niedrige Roundtrip-Netzwerklatenz, andernfalls werden die Replikation und die Clientumgebung beeinträchtigt). Darüber hinaus sollten die Rechenzentren über redundante Netzwerkpfade verbunden werden, die von verschiedenen Betriebsnetzbetreibern bereitgestellt werden.

Während wir das Stretching eines Active Directory-Standorts über mehrere Rechenzentren hinweg unterstützen, empfehlen wir für die Pa, dass jedes Rechenzentrum ein eigener Active Directory-Standort sein sollte. Es gibt zwei Gründe:

  1. Die Ausfallsicherheit von Transportstandorten über Schattenredundanz in Exchange Server und Safety Net in Exchange Server kann nur erreicht werden, wenn die DAG Mitglieder an mehreren Active Directory-Standorten hat.

  2. Active Directory hat Richtlinien veröffentlicht , die angeben, dass Subnetze an verschiedenen Active Directory-Standorten platziert werden sollen, wenn die Roundtriplatenz zwischen den Subnetzen größer als 10 ms ist.

Serverdesign

In der Pa sind alle Server physische Server und verwenden lokal angefügten Speicher. Physische Hardware wird aus zwei Gründen anstelle von virtualisierter Hardware bereitgestellt:

  1. Die Server werden so skaliert, dass sie im Modus mit den meisten Fehlern 80 % der Ressourcen verwenden.

  2. Die Virtualisierung bietet eine leichte Leistungseinbuße und fügt eine zusätzliche Verwaltungs- und Komplexitätsebene hinzu, wodurch zusätzliche Wiederherstellungsmodi eingeführt werden, die keinen Mehrwert bieten, insbesondere, da Exchange Server systemintern die gleiche Funktionalität bereitstellt.

Commodity-Server

Commodity-Serverplattformen werden in der Pa verwendet. Aktuelle Warenplattformen sind und umfassen:

  • 2U, duale Socketserver mit bis zu 48 physischen Prozessorkernen (eine Steigerung von 24 Kernen in Exchange 2016)

  • Bis zu 256 GB Arbeitsspeicher (eine Erhöhung von 192 GB in Exchange 2016)

  • Ein akkugesicherter Schreibcachecontroller

  • 12 oder mehr Laufwerke innerhalb des Server-Chassis

  • Die Möglichkeit, herkömmliche sich drehende Speicher (HDD) und Solid-State Storage (SSD) innerhalb desselben Chassis zu kombinieren.

Skalierungsthematik

Es ist wichtig zu beachten, dass die Empfehlung der Exchange Server PG, die PG nicht nach oben zu skalieren, sondern die zulässige Prozessor- und Arbeitsspeicherkapazität in Exchange Server 2019 erhöht hat. Eine Skalierung im Vergleich zu höher bedeutet, dass Sie viel lieber eine größere Anzahl von Servern mit etwas weniger Ressourcen pro Server bereitstellen als eine kleinere Anzahl von dichten Servern, die maximale Ressourcen verwenden und mit einer großen Anzahl von Postfächern aufgefüllt werden. Durch die Suche einer angemessenen Anzahl von Postfächern innerhalb eines Servers verringern Sie die Auswirkungen eines geplanten oder ungeplanten Ausfalls und verringern das Risiko, dass andere Systemengpässe erkannt werden.

Eine Erhöhung der Systemressourcen sollte nicht dazu führen, dass lineare Leistungssteigerungen in Exchange Server 2019 unter Verwendung der maximal zulässigen Ressourcen beim Vergleich mit den maximal zulässigen Ressourcen von Exchange 2016 zu beobachten sind. Jede neue Version von Exchange bietet neue Prozesse und Updates, die es wiederum schwierig machen, eine aktuelle Version mit der früheren Version zu vergleichen. Befolgen Sie alle Richtlinien von Microsoft zur Größenanpassung, wenn Sie Ihr Serverdesign bestimmen.

Storage

Abhängig von der Anzahl der Postfächer, der Postfachgröße und der Skalierbarkeit der Serverressourcen können zusätzliche Laufwerke direkt pro Server angefügt werden.

Jeder Server enthält ein einzelnes RAID1-Datenträgerpaar für das Betriebssystem, Exchange Binärdateien, Protokoll-/Clientprotokolle und die Transportdatenbank.

Der verbleibende Speicher ist als JBOD konfiguriert (nur eine Gruppe von Datenträgern). Beachten Sie, dass für einige Hardwarespeichercontroller jeder Datenträger als RAID0-Gruppe mit einem Datenträger konfiguriert sein muss, damit die Zwischenspeicherung für Schreibzugriff verwendet werden kann. Wenden Sie sich an Ihren Hardwarehersteller, um die richtige Konfiguration für Ihr System zu bestätigen, die die Verwendung von Schreibcache garantiert.

Neu bei Exchange Server 2019 PA ist die Empfehlung, zwei Speicherklassen für alles zu verwenden, was sich noch nicht auf dem zuvor erwähnten RAID1-Datenträgerpaar befindet.

Herkömmliche Speicherklasse

Diese Speicherklasse enthält Exchange Server Datenbankdateien und Exchange Server Transaktionsprotokolldateien. Bei diesen Datenträgern handelt es sich um seriell angeschlossene SCSI-Datenträger (SAS)-Datenträger mit einer Kapazität von 7,2 K U/min. SATA-Datenträger sind zwar auch verfügbar, aber wir beobachten eine bessere E/A und eine niedrigere annualisierte Fehlerrate mithilfe der SAS-Entsprechung.

Um sicherzustellen, dass die Kapazität und E/A jedes Datenträgers so effizient wie möglich verwendet wird, werden bis zu vier Datenbankkopien pro Datenträger bereitgestellt. Das normale Laufzeitkopielayout stellt sicher, dass pro Datenträger nicht mehr als eine einzige aktive Datenbankkopie vorhanden ist.

Mindestens ein Datenträger im herkömmlichen Speicherdatenträgerpool ist als Hot-Reserve reserviert. AutoReseed ist aktiviert und stellt die Datenbankredundanz nach einem Datenträgerfehler schnell wieder her, indem das Hot-Reserve aktiviert und datenbankkopienreaktivierte Dateien initiiert werden.

Solid-State-Speicherklasse

Diese Speicherklasse enthält die neuen MetaCache-Datenbankdateien (MCDB) Exchange 2019. Diese Solid-State-Laufwerke können verschiedene Formfaktoren aufweisen, z. B. herkömmliche, mit SAS verbundene 2,5-/3,5-Zoll- oder M.2-PCIe-Laufwerke.

Kunden sollten davon ausgehen, dass sie ungefähr 5 bis 10 % zusätzlichen Speicher als Solid-State-Speicher bereitstellen. Wenn z. B. erwartet wird, dass ein einzelner Server 28 TB Postfachdatenbankdateien auf herkömmlichem Speicher enthält, wird ein zusätzlicher Speicher mit 1,4-2,8 TB Solid-State-Speicher ebenfalls als zusätzlicher Speicher für denselben Server empfohlen.

Herkömmliche Datenträger und Solid-State-Datenträger sollten nach Möglichkeit in einem Verhältnis von 3:1 bereitgestellt werden. Für alle drei herkömmlichen Datenträger innerhalb des Servers wird ein einzelner Solid-State-Datenträger bereitgestellt. Diese Solid-State-Datenträger enthalten die MCDBs für alle DBs innerhalb der drei zugeordneten herkömmlichen Datenträger. Diese Empfehlung schränkt die Fehlerdomäne ein, die ein Solid-State-Laufwerkfehler für ein System verursachen kann. Wenn eine SSD fehlschlägt, übergibt Exchange 2019 alle Datenbankkopien, die diese SSD für ihre MCDB verwenden, auf einen anderen DAG-Knoten mit fehlerfreien MCDB-Ressourcen für die betroffene Datenbank. Wenn Sie die Anzahl der Datenbankfailovers begrenzen, verringern Sie die Wahrscheinlichkeit, dass sich dies auf Benutzer auswirkt, wenn viele weitere Datenbanken eine kleinere Anzahl von Solid-State-Laufwerken verwenden.

Wenn ein Solid-State-Laufwerkfehler Exchange Hochverfügbarkeitsdienst auftritt, wird versucht, die betroffenen Datenbanken auf verschiedenen DAG-Knoten bereitzustellen, wo weiterhin eine fehlerfreie MCDB für jede betroffene Datenbank vorhanden ist. Wenn aus irgendeinem Grund keine fehlerfreien MCDBs für eine der betroffenen Datenbanken vorhanden sind, lassen Exchange Hochverfügbarkeitsdienste die lokal betroffene Datenbankkopie ohne die Leistungsvorteile der MCDB ausgeführt.

Wenn ein Kunde beispielsweise ein System bereitstellen würde, das 20 Laufwerke enthalten kann, kann es ein Layout wie das folgende aufweisen.

  • 2 HDDs für BS-Spiegelung, Exchange Binärdateien und Transportdatenbank

  • 12 HDDs für Exchange Datenbankspeicher

  • 1 HDD als AutoReseed-Ersatz

  • 4 SSDs für Exchange MCDBs, die zwischen 5 und 10 % der kumulativen Datenbankspeicherkapazität bereitstellen.

  • Optional kann ein Kunde entscheiden, eine Ersatz-SSD oder ein zweites AutoReseed-Laufwerk hinzuzufügen.

Diese Konfiguration kann mithilfe des folgenden Diagramms visualisiert werden:

Beispiel für Exchange 2019 Postfachserver-Datenträgerlayout.

Im obigen Beispiel verfügen wir über 120 TB Exchange Datenbankspeichers und 7,68 TB MCDB-Speicher, der ungefähr 6,4 % des herkömmlichen Datenbankspeicherplatzes entspricht. Bei dieser Menge an MCBD-Speicher werden wir perfekt an die Richtlinien von 5 bis 10 % angepasst. Jedes der 10-TB-Laufwerke enthält vier Datenbankkopien, und jedes MCDB-Laufwerk enthält 12 MCDBs.

Allgemeine Speichereinstellungen

Unabhängig davon, ob es sich um einen herkömmlichen oder einen soliden Zustand handelt, werden alle Datenträger, auf denen eine Exchange Daten gespeichert ist, mit ReFS formatiert (mit deaktiviertem Integritätsfeature), und die DAG ist so konfiguriert, dass AutoReseed die Datenträger mit ReFS formatiert:

Set-DatabaseAvailabilityGroup -Identity <DAGIdentity> -FileSystem ReFS

BitLocker wird verwendet, um jeden Datenträger zu verschlüsseln, wodurch ruhende Datenverschlüsselung bereitgestellt und Bedenken im Zusammenhang mit Datendiebstahl oder Datenträgerersetzung entschärft werden. Weitere Informationen finden Sie unter Aktivieren von BitLocker auf Exchange Servern.

Entwurf einer Datenbankverfügbarkeitsgruppe

Innerhalb jedes standortresilienten Rechenzentrumspaars verfügen Sie über eine oder mehrere DAGs. Es wird nicht empfohlen, eine DAG über mehr als zwei Rechenzentren zu dehnen.

DAG-Konfiguration

Wie beim Namespacemodell wird jede DAG innerhalb des standortresilienten Rechenzentrumspaars in einem ungebundenen Modell ausgeführt, wobei aktive Kopien gleichmäßig auf alle Server in der DAG verteilt sind. Dieses Modell:

  1. Stellt sicher, dass der vollständige Stapel der Dienste jedes DAG-Mitglieds (Clientkonnektivität, Replikationspipeline, Transport usw.) während des normalen Betriebs überprüft wird.

  2. Verteilt die Last während eines Fehlerszenarios auf so viele Server wie möglich, wodurch die Ressourcennutzung nur inkrementell auf die verbleibenden Mitglieder innerhalb der DAG erhöht wird.

Jedes Rechenzentrum ist symmetrisch, mit einer gleichen Anzahl von DAG-Mitgliedern in jedem Rechenzentrum. Dies bedeutet, dass jede DAG über eine gerade Anzahl von Servern verfügt und einen Zeugenserver für die Quorumwartung verwendet.

Die DAG ist der grundlegende Baustein in Exchange 2019. Im Hinblick auf die DAG-Größe bietet eine DAG mit einer größeren Anzahl von beteiligten Mitgliedsknoten mehr Redundanz und Ressourcen. Innerhalb der Pa besteht das Ziel darin, DAGs mit einer größeren Anzahl von Mitgliedsknoten bereitzustellen, die in der Regel mit einer DAG mit acht Membern beginnen und die Anzahl der Server nach Bedarf erhöhen, um Ihre Anforderungen zu erfüllen. Sie sollten neue DAGs nur erstellen, wenn Skalierbarkeit Bedenken hinsichtlich des vorhandenen Datenbankkopielayouts mit sich bringt.

DAG-Netzwerkdesign

Die Pa verwendet eine einzelne, nicht-teamierte Netzwerkschnittstelle für clientkonnektivität und Datenreplikation. Eine einzige Netzwerkschnittstelle ist nur erforderlich, da unser Ziel letztlich darin besteht, unabhängig vom Fehler ein Standardwiederherstellungsmodell zu erreichen – unabhängig davon, ob ein Serverfehler auftritt oder ein Netzwerkfehler auftritt, ist das Ergebnis dasselbe: Eine Datenbankkopie wird auf einem anderen Server innerhalb der DAG aktiviert. Diese Architekturänderung vereinfacht den Netzwerkstapel und macht es überflüssig, taktübergreifendes Heartbeat manuell zu vermeiden.

Platzierung des Zeugenservers

Die Platzierung des Zeugenservers bestimmt, ob die Architektur automatische Rechenzentrumsfailoverfunktionen bereitstellen kann oder ob eine manuelle Aktivierung erforderlich ist, um den Dienst zu aktivieren, wenn ein Standortfehler auftritt.

Wenn Ihre Organisation über einen dritten Standort mit einer Netzwerkinfrastruktur verfügt, die von Netzwerkfehlern isoliert ist, die sich auf das standortresiliente Rechenzentrumspaar auswirken, an dem die DAG bereitgestellt wird, wird empfohlen, den Zeugenserver der DAG an diesem dritten Standort bereitzustellen. Diese Konfiguration bietet der DAG die Möglichkeit, als Reaktion auf ein Fehlerereignis auf Rechenzentrumsebene automatisch einen Failover von Datenbanken an das andere Rechenzentrum durchzuführen, unabhängig davon, welches Rechenzentrum den Ausfall hat.

Wenn Ihre Organisation keinen dritten Standort hat, sollten Sie den Serverzeugen in Azure platzieren. Alternativ können Sie den Zeugenserver in einem der Rechenzentren innerhalb des standortresilienten Rechenzentrumspaars platzieren. Wenn Sie mehrere DAGs innerhalb des standortresilienten Rechenzentrumspaars haben, platzieren Sie den Zeugenserver für alle DAGs im selben Rechenzentrum (in der Regel das Rechenzentrum, in dem sich die meisten Benutzer physisch befinden). Stellen Sie außerdem sicher, dass sich der primary Active Manager (PAM) für jede DAG auch im selben Rechenzentrum befindet.

Exchange Server 2019 und alle früheren Versionen unterstützen nicht die Verwendung des Cloudzeugenfeatures, das erstmals in Windows Server 2016 Failovercluster eingeführt wurde.

Datenresilienz

Die Datenresilienz wird durch die Bereitstellung mehrerer Datenbankkopien erreicht. In der Pa werden Datenbankkopien über das ausfallsichere Rechenzentrumspaar verteilt, wodurch sichergestellt wird, dass Postfachdaten vor Software-, Hardware- und sogar Rechenzentrumsfehlern geschützt sind.

Jede Datenbank verfügt über vier Kopien mit zwei Kopien in jedem Rechenzentrum, was bedeutet, dass die PA mindestens vier Server erfordert. Von diesen vier Kopien sind drei als hoch verfügbar konfiguriert. Die vierte Kopie (die Kopie mit der höchsten Aktivierungseinstellungsnummer) wird als verzögerte Datenbankkopie konfiguriert. Aufgrund des Serverdesigns ist jede Kopie einer Datenbank von ihren anderen Kopien isoliert, wodurch Fehlerdomänen reduziert und die allgemeine Verfügbarkeit der Lösung wie in DAG: Beyond the "A" beschrieben erhöht wird.

Der Zweck der verzögerten Datenbankkopie besteht darin, einen Wiederherstellungsmechanismus für das selten auftretende systemweite, schwerwiegende logische Beschädigungsereignis bereitzustellen. Es ist nicht für die Wiederherstellung einzelner Postfächer oder postfachelementwiederherstellung vorgesehen.

Die verzögerte Datenbankkopie wird mit einer siebentägigen ReplayLagTime konfiguriert. Darüber hinaus ist der Replay Lag Manager auch aktiviert, um dynamische Protokolldatei-Playdowns für verzögerte Kopien bereitzustellen, wenn die Verfügbarkeit aufgrund des Verlusts nicht verzögerter Kopien kompromittiert wird.

Wenn Sie die verzögerte Datenbankkopie auf diese Weise verwenden, ist es wichtig zu wissen, dass die verzögerte Datenbankkopie keine garantierte Point-in-Time-Sicherung ist. Die verzögerte Datenbankkopie hat einen Verfügbarkeitsschwellenwert, in der Regel ca. 90 %, aufgrund von Zeiträumen, in denen der Datenträger mit einer verzögerten Kopie aufgrund eines Datenträgerfehlers verloren geht, die verzögerte Kopie zu einer HA-Kopie wird (aufgrund der automatischen Wiedergabe) und die Zeiträume, in denen die verzögerte Datenbankkopie die Wiedergabewarteschlange neu erstellt.

Zum Schutz vor versehentlichem (oder böswilligem) Löschen von Elementen werden Technologien zum Wiederherstellen einzelner Elemente oder zum In-Situ-Archiv verwendet, und das Aufbewahrungsfenster für gelöschte Elemente wird auf einen Wert festgelegt, der alle definierten Wiederherstellungs-SLA auf Elementebene erfüllt oder überschreitet.

Bei all diesen Technologien sind herkömmliche Sicherungen nicht erforderlich. daher verwendet die Pa Exchange nativen Datenschutz.

Office Online Server-Design

Sie sollten mindestens eine oos-Farm (Office Online Server) mit mindestens zwei OOS-Knoten in jedem Rechenzentrum bereitstellen, das Exchange 2019-Server hostet. Jeder Office Online Server sollte über mindestens 8 Prozessorkerne, 32 GB Arbeitsspeicher und mindestens 40 GB Speicherplatz verfügen, der für Protokolldateien reserviert ist. Exchange 2019-Postfachserver sollten so konfiguriert werden, dass sie sich auf die lokale OOS-Farm in ihrem Rechenzentrum verlassen, um die geringstmögliche Latenz und die größtmögliche Bandbreite zwischen den Servern sicherzustellen, um Dateiinhalte für Benutzer zu rendern.

Zusammenfassung

Exchange Server 2019 verbessert die Investitionen in früheren Versionen von Exchange und führt zusätzliche Technologien ein, die ursprünglich für die Verwendung in Microsoft 365 und Office 365 vorgesehen waren.

Durch die Ausrichtung an der bevorzugten Architektur nutzen Sie diese Änderungen und bieten die bestmögliche lokale Benutzererfahrung. Sie werden weiterhin eine äußerst zuverlässige, vorhersagbare und ausfallsichere Exchange Bereitstellung haben.