Exchange 2019 – Bevorzugte Architektur
Mit jedem neuen Release von Exchange Server für unsere lokalen Kunden aktualisieren wir unsere bevorzugte Architektur und besprechen, welche Änderungen unsere Kunden beachten sollen. Exchange Server 2013 brachte uns die erste der bevorzugten Architekturen in der modernen Exchange-Geschichte und wurde dann mit einer Aktualisierung für Exchange Server 2016 gefolgt, indem verbesserungen für die Änderungen bereitgestellt wurden, die im Release 2016 enthalten waren. Mit diesem Update für Exchange Server 2019 durchlaufen wir die vorherige PA, um neue Technologien und Verbesserungen zu nutzen.
Die bevorzugte Architektur
Die PA ist die Best Practice-Empfehlung 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 untersuchte Architektur. Es gibt zwar andere unterstützte Bereitstellungsarchitekturen, aber sie sind nicht unsere empfohlene Vorgehensweise.
Die Einhaltung der PA hilft Kunden dabei, Mitglied einer Community von Organisationen mit ähnlichen Exchange Server Bereitstellungen zu werden. Diese Strategie ermöglicht einen einfacheren Wissensaustausch 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 lange Zyklen damit verbringt, die hochgradig benutzerdefinierte Umgebung eines Kunden zu lernen und zu verstehen, bevor sie mit ihnen an einer Supportfalllösung arbeitet.
Die PA ist unter Berücksichtigung mehrerer Geschäftsanforderungen konzipiert, z. B. der Anforderung, dass die Architektur in der Lage sein muss:
Sowohl Hochverfügbarkeit innerhalb des Rechenzentrums als auch Standortresilienz zwischen Rechenzentren einbeziehen
Unterstützung mehrerer Kopien jeder Datenbank, wodurch eine schnelle Aktivierung möglich ist
Reduzieren der Kosten für die Messaginginfrastruktur
Erhöhen der Verfügbarkeit durch Optimieren von Fehlerdomänen und Verringern der Komplexität
Der spezifische präskriptive Charakter der PA bedeutet, dass nicht jeder Kunde sie Wort für Wort bereitstellen kann. Beispielsweise verfügen nicht alle unsere Kunden über mehrere Rechenzentren. Einige unserer Kunden haben möglicherweise unterschiedliche Geschäftsanforderungen oder interne Richtlinien, die sie einhalten müssen, was eine andere Bereitstellungsarchitektur erfordert. Wenn Sie in diese Kategorien fallen und Exchange lokal bereitstellen möchten, hat es immer noch 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 eine große Anzahl von Servern nicht mehr bereitstellen oder verwalten müssen.
Die PA beseitigt komplexitäts- und redundanz, wenn dies erforderlich ist, um die Architektur auf ein vorhersagbares Wiederherstellungsmodell zu lenken: Wenn ein Fehler auftritt, wird eine andere Kopie der betroffenen Datenbank aktiviert.
Die PA deckt die folgenden vier Schwerpunktbereiche ab:
Für Exchange Server 2019 gibt es keine Änderungen in drei der vier Kategorien der Exchange Server 2016 Preferred Architecture. Die Bereiche Namespaceentwurf, Rechenzentrumsentwurf und DAG-Entwurf werden nicht wesentlich geändert. Wir freuen uns über Kundenbereitstellungen, die die Exchange Server 2016 PA genau befolgt haben, und sehen keine Notwendigkeit, von den Empfehlungen in diesen Bereichen abzuweichen.
Die bemerkenswertesten Änderungen in der Exchange Server 2019 PA konzentrieren sich auf den Bereich des Serverdesigns aufgrund einiger neuer und spannender Technologien.
Namespaceentwurf
In den Artikeln namespace planning and load balancing principles for Exchange Server 2016 beschreibt Ross 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 besteht die Auswahl entweder in der Bereitstellung eines gebundenen Namespaces (wobei die Benutzer die Möglichkeit haben, aus einem bestimmten Rechenzentrum heraus zu arbeiten) oder einen ungebundenen Namespace (wobei die Benutzer ohne Präferenz eine Verbindung mit einem beliebigen Rechenzentrum herstellen).
Der empfohlene Ansatz besteht darin, das ungebundene Modell zu verwenden und einen einzelnen Exchange-Namespace pro Clientprotokoll für das standortresiliente Rechenzentrumspaar bereitzustellen (wobei davon ausgegangen wird, dass jedes Rechenzentrum seinen eigenen Active Directory-Standort darstellt ( weitere Details dazu finden Sie 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 beiden Rechenzentren in einer Layer-7-Konfiguration, die keine Sitzungsaffinität verwendet, lastenausgleichen, was dazu führt, dass 50 Prozent des Datenverkehrs zwischen Rechenzentren per Proxy übertragen werden. Der Datenverkehr wird über Roundrobin-DNS, Geo-DNS oder ä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 verwalten, daher empfehlen wir die Verwendung von Roundrobin-DNS.
Eine Vorsicht für Kunden besteht darin, sicherzustellen, dass Sie jedem DNS-Eintrag, der Ihrer Exchange-Architektur zugeordnet ist, einen niedrigen TTL-Wert (Time to Live) zuweisen. Wenn ein vollständiger Rechenzentrumsausfall auftritt, wenn Sie Roundrobin-DNS verwenden, müssen Sie die Möglichkeit haben, Ihre DNS-Einträge schnell zu aktualisieren. Sie müssen die IP-Adressen aus dem Offlinerechenzentrum entfernen, damit sie nicht für DNS-Abfragen zurückgegeben werden. Wenn Ihre DNS-Einträge beispielsweise einen längeren TTL-Wert von 24 Stunden aufweisen, kann es bis zu einem Tag dauern, bis downstream-DNS-Caches ordnungsgemäß aktualisiert werden. Wenn Sie diesen Schritt nicht ausführen, stellen Sie möglicherweise fest, dass einige Clients nicht ordnungsgemäß zu den noch 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 geschaltetes Rechenzentrum wiederhergestellt und bereit ist, Dienste erneut zu hosten.
Rechenzentrumsaffinität ist für die Office Online Server Farmen erforderlich. Daher wird ein Namespace pro Rechenzentrum bereitgestellt, wobei der Lastenausgleich die Schicht 7 nutzt und die Sitzungsaffinität über cookiebasierte Persistenz aufrechterhalten wird.
Wenn Sie mehrere standortresiliente Rechenzentrumspaare in Ihrer Umgebung haben, müssen Sie entscheiden, ob Sie einen einzelnen weltweiten Namespace verwenden möchten oder ob Sie den Datenverkehr zu jedem bestimmten Rechenzentrum mithilfe regionaler 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 z. B. Rechenzentren in Nordamerika und Südafrika haben, kann die Netzwerkverbindung zwischen diesen Regionen nicht nur kostspielig sein, sondern auch eine hohe Latenz aufweisen, was zu Problemen und Betriebsproblemen für den Benutzer 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 über kostspielige Netzwerkverbindungen verfügen. Geo-DNS ermöglicht es Ihnen, Ihre Benutzer basierend auf der IP-Adresse ihres Clients an das nächstgelegene Rechenzentrum zu lenken.
Entwurf eines standortresilienten Rechenzentrumspaars
Um eine hochverfügbare und standortresiliente Architektur zu erreichen, müssen Sie über zwei oder mehr Rechenzentren verfügen, die gut verbunden sind (idealerweise möchten Sie eine niedrige Roundtrip-Netzwerklatenz, da sonst die Replikation und die Clienterfahrung beeinträchtigt werden). Darüber hinaus sollten die Rechenzentren über redundante Netzwerkpfade verbunden werden, die von verschiedenen Betreibern bereitgestellt werden.
Obwohl wir die Erweiterung eines Active Directory-Standorts über mehrere Rechenzentren hinweg unterstützen, empfehlen wir für die PA, dass jedes Rechenzentrum ein eigener Active Directory-Standort ist. Es gibt zwei Gründe:
Resilienz des Transportstandorts ü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.
Active Directory hat einen Leitfaden veröffentlicht , der besagt, dass Subnetze an verschiedenen Active Directory-Standorten platziert werden sollten, wenn die Roundtriplatenz zwischen den Subnetzen größer als 10 ms ist.
Serverentwurf
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:
Die Server werden so skaliert, dass 80 % der Ressourcen während des Modus mit den schlimmsten Fehlern verwendet werden.
Die Virtualisierung bringt eine leichte Leistungseinbuße mit sich und führt zu einer zusätzlichen Verwaltungs- und Komplexitätsebene, wodurch zusätzliche Wiederherstellungsmodi eingeführt werden, die keinen Mehrwert bieten, insbesondere da Exchange Server nativ die gleiche Funktionalität bietet.
Standardserver
Standardserverplattformen werden in der PA verwendet. Aktuelle Standardplattformen sind und umfassen:
2U, Dual-Socket-Server mit bis zu 48 physischen Prozessorkernen (eine Steigerung gegenüber 24 Kernen in Exchange 2016)
Bis zu 256 GB Arbeitsspeicher (gegenüber 192 GB in Exchange 2016)
Ein batteriegestützter Schreibcachecontroller
12 oder mehr Laufwerksplätze innerhalb des Servergehäuses
Die Möglichkeit, herkömmlichen rotierenden Plattenspeicher (HDD) und Solid State Storage (SSD) innerhalb desselben Gehäuses zu kombinieren.
Skalierungstheorie
Es ist wichtig zu beachten, auch wenn wir die zulässige Prozessor- und Speicherkapazität in Exchange Server 2019 erhöht haben, empfiehlt es sich weiterhin, die Exchange Server PG auf- statt hochzuskalieren. Horizontales Hochskalieren bedeutet, dass Wir viel lieber eine größere Anzahl von Servern mit etwas weniger Ressourcen pro Server bereitstellen als eine kleinere Anzahl von Servern mit hoher Dichte, die maximale Ressourcen verwenden und mit einer großen Anzahl von Postfächern aufgefüllt werden. Indem Sie eine angemessene Anzahl von Postfächern innerhalb eines Servers suchen, verringern Sie die Auswirkungen eines geplanten oder ungeplanten Ausfalls und verringern das Risiko, dass andere Systemengpässe entdeckt werden.
Eine Erhöhung der Systemressourcen sollte nicht zu der Annahme führen, dass sie in Exchange Server 2019 lineare Leistungssteigerungen bei Verwendung der maximal zulässigen Ressourcen feststellen, wenn sie mit den maximal zulässigen Ressourcen von Exchange 2016 verglichen werden. Jede neue Version von Exchange bietet neue Prozesse und Updates, die es wiederum schwierig machen, eine aktuelle Version mit einer früheren Version zu vergleichen. Befolgen Sie alle Anweisungen zur Größenanpassung von Microsoft, wenn Sie ihren Serverentwurf bestimmen.
Speicher
Abhängig von der Anzahl der Postfächer, der Postfachgröße und der Ressourcenskalierbarkeit des Servers können zusätzliche Laufwerksplätze pro Server direkt 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 wird als JBOD (Nur eine Reihe von Datenträgern) konfiguriert. Beachten Sie, dass für einige Hardwarespeichercontroller jeder Datenträger als RAID0-Gruppe mit einem einzelnen Datenträger konfiguriert werden muss, damit die Schreibzwischenspeicherung verwendet werden kann. Wenden Sie sich an Ihren Hardwarehersteller, um die richtige Konfiguration für Ihr System zu bestätigen, die die Verwendung des Schreibcaches garantiert.
Neu in der Exchange Server 2019 PA ist die Empfehlung, zwei Speicherklassen für alles zu verwenden, was sich nicht bereits 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 angefügte SCSI-Datenträger (SAS) mit großer Kapazität von 7,2 K RPM. Sata-Datenträger sind zwar ebenfalls verfügbar, aber wir beobachten eine bessere E/A-Rate und eine niedrigere annualisierte Fehlerrate unter Verwendung des SAS-Äquivalents.
Um sicherzustellen, dass die Kapazität und E/A jedes Datenträgers so effizient wie möglich genutzt werden, werden pro Datenträger bis zu vier Datenbankkopien bereitgestellt. Das normale Laufzeit-Kopierlayout stellt sicher, dass pro Datenträger nicht mehr als eine einzelne aktive Datenbankkopie vorhanden ist.
Mindestens ein Datenträger im herkömmlichen Speicherdatenträgerpool ist als Hot-Spare reserviert. AutoReseed ist aktiviert und stellt die Datenbankredundanz nach einem Datenträgerfehler schnell wieder her, indem der Hot-Spare aktiviert und Datenbankkopien initiiert werden.
Solid-State-Speicherklasse
Diese Speicherklasse enthält die neuen MCDB-Dateien (MetaCache Database) von Exchange 2019. Diese Solid-State-Laufwerke können verschiedene Formfaktoren aufweisen, z. B. herkömmliche 2,5"/3,5"-SAS-Laufwerke oder M.2-PCIe-verbundene Laufwerke.
Kunden sollten damit rechnen, etwa 5 bis 10 % zusätzlichen Speicher als Solid State Storage bereitzustellen. Wenn beispielsweise erwartet wird, dass ein einzelner Server 28 TB Postfachdatenbankdateien im herkömmlichen Speicher enthält, werden zusätzliche 1,4 bis 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 im Verhältnis 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 Datenbanken in den drei zugeordneten herkömmlichen Datenträgern. Diese Empfehlung schränkt die Fehlerdomäne ein, die ein Solid State Drive-Fehler für ein System verursachen kann. Wenn eine SSD ausfällt, führt Exchange 2019 ein Failover aller Datenbankkopien mit dieser SSD für ihre MCDB auf einen anderen DAG-Knoten mit fehlerfreien MCDB-Ressourcen für die betroffene Datenbank durch. Die Begrenzung der Anzahl von Datenbankfailovern verringert die Wahrscheinlichkeit, dass Benutzer beeinträchtigt werden, wenn viele weitere Datenbanken eine kleinere Anzahl von Solid State-Laufwerken gemeinsam nutzen.
Wenn ein Solid State Drive-Fehler auftritt, versucht der Exchange-Hochverfügbarkeitsdienst, die betroffenen Datenbanken auf verschiedenen DAG-Knoten bereitzustellen, auf denen noch 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 lokale betroffene Datenbankkopie ohne die Leistungsvorteile der MCDB laufen.
Wenn ein Kunde beispielsweise ein System bereitstellen würde, das 20 Laufwerke aufnehmen kann, kann es ein Layout wie das folgende haben.
2 HDDs für Betriebssystemspiegelung, 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 eine ERSATZ-SSD oder ein zweites AutoReseed-Laufwerk hinzufügen.
Diese Konfiguration kann mithilfe des folgenden Diagramms visualisiert werden:
Im obigen Beispiel verfügen wir über 120 TB Exchange-Datenbankspeicher und 7,68 TB MCDB-Speicher, was ungefähr 6,4 % des herkömmlichen Datenbankspeicherplatzes entspricht. Mit dieser Menge an MCBD-Speicher sind wir perfekt innerhalb der Vorgaben von 5-10% ausgerichtet. Jedes der 10-TB-Laufwerke enthält vier Datenbankkopien, und jedes MCDB-Laufwerk würde 12 MCDBs enthalten.
Allgemeine Speichereinstellungen
Ob traditionell oder Solid-State: Alle Datenträger, auf denen Exchange-Daten gespeichert sind, werden mit ReFS formatiert (mit deaktivierter Integritätsfunktion), 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 die Datenverschlüsselung ruhender Daten ermöglicht und Bedenken in Bezug auf Datendiebstahl oder Datenträgeraustausch gemildert werden. Weitere Informationen finden Sie unter Aktivieren von BitLocker auf Exchange-Servern.
Datenbankverfügbarkeitsgruppenentwurf
Innerhalb jedes standortresilienten Rechenzentrumspaars verfügen Sie über ein oder mehrere DAGs. Es wird nicht empfohlen, eine DAG über mehr als zwei Rechenzentren zu erstrecken.
DAG-Konfiguration
Wie beim Namespacemodell arbeitet jede DAG innerhalb des standortresilienten Rechenzentrumspaars in einem ungebundenen Modell mit aktiven Kopien, die gleichmäßig auf alle Server in der DAG verteilt sind. Dieses Modell:
Stellt sicher, dass der vollständige Dienststapel jedes DAG-Mitglieds (Clientkonnektivität, Replikationspipeline, Transport usw.) während des normalen Betriebs überprüft wird.
Verteilt die Last während eines Ausfallszenarios auf so viele Server wie möglich, wodurch die Ressourcennutzung nur inkrementell auf die verbleibenden Member 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. In Bezug auf die DAG-Größe bietet eine DAG mit einer größeren Anzahl teilnehmender Memberknoten mehr Redundanz und Ressourcen. Innerhalb der PA besteht das Ziel darin, DAGs mit einer größeren Anzahl von Mitgliedsknoten bereitzustellen. Dies beginnt in der Regel mit einer DAG mit acht Mitgliedern und erhöht die Anzahl der Server nach Bedarf, um Ihre Anforderungen zu erfüllen. Sie sollten neue DAGs nur erstellen, wenn die Skalierbarkeit Bedenken hinsichtlich des vorhandenen Datenbankkopierlayouts einführt.
DAG-Netzwerkentwurf
Die PA verwendet eine einzelne Netzwerkschnittstelle ohne Team für Clientkonnektivität und Datenreplikation. Eine einzelne Netzwerkschnittstelle ist alles, was benötigt wird, denn letztendlich ist unser Ziel, ein Standardwiederherstellungsmodell zu erreichen, unabhängig vom Ausfall . Unabhängig davon, ob ein Serverausfall 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 verhindert die Notwendigkeit, Heartbeat-Cross-Talk manuell zu eliminieren.
Zeugenserverplatzierung
Die Platzierung des Zeugenservers bestimmt, ob die Architektur automatische Rechenzentrumsfailoverfunktionen bereitstellen kann oder ob eine manuelle Aktivierung erforderlich ist, um den Dienst bei einem Standortausfall zu aktivieren.
Wenn Ihre Organisation über einen dritten Standort mit einer Netzwerkinfrastruktur verfügt, die von Netzwerkausfällen isoliert ist, die sich auf das standortresiliente Rechenzentrumspaar auswirken, in 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 ein Failover von Datenbanken auf das andere Rechenzentrum auszuführen, unabhängig davon, welches Rechenzentrum den Ausfall aufweist.
Wenn Ihre Organisation nicht über einen dritten Standort verfügt, sollten Sie den Serverzeugen in Azure platzieren. Alternativ können Sie den Zeugenserver in einem der Rechenzentren innerhalb des Standortresilienz-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 primäre Active Manager (PAM) für jede DAG auch im selben Rechenzentrum befindet.
Exchange Server 2019 und allen früheren Versionen wird die Verwendung des Cloudzeugenfeatures, das erstmals in Windows Server 2016 Failovercluster eingeführt wurde, nicht unterstützt.
Datenresilienz
Die Datenresilienz wird durch die Bereitstellung mehrerer Datenbankkopien erreicht. In der Pa werden Datenbankkopien über das standortresiliente Rechenzentrumspaar verteilt, wodurch sichergestellt wird, dass Postfachdaten vor Software-, Hardware- und sogar Rechenzentrumsausfällen geschützt sind.
Jede Datenbank verfügt über vier Kopien mit zwei Kopien in jedem Rechenzentrum, was bedeutet, dass mindestens vier Server für die PA erforderlich sind. Von diesen vier Kopien sind drei als hochverfü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 Gesamtverfügbarkeit der Lösung erhöht wird, wie in DAG: Beyond the "A" (Dag: Über das "A" hinaus erläutert).
Der Zweck der verzögerten Datenbankkopie besteht darin, einen Wiederherstellungsmechanismus für das seltene Ereignis einer systemweiten schwerwiegenden logischen Beschädigung bereitzustellen. Es ist nicht für die Wiederherstellung einzelner Postfächer oder die Wiederherstellung von Postfachelementen vorgesehen.
Die verzögerte Datenbankkopie wird mit einem siebentägigen ReplayLagTime konfiguriert. Darüber hinaus ist der Wiedergabeverzögerungs-Manager auch aktiviert, um dynamische Protokolldateien für verzögerte Kopien bereitzustellen, wenn die Verfügbarkeit aufgrund des Verlusts von nicht verzögerten Kopien gefährdet ist.
Wenn Sie die verzögerte Datenbankkopie auf diese Weise verwenden, ist es wichtig zu verstehen, dass die verzögerte Datenbankkopie keine garantierte Point-in-Time-Sicherung ist. Die verzögerte Datenbankkopie weist einen Verfügbarkeitsschwellenwert von in der Regel um 90 % auf, da der Datenträger, der eine verzögerte Kopie enthält, aufgrund eines Datenträgerfehlers verloren geht, die verzögerte Kopie zu einer Hochverfügbarkeitskopie 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 zur Wiederherstellung einzelner Elemente oder In-Situ-Aufbewahrung verwendet, und das Fenster Aufbewahrung gelöschter Elemente wird auf einen Wert festgelegt, der eine definierte SLA für die Wiederherstellung auf Elementebene erfüllt oder überschreitet.
Da all diese Technologien im Spiel sind, sind herkömmliche Sicherungen unnötig. Daher verwendet die PA den nativen Schutz von Exchange-Daten.
Office Online Server Design
Sie sollten mindestens eine Office Online Server-Farm (OOS) mit mindestens zwei OOS-Knoten in jedem Rechenzentrum bereitstellen, das Exchange 2019-Server hostet. Jede Office Online Server sollte über mindestens 8 Prozessorkerne, 32 GB Arbeitsspeicher und mindestens 40 GB dedizierten Speicherplatz für Protokolldateien verfügen. 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 höchstmögliche Bandbreite zwischen den Servern sicherzustellen, um Dateiinhalte für Benutzer zu rendern.
Zusammenfassung
Exchange Server 2019 verbessert sich weiter gegenüber den Investitionen, die in früheren Versionen von Exchange eingeführt wurden, und führt zusätzliche Technologien ein, die ursprünglich für die Verwendung in Microsoft 365 und Office 365 entwickelt wurden.
Wenn Sie sich an der bevorzugten Architektur orientieren, profitieren Sie von diesen Änderungen und bieten die bestmögliche lokale Benutzererfahrung. Sie setzen die Tradition einer äußerst zuverlässigen, vorhersagbaren und resilienten Exchange-Bereitstellung fort.