Exchange Online Datenresilienz in Microsoft 365

  • Artikel

Wichtig

Da wir weiterhin auf unterschiedliche Weise investieren, um Postfachinhalte zu erhalten, kündigen wir die Einstellung von In-Place Holds im Exchange Admin Center (EAC) in Exchange Online. Ab dem 1. Juli 2020 können Sie keine neuen In-Place Haltebereiche erstellen. Sie können aber weiterhin In-Place Haltebereiche im EAC oder mithilfe des Cmdlets "Set-MailboxSearch" in Exchange Online PowerShell verwalten. Ab dem 1. Oktober 2020 können Sie jedoch In-Place Haltebereiche nicht mehr verwalten. Sie können sie nur im EAC oder mithilfe des Cmdlets Remove-MailboxSearch entfernen. Die Verwendung In-Place Haltebereiche in Exchange Server- und Exchange-Hybridbereitstellungen wird weiterhin unterstützt. Weitere Informationen zur Einstellung von In-Place Haltebereichen in Exchange Online finden Sie unter Retirement of legacy eDiscovery tools.

Bei einem Compliance-Archiv bleiben sämtliche Postfachinhalte einschließlich gelöschter Elemente und Originalversionen geänderter Elemente erhalten. Alle diese Postfachelemente werden bei einer Compliance-eDiscovery-Suche zurückgegeben. Wenn Sie ein In-Place Haltebereich für das Postfach eines Benutzers setzen, werden auch die Inhalte im entsprechenden Archivpostfach (sofern aktiviert) in den Haltebereich gesetzt und bei einer eDiscovery-Suche zurückgegeben.

Es gibt zwei Arten von Beschädigungen, die sich auf eine Exchange-Datenbank auswirken können: physische Beschädigung, die in der Regel durch Hardwareprobleme (insbesondere Speicherhardware) verursacht wird, und logische Beschädigung, die aufgrund anderer Faktoren auftritt. Im Allgemeinen gibt es zwei Arten von logischen Beschädigungen, die in einer Exchange-Datenbank auftreten können:

  • Logische Datenbankbeschädigung – Die Prüfsumme der Datenbankseite stimmt überein, aber die Daten auf der Seite sind logisch falsch. Dies kann auftreten, wenn das Datenbankmodul (Extensible Storage Engine, ESE) versucht, eine Datenbankseite zu schreiben, und obwohl das Betriebssystem eine Erfolgsmeldung zurückgibt, werden die Daten entweder nie auf den Datenträger geschrieben oder an die falsche Stelle geschrieben. Dies wird als verlorene Leerung bezeichnet. ESE enthält zahlreiche Features und Sicherheitsvorkehrungen, die darauf ausgelegt sind, physische Beschädigungen einer Datenbank und andere Datenverlustszenarien zu verhindern. Um zu verhindern, dass verloren gegangene Daten verloren gehen, enthält ESE einen Erkennungsmechanismus für die verlorene Spülung in der Datenbank zusammen mit einem Feature (Wiederherstellung einer einzelnen Seite), um es zu korrigieren.
  • Logische Beschädigung speichern – Daten werden auf eine Weise hinzugefügt, gelöscht oder bearbeitet, die der Benutzer nicht erwartet. Diese Fälle werden durch Anwendungen von Drittanbietern verursacht. Es handelt sich in der Regel um Eine Beschädigung in dem Sinne, dass der Benutzer sie als Beschädigung angibt. Der Exchange-Speicher betrachtet die Transaktion, die zur logischen Beschädigung geführt hat, als eine Folge gültiger MAPI-Operationen. Die In-Situ-Aufbewahrungsfeatures in Exchange Online bieten Schutz vor logischen Speicherbeschädigungen (da dadurch verhindert wird, dass Inhalte von einem Benutzer oder einer Anwendung dauerhaft gelöscht werden).

Exchange Online führt mehrere Konsistenzprüfungen für replizierte Protokolldateien sowohl bei der Protokollüberprüfung als auch bei der Protokollwiederholung durch. Diese Konsistenzüberprüfungen verhindern, dass physische Beschädigungen vom System repliziert werden. Beispielsweise wird während der Protokollüberprüfung eine Überprüfung der physischen Integrität durchgeführt, die die Protokolldatei überprüft und überprüft, ob die in der Protokolldatei aufgezeichnete Prüfsumme der im Arbeitsspeicher generierten Prüfsumme entspricht. Darüber hinaus wird der Protokolldateiheader untersucht, um sicherzustellen, dass die im Protokollheader aufgezeichnete Protokolldateisignatur mit der der Protokolldatei übereinstimmt. Während der Protokollreplay wird die Protokolldatei einer weiteren Prüfung unterzogen. Beispielsweise enthält der Datenbankheader auch die Protokollsignatur, die mit der Signatur der Protokolldatei verglichen wird, um sicherzustellen, dass sie übereinstimmen.

Der Schutz vor Beschädigung von Postfachdaten in Exchange Online wird durch die Verwendung von Exchange Native Data Protection erreicht, einer Resilienzstrategie, die replikation auf Anwendungsebene über mehrere Server und mehrere Rechenzentren hinweg zusammen mit anderen Features nutzt, die dazu beitragen, Daten aufgrund von Beschädigungen oder anderen Gründen vor dem Verlust zu schützen.Protection of corruption of mailbox data in Exchange Online is achieved by using Exchange Native Data Protection, a resiliency strategy that leverages application-level replication across multiple servers and multiple datacenters along with other features that help protect data from being lost due to corruption or other reasons. Zu diesen Features gehören systemeigene Features, die von Microsoft oder der Exchange Online Anwendung selbst verwaltet werden, z. B.:

  • Datenverfügbarkeitsgruppen
  • Einzelbitkorrektur
  • Onlinedatenbanküberprüfung
  • Erkennung verlorener Spülung
  • Wiederherstellen einer einzelnen Seite
  • Postfachreplikationsdienst
  • Protokolldateiprüfungen
  • Bereitstellung im resilienten Dateisystem

Weitere Informationen zu den zuvor aufgeführten nativen Features finden Sie unter den Links. Weitere Informationen und Details zu Elementen ohne Hyperlinks finden Sie in den folgenden Themen. Zusätzlich zu diesen nativen Features umfasst Exchange Online auch Datenresilienzfeatures, die Kunden verwalten können, z. B.:

Datenbankverfügbarkeitsgruppen

Jede Postfachdatenbank in Microsoft 365 wird in einer Datenbankverfügbarkeitsgruppe (DAG) gehostet und in geografisch getrennte Rechenzentren innerhalb derselben Region repliziert. Die häufigste Konfiguration sind vier Datenbankkopien in vier Rechenzentren. Einige Regionen verfügen jedoch über weniger Rechenzentren (Datenbanken werden in drei Rechenzentren in Indien und zwei Rechenzentren in Australien und Japan repliziert). In allen Fällen verfügt jede Postfachdatenbank jedoch über vier Kopien, die über mehrere Rechenzentren verteilt sind, wodurch sichergestellt wird, dass Postfachdaten vor Software-, Hardware- und sogar Rechenzentrumsfehlern geschützt sind.

Von diesen vier Kopien sind drei als hoch verfügbar konfiguriert. Die vierte Kopie ist als verzögerte Datenbankkopie konfiguriert. Die verzögerte Datenbankkopie ist nicht für die Wiederherstellung einzelner Postfächer oder Postfachelemente vorgesehen. Sein Zweck ist es, einen Wiederherstellungsmechanismus für das seltene Ereignis einer systemweiten, katastrophalen logischen Beschädigung bereitzustellen.

Verzögerte Datenbankkopien in Exchange Online werden mit einer Verzögerung von sieben Tagen für die Wiedergabe von Protokolldateien konfiguriert. Darüber hinaus ist der Exchange Replay Lag Manager aktiviert, um dynamische Protokolldateien für verzögerte Kopien bereitzustellen, damit verzögerte Datenbankkopien selbst repariert und das Wachstum von Protokolldateien verwaltet werden können. Obwohl verzögerte Datenbankkopien in Exchange Online verwendet werden, ist es wichtig zu wissen, dass sie keine garantierte Point-in-Time-Sicherung sind. Verzögerte Datenbankkopien in Exchange Online haben einen Verfügbarkeitsschwellenwert von in der Regel etwa 90 %, aufgrund von Zeiträumen, in denen der Datenträger, der eine verzögerte Kopie enthält, aufgrund eines Datenträgerfehlers verloren geht, die verzögerte Kopie zu einer hoch verfügbaren Kopie wird (aufgrund der automatischen Wiedergabe), sowie aufgrund der Zeiträume, in denen die verzögerte Datenbankkopie die Warteschlange für die Protokollwiederholung neu erstellt.

Transportresilienz

Exchange Online umfasst zwei primäre Features für die Transportresilienz: Schattenredundanz und Sicherheitsnetz. Schattenredundanz behält während der Übertragung eine redundante Kopie einer Nachricht bei. Safety Net behält eine redundante Kopie einer Nachricht bei, nachdem die Nachricht erfolgreich übermittelt wurde.

Mit Schattenredundanz erstellt jeder Exchange Online Transportserver eine Kopie jeder empfangenen Nachricht, bevor er den erfolgreichen Empfang der Nachricht an den sendenden Server bestätigt. Dadurch werden alle Nachrichten in der Transportpipeline während der Übertragung redundant. Wenn Exchange Online feststellt, dass die ursprüngliche Nachricht während der Übertragung verloren gegangen ist, wird eine redundante Kopie der Nachricht erneut gelöscht.

Safety Net ist eine Transportwarteschlange, die dem Transportdienst auf einem Postfachserver zugeordnet ist. In dieser Warteschlange werden Kopien von Nachrichten gespeichert, die vom Server erfolgreich verarbeitet wurden. Wenn für einen Ausfall einer Postfachdatenbank oder eines Servers eine veraltete Kopie der Postfachdatenbank aktiviert werden muss, werden Nachrichten in der Safety Net-Warteschlange automatisch an die neue aktive Kopie der Postfachdatenbank gesendet. Das Sicherheitsnetz ist ebenfalls redundant, wodurch der Transport als einzelner Fehlerpunkt eliminiert wird. Es verwendet das Konzept eines primären Sicherheitsnetzes und eines Schattensicherheitsnetzes. Wenn das primäre Sicherheitsnetz für mehr als 12 Stunden nicht verfügbar ist, werden erneute Übermittlungsanforderungen zu Schatten-Erneut-Übermittlungsanforderungen, und Nachrichten werden aus dem Shadow Safety Net erneut gesendet.

Erneute Nachrichtenübermittlungen aus Safety Net werden automatisch von der Active Manager-Komponente des Microsoft Exchange-Replikationsdiensts initiiert, der DAGs und Postfachdatenbankkopien verwaltet. Zum erneuten Übermitteln von Nachrichten aus Safety Net sind keine manuellen Aktionen erforderlich.

Einzelbitkorrektur

ESE enthält einen Mechanismus zum Erkennen und Beheben von Single-Bit-CRC-Fehlern (auch als Single-Bit-Flips bezeichnet), die das Ergebnis von Hardwarefehlern sind (und daher physische Beschädigung darstellen). Wenn diese Fehler auftreten, korrigiert ESE sie automatisch und protokolliert ein Ereignis im Ereignisprotokoll.

Onlinedatenbanküberprüfung

Die Onlinedatenbanküberprüfung (auch als Datenbanküberprüfungssumme bezeichnet) ist der Prozess, bei dem ein ESE eine Datenbankkonsistenzprüfung verwendet, um jede Seite zu lesen und auf Seitenbeschädigung zu überprüfen. Der Hauptzweck besteht darin, physische Beschädigungen und verlorene Spülungen zu erkennen, die von Transaktionsvorgängen möglicherweise nicht erkannt werden. Die Datenbanküberprüfung führt auch Nachspeicherabsturzvorgänge durch. Aufgrund von Abstürzen kann Speicherplatz verloren gehen, und die Onlinedatenbanküberprüfung findet und stellt verlorenen Speicherplatz wiederher. Das System ist so konzipiert, dass jede Datenbank einmal alle sieben Tage vollständig gescannt wird.

Erkennung verlorener Spülung

Ein Leerlauf tritt auf, wenn ein Datenbankschreifvorgang, der vom Datenträgersubsystem/Betriebssystem als abgeschlossen zurückgegeben wurde, nicht tatsächlich auf den Datenträger geschrieben wurde oder an dem falschen Speicherort geschrieben wurde. Verlorene Flush-Vorfälle können zu einer logischen Beschädigung der Datenbank führen. Um zu verhindern, dass verloren gegangene Daten verloren gehen, enthält ESE einen Mechanismus zur Erkennung des Leerens. Da Datenbankseiten in passive Kopien geschrieben werden, wird eine Überprüfung auf verlorene Leerungen für die aktive Kopie durchgeführt. Wenn ein leerer Vorgang erkannt wird, kann ESE den Prozess mithilfe eines Seitenpatchvorgangs reparieren.

Wiederherstellen einer einzelnen Seite

Die Wiederherstellung einzelner Seiten, auch als Seitenpatching bezeichnet, ist ein automatischer Prozess, bei dem beschädigte Datenbankseiten durch fehlerfreie Kopien aus einem fehlerfreien Replikat ersetzt werden. Der Reparaturvorgang für eine beschädigte Seite hängt davon ab, ob die Datenbankkopie aktiv oder passiv ist. Wenn eine aktive Datenbankkopie auf eine beschädigte Seite stößt, kann sie eine Seite aus einem ihrer Replikate kopieren, sofern die kopierte Seite auf dem neuesten Stand ist. Dieser Prozess wird erreicht, indem eine Anforderung für die Seite in den Protokolldatenstrom eingefügt wird, der die Grundlage der Postfachdatenbankreplikation ist. Sobald ein Replikat auf die Seitenanforderung trifft, antwortet es, indem es eine Kopie der Seite an die anfordernde Datenbankkopie sendet. Die Wiederherstellung einzelner Seiten bietet auch einen asynchronen Kommunikationsmechanismus für aktive Benutzer, um eine Seite von Replikaten anzufordern, auch wenn die Replikate derzeit offline sind.

Im Falle einer Beschädigung in einer passiven Datenbankkopie, einschließlich einer verzögerten Datenbankkopie, da sich diese Kopien immer hinter ihrer aktiven Kopie befinden, ist es immer sicher, jede Seite von der aktiven Kopie in eine passive Kopie zu kopieren. Eine passive Datenbankkopie ist von Natur aus hoch verfügbar. Während des Seitenpatchvorgangs wird die Protokollwiederholung angehalten, aber das Kopieren von Protokollen wird fortgesetzt. Die passive Datenbankkopie ruft eine Kopie der beschädigten Seite aus der aktiven Kopie ab, wartet, bis die Protokolldatei, die die maximal erforderliche Protokollgenerierungsanforderung erfüllt, kopiert und überprüft wird, und patches dann die beschädigte Seite. Nachdem die Seite gepatcht wurde, wird die Wiedergabe des Protokolls fortgesetzt. Der Vorgang ist für die verzögerte Datenbankkopie identisch, mit der Ausnahme, dass die verzögerte Datenbank zuerst alle Protokolldateien wiedergibt, die erforderlich sind, um einen patchbaren Zustand zu erreichen.

Postfachreplikationsdienst

Das Verschieben von Postfächern ist ein wichtiger Bestandteil der Verwaltung eines umfangreichen E-Mail-Diensts. Es gibt immer aktualisierte Technologien und Hardware- und Versionsupgrades, daher ist es wichtig, ein robustes, gedrosselte System zu haben, das es unseren Technikern ermöglicht, diese Arbeit zu erledigen, während das Postfach für Benutzer transparent bleibt (indem sichergestellt wird, dass sie während des gesamten Prozesses online bleiben) und sicherstellen, dass der Prozess ordnungsgemäß skaliert wird, wenn Postfächer größer und größer werden.

Der Exchange-Postfachreplikationsdienst (Exchange Mailbox Replication Service, MRS) ist für das Verschieben von Postfächern zwischen Datenbanken verantwortlich. Während der Verschiebung führt MRS eine Konsistenzüberprüfung für alle Elemente innerhalb des Postfachs durch. Wenn ein Konsistenzproblem gefunden wird, behebt MRS entweder das Problem oder überspringt die beschädigten Elemente, wodurch die Beschädigung aus dem Postfach entfernt wird.

Da MRS eine Komponente von Exchange Online ist, können wir Änderungen an ihrem Code vornehmen, um neue Formen von Korruption zu beheben, die in Zukunft erkannt werden. Wenn wir beispielsweise ein Konsistenzproblem erkennen, das MRS nicht beheben kann, können wir die Beschädigung analysieren, den MRS-Code ändern und die Inkonsistenz korrigieren (wenn wir wissen, wie das geht).

Protokolldateiprüfungen

Alle Transaktionsprotokolldateien, die von einer Exchange-Datenbank generiert werden, werden mehreren Formen der Konsistenzprüfung unterzogen. Wenn eine Protokolldatei erstellt wird, wird zunächst ein Bitmuster geschrieben, und dann wird eine Reihe von Protokoll-Schreibvorgängen ausgeführt. Diese Struktur ermöglicht es Exchange Online, eine Reihe von Prüfungen (leerer Vorgang, CRC und andere Überprüfungen) auszuführen, um jede Protokolldatei beim Schreiben und erneuten Replizieren zu überprüfen.

Bereitstellung im resilienten Dateisystem

Um eine Beschädigung auf Dateisystemebene zu verhindern, wird Exchange Online auf ReFS-Partitionen (Resilient File System) bereitgestellt, um verbesserte Wiederherstellungsfunktionen bereitzustellen. ReFS ist ein Dateisystem in Windows Server 2012 und höher, das so konzipiert ist, dass es widerstandsfähiger gegen Datenbeschädigung ist und dadurch die Datenverfügbarkeit und -integrität maximiert. Insbesondere bietet ReFS Verbesserungen in der Art und Weise, wie Metadaten aktualisiert werden, was einen besseren Schutz für Daten bietet und Fälle von Datenbeschädigung reduziert. Außerdem werden Prüfsummen verwendet, um die Integrität von Dateidaten und Metadaten zu überprüfen, um sicherzustellen, dass Datenbeschädigungen leicht gefunden und repariert werden können.

Exchange Online nutzt mehrere ReFS-Vorteile:

  • Eine größere Resilienz bei der Datenintegrität bedeutet weniger Vorfälle bei Datenbeschädigungen. Die Verringerung der Anzahl von Beschädigungsvorfällen bedeutet weniger unnötige Datenbankneuzugänge.
  • Prüfsummen, die für Metadaten ausgeführt werden, die die Erkennung von Korruptionsfällen früher und deterministischer ermöglichen, sodass wir Kundendatenbeschädigungen beheben können, bevor graue Fehler auf Datenvolumes auftreten.
  • Geeignet für große Datasets – petabytes und größer – ohne Auswirkungen auf die Leistung
  • Unterstützung für andere Features, die von Exchange Online verwendet werden, z. B. BitLocker-Verschlüsselung.

Exchange Online profitiert auch von anderen ReFS-Features:

  • Integrität (Integritätsdatenströme) – ReFS speichert Daten so, dass sie vor vielen häufig auftretenden Fehlern geschützt werden, die normalerweise zu Datenverlusten führen können. Microsoft 365 Search verwendet Integritätsstreams, um die Erkennung von Datenträgerschäden und Prüfsummen von Dateiinhalten frühzeitig zu unterstützen. Das Feature reduziert auch Beschädigungsvorfälle, die durch "Zerrissene Schreibvorgänge" verursacht werden (wenn ein Schreibvorgang aufgrund von Stromausfällen nicht abgeschlossen wird usw.).
  • Verfügbarkeit (Restwert) – ReFS priorisiert die Verfügbarkeit von Daten. In der Vergangenheit waren Dateisysteme häufig anfällig für Datenbeschädigungen, bei denen das System zur Reparatur offline geschaltet werden musste. Obwohl selten, wenn eine Beschädigung auftritt, implementiert ReFS Restwert, ein Feature, das die beschädigten Daten aus dem Namespace auf einem Livevolume entfernt und sicherstellt, dass gute Daten nicht durch nicht reparierbare beschädigte Daten beeinträchtigt werden. Das Anwenden des Restwertfeatures und das Isolieren von Datenbeschädigungen auf Exchange Online Datenbankvolumes bedeutet, dass nicht betroffene Datenbanken auf einem beschädigten Volume zwischen dem Zeitpunkt der Beschädigung und Reparatur fehlerfrei bleiben können. Diese Struktur erhöht die Verfügbarkeit von Datenbanken, die normalerweise von solchen Datenträgerschäden betroffen wären.