Neue Funktionalität für hohe Verfügbarkeit und Ausfallsicherheit von Standorten

Gilt für: Exchange Server 2010 SP2

Letztes Änderungsdatum des Themas: 2016-11-28

Microsoft Exchange Server 2010 verringert die Kosten und die Komplexität für die Bereitstellung einer E-Mail-Lösung, die Serververfügbarkeit und Ausfallsicherheit von Standorten im höchsten Maße bietet. Beruhend auf den einheitlichen Replikationsfunktionen, die in Exchange Server 2007 eingeführt wurden, stellt die neue Architektur für hohe Verfügbarkeit in Exchange 2010 ein vereinfachtes, vereinheitlichtes Gerüst sowohl für hohe Verfügbarkeit als auch für Wiederherstellung bereit. In Exchange 2010 ist die hohe Verfügbarkeit in der grundlegenden 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.

Gelernte Lektionen in Exchange Server 2007

Durch Exchange 2007 wurden die Kosten für die hohe Verfügbarkeit verringert und die Ausfallsicherheit von Standorten wesentlich kostengünstiger gestaltet, indem neue Technologien eingeführt wurden, z. B. die fortlaufende lokale Replikation (Local Continuous Replication, LCR), die fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR) und die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR). Dennoch sind einige Herausforderungen geblieben:

• Manche Administratoren wurden durch die Komplexität des Windows-Failoverclusterings eingeschüchtert.

• 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 einem Fehler für eine einzelne Datenbank auf einem großen Postfachserver konnte für alle Benutzer auf dem Postfachserver zu einer temporären Dienstunterbrechung führen.

• Lösungen für die Ausfallsicherheit von Standorten arbeiteten nicht reibungslos.

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

In Exchange 2010 sind wichtige grundlegende Änderungen enthalten, die die hohe Verfügbarkeit zu einem festen Bestandteil der Architektur machen, wodurch diese für alle Kunden noch kostengünstiger und einfacher bereitzustellen und zu verwalten ist als in Exchange 2007. Unternehmen können jetzt eine vollständig redundante Exchange-Organisation mit nur zwei Servern bereitstellen und von Failovervorgängen auf Datenbankebene profitieren. Kunden profitieren von automatischen Failoverfunktionen auf Datenbankebene, ohne zu Experten für das Windows-Failoverclustering werden zu müssen. Darüber hinaus gestaltet sich das Hinzufügen der Ausfallsicherheit von Standorten zu vorhandenen Bereitstellungen mit hoher Verfügbarkeit weniger komplex.

In Exchange 2007 wurden viele neue Änderungen an der Architektur eingeführt, die dazu gedacht waren, Lösungen für hohe Verfügbarkeit und Ausfallsicherheit von Standorten schneller und einfacher für Exchange bereitstellen zu können. Diese Verbesserungen umfassten ein integriertes Setup, optimierte Konfigurationseinstellungen und die Möglichkeit, die meisten Aspekte der Lösung für hohe Verfügbarkeit mithilfe einheitlicher Exchange-Verwaltungstools zu verwalten.

Dennoch erforderte die Verwaltung einer Exchange 2007-Lösung für hohe Verfügbarkeit von den Administratoren die Kenntnis einiger Konzepte des Clusterings, z. B. das Konzept zum Verschieben von Netzwerkidentitäten und zum Verwalten von Clusterressourcen. Außerdem mussten die Administratoren bei der Behandlung von Problemen, die sich auf Postfachclusterserver bezogen, Exchange-Tools und Clustertools verwenden, um Protokolle und Ereignisse aus zwei verschiedenen Quellen zu überprüfen und in Beziehung zu setzen: von Exchange und vom Cluster.

Auf Grundlage des Kundenfeedbacks wurden zwei weitere einschränkende Aspekte der Exchange 2007-Architektur erneut bewertet 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 die vollständige Redundanz für die Hauptkomponenten einer Bereitstellung zu erzielen, d. h. die grundlegenden Serverrollen (Postfach, Hub-Transport und Clientzugriff).

• In Exchange 2007 erfolgt das Failover für einen Postfachclusterserver auf Serverebene. Wenn dann ein einzelner Datenbankfehler aufgetreten ist, musste der Administrator ein Failover für den gesamten Postfachclusterserver auf einen anderen Knoten im Cluster durchführen (was für alle Benutzer auf dem Server zu kurzen Ausfallzeiten geführt hat und nicht nur für die Benutzer mit einem Postfach in der betroffenen Datenbank), oder er musste die Benutzer der fehlerhaften Datenbank (möglicherweise für Stunden) offline lassen, während die Datenbank aus der Sicherung wiederhergestellt wurde.

Ausfallsicherheit von Postfächern

Exchange 2010 wurde um das Konzept der Ausfallsicherheit von Postfächern erweitert. Die Architektur wurde so geändert, dass der automatische Failoverschutz jetzt auf den einzelnen Postfachdatenbankebenen bereitgestellt wird, anstatt wie früher auf Serverebene. In Exchange 2010 wird dies als Datenbankmobilität bezeichnet. Als Ergebnis dieser und weiterer Architekturänderungen am Datenbankcache werden Failoveraktionen jetzt sehr viel schneller ausgeführt als in früheren Versionen von Exchange. Das Failover für einen Postfachclusterserver in einer CCR-Umgebung, in der Exchange 2007 mit Service Pack 2 (SP2) ausgeführt wird, wird in ungefähr zwei Minuten abgeschlossen. Zum Vergleich: Das Failover einer Postfachdatenbank in einer Exchange 2010-Umgebung wird in 30 Sekunden oder weniger abgeschlossen (gemessen ab dem Zeitpunkt, an dem der Fehler erkannt wurde, bis zum Einbinden einer Datenbankkopie, unter der Annahme, dass eine verfügbare, fehlerfreie und aktuelle Kopie mit Protokollwiederherstellung verwendet wird). Die Kombination von Failover auf Datenbankebene und einer wesentlich schnelleren Failoverausführung verbessert die Verfügbarkeit eines Unternehmens grundlegend.

Die Architektur für die Ausfallsicherheit von Postfächern, die in Exchange 2010 integriert ist, bietet neue Vorteile für Unternehmen und ihre Messagingadministratoren:

• Auf Servern mit hoher Verfügbarkeit können mehrere Serverrollen gleichzeitig vorhanden sein. Dadurch können kleine Unternehmen eine aus zwei Servern bestehende Konfiguration bereitstellen, die eine Redundanz der Postfachdaten und des Diensts bietet, während darüber hinaus redundante Clientzugriff- und Hub-Transport-Dienste zur Verfügung gestellt werden.

• Der Administrator muss nicht länger einen Failovercluster erstellen, um hohe Verfügbarkeit zu erreichen. Failovercluster werden jetzt für den Administrator unsichtbar von Exchange 2010 erstellt. Anders als bei früheren Versionen von Exchange-Clustern, die eine von Exchange bereitgestellte Clusterressourcen-DLL (ExRes.dll) verwendeten, ist die Clusterressourcen-DLL in Exchange 2010 nicht länger erforderlich und wird auch nicht mehr verwendet. Exchange 2010 ist keine Clusteranwendung und verwendet nur einen kleinen Teil der Failoverclusterkomponenten, z. B. die Taktfunktionen und die Clusterdatenbank, um die Datenbankmobilität bereitzustellen.

• Die Administratoren können die hohe Verfügbarkeit zu ihrer Exchange 2010-Umgebung hinzufügen, nachdem Exchange bereitgestellt wurde, ohne Exchange deinstallieren und anschließend in einer Konfiguration mit hoher Verfügbarkeit erneut bereitstellen zu müssen.

• Exchange 2010 bietet eine Ansicht des Ereignisstroms, der die Ereignisse des Betriebssystems mit den Ereignissen von Exchange kombiniert.

• Da Speichergruppenobjekte in Exchange 2010 nicht länger vorhanden und Postfachdatenbanken über alle Exchange 2010-Postfachserver hinweg portierbar sind, ist das Verschieben von Datenbanken bei Bedarf einfach.

Weitere Informationen finden Sie unter Hohe Verfügbarkeit und Ausfallsicherheit für Standorte.

Flexibler Postfachschutz

In Exchange 2010 sind verschiedene neue Funktionen und grundlegende Änderungen enthalten, die bei ordnungsgemäßer Bereitstellung und Konfiguration einen flexiblen Postfachschutz bieten können, der die Notwendigkeit beseitigt, herkömmliche Sicherungen Ihrer Daten zu erstellen. Durch die Verwendung der in Exchange 2010 integrierten Funktionen für hohe Verfügbarkeit zum Minimieren von Ausfallzeiten und Datenverlusten bei Notfällen können auch die Gesamtkosten des Messagingsystems verringert werden. Die Kombination dieser Funktionen mit anderen integrierten Funktionen, z. B. der rechtlichen Aufbewahrungspflicht, ermöglicht Unternehmen, ihre Abhängigkeit von herkömmlichen Sicherungen zu bestimmten Zeitpunkten zu verringern oder zu beseitigen und die daraus resultierenden Kosteneinsparungen zu erzielen.

Zusätzlich zu der Feststellung, ob Exchange 2010 es Ihnen ermöglicht, von der herkömmlichen Sicherung zu bestimmten Zeitpunkten abzusehen, wird außerdem empfohlen, die Kosten für die aktuelle Sicherungsinfrastruktur abzuschätzen. Beachten Sie die Kosten der Ausfallzeit für Endbenutzer und der Datenverluste bei dem Versuch der Wiederherstellung nach einem Notfall unter Verwendung der vorhandenen Sicherungsinfrastruktur. Berücksichtigen Sie auch die Kosten für Hardware, Installation und Lizenzen ein sowie die Verwaltungskosten, die mit der Wiederherstellung von Daten und der Pflege von Sicherungen einhergehen. In Abhängigkeit von den Anforderungen in Ihrem Unternehmen ist es sehr wahrscheinlich, dass eine reine Exchange 2010-Umgebung mit mindestens drei Postfachdatenbankkopien geringere Gesamtkosten mit sich bringt als eine Umgebung mit Sicherungen.

Weitere Informationen zum flexiblen Postfachschutz finden Sie unter Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung.

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

Exchange 2010 umfasst viele Änderungen an der grundlegenden Architektur. Exchange 2010 vereint die wesentlichen Verfügbarkeits- und Flexibilitätsfunktionen von CCR und SCR in einer Lösung für hohe Verfügbarkeit, die sowohl standortinterne als auch standortexterne Datenreplikation bietet. Postfachserver können als Teil einer Database Availability Group (DAG) definiert werden, um eine automatische Wiederherstellung der einzelnen Postfächer auf Datenbankebene statt auf Serverebene bereitzustellen. Jede Postfachdatenbank kann bis zu 16 Kopien besitzen. In Exchange 2010 werden weitere neue Konzepte für Hochverfügbarkeit eingeführt, z. B. die Datenbankmobilität und die inkrementelle Bereitstellung. Das Konzept eines Unternehmens ohne Sicherungen und RAID werden ebenfalls in Exchange 2010 vorgestellt.

Zusammenfassend lassen sich die Hauptaspekte der Daten- und Dienstverfügbarkeit für Postfachserverrolle und Postfachdatenbanken wie folgt benennen:

• Exchange 2010 verwendet eine verbesserte Version derselben Technologie für fortlaufende Replikation, die in Exchange 2007 eingeführt wurde. Weitere Informationen finden Sie weiter unten in diesem Thema im Abschnitt Änderungen an der fortlaufenden Replikation von Exchange Server 2007.

• Speichergruppen sind in Exchange 2010 nicht mehr vorhanden. Stattdessen gibt es einfach Postfachdatenbanken, Postfachdatenbankkopien und Öffentliche Ordner-Datenbanken. Die primären Verwaltungsschnittstellen für Exchange-Datenbanken wurden innerhalb der Exchange-Verwaltungskonsole vom Knoten "Postfach" unter Serverkonfiguration zum Knoten "Postfach" unter Organisationskonfiguration verschoben.

• Windows-Failoverclustertechnologie wird auch in Exchange 2010 verwendet, aber sie wird jetzt vollständig von Exchange verwaltet. Administratoren müssen bei der Bereitstellung von hochverfügbaren Postfachservern keinerlei Aspekte des Failoverclusterings installieren, erstellen oder konfigurieren.

• Jeder Postfachserver kann als Host für bis zu 100 Datenbanken fungieren, und jede Datenbank kann wiederum bis zu 16 Kopien besitzen.

• Zusätzlich zum Transportdumpster wurde die neue Hub-Transport-Serverfunktion Shadow-Redundanz hinzugefügt. Die Shadow-Redundanz stellt Redundanz für Nachrichten während ihrer Übermittlung bereit. Die Lösung basiert auf einer Technik ähnlich dem Transportdumpster. Bei der Shadow-Redundanz wird das Löschen einer Nachricht aus der Transportdatenbank verzögert, bis der Transportserver überprüft hat, dass alle folgenden Hops für diese Nachricht die Zustellung abgeschlossen haben. Wenn bei einem der nächsten Hops ein Fehler auftritt, bevor die erfolgreiche Zustellung gemeldet wurde, wird die Nachricht erneut an diesen nächsten Hop zugestellt. Weitere Informationen zur Shadow-Redundanz finden Sie unter Grundlegendes zur Shadow-Redundanz.

Inkrementelle Bereitstellung

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 Prozess wurde ein spezieller Postfachserver erstellt, der als Postfachclusterserver bezeichnet wurde (oder als virtueller Exchange-Server in früheren Versionen von Exchange). Wenn Sie bereits die Exchange-Programmdateien auf einem Server ohne Cluster installiert hatten und sich dann für einen Postfachclusterserver entschlossen haben, mussten Sie einen Cluster mithilfe neuer Hardware erstellen oder Exchange vom vorhandenen Server entfernen, das Failoverclustering installieren und dann Exchange erneut installieren.

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.

Database Availability Groups

Eine Database Availability Group (DAG) besteht aus bis zu 16 Postfachservern, die 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 einer DAG ein Server hinzugefügt wird, wird dieser mit den anderen Servern in der DAG eingesetzt, um eine automatische Wiederherstellung nach Fehlern zu bieten, die Postfachdatenbanken betreffen, z. B. Datenträger- oder Serverfehler.

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

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, die Unterstützung für bis zu 16 Kopien einer einzelnen Datenbank hinzugefügt und eine einheitliche Vorgehensweise beim Hinzufügen von Datenbankkopien zu einer Datenbank bereitgestellt. In Exchange 2007 konnten Sie mithilfe einer Funktion, die als "Datenbankportabilität" bezeichnet wurde, auch eine Postfachdatenbank zwischen Servern verschieben. Ein Hauptunterschied zwischen der Datenbankportabilität und der Datenbankmobilität ist jedoch, dass bei der Datenbankmobilität alle Kopien einer Datenbank dieselbe GUID besitzen.

Weitere wichtige Merkmale der Datenbankmobilität:

• Da es in Exchange 2010 keine Speichergruppen meht gibt, wird die fortlaufende Replikation jetzt auf Datenbankebene ausgeführt. In Exchange 2010 werden Transaktionsprotokolle auf mindestens einen Postfachserver repliziert und in einer Kopie einer Postfachdatenbank wiedergegeben, die auf diesen Servern gespeichert wird.

• Ein Failover ist ein automatischer Aktivierungsprozess, der entweder auf Datenbankebene oder auf Serverebene auftreten kann. Ein Switchover ist ein manueller Aktivierungsprozess, den Sie auf Datenbank-, Server- oder Datencenterebene (Standort) ausführen können.

• Datenbanknamen für Exchange 2010 müssen innerhalb der Exchange-Organisation eindeutig sein.

• Wenn eine Postfachdatenbank mit mindestens einer Datenbankkopie konfiguriert wurde, muss der vollständige Pfad für alle Datenbankkopien auf allen Postfachservern identisch sein, die als Host einer Kopie fungieren.

• Jede Postfachdatenbankkopie (die aktive oder eine beliebige passive Kopie) kann mithilfe einer Exchange-abhängigen VSS-basierten (Volume Shadow Copy Service, Volumenschattenkopie-Dienst) Sicherungsanwendung gesichert werden.

Weitere Informationen zu Postfachdatenbankkopien finden Sie unter Grundlegendes zu Postfachdatenbankkopien.

Änderungen an der fortlaufenden Replikation von Exchange Server 2007

Die zugrunde liegende Technologie für fortlaufende Replikation, die bereits in CCR und SCR enthalten war, bleibt in Exchange 2010 erhalten und wurde weiterentwickelt, um neue Funktionen für hohe Verfügbarkeit zu unterstützen, z. B. Datenbankkopien, Datenbankmobilität und DAGs. Einige dieser neuen Änderungen an der Architektur werden wie folgt kurz beschrieben:

• Da es in Exchange 2010 keine Speichergruppen mehr gibt, wird die fortlaufende Replikation jetzt auf Datenbankebene ausgeführt. In Exchange 2010 wird weiterhin eine ESE-Datenbank (Extensible Storage Engine) verwendet, die Transaktionsprotokolle erzeugt, die an mindestens einen Standort repliziert und in mindestens einer Kopie einer Postfachdatenbank wiedergegeben werden.

• Da die vom Microsoft Exchange-Replikationsdienst in Exchange 2007 ausgeführte Funktion zur Protokollwiedergabe in die Version Exchange 2010 des Microsoft Exchange-Informationsspeicherdiensts (store.exe) verschoben wurde, tritt der den Failover- und Switchovervorgängen zugeordnete Leistungseinbruch nicht länger auf (da ein neuer Datenbankcache eingesetzt wurde). Wenn ein Failover- oder Switchovervorgang auftritt, verfügt die aktivierte Datenbank über einen jederzeit einsatzbereiten Cache.

• Beim Protokollversand und Seeding wird nicht länger der SMB (Server Message Block) für die Datenübertragung eingesetzt. Die fortlaufende Exchange 2010-Replikation verwendet einen TCP-Port für die Datenübertragung, der von einem einzelnen Administrator festgelegt wurde. Zusätzlich umfasst Exchange 2010 integrierte Optionen für die Netzwerkverschlüsselung und Komprimierung des Datenstroms.

• Beim Protokollversand wird kein Pull-Modell mehr verwendet, bei dem die passive Kopie geschlossene Protokolldateien von der aktiven Kopie abzieht. Stattdessen schiebt die aktive Kopie die Protokolldateien zu den einzelnen konfigurierten passiven Kopien.

• 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 das Seeding und erneute Seeding von Datenbankenkopien angegeben werden.

• Datenbankkopien sind nur für Postfachdatenbanken verfügbar. Um für Öffentliche Ordner-Datenbanken Redundanz und Hochverfü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, kann jede DAG eine Öffentliche Ordner-Datenbank hosten, und Sie können die Replikation Öffentlicher Ordner verwenden, um Öffentliche Ordner zwischen auf DAG-Mitgliedern gehosteten Öffentliche Ordner-Datenbanken zu replizieren.

• Die LogReplayer-Komponente des Microsoft Exchange-Replikationsdiensts enthält neue Logik zum Anhalten der Protokollwiedergabe, wenn die Länge der Kopiewarteschlange einen bestimmten Schwellenwert überschreitet. Wenn die Anzahl der Protokolle in der Kopiewarteschlange größer ist als die Anzahl der Protokolldateien, die in die passive Datenbankkopie kopiert, von der passiven Kopie aber nicht überprüft wurden, hält der Microsoft Exchange-Replikationsdienst die Protokollwiedergabe für die passive Kopie an und schreibt Warnereignis 4110 in das Ereignisprotokoll. Wenn die Anzahl der Protokolldateien in der Kopiewarteschlange unter die Anzahl der nicht überprüften kopierten Protokolldateien fällt, setzt der Microsoft Exchange-Replikationsdienst die Wiedergabe der passiven Kopie fort und schreibt Informationsereignis 4111 in das Ereignisprotokoll.

Verschiedene bei der fortlaufenden Exchange 2007-Replikation verwendete Konzepte werden auch weiterhin in Exchange 2010 verwendet. Dazu gehören die Konzepte der Failoververwaltung, der Abweichung, der Verwendung von AutoDatabaseMountDial sowie der Verwendung von öffentlichen und privaten Netzwerken.

Ä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 diesem 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 DAG-Mitglied ist und wenn er ü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 Hub-Transport- und Postfachserverrolle und außerdem ein 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 in das Postfach auf EX1 zu.

Es gibt eine weitere vergleichbare Verhaltensänderung hinsichtlich des Microsoft Exchange-Mailübergabediensts. Dieser Dienst wurde so geändert, dass er es vorzieht, Nachrichten nicht an eine lokale Hub-Transport-Serverrolle zu übermitteln, 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 an demselben Active Directory-Standort gesorgt und wieder auf den lokalen Hub-Transport-Server zurückgegriffen, wenn an demselben Standort keine weiteren Hub-Transport-Server verfügbar sind.

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:

• Transportausfallsicherheit

• Onlineverschiebung von Postfächern

• Systemeigener Exchange-Datenschutz

• Inkrementelle Neusynchronisierung

• Replikations-API von Drittanbietern

Transportausfallsicherheit

In Exchange 2007 wurde der Transportdumpster des Hub-Transport-Servers eingeführt. Der Transportdumpster verwaltet eine Warteschlange mit Nachrichten, die an Empfänger gesendet wurden, deren Postfächer sich in einer Umgebung mit fortlaufender Clusterreplikation (und in Exchange 2007 SP1 in einer Umgebung mit fortlaufender lokaler Replikation) befunden haben. Diese Funktion wurde entwickelt, um dem Administrator zum Schutz vor Datenverlusten die Möglichkeit zu geben, einen Postfachclusterserver bei minimalen Datenverlusten auf einem anderen Knoten automatisch online verfügbar zu machen. Dies wird als Failover mit Datenverlust bezeichnet. Bei einem Failover mit Datenverlust stellte das System automatisch alle zuletzt gesendeten E-Mail-Nachrichten an die Benutzer auf dem Postfachclusterserver, auf dem der Fehler aufgetreten war, erneut zu, wobei der Transportdumpster verwendet wurde, in dem die E-Mail-Nachrichten noch vorhanden waren. Obwohl mit dieser Lösung der Datenverlust bei einem Failover mit Datenverlust minimiert werden konnte, bot die Lösung nur Schutz bei Datenverlust innerhalb eines Standorts, nicht aber für Nachrichten während der Übertragung.

In Exchange 2010 werden Änderungen an der grundlegenden Architektur eingeführt, die beide Probleme berücksichtigen. Da DAGs sich über mehrere Active Directory-Standorte erstrecken können, ist es für eine einzelne Postfachdatenbank möglich, zwischen Active Directory-Standorten zu wechseln. Aufgrund dieser Entwurfsänderung wird die Anforderung des Transportdumpsters zur erneuten Zustellung bei einem verlustbehafteten Datenbankfailover jetzt an Hub-Transport-Server gerichtet, die sich sowohl am ursprünglichen als auch am neuen Active Directory-Standort der Datenbank befinden.

Eine weitere entscheidende Änderung des Transportdumpsters ist, dass er jetzt Feedback von der Replikationspipeline empfängt. Wenn Nachrichten im Transportdumpster an alle Postfachdatenbankkopien repliziert wurden, dann werden sie aus dem Transportdumpster entfernt. Dadurch wird sichergestellt, dass nur nicht replizierte Daten im Transportdumpster verbleiben.

Zusätzlich zum Transportdumpster 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 bei einem der nächsten Hops ein Fehler auftritt, bevor die erfolgreiche Zustellung gemeldet wurde, wird die Nachricht erneut an diesen nächsten Hop zugestellt. 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, dann hat sich das Cmdlet sowohl bei die Quelldatenbank als auch bei der Zieldatenbank angemeldet und die Inhalte von einem Postfach in ein anderes verschoben. Das Verschieben von Postfächern mithilfe von Cmdlets hatte verschiedene Nachteile:

• Postfachverschiebungen haben normalerweise Stunden gedauert, 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, erfolgte der Abbruch des Verschiebungsvorgangs, der dann wieder komplett neu gestartet werden musste.

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

Die neuen Cmdlets für Verschiebungsanforderungen in Exchange 2010 können zum Ausführen asynchroner Verschiebungsvorgänge verwendet werden. Anders als bei 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 Postfachreplikationsdienst. Weitere Informationen zur Onlineverschiebung von Postfächern finden Sie unter Grundlegendes zu Verschiebungsanforderungen.

Systemeigener Exchange-Datenschutz

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 jüngst generierte Protokolldateien nicht verfügbar sind. Bei LLR werden Schreibvorgänge in die Datenbank verzögert, bis die angegebene Anzahl an 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.

Mithilfe des erneuten inkrementellen Seedings konnten Abweichungen im Transaktionsprotokollstrom zwischen einer Quell- und einer Zielspeichergruppe korrigiert werden, indem auf die verzögerten Wiedergabefunktionen von LLR vertraut wurde. 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 automatisch unter den folgenden Bedingungen 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.

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.

Replikations-API von Drittanbietern

Exchange 2010 enthält auch eine neue Replikations-API von Drittanbietern, mit der Unternehmen Lösungen zur synchronen Replikation von Drittanbietern anstatt der integrierten Funktion für fortlaufende Replikation verwenden können. Weitere Informationen zu Partnerprodukten für Exchange 2010 finden Sie auf der Website Exchange 2010-Partner (möglicherweise in englischer Sprache). Wenn Sie ein Partner sind, der nach Informationen zur Replikations-API von Drittanbietern sucht, dann wenden Sie sich an einen Microsoft-Mitarbeiter.

In Exchange 2010 nicht länger vorhandene Funktionen

Die folgenden Funktionen aus Exchange 2007 und Exchange 2007 SP1 sind in Exchange 2010 nicht länger vorhanden. Die sie ersetzenden Funktionen sind in der Tabelle aufgeführt.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.