Hochverfügbarkeit

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

Letztes Änderungsdatum des Themas: 2009-04-01

Dieser Inhaltsbereich zum Thema "Hochverfügbarkeit" enthält Themen, die sich den Entwurf, die Erstellung und den Betrieb eines hochverfügbaren Messagingsystems basierend auf der RTM-Version (Release To Manufacturing) von Microsoft Exchange Server 2007 und Exchange 2007 Service Pack 1 (SP1) beziehen. Die Dokumentation in diesem Bereich umfasst Folgendes:

• Hochverfügbarkeitsstrategien

• Site Resilience Configurations

• Fortlaufende lokale Replikation

• Fortlaufende Clusterreplikation

• Fortlaufende Standbyreplikation

• Einzelkopiecluster

• Delegierte Installation eines Postfachclusterservers

• Aktualisieren von Postfachclusterservern auf Exchange 2007 SP1 oder SP2

• Anwenden von Exchange 2007-Updaterollups auf Postfachclusterserver

• Deinstallieren von Postfachclusterservern

• Überwachen der fortlaufenden Replikation

• Problembehandlung bei Bereitstellungen für hohe Verfügbarkeit

Es wird empfohlen, die entsprechende Dokumentation zu lesen, bevor Sie eine hochverfügbare Messaginglösung basierend auf Exchange 2007 SP1 entwerfen oder bereitstellen.

Die Dokumentation in diesem Bereich wurde aktualisiert und enthält nun die neuesten Empfehlungen und bewährten Methoden für die Bereitstellung von Exchange 2007 SP1 unter Windows Server 2008 und Windows Server 2003 Service Pack 2 (SP2).

Hochverfügbarkeit für Exchange Server 2007

Die Anforderungen an die Mindestbetriebszeit sind je nach Organisation unterschiedlich, jede Organisation möchte jedoch eine hohe Betriebszeit erreichen. Organisationen, für die Messaging unternehmenswichtig ist, entwerfen häufig ein hochverfügbares Messagingsystem, um diese Betriebszeit zu gewährleisten.

Exchange 2007 RTM und Exchange 2007 SP1 enthalten die folgenden integrierten Funktionen für schnelle Wiederherstellung, Hochverfügbarkeit und Standortflexibilität für Exchange 2007-Postfachserver:

• Fortlaufende lokale Replikation (Local Continuous Replication, LCR)   LCR ist eine Lösung mit einem Einzelserver, bei der mit integrierter asynchroner Protokollversandtechnologie eine Speichergruppenkopie auf einem zweiten Datenträgersatz erstellt und verwaltet wird, der mit demselben Server wie die Produktionsspeichergruppe verbunden ist. LCR bietet den Protokollversand, die Protokollwiedergabe und einen schnellen manuellen Wechsel zu einer sekundären Kopie der Daten.

• Fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR)   CCR ist eine Failoverclusterlösung ohne freigegebenen Speicher und stellt einen von zwei Typen von Postfachclusterserver-Bereitstellungen dar, die in Exchange 2007 verfügbar sind. CCR ist eine Clusterlösung (als CCR-Umgebung bezeichnet), die integrierte asynchrone Protokollversandtechnologie zum Erstellen und Verwalten einer Kopie jeder Speichergruppe auf einem zweiten Server in einem Failovercluster verwendet. CCR wurde als Lösung für ein oder zwei Datencenter konzipiert und stellt sowohl hohe Verfügbarkeit als auch Standortflexibilität bereit. CCR unterscheidet sich erheblich von Clusterlösungen in früheren Versionen von Exchange Server. Einzelheiten zu einigen dieser Unterschiede finden Sie unter Exchange-Clusterressourcen für Postfachclusterserver und Wiederherstellungsverhalten der fortlaufenden Clusterreplikation.

• Fortlaufende Standbyreplikation (SCR)   SCR ist ein neues Feature, das in Exchange 2007 SP1 eingeführt wird. Wie der Name schon nahelegt, ist die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) auf Fälle ausgelegt, in denen Standbywiederherstellungsserver verwendet werden bzw. deren Verwendung aktiviert wird. SCR erweitert die vorhandenen Features der fortlaufenden Replikation und aktiviert neue Datenverfügbarkeitsszenarien für Exchange 2007-Postfachserver. SCR verwendet die gleiche Protokollversand- und Wiedergabetechnologie wie LCR und CCR, um zusätzliche Bereitstellungsoptionen und -konfigurationen zur Verfügung zu stellen, indem der Administrator in die Lage versetzt wird, zusätzliche Speichergruppenkopien zu erstellen. SCR kann verwendet werden, um Daten von eigenständigen Postfachservern und Postfachclusterservern zu replizieren.

• Einzelkopiecluster (Single Copy Cluster, SCC)   SCC ist eine Failoverclusterlösung mit freigegebenem Speicher und stellt den anderen Typ von Postfachclusterserver-Bereitstellung dar, der in Exchange 2007 verfügbar ist. SCC ist eine Clusterlösung, die eine einzelne Kopie einer Speichergruppe auf einem Speichermedium verwendet, das von den Knoten im Cluster gemeinsam verwendet wird. SCC ähnelt den Clusterlösungen in früheren Versionen von Exchange Server in gewisser Hinsicht, weist jedoch neben zahlreichen Verbesserungen auch einige erhebliche Änderungen auf. Einzelheiten zu einigen dieser Änderungen finden Sie unter Einzelkopiecluster-Ressourcenmodell und Wiederherstellen eines Einzelkopieclusters.

Details zu anderen in SP1 eingeführten Hochverfügbarkeitsfeatures und -funktionen finden Sie unter Neue Hochverfügbarkeitsfeatures in Exchange 2007 SP1.

Hochverfügbarkeit für Postfachserver

Hochverfügbarkeit für Postfachserver bezieht sich auf zwei Aspekte: Dienstverfügbarkeit und Datenverfügbarkeit. Die Dienstverfügbarkeit wird durch die Verwendung eines Windows Server-Failoverclusters bereitgestellt. Die Datenverfügbarkeit wird durch ein integriertes Feature namens fortlaufende Replikation zur Verfügung gestellt.

Postfachclusterserver

Sowohl CCR als auch SCC sind Lösungen, die in einem Windows Server-Failovercluster bereitgestellt werden. In einem Failovercluster kann nur die Serverfunktion Mailbox installiert werden. Es können keine anderen Serverfunktionen in einem Failovercluster installiert werden. Ein Postfachserver, der in einem Failovercluster bereitgestellt wird, wird als Postfachclusterserver bezeichnet. Postfachclusterserver, die in einer CCR-Umgebung ausgeführt werden, unterscheiden sich erheblich von Postfachservern, die in einer SCC-Umgebung ausgeführt werden. Außerdem unterscheiden sich Postfachclusterserver in Exchange 2007 RTM und Exchange 2007 SP1 erheblich von Postfachclusterservern in früheren Versionen von Microsoft Exchange.

Mithilfe von Get-MailboxServer <CMSName> | fl Name, ClusteredStorageType können Sie in der Exchange-Verwaltungsshell bestimmen, ob ein Postfachclusterserver in einer CCR- oder in einer SCC-Umgebung gehostet wird. Ein Wert von NichtFreigegeben weist darauf hin, dass sich der Postfachclusterserver in einer CCR-Umgebung befindet, während ein Wert von Freigegeben anzeigt, dass der Postfachclusterserver sich in einer SCC-Umgebung befindet. Ein Wert von Deaktiviert zeigt an, dass der Postfachserver ein eigenständiger Server ist.

Um zu bestimmen, ob ein Postfachclusterserver in einer CCR- oder in einer SCC-Umgebung gehostet wird, können Sie auch den Wert des Attributs msExchClusterStorageType für das Postfachserverobjekt in Active Directory überprüfen. Ein Wert von "1" für das Attribut msExchClusterStorageType weist darauf hin, dass sich der Postfachclusterserver in einer CCR-Umgebung befindet, während ein Wert von "2" anzeigt, dass der Postfachclusterserver sich in einer SCC-Umgebung befindet. Ein Wert von <Nicht festgelegt> zeigt an, dass der Postfachserver ein eigenständiger Server ist.

CCR-Umgebungen

Exchange 2007 RTM und Exchange 2007 SP1 unterstützen in einer CCR-Umgebung maximal zwei Knoten, auf denen die Serverfunktion Mailbox installiert ist (einen aktiven und einen passiven Knoten). Ein Failovercluster mit drei Knoten, der einen Wählerknoten und ein traditionelles Hauptknotensatz-Quorum verwendet, wird ebenfalls unterstützt, stellt jedoch nicht das bevorzugte Clustermodell dar. Für die meisten Kunden wird jedoch die Bereitstellung von CCR-Umgebungen mit nur zwei Knoten und entweder einem Knoten- und Dateifreigabe-Mehrheitsquorum (Windows Server 2008) oder einem Hauptknotensatz-Quorum mit Dateifreigabezeuge (Windows Server 2003) empfohlen. Aus diesem Grund orientiert sich die Dokumentation zu CCR an Failoverclustern mit zwei Knoten, die eines dieser Quorummodelle verwenden.

Einzelkopiecluster

Exchange 2007 RTM und Exchange 2007 SP1 unterstützen maximal acht Knoten in einem Einzelkopiecluster. Gültige Kombinationen von Exchange 2007 SP1-SCCs auf Windows Server-Failoverclustern sind beispielsweise:

• 7 aktive / 1 passiver

• 6 aktive / 1 oder 2 passive

• 5 aktive / 1, 2 oder 3 passive

• 4 aktive / 1, 2, 3 oder 4 passive

• 3 aktive / 1, 2, 3, 4 oder 5 passive

• 2 aktive / 1, 2, 3, 4, 5 oder 6 passive

• 1 aktiver / 0, 1, 2, 3, 4, 5, 6 oder 7 passive

  Hinweis

  Die 64-Bit-Version von Windows Server 2008 unterstützt bis zu 16 Knoten in einem einzelnen Failovercluster. Exchange 2007 unterstützt jedoch maximal 8 Knoten im Cluster. Der Failovercluster kann zwar trotzdem 16 Knoten enthalten, Exchange 2007 sollte jedoch auf höchstens 8 Knoten im Failovercluster installiert sein.

Üblicherweise wird für jeden aktiven Knoten im Cluster nur ein passiver Knoten benötigt. Daher ist eine Konfiguration aus einem aktiven und einem passiven Knoten Konfigurationen mit einem aktiven und mehreren passiven Knoten vorzuziehen. Wenn Sie einen Einzelkopiecluster mit einem Knoten verwenden, können Sie entweder ein Quorum mit freigegebenem Speicher oder ein Hauptknotensatz-Quorum (traditionell, ohne Dateifreigabezeuge) verwenden. Zwar werden Einzelkopiecluster mit einem Knoten unterstützt, sie werden jedoch nicht als Hochverfügbarkeitslösung betrachtet, weil im Cluster keine Redundanz verfügbar ist.

Verteilter Cluster

Ein "verteilter Cluster", auch geografisch verteilter Cluster genannt, ist ein Failovercluster, der über mehrere Datencenter verteilt ist. Verteilte Cluster können als Teil eines Standortflexibilitätsdesigns für Ihre Exchange-Organisation verwendet werden. Da die CCR keinen freigegebenen Speicher verwendet, kann sie einfach in einem geographisch verteilten Failovercluster bereitgestellt werden, einschließlich eines verteilten Clusters mit mehreren Subnetzen unter Windows Server 2008. SCC wird in verteilten Clustern ebenfalls unterstützt. Verteilte SCC erfordert jedoch den Einsatz einer Drittanbietertechnologie für die synchrone Replikation. Weitere Informationen zu verteilten Clustern finden Sie unter Site Resilience Configurations.

Standbycluster

Ein weiterer Typ von Cluster, der durch Exchange 2007 und Exchange 2007 SP1 unterstützt wird, wird als Standbycluster bezeichnet. Ein Standbycluster ist ein Windows Server-Failovercluster, der keinen Postfachclusterserver enthält, jedoch schnell mit einem Ersatz-Postfachclusterserver ausgestattet werden kann, sollte ein Notfall, ein weiterer Fehler des Produktionsfailoverclusters oder ein anderes Wiederherstellungsszenario eintreten.

Fortlaufende Replikation

Die fortlaufende Replikation, die auch als Protokollversand bezeichnet wird, ist der Vorgang der Automatisierung der Replikation geschlossener Transaktionsprotokolldateien aus einer Produktionsspeichergruppe in eine Kopie dieser Speichergruppe, die sich auf einem zweiten Datenträgersatz auf dem lokalen Computer oder auf einem ganz anderen Server befindet. Die Protokolldateien werden, nachdem sie an den zweiten Speicherort kopiert wurden, in die Kopie der Datenbank wiedergegeben. Auf diese Weise bleiben die Speichergruppen mit einer leichten Zeitverzögerung synchronisiert.

Die fortlaufende Replikation ist in Exchange 2007 RTM in zwei Formen (LCR und CCR) und in Exchange 2007 SP1 in drei Formen (LCR, CCR und SCR) verfügbar.

Hochverfügbarkeit für andere Serverfunktionen

Hohe Verfügbarkeit wird bei den Serverfunktionen Hub-Transport, Edge-Transport, ClientAccess und UnifiedMessaging durch eine Kombination aus Serverredundanz, Netzwerklastenausgleich (Network Load Balancing, NLB), Hardwarelastenausgleich, DNS-Roundrobinverfahren (Domain Name System) und proaktiver Server-, Dienste- und Infrastrukturverwaltung erreicht. Im Allgemeinen können Sie Hochverfügbarkeit für die Serverfunktionen Client Access, Hub-Transport, Edge-Transport und UnifiedMessaging mithilfe der folgenden Strategien und Technologien 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. Sie können mithilfe des Netzwerklastenausgleichs auch Lastenausgleich und hohe Verfügbarkeit für Edge-Transport-Server bereitstellen.

• ClientAccess   Für die hohe Verfügbarkeit von Clientzugriffsservern können Netzwerklastenausgleich (NLB) oder ein hardwarebasiertes Drittherstellergerät für den Netzwerklastenausgleich verwendet werden. Weitere Informationen zum Netzwerklastenausgleich finden Sie im Windows Server TechCenter (englischsprachig).

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

  • Hub-Transport-Server zu Hub-Transport-Server (innerhalb der Organisation)   Die Kommunikation zwischen Hub-Transport-Servern innerhalb eine Organisation führt automatisch einen Lastenausgleich zwischen den verfügbaren Hub-Transport-Servern am Zielstandort des Active Directory-Verzeichnisdiensts aus.

  • Postfachserver zu Hub-Transport-Server (innerhalb eines Active Directory-Standorts)   Der Microsoft 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. In Exchange 2007 SP1 können Sie 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 Exchange 2007-Datenverkehr innerhalb der Organisation das Hardware-Lastenausgleichsmodul durchläuft, weil Datenverkehr innerhalb der Organisation integrierte Lastenausgleichsalgorithmen verwendet (wie weiter oben beschrieben wird). Weitere Informationen zum Lastenausgleich und zu Transportservern finden Sie unter Bereitstellungsoptionen für Hub-Transport-Server und Lastenausgleich und Fehlertoleranz für Transportserver.

• 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 Wählplan 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 Round-Robin-Verfahren geroutet werden. Darüber hinaus können diese Gateways die Liste der Server für einen Wählplan 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.

Erreichen hoher Verfügbarkeit mit Daten- und Dienstredundanz

Die Grundvoraussetzung der Exchange 2007-Hochverfügbarkeitsarchitektur ist das Einführen von Redundanz in die Bereitstellung. Ein Ausfall wird mithilfe der verbleibenden IT-Ressourcen zur Unterstützung der Exchange-Dienste aufgefangen. Sobald Ausfälle behoben sind, stehen die IT-Ressourcen Exchange und seinen Clients wieder zur Verfügung. In diesem Kontext können IT-Ressourcen Computer oder der Speicher für Postfach- oder andere Exchange-Daten sein.

Auch in einem einzelnen Rechenzentrum kann für Redundanz gesorgt werden. Dieser Ansatz wird meist zum Schutz gegen den Ausfall eines einzelnen Servers gewählt. Beispiel: Durch die Einführung eines zweiten Hub-Transport-Servers in das Hauptrechenzentrum Ihrer Organisation kann die Nachrichtenübermittlung fortgesetzt werden, sollte einer der beiden Server ausfallen.

Alternativ oder zusätzlich kann in ein sekundäres Rechenzentrum Redundanz eingeführt werden. Zwei Rechenzentrumskonfigurationen ermöglichen bei Ausfall eines Rechenzentrums die Fortsetzung des Betriebs. Wenn ein zusätzlicher Hub-Transport-Server in ein sekundäres Datacenter eingeführt wird, besteht die Möglichkeit, dass der zweite Hub-Transport-Server die Nachrichtenübermittlung übernimmt, sollte der primäre Hub-Transport-Server ausfallen oder das Produktionsdatacenter nicht verfügbar sein. Wenn drei Hub-Transport-Server bereitgestellt werden, können sich zwei davon im Produktionsrechenzentrum und einer im sekundären Rechenzentrum befinden.

Der Kernpunkt bei der Bereitstellung besteht darin, dass Redundanz Ausfälle verhindern kann, die ohne Redundanz zwangsläufig erfolgen würden. Die Ausfälle, die erfolgen können, ohne die Verfügbarkeit von Daten und Diensten zu beeinträchtigen, werden von der Bereitstellung redundanter Computer und Dienste bestimmt. Organisationen müssen ihre Anforderungen ermitteln und anschließend die betrieblichen Aspekte untersuchen, um die geeignetste Lösung zu finden. Beispiel: Eine Organisation möchte sein sekundäres Datencenter erst 20 Minuten nach dem Ausfall des Produktionsdatencenters aktivieren. In diesem Fall muss die Organisation die erforderlichen Prozesse einrichten, die für eine regelmäßige Überprüfung von Aktivierung und Betrieb des sekundären Datencenters sorgen. Eine andere Organisation legt ggf. fest, dass eine fortlaufende Überprüfung des sekundären Rechenzentrums wichtig für ihren Erfolg ist, was deshalb zu einer anderen Bereitstellungskonfiguration führt.