Fortlaufende Clusterreplikation

  • Artikel

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2008-03-21

Fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR) ist ein Hochverfügbarkeitsfeature von Microsoft Exchange Server 2007, das die in Exchange 2007 integrierte asynchrone Protokollversand und -wiederherstellungstechnologie mit den Failover- und Verwaltungsfeatures kombiniert, die vom Clusterdienst bereitgestellt werden.

CCR ist auf die Bereitstellung hoher Verfügbarkeit für Exchange 2007-Postfachserver ausgelegt, indem eine Lösung zur Verfügung gestellt wird, die folgende Anforderungen erfüllt:

  • Keine einzelne Fehlerquelle

  • Keine besonderen Hardwareanforderungen

  • Keine Anforderungen an eine gemeinsame Speichernutzung

  • Möglichkeit der Bereitstellung in ein oder zwei Datacenterkonfigurationen

  • Möglichkeit der Verringerung der Häufigkeit vollständiger Sicherungen sowie der Gesamtanzahl zu sichernden Datenvolumes sowie der Verkürzung der Wiederherstellungsdauer nach dem ersten Ausfall gemäß der Vereinbarung zum Servicelevel

Für die CCR wird die Wiederherstellungsfunktionalität in Exchange 2007 nach einem Datenbankausfall genutzt, um die fortlaufende und asynchrone Aktualisierung einer zweiten Kopie einer Datenbank mit den Änderungen zu ermöglichen, die an der aktiven Kopie der Datenbank erfolgt sind. Während der Installation des passiven Knotens in einer CCR-Umgebung werden alle Speichergruppen und ihre Datenbanken vom aktiven auf den passiven Knoten kopiert. Dieser Vorgang wird als Seeding bezeichnet und stellt die Basisdaten der zu replizierenden Datenbank zur Verfügung. Nach dem anfänglichen Seeding erfolgen das Kopieren und Wiedergeben bzw. Zurückspielen des Protokolls fortlaufend.

In einer CCR-Umgebung sind die Replikationsfunktionen mit dem Clusterdienst integriert, um eine Lösung mit hoher Verfügbarkeit bereitzustellen. Zusätzlich zur Sicherstellung der Daten- und Dienstverfügbarkeit ermöglicht CCR auch geplante Ausfallzeiten. Wenn Updates installiert werden müssen oder eine Wartung erfolgen muss, kann ein Administrator einen Postfachclusterserver (in früheren Versionen von Exchange Server als virtueller Exchange-Server bezeichnet) manuell auf einen passiven Knoten verschieben. Nach dem Verschieben kann der Administrator die gewünschte Wartung durchführen.

Der Verschiebevorgang wird über die Exchange-Verwaltungsshell mit dem Cmdlet Move-ClusteredMailboxServer ausgeführt. Microsoft Exchange Server 2007 Service Pack 1 (SP1) umfasst auch einen neuen Assistenten zum Verwalten von Postfachclusterservern in der Exchange-Verwaltungskonsole, mit dem Sie Postfachclusterserver verschieben können. Die von diesen Aufgaben verwendete Logik sorgt dafür, dass während des Verschiebens keine Postfachdaten verloren gehen. Die Aufgaben führen vor dem Verschieben auch Überprüfungen durch, um sicherzustellen, dass die Replikation auf dem passiven Knoten schnell aktiviert werden kann.

Im Folgenden werden die wichtigsten Fakten zu CCR vorgestellt:

  • Die fortlaufende Replikation erfolgt asynchron   Protokolle werden erst kopiert, nachdem sie geschlossen wurden und nicht mehr vom Postfachserver verwendet werden. Dies bedeutet, dass der passive Knoten in der Regel nicht über eine Kopie aller Protokolldateien verfügt, die auf dem aktiven Knoten vorhanden sind. Die einzige Ausnahme liegt vor, wenn der Administrator einen geplanten Ausfall des aktiven Knotens durchgeführt hat, um ein Update aufzuspielen oder andere Wartungsaufgaben durchzuführen.

  • Während des normalen Betriebs sorgt die fortlaufende Replikation für keinerlei CPU- und E/A-Last (Eingabe/Ausgabe) auf dem aktiven Knoten   Die CCR nutzt den passiven Knoten zum Kopieren und Wiedergeben der Protokolle. Der passive Knoten greift über eine abgesicherte Dateifreigabe auf den passiven Knoten zu.

  • Die Änderung eines aktiven Knotens in einen passiven Knoten und umgekehrt im Verlauf der Lebensdauer des Clusters erfolgt automatisch   Bei einem Ausfall ändert sich beispielsweise die Aktiv-/Passiv-Zuweisung. Dies bedeutet, dass sich die Richtung der Replikation umkehrt. Für die Umkehrung der Replikation ist kein Administratoreingriff erforderlich. Das System verwaltet die Umkehrung der Replikation automatisch.

  • Failovervorgänge und geplante Ausfälle sind hinsichtlich Funktionalität und Leistung symmetrisch   Ein Failover von Knoten 1 auf Knoten 2 dauert z. B. genauso lange wie ein Failover von Knoten 2 auf Knoten 1. In der Regel dauert dies nicht länger als zwei Minuten. Auf großen Servern erfolgen geplante Ausfälle meist in weniger als vier Minuten. Der Zeitunterschied zwischen einem Failover und einem geplanten Ausfall ist verknüpft mit der Zeit, die benötigt wird, um ein kontrolliertes Herunterfahren des aktiven Knotens für einen geplanten Ausfall durchzuführen. Dieser Leistungsunterschied wird ggf. durch ein künftiges Service Pack verringert.

  • VSS-Sicherungen (Volume Shadow Copy Service, Volumeschattenkopie-Dienst) auf dem passiven Knoten werden unterstützt   Dies ermöglicht Administratoren das Verlagern von Sicherungen weg vom aktiven Knoten und das Vergrößern des Zeitfensters für Sicherungen. Darüber hinaus müssen größere Konfigurationen aufgrund von Leistungsanforderungen für die Verwendung von VSS-Sicherungen keine hardwarebasierte VSS-Unterstützung bieten. Die Verarbeitungslast auf dem passiven Knoten umfasst hauptsächlich das Kopieren und Wiedergeben von Protokollen. Diese Vorgänge unterliegen keinen Echtzeitanforderungen wie der Postfachclusterserver auf dem aktiven Knoten. Der aktive Knoten muss beispielsweise auf Clientanfragen zeitgerecht reagieren. Ein größeres Zeitfenster für die Sicherung kann verwendet werden, da der passive Knoten nicht in Echtzeit reagieren muss, wodurch größere Datenbanken und Postfächer zulässig werden.

  • Die Gesamtdatenmenge auf Sicherungsmedien wird verringert    Die passive CCR-Kopie stellt die erste Schutzmaßnahme gegen Datenbeschädigungen und -verluste dar. Deshalb muss ein nochmaliger Ausfall erfolgen, bevor Sicherungen benötigt werden. Für die Wiederherstellungsdauer nach dem ersten Ausfall gemäß der Servicevereinbarung kann ein kurzer Zeitraum gewählt werden, da kein Rückspeichern erforderlich ist. Für die Wiederherstellung nach dem zweiten Ausfall kann eine wesentlich längere Dauer gewählt werden. Sicherungen können demnach im Rahmen eines vollständigen Wochenzyklus mit täglichen inkrementellen Sicherungen erfolgen. Dadurch verringert sich die Gesamtdatenmenge, die auf den Sicherungsmedien abgelegt werden muss.

  • CCR kann mit SCR (Standby Continuous Replication, fortlaufende Standbyreplikation) kombiniert werden   CCR kann mit SCR kombiniert werden, um Speichergruppen lokal in einem primären Datencenter (mithilfe von CCR für Hochverfügbarkeit) und remote in einem sekundären oder Sicherungsdatencenter (mithilfe von SCR für Standortflexibilität) zu replizieren. Dieses sekundäre Datencenter kann einen passiven Knoten in einem Failovercluster enthalten, der die SCR-Ziele hostet. Diese Art von Cluster wird als Standbycluster bezeichnet, da sie keine Postfachclusterserver enthält, aber schnell durch einen Ersatz-Postfachclusterserver in einem Wiederherstellungsszenario bereitgestellt werden kann. Wenn das Hauptdatencenter ausfällt oder die Verbindung auf andere Weise unterbrochen wird, können die in diesen SCR-Zielen gehosteten Standbycluster schnell auf dem Standbycluster aktiviert werden.

Grundlegende Architektur von CCR

CCR kombiniert die folgenden Elemente:

  • Die von Microsoft-Failoverclustern bereitgestellten Failover- und Virtualisierungsfeatures.

  • Ein auf einem Hauptknotensatz basierendes Failoverclusterquorum-Modell, das eine Dateifreigabe als Zeugen für die Clusteraktivität verwendet.

  • Die Exchange 2007-Features für Replikation und Wiedergabe von Transaktionsprotokollen.

  • Ein Nachrichtenwarteschlangen-Feature des Hub-Transport-Servers, der so genannte Transportpapierkorb.

Windows-Failovercluster

Wie in der folgenden Abbildung gezeigt, verwendet CCR in Exchange 2007 SP1 zwei Computer (die als Knoten bezeichnet werden), die zu einem Failovercluster mit Windows Server 2003 Service Pack 2 oder Windows Server 2008 zusammengeführt werden. Die Knoten im Failovercluster hosten einen einzelnen Postfachclusterserver. Ein Knoten, der aktuell einen Postfachclusterserver ausführt, wird als aktiver Knoten bezeichnet, und ein Knoten, der keinen Postfachclusterserver ausführt, jedoch Teil des Clusters und Ziel der fortlaufenden Replikation ist, wird als passiver Knoten bezeichnet. Als Ergebnis geplanter gewarteter und ungeplanter Ausfälle ändert sich die Reservierung eines Knotens als aktiv oder passiv während der Lebensdauer des Failoverclusters mehrmals.

Grundlegende Bereitstellung von CCR

Architektur für fortlaufende Clusterreplikation

Der Failovercluster wird mithilfe vom Clusterdienst und einer neuen bestimmten Art von Clusterquorummodell erstellt:

Dateifreigabezeuge

Beide oben beschriebenen Quorummodelle verwenden eine Dateifreigabe auf einem dritten Computer als Zeuge. In diesen Quorummodellen wird eine Dateifreigabe auf einem dritten Computer verwendet, um das Auftreten einer Netzwerkpartition im Cluster zu verhindern, die auch als Split Brain-Syndrom bezeichnet wird. Das Split Brain-Syndrom tritt auf, wenn alle Netzwerke ausfallen, die für interne Clusterkommunikation reserviert sind, und die Knoten keine Taktsignale voneinander empfangen können. Das Split Brain-Syndrom wird verhindert, indem immer verlangt wird, dass unter den zwei Knoten und der Dateifreigabe eine Mehrheit verfügbar ist und kommuniziert, damit der Postfachclusterserver betriebsfähig ist. Wenn die Mehrheit der Computer kommuniziert, besitzt der Cluster ein Quorum. Die Dateifreigabe für den Dateifreigabezeugen kann sich auf einem beliebigen Computer befinden, auf dem Windows Server ausgeführt wird. Es ist nicht erforderlich, dass die Version des Betriebssystems Windows Server, mit der die Dateifreigabe ausgeführt wird, dem Betriebssystem der CCR-Umgebung entspricht. Es wird jedoch empfohlen, einen Hub-Transport-Server am Standort des Active Directory-Verzeichnisdiensts mit dem Postfachclusterserver zum Hosten der Dateifreigabe zu verwenden, weil ein Messagingadministrator auf diese Weise die Kontrolle über die Dateifreigabe besitzt.

Hinweis

Die vom Dateifreigabezeugen verwendete Dateifreigabe kann nicht in einer DFS-Umgebung (Distributed File System) gehostet werden.

Der Dateifreigabezeuge verwendet eine Dateifreigabe auf einem Computer außerhalb des Clusters als Zeuge für die Aktivitäten der beiden Knoten im Cluster. Der Zeuge wird von den beiden Knoten verwendet, um zu verfolgen, welcher Knoten die Kontrolle über den Cluster hat. Das Notizbrett wird nur benötigt, wenn die beiden Knoten nicht miteinander kommunizieren können. Stellen Sie sich einen Postfachclusterserver mit zwei Knoten, Knoten1 und Knoten2, vor. In diesem Fall ist Knoten1 der Knoten, der die Kontrolle über das Notizbrett und damit über den Cluster hat und den Postfachclusterserver hochfahren kann. Ist Knoten2 in Betrieb, kann aber nicht mit Knoten1 kommunizieren, versucht Knoten2, die Kontrolle über das Notizbrett zu übernehmen und verursacht einen Fehler. Die Tatsache, dass Knoten2 die Kontrolle über das Notizbrett nicht übernehmen kann, bedeutet, dass er den Postfachclusterserver nicht hochfahren soll.

Wenn die beiden Knoten miteinander kommunizieren können, wird das Notizbrett nicht benötigt und könnte offline sein. Wenn der Dateifreigabezeuge jedoch nicht verfügbar ist, würde ein Ausfall eines der beiden Knoten dazu führen, dass der Postfachclusterserver nicht online ist.

Die Dateifreigabe dient nur der beschriebenen Verwaltung des Zustands. Daher werden sämtliche Clusterkonfigurationsinformationen zwischen den beiden Knoten ausgetauscht. Das ist wichtig, denn es bedeutet Folgendes: Wenn Knoten1 verfügbar und Knoten2 nicht verfügbar ist, kann Knoten2 erst dann wieder verfügbar werden, wenn die Kommunikation mit Knoten1 wieder funktioniert, selbst wenn Knoten2 mit dem Dateifreigabezeugen kommunizieren kann.

Die Unterstützung des Dateifreigabezeugen führt eine periodische Zugriffsüberprüfung des Dateifreigabezeugen durch. Schlägt die Zugriffsüberprüfung fehl, wird ein Ereignis generiert. Das Ereignis kann vom Überwachungssystem erkannt, erfasst und gemeldet werden. Auf diese Weise ist das Betriebspersonal in der Lage, Fehler zu korrigieren, bevor diese aufgrund eines zweiten gleichzeitig auftretenden Fehlers zu einem Ausfall führen.

Unter folgenden Bedingungen wird auf die Dateifreigabe zugegriffen:

  • Wenn ein Clusterknoten hochfährt und nur ein Clusterknoten verfügbar ist.

  • Wenn ein Netzwerkverbindungsproblem einen zuvor erreichbaren Knoten an der Kommunikation mit dem Cluster hindert.

  • Wenn ein Clusterknoten den Cluster verlässt.

  • Regelmäßig zu Überprüfungszwecken. Die Häufigkeit ist konfigurierbar.

Aus diesen Gründen ist die Arbeitsbelastung der Dateifreigabe sehr niedrig. Aus diese Grund kann ein einzelner Server Dateifreigaben für mehrere CCR-Umgebungen bereitstellen. Jede CCR-Umgebung sollte jedoch ihren eigenen reservierten Ordner und ihre eigene Freigabe auf diesem Server besitzen.

Überlegungen zum Dateifreigabezeugen

CCR ist eine Umgebung mit zwei Knoten, die entweder ein MNS-Quorum mit Dateifreigabezeugen oder ein Knoten- und Dateifreigabe-Mehrheitsquorum anstelle eines dritten Knotens (oder weiterer Knoten) im Cluster verwendet, der in traditionellen MNS-Clustern erforderlich war. Eine geografisch verteilte CCR-Umgebung ist eine aus zwei Datacentern bestehende Bereitstellung, in der der aktive Knoten im primären Datacenter und der passive Knoten im sekundären Datacenter bereitgestellt wird. Daher gibt es in einer geografisch verteilten CCR-Umgebung zwei Optionen zur Positionierung der Dateifreigabe: Die Positionierung im primären Datacenter oder in einem dritten Datacenter.

Bei der ersten Option wird die Dateifreigabe auf einem Hub-Transport-Server im primären Datacenter konfiguriert. Es wird ein Hub-Transport-Server empfohlen, da er es einem Messagingadministratoren ermöglicht, Ausfälle der Dateifreigabe zu verwalten und zu überwachen. Die Erfahrung und das Feedback von Kunden zeigt, dass die häufigsten Arten von Netzwerkdienstunterbrechungen in WAN-Topologien (Wide Area Network) auftreten. Die Positionierung der Dateifreigabe im primären Datacenter ist hilfreich, da Dienstunterbrechungen aufgrund von Netzwerkausfällen zwischen den beiden Datacentern verhindert werden. Die Verwendung dieser Konfiguration bedeutet, dass bei einem Ausfall des primären Datacenters kein automatischer Failover erfolgt. Es wird jedoch sichergestellt, dass die Mehrheit im Failovercluster von einem Netzwerkausfall zwischen dem primären und sekundären Datacenster nicht betroffen ist.

Die zweite Möglichkeit ist es, die Dateifreigabe auf einer verwalteten Serverfunktion innerhalb eines dritten physischen Standorts zu konfigurieren. Eine verwaltete Serverfunktion ist ein Server, der bis zu einem ähnlichen Grad wie andere Server unterstützt und verwaltet wird, die für die Bereitstellung des Messagingdiensts von Bedeutung sind. Ein Beispiel für eine verwaltete Serverfunktion ist ein Hub-Transport-Server im primären Datacenster. Bei diesem dritten physischen Standort kann es sich um eine Zweigstelle oder ein drittes Datacenter handeln. Eine Anforderung dieser Konfiguration ist es, dass der dritte Standort über eine Netzwerkinfrastruktur zum primären und sekundären Datacenter verfügt, die eine geringe Latenz und eine hohe Zuverlässigkeit aufweist.

Replikation und Wiedergabe von Transaktionsprotokollen

Die Replikation und Wiedergabe von Transaktionsprotokollen wird verwendet, um geänderte Daten zu kopieren und die Datenbank der passiven Kopie zu aktualisieren. Die Replikation nutzt den Änderungsverlauf, der von ESE (Extensible Storage Engine) generiert wird. Dieser Änderungsverlauf wird als Sequenz von Protokolldateien mit einer festen Größe von 1 MB dargestellt. Die Replikationsfunktion kopiert die Protokolldateien bei der Generierung der einzelnen Protokolldateien auf den passiven Knoten. Der Replikationsmechanismus ist für die Onlinedatenbank asynchron. Wenn die Protokolle auf dem passiven Knoten eintreffen, werden sie auf Beschädigungen überprüft und in die Kopie der Datenbank wiedergegeben, die auf dem passiven Knoten gespeichert ist. Der Wiedergabevorgang nimmt die im Änderungsprotokoll beschriebenen Änderungen an der Datenbank des passiven Knotens vor. Hierdurch entspricht die Datenbank des passiven Knotens mit einer geringfügigen Zeitverzögerung der Produktionsdatenbank.

Da die Daten zwischen den Knoten repliziert werden, kann der Postfachclusterserver auf jedem der beiden Knoten im Cluster betrieben werden. Diese Funktion stellt erhöhte Verfügbarkeit bereit, da geplante Ausfälle und Fehler eines Knotens keinen erweiterten Ausfall des Postfachclusterservers bewirken. Außerdem haben Dienstausfälle des Speichers auf einem Knoten keinen Einfluss auf die Verfügbarkeit des anderen Knotens und des Postfachclusterservers. Vorausgesetzt, dass die Dateifreigabe noch verfügbar ist und mit dem passiven Knoten kommunizieren kann, wechselt der Postfachclusterserver bei einem Ausfall des aktiven Knotens auf einen verbleibenden Knoten und setzt seinen Betrieb fort.

In einer CCR-Umgebung wird der Ordner mit den Transaktionsprotokolldateien auf dem aktiven Knoten mithilfe einer Windows-Standarddateifreigabe freigegeben. Die Objekt-GUID (Globally Unique Identifier) für die Speichergruppe wird als Freigabename verwendet, und ein Dollarzeichen ($) wird an das Ende der Freigabe angefügt. Der Microsoft Exchange-Replikationsdienst auf dem passiven Knoten stellt die Verbindung mit der Freigabe auf dem aktiven Knoten her um die Protokolldateien unter Verwendung des SMB-Protokolls (Server Message Block) zu kopieren oder anzufordern. Der passive Knoten überprüft dann die Protokolldatei und gibt sie in die Kopie der Datenbank auf dem passiven Knoten wieder.

Hinweis

Der SMB-Datenverkehr für die Replikation der Transaktionsprotokolldatei erfolgt unverschlüsselt. Bei Bedarf können Sie diesen Datenverkehr mit IPsec (Internet Protocol Security) verschlüsseln. Nur die Replikation der Transaktionsprotokolldatei erfolgt mithilfe des SMB-Protokolls. Das erneute Seeding einer passiven Kopie erfolgt mithilfe der ESE-Sicherungs-API (Application Programming Interface). Hierbei handelt es sich um eine nicht verschlüsselte Kommunikation. Falls erforderlich, kann IPSec (IP Security) zum Verschlüsseln dieser Daten verwendet werden.

Fortlaufende Replikation über redundante Clusternetzwerke

In der RTM-Version von Microsoft Exchange Server 2007 erfolgen sämtliche Kopier- und Seedingvorgänge für Transaktionsprotokolldateien in einer CCR-Umgebung über das öffentliche Netzwerk. Für diese Konfiguration gelten folgende Einschränkungen:

  • Wenn der passive Knoten mehrere Stunden nicht verfügbar ist, kann sich eine erhebliche Anzahl von Protokollen ansammeln, die übertragen werden muss. Die Verschiebung dieser Protokolle muss so schnell wie möglich erfolgen, sobald der passive Knoten verfügbar ist. Beim Kopieren der Protokolle über das öffentliche Netzwerk konkurriert die Verschiebung der Protokolle mit dem Clientdatenverkehr. Dies wirkt sich auf den Clientdatenverkehr aus und verlangsamt die erneute Synchronisation.

  • Wenn das öffentliche Netzwerk ausfällt, ergibt sich ein verlustreicher Failover, auch wenn die Protokolldaten verfügbar sind.

  • Durch die Verwendung eines isolierten Netzwerks für die Protokollkommunikation haben Sie die Möglichkeit, die Sicherheit für Nachrichtendaten ohne Verschlüsselung bereitzustellen, wodurch auch die zugehörigen Leistungseinbußen ausbleiben.

  • Unter gewissen Umständen kann es zu einem Ansturm von Protokollen kommen. Wenn dieser auftritt, erfährt das System eine ungewöhnlich hohe Replikationsbelastung. Diese Situation kann zu einer Unterversorgung von Clients führen, wenn die Protokolldaten über dasselbe Netzwerk übertragen werden müssen, das für die Kommunikation mit den Clients verwendet wird.

Nicht alle genannten Probleme treten mit der gleichen Häufigkeit auf. Das erste Problem kann jedoch sicherlich alle paar Monate auftreten, da die passiven Knoten für regelmäßige Wartungsmaßnahmen offline gestellt werden.

Exchange 2007 SP1 minimiert die Auswirkungen der vorhergehenden Probleme, indem es dem Administrator ermöglicht, ein oder mehrere gemischte Netzwerke im Cluster für die Protokollübermittlung zu erstellen (ein gemischtes Netzwerk ist ein Clusternetzwerk, das sowohl den internen Taktdatenverkehr des Clusters als auch den Clientdatenverkehr unterstützt). Exchange 2007 SP1 bietet einem Administrator außerdem die Möglichkeit, ein bestimmtes gemischtes Netzwerk für das Seeding anzugeben.

Hinweis

Für den Protokollversand und das Seeding verwendete Clusternetzwerke müssen als gemischte Netzwerke konfiguriert werden. Ein gemischtes Netzwerk ist ein beliebiges Clusternetzwerk, das sowohl für den Clusterverkehr (Taktdaten) als auch für den Clientzugriffsverkehr konfiguriert ist. Außerdem muss der Administrator auf dem Netzwerkadapter, der mit dem Namen eines Hosts für die fortlaufende Replikation konfiguriert wird, das Kontrollkästchen Adressen dieser Verbindung in DNS registrieren im Dialogfeld Erweiterte TCP/IP-Eigenschaften deaktivieren und statische DNS-Einträge oder Einträge der Datei Hosts auf jedem Knoten verwenden, um die Namensauflösung für die neu erstellten Hostnamen durch jeden Knoten zu ermöglichen. Der vom Netzwerkadapter verwendete DNS-Server kann sich im öffentlichen oder privaten Netzwerk befinden. Unabhängig von seinem Standort müssen jedoch beide Knoten darauf zugreifen können, damit die Hostnamensauflösung auftreten kann. Unter Windows Server 2008 muss für die Netzwerkadapter, die für den Protokollversand oder das Seeding verwendet werden, außerdem NetBIOS aktiviert sein.

Die Unterstützung für das Kopieren von Protokolldateien über ein gemischtes Netzwerk wird mithilfe eines neuen Cmdlets namens Enable-ContinuousReplicationHostName konfiguriert. Ähnlich erzielen Sie die Deaktivierung dieses Features durch Verwendung des Cmdlets Disable-ContinuousReplicationHostName.

Nachdem ein Postfachclusterserver in einer CCR-Umgebung vorhanden ist, kann ein Administrator das Cmdlet Enable-ContinuousReplicationHostName auf beiden Knoten des Clusters ausführen und weitere IP-Adressen und Hostnamen angeben, die dann in dedizierten Clustergruppen erstellt werden, die den einzelnen Knoten zugeordnet sind. Nachdem diese Aufgabe durchgeführt wurde, beginnt der Microsoft Exchange-Replikationsdienst kurz nach der erfolgreichen Konfiguration und im Anschluss an die Bestätigung, dass das neue Netzwerk einsatzbereit ist, mit dem Kopieren von Protokollen über dieses neu erstellte Netzwerk. Wenn mehrere neue Netzwerke erstellt werden, wählt der Microsoft Exchange-Replikationsdienst wahllos ein Netzwerk aus. Wenn das angegebene Netzwerk nicht mehr verfügbar ist, beginnt der Microsoft Exchange-Replikationsdienst automatisch mit der Verwendung weiterer Replikationsnetzwerke. Wenn kein Replikationsnetzwerk verfügbar ist, beginnt er innerhalb von fünf Minuten damit, das öffentliche Netzwerk für den Protokollversand zu verwenden. (Die Netzwerkerkennung durch den Microsoft Exchange-Replikationsdienst erfolgt alle fünf Minuten.) Wenn das bevorzugte Replikationsnetzwerk erneut verfügbar ist, verwendet der Microsoft Exchange-Replikationsdienst dieses Netzwerk automatisch wieder für den Protokollversand.

Weitere Informationen über die Cmdlets finden Sie unter Enable-ContinuousReplicationHostName und Disable-ContinuousReplicationHostName.

Die Unterstützung für das Seeding über ein redundantes Clusternetzwerk wird mithilfe des Cmdlets Update-StorageGroupCopy konfiguriert, das in Exchange 2007 SP1 aktualisiert wurde, um einen neuen Parameter mit der Bezeichnung DataHostNames einzubeziehen. Dieser Parameter gibt an, welches Clusternetzwerk für das Seeding zu verwenden ist. Weitere Informationen zu den Änderungen am Cmdlet Update-StorageGroupCopy in Exchange 2007 SP1 finden Sie unter Update-StorageGroupCopy.

Nachdem ein Clusternetzwerk für die fortlaufende Replikation erstellt wurde, können Sie das Cmdlet Get-ClusteredMailboxServerStatus dazu verwenden, um aktualisierte Informationen über Clusternetzwerke anzuzeigen, die für die fortlaufende Replikationsaktivität aktiviert wurden. Die neuen Ausgabedetails umfassen:

  • OperationalReplicationHostNames:{Host1,Host2,Host3}

  • FailedReplicationHostNames:{Host4}

  • InUseReplicationHostNames:{Host1,Host2}

Weitere Informationen zu den Änderungen am Cmdlet Get-ClusteredMailboxServerStatus in Exchange 2007 SP1 finden Sie unter Get-ClusteredMailboxServerStatus.

Transportpapierkorb

Die Masse der verlorenen Daten, die während einer automatischen Wiederherstellung anfallen, werden nachfolgend automatisch von einem Feature des Hub-Transport-Servers, dem so genannten Transportpapierkorb, wiederhergestellt. Der Transportpapierkorb für eine bestimmte Datenbank befindet sich ggf. auf allen Hub-Transport-Servern an dem Active Directory-Standort, der den Postfachclusterserver enthält. Wenn eine Nachricht auf ihrem Weg zu einem Postfachclusterserver in einer CCR-Umgebung Hub-Transport-Server durchläuft, wird eine Kopie in der Transportwarteschlange (mail.que) zurückbehalten, bis das Replikationsfenster vorbei ist. Der Transportpapierkorb ist eine erforderliche Komponente für CCR-Bereitstellungen. Der Transportpapierkorb nutzt die Redundanz in der Umgebung, um einen Teil der vom Failover betroffenen Daten verfügbar zu machen. Insbesondere verwalten Hub-Transport-Server eine Warteschlange mit den zuletzt zugestellten E-Mails. Diese Warteschlange ist abhängig von der Aufbewahrungsdauer von E-Mails und dem gesamten verwendeten Speicherplatz. Bei einem nicht verlustfreien Failover fordert CCR auf dem Postfachclusterserver automatisch jeden Hub-Transport-Server auf dem Active Directory-Standort auf, alle Nachrichten aus der Transportpapierkorb-Warteschlange erneut zu senden. Der Informationsspeicher löscht automatisch die Duplikate und stellt verlorene E-Mails erneut zu.

Der Transportpapierkorb ist für CCR und in Exchange 2007 SP1 auch für die fortlaufende lokale Replikation (Local Continuous Replication, LCR) aktiviert. Der Transportpapierkorb ist nicht für SCR oder Einzelkopiecluster (Single Copy Clusters, SCCs) aktiviert. Für CCR ist die Voraussetzung dafür, dass eine E-Mail-Nachricht im Transportpapierkorb aufbewahrt wird, dass wenigstens ein Empfänger über ein Postfach auf einem Postfachclusterserver in einer CCR-Umgebung oder in SP1 in einer für LCR aktivierten Datenbank verfügt.

Der Transportpapierkorb wurde entwickelt, um dem Administrator zum Schutz vor Datenverlusten die Möglichkeit zu geben, CCR so zu konfigurieren, dass der Postfachclusterserver automatisch bei minimalen Datenverlusten auf einem anderen Knoten online verfügbar wird. Wenn dies geschieht, stellt das System automatisch alle zuletzt gesendeten E-Mail-Nachrichten an die Benutzer auf diesem Server zu, und nutzt dabei den Transportpapierkorb, in dem diese E-Mail-Nachrichten noch vorhanden sind. So kann in den meisten Fällen ein Datenverlust verhindert werden. In einer CCR-Umgebung werden Anforderungen für eine erneute Zustellung aus dem Transportpapierkorb auf allen Hub-Transport-Servern am Standort automatisch durchgeführt. In Exchange 2007 RTM ist das Wiederholungsintervall fest codiert und beträgt sieben Tage. In Exchange 2007 SP1 entspricht das Wiederholungsintervall dem für MaxDumpsterTime festgelegten Wert. In einer LCR-Umgebung wird die Anforderung für eine erneute Zustellung aus allen Hub-Transport-Servern am Standort als Teil des TasksRestore-StorageGroupCopy durchgeführt.

Für folgende Elemente kann der Transportpapierkorb einen Datenverlust nicht verhindern:

  • Ordner Entwürfe für alle Microsoft Outlook-Clients im Onlinemodus.

  • Termine, Aktualisierungen von Kontakten, Aktualisierungen von Eigenschaften, Tasks und Aktualisierungen von Tasks.

  • Ausgehende E-Mail-Nachrichten, die vom Client an den Hub-Transport-Server unterwegs sind. Es gibt eine Zeitspanne, in der E-Mail-Nachrichten nur auf dem Postfachserver des Absenders existieren.

Bereitstellung der fortlaufenden Clusterreplikation

Die Bereitstellung der fortlaufenden Clusterreplikation (Cluster Continuous Replication, CCR) gleicht der Bereitstellung eines eigenständigen Servers mit Exchange und der Bereitstellung eines Einzelkopieclusters (Single Copy Cluster, SCC). Weitere Informationen zu Einzelkopieclustern finden Sie unter Einzelkopiecluster. Es gibt jedoch einige entscheidende Unterschiede, die bei der Bereitstellung der fortlaufenden Clusterreplikation zu berücksichtigen sind. Es empfiehlt sich, die folgenden Themen durchzulesen, bevor Sie CCR in Ihrer Umgebung planen und bereitstellen:

Wenn Sie bereit sind, die fortlaufende Clusterreplikation bereitzustellen, können Sie den Prozess beginnen, indem Sie die in einem der folgenden Themen beschriebenen Schritte für die einzelnen Phasen der Installation durchführen.

Verbesserungen von CCR in Exchange 2007 SP1

Exchange 2007 SP1 enthält verschiedene Verbesserungen von CCR, einschließlich zusätzlicher Benutzeroberflächenelemente für die Exchange-Verwaltungskonsole, verbesserte Status- und Überwachungsfunktionen und eine verbesserte Leistung.

Verbesserungen der Exchange-Verwaltungskonsole

In Exchange 2007 SP1 wurden verschiedene neue Elemente der Benutzeroberfläche hinzugefügt, mit denen die Verwaltungserfahrung für Hochverfügbarkeitsfeatures wie CCR verbessert wird. Diese Verbesserungen umfassen unter anderem:

  • Benutzeroberfläche des Transportpapierkorbs   Dem Knoten Hub-Transport im Arbeitsbereich Organisationskonfiguration wurde die neue Registerkarte Globale Einstellungen hinzugefügt. Diese Registerkarte umfasst die Seite Transporteinstellungen - Eigenschaften, auf der Sie die Einstellungen für den Transportpapierkorb für die Organisation konfigurieren können:

    • Maximale Größe pro Speichergruppe (MB)   Gibt die maximale Größe der Transportpapierkorb-Warteschlange für jede Speichergruppe an.

    • Maximale Aufbewahrungsdauer (Tage)   Gibt an, wie lange eine E-Mail-Nachricht in der Transportpapierkorb-Warteschlange aufbewahrt werden soll.

  • Fortlaufende Replikation   Der Benutzeroberfläche der Exchange-Verwaltungskonsole wurden zusätzliche Steuerelemente hinzugefügt, die es dem Administrator ermöglichen, die fortlaufende Replikation anzuhalten, fortzusetzen, zu aktualisieren und wiederherzustellen. Diese Steuerelemente entsprechen der Verwendung der folgenden Cmdlets der Exchange-Verwaltungsshell:

    • Suspend-StorageGroupCopy

    • Resume-StorageGroupCopy

    • Update-StorageGroupCopy

    • Restore-StoreGroupCopy

    Mithilfe dieser Cmdlets und der entsprechenden Exchange-Verwaltungskonsolenaufgaben können Sie die fortlaufende Replikation sowohl in LCR- als auch in CCR-Umgebungen verwalten.

Verbesserungen von Status und Überwachung

In Exchange 2007 SP1 sind auch verschiedene Änderungen enthalten, die auf eine höhere Verwaltungsfreundlichkeit von Exchange 2007 abzielen. Dazu zählen Verbesserungen der Berichtsfeatures für Cluster in Exchange 2007 RTM sowie zusätzliche Funktionalität für die proaktive Überwachung von Umgebungen mit fortlaufender Replikation. Insbesondere werden durch die Änderungen und Verbesserungen bekannte Mängel des Cmdlets Get-StorageGroupCopyStatus korrigiert, ein neues Cmdlet namens Test-ReplicationHealth eingeführt und eine verbesserte Einsichtnahme in das vom Transportpapierkorb abgedeckte Verlustfenster bereitgestellt.

Verbesserungen des Cmdlets "Get-StorageGroupCopyStatus"

In Exchange 2007 RTM gibt es mehrere Umstände, unter denen der von Get-StorageGroupCopyStatus gemeldete Status und die Leistungsindikatoren der fortlaufenden Replikation ungenau oder irreführend sind:

  • Eine Speichergruppe, die nicht aktiv ist (d. h. sich nicht ändert), kann als Fehlerfrei gemeldet werden, obwohl sie möglicherweise nicht fehlerfrei ist. Diese Situation tritt ein, weil der fehlerhafte Zustand erst erkannt wird, wenn ein Protokoll wiedergegeben wird.

  • Während der Initialisierung der Replikation wird der Replikationssatus erneut bewertet und ist möglicherweise nicht mehr genau. Nach Abschluss der Initialisierung wird der Status aktualisiert.

  • Der Wert des Felds LastLogGenerated kann falsch sein, wenn die Bereitstellung der Datenbank in der Speichergruppe aufgehoben wird.

  • Wenn in der Mitte eines Protokollstreams mindestens ein Protokoll fehlt, setzt die passive Kopie ihre Wiederherstellungsversuche fort, was dazu führt, dass der Replikationsstatus zwischen den Zuständen Fehler und Fehlerfrei wechselt. Wenn dies eintritt, wachsen die Wiedergabe- und Kopiewarteschlangen weiterhin an.

  • Unter seltenen Umständen kann ein Protokoll erfolgreich überprüft werden, aber dennoch nicht fehlerfrei wiedergegeben werden. In dieser Situation wechselt das System während der Wiederherstellungsversuche ständig zwischen den Zuständen Fehler und Fehlerfrei. Wenn dies eintritt, wachsen die Wiedergabe- und Kopiewarteschlangen weiterhin an.

Das Cmdlet Get-StorageGroupCopyStatus wurde auch durch Hinzufügen neuer Statusinformationen für CCR-Umgebungen verbessert:

  • Das Cmdlet Get-StorageGroupCopyStatus meldet einen SummaryCopyStatus von "ServiceDown", wenn nicht über das Netzwerk auf den Microsoft Exchange-Replikationsdienst auf dem Zielcomputer zugegriffen werden kann.

  • Das Cmdlet Get-StorageGroupCopyStatus meldet einen SummaryCopyStatus von "Initialisieren", wenn der Microsoft Exchange-Replikationsdienst auf dem Zielcomputer die Anfangstests beim Startvorgang noch nicht abgeschlossen hat. Es wurde außerdem eine neuer Leistungsindikator erstellt, um diesen Status als Booleschen Wert darstellen zu können.

  • Das Cmdlet Get-StorageGroupCopyStatus meldet einen SummaryCopyStatus von Wird synchronisiert, wenn ein inkrementelles erneutes Seeding nicht abgeschlossen wurde.

Die neuen Zustände für den Wert SummaryCopyStatus sind nur bei Verwendung der Exchange 2007 SP1-Version der Exchange-Verwaltungstools sichtbar. Bei Verwendung der Exchange 2007 RTM-Version der Exchange-Verwaltungstools wird der Status für jeden vorherigen Zustand als Fehler gemeldet.

Test-ReplicationHealth (Cmdlet)

Mit Exchange 2007 SP1 wird ein neues Cmdlet namens Test-ReplicationHealth eingeführt. Dieses Cmdlet ist auf die proaktive Überwachung der fortlaufenden Replikation sowie der fortlaufenden Replikationspipeline ausgelegt. Das Cmdlet Test-ReplicationHealth prüft alle Aspekte der Replikation, der Clusterdienste und der Speichergruppenreplikation sowie den Wiedergabestatus, um eine vollständige Übersicht über das Replikationssystem bereitzustellen. Insbesondere wenn das Cmdlet Test-ReplicationHealth auf einem Knoten im Cluster ausgeführt wird, führt es die in der folgenden Tabelle beschriebenen Tests aus.

Vom Test-ReplicationHealth-Cmdlet ausgeführte Tests

Test Beschreibung

Status des Clusternetzwerks

Überprüft, ob alle auf dem lokalen Knoten gefundenen clusterverwalteten Netzwerke ausgeführt werden. Dieser Test wird nur in CCR-Umgebungen ausgeführt.

Zustand der Quorumgruppe

Überprüft, ob die Clustergruppe, die die Quorumressource enthält, fehlerfrei ist. Dieser Test wird nur in CCR-Umgebungen ausgeführt.

Zustand des Dateifreigabequorums

Überprüft, ob der Wert von FileSharePath, der vom Hauptknotensatz-Quorum mit Dateifreigabenzeuge verwendet wird, erreichbar ist. Dieser Test wird nur in CCR-Umgebungen ausgeführt.

Zustand der Postfachclusterserver-Gruppe

Überprüft, ob der Postfachclusterserver fehlerfrei ist, indem sichergestellt wird, dass alle Ressourcen in der Gruppe online sind. Dieser Test wird nur in CCR-Umgebungen ausgeführt.

Knotenzustand

Überprüft, dass keiner der Knoten im Cluster sich im Zustand Angehalten befindet. Dieser Test wird nur in CCR-Umgebungen ausgeführt.

Status der DNS-Registrierung

Überprüft, ob alle clusterverwalteten Netzwerkschnittstellen, für die Erfolgreiche DNS-Registrierung vorschreiben festgelegt ist, die DNS-Registrierung erfolgreich abgeschlossen haben. Dieser Test wird nur in CCR-Umgebungen ausgeführt.

Status des Replikationsdiensts

Überprüft, ob der Microsoft Exchange-Replikationsdienst auf dem lokalen Computer fehlerfrei ist.

Speichergruppenkopie angehalten

Überprüft, ob die fortlaufende Replikation für Speichergruppen, die für die fortlaufende Replikation aktiviert sind, angehalten wurde.

Speichergruppenkopie mit Fehler

Überprüft, ob eine der Speichergruppenkopien den Status "Fehler" aufweist.

Länge der Speichergruppenreplikations-Warteschlange

Überprüft, ob eine der Speichergruppen eine Replikationskopiewarteschlange besitzt, die länger als die Schwellenwerte der bewährten Methoden ist. Zurzeit handelt es sich bei diesen Schwellenwerten um folgende:

  • Warnung   Warteschlangenlänge beträgt 3 bis 5 Protokolle.

  • Fehler   Warteschlangenlänge beträgt 6 oder mehr Protokolle.

Datenbanken mit nach Failover aufgehobener Bereitstellung

Überprüft, ob die Bereitstellung von Datenbanken nach einem Failover aufgehoben wurde oder sie den Status "Fehler" aufweist. Mit diesem Test wird nur das Vorhandensein von Datenbanken überprüft, die als Folge eines Failovers fehlerhaft sind.

Leistungsverbesserungen

In Exchange 2007 SP1 wurden Leistungsverbesserungen vorgenommen, die für Bereitstellungen mit hoher Verfügbarkeit von Vorteil sind. Diese Verbesserungen umfassen unter anderem:

  • E/A-Verringerungen für die Datenträger, auf denen sich passive Kopien von Speichergruppen in Umgebungen mit fortlaufender Clusterreplikation befinden   In Exchange 2007 SP1 wurde das Design der Architektur mit fortlaufender Replikation so geändert, dass der Datenbankcache nun zwischen den einzelnen Instanzen der Protokollwiedergabe auf dem passiven Knoten beibehalten wird. Durch die Beibehaltung des Datenbankcaches zwischen den einzelnen Instanzen der Protokollwiedergabe wird der Microsoft Exchange-Replikationsdienst in die Lage versetzt, die Datenbankcachefeatures der Extensible Storage Engine (ESE) zu nutzen, wodurch wiederum die Menge der Datenträger-E/A-Operationen für die logischen Gerätenummern (Logical Unit Number, LUN) der passiven Kopie verringert wird. In Exchange 2007 RTM hingegen wurde für jeden Batch von Protokollwiedergaben ein neuer Datenbankcache erstellt, was dazu führte, dass die Datenträger-E/A-Aktivität für den passiven Knoten bis zu zwei- bis dreimal so hoch war wie die Datenträger-E-/A-Aktivität für den aktiven Knoten.

  • Schnellere Verschiebung von Postfachclusterservern zwischen Knoten in einer CCR-Umgebung   Mithilfe dieser Verbesserungen können die Postfachclusterserver in maximal zwei Minuten zwischen Knoten verschoben werden. Dies bezieht Verschiebungen durch einen Administrator (mithilfe des Cmdlets Move-ClusteredMailboxServer) und Failovers mit ein, die vom Clusterdienst verwaltet werden. Die Datenbanken werden offline gestellt, ohne den Datenbankcache zu leeren, damit schnelle Verschiebungen in einer CCR-Umgebung erreicht werden. Dieses Verhalten verkürzt die Ausfallzeit, die beim Verschieben des Postfachclusterservers auf einen anderen Knoten auftritt.

Verwenden der fortlaufenden Standbyreplikation mit CCR

Die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) ist ein neues Feature in Exchange 2007 SP1. SCR erweitert die vorhandenen Features der fortlaufenden Replikation und aktiviert neue Datenverfügbarkeitsszenarien für Exchange 2007-Postfachserver. SCR verwendet dieselbe Protokollversand- und -wiedergabetechnologie, die auch von der LCR und CCR verwendet wird, um zusätzliche Bereitstellungsoptionen und -konfigurationen bereitzustellen.

Mithilfe von SCR können Sie die fortlaufende Replikation dazu verwenden, Postfachserverdaten eines eigenständigen Postfachservers (mit oder ohne LCR) oder eines Postfachclusterservers in einer SCC- oder CCR-Umgebung zu replizieren.

Die Aktivierung von Postfachserverdaten, die mit SCR erstellt und verwaltet werden, erfolgt manuell. Sie ist für Situationen konzipiert, in denen ein schwerwiegender Fehler auftritt (und nicht für einfache Serverausfälle, die durch einen Neustart oder anderweitig schnell zu beheben sind). Sie können ein SCR-Ziel mit der Datenbankportabilität, der Option für die Serverwiederherstellung (Setup /m:RecoverServer), oder, bei einem Postfachclusterserver, mit der Option für die Wiederherstellung von Postfachclusterservern (Setup /RecoverCMS) aktivieren. Die von Ihnen zu wählende Option hängt von Ihrer Konfiguration und dem Typ des aufgetretenen Fehlers ab.

Weitere Informationen zur SCR finden Sie unter Fortlaufende Standbyreplikation.

Weitere Informationen

In den folgenden Themenbereichen wird behandelt, wann und wie CCR als Teil eines Hochverfügbarkeits- und Standortflexibilitätsplans verwendet wird: