Grundlegendes zu hoher Verfügbarkeit und Ausfallsicherheit von Standorten

  • Artikel

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Postfachdatenbanken und die darin enthaltenen Daten sind eine der wichtigsten (wenn nicht die wichtigsten) Komponenten einer jeden Exchange-Organisation. In Microsoft Exchange Server 2010 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 2010 senkt die Kosten und Komplexität für die Bereitstellung einer hoch verfügbaren und ausfallsicheren Messaginglösung und bietet gleichzeitig eine höhere durchgängige Verfügbarkeit sowie Unterstützung für große Postfächer. Beruhend auf den systemeigenen Replikationsfunktionen, die in Exchange Server 2007 eingeführt wurden, stellt die neue Architektur für hohe Verfügbarkeit in Exchange 2010 ein vereinfachtes, einheitliches System für hohe Verfügbarkeit und Ausfallsicherheit für Standorte bereit. In Exchange 2010 ist die hohe Verfügbarkeit in die grundlegende Architektur von Exchange integriert, 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

Wichtige Merkmale der Exchange Server 2010-Lösung

Datenbankmobilität

Inkrementelle Bereitstellung

Database Availability Groups (DAGs)

Postfachdatenbankkopien

Active Manager

Änderungen hinsichtlich der hohen Verfügbarkeit gegenüber früheren Versionen von Exchange

Hohe Verfügbarkeit für Nicht-Postfachserverrollen

Ausfallsicherheit für Standorte

End-to-End-Verfügbarkeit

Wichtige Terminologie

Es werden die folgenden Begriffe verwendet:

  • Adressbuchdienst
    Ein Dienst auf dem Clientzugriffsserver, der für Microsoft Outlook-Clients einen Verzeichniszugriffsendpunkt bereitstellt.
  • Fortlaufende Replikation - Blockmodus
    Eine neue Form der fortlaufenden Replikation in SP1, bei der beim Schreiben einer Aktualisierung in den aktiven Protokollpuffer der aktiven Datenbankkopie diese auch in einen Protokollpuffer aller passiven Postfachkopien übertragen wird. 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
    Der Name der ursprünglichen Form der fortlaufenden Replikation in der RTM-Version (Release to Manufacturing) von Exchange 2010, bei der geschlossene Transaktionsprotokolldateien aus der aktiven Datenbankkopie in eine oder mehrere passive Datenbankkopien übertragen werden.
  • Database Availability Group (DAG)
    Eine Gruppe von bis zu 16 Exchange 2010-Postfachservern, die eine Gruppe replizierter Datenbanken hostet.
  • Datenbankmobilität
    Die Fähigkeit, eine einzelne Exchange 2010-Postfachdatenbank zu replizieren und auf anderen Exchange 2010-Postfachservern einzubinden.
  • 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 Database Availability Groups 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 2010 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 2010.
  • RPC-Clientzugriffsdienst
    Ein Dienst auf dem Clientzugriffsserver, der für Microsoft Outlook-Clients einen MAPI-Endpunkt bereitstellt.
  • Ausfallsicherheit von Standorten
    Ein manueller Prozess zur Notfallwiederherstellung, um ein alternatives oder Standbydatencenter zu aktivieren, wenn das primäre Datencenter das für die Organisation erforderliche Servicelevel nicht länger bieten kann. Dies umfasst zudem die erneute Aktivierung eines primären Datencenters, das wiederhergestellt oder neu erstellt wurde. Sie können Ihre Messaginglösung für hohe Verfügbarkeit konfigurieren und mithilfe der integrierten Funktionen in Exchange 2010 die Ausfallsicherheit für Standorte aktivieren.
  • Shadow-Redundanz
    Eine Transportserverfunktion, die Redundanz für Nachrichten bietet, während diese übertragen werden.
  • *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.

Zurück zum Seitenanfang

Wichtige Merkmale der Exchange Server 2010-Lösung

Durch Exchange 2007 wurden die Kosten für hohe Verfügbarkeit verringert und die Ausfallsicherheit von Standorten wesentlich wirtschaftlicher gestaltet, indem neue Technologien eingeführt wurden, z. B. die fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR) und die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR). Dennoch gibt es weiterhin einige Herausforderungen:

  • Windows-Failover-Cluster könnten aufgrund ihrer Komplexität verwirrend sein.

  • Für eine durchgehend hohe Verfügbarkeit sind möglicherweise viele Administratoreingriffe erforderlich.

  • Jede Art von fortlaufender Replikation wurde unterschiedlich und separat verwaltet.

  • Die Wiederherstellung nach dem Ausfall einer einzelnen Datenbank auf einem großen Postfachserver konnte für alle Benutzer auf dem Postfachserver zu einer temporären Dienstunterbrechung führen.

  • Der Transportdumpster des Hub-Transport-Servers konnte nur Nachrichten schützen, die an Postfächer in einer CCR-Umgebung gerichtet waren. Wenn ein Hub-Transport-Server während der Verarbeitung von Nachrichten ausfällt und nicht wiederherstellt werden kann, kann dies zu Datenverlusten führen.

In Exchange 2010 sind wichtige grundlegende Änderungen enthalten, um hohe Verfügbarkeit in die Architektur zu integrieren, wodurch diese kostengünstiger und einfacher bereitzustellen und zu verwalten ist als bei früheren Versionen von Exchange. Exchange 2010 bietet eine neue vereinheitlichte Plattform für hohe Verfügbarkeit und Ausfallsicherheit von Standorten.

Mit den grundlegenden Verbesserungen an Exchange 2010 steigt die empfohlene Maximalgröße für Postfachdatenbanken bei Verwendung der fortlaufenden Replikation von 200 Gigabyte (GB) in Exchange 2007 auf 2 Terabyte in Exchange 2010. Immer mehr Unternehmen erkennen die Vorteile großer Postfächer (von 2 GB bis 10 GB), weshalb größere Datenbanken schon bald Normalität sein können. Die Unterstützung größerer Datenbanken bedeutet eine Abkehr von bislang herkömmlichen Mechanismen für die Wiederherstellung, z. B. Sicherung und Wiederherstellung, hin zu neueren, schnelleren Schutzmethoden, z. B. Datenreplikation und Serverredundanz. Letztendlich hängt die Größe Ihrer Postfachdatenbanken von verschiedenen Faktoren ab, die Sie während des Exchange 2010-Planungsprozesses ableiten. Detaillierte Anleitungen zur Planung von Postfächern und Postfachservern finden Sie unter Speicherentwurf für Postfachserver.

Exchange 2010 kombiniert die wichtigsten Verfügbarkeits- und Ausfallsicherheitsfunktionen von CCR und SCR in einer kompakten Lösung, die sowohl die standortinterne als auch die standortexterne Datenreplikation unterstützt. Postfachserver können als Teil einer Database Availability Group definiert werden, um eine automatische Wiederherstellung der einzelnen Postfächer auf Postfachdatenbankebene statt auf Serverebene zu ermöglichen. In Exchange 2010 werden weitere neue Konzepte für Hochverfügbarkeit eingeführt, z. B. die Datenbankmobilität und die inkrementelle Bereitstellung.

Zurück zum Seitenanfang

Datenbankmobilität

In Exchange 2007 wurden viele Architekturänderungen eingeführt, die dazu gedacht waren, Lösungen für hohe Verfügbarkeit und Ausfallsicherheit von Standorten für Exchange schneller und einfacher bereitstellen zu können. Zu diesen Verbesserungen zählten ein integriertes Setup, optimierte Konfigurationseinstellungen und die Möglichkeit, die meisten Aspekte der Hochverfügbarkeitslösung mithilfe systemeigener Exchange-Verwaltungstools zu verwalten.

Dennoch setzte die Verwaltung einer Exchange 2007-Hochverfügbarkeitslösung die Kenntnis komplexer Clusterkonzepte voraus, z. B. das Konzept zum Verschieben von Netzwerkidentitäten und zum Verwalten von Clusterressourcen. Außerdem mussten bei der Behandlung von Problemen im Zusammenhang mit einem Postfachclusterserver Exchange-Tools und Clustertools verwendet werden, um Protokolle und Ereignisse aus zwei verschiedenen Quellen zu überprüfen und in Beziehung zu setzen: von Exchange und vom Cluster.

Auf Grundlage von Kundenfeedback wurden zwei weitere einschränkende Aspekte der Exchange 2007-Architektur geprüft und überarbeitet:

  • Exchange 2007-Clusterserver erfordern dedizierte Hardware. Nur die Postfachserverrolle konnte auf einem Knoten im Cluster installiert werden. Das bedeutete, dass mindestens vier Exchange-Server erforderlich waren, um vollständige Redundanz für die Hauptkomponenten einer Bereitstellung zu erzielen, z. B. die grundlegenden Serverrollen (Postfach, Hub-Transport und Clientzugriff).

  • In Exchange 2007 erfolgt das Failover für einen Postfachclusterserver auf Serverebene. Bei einem Ausfall einer einzelnen Datenbank musste der Administrator ein Failover für den gesamten Postfachclusterserver auf einen anderen Knoten im Cluster durchführen (was nicht nur für die Benutzer mit einem Postfach in der betroffenen Datenbank, sondern für alle Benutzer auf dem Server zu einer kurzen Downtime führte), oder er musste die Benutzer der ausgefallenen Datenbank (möglicherweise für Stunden) offline lassen, während die Datenbank aus der Sicherung wiederhergestellt wurde.

Exchange 2010 wurde mit dem Konzept der Datenbankmobilität entwickelt. Die Datenbankmobilität erweitert die Verwendung der fortlaufenden Replikation des Systems, indem eine Datenbank auf mehrere verschiedene Server innerhalb einer Gruppe repliziert wird. Dieses Modell bietet einen besseren Schutz der Datenbank und eine höhere Verfügbarkeit. Bei diesem Modell wird der automatische Failoverschutz und der manuelle Switchover nicht auf Serverebene, sondern auf Postfachdatenbankebene gesteuert.

Falls Fehler auftreten, können andere Server, die Kopien der Datenbank besitzen, diese Datenbank einbinden. Als Ergebnis dieser und weiterer Architekturänderungen werden Failoveraktionen jetzt sehr viel schneller ausgeführt als in früheren Versionen von Exchange. Beispielsweise erfolgt ein Failover für einen Postfachclusterserver in einer CCR-Umgebung, in der Exchange 2007 mit Service Pack 1 ausgeführt wird, in etwa 2 Minuten (bei einem standortinternen Fehler unter der Annahme, dass sich die IP-Adresse des Postfachclusterservers nicht ändert). Zum Vergleich: Das Failover einer Postfachdatenbank in einer Exchange 2010-Umgebung dauert 30 Sekunden (gemessen ab dem Zeitpunkt, an dem der Fehler erkannt wurde, bis zum Einbinden einer Datenbankkopie, vorausgesetzt, eine fehlerfreie und aktuelle Kopie mit Protokollwiedergabe wird verwendet). Die Kombination von Failover auf Datenbankebene und einer wesentlich schnelleren Failoverausführung ermöglicht Unternehmen mehr Betriebszeit.

Zurück zum Seitenanfang

Inkrementelle Bereitstellung

In Exchange 2010 wird das Konzept der inkrementellen Bereitstellung eingeführt, bei dem Sie die Dienst- und Datenverfügbarkeit für alle Postfachserver und Datenbanken bereitstellen können, nachdem Exchange installiert wurde. Die Dienst- und Datenredundanz wird mithilfe neuer Funktionen in Exchange 2010 erreicht, z. B. mit Database Availability Groups und Datenbankkopien.

In früheren Versionen von Exchange wurde die Dienstverfügbarkeit für die Postfachserverrolle durch Bereitstellen von Exchange in einem Windows-Failovercluster erreicht. Für die Bereitstellung von Exchange in einem Cluster mussten Sie zuerst einen Failovercluster erstellen und dann die Exchange-Programmdateien installieren. Bei diesem Vorgang wurde ein spezieller Postfachserver erstellt, der als Postfachclusterserver bezeichnet wurde (oder in älteren Versionen von Exchange als virtueller Exchange-Server). Wenn Sie bereits die Exchange-Programmdateien auf einem Server ohne Cluster installiert hatten und dann einen Postfachclusterserver einsetzen wollten, mussten Sie einen Cluster mithilfe neuer Hardware erstellen oder Exchange vom vorhandenen Server entfernen, die Failover-Clusterunterstützug installieren und dann Exchange erneut installieren.

Zurück zum Seitenanfang

Database Availability Groups (DAGs)

Eine Database Availability Group (DAG) ist die Basiskomponente des Systems für hohe Verfügbarkeit und Ausfallsicherheit für Standorte in Exchange 2010. Eine Database Availability Group umfasst bis zu 16 Postfachservern, die einen Satz Datenbanken hosten und eine automatische Wiederherstellung auf Datenbankebene nach Fehlern bieten, die einzelne Datenbanken 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.

Mit Exchange 2007 wurde eine Technologie zur integrierten Datenreplikation eingeführt, die sogenannte fortlaufende Replikation. Die fortlaufende Replikation stand in drei Formen zur Verfügung: als lokale fortlaufende Replikation, als fortlaufende Cluster- und als fortlaufende Standbyreplikation. Mit der fortlaufenden Replikation wurden die Kosten für die Bereitstellung einer hoch verfügbaren Exchange-Infrastruktur erheblich gesenkt und die Bereitstellung und Verwaltung gegenüber früheren Versionen von Exchange stark verbessert. Doch trotz dieser Kosteneinsparungen und Verbesserungen war zur Ausführung einer hoch verfügbaren Exchange 2007-Infrastruktur viel Zeit und Wissen erforderlich, da die Integration zwischen Exchange und Windows-Failoverclustern nicht nahtlos erfolgte. Zusätzlich wünschten sich Kunden eine einfachere Methode zum Replizieren ihrer E-Mail-Daten an einen Remotestandort, um ihre Exchange-Umgebung gegen Ausfälle auf Standortebene zu schützen.

Exchange 2010 verwendet dieselbe Technologie für eine fortlaufende Replikation wie Exchange 2007. Exchange 2010 kombiniert die standortinterne Datenreplikation (CCR) und die standortexterne Datenreplikation (SCR) in einem System mit dem Namen Database Availability Group (DAG). Nachdem einer Database Availability Group Server hinzugefügt wurden, können Sie (bis zu 16) replizierte Datenbankkopien inkrementell hinzufügen, und Exchange 2010 wechselt zur Erhaltung der Verfügbarkeit automatisch zwischen diesen Kopien.

Im Gegensatz zu Exchange 2007, bei dem für Postfachclusterserver dedizierte Hardware erforderlich ist, können Postfachserver in einer Database Availability Group andere Exchange-Rollen hosten (Clientzugriff, Hub-Transport und Unified Messaging). So kann mit lediglich zwei Servern vollständige Redundanz der Exchange-Dienste und -Daten gewährleistet werden.

Die neue Architektur für hohe Verfügbarkeit ermöglicht außerdem eine vereinfachte Wiederherstellung bei verschiedenen Fehlern (auf Datenträger, Server- und Datencenterebene), und die Architektur kann für eine Vielzahl von Speichertypen bereitgestellt werden.

Weitere Informationen zu Database Availability Groups finden Sie unter Grundlegendes zu Database Availability Groups.

Zurück zum Seitenanfang

Postfachdatenbankkopien

Die zuerst in Exchange 2007 eingeführten Funktionen für hohe Verfügbarkeit und Ausfallsicherheit für Standorte werden in Exchange 2010 zum Erstellen und Verwalten von Datenbankkopien verwendet, damit Sie Ihre Verfügbarkeitsziele in Exchange 2010 erreichen. In Exchange 2010 wird außerdem das Konzept der Datenbankmobilität eingeführt, bei dem Exchange Failovervorgänge auf Datenbankebene verwaltet.

Im Rahmen der Datenbankmobilität werden Datenbanken von Servern getrennt, Unterstützung für bis zu 16 Kopien einer einzelnen Datenbank hinzugefügt und eine systemeigene Umgebung für das Hinzufügen von Datenbankkopien zu einer Datenbank bereitgestellt. In Exchange 2007 konnten Sie mithilfe einer Funktion, die als "Datenbankportabilität" bezeichnet wurde, ebenfalls eine Postfachdatenbank zwischen Servern verschieben. Ein wesentlicher Unterschied zwischen der Datenbankportabilität und der Datenbankmobilität ist jedoch, dass bei der Datenbankmobilität alle Kopien einer Datenbank dieselbe GUID besitzen.

Das Festlegen einer Datenbankkopie als aktive Postfachdatenbank wird als Switchover bezeichnet. Wenn ein Fehler auftritt, der die 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 2010-Serverrollen 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. Falls die Datenbank die Kriterien für eine automatische Einbindung nicht erfüllt und daher nicht automatisch eingebunden werden kann, können Sie ein manuelles Datenbankfailover durchführen.

Weitere Informationen zu Postfachdatenbankkopien finden Sie unter Grundlegendes zu Postfachdatenbankkopien.

Zurück zum Seitenanfang

Active Manager

In Exchange 2007 und früheren Versionen verwendete Exchange das Clusterressourcenmodell zum Installieren, Implementieren und Verwalten der Hochverfügbarkeitslösung für den Postfachserver. In der Vergangenheit wurde zur Bereitstellung eines Postfachservers mit hoher Verfügbarkeit zunächst ein Windows-Failovercluster erstellt, und anschließend wurde das Exchange-Setup im Clustermodus ausgeführt. In diesem Modus wurde die Exchange-Clusterressourcen-DLL, exres.dll, registriert und erlaubte die Erstellung eines Postfachclusterservers (in älteren Versionen als virtueller Exchange-Server bezeichnet). Bei der Bereitstellung von Clustern mit freigegebenem Speicher oder Einzelkopieclustern (Single Copy Cluster, SCC) in älteren Exchange-Versionen waren vor und nach Erstellung des Failoverclusters sowie nach Erstellung des Postfachclusterservers und der Speichergruppe zusätzliche Schritte zum Konfigurieren des Speichers erforderlich.

Exchange 2010 bietet mit Active Manager eine neue Komponente. Die Funktionalität von Active Manager ersetzt das Ressourcenmodell und die Funktionen zur Failoververwaltung, die durch die Integration mit dem Clusterdienst in früheren Versionen von Exchange bereitgestellt wurden. Weitere Informationen zu Active Manager finden Sie in Grundlegendes zu Active Manager.

Zurück zum Seitenanfang

Änderungen hinsichtlich der hohen Verfügbarkeit gegenüber früheren Versionen von Exchange

Es wurden verschiedene Änderungen an der Kernarchitektur von Exchange 2010 vorgenommen, die sich direkt auf die Konfiguration von Exchange für hohe Verfügbarkeit sowie darauf auswirken, wie Sie eine Standortwiederherstellung durchführen. Eine wichtige Änderung ist die Entfernung des Postfachclusterservers und die Verwendung des Windows-Failovercluster-Ressourcenmodells. Weitere wesentliche Änderungen sind die Globalisierung der Datenbanken und die Weiterentwicklungen an der integrierten Technologie für die fortlaufende Replikation, die zuerst in Exchange 2007 eingeführt wurde.

Entfernung des Postfachclusterservers

In Exchange 2010 ist Exchange nicht länger eine Clusteranwendung, und das Clusterressourcenmodell findet zum Sicherstellen einer hohen Verfügbarkeit von Exchange keine Anwendung mehr. Die Datei "Exres.dll" und alle durch diese DLL bereitgestellten Exchange-Clusterressourcen sind nicht länger vorhanden, Postfachclusterserver eingeschlossen. Exchange 2010 verwendet stattdessen ein eigenes, internes Modell zur Sicherstellung einer hohen Verfügbarkeit. Einige Komponenten der Windows-Failover-Clusterunterstützung werden weiterhin eingesetzt, sind jetzt jedoch in eine andere Funktionalität von Exchange 2010 integriert.

Globalisierung von Datenbanken

In Exchange 2010 ist jede Datenbank einem einzelnen, dedizierten Protokolldatenstrom zugeordnet, der aus einer Folge sequenziell benannter 1 MB (Megabyte) großer Protokolldateien besteht. Das Konzept der Speichergruppen wurde aus Exchange 2010 entfernt. Als Ergebnis dieser Änderungen verfügen Exchange-Datenbanken über einen dedizierten Protokolldatenstrom und verwenden Protokolldatenströme nicht länger gemeinsam mit anderen Datenbanken.

Im Gegensatz zu früheren Versionen von Exchange sind Datenbanken nicht länger eng an einen spezifischen Postfachserver gebunden. Darüber hinaus werden Datenbanken nicht länger durch den Postfachserver identifiziert, auf dem sie sich befinden, und Servernamen sind nicht länger Bestandteil von Datenbankidentitäten. Als Ergebnis dieser Änderungen sind Datenbanken nun globale Objekte in Active Directory und in jeder Exchange-Organisation. Bei Verwendung der Exchange-Verwaltungskonsole werden Datenbanken nun über den Knoten Postfach unterhalb des Knotens Organisationskonfiguration verwaltet.

Jeder Postfachserver kann maximal 100 Datenbanken hosten (Summe der aktiven und passiven Datenbanken). Die Gesamtanzahl der Datenbanken entspricht der Summe der aktiven und passiven Datenbanken auf einem Server. Die Wiederherstellungsdatenbank wird bei der maximalen Anzahl von 100 Datenbanken nicht eingerechnet.

Änderungen an der fortlaufenden Replikation von Exchange Server 2010 RTM

Die in Exchange 2007 eingeführte Technologie für die fortlaufende Replikation ist in Exchange 2010 weiterhin verfügbar. Die Technologie wurde jedoch wesentlich weiterentwickelt, um neue Hochverfügbarkeitsfunktionen und eine größere Skalierbarkeit zu unterstützen. Unter anderem wurden die folgenden Architekturänderungen vorgenommen:

  • Da Speichergruppen in Exchange 2010 entfernt wurden, erfolgt die fortlaufende Replikation nun auf Datenbankebene. Exchange 2010 verwendet weiterhin eine ESE-Datenbank (Extensible Storage Engine) zum Generieren von Transaktionsprotokollen. Diese Transaktionsprotokolle werden an einen oder mehrere Standorte repliziert und in einer oder mehreren Postfachdatenbankkopien wiedergegeben. Jede Postfachdatenbank kann über bis zu 16 Kopien verfügen.

  • Der Protokollversand verwendet nicht länger SMB (Server Message Block) und Windows-Dateisystembenachrichtigungen. Beim Protokollversand wird kein Pull-Modell mehr verwendet, bei dem die passive Kopie eine geschlossene Protokolldatei von der aktiven Kopie abruft. Stattdessen verwendet die passive Kopie TCP-basierte Benachrichtigungen, um die aktive Kopie darüber zu informieren, welche Protokolldateien die passive Kopie benötigt. Die aktive Kopie übermittelt die Protokolldateien dann über den TCP-Socket im Push-Verfahren an jede konfigurierte passive Kopie.

  • Die fortlaufende Replikation in Exchange 2010 verwendet einen einzelnen, vom Administrator definierten TCP-Port für die Datenübertragung. Zusätzlich umfasst Exchange 2010 integrierte Optionen für die Netzwerkverschlüsselung und Komprimierung des Datenstroms.

  • Das Seeding ist nicht länger auf die ausschließliche Verwendung der aktiven Kopie der Datenbank beschränkt. Passive Kopien von Postfachdatenbanken können jetzt als Quelle für ein Seeding und ein erneutes Seeding von Datenbankenkopien angegeben werden.

  • Datenbankkopien sind nur für Postfachdatenbanken verfügbar. Um für Öffentliche Ordner-Datenbanken Redundanz und hohe Verfügbarkeit zu erreichen, sollten Sie die Replikation Öffentlicher Ordner verwenden. Anders als bei der fortlaufenden Clusterreplikation (Cluster Continuous Replication, CCR), bei der mehrere Kopien einer Öffentliche Ordner-Datenbank nicht im gleichen Cluster enthalten sein können, haben Sie die Möglichkeit, die Replikation Öffentlicher Ordner zu verwenden, um Öffentliche Ordner-Datenbanken zwischen Servern innerhalb einer Database Availability Group zu replizieren.

  • In Exchange 2007 sorgt der Microsoft Exchange-Replikationsdienst für die Wiedergabe von Protokollen in passive Datenbankkopien. Beim Aktivieren der passiven Kopie ging der Datenbankcache verloren, den der Microsoft Exchange-Replikationsdienst als Ergebnis der Wiedergabeaktivität erstellt hatte, wenn der Microsoft Exchange-Informationsspeicherdienst die Datenbank einband. Der Datenbankcache wurde in einen Status versetzt, der als Kaltzustand bezeichnet wird. Der Datenbankcache, der zum Zwischenspeichern von Lese-/Schreibvorgängen verwendet wird, weist während dieser Zeit nur eine geringe Größe auf. Daher ist die Möglichkeit, E/A-Lesevorgänge zu reduzieren, deutlich eingeschränkt. In Exchange 2010 wird die Wiedergabefunktionalität der passiven Kopie, die zuvor der Microsoft Exchange-Replikationsdienst innehatte, in den Microsoft Exchange-Informationsspeicherdienst verlagert. Als Ergebnis liegt ein Datenbankcache im "Warmzustand" vor, der sofort nach einem Failover oder Switchover zur Verfügung steht.

Verschiedene bei der fortlaufenden Exchange 2007-Replikation verwendete Konzepte kommen auch weiterhin in Exchange 2010 zum Einsatz. Hierzu gehören die Konzepte für Failoververwaltung, Abweichung, die Verwendung von AutoDatabaseMountDial sowie von Replikations- und Clientzugriffsnetzwerken (MAPI).

Änderungen an der fortlaufenden Replikation von Exchange Server 2010 SP1

In der RTM-Version von Exchange 2010 und allen Versionen von Exchange Server 2007 werden bei der fortlaufenden Replikation Kopien der von der aktiven Datenbankkopie erstellten Protokolldateien in die passiven Kopien übertragen. Ab Exchange 2010 SP1 wird diese Form der fortlaufenden Replikation als Fortlaufende Replikation - Dateimodus bezeichnet. In SP1 wird auch eine neue Form der fortlaufenden Replikation eingeführt, die als Fortlaufende Replikation - Blockmodus bezeichnet wird. 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. Sollte sich ein Systemausfall auf die aktive Kopie auswirken, werden die passiven Kopien mit den meisten oder allen der letzten Aktualisierungen aktualisiert. Die aktive Kopie wartet nicht den Abschluss der Replikation ab, um Replikationsprobleme daran zu hindern, sich auf die Clientumgebung auszuwirken.

Der Blockmodus verkürzt drastisch die Wartezeit zwischen dem Zeitpunkt einer Änderung an der aktiven Kopie und deren Replikation in passive Kopien. Zusätzlich zum Replizieren einzelner Protokolldateischreibvorgänge ändert der Blockmodus auch den Aktivierungsprozess einer passiven Kopie. Wenn sich eine Kopie bei Auftreten eines Fehlers im Blockmodus befindet, verwendet das System während des Aktivierungsprozesses die vorhandenen teilweisen Protokollinhalte. Dies verhindert, dass die aktuelle Protokolldatei eine einzelne Fehlerquelle für die aktive Kopie darstellt.

Der Ausgangsmodus des Vorgangs ist stets der Dateimodus. Der Blockmodus ist nur aktiv, wenn die fortlaufende Replikation im Dateimodus auf dem neuesten Stand ist. Der Übergang in und aus dem Blockmodus erfolgt mithilfe der Protokollkopierfunktion automatisch. Wenn die passive Kopie die aktuelle Protokolldatei anfordert, gibt diese Funktion an, dass die fortlaufende Replikation auf dem neuesten Stand ist (d. h. die Länge der Kopiewarteschlange ist 0) und das System automatisch vom Datei- in den Blockmodus wechseln soll.

Sie können feststellen, ob sich eine passive Datenbankkopie im Blockmodus befindet, indem Sie den Leistungsindikator Fortlaufende Replikation - Blockmodus aktiv im Leistungsobjekt MSExchange-Replikationsserver überprüfen. Jede Datenbankkopie weist eine eigene Instanz dieses Indikators auf. Wenn sich die passive Kopie im Blockmodus befindet, ist der Wert dieses Indikators auf 1 und im Blockmodus auf 0 festgelegt. Sie können den Wert dieses Indikators mithilfe der Cmdlets Get-Counter oder Get-WMIObject bestimmen (siehe die folgenden Beispiele):

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Änderungen am Transportdumpster im Vergleich zu Exchange 2007

Die Exchange 2010-Hub-Transport-Serverrolle umfasst eine Funktion, die als Transportdumpster bezeichnet wird und in Exchange 2007 erstmals eingeführt wurde. Der Transportdumpster schützt vor einem Datenverlust, indem eine Warteschlange aller E-Mail-Nachrichten verwaltet wird, die vor kurzem an Benutzer mit Postfächern gesendet wurden, die über CCR oder LCR geschützt werden. Tritt in einer dieser Umgebungen ein Fehler auf, der normalerweise zu einem Datenverlust führen würde, werden die vom Fehler betroffenen Daten automatisch durch den Transportdumpster wiederhergestellt.

Der Transportdumpster wird nur für replizierte Postfachdatenbanken verwendet. An Öffentliche Ordner gesendete Nachrichten werden ebenso wenig geschützt wie Nachrichten, die an Empfänger in nicht replizierten Postfachdatenbanken gesendet werden. Die Transportdumpster-Warteschlange für eine bestimmte Postfachdatenbank befindet sich auf allen Hub-Transport-Servern an den Active Directory-Standorten, die zur Database Availability Group gehören.

In Exchange 2007 verblieben Nachrichten im Transportdumpster, bis eine vom Administrator definierte Zeit- oder Größenbeschränkung erreicht wurde. In Exchange 2010 erhält der Transportdumpster jetzt Feedback von der Replikationspipeline und ermittelt anhand der empfangenen Informationen, welche Nachrichten zugestellt und repliziert wurden. Für jede Nachricht, die bei der Übermittlung in eine replizierte Postfachdatenbank einer Database Availability Group über die Hub-Transport-Server übertragen wird, verbleibt eine Nachrichtenkopie in der Transportwarteschlange (mail.que), bis die Transaktionsprotokolle, die die Nachricht darstellen, erfolgreich repliziert und von allen Kopien der Postfachdatenbank geprüft wurden. Nachdem die Protokolle repliziert und von allen Datenbankkopien geprüft wurden, werden die Nachrichten in diesen Protokollen vom Transportdumpster abgeschnitten. Auf diese Weise wird die Transportdumpster-Warteschlange klein gehalten, da nur Kopien der Nachrichten gespeichert werden, deren Transaktionsprotokolle noch nicht repliziert wurden.

Der Active Manager jeder DAG verfolgt den Wert des Zeitpunkts der letzten Protokollüberprüfung für jede passive Datenbankkopie nach. Der Active Manager-Client, der auf dem Hub-Transport-Server ausgeführt wird, ruft diese Informationen vom Standby Active Manager (SAM) ab und wandelt diese Informationen in einen zeitbasierten Grenzwert um. Der Hub-Transport-Server vergleicht anschließend den Übermittlungszeitpunkt von Nachrichten im Transportdumpster mit dem Grenzwert. Wenn der Übermittlungszeitpunkt einer Nachricht älter als der Grenzwert ist, schneidet der Transportdumpster die Nachricht ab.

Der Transportdumpster wurde außerdem erweitert, um den Änderungen an der Postfachserverrolle Rechnung zu tragen, die das Verschieben einer einzelnen Postfachdatenbank zwischen Active Directory-Standorten ermöglicht. Database Availability Groups können auf mehrere Active Directory-Standorte ausgeweitet werden, und als Ergebnis kann für eine einzelne Postfachdatenbank an einem Active Directory-Standort ein Failover auf einen anderen Active Directory-Standort durchgeführt werden. Wenn dieser Fall eintritt, werden alle Anforderungen für eine erneute Zustellung aus dem Transportdumpster an beide Active Directory-Standorte gesendet: den ursprünglichen Standort und den neuen Standort.

Änderungen am Routingverhalten, wenn sowohl Hub-Transport-Server als auch Postfachserver in einer DAG enthalten sind

Wenn der Hub-Transport-Server zusammen mit einem Postfachserver Mitglied einer DAG ist, ergeben sich Änderungen am Routingverhalten, um sicherzustellen, dass die Funktionen zur Ausfallsicherheit beider Serverrollen den erforderlichen Schutz für Nachrichten bereitstellen, die von Benutzern auf dem jeweiligen Server gesendet und empfangen werden. Die Hub-Transport-Serverrolle wurde dahingehend geändert, dass sie jetzt versucht, eine Nachricht für einen lokalen Postfachserver an einen anderen Hub-Transport-Server am gleichen Standort umzuleiten, wenn der Hub-Transport-Server ebenfalls ein Mitglied der DAG ist und über eine Kopie der lokal eingebundenen Postfachdatenbank verfügt. Dieser zusätzliche Hop wurde hinzugefügt, um die Nachricht im Transportdumpster auf einem anderen Hub-Transport-Server zu platzieren.

Der Server EX1 ist z. B. der Host für die Serverrollen Hub-Transport und Postfach und außerdem Mitglied einer DAG. Wenn eine Nachricht beim Transport für EX1 eintrifft, die an einen Empfänger gerichtet ist, dessen Postfach sich ebenfalls auf EX1 befindet, dann wird die Nachricht vom Transport an einen anderen Hub-Transport-Server an dem Standort (z. B. EX2) umgeleitet, und der Server stellt dann die Nachricht an das Postfach auf EX1 zu.

Es gibt eine zweite vergleichbare Verhaltensänderung hinsichtlich des Microsoft Exchange-Mailübergabediensts. Dieser Dienst wurde so geändert, dass Nachrichten nicht an eine lokale Hub-Transport-Serverrolle übermittelt werden, wenn Postfach- und Hub-Transport-Server Mitglied einer DAG sind. In diesem Szenario wird für einen Lastenausgleich für Übermittlungsanforderungen mithilfe von anderen Hub-Transport-Servern am selben Active Directory-Standort gesorgt und wieder auf den lokalen Hub-Transport-Server zurückgegriffen, wenn am selben Standort keine weiteren Hub-Transport-Server verfügbar sind.

Zurück zum Seitenanfang

Hohe Verfügbarkeit für Nicht-Postfachserverrollen

Hohe Verfügbarkeit wird bei den Serverrollen Hub-Transport, Edge-Transport, Clientzugriff und Unified Messaging durch eine Kombination aus Serverredundanz, Netzwerklastenausgleich und DNS-Roundrobin-Verfahren sowie durch eine proaktive Server-, Dienste- und Infrastrukturverwaltung erreicht. Im Allgemeinen können Sie für die Serverrollen Clientzugriff, Hub-Transport, Edge-Transport und Unified Messaging mithilfe der folgenden Strategien und Technologien hohe Verfügbarkeit erreichen:

  • Edge-Transport   Es können mehrere Edge-Transport-Server bereitgestellt werden. Für den Lastenausgleich von serverübergreifenden Aktivitäten können mehrere DNS MX-Einträge (Mail Exchanger) verwendet werden. Zur Bereitstellung von Lastenausgleich und hoher Verfügbarkeit für Edge-Transport-Server können Sie auch mit dem Netzwerklastenausgleich arbeiten.

  • Clientzugriff   Für die hohe Verfügbarkeit von Clientzugriffsservern können Netzwerklastenausgleich oder ein hardwarebasiertes Gerät eines anderen Herstellers für den Netzwerklastenausgleich verwendet werden.

  • Hub-Transport   Zur Sicherstellung der hohen Verfügbarkeit des internen Transports können mehrere Hub-Transport-Server bereitgestellt werden. Ausfallsicherheit wurde auf folgende Weise in die Hub-Transport-Serverrolle integriert:

    • Hub-Transport-Server zu Hub-Transport-Server (innerhalb der Organisation)   Die Kommunikation zwischen Hub-Transport-Servern innerhalb einer Organisation unterliegt automatisch einem Lastenausgleich zwischen den verfügbaren Hub-Transport-Servern am Active Directory-Zielstandort.

    • Postfachserver zu Hub-Transport-Server (innerhalb eines Active Directory-Standorts)   Der Exchange-Mailübergabedienst auf Postfachservern führt automatisch einen Lastenausgleich zwischen allen verfügbaren Hub-Transport-Servern am gleichen Active Directory-Standort aus.

    • Unified Messaging-Server zu Hub-Transport-Server   Der Unified Messaging-Server führt automatisch einen Lastenausgleich der Verbindungen zwischen allen verfügbaren Hub-Transport-Servern am gleichen Active Directory-Standort aus.

    • Edge-Transport-Server zu Hub-Transport-Server   Der Edge-Transport-Server führt automatisch einen Lastenausgleich des eingehenden SMTP-Datenverkehrs (Simple Mail Transfer Protocol) für alle Hub-Transport-Server am Active Directory-Standort aus, die der Edge-Transport-Server abonniert hat.

    Wenn Sie zusätzliche Redundanz wünschen (z. B. Anwendungen, die ein SMTP-Relay erfordern), können Sie einen neuen DNS-Eintrag (z. B. relay.company.com) erstellen, eine IP-Adresse zuweisen und ein Hardware-Lastenausgleichsmodul verwenden, um diese IP-Adresse an mehrere Hub-Transport-Server umzuleiten. Sie können den Netzwerklastenausgleich auch für die Clientconnectors auf Hub-Transport-Servern verwenden. Wenn ein Hardware-Lastenausgleichsmodul verwendet wird, müssen Sie bestätigen, dass kein organisationsinterner Datenverkehr das Hardware-Lastenausgleichsmodul durchläuft, da für den organisationsinternen Datenverkehr integrierte Lastenausgleichsalgorithmen verwendet werden (wie weiter oben beschrieben wird).

  • Unified Messaging   Unified Messaging-Bereitstellungen können zuverlässiger gestaltet werden, indem mehrere Unified Messaging-Server eingerichtet werden, von denen zwei oder mehrere einem einzelnen Satz mit Wähleinstellungen zugewiesen sind. Die von Unified Messaging unterstützten VoIP-Gateways (Voice over IP) können so konfiguriert werden, dass Anrufe an Unified Messaging-Server nach dem Roundrobin-Verfahren geroutet werden. Darüber hinaus können diese Gateways die Liste der Server für einen Satz mit Wähleinstellungen aus DNS abrufen. In beiden Fällen zeigen die VoIP-Gateways einen Anruf einem Unified Messaging-Server an. Wird der Anruf nicht angenommen, wird der Anruf einem weiteren Server angezeigt, wodurch zum Zeitpunkt des Anrufaufbaus Redundanz bereitgestellt wird.

Zurück zum Seitenanfang

Ausfallsicherheit für Standorte

Exchange 2010 bietet eine vereinheitlichte Plattform für hohe Verfügbarkeit und Ausfallsicherheit für Standorte. Durch die Kombination der systemeigenen Ausfallsicherheit für Standorte in Exchange 2010 und einer guten Planung kann ein zweites Datencenter schnell zur Bereitstellung von Diensten für die Clients des ausgefallenen Datencenters aktiviert werden. Der Ausfall eines Datencenters oder Standorts wird anders gehandhabt als Ausfälle, die ein Failover eines Servers oder einer Datenbank auslösen können. In einer Konfiguration für hohe Verfügbarkeit wird die automatische Wiederherstellung vom System gestartet, und trotz des Ausfalls ist das Messagingsystem in der Regel voll funktionsfähig. Im Gegensatz dazu ist ein Datencenterausfall ein Ereignis, das eine Notfallwiederherstellung erfordert. Die Wiederherstellung muss manuell erfolgen und abgeschlossen werden, damit der Clientdienst wiederhergestellt werden und der Ausfall ein Ende findet. Der dazu ausgeführte Vorgang wird als Datencenterswitchover bezeichnet. Wie bei den meisten Notfallwiederherstellungsszenarien erleichtern eine Vorabplanung und -vorbereitung eines Datencenterswitchovers den Prozess der Wiederherstellung und verkürzen die Dauer des Ausfalls.

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

Zurück zum Seitenanfang

End-to-End-Verfügbarkeit

Exchange 2010 enthält außerdem viele Funktionen, die zum Erhöhen der End-to-End-Verfügbarkeit des Systems entworfen wurden. Zu diesen Funktionen zählen die folgenden:

  • Shadow-Redundanz

  • Onlineverschiebung von Postfächern

  • Flexibler Postfachschutz

  • Inkrementelle Neusynchronisierung

  • API für die Drittanbieterreplikation

Shadow-Redundanz

Zusätzlich zum Transportdumpster und dem zuvor beschriebenen geänderten Routingverhalten wurde die neue Hub-Transport-Serverfunktion Shadow-Redundanz hinzugefügt. Die Shadow-Redundanz stellt Redundanz für Nachrichten während ihrer Übermittlung bereit. Diese Lösung beruht auf einer Technik, die dem Transportdumpster ähnelt. Bei der Shadow-Redundanz wird das Löschen einer Nachricht aus der Transportdatenbank verzögert, bis der Transportserver überprüft hat, ob alle folgenden Hops für diese Nachricht die Zustellung abgeschlossen haben. Wenn einer der nächsten Hops einen Fehler verursacht, bevor eine erfolgreiche Zustellung gemeldet wird, wird die Nachricht erneut an diesen nächsten Hop gesendet. Weitere Informationen zur Shadow-Redundanz finden Sie unter Grundlegendes zur Shadow-Redundanz.

Onlineverschiebung von Postfächern

Exchange 2010 enthält eine neue Funktion, die es Ihnen ermöglicht, Postfächer asynchron zu verschieben. Wenn Sie in Exchange 2007 das Cmdlet Move-Mailbox zum Verschieben eines Postfachs verwendet haben, meldete sich das Cmdlet sowohl bei der Quelldatenbank als auch bei der Zieldatenbank an und verschob die Inhalte des einen Postfachs in ein anderes Postfach. Das Verschieben von Postfächern mithilfe von Cmdlets hatte verschiedene Nachteile:

  • Postfachverschiebungen dauerten üblicherweise Stunden, und während des Verschiebens konnten die Benutzer nicht auf ihr Postfach zugreifen.

  • Wenn das zum Ausführen des Cmdlets Move-Mailbox verwendete Befehlsfenster geschlossen wurde, wurde der Verschiebungsvorgang abgebrochen und musste neu gestartet werden.

  • Der zum Ausführen des Verschiebungsvorgangs verwendete Computer war an der Datenübertragung beteiligt. Wenn ein Administrator die Cmdlets von seiner Arbeitsstation ausführte, wurden die Postfachdaten vom Quellserver zur Arbeitsstation des Administrators und dann zum Zielserver übertragen.

Das neue Cmdlet New-MoveRequest in Exchange 2010 kann zum Durchführen asynchroner Verschiebungsvorgänge verwendet werden. Anders als in Exchange 2007 führen die Cmdlets den eigentlichen Verschiebungsvorgang nicht aus. Die Verschiebung erfolgt durch den Microsoft Exchange-Postfachreplikationsdienst, einen neuen Dienst, der auf dem Clientzugriffsserver ausgeführt wird. Das Cmdlet New-MoveRequest sendet Anforderungen an den Microsoft Exchange-Postfachreplikationsdienst. Weitere Informationen zu Onlineverschiebungen von Postfächern finden Sie unter Grundlegendes zu Verschiebungsanforderungen.

Flexibler Postfachschutz

Es gibt verschiedene Änderungen an der grundlegenden Architektur von Exchange 2010, die direkte Auswirkungen darauf haben, wie Sie Ihre Postfachdatenbanken und die darin enthaltenen Postfächer schützen.

Eine bedeutende Änderung ist das Entfernen von Speichergruppen. In Exchange 2010 ist jede Datenbank einem Protokolldatenstrom zugeordnet, der aus einer Folge von 1 MB (Megabyte) großen Protokolldateien besteht. Jeder Server kann als Host für maximal 100 Datenbanken fungieren.

Eine weitere bedeutende Änderung in Exchange 2010 ist, dass Datenbanken nicht länger eng an einen bestimmten Postfachserver gebunden sind. Die Datenbankmobilität erweitert die Verwendung der fortlaufenden Replikation des Systems, indem eine Datenbank auf mehrere verschiedene Server repliziert wird. Dies bietet einen besseren Schutz der Datenbank und eine höhere Verfügbarkeit. Falls Fehler auftreten, können die anderen Server, die Kopien der Datenbank besitzen, diese Datenbank einbinden.

Die Möglichkeit, mehrere Kopien einer Datenbank auf mehreren Servern zu hosten, bedeutet, dass Sie diese Datenbankkopien bei ausreichender Anzahl als Sicherungen verwenden können. Weitere Informationen zu dieser Vorgehensweise finden Sie unter Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung.

Inkrementelle Neusynchronisierung

In Exchange 2007 wurden die Konzepte der Flexibilität für verlorene Protokolle (Lost Log Resilience, LLR) und des erneuten inkrementellen Seedings eingeführt. Die Flexibilität der verlorenen Protokolle (Lost Log Resilience, LLR) ist eine interne Komponente von ESE (Extensible Storage Engine), mit der Sie Exchange-Postfachdatenbanken wiederherstellen können, auch wenn mindestens eine der kürzlich generierten Transaktionsprotokolldateien verloren gegangen ist oder beschädigt wurde. LLR ermöglicht das Einbinden einer Postfachdatenbank auch dann, wenn vor kurzem generierte Protokolldateien nicht verfügbar sind. Bei LLR werden Schreibvorgänge in die Datenbank verzögert, bis die angegebene Anzahl von Protokollgenerierungen erzeugt wurde. LLR verzögert aktuelle Updates der Datenbank für eine kurze Zeit. Die Dauer der Verzögerung für die Schreibvorgänge ist davon abhängig, wie schnell Protokolle generiert werden.

In Exchange 2007 wurde auch das Konzept des erneuten inkrementellen Seedings eingeführt, mit dem Abweichungen im Transaktionsprotokollstrom zwischen einer Quell- und einer Zielspeichergruppe korrigiert werden, indem auf die verzögerten Wiedergabefunktionen von LLR vertraut wird. Das erneute inkrementelle Seeding bot keine Möglichkeiten zum Korrigieren der Abweichungen in der passiven Kopie einer Datenbank, nachdem abweichende Protokolle wiedergegeben wurden, wodurch ein vollständiges erneutes Seeding erforderlich wurde. Im Gegensatz zu Exchange 2007 gibt es in Exchange 2010 keine Protokollverluste, die ein erneutes Seeding erfordern.

In Exchange 2010 ist inkrementelle Neusynchronisierung der neue Name für die Funktion, mit der Abweichungen in Datenbankkopien unter den folgenden Bedingungen automatisch korrigiert werden:

  • Nach einem automatischen Failover für alle konfigurierten Kopien einer Datenbank

  • Wenn eine neue Kopie aktiviert wird und einige Datenbank- und Protokolldateien bereits an der Kopierposition vorhanden sind

  • Wenn die Replikation nach einer Unterbrechung fortgesetzt wird oder der Microsoft Exchange-Replikationsdienst neu gestartet wurde

Als Ergebnis dieser Änderungen ist die Flexibilität der verlorenen Protokolle nun für alle Exchange 2010-Postfachdatenbanken in einer Protokolldatei hartcodiert.

Wenn die Abweichung zwischen einer aktiven Datenbank und einer Kopie dieser Datenbank erkannt wird, führt die inkrementelle Neusynchronisierung die folgenden Tasks aus:

  • Sie durchsucht den Protokolldateistrom, um den Beginn der Abweichung zu ermitteln.

  • Sie sucht die geänderten Datenbankseiten in der abweichenden Kopie.

  • Sie liest die geänderten Seiten aus der aktiven Kopie und kopiert dann die erforderlichen Protokolldateien aus der aktiven Kopie.

  • Sie übernimmt die Änderungen der Datenbankseiten in die abweichende Kopie.

  • Sie führt die Wiederherstellung für die abweichende Kopie aus und gibt die erforderlichen Protokolldateien in der Datenbankkopie wieder.

API für die Drittanbieterreplikation

Exchange 2010 enthält eine neue 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 vordefinierte 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-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. Weitere Informationen zu Partnerprodukten für Exchange 2010 finden Sie auf der Website Microsoft Exchange-Partner.

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.