Änderungen an Hochverfügbarkeit und Standortresilienz gegenüber früheren Versionen von Exchange Server

Exchange Server 2013 und höher werden DAGs und Postfachdatenbankkopien (zusammen mit anderen Features wie Wiederherstellung einzelner Elemente, Aufbewahrungsrichtlinien und verzögerte Datenbankkopien) verwendet, 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 seit Exchange 2010 verbessert, um Verfügbarkeit und eine weniger komplexe Verwaltung bereitzustellen und Kosten zu senken. Diese Verbesserungen umfassen:

• Reduzierung von IOPS: Dadurch können Sie größere Datenträger in Bezug auf Kapazität und IOPS so effizient wie möglich verwenden.

• Verwaltete Verfügbarkeit: Bei verwalteter Verfügbarkeit sind interne Überwachungs- und wiederherstellungsorientierte Features eng integriert, um Fehler zu verhindern, Dienste proaktiv wiederherzustellen und Serverfailover automatisch zu starten oder Administratoren zu Maßnahmen zu warnen. 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 oder höher. Der verwaltete Speicher ist in C# geschrieben und eng in den Microsoft Exchange-Replikationsdienst (MSExchangeRepl.exe) integriert, um eine höhere Verfügbarkeit durch verbesserte Resilienz zu gewährleisten.

• Unterstützung für mehrere Datenbanken pro Datenträger: Mit den Verbesserungen können Sie mehrere Datenbanken (Mischungen aus aktiven und passiven Kopien) auf demselben Datenträger unterstützen und dadurch größere Datenträger in Bezug auf Kapazität und IOPS so effizient wie möglich verwenden.

• 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: 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. Exchange bietet jetzt mehr Wiederherstellungsverhalten für lange E/A-Zeiten, ü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 erkennt, dass seitenpatching für eine verzögerte Kopie erforderlich ist, werden die Protokolle automatisch in die verzögerte Kopie wiedergegeben, um seitenpatchen zu können. Verzögerte Kopien rufen die automatische Wiedergabefunktion auch auf, wenn ein Schwellenwert bezüglich zu wenig Speicherplatz erreicht wird und wenn die verzögerte Kopie während eines bestimmten Zeitraums die einzige verfügbare Kopie ist. Darüber hinaus können verzögerte Kopien Safety Net verwenden, was die Wiederherstellung oder Aktivierung erheblich vereinfacht.

• Verbesserungen bei Warnungen für einzelnes Kopieren: Die in Exchange 2010 eingeführte Warnung für einzelnes 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

In Exchange 2010 weisen passive Datenbankkopien eine geringe Prüfpunkttiefe auf, die für ein schnelles Failover erforderlich ist. Darüber hinaus führt die passive Kopie aggressive Vorablesevorgänge von Daten durch, um mit einer Prüfpunkttiefe von 5 Megabyte (MB) Schritt zu halten. Aufgrund der Verwendung einer geringen Prüfpunkttiefe und der Durchführung dieser aggressiven Vorlesevorgänge entspricht der IOPS-Wert für eine passive Datenbankkopie den IOPS für eine aktive Kopie in Exchange 2010.

In Exchange 2013 oder höher kann das System ein schnelles Failover bereitstellen und gleichzeitig eine hohe Prüfpunkttiefe für die passive Kopie (100 MB) verwenden. Aufgrund der 100-MB-Prüfpunkttiefe für passive Kopien sind aggressive Prereadvorgänge nicht länger nötig. Aufgrund der Erhöhung der Prüfpunkttiefe und der Aufhebung der Optimierung der aggressiven Vorablesevorgänge sind IOPS für eine passive Kopie etwa 50 Prozent der aktiven Kopier-IOPS.

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. Ab Exchange 2013 wurde die ESE-Protokollierung neu geschrieben, sodass der Cache während des Übergangs von passiv zu aktiv beibehalten wird. 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 jetzt eine deutliche Verringerung der IOPS gegenüber Exchange 2010.

Verwaltete Verfügbarkeit

Verwaltete Verfügbarkeit ist die Integration der integrierten, aktiven Überwachung und der Exchange-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. Die verwaltete Verfügbarkeit ist eine interne Infrastruktur, die in den Clientzugriffsdiensten (Front-End) und Back-End-Diensten auf Postfachservern bereitgestellt wird. Die verwaltete Verfügbarkeit umfasst drei asynchrone Hauptkomponenten, die ständig arbeiten:

1. 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.

2. 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.

3. 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. Zum Beispiel:

1. Starten Sie den Anwendungspool neu.

2. Starten Sie den Dienst neu.

3. Starten Sie den Server neu.

4. Schalten Sie den Server offline, 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 Health Manager-Arbeitsprozess (MSExchangeHMWorker.exe):Dies ist der Arbeitsprozess, der für die Ausführung der Laufzeittasks verantwortlich ist.

Die verwaltete Verfügbarkeit verwendet persistenten Speicher, um ihre 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

Exchange 2010 und frühere Versionen unterstützen das Ausführen einer einzelnen Instanz des Informationsspeicherprozesses (Store.exe) für die Postfachserverrolle. Diese einzelne Speicherinstanz hostet alle Datenbanken auf diesem Server: aktive, passive, verzögerte und wiederhergestellte. In diesen 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 Store-Instanz ist die fehlende Prozessorskalierbarkeit mit der Extensible Storage Engine (ESE). ESE kann gut auf 8 bis 12 Prozessorkerne skaliert werden, aber darüber hinaus führen Prozessorübergreifende Kommunikation und Cachesynchronisierungsprobleme zu einer negativen Leistung. Angesichts der heutigen Server mit mehr als 16 Kernsystemen würde dies die administrative Herausforderung darstellen, die Affinität von 8 bis 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 Grenzwerte wurde Store.exe in Exchange 2013 entfernt und durch den verwalteten Speicher ersetzt.

Weitere Informationen finden Sie unter Verwalteter Speicher.

Mehrere Datenbanken pro Volume

Obwohl die Speicherverbesserungen in Exchange in erster Linie für eine Reihe von Datenträgerkonfigurationen (JBOD) konzipiert 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, die Speicherkapazität zu erhöhen, setzt sich fort. Die Exchange Best Practices-Richtlinie für die maximale Datenbankgröße (2 Terabytes) auf einem Laufwerk mit 8 Terabyte bedeutet beispielsweise, dass Sie mehr als 5 Terabyte Speicherplatz auf dem Datenträger verschwenden würden.

Eine Lösung wäre, die Datenbanken zu vergrößern, aber dies hemmt die Verwaltbarkeit, da dies zu langen Wiederaufnahmenzeiten (einschließlich betriebsbedingter nicht zu verwaltbarer Zeit für die Erneuteinsetzung) und zu einer kompromittierten Zuverlässigkeit beim Kopieren dieser Datenmenge über das Netzwerk führen kann.

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.

Exchange 2013 und höher wurde optimiert, um große Datenträger (8 Terabyte) in einer JBOD-Konfiguration effizienter zu verwenden. Mit mehreren Datenbanken pro Datenträger können Sie jetzt datenträgergleiche Datenträger verwenden, die mehrere Datenbankkopien speichern, einschließlich verzögerter Kopien. 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.

Konfiguration, die mehrere Datenbanken pro Volume verwendet

Die Konfiguration im Diagramm bietet einen symmetrischen Entwurf. 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.

In der Konfiguration im Diagramm 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. Beispiel:

• Die aktive Kopie weist den Wert 1 für die Aktivierungseinstellung auf.

• Die erste passive Kopie hat den Aktivierungspräferenzwert 2.

• Die zweite passive Kopie hat den Wert für die Aktivierungseinstellung 3.

• Die verzögerte Kopie hat den Wert für die Aktivierungseinstellung 4.

Zusätzlich zu einer besseren Verteilung der Benutzer auf die vorhandenen Volumes besteht ein weiterer Vorteil der Verwendung mehrerer Datenbanken pro Datenträger darin, dass die Zeit zum Wiederherstellen des Schutzes von Daten bei Fehlern, die ein erneutes Aussetzen erfordern (z. B. Datenträgerfehler), reduziert wird.

Je größer eine Datenbank ist, desto mehr Zeit wird für das erneute Seeding der Datenbank benötigt. Beispielsweise kann das erneute Seeding einer 2-TB-Datenbank 23 Stunden in Anspruch nehmen, bei einer 8-TB-Datenbank kann das erneute Seeding 93 Stunden dauern (beinahe 4 Tage). 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.

Durch die Aufteilung des Volumes in mehrere Datenbankkopien und durch die Speicherung der aktiven Kopie der passiven Datenbanken auf einem bestimmten Volume auf separaten DAG-Mitgliedern ist das System beim erneuten Seeding des Datenträgers nicht an eine einzelne Quelle gebunden. Wenn ein fehlerhafter Datenträger ausgetauscht wird, kann das erneute Seeding über mehrere Quellen erfolgen. Auf diese Weise kann das System das erneute Seeding und die Wiederherstellung des Datenschutzes für diese Datenbanken innerhalb einer deutlich kürzeren Zeit abschließen.

Wenn Sie mehrere Datenbanken pro Volume verwenden, empfiehlt es sich, die folgenden bewährten Methoden und Anforderungen zu befolgen:

• 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 Einsen (auch als AutoReseed bezeichnet) ist der Ersatz für eine normalerweise vom Administrator gesteuerte Aktion als Reaktion auf einen Datenträgerfehler, ein Datenbankbeschädigungsereignis oder ein anderes Problem, bei dem ein erneutes Senden einer Datenbankkopie erforderlich ist. 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 ermöglicht dem System die Wiederherstellung nach Fehlern, die sich auf Resilienz oder Redundanz auswirken. Zusätzlich zu den in Exchange 2010 eingeführten Fehlerprüfungsverhaltens bietet Exchange jetzt zusätzliche Wiederherstellungsverhalten für lange E/A-Zeiten, einen übermäßigen Arbeitsspeicherverbrauch 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. In der folgenden Tabelle sind Features aufgeführt, die Features für die Erkennung und Wiederherstellung von hängen gebliebenen E/A-Vorgängen bieten, die eine verbesserte Resilienz bieten.

Exchange 2013 und höher verbessert die Resilienz von Servern und Speicher, indem Verhaltensweisen für andere schwerwiegende Bedingungen eingeschlossen werden. Diese Bedingungen und Verhaltensweisen werden in der folgenden Tabelle beschrieben.

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. Safety Net wurde in Exchange 2013 eingeführt, um das Exchange 2010-Feature zu ersetzen, das als Transportdumpster bezeichnet wird. Safety Net ähnelt dem Transportdumpster, da 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 bei Schattenredundanz keine weitere Kopie der übermittelten Nachricht in einer Schattenwarteschlange gespeichert werden, während sie darauf wartet, dass die zugestellte 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 schattenredundanz die Nachricht bei Bedarf aus Safety Net erneut zugestellt werden kann.

Mit 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 Sie auf eine Situation stoßen, in der Sie Ihre verzögerte Kopie verwenden müssen, haben Sie folgende Möglichkeiten:

1. Anhalten der Replikation darauf.

2. Kopieren Sie sie zweimal (um die verzögerte Natur der Datenbank zu erhalten und bei Bedarf eine zusätzliche Kopie zu erstellen).

3. Kopieren Sie eine Kopie, und verwerfen Sie alle Protokolldateien mit Ausnahme der Protokolldateien im erforderlichen Bereich.

4. 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 für mehr als 24 Stunden weniger als drei fehlerfreie Kopien (nur aktiv oder passiv; verzögerte Datenbankkopien werden nicht gezählt) zur Verfügung stehen

In Exchange 2010 stand das Seitenpatching nicht für verzögerte Kopien zur Verfügung. In Exchange 2013 oder höher ist das Patchen von Seiten für verzögerte Kopien über dieses automatische Wiedergabefeature verfügbar. 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 die automatische Wiedergabefunktion auch auf, wenn ein Schwellenwert bezüglich zu wenig Speicherplatz erreicht wird und wenn die verzögerte Kopie während eines bestimmten Zeitraums die einzige verfügbare Kopie ist.

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 vier Kopien (drei hochverfügbare Kopien und eine 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 Sicherstellung, dass Ihre Server zuverlässig funktionieren und ihre Postfachdatenbankkopien fehlerfrei sind, ist das hauptziel der täglichen Exchange-Messagingvorgänge. Sie müssen eine aktive Überwachung von Hardware, Windows-Betriebssystem und Exchange-Diensten sicherstellen.

In einer Exchange-Postfachresilienzumgebung ist es jedoch wichtig, dass Sie die Integrität und den Status der DAG und ihrer Postfachdatenbankkopien ü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, die kein Redundant Array of Independent Disks (RAID) verwenden und stattdessen JBOD-Konfigurationen bereitstellen. In einer RAID-Umgebung hat der Ausfall eines einzelnen Datenträgers keine Auswirkung auf eine aktive Postfachdatenbankkopie. In einer JBOD-Umgebung führt der Ausfall eines einzelnen Datenträgers jedoch zu einem Datenbankfailover.

Das CheckDatabaseRedundancy.ps1 Skript wurde in Exchange 2010 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. Verzögerte Kopien werden nicht als hinterher betrachtet, wenn sie ihre Protokolle innerhalb von 10 Minuten bis zu ihrem Verzögerungszeitraum wiedergeben.

• 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 Funktionalität warnt Administratoren weiterhin über Ereignisprotokollbenachrichtigungen, und um Exchange 2013- oder höher-Warnungen von Exchange 2010 zu unterscheiden, verwendet Exchange jetzt die folgenden Ereignis-IDs:

• Ereignis 4138 (roter Alarm)

• Ereignis 4139 (grüner Alarm)

Die native Funktionalität wurde verbessert, um Warnungsgeräusche zu reduzieren, die auftreten, wenn mehrere Datenbanken auf demselben Server in eine einzige Kopierbedingung eintreten. In Exchange 2010 wurden Einzelkopierwarnungen auf Datenbankebene generiert. Daher kann ein serverweites Problem, das mehrere Datenbanken und mehrere Datenbankkopien betrifft, Warnungsstürme verursachen. Da mehrere Fehler serverweit auftreten (z. B. Controller- oder Arbeitsspeicherprobleme), bestand eine gute Chance, dass für jeden Servervorfall ein Warnungssturm auftritt.

Warnungen werden jetzt auf Serverbasis generiert. Wenn sich ein Ausfall auf einen gesamten Server auswirkt und die Datenredundanz für mehrere Datenbankkopien gefährdet wird, wird 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 Subnetzen erstellt, die vom Clusterdienst aufgelistet wurden. Wenn Sie über mehrere Netzwerke verfügten und sich die Schnittstellen für ein angegebenes Netzwerk (z. B. das MAPI-Netzwerk) im selben Subnetz befanden, war nur wenig zusätzliche Konfiguration erforderlich. Wenn sich die Schnittstellen für ein angegebenes Netzwerk jedoch in mehreren Subnetzen befanden, mussten Sie eine Aufgabe ausführen, die als Reduzieren von DAG-Netzwerken bezeichnet wird.

In Exchange 2013 oder höher ist das Reduzieren von DAG-Netzwerken nicht mehr erforderlich. Exchange 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. Zum Anzeigen von DAG-Netzwerkeigenschaften im Exchange Admin Center (EAC) 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 Parameter ManualDagNetworkConfiguration auf $truefestzulegen.

Änderungen in Bezug auf die Auswahl der besten Kopie

Die beste Kopierauswahl (Best Copy Selection, BCS) ist ein interner Algorithmusprozess, mit dem die beste Kopie einer einzelnen Datenbank gesucht wird, die aktiviert werden kann, und zwar unter Berücksichtigung einer Liste möglicher Kopien für die Aktivierung sowie 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 oder höher führt Active Manager die gleichen BCS-Überprüfungen und -Phasen aus, um die Replikationsintegrität zu bestimmen, umfasst aber jetzt auch die Verwendung einer Einschränkung der abnehmenden Reihenfolge der Integritätszustände. Aufgrund dieser Änderungen lautet der Name dieser Funktion jetzt BCSS (Best Copy and Server Selection).

BCSS enthält mehrere neue Integritätsprüfungen, die jetzt Teil der integrierten Komponenten für die Überwachung der verwalteten Verfügbarkeit in Exchange sind. Active Manager führt vier zusätzliche Überprüfungen durch (die in der Reihenfolge aufgeführt sind, in der sie ausgeführt werden):

1. Alle fehlerfrei: Sucht nach einem Server, auf dem eine Kopie der betroffenen Datenbank gehostet wird, auf dem alle Überwachungskomponenten in einem fehlerfreien Zustand sind.

2. 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.

3. 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.

4. 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 Failover responder), 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 beispielsweise ein Fehler von Outlook im Web (früher als Outlook Web App bezeichnet) ein Failover der verwalteten Verfügbarkeit über einen Failover-Responder auslöst, muss BCSS einen Server auswählen, der eine Kopie der betroffenen Datenbank hostet, auf der Outlook im Web fehlerfrei ist.

DAG-Verwaltungsdienste

Exchange 2013 CU2 oder höher enthält den Microsoft Exchange DAG-Verwaltungsdienst (MSExchangeDAGMgmt). Dieser Dienst enthält die interne DAG-Überwachungsfunktion, die sich zuvor im Microsoft Exchange-Replikationsdienst (MSExchangeRepl) befand.

DAGs ohne Administratorzugriffspunkt im Cluster

Alle DAGs auf Exchange-Servern, auf denen Windows Server 2008 R2 oder Windows Server 2012 ausgeführt werden, 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 oder höher können Sie einen Failovercluster ohne Administratorzugriffspunkt erstellen. Windows-Failovercluster ohne Administratorzugriffspunkte weisen die folgenden Merkmale auf:

• Dem Cluster ist keine IP-Adresse zugewiesen, sodass keine IP-Adressressource in der Clusterkernressourcengruppe vorhanden ist.

• Dem Cluster ist kein Netzwerkname zugewiesen, sodass keine Netzwerknamenressource in der Clusterkernressourcengruppe vorhanden ist.

• Der Name des Clusters ist nicht im DNS registriert, und der Clustername kann im Netzwerk nicht aufgelöst werden.

• Ein Clusternamenobjekt (Cluster Name Object, CNO) wird in Active Directory nicht erstellt.

• Sie können den Windows-Failovercluster nicht mit dem Failoverclusterverwaltungstool verwalten. Stattdessen müssen Sie Windows PowerShell verwenden und die PowerShell-Cmdlets für die einzelnen Clustermitglieder ausführen.

Mit Exchange 2013 SP1 oder höher unter Exchange auf Windows Server 2012 R2 oder höher können Sie eine DAG ohne Clusteradministratorzugriffspunkt erstellen. Weitere Informationen finden Sie unter Erstellen von DAGs und Erstellen einer Datenbankverfügbarkeitsgruppe.