Grundlegendes zu hoher Verfügbarkeit und Ausfallsicherheit von Standorten

  • Artikel

Gilt für: Exchange Server 2010

Letztes Änderungsdatum des Themas: 2009-12-07

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

Datenbankverfügbarkeitsgruppen

Postfachdatenbankkopien

Active Manager

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

Hohe Verfügbarkeit für Nicht-Postfachserverrollen

End-to-End-Verfügbarkeit

Wichtige Terminologie

Es werden die folgenden Begriffe verwendet:

  • Datenbankverfügbarkeitsgruppe (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 Datenbankverfügbarkeitsgruppen 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 neuer Dienst, der einen MAPI-Endpunkt für Outlook-Clients bereitstellt.
  • Ausfallsicherheit von Standorten
    Ein manueller Prozess zur Notfallwiederherstellung, um eine Wiederherstellung nach einem vollständigen Standortausfall durchzuführen. 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
    Abkürzung für Switchover und Failover. Ein Switchover ist die manuelle Aktivierung einer oder mehrerer Datenbanken. Ein Failover ist die automatische Aktivierung einer oder mehrerer Datenbanken nach einem Ausfall.

Nach oben

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 dieser größeren 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.

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 Datenbankverfügbarkeitsgruppe 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.

Nach oben

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. Datenbankmobilität erweitert die vom System verwendete fortlaufende Replikation durch das Replizieren einer Datenbank auf mehrere unterschiedliche Server, die einer Gruppe angehören. 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.

Nach oben

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 Datenbankverfügbarkeitsgruppen 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.

Nach oben

Datenbankverfügbarkeitsgruppen

Eine Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) ist die Basiskomponente des Systems für hohe Verfügbarkeit und Ausfallsicherheit für Standorte in Exchange 2010. Eine Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe kann als Host für eine Kopie einer Postfachdatenbank eines beliebigen anderen Servers in der Datenbankverfügbarkeitsgruppe fungieren. Wenn ein Server einer Datenbankverfügbarkeitsgruppe hinzugefügt wird, wird dieser mit den anderen Servern in der Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG). Nachdem einer Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppen finden Sie unter Grundlegendes zu Datenbankverfügbarkeitsgruppen.

Nach oben

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 Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe 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.

Nach oben

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.

Nach oben

Ä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 2007

Die zugrunde liegende Technologie für die fortlaufende Replikation in CCR- und SCR-Umgebungen bleibt in Exchange 2010 erhalten und wurde zur Unterstützung neuer Hochverfügbarkeitsfunktionen erweitert. Unter anderem wurden die folgenden Architekturänderungen vorgenommen:

  • Da Speichergruppen aus Exchange 2010 entfernt wurden, erfolgt die fortlaufende Replikation nun auf Datenbankebene. Exchange 2010 verwendet weiterhin eine ESE-Datenbank (Extensible Storage Engine) zum Erzeugen von Transaktionsprotokollen. Diese Transaktionsprotokolle werden an einen oder mehrere Standorte repliziert und in einer oder mehreren Postfachdatenbankkopien wiedergegeben. Jede Postfachdatenbank kann über maximal 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 Datenbankverfügbarkeitsgruppe 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, sodass die Fähigkeit zum Verringern von E/A-Lesevorgängen erheblich reduziert ist. 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 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 Datenbankverfügbarkeitsgruppe 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 sich auf ihrem Weg in eine replizierte Postfachdatenbank einer Datenbankverfügbarkeitsgruppe über die Hub-Transport-Server bewegt, verbleibt eine Nachrichtenkopie in der Transportwarteschlange (mail.que), bis die Replikationspipeline den Hub-Transport-Server darüber benachrichtigt, dass die Nachricht erfolgreich repliziert und von allen Kopien der Postfachdatenbank geprüft wurde. Nachdem die Protokolle repliziert und von allen Datenbankkopien geprüft wurden, werden sie 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 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. Datenbankverfügbarkeitsgruppen 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 Datenbankverfügbarkeitsgruppe enthalten sind

Wenn der Hub-Transport-Server zusammen mit einem Postfachserver Mitglied einer Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe. 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 Datenbankverfügbarkeitsgruppe 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.

Nach oben

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.

Nach oben

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 zur Onlineverschiebung 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 Strategie 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.

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. Weitere Informationen zu Partnerprodukten für Exchange 2010 finden Sie auf der Website Microsoft Exchange-Partner. Wenn Sie ein Partner sind, der nach Informationen zur Drittanbieter-API sucht, wenden Sie sich an Ihren Ansprechpartner bei Microsoft.

Nach oben