Änderungen bei hoher Verfügbarkeit und Ausfallsicherheit im Vergleich zu früheren Versionen

Artikel
04/04/2023

Gilt für: Exchange Server 2013 SP1

Exchange 2013 verwendet DAGs und Postfachdatenbankkopien sowie andere Features wie die Wiederherstellung einzelner Elemente, Aufbewahrungsrichtlinien und verzögerte Datenbankkopien, um Hochverfügbarkeit, Standortresilienz und nativen Schutz von Exchange-Daten zu gewährleisten. Die Hochverfügbarkeitsplattform, der Exchange-Informationsspeicher und die Extensible Storage Engine (ESE) wurden verbessert, um eine höhere Verfügbarkeit und einfachere Verwaltung zu ermöglichen und Kosten zu senken. Diese Verbesserungen umfassen:

Verringerung der IOPS gegenüber Exchange 2010: Dadurch können Sie größere Datenträger in Bezug auf Kapazität und IOPS so effizient wie möglich nutzen.
Verwaltete Verfügbarkeit: Bei der verwalteten Verfügbarkeit werden eine interne Überwachung und wiederherstellungsorientierte Funktionen eng miteinander verzahnt, um Ausfälle zu vermeiden, Dienste proaktiv wiederherzustellen, ein Serverfailover automatisch einzuleiten oder den Administrator zu benachrichtigen, damit dieser entsprechende Maßnahmen ergreift. Der Schwerpunkt liegt eher auf der Überwachung und Verbesserung der Benutzerfreundlichkeit als darauf, nur den Betrieb von Servern und Komponenten sicherzustellen, damit die Dienste ohne Unterbrechung verfügbar sind.
Verwalteter Speicher: Der verwaltete Speicher ist der Name der neu geschriebenen Informationsspeicherprozesse in Exchange 2013. Der neue verwaltete Speicher ist in C# geschrieben und eng in den Microsoft Exchange-Replikationsdienst (MSExchangeRepl.exe) integriert, um eine verbesserte Resilienz und damit eine höhere Verfügbarkeit bereitzustellen.
Unterstützung für mehrere Datenbanken pro Datenträger: Exchange 2013 umfasst Verbesserungen, mit denen Sie mehrere Datenbanken (Mischungen aus aktiven und passiven Kopien) auf demselben Datenträger unterstützen können, wodurch größere Datenträger in Bezug auf Kapazität und IOPS so effizient wie möglich genutzt werden können.
AutoReseed: Mit der Funktion zum automatischen Erneuteinsenden können Sie die Datenbankredundanz nach einem Datenträgerausfall schnell wiederherstellen. Wenn ein Datenträger ausfällt, wird die auf diesem Datenträger gespeicherte Datenbankkopie aus der aktiven Datenbankkopie auf einen Ersatzdatenträger auf demselben Server kopiert. Wenn mehrere Datenbankkopien auf dem fehlerhaften Datenträger gespeichert waren, kann für diese automatisch ein erneutes Seeding auf einem Ersatzdatenträger ausgeführt werden. Damit kann das erneute Seeding schneller ausgeführt werden, da die aktiven Datenbanken sich wahrscheinlich auf mehreren Servern befinden und die Daten parallel kopiert werden können.
Automatische Wiederherstellung nach Speicherfehlern: Dieses Feature setzt die in Exchange 2010 eingeführte Innovation fort, um dem System die Wiederherstellung nach Fehlern zu ermöglichen, die sich auf Resilienz oder Redundanz auswirken. Zusätzlich zu den Exchange 2010-Fehlerüberprüfungsverhaltensweisen enthält Exchange 2013 zusätzliche Wiederherstellungsverhalten für lange E/A-Zeiten, einen übermäßigen Arbeitsspeicherverbrauch durch MSExchangeRepl.exe und schwerwiegende Fälle, in denen sich das System in einem so schlechten Zustand befindet, dass Threads nicht geplant werden können.
Verbesserungen für verzögerte Kopien: Verzögerte Kopien können sich jetzt mithilfe der automatischen Abspielung von Protokollen zu einem gewissen Grad selbst kümmern. Verzögerte Kopien spielen Protokolldateien in verschiedenen Situationen automatisch ab, z. B. in Szenarien mit Seitenpatches und wenig Speicherplatz. Wenn das System ermittelt, dass für eine verzögerte Kopie ein Seitenpatching erforderlich ist, werden die Protokolle automatisch in die verzögerte Kopie wiedergegeben, um das Seitenpatching auszuführen. Verzögerte Kopien rufen auch dieses Feature für die automatische Wiedergabe auf, wenn ein Schwellenwert für geringen Speicherplatz erreicht wird und wenn die verzögerte Kopie als die einzige verfügbare Kopie für einen bestimmten Zeitraum erkannt wird. Darüber hinaus können verzögerte Kopien Safety Net verwenden, um die Wiederherstellung oder Aktivierung zu vereinfachen.
Verbesserungen bei warnungsbasiertem Einzelkopien: Die in Exchange 2010 eingeführte Warnung für einmaliges Kopieren ist kein separates geplantes Skript mehr. Es wurde in die Systemkomponenten für verwaltete Verfügbarkeit integriert und ist jetzt eine systemeigene Funktion von Exchange.
Automatische DAG-Netzwerkkonfiguration: DAG-Netzwerke können vom System basierend auf Konfigurationseinstellungen automatisch konfiguriert werden. DAGs bieten nicht nur manuelle Konfigurationsoptionen, sondern können auch zwischen MAPI- und Replikationsnetzwerken unterscheiden und DAG-Netzwerke automatisch konfigurieren.

Verringerung der IOPS gegenüber Exchange 2010

In Exchange 2010 weisen passive Datenbankkopien eine geringe Prüfpunkttiefe auf, die für ein schnelles Failover erforderlich ist. Zusätzlich führen die passiven Kopien ein aggressives Preread von Daten durch, um einer Prüfpunkttiefe von 5 MB nachzukommen. Aufgrund der Verwendung einer geringen Prüfpunkttiefe und der Durchführung dieser aggressiven Vorlesevorgänge waren die IOPS für eine passive Datenbankkopie gleich IOPS für eine aktive Kopie in Exchange 2010.

In Exchange 2013 ist das System in der Lage, ein schnelleres Failover durchzuführen, während gleichzeitig eine hohe Prüfpunkttiefe für die passive Kopie verwendet wird (100 MB). Da passive Kopien eine Prüfpunkttiefe von 100 MB haben, werden sie so eingestellt, dass sie nicht mehr so aggressiv sind. Als Ergebnis der höheren Prüfpunkttiefe und der Verringerung aggressiver Prereadvorgänge weist eine passive Kopie in Exchange 2013 gegenüber einer aktiven Kopie etwa 50 Prozent weniger IOPS auf.

Die höhere Prüfpunkttiefe für passive Kopien hat weitere Änderungen zur Folge. Bei einem Failover in Exchange 2010 wird der Datenbankcache geleert, wenn die Datenbank von einer passiven Kopie in eine aktive Kopie konvertiert wird. In Exchange 2013 wurde die ESE-Protokollierung umgeschrieben, sodass der Cache beim Übergang von einer passiven auf eine aktive Kopie erhalten bleibt. Da ESE den Cache nicht leeren muss, kann das Failover schneller ausgeführt werden.

Eine weitere Änderung bezieht sich auf die Hintergrundwartung für Datenbanken. Bei der Hintergrundwartung für Datenbanken werden nun 1-2 MB pro Sekunde pro Kopie bearbeitet.

Als Ergebnis dieser Änderungen bietet Exchange 2013 gegenüber Exchange 2010 eine erhebliche Verringerung der IOPS.

Verwaltete Verfügbarkeit

Verwaltete Verfügbarkeit ist die Integration der integrierten, aktiven Überwachung und der Exchange 2013-Hochverfügbarkeitsplattform. Mit der verwalteten Verfügbarkeit kann das System basierend auf der Dienstintegrität bestimmen, wann ein Failover für eine Datenbank ausgeführt werden soll. Verwaltete Verfügbarkeit ist eine interne Infrastruktur, die auf den Serverrollen Clientzugriff und Postfach in Exchange 2013 bereitgestellt wird. Die verwaltete Verfügbarkeit umfasst drei Standard asynchronen Komponenten, die ständig arbeiten. Die erste Komponente ist die Probe-Engine, die für die Durchführung von Messungen auf dem Server und das Sammeln von Daten zuständig ist. Die Ergebnisse dieser Messungen fließen in die zweite Komponente, den Monitor, ein. Der Monitor enthält die gesamte Geschäftslogik, die vom System basierend darauf verwendet wird, was für die gesammelten Daten als fehlerfrei gilt. Ähnlich wie bei einer Mustererkennungs-Engine sucht der Monitor bei allen gesammelten Messungen nach den verschiedenen Mustern und entscheidet dann, ob etwas als fehlerfrei gilt. Schließlich gibt es noch die Responder-Engine, die für Wiederherstellungsaktionen zuständig ist. Wenn etwas fehlerhaft ist, besteht die erste Aktion darin, diese Komponente wiederherzustellen. Dies kann mehrstufige Wiederherstellungsaktionen umfassen. Der erste Versuch kann beispielsweise darin bestehen, den Anwendungspool neu zu starten, der zweite kann darin bestehen, den Dienst neu zu starten, der dritte Versuch kann darin bestehen, den Server neu zu starten, und der nachfolgende Versuch kann darin bestehen, den Server offline zu schalten, damit er keinen Datenverkehr mehr akzeptiert. Wenn die Wiederherstellungsaktionen nicht erfolgreich sind, eskaliert das System das Problem über Ereignisprotokollbenachrichtigungen an einen Menschen.

Die verwaltete Verfügbarkeit wird in Form von zwei Diensten implementiert:

Exchange Health Manager Service (MSExchangeHMHost.exe): Dies ist ein Controllerprozess, der zum Verwalten von Arbeitsprozessen verwendet wird. Es wird verwendet, um den Arbeitsprozess nach Bedarf zu erstellen, auszuführen und zu starten und zu beenden. Es wird auch verwendet, um den Arbeitsprozess für den Fall, dass der Prozess abstürzt, wiederherzustellen, um zu verhindern, dass der Arbeitsprozess ein Single Point of Failure ist.
Exchange-Integritäts-Manager-Arbeitsprozess (MSExchangeHMWorker.exe): Dies ist der Arbeitsprozess, der für die Ausführung der Laufzeitaufgaben verantwortlich ist.

Bei der verwalteten Verfügbarkeit wird ein beständiger Speicher verwendet, um die zugehörigen Funktionen auszuführen:

Zum Initialisieren der Arbeitselementdefinitionen während des Starts des Arbeitsprozesses werden XML-Konfigurationsdateien verwendet.
Die Registrierung wird zum Speichern von Laufzeitdaten wie z. B. Lesezeichen verwendet.
Die Crimson-Kanal-Ereignisprotokollinfrastruktur wird zum Speichern der Arbeitselementergebnisse verwendet.

Weitere Informationen zur verwalteten Verfügbarkeit finden Sie unter Verwaltete Verfügbarkeit.

Verwalteter Speicher

Alle vorherigen Exchange Server-Versionen, von Exchange Server 4.0 bis Exchange Server 2010, haben die Ausführung einer einzelnen Instanz des Prozesses des Microsoft Exchange-Informationsspeichers (Store.exe) in der Serverrolle "Mailbox" unterstützt. Diese einzelne Speicherinstanz hostet alle Datenbanken auf diesem Server: aktive, passive, verzögerte und wiederhergestellte. In den vorherigen Exchange-Architekturen gibt es nur wenig Isolation zwischen den verschiedenen Datenbanken, die auf einem Postfachserver gehostet werden. Ein Problem mit einer einzelnen Postfachdatenbank hat das Potenzial, sich auf alle anderen Datenbanken auszuwirken, und Ausfälle aufgrund der Beschädigung einer Datenbank können den Dienst für alle Benutzer, deren Datenbanken auf diesem Server gehostet werden, beeinträchtigen.

Eine weitere Herausforderung bei einer einzelnen Speicherinstanz von Exchange ist, dass Extensible Storage Engine (ESE) für 8 bis 12 Prozessorkerne angemessen skaliert ist, aber darüber hinaus Probleme mit prozessorübergreifender Kommunikation und Cache-Synchronisierung auftreten können. Angesichts der heutigen größeren Server mit 16+ verfügbaren Kernsystemen würde dies die administrative Herausforderung darstellen, die Affinität von 8-12 Kernen für ESE zu verwalten und die anderen Kerne für Nicht-Store-Prozesse zu verwenden (z. B. Assistenten, Search Foundation, verwaltete Verfügbarkeit usw.). Außerdem waren die Aufwärtsskalierungsoptionen für den Informationsspeicherprozess in der bisherigen Architektur beschränkt.

Der Prozess Store.exe hat im Laufe der Jahre, in denen sich Exchange Server selbst entwickelt hat, auch eine bemerkenswerte Entwicklung durchgemacht, aber als einzelner Prozess ist seine Skalierbarkeit begrenzt, und er stellt auch eine einzelne Fehlerquelle dar. Aufgrund dieser Begrenzungen ist Store.exe in Exchange 2013 nicht mehr vorhanden und wird durch den verwalteten Speicher ersetzt.

Weitere Informationen finden Sie unter Verwalteter Speicher.

Mehrere Datenbanken pro Volume

Obwohl die Speicherverbesserungen in Exchange 2013 primär auf JBOD-Konfigurationen (Just a Bunch Of Disks) ausgerichtet sind, stehen sie für alle unterstützten Speicherkonfigurationen zur Verfügung. Eine dieser Verbesserungen ist die Fähigkeit, mehrere Datenbanken auf demselben Volume zu hosten. Dadurch ergibt sich eine bessere Unterstützung für große Datenträger in Exchange. Diese Verbesserungen führen zu einer sehr viel effizienteren Verwendung großer Datenträger in Bezug auf Kapazität, IOPS und Zeit für das erneute Seeding, und sie tragen dazu bei, den Herausforderungen bei der Ausführung in einer JBOD-Speicherkonfiguration zu begegnen:

Datenbankgrößen müssen verwaltbar sein.
Das erneute Seeding muss schnell und zuverlässig erfolgen.
Die Speicherkapazität nimmt zu, die IOPS jedoch nicht.
Datenträger mit passiven Datenbankkopien sind bezogen auf die IOPS nicht ausgelastet.
Verzögerte Kopien haben asymmetrische Speicheranforderungen.
Bei der Wiederherstellung nach Speicherplatzproblemen besteht nur geringe Flexibilität.

Der Trend zur Erhöhung der Speicherkapazität setzt sich fort, wobei 8-Terabyte-Laufwerke voraussichtlich bald verfügbar sein werden. Bei Verwendung von 8-Terabyte-Laufwerken in Verbindung mit den bewährten Methoden für die maximale Datenbankgröße von Exchange (2 Terabytes) würden Sie mehr als 5 Terabyte Speicherplatz verschwenden. Eine Lösung wäre, die Datenbanken zu vergrößern, aber dies hemmt die Verwaltbarkeit, da dadurch lange Zeiten für die Erneuteinsetzung eingeführt werden, einschließlich in einigen Fällen, betriebsbedingte, nicht zu verwaltbare Zeitangaben, und die Zuverlässigkeit des Kopierens dieser Datenmenge über das Netzwerk ist gefährdet.

Darüber hinaus ist beim Exchange 2010-Modell der Datenträger, auf dem eine passive Kopie gespeichert wird, in Bezug auf die IOPS nicht ausgelastet. Im Falle einer verzögerten passiven Kopie ist der Datenträger nicht nur in Bezug auf die IOPS unterlastet, sondern auch in Bezug auf die Datenträger zum Speichern der aktiven und nicht verzögerten passiven Kopien in seiner Größe asymmetrisch.

Als Ergebnis der stetigen Weiterentwicklung wurde Exchange 2013 so optimiert, dass große Datenträger (8 TB) in einer JBOD-Konfiguration effizienter genutzt werden können. In Exchange 2013 können bei mehreren Datenbanken pro Datenträger gleich große Datenträger mehrere Datenbankkopien (verzögerte Kopien eingeschlossen) speichern. Das Ziel besteht darin, die Verteilung der Benutzer auf die Anzahl von vorhandenen Volumes zu verbessern und so ein symmetrisches Design zu erhalten, bei dem während des normalen Betriebs jedes DAG-Mitglied eine Kombination aus aktiven, passiven und (optional) verzögerten Kopien auf demselben Volume hostet.

Die nachstehende Abbildung zeigt eine Beispielkonfiguration mit mehreren Datenbanken pro Volume.

Mehrere Datenbanken pro Volume.

Die obige Konfiguration gewährleistet ein symmetrisches Design. Alle vier Server verfügen über dieselben vier Datenbanken, jeweils gehostet auf einem einzelnen Datenträger pro Server. Der entscheidende Punkt ist, dass die Anzahl von Kopien jeder Datenbank der Anzahl von Datenbankkopien pro Datenträger entsprechen sollte. Im obigen Beispiel gibt es vier Kopien jeder Datenbank: eine aktive Kopie, zwei passive Kopien und eine verzögerte Kopie. Da vier Kopien jeder Datenbank vorliegen, umfasst die ordnungsgemäße Konfiguration vier Kopien pro Volume. Zusätzlich wird die Aktivierungseinstellung so konfiguriert, dass ein Ausgleich über die DAG und die einzelnen Server gewährleistet ist. Beispielsweise hat die aktive Kopie den Aktivierungseinstellungswert 1, die erste passive Kopie den Wert für die Aktivierungseinstellung 2, die zweite passive Kopie hat den Aktivierungseinstellungswert 3, und die verzögerte Kopie hat den Wert der Aktivierungseinstellung 4.

Zusätzlich zu einer besseren Verteilung der Benutzer auf die vorhandenen Volumes liegt ein weiterer Vorteil der Verwendung mehrerer Datenbanken pro Datenträger darin, dass die Zeit zur Wiederherstellung des Datenschutzes nach Fehlern verringert wird, die ein erneutes Seeding erforderlich machen (z. B. Datenträgerausfälle).

Je größer eine Datenbank ist, desto mehr Zeit wird für das erneute Seeding der Datenbank benötigt. Für eine 2-Terabyte-Datenbank kann es z. B. 23 Stunden dauern, bis eine Datenbank mit 8 Terabyte wieder eingereet wurde, während es bis zu 93 Stunden (fast vier Tage) dauern kann. Beide Seedingvorgänge würden mit etwa 20 MB pro Sekunde erfolgen. Dies bedeutet im Allgemeinen, dass ein erneutes Seeding für eine sehr große Datenbank nicht innerhalb einer angemessenen Zeit durchgeführt werden kann.

Im Fall eines Szenarios mit einer einzelnen Datenbankkopie pro Datenträger ist der Seedingvorgang quellgebunden, da der Seedingvorgang des Datenträgers über eine einzelne Quelle erfolgt. Indem sie das Volume in mehrere Datenbankkopien unterteilen und die aktive Kopie der passiven Datenbanken auf einem angegebenen Volume auf separaten DAG-Membern speichern. Das System ist im Kontext des erneuten Einsendens des Datenträgers nicht mehr quellgebunden. Wenn ein fehlerhafter Datenträger ausgetauscht wird, kann das erneute Seeding über mehrere Quellen erfolgen. Dies ermöglicht es dem System, den Schutz der Daten für diese Datenbanken in kürzerer Zeit erneut zu senden und wiederherzustellen.

Bei der Verwendung mehrerer Datenbanken pro Volume sollten die folgenden bewährten Methoden und Anforderungen befolgt werden:

Pro physischem Datenträger muss eine einzelne logische Datenträgerpartition verwendet werden. Erstellen Sie nicht mehrere Partitionen auf dem Datenträger. Jede Datenbankkopie und ihre Begleitdateien (z. B. Transaktionsprotokolle und Inhaltsindex) sollten in einem eindeutigen Verzeichnis auf der einzelnen Partition gehostet werden.
Die Anzahl von Datenbankkopien, die pro Volume konfiguriert werden, sollte der Anzahl an Kopien jeder Datenbank entsprechen. Wenn Sie beispielsweise über vier Kopien Ihrer Datenbanken verfügen, sollten Sie vier Datenbankkopien pro Volume verwenden.
Datenbankkopien sollten dieselben Nachbarelemente aufweisen. (Sie sollten sich beispielsweise alle auf dem gleichen Datenträger auf jedem jeweiligen Server befinden.)
Die Aktivierungseinstellungen in der DAG sollten abgeglichen werden, sodass jede Datenbankkopie auf einem bestimmten Datenträger einen eindeutigen Wert für die Aktivierungseinstellung aufweist.

AutoReseed

Automatisches erneutes Eeed oder AutoReseed ist ein Feature, das die normalerweise vom Administrator gesteuerte Aktion als Reaktion auf einen Datenträgerfehler, ein Datenbankbeschädigungsereignis oder ein anderes Problem ersetzt, das ein erneutes Inserieren einer Datenbankkopie erfordert. AutoReseed ist so konzipiert, dass die Datenbankredundanz nach einem Datenträgerausfall automatisch wiederhergestellt wird, indem ersatzfähige Datenträger verwendet werden, die auf dem System bereitgestellt wurden.

Weitere Informationen finden Sie unter AutoReseed. Ausführliche Schritte zur Konfiguration von AutoReseed finden Sie unter Konfigurieren von AutoReseed für eine Database Availability Group.

Automatische Wiederherstellung nach Speicherfehlern

Die automatische Wiederherstellung nach Speicherfehlern ist eine Weiterentwicklung der in Exchange 2010 eingeführten Funktion, die es dem System erlaubt, nach Ausfällen mit Auswirkung auf Resilienz oder Redundanz eine automatische Wiederherstellung durchzuführen. Zusätzlich zu den Exchange 2010-Fehlerüberprüfungsverhaltensweisen enthält Exchange 2013 zusätzliche Wiederherstellungsverhalten für lange E/A-Zeiten, eine übermäßige Arbeitsspeicherauslastung durch den Microsoft Exchange-Replikationsdienst (MSExchangeRepl.exe) und schwerwiegende Fälle, in denen Threads nicht geplant werden können.

Selbst in JBOD-Umgebungen können Probleme mit Speicherarraycontrollern auftreten, beispielsweise können diese abstürzen oder nicht mehr reagieren. Exchange 2010 umfasste eine Erkennung von nicht mehr reagierenden E/A-Vorgängen sowie Wiederherstellungsfunktionen zur Verbesserung der Ausfallsicherheit. Diese Funktionen werden in der folgenden Tabelle aufgeführt.

Name	Prüfen	Aktion	Schwellenwert
Erkennung nicht reagierender E/A-Vorgänge für ESE-Datenbank	ESE-Prüfungen für ausstehende E/A-Vorgänge	Generiert ein Fehlerelement im Crimson-Kanal, um den Server neu zu starten	240 Sekunden
Taktsignal für Fehlerelement im Kanal	Stellt sicher, dass Fehlerelemente in den Crimson-Kanal geschrieben und aus diesem gelesen werden können	Der Replikationsdienst sendet ein Taktsignal an den Crimson-Kanal und startet den Server bei Fehlern neu	30 Sekunden
Taktsignal für Systemdatenträger	Überprüft den Status des Systemdatenträgers auf dem Server	In regelmäßigen Abständen werden ungepufferte E/A an den Systemdatenträger gesendet, und der Server wird bei Auftreten eines Takttimeouts neu gestartet	120 Sekunden

Exchange 2013 verbessert die Ausfallsicherheit für Server und Speicher, indem neue Funktionen für weitere schwerwiegende Bedingungen bereitgestellt werden. Diese Bedingungen und Verhaltensweisen werden in der folgenden Tabelle beschrieben.

Name	Prüfen	Aktion	Schwellenwert
Ungültiger Systemstatus	Keine Threadplanung möglich, nicht verwaltete Threads eingeschlossen	Der Server wird neu gestartet	302 Sekunden
Lange E/A-Zeiten	Latenzmessungen für E/A-Vorgänge	Der Server wird neu gestartet	41 Sekunden
Speicherbelegung durch Replikationsdienst	Messung des Arbeitssatzes von "MSExchangeRepl.exe"	Protokollierung von Ereignis 4395 im Crimson-Kanal, mit einer Anforderung zur Dienstbeendigung Einleiten der Beendigung von "MSExchangeRepl.exe" Serverneustart, wenn Dienst nicht erfolgreich beendet werden kann	4 Gigabyte (GB)
Systemereignis 129 (Bus-Reset)	Im Systemereignisprotokoll nach Ereignis 129 suchen	Der Server wird neu gestartet	Wenn das Ereignis auftritt
Clusterdatenbank reagiert nicht mehr	Globale Update-Manager-Updates werden blockiert	Der Server wird neu gestartet	Wenn das Ereignis auftritt

Verbesserungen in Bezug auf verzögerte Kopien

Zu den Verbesserungen im Hinblick auf verzögerte Kopien gehören die Integration in das Sicherheitsnetz sowie die automatische Wiedergabe von Protokolldateien in bestimmten Szenarien. Das Sicherheitsnetz ist eine Funktion des Transportdiensts, die den Exchange 2010-Transportdumpster ersetzt. Das Sicherheitsnetz ähnelt dem Transportdumpster dahingehend, dass es sich um eine Zustellungswarteschlange handelt, die dem Transportdienst auf einem Postfachserver zugeordnet ist. Diese Warteschlange speichert Kopien von Nachrichten, die erfolgreich an die aktive Postfachdatenbank auf dem Postfachserver zugestellt wurden. Jede aktive Postfachdatenbank auf dem Postfachserver verfügt über eine eigene Warteschlange zum Speichern von Kopien der zugestellten Nachrichten. Sie können festlegen, wie lange das Sicherheitsnetz Kopien der erfolgreich zugestellten Nachrichten speichert, bis diese ablaufen und automatisch gelöscht werden.

Safety Net übernimmt eine gewisse Verantwortung für Schattenredundanz in DAG-Umgebungen. In DAG-Umgebungen muss die Schattenredundanz keine weitere Kopie der übermittelten Nachricht in einer Schattenwarteschlange aufbewahren, während sie darauf wartet, dass die übermittelte Nachricht in die passiven Kopien von Postfachdatenbanken auf den anderen Postfachservern in der DAG repliziert wird. Die Kopie der übermittelten Nachricht ist bereits in Safety Net gespeichert, sodass die Schattenredundanz die Nachricht bei Bedarf aus Safety Net erneut zugestellt werden kann.

Mit der Einführung von Safety Net wird das Aktivieren einer verzögerten Datenbankkopie einfacher. Angenommen, Sie verfügen über ein verzögerte Kopie mit einer Wiedergabeverzögerung von 2 Tagen. In diesem Fall würden sie das Sicherheitsnetz für einen Zeitraum von 2 Tagen konfigurieren. Wenn eine Situation eintritt, die die Verwendung einer verzögerten Kopie erforderlich macht, können Sie die Replikation für diese Kopie anhalten und die Kopie zweimal kopieren (zur Beibehaltung der Datenbankversion mit Verzögerung und zum Erstellen einer zusätzlichen Kopie, sofern diese benötigt wird). Anschließend nehmen Sie eine Kopie und entfernen alle Protokolldateien, mit Ausnahme der Protokolldateien im erforderlichen Bereich. Sie binden die Kopie ein, wodurch eine automatische Anforderung an das Sicherheitsnetz ausgelöst wird, die E-Mails der letzten zwei Tage erneut zuzustellen. Mit dem Sicherheitsnetz müssen Sie nicht länger ermitteln, ab welchem Zeitpunkt eine Beschädigung vorlag. Sie erhalten alle E-Mails der letzten zwei Tage zurück, abzüglich der Daten, die bei einem verlustbehafteten Failover regulär verloren gehen.

Verzögerte Kopien können sich jetzt bis zu einem gewissen Grad selbst verwalten und in bestimmten Szenarien eine automatische Protokollwiedergabe auslösen:

Wenn ein Schwellenwert für zu wenig Speicherplatz erreicht wird
Wenn die verzögerte Kopie eine physische Beschädigung aufweist und ein Seitenpatching erforderlich ist
Wenn weniger als drei fehlerfreie Kopien verfügbar sind (nur aktiv oder passiv; verzögerte Datenbankkopien werden nicht gezählt) für mehr als 24 Stunden

In Exchange 2010 stand das Seitenpatching nicht für verzögerte Kopien zur Verfügung. In Exchange 2013 kann das Seitenpatching über die automatische Wiedergabefunktion für verzögerte Kopien genutzt werden. Wenn das System ermittelt, dass für eine verzögerte Kopie ein Seitenpatching erforderlich ist, werden die Protokolle automatisch in die verzögerte Kopie wiedergegeben, um das Seitenpatching auszuführen. Verzögerte Kopien rufen auch dieses Feature für die automatische Wiedergabe auf, wenn ein Schwellenwert für geringen Speicherplatz erreicht wird und wenn die verzögerte Kopie als einzige verfügbare Kopie für einen bestimmten Zeitraum erkannt wird.

Die Wiedergabe für verzögerte Kopien ist standardmäßig deaktiviert und kann durch Ausführung des folgenden Befehls aktiviert werden:

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

Nach der Aktivierung wird eine Wiedergabe durchgeführt, wenn weniger als drei Kopien zur Verfügung stehen. Sie können den Standardwert 3 ändern, indem Sie den folgenden DWORD-Registrierungswert bearbeiten.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Sie müssen den folgenden Registrierungswert konfigurieren, um die Wiedergabe bei Erreichen von Schwellenwerten in Bezug auf zu wenig Speicherplatz zu aktivieren:

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

Starten Sie nach der Konfiguration einer dieser Registrierungseinstellungen den Microsoft Exchange DAG-Verwaltungsdienst neu, damit die Änderungen übernommen werden.

Betrachten Sie beispielsweise eine Umgebung, in der eine bestimmte Datenbank über 4 Kopien (3 hochverfügbare Kopien und 1 verzögerte Kopie) verfügt und die Standardeinstellung für ReplayLagManagerNumAvailableCopies verwendet wird. Wenn eine nicht verzögerte Kopie aus irgendeinem Grund außer Betrieb ist (z. B. wird sie angehalten usw.), spielt die verzögerte Kopie ihre Protokolldateien in 24 Stunden automatisch ab.

Verbesserte Warnung zu einzelnen Kopien

Die Hauptziele beim täglichen Exchange 2013-Messaging bestehen unter anderem darin sicherzustellen, dass Ihre Server zuverlässig arbeiten und dass sich Ihre Datenbankkopien in einem fehlerfreien Zustand befinden. Sie müssen eine aktive Überwachung von Hardware, Windows-Betriebssystem und Exchange-Diensten sicherstellen. In einer Exchange 2013-Umgebung mit Ausfallsicherheit für Postfächer ist es jedoch auch wichtig, die Integrität und den Status der DAG und Ihrer Postfachdatenbankkopien zu überwachen. Es ist besonders wichtig, ein Risikomanagement durch Datenredundanz durchzuführen und auf Szenarien zu überwachen, in denen lediglich eine einzelne Kopie einer replizierten Datenbank vorliegt. Dies ist wichtig in Umgebungen, in denen kein Redundant Array of Independent Disks (RAID) verwendet wird und stattdessen JBOD-Konfigurationen bereitgestellt werden. In einer RAID-Umgebung hat der Ausfall eines einzelnen Datenträgers keine Auswirkung auf eine aktive Postfachdatenbankkopie. In einer JBOD-Umgebung löst jedoch ein einzelner Datenträgerfehler ein Datenbankfailover aus.

In Exchange 2010 wurde das Skript CheckDatabaseRedundancy.ps1 eingeführt. Wie der Name schon sagt, bestand der Zweck des Skripts darin, die Redundanz replizierter Postfachdatenbanken zu überwachen, indem überprüft wird, ob mindestens zwei konfigurierte, fehlerfreie und aktuelle Kopien vorhanden sind, und einen Administrator über die Ereignisprotokollgenerierung zu benachrichtigen, wenn nur eine einzige fehlerfreie Kopie einer replizierten Datenbank vorhanden ist. In diesem Fall werden bei der Ermittlung der Redundanz sowohl aktive als auch passive Kopien gezählt.

Eine Einzelkopiebedingung ist u. a. in diesen Fällen erfüllt:

Ausfall einer aktiven Kopie, die auf eine beliebige passive Kopie repliziert werden soll.
Ausfall aller passiven Kopien, was neben den Statuswerten "FailedAndSuspended" und "Fehler" auch den Status "Fehlerfrei" umfasst, wenn die Kopie in Bezug auf Protokollkopie oder -wiedergabe im Rückstand ist. Beachten Sie, dass verzögerte Kopien nicht als rückständig betrachtet werden, wenn sie bei der Protokollwiedergabe weniger als zehn Minuten gegenüber der festgelegten Verzögerungszeit zurückliegen.
Das System kann die aktuelle Protokollgenerierung der aktiven Kopie nicht genau ermitteln.

Da es für Administratoren von höchster Wichtigkeit ist, zu wissen, wann nur noch eine einzelne fehlerfreie Kopie einer Datenbank vorliegt, wurde das Skript "CheckDatabaseRedundancy.ps1" durch eine integrierte, systemeigene Funktion ersetzt, die zum DataProtection-Integritätssatz der verwalteten Verfügbarkeit gehört.

Die systemeigene Funktion warnt Administratoren weiterhin über Ereignisprotokollbenachrichtigungen und verwendet zur Unterscheidung von Exchange 2013-Warnungen von Exchange 2010-Warnungen die folgenden Ereignis-IDs für Exchange 2013:

Ereignis 4138 (roter Alarm)
Ereignis 4139 (grüner Alarm)

In Exchange 2013 wurde die native Funktionalität verbessert, um das Ausmaß der Warnungsgeräusche zu reduzieren, die auftreten können, wenn mehrere Datenbanken auf demselben Server in eine einzige Kopierbedingung eintreten. In Exchange 2010 wurden Einzelkopierwarnungen auf Datenbankebene generiert. Daher können Warnungsstürme auftreten, wenn ein serverweites Problem vorliegt, das mehrere Datenbanken und mehrere Datenbankkopien betrifft. Da mehrere Fehler, z. B. Controller- oder Arbeitsspeicherprobleme, serverweit auftreten, war die Wahrscheinlichkeit gering, dass ein solcher Warnungssturm für jeden Servervorfall auftreten würde. In Exchange 2013 werden Warnungen jetzt auf Serverbasis generiert. Wenn sich ein Ausfall auf einen gesamten Server auswirkt und die Datenredundanz für mehrere Datenbankkopien gefährdet wird, wird jetzt eine einzelne Warnung pro Server generiert.

Automatische Konfiguration von DAG-Netzwerken

Ein DAG-Netzwerk ist eine Sammlung von Subnetzen, die entweder für Replikationsdatenverkehr oder MAPI-Datenverkehr verwendet werden. Jedes DAG-Netzwerk enthält maximal ein MAPI-Netzwerk und null oder mehr Replikationsnetzwerke. In Exchange 2010 wurden die anfänglichen DAG-Netzwerke (z. B. DAGNetwork01 und DAGNetwork02) vom System basierend auf den vom Clusterdienst aufgezählten Subnetzen erstellt. In Umgebungen, in denen mehrere Netzwerke verwendet werden und sich die Schnittstellen für ein angegebenes Netzwerk (z. B. das MAPI-Netzwerk) im selben Subnetz befanden, gab es wenig zusätzliche Konfiguration, die ein Administrator ausführen musste. In Umgebungen, in denen sich die Schnittstellen für ein angegebenes Netzwerk in mehreren Subnetzen befanden, musste der Administrator jedoch eine Aufgabe ausführen, die als Reduzieren von DAG-Netzwerken bezeichnet wird.

In Exchange 2013 ist das Reduzieren von DAG-Netzwerken nicht mehr erforderlich. Exchange 2013 verwendet immer noch die gleichen Erkennungsmechanismen, um zwischen mapi und replikationsnetzwerken zu unterscheiden, aber jetzt werden DAG-Netzwerke automatisch reduziert.

Zusätzlich werden DAG-Netzwerke ab sofort automatisch vom System verwaltet. Um DAG-Netzwerkeigenschaften im Exchange Admin Center (EAC) anzuzeigen, müssen Sie die DAG für die manuelle Netzwerksteuerung konfigurieren, indem Sie die Eigenschaften der DAG mithilfe von EAC ändern oder das Cmdlet Set-DatabaseAvailabilityGroup verwenden, um den ManualDagNetworkConfiguration-Parameter auf Truefestzulegen.

Änderungen in Bezug auf die Auswahl der besten Kopie

Die beste Kopierauswahl (Best Copy Selection, BCS) ist ein interner Algorithmusprozess zum Suchen der besten Kopie einer einzelnen Datenbank, die aktiviert werden kann, mit einer Liste möglicher Kopien für die Aktivierung, deren Integrität und status. Active Manager wählt die beste verfügbare (und entsperrte) Kopie aus, um die neue aktive Datenbankkopie zu werden, wenn die vorhandene aktive Datenbankkopie fehlschlägt oder wenn ein Administrator einen ziellosen Wechsel durchführt. In Exchange 2010 hat der BCS-Prozess mehrere Aspekte jeder Datenbankkopie ausgewertet, um die am besten zu aktivierende Kopie zu ermitteln. Hierzu gehörten:

Länge der Kopiewarteschlange
Länge der Wiedergabewarteschlange
Status der Datenbank
Inhaltsindexzustand

In Exchange 2013 führt Active Manager dieselben BCS-Prüfungen und -Vorgänge aus, um die Replikationsintegrität zu ermitteln; jetzt wird jedoch zusätzlich eine Einschränkung der absteigenden Reihenfolge von Integritätsstatuswerten verwendet. Aufgrund dieser Änderungen lautet der Name dieser Funktion jetzt BCSS (Best Copy and Server Selection).

BCSS enthält mehrere neue Integritätsprüfungen, die Teil der integrierten Komponenten für die Überwachung der verwalteten Verfügbarkeit in Exchange 2013 sind. Active Manager führt vier zusätzliche Prüfungen durch (hier in der Ausführungsreihenfolge aufgeführt):

Alle fehlerfrei: Sucht nach einem Server, auf dem eine Kopie der betroffenen Datenbank gehostet wird, auf dem alle Überwachungskomponenten in einem fehlerfreien Zustand sind.
Bis zu Normal fehlerfrei: Sucht nach einem Server, der eine Kopie der betroffenen Datenbank hosten soll, der alle Überwachungskomponenten mit normaler Priorität in einem fehlerfreien Zustand aufweist.
Alles besser als Quelle: Sucht nach einem Server, auf dem eine Kopie der betroffenen Datenbank gehostet wird, der Überwachungskomponenten in einem Zustand aufweist, der besser ist als der aktuelle Server, auf dem die betroffene Kopie gehostet wird.
Identisch mit Quelle: Sucht nach einem Server, auf dem eine Kopie der betroffenen Datenbank gehostet wird, die Überwachungskomponenten in einem Zustand aufweist, der dem aktuellen Server entspricht, auf dem die betroffene Kopie gehostet wird.

Wenn BCSS als Ergebnis eines Failovers aufgerufen wird, das von einer verwalteten Verfügbarkeitsüberwachungskomponente ausgelöst wird (z. B. über einen Failoverantworter), wird eine zusätzliche obligatorische Einschränkung erzwungen, bei der die Komponentenintegrität des Zielservers besser sein muss als der Server, auf dem das Failover stattgefunden hat. Wenn z. B. ein Fehler von Outlook Web App über einen Failoverantworter ein Failover der verwalteten Verfügbarkeit auslöst, muss BCSS einen Server auswählen, der eine Kopie der betroffenen Datenbank hostet, auf der Outlook Web App fehlerfrei ist.

DAG-Verwaltungsdienste

Das kumulative Update 2 (CU2) für die RTM-Version von Exchange 2013 beinhaltet einen neue Dienste auf Postfachservern, die Mitglieder einer DAG sind. Dieser Dienst wird Microsoft Exchange DAT-Verwaltungsdienst (MSExchangeDAGMgmt) genannt. Dieser neue Dienst beinhaltet eine interne DAG-Überwachungsfunktion, wird bereits im Microsoft Exchange-Replikationsdienst (MSExchangeRepl) ausgeführt.

DAGs ohne Administratorzugriffspunkt im Cluster

Alle DAGs mit Windows Server 2008 R2 oder Windows Server 2012 erfordern mindestens eine IP-Adresse in jedem Subnetz, das im MAPI-Netzwerk enthalten ist. Die IP-Adressen, die der DAG zugewiesen wurden, werden vom Cluster der DAG mit dem Administratorzugriffspunkt im Cluster (auch Clusternetzwerkname genannt) verwendet, um die Namensauflösung und Verbindungen mit dem Cluster (genauer gesagt, Verbindungen mit dem Clustermitglied, das der aktuelle Besitzer der Kernressourcengruppe des Clusters ist) unter Verwendung des Clusternamens zu ermöglichen. Windows Server 2012 R2 ermöglicht Ihnen, ein Failovercluster ohne Administratorzugriffspunkt zu erstellen. Windows-Failovercluster ohne Administratorzugriffspunkte weisen die folgenden Merkmale auf:

Dem Cluster ist keine IP-Adresse und daher keine IP-Adressressource in der Clusterkernressourcengruppe zugewiesen.
Dem Cluster ist kein Netzwerkname zugewiesen, und daher keine Netzwerknamenressource in der Clusterkernressourcengruppe
Der Name des Clusters ist nicht im DNS registriert und kann im Netzwerk nicht aufgelöst werden.
Ein Clusternamenobjekt (Cluster Name Object, CNO) wird in Active Directory nicht erstellt.
Der Windows-Failovercluster kann nicht mit dem Failoverclusterverwaltungstool verwaltet werden. Er muss über Windows PowerShell verwaltet werden, und die PowerShell-Cmdlets müssen für die einzelnen Cluster-Mitglieder ausgeführt werden.

Unter Windows Server 2012 R2 oder höher ermöglicht Ihnen Service Pack 1 (SP1) für Exchange 2013 und höher eine DAG ohne Administratorzugriffspunkt im Cluster zu erstellen. Sie können eine DAG ohne Administratorzugriffspunkt erstellen, indem Sie das Exchange Admin Center oder die Shell verwenden. Weitere Informationen finden Sie unter Erstellen von DAGs und Erstellen einer Datenbankverfügbarkeitsgruppe.

Freigeben über