(0) exportieren Drucken
Alle erweitern

Hohe Verfügbarkeit und Ausfallsicherheit von Standorten

 

Gilt für: Exchange Server 2013

Letztes Änderungsdatum des Themas: 2014-06-19

Postfachdatenbanken und die darin enthaltenen Daten sind eine der wichtigsten (wenn nicht die wichtigsten) Komponenten einer jeden Exchange-Organisation. In Microsoft Exchange Server 2013 können Sie Postfachdatenbanken und die darin enthaltenen Daten schützen, indem Sie Ihre Postfachdatenbanken für hohe Verfügbarkeit und Ausfallsicherheit für Standorte konfigurieren. Exchange 2013 senkt die Kosten und Komplexität für die Bereitstellung einer hochverfügbaren und ausfallsicheren Messaginglösung und bietet gleichzeitig eine höhere End-to-End-Verfügbarkeit sowie Unterstützung für große Postfächer. Exchange 2013 baut auf den systemeigenen Replikationsfunktionen und der Architektur für hohe Verfügbarkeit von Exchange 2010 auf, wodurch Kunden beliebiger Größe und aus allen Sparten die Möglichkeit erhalten, einen Dienst zur Aufrechterhaltung des Messagings im Unternehmen kostengünstig bereitzustellen.

Möchten Sie wissen, welche Verwaltungsaufgaben es im Zusammenhang mit hoher Verfügbarkeit und Ausfallsicherheit gibt? Weitere Informationen finden Sie unter Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

Inhalt

Wichtige Terminologie

Datenbankverfügbarkeitsgruppen (DAGs)

Postfachdatenbankkopien

Active Manager

Änderungen in Bezug auf die Hochverfügbarkeit gegenüber Exchange 2010

Ausfallsicherheit von Standorten

API für die Drittanbieterreplikation

Dokumentation zu Hochverfügbarkeit und Ausfallsicherheit für Standorte

Nachfolgend werden die wichtigsten Begriffe zum Verständnis von Hochverfügbarkeit und Ausfallsicherheit von Standorten erläutert:

Active Manager

Eine interne Exchange-Komponente, die im Microsoft Exchange-Replikationsdienst ausgeführt wird. Sie überwacht die Umgebung auf Ausfälle und führt Korrekturmaßnahmen aus, indem ein Failover innerhalb einer Database Availability Group (DAG) durchgeführt wird.

AutoDatabaseMountDial

Eine Eigenschafteneinstellung eines Postfachservers, die basierend auf der Anzahl von fehlenden Protokolldateien für die einzubindende Kopie festlegt, ob eine passive Datenbankkopie automatisch als neue aktive Kopie eingebunden wird.

Fortlaufende Replikation – Blockmodus

Im Blockmodus wird beim Schreiben jeder Aktualisierung in den aktiven Protokollpuffer der aktiven Datenbankkopie diese auch in einen Protokollpuffer aller passiven Postfachkopien übertragen. Sobald der Protokollpuffer voll ist, führt jede Datenbankkopie eine Überprüfung durch und erstellt dann die nächste Protokolldatei in der Generierungssequenz.

Fortlaufende Replikation – Dateimodus

Im Dateimodus werden geschlossene Transaktionsprotokolldateien von der aktiven Datenbankkopie per Pushvorgang in eine oder mehrere passive Datenbankkopien kopiert.

Database Availability Group (DAG)

Eine Gruppe von bis zu 16 Exchange 2013-Postfachservern, die eine Gruppe replizierter Datenbanken hostet.

Datenbankmobilität

Die Fähigkeit, eine Exchange 2013-Postfachdatenbank zu replizieren und auf anderen Exchange 2013-Postfachservern einzubinden.

Datencenter

In der Regel bezieht sich dieser Begriff auf einen Active Directory-Standort, es kann jedoch auch ein physischer Standort gemeint sein. Im Rahmen dieser Dokumentation entspricht ein Datencenter einem Active Directory-Standort.

Datencenter-Aktivierungsmodus

Eine Eigenschaft der DAG-Einstellung, die bei Aktivierung erzwingt, dass der Microsoft Exchange-Replikationsdienst Berechtigungen zum Einbinden von Datenbanken beim Start erwirbt.

Notfallwiederherstellung

Jeder Prozess zur manuellen Wiederherstellung nach einem Ausfall. Dies kann ein Ausfall sein, der ein einzelnes Element betrifft, oder ein Ausfall, der sich auf einen gesamten physischen Standort auswirkt.

Exchange-API für die Drittanbieterreplikation

Eine mit Exchange bereitgestellte API, welche die Verwendung von Drittanbieterprodukten für die synchrone Replikation von DAGs anstelle einer fortlaufenden Replikation ermöglicht.

Hohe Verfügbarkeit

Eine Lösung, die Dienstverfügbarkeit, Datenverfügbarkeit und eine automatische Wiederherstellung nach Ausfällen sicherstellt, die sich auf den Dienst oder Daten auswirken (z. B. Netzwerk-, Speicher- oder Serverausfall).

Inkrementelle Bereitstellung

Die Fähigkeit zur Bereitstellung von hoher Verfügbarkeit und Ausfallsicherheit für Standorte, nachdem Exchange 2013 installiert wurde.

Verzögerte Postfachdatenbankkopie

Eine passive Postfachdatenbankkopie, für die eine Wiedergabeverzögerung größer null festgelegt ist.

Postfachdatenbankkopie

Eine Postfachdatenbank (EDB-Datei und Protokolle), die entweder aktiv oder passiv ist.

Ausfallsicherheit von Postfächern

Der Name einer einheitlichen Lösung für hohe Verfügbarkeit und Ausfallsicherheit für Standorte in Exchange 2013.

Verwaltete Verfügbarkeit

Ein Satz interner Prozesse bestehend aus Tests, Monitoren und Antwortdiensten, die Überwachung und Hochverfügbarkeit für alle Serverrollen und sämtliche Protokolle bereitstellen.

*over (englisch ausgesprochen, "Star over")

Abkürzung für Switchover und Failover. Ein Switchover ist die manuelle Aktivierung einer oder mehrerer Datenbankkopien. Ein Failover ist die automatische Aktivierung einer oder mehrerer Datenbankkopien nach einem Ausfall.

Sicherheitsnetz

Dieses vormals als Transportdumpster bezeichnete Feature ist Bestandteil des Transportdiensts und speichert eine Kopie aller Nachrichten für X Tage. Die Standardeinstellung beträgt 2 Tage.

Shadow-Redundanz

Ein Transportserverfeature, das Redundanz für Nachrichten bietet, während diese übertragen werden.

Ausfallsicherheit von Standorten

Eine Konfiguration, mit der die Messaginginfrastruktur auf mehrere Active Directory-Standorte ausgeweitet wird, um bei einem Ausfall einer der Standorte einen unterbrechungsfreien Betrieb für das Messagingsystem zu gewährleisten.

Wichtige Terminologie

Eine Database Availability Group (DAG) ist die Basiskomponente des Systems für hohe Verfügbarkeit und Ausfallsicherheit für Standorte in Exchange 2013. Eine DAG besteht aus bis zu 16 Postfachservern, die eine Gruppe von Datenbanken hosten und eine automatische Wiederherstellung auf Datenbankebene nach Ausfällen bieten, die einzelne Datenbanken, Netzwerke oder Server betreffen. Jeder Server in einer DAG kann als Host für eine Kopie einer Postfachdatenbank eines beliebigen anderen Servers in der DAG fungieren. Wenn ein Server einer DAG hinzugefügt wird, wird dieser mit den anderen Servern in der DAG eingesetzt, um eine automatische Wiederherstellung nach Fehlern zu bieten, die Postfachdatenbanken betreffen, z. B. Datenträger- oder Serverfehler. Weitere Informationen zu Database Availability Groups finden Sie unter Database Availability Groups (DAGs).

Wichtige Terminologie

Die erstmals in Exchange 2010 eingeführten Funktionen zur Bereitstellung von Hochverfügbarkeit und Ausfallsicherheit für Standorte werden in Exchange 2013 dazu verwendet, Datenbankkopien zu erstellen und zu verwalten. Exchange 2013 nutzt außerdem das Konzept der Datenbankmobilität, die von Exchange verwaltete Failoverfunktion auf Datenbankebene.

Im Rahmen der Datenbankmobilität werden Datenbanken von Servern getrennt und Unterstützung für bis zu 16 Kopien einer einzelnen Datenbank hinzugefügt. Zudem wird eine systemeigene Umgebung für das Erstellen von Kopien einer Datenbank bereitgestellt.

Das Festlegen einer Datenbankkopie als aktive Postfachdatenbank wird als Switchover bezeichnet. Wenn ein Fehler auftritt, der eine Datenbank oder den Zugriff auf eine Datenbank beeinträchtigt, und eine neue Datenbank als aktive Kopie festgelegt wird, wird dieser Vorgang als Failover bezeichnet. Dieser Vorgang bezieht sich auch auf einen Serverausfall, bei dem ein oder mehrere Server die Datenbank online schalten, die sich zuvor auf dem ausgefallenen Server befunden hat. Wenn entweder ein Switchover oder Failover erfolgt, wird dieses Ereignis von den Exchange 2013-Servern sofort erkannt, und der Client- und Messagingdatenverkehr wird an die neue aktive Datenbank umgeleitet.

Wenn beispielsweise eine aktive Datenbank in einer Database Availability Group aufgrund eines Fehlers der zugrunde liegenden Speicherkomponente ausfällt, führt Active Manager eine automatische Wiederherstellung durch, indem ein Failover auf eine Datenbankkopie auf einem anderen Postfachserver in der Database Availability Group durchgeführt wird. In Exchange 2013 umfasst die verwaltete Verfügbarkeit neue Verhaltensweisen zur Wiederherstellung nach einem Verlust des Protokollzugriffs auf eine Datenbank. Hierzu gehören das Recycling von Anwendungsprozesspools, das Neustarten von Diensten und Servern sowie das Einleiten eines Datenbankfailovers.

Weitere Informationen zu Postfachdatenbankkopien finden Sie unter Postfachdatenbankkopien.

Wichtige Terminologie

Exchange 2013 nutzt die in Exchange 2010 eingeführte Active Manager-Komponente zum Verwalten der Integrität von Datenbanken und Datenbankkopien, für Status, fortlaufende Replikation und weitere Aspekte in Bezug auf die Hochverfügbarkeit von Postfachservern. Weitere Informationen zu Active Manager finden Sie in Active Manager.

Wichtige Terminologie

Exchange 2013 verwendet DAGs, Postfachdatenbankkopien und weitere Funktionen, wie z. B. die Wiederherstellung einzelner Elemente, Aufbewahrungsrichtlinien und verzögerte Datenbankkopien, um Hochverfügbarkeit, Ausfallsicherheit für Standorte und einen systemeigenen Exchange-Datenschutz bereitzustellen. Sowohl die Hochverfügbarkeitsplattform als auch der Exchange-Informationsspeicher und das ESE-Modul (Extensible Storage Engine) wurden erweitert und bieten mehr Verfügbarkeit, eine vereinfachte Verwaltung und die Möglichkeit zur Kosteneinsparung. Diese Verbesserungen umfassen:

  • Verringerung der IOPS gegenüber Exchange 2010   Dies ermöglicht eine effizientere Nutzung großer Datenträger in Bezug auf Kapazität und IOPS.

  • 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   Als verwalteter Speicher werden die neu gestalteten Informationsspeicherprozesse in Exchange 2013 bezeichnet. 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 bietet Verbesserungen, die Ihnen die Unterstützung mehrerer Datenbanken (eine Kombination aus aktiven und passiven Kopien) auf demselben Datenträger ermöglichen, wodurch größere Datenträger in Bezug auf Kapazität und E/A pro Sekunde effizienter genutzt werden können.

  • Automatisches erneutes Seeding   Ermöglicht das schnelle Wiederherstellen von Datenbankredundanz nach einem Datenträgerausfall. 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. Zusätzlich zur Fehlerprüfung von Exchange 2010 bietet Exchange 2013 weitere Wiederherstellungsfunktionen bei langen E/A-Zeiten, übermäßige Speicherbelegungen durch "MSExchangeRepl.exe" und für gravierende Fälle, bei denen das System sich in einem so schlechten Zustand befindet, dass keine Threads geplant werden können.

  • Verbesserungen in Bezug auf verzögerte Kopien   Verzögerte Kopien können sich mithilfe der automatischen Protokollwiedergabe jetzt bis zu einem gewissen Grad selbst verwalten. Verzögerte Kopien geben in verschiedenen Situationen automatisch Protokolldateien wieder, wie zum Beispiel beim Seitenpatching und in Szenarien mit 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 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 nutzen verzögerte Kopien die Funktion "Sicherheitsnetz", mit der die Wiederherstellung oder Aktivierung wesentlich vereinfacht wird.

  • Verbesserte Warnung zu einzelnen Kopien   Die in Exchange 2010 eingeführte Warnung zu einzelnen Kopien wird nicht länger als separat geplantes Skript zur Verfügung gestellt. Es wurde in die Systemkomponenten für verwaltete Verfügbarkeit integriert und ist jetzt eine systemeigene Funktion von Exchange.

  • Automatische Konfiguration von DAG-Netzwerken   DAG-Netzwerke können basierend auf Konfigurationseinstellungen automatisch vom System konfiguriert werden. DAGs bieten nicht nur manuelle Konfigurationsoptionen, sondern können auch zwischen MAPI- und Replikationsnetzwerken unterscheiden und DAG-Netzwerke automatisch konfigurieren.

In Exchange 2010 weisen passive Datenbankkopien eine sehr 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. Als Ergebnis einer geringen Prüfpunkttiefe und der Durchführung von aggressiven Prereadvorgängen entsprachen die IOPS für eine passive Datenbankkopie in Exchange 2010 den IOPS einer aktiven Kopie.

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). Aufgrund der 100-MB-Prüfpunkttiefe für passive Kopien sind aggressive Prereadvorgänge nicht länger nötig. 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 Verringerung der IOPS um 50 Prozent.

Die verwaltete Verfügbarkeit kombiniert vordefinierte Funktionen für die aktive Überwachung mit der Hochverfügbarkeitsplattform von Exchange 2013. Mit der verwalteten Verfügbarkeit kann das System basierend auf der Dienstintegrität entscheiden, wann ein Datenbankfailover durchgeführt werden sollte. Die verwaltete Verfügbarkeit ist eine interne Infrastruktur, die in den Clientzugriffs- und Postfachserverrollen von Exchange 2013 bereitgestellt wird. Sie umfasst drei asynchrone Hauptkomponenten, die kontinuierlich arbeiten. Die erste Komponente ist das Prüfmodul, das Messungen auf dem Server vornimmt und Daten sammelt. Die Ergebnisse dieser Messungen fließen in die zweite Komponente ein, den Monitor. Der Monitor umfasst die vollständige, vom System verwendete Geschäftslogik zur Definition des fehlerfreien Zustands von gesammelten Daten. Ähnlich wie bei einem Modul zur Mustererkennung achtet der Monitor auf die zahlreichen verschiedenen Muster aller gesammelten Messungen. Anschließend wird entschieden, ob eine Komponente als fehlerfrei betrachtet wird. Schließlich gibt es das Respondermodul, das für Wiederherstellungsaktionen verantwortlich ist. Wenn eine Komponente fehlerhaft ist, besteht die erste Aktion in dem Versuch, diese Komponente wiederherzustellen. Dies kann mehrstufige Wiederherstellungsaktionen umfassen. Der erste Versuch kann z. B. darin bestehen, dass der Anwendungspool neu gestartet wird, während der zweite Versuch den Neustart des Diensts und der dritte Versuch den Neustart des Servers umfasst. Ein nachfolgender Versuch könnte darin bestehen, den Server offline zu nehmen, damit kein Datenverkehr mehr angenommen wird. Wenn die Wiederherstellungsaktionen keinen Erfolg zeigen, eskaliert das System das Problem per Ereignisprotokollbenachrichtigung an einen Benutzer.

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

  • Exchange-Integritätsdienst (MSExchangeHMHost.exe)   Dies ist ein Controllerprozess, der zur Verwaltung von Arbeitsprozessen verwendet wird. Mit diesem Prozess wird der Arbeitsprozess nach Bedarf erstellt, ausgeführt, gestartet und angehalten. Dieser Prozess wird auch zur Wiederherstellung des Arbeitsprozesses verwendet, falls dieser ausfällt. So soll verhindert werden, dass der Arbeitsprozess zu einer einzelnen Fehlerquelle wird.

  • Arbeitsprozess des Exchange-Integritätsdiensts (MSExchangeHMWorker.exe)   Dies ist der Arbeitsprozess, der für die Ausführung der Laufzeittasks zuständig 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 Überwachen von Database Availability Groups.

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 hin zu steigenden Speicherkapazitäten setzt sich fort: Bald werden Laufwerke mit 8 TB zur Verfügung stehen. Bei Verwendung von 8-TB-Laufwerken im Einklang mit den empfohlenen Richtlinien zur maximalen Exchange-Datenbankgröße (2 TB) würden mehr als 5 TB an Speicherplatz vergeudet. Eine Lösung wäre die Vergrößerung der Datenbanken. Dadurch würde jedoch die Verwaltbarkeit eingeschränkt, da sich die Ausführungszeiten für das erneute Seeding erheblich verlängern würden – bis hin zur Nichtverwaltbarkeit bei Seedingvorgängen. Auch die Zuverlässigkeit beim Kopieren derartiger Datenmengen über das Netzwerk würde beeinträchtigt.

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.

Konfiguration, die mehrere Datenbanken pro Volume verwendet

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. Wenn beispielsweise die Aktivierungseinstellung für die aktive Kopie den Wert 1 aufweist, erhält die erste passive Kopie eine Aktivierungseinstellung mit dem Wert 2, die zweite passive Kopie den Wert 3, und die verzögerte Kopie den Wert 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. 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.

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

  • Eine einzelne logische Datenträgerpartition pro physischem Datenträger muss verwendet werden. Erstellen Sie nicht mehrere Partitionen auf dem Datenträger. Jede Datenbankkopie und die zugehörigen Begleitdateien (wie 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.

Das automatische erneute Seeding, auch AutoReseed genannt, ist ein Feature zur Ersetzung der Aufgaben, die – als Reaktion auf einen Datenträgerfehler, eine Datenbankbeschädigung oder andere Probleme, die ein erneutes Seeding einer Datenbankkopie erforderlich machen – normalerweise von einem Administrator ausgeführt werden. Die AutoReseed-Funktion ist für die automatische Wiederherstellung der Datenbankredundanz nach einem Datenträgerfehler konzipiert. Hierbei wird auf Ersatzdatenträger zurückgegriffen, die im System bereitgestellt wurden.

In einer AutoReseed-Konfiguration (mit automatischem erneuten Seeding) wird eine standardisierte Speicherstruktur verwendet, und der Administrator bestimmt den Startpunkt. Die AutoReseed-Funktion sorgt nach dem Ausfall eines Datenträgers für eine schnellstmögliche Wiederherstellung der Redundanz. Hierbei werden Sätze aus Volumes (Ersatzvolumes eingeschlossen) und Datenbanken mithilfe von Bereitstellungspunkten vorab zugeordnet. Bei Auftreten eines Datenträgerfehlers, durch den der Datenträger nicht länger für das Betriebssystem zur Verfügung steht oder nicht mehr beschreibbar ist, wird ein Ersatzvolume durch das System zugewiesen, und für die betroffenen Datenbanken wird automatisch ein erneutes Seeding durchgeführt. AutoReseed verwendet den folgenden Prozess:

  1. Der Microsoft Exchange-Replikationsdienst prüft regelmäßig auf Kopien mit dem Status "FailedAndSuspended".

  2. Wird eine Kopie mit diesem Status ermittelt, werden einige erforderliche Prüfungen durchgeführt. Beispielsweise wird überprüft, ob nur eine Kopie vorliegt, ob Ersatzdatenträger verfügbar sind, und es wird sichergestellt, dass die automatische Ausführung eines erneuten Seedings im System möglich ist.

  3. Wenn die erforderlichen Prüfungen erfolgreich waren, weist der Microsoft Exchange-Replikationsdienst einen Ersatzdatenträger zu.

  4. Im nächsten Schritt wird das erneute Seeding ausgeführt.

  5. Nach Abschluss des Seedings überprüft der Microsoft Exchange-Replikationsdienst, ob die neu eingespielte Kopie sich in einem fehlerfreien Zustand befindet.

Wenn es sich bei dem Fehler um einen Datenträgerausfall handelt, ist an diesem Punkt das manuelle Eingreifen eines Bedieners oder Administrators erforderlich, um den ausgefallenen Datenträger zu entfernen und zu ersetzen, um den Datenträger zu formatieren, zu initialisieren und erneut als Ersatzdatenträger zu konfigurieren.

Die AutoReseed-Konfiguration wird über drei Eigenschaften der DAG konfiguriert. Zwei der Eigenschaften beziehen sich auf die zwei in Verwendung befindlichen Bereitstellungspunkte. Exchange 2013 nutzt die Tatsache, dass Windows Server mehrere Bereitstellungspunkte pro Volume unterstützt. Die Eigenschaft AutoDagVolumesRootFolderPath bezieht sich auf den Bereitstellungspunkt, der alle verfügbaren Volumes enthält. Hierzu zählen Volumes, die Datenbanken hosten, sowie Ersatzvolumes. Die Eigenschaft AutoDagDatabasesRootFolderPath bezieht sich auf den Bereitstellungspunkt, der die Datenbanken umfasst. Eine dritte DAG-Eigenschaft, AutoDagDatabaseCopiesPerVolume, wird zum Konfigurieren der Anzahl von Datenbankkopien pro Volume verwendet.

Die nachstehende Abbildung zeigt eine AutoReseed-Beispielkonfiguration.

Beispielkonfiguration für AutoReseed

Beispielkonfiguration für automatisches erneutes Seeding

In diesem Beispiel sind drei Volumes vorhanden, von denen zwei Datenbanken (VOL1 und VOL2) enthalten und es sich bei dem dritten um ein leeres, formatiertes Ersatzvolume (VOL3) handelt.

So konfigurieren Sie die AutoReseed-Funktion:

  1. Alle drei Volumes werden über einen einzelnen Bereitstellungspunkt bereitgestellt. In diesem Beispiel wird der Bereitstellungspunkt "C:\ExchVols" verwendet. Dieser steht für das Verzeichnis zum Speicherabruf für Exchange-Datenbanken.

  2. Das Stammverzeichnis der Postfachdatenbanken wird als ein weiterer Bereitstellungspunkt konfiguriert. In diesem Beispiel wird der Bereitstellungspunkt "C:\ExchDBs" verwendet. Im nächsten Schritt wird eine Verzeichnisstruktur erstellt, die ein übergeordnetes Verzeichnis für jede Datenbank aufweist. Zu jedem übergeordneten Verzeichnis werden zwei Unterverzeichnisse erstellt: ein Verzeichnis für die Datenbankdatei und ein Verzeichnis für die Protokolldateien.

  3. Die Datenbanken werden erstellt. Das obige Beispiel zeigt ein einfaches Design mit einer einzelnen Datenbank pro Volume. Auf "VOL1" gibt es somit drei Verzeichnisse: ein übergeordnetes Verzeichnis und zwei Unterverzeichnisse (ein Verzeichnis für die MDB1-Datenbankdatei und ein Verzeichnis für die zugehörigen Protokolle). Obwohl nicht in der Abbildung dargestellt, würde auch "VOL2" drei Verzeichnisse enthalten: das übergeordnete Verzeichnis und darunter das Verzeichnis für die MDB2-Datenbankdatei sowie das Verzeichnis für die zugehörigen Protokolldateien.

In dieser Konfiguration wird bei Ausfall von MDB1 oder MDB2 für eine Kopie der ausgefallenen Datenbank automatisch ein erneutes Seeding auf "VOL3" ausgeführt.

Weitere Informationen zum Konfigurieren der AutoReseed-Funktion finden Sie unter Konfigurieren von AutoReseed für eine Database Availability Group.

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 zur Fehlerprüfung von Exchange 2010 bietet Exchange 2013 weitere Wiederherstellungsfunktionen bei langen E/A-Zeiten, übermäßigen Speicherbelegungen durch den Microsoft Exchange-Replikationsdienst (MSExchangeRepl.exe) und für gravierende Fälle, in denen keine Threads 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üfung 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üfung 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"

  1. Protokollierung von Ereignis 4395 im Crimson-Kanal, mit einer Anforderung zur Dienstbeendigung

  2. Einleiten der Beendigung von "MSExchangeRepl.exe"

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

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.

Das Sicherheitsnetz übernimmt einige Aufgaben der Shadow-Redundanz in DAG-Umgebungen. In DAG-Umgebungen muss über die Shadow-Redundanz keine weitere Kopie der zugestellten Nachricht in einer Schattenwarteschlange speichern, während auf die Replikation der zugestellten Nachricht in die passiven Kopien der Postfachdatenbanken auf den anderen Postfachservern in der DAG gewartet wird. Die Kopie der zugestellten Nachricht wird bereits im Sicherheitsnetz gespeichert, daher kann die Shadow-Redundanz die Nachricht ggf. aus dem Sicherheitsnetz erneut zustellen.

Mit der Einführung des Sicherheitsnetzes wird die Aktivierung einer verzögerten Datenbankkopie erheblich vereinfacht. 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 für mehr als 24 Stunden weniger als drei fehlerfreie Kopien (aktiv oder passiv) zur Verfügung stehen

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 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 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\ReplayLagPlayDownPercentDiskFreeSpace

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 gilt insbesondere für Umgebungen, die kein RAID (Redundant Array of Independent Disks) 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.

In Exchange 2010 wurde das Skript "CheckDatabaseRedundancy.ps1" eingeführt. Wie sein Name vermuten lässt, besteht der Zweck dieses Skripts in der Überwachung der Redundanz replizierter Postfachdatenbanken, indem überprüft wird, ob mindestens zwei konfigurierte, fehlerfreie und aktuelle Kopien vorhanden sind. Falls nur eine fehlerfreie Kopie einer replizierten Datenbank vorhanden ist, führt dies zu einer Ereignisprotokollgenerierung und zur Ausgabe einer Warnung an den Administrator. In diesem Fall werden zum Bestimmen von 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 systemeigene Funktion erweitert, um ein Warnungsrauschen zu verringern, das auftreten kann, wenn für mehrere Datenbanken auf demselben Server eine Einzelkopiebedingung erfüllt ist. In Exchange 2010 wurden Warnungen zu einzelnen Kopien auf Datenbankebene generiert. Bei Auftreten eines serverweiten Problems mit Auswirkung auf mehrere Datenbanken und Datenbankkopien konnte es daher zu einem Warnungssturm kommen. Da verschiedene Fehler, wie z. B. Controllerprobleme oder Arbeitsspeicherprobleme, serverweit auftreten, lag die Wahrscheinlichkeit eines solchen Warnungssturms bei diesen Fehlersituationen recht hoch. In Exchange 2013 werden diese Warnungen jetzt auf Serverbasis konfiguriert. Wenn ein Ausfall den gesamten Server betrifft und die Datenredundanz für mehrere Datenbankkopien gefährdet ist, wird nur eine Warnung pro Server generiert.

Ein DAG-Netzwerk ist eine Sammlung aus einem oder mehreren Subnetzen, die für Replikations- oder MAPI-Verkehr verwendet werden. Jede DAG enthält maximal ein MAPI-Netzwerk und kein oder mehr Replikationsnetzwerke. In Exchange 2010 basieren die vom System erstellten anfänglichen DAG-Netzwerke (z. B. DAGNetzwerk01 und DAGNetzwerk02) basieren auf den vom Clusterdienst erkannten Subnetzen. In Umgebungen, die mehrere Netzwerke verwenden, und bei denen die Schnittstellen für ein bestimmtes Netzwerk (z. B. das MAPI-Netzwerk) sich im gleichen Subnetz befinden, musste ein Administrator nur wenige zusätzliche Konfigurationsaufgaben ausführen. In Umgebungen jedoch, in denen die Schnittstellen für ein bestimmtes Netzwerk sich in unterschiedlichen Subnetzen befanden, musste der Administrator eine sogenannte Zusammenfassung von DAG-Netzwerken durchführen.

In Exchange 2013 ist eine Zusammenfassung von DAG-Netzwerken nicht länger erforderlich. Exchange 2013 verwendet weiterhin dieselben Erkennungsmechanismen zur Unterscheidung zwischen den MAPI- und Replikationsnetzwerken, fasst DAG-Netzwerke jetzt jedoch automatisch für Sie zusammen.

Zusätzlich werden DAG-Netzwerke ab sofort automatisch vom System verwaltet. Zur Anzeige der DAG-Netzwerkeigenschaften mithilfe der Exchange-Verwaltungskonsole müssen Sie die DAG für eine manuelle Netzwerksteuerung konfigurieren, indem Sie die Eigenschaften der DAG unter Verwendung der Exchange-Verwaltungskonsole ändern oder das Cmdlet Set-DatabaseAvailabilityGroup verwenden, um den Parameter ManualDagNetworkConfiguration auf True festzulegen.

Die Auswahl der besten Kopie (Best Copy Selection, BCS) ist ein interner Algorithmenprozess zum Ermitteln der besten Kopie einer einzelnen Datenbank für die Aktivierung. Die Auswahl erfolgt basierend auf einer Liste potenzieller Kopien für die Aktivierung, die Integrität und Status jeder Kopie angibt. Active Manager wählt die beste verfügbare (und nicht blockierte) Kopie aus, die zur neuen aktiven Datenbankkopie wird, wenn die vorhandene aktive Datenbankkopie ausfällt oder wenn ein Administrator ein Switchover ohne Zielangabe ausführt. In Exchange 2010 wertete der BCS-Prozess verschiedene Aspekte der einzelnen Datenbankkopien aus, um zu ermitteln, welche Kopie am besten aktiviert werden sollte. 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 umfasst verschiedene neue Integritätsprüfungen, die Bestandteil der Überwachungskomponenten für die verwaltete Verfügbarkeit in Exchange 2013 sind. Active Manager führt vier zusätzliche Prüfungen durch (hier in der Ausführungsreihenfolge aufgeführt):

  1. Alle Komponenten fehlerfrei   Prüft, ob ein Server mit einer Kopie der betroffenen Datenbank vorhanden ist, in der sich alle Überwachungskomponenten in einem fehlerfreien Status befinden.

  2. Komponenten mit normaler Priorität fehlerfrei   Prüft, ob ein Server mit einer Kopie der betroffenen Datenbank vorhanden ist, in der sich alle Überwachungskomponenten mit normaler Priorität in einem fehlerfreien Status befinden.

  3. Alle Komponenten besser als Quelle   Prüft, ob ein Server mit einer Kopie der betroffenen Datenbank vorhanden ist, in der sich alle Überwachungskomponenten in einem besseren Status als der aktuelle Server mit der betroffenen Kopie befinden.

  4. Komponenten genauso wie Quelle   Prüft, ob ein Server mit einer Kopie der betroffenen Datenbank vorhanden ist, in der sich alle Überwachungskomponenten im gleichen Status wie der aktuelle Server mit der betroffenen Kopie befinden.

Wenn BCSS aufgrund eines Failovers aufgerufen wird, das von einer Überwachungskomponente der verwalteten Verfügbarkeit ausgelöst wird (z. B. über einen Failoverantwortdienst), wird eine zusätzliche obligatorische Einschränkung erzwungen, die erfordert, dass die Komponentenintegrität des Zielservers besser sein muss als die des Servers, auf dem das Failover ausgeführt wurde. Wenn z. B. ein Microsoft Office Outlook Web App-Fehler einen Failover der verwalteten Verfügbarkeit über einen Failoverantwortdienst auslöst, muss BCSS einen Server auswählen, der eine Kopie der betroffenen Datenbank hostet, auf dem Outlook Web App fehlerfrei ist.

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.

Alle DAGs mit Windows Server 2008 R2 oder Windows Server 2012 benötigen mindestens eine IP-Adresse in jedem Subnetz im MAPI-Netzwerk. 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. In Windows Server 2012 R2 können Failovercluster ohne Administratorzugriffspunkt erstellt werden. Windows-Failovercluster ohne Administratorzugriffspunkte weisen die folgenden Merkmale auf:

  • Dem Cluster ist keine IP-Adresse zugewiesen, und daher enthält die Kernressourcengruppe des Clusters keine IP-Adressressource.

  • Dem Cluster ist kein Netzwerkname zugewiesen, und daher enthält die Kernressourcengruppe des Clusters keine Netzwerknamensressource.

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

  • Es wird kein Clusternamensobjekt (CNO) in Active Directory erstellt.

  • Der Windows-Failovercluster kann nicht mit dem Tool für die Failover-Clusterverwaltung verwaltet werden. Er muss mit Windows PowerShell verwaltet werden, und die PowerShell-Cmdlets müssen für einzelne Clustermitglieder 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 mit der Exchange-Verwaltungskonsole oder der Shell DAGs ohne Administratorzugriffspunkt erstellen. Weitere Informationen finden Sie unter Erstellen von DAGs und Erstellen einer Datenbankverfügbarkeitsgruppe.

Obwohl in Exchange 2013 weiterhin DAGs und das Windows-Failoverclustering für die Postfachserverrolle für die Bereitstellung von Hochverfügbarkeit und Ausfallsicherheit für Standorte eingesetzt wird, ist die Ausfallsicherheit für Standorte nicht dieselbe wie in Exchange 2013. Die Ausfallsicherheit für Standorte ist in Exchange 2013 deutlich besser, da sie vereinfacht wurde. Die zugrunde liegenden Architekturänderungen in Exchange 2013 haben erhebliche Auswirkungen auf die Wiederherstellungsaspekte einer Konfiguration zur Ausfallsicherheit von Standorten.

In Exchange 2010 war die Wiederherstellung von Postfach- (DAG) und Clientzugriff (Clientzugriffsserver-Array) eng verknüpft. Bei einem Ausfall von sämtlichen Clientzugriffsservern, der VIP für das Array oder einem Ausfall großer Teile Ihrer DAG war es erforderlich, ein Datencenterswitchover durchzuführen. Dies ist ein gut dokumentierter und im Allgemeinen leicht verständlicher Vorgang, wenngleich die Ausführung Zeit kostet und der Vorgang von einem Benutzer gestartet werden muss.

Wenn Sie in Exchange 2013 aus beliebigen Gründen das Clientzugriffsserver-Array verlieren (z. B. weil das Lastenausgleichsmodul ausfällt), muss kein Datencenterswitchover durchgeführt werden. Mit der richtigen Konfiguration findet ein Failover auf Clientebene statt, und Clients werden automatisch an ein zweites Datencenter umgeleitet, das über funktionierende Clientzugriffsserver verfügt. Diese Clientzugriffsserver leiten die Kommunikation zurück an den Benutzerpostfachserver, der vom Ausfall nicht betroffen ist (da Sie kein Switchover durchgeführt haben). Statt daran zu arbeiten, den Dienst wiederherzustellen, stellt der Dienst sich selbst wieder her, und Sie können sich auf die Behebung des Hauptproblems konzentrieren (z. B. um den Austausch des Lastenausgleichmoduls).

Darüber hinaus wird es durch Änderungen wie z. B. die Vereinfachung von Namespaces, die Konsolidierung von Serverrollen, die Entkopplung von Serverrollenanforderungen der Active Directory-Standorte, die Trennung von Clientzugriffsserver-Array- und DAG-Wiederherstellung sowie Änderungen am Lastenausgleich in Exchange 2013 ab sofort möglich, die Clientzugriffsserver- und DAG-Wiederherstellung zu trennen und automatisch über Standorte hinweg auszuführen. Auf diese Weise werden Szenarien für ein Datencenterfailover unterstützt, wenn Sie über drei Standorte verfügen.

In Exchange 2010 konnten Sie eine DAG über zwei Datencenter hinweg bereitstellen, den Zeugenserver in einem dritten Datencenter hosten und ein Failover für die Postfachserverrolle für beide Datencenter aktivieren. Es gab jedoch kein Failover für die Lösung selbst, da der Namespace für die Nicht-Postfachserverrollen weiterhin manuell geändert werden musste.

In Exchange 2013 muss der Namespace nicht mit der DAG verschoben werden. Exchange nutzt die integrierte Fehlertoleranz des Namespace über mehrere IP-Adressen, Lastenausgleich (und, sofern erforderlich, die Fähigkeit zur Inbetriebnahme und Außerbetriebnahme von Servern). Moderne HTTP-Clients arbeiten automatisch mit dieser Redundanz. Der HTTP-Stack kann mehrere IP-Adressen für einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) akzeptieren, und wenn die erste IP-Adresse dauerhaft ausfällt (d. h. eine Verbindung nicht möglich ist), wird die nächste IP-Adresse in der Liste verwendet. Bei einem temporären Fehler (Verbindungsverlust nach dem Einrichten einer Sitzung, beispielsweise aufgrund eines zeitweiligen Fehlers im Dienst, bei dem ein Gerät Pakete verliert und außer Betrieb genommen werden muss), muss der Benutzer möglicherweise den Browser aktualisieren.

Dies bedeutet, dass der Namespace nicht länger eine einzelne Fehlerquelle ist, wie dies in Exchange 2010 der Fall war. In Exchange 2010 ist die womöglich größte einzelne Fehlerquelle im Messagingsystem der Benutzern zugewiesene FQDN, da er die Zieladresse angibt. Im Exchange 2010-Paradigma ist eine Änderung des FQDN-Ziels nicht einfach, da Sie die DNS-Einstellungen ändern und die DNS-Wartezeit berücksichtigen müssen, die in einigen Teilen der Erde sehr hoch liegt. Außerdem werden in Browsern Namencaches verwendet, die Daten typischerweise für 30 Minuten oder mehr zwischenspeichern, und dieser Tatsache muss Rechnung getragen werden.

Eine der Änderungen in Exchange 2013 besteht darin, mehrere Zieladressen für Clients zu ermöglichen. Die Tatsache, dass der Client mehrere Zieladressen verwenden kann (fast alle Clientzugriffsprotokolle in Exchange 2013 sind HTTP-basiert (wie z. B. Outlook, Outlook Anywhere, EAS, EWS, OWA und die Exchange-Verwaltungskonsole), und alle unterstützten HTTP-Clients können mehrere IP-Adressen verwenden), ermöglicht ein Failover auf Clientseite. Sie können DNS so konfigurieren, dass einem Client während der Namensauflösung mehrere IP-Adressen übergeben werden. Der Client fragt "mail.contoso.com" an und erhält beispielsweise zwei oder vier IP-Adressen. Viele der an den Client zurückgegebenen IP-Adressen können jedoch zuverlässig verwenden werden. Dies verbessert den Clientbetrieb, da der Client bei einem Ausfall einer der IP-Adressen weitere IP-Adressen zur Verbindungsherstellung zur Verfügung stehen. Wenn beim Versuch einer Verbindungsherstellung durch den Client ein Fehler auftritt, wartet der Client für etwa 20 Sekunden und versucht es dann mit der nächsten Adresse in der Liste. Wenn also die VIP für das Clientzugriffsserver-Array ausfällt, wird innerhalb von etwa 21 Sekunden eine automatische Clientwiederherstellung durchgeführt.

Hierdurch bieten sich folgende Vorteile:

  • Wenn in Exchange 2010 das Lastenausgleichsmodul im primären Datencenter ausfiel und an diesem Standort kein weiteres Lastenausgleichsmodul verfügbar war, musste ein Datencenterswitchover durchgeführt werden. Wenn in Exchange 2013 das Lastenausgleichsmodul am primären Standort ausfällt, schalten Sie es einfach ab (oder deaktivieren die VIP) und reparieren bzw. ersetzen es. Für Clients, die nicht bereits die VIP im sekundären Datencenter verwenden, wird ein automatisches Failover zur sekundären VIP durchgeführt – ohne Änderung des Namespace und ohne DNS-Änderungen. Dies bedeutet nicht nur, dass Sie keinen Switchover durchführen müssen, sondern auch keine Zeit für die normalerweise mit einem Datencenterswitchover verbundene Wiederherstellung aufwenden müssen. In Exchange 2010 mussten Sie die DNS-Wartezeit berücksichtigen (die empfohlene TTL-Einstellung (Time to Live) lautet 5 Minuten, und es muss eine Failback-URL eingeführt werden). In Exchange 2013 ist dies nicht erforderlich, da Sie ein schnelleres Failover (20 Sekunden) des Namespace zwischen VIPs (Datencentern) durchführen können.

  • Da jetzt ein Failover des Namespace zwischen Datencentern möglich ist, wird zum Erreichen eines Datencenterfailovers lediglich ein Mechanismus für ein datencenterübergreifendes Failover der Postfachserverrolle benötigt. Für ein automatisches Failover der DAG benötigen Sie lediglich eine Lösung, bei der die DAG gleichmäßig auf zwei Datencenter aufgeteilt ist. Anschließend platzieren Sie den Zeugenserver an einem dritten Standort, sodass er von DAG-Mitgliedern beider Datencenter vermittelt werden kann – unabhängig vom Status des Netzwerks zwischen den Datencentern, die die DAG-Mitglieder enthalten.

  • In diesem Szenario beschränken sich die Aufgaben des Administrators darauf, das vorliegende Problem zu lösen, eine Dienstwiederherstellung ist nicht erforderlich. Sie korrigieren lediglich die fehlerhafte Komponente, während der Dienst weiter ausgeführt und die Datenintegrität aufrechterhalten wird. Der Termindruck und der Stress bei der Reparatur eines beschädigten Geräts sind nicht zu vergleichen mit dem Termindruck und dem Stress, der mit der Wiederherstellung eines Diensts einhergeht. Das bedeutet Vorteile für den Endbenutzer und weniger Stress für den Administrator.

Sie können ein Failover durchführen, ohne Switchbacks auszuführen (gelegentlich fälschlich als Failbacks bezeichnet). Wenn Sie den Clientzugriffsserver im primären Datencenter verlieren und dies zu einer 20 Sekunden dauernden Dienstunterbrechung für die Clients führt, müssen Sie sich möglicherweise noch nicht einmal Gedanken über ein Failback machen. Zu diesem Zeitpunkt besteht Ihre Hauptsorge darin, das Kernproblem zu lösen (z. B. das ausgefallene Lastenausgleichsmodul zu ersetzen). Nachdem die Komponente wieder online und betriebsbereit ist, beginnen einige Clients damit, die Komponente erneut zu nutzen, und andere Clients nehmen Dienste über das zweite Datencenter in Anspruch.

Exchange 2013 bietet außerdem eine Funktionalität, die Administratoren die Handhabung von zeitweise auftretenden Fehlern ermöglicht. Ein zeitweiliger Fehler ist beispielsweise eine Situation, in der die anfängliche TCP-Verbindung hergestellt werden kann, dann jedoch ein Stillstand eintritt. Ein zeitweise auftretender Fehler erfordert einigen zusätzlichen Verwaltungsaufwand, da er das Ergebnis der Inbetriebnahme eines Ersatzgeräts sein kann. Während der Reparatur wird das Gerät möglicherweise eingeschaltet und akzeptiert einige Anforderungen, kann jedoch nicht wirklich für die Verarbeitung von Dienstanforderungen durch Clients verwendet werden, bis die erforderlichen Konfigurationsschritte ausgeführt wurden. In diesem Szenario kann der Administrator einen Namespaceswitchover durchführen, indem einfach die VIP für das im Austausch befindliche Gerät aus der DNS-Konfiguration entfernt wird. Dies führt dazu, dass Clients während der Wartungsphase nicht versuchen, eine Verbindung mit dem Gerät herzustellen. Nachdem der Austausch abgeschlossen wurde, kann der Administrator die VIP wieder in die DNS-Konfiguration einfügen, und Clients können das Gerät wieder verwenden.

Weitere Informationen zum Planen und Bereitstellen von Ausfallsicherheit für Standorte finden Sie unter Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten und Bereitstellen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten.

Wichtige Terminologie

Exchange 2013 enthält eine API für die Drittanbieterreplikation, mit der Unternehmen anstelle der integrierten Funktion für die fortlaufende Replikation Lösungen anderer Anbieter für die synchrone Replikation verwenden können. Microsoft unterstützt Drittanbieterlösungen, die diese API verwenden, sofern die Lösung die benötigte Funktionalität bereitstellt, um sämtliche systemeigene Funktionalität für die fortlaufende Replikation zu ersetzen, die als Ergebnis der Verwendung der API deaktiviert ist. Lösungen werden nur unterstützt, wenn die API in einer DAG zum Verwalten und Aktivieren von Postfachdatenbankkopien verwendet wird. Die Verwendung der API darüber hinaus wird nicht unterstützt. Außerdem muss die Lösung die geltenden Supportanforderungen für Windows-Hardware erfüllen. (Für Support ist keine Testvalidierung erforderlich.)

Beim Bereitstellen einer Lösung, die die integrierte Drittanbieterreplikations-API verwendet, muss Ihnen klar sein, dass der Lösungsanbieter für den Primärsupport der Lösung zuständig ist. Microsoft unterstützt Exchange-Daten in sowohl replizierten als auch nicht replizierten Lösungen. Lösungen mit Datenreplikation müssen die Supportrichtlinie von Microsoft für die Datenreplikation befolgen. Siehe Microsoft Knowledge Base-Artikel 895847, Unterstützung der Datenreplikation für mehrere Standorte durch Exchange Server. Darüber hinaus müssen Lösungen, die das Ressourcenmodell "Windows-Failovercluster" nutzen, die Supportanforderungen für Windows-Cluster im Microsoft Knowledge Base-Artikel 943984 erfüllen: Microsoft-Supportrichtlinie für Windows Server 2008- oder Windows Server 2008 R2 Failovercluster oder Microsoft-Supportrichtlinie für Windows Server 2012 Failovercluster.

Die Supportrichtlinie für Sicherung und Wiederherstellung von Microsoft für Bereitstellungen mit Replikations-API-basierten Drittanbieterlösungen entspricht der Richtlinie für systemeigene Bereitstellungen der fortlaufenden Replikation.

Wenn Sie ein Partner sind, der nach Informationen zur Drittanbieter-API sucht, wenden Sie sich an Ihren Ansprechpartner bei Microsoft.

Wichtige Terminologie

In der folgenden Tabelle sind Links zu Themen aufgeführt, in denen Sie weitere Informationen zu DAGs, Postfachdatenbankkopien und Sicherung und Wiederherstellung für Exchange 2013 sowie zur Verwaltung dieser Funktionen finden.

 

Thema Beschreibung

Database Availability Groups (DAGs)

Hier erhalten Sie Informationen zu DAGs, Active Manager, DAC-Modus (Datacenter Activation Coordination) und Postfachdatenbankkopien.

Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten

Hier erhalten Sie Informationen zu den allgemeinen Anforderungen und den Anforderungen für Hardware, Netzwerk, Zeugenserver und zu den bewährten Methoden für DAGs.

Bereitstellen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten

Hier können Sie ein Beispielszenario für die Bereitstellung und Konfiguration von DAGs untersuchen.

Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte

Hier erhalten Sie Informationen zu Verwaltungsaufgaben in Bezug auf DAGs, zu Switchover- und Failovervorgängen sowie zum Wartungsmodus.

Überwachen von Database Availability Groups

Hier erhalten Sie Informationen zu den integrierten Cmdlets und Skripts für die Überwachung von DAGs und Datenbankkopien.

Sicherung, Wiederherstellung und Notfallwiederherstellung

Hier erhalten Sie Informationen zur Sicherung und Wiederherstellung von Exchange-Datenbanken und Wiederherstellungsdatenbanken sowie zur Serverwiederherstellung.

Wichtige Terminologie

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft