Bereitstellungen für hohe Verfügbarkeit

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

Letztes Änderungsdatum des Themas: 2008-01-17

Eins der primären Entwicklungsziele für hohe Verfügbarkeit in Microsoft Exchange Server 2007 bestand darin, die Praktiken und Konfigurationsoptionen für hohe Verfügbarkeit aus vorherigen Versionen von Exchange Server zu hinterfragen und zu verbessern. Durch Einhaltung eines strukturierten Planungsprozesses mit Exchange 2007 können Sie Ihre Bereitstellungs- und Betriebskosten senken und gleichzeitig Ihren Endbenutzern mehr Dienste anbieten.

Microsoft und zahlreiche Kunden haben die Lösungen mit hoher Verfügbarkeit in Exchange Server 2003 erfolgreich in der Produktion bereitgestellt, um eine Messagingumgebung mit hoher Verfügbarkeit zur Verfügung zu stellen. Darüber hinaus haben viele Kunden erfolgreich Partnerreplikationstechnologien bereitgestellt und Lösungen erstellt, die im Falle einer Fehlfunktion ein automatisches Failover auf eine zweite Kopie der Daten durchführen. Exchange 2007 umfasst Verbesserungen an den in Exchange 2003 vorhandenen Lösungen mit hoher Verfügbarkeit sowie neue Features für hohe Verfügbarkeit, die den Einsatz von Drittanbieter-Replikationstechnologien überflüssig machen und die Kosten sowie die Komplexität der Gesamtlösung verringern. Einige dieser Verbesserungen resultieren unmittelbar aus dem Feedback von Kunden, die über folgende Aspekte berichteten:

• Die Notwendigkeit von freigegebenem Speicher für die Lösung erhöhte deren Kosten und Komplexität. So musste beispielsweise die Hardware für die gesamte Lösung aus der Kategorie "Clusterlösungen" im Windows Server-Katalog getesteter Produkte gewählt werden. In Exchange 2007 halten Einzelkopiecluster (Single Copy Cluster, SCC) diese Anforderung weiterhin aufrecht, während Postfachclusterserver, die in einer Umgebung mit fortlaufender Clusterreplikation (Cluster Continuous Replication, CCR) konfiguriert sind, diese Anforderung nicht mehr stellen.

• Die Verwendung einer Einzelkopie der Postfachdaten bedeutete, dass Fehler dieser Kopie oder des zugehörigen Speichers zu massiven Unterbrechungen führten, die häufig zu langwierigen Ausfällen und manchmal Datenverlusten führten.

• Mangelnde Installations- und Verwaltungsintegration zwischen dem Clusterdienst und Exchange Server zwang Exchange-Administratoren dazu, sich exakte Kenntnisse der Clusterkonzepte und -funktionalität anzueignen. Für einige Exchange-Administratoren führte dies zu einem beachtlichen Einarbeitungsaufwand.

• Die voreingestellten Standardkonfigurationseinstellungen waren nicht auf ein optimales Wiederherstellungsverhalten abgestimmt. Administratoren mussten die Standardclusterressourcen und Clustereinstellungen manuell neu konfigurieren, um die Empfehlungen bewährter Methoden einzuhalten.

• Alle Exchange-Dienste (Clientzugriff, Transport und Speicher) wurden gemäß derselben Verfügbarkeitsstrategie behandelt, obwohl hinsichtlich der Architektur gravierende Unterschiede zwischen diesen Diensten bestanden, einschließlich verschiedenartiger Strategien für hohe Verfügbarkeit.

• Einige Kunden waren gezwungen, Partnertechnologien einzusetzen, um eine Lösung zu erzielen, die zwei Kopien der Postfachdaten pflegte. Solche Lösungen erhöhten die Kosten und die Komplexität der Bereitstellung.

Die Lösungen für hohe Verfügbarkeit in Exchange 2007 sind darauf ausgelegt, alle Mängel des in Exchange 2003 verwendeten Ansatzes für hohe Verfügbarkeit zu beseitigen. Exchange 2007 behebt diese Mängel durch Änderungen an der Architektur, die Unterstützung neuer Konfigurationen, eine Änderung des Verwaltungsmodells sowie durch die Einführung neuer Ansätze für hohe Verfügbarkeit. Das Ergebnis ist eine flexible Lösung, die jeder Organisation die Freiheit lässt, eine Lösung zu wählen, die den jeweiligen individuellen Bedürfnissen entspricht.

Bereitstellungsoptionen für hohe Verfügbarkeit

Hohe Verfügbarkeit sollte immer sowohl auf der Ebene der Einzelkomponente als auch im Kontext des Gesamtsystems bzw. der Gesamtlösung angelegt sein. Im Allgemeinen gibt es zwei Typen von Bereitstellungsoptionen für hohe Verfügbarkeit mit Exchange 2007:

• Einzeldatencenter-Bereitstellungen mit Redundanz, die sich bei einigen Fehlern nach einem kurzen Ausfall automatisch wiederherstellen können. Im Falle eines Standortfehlers ist eine Einzeldatencenter-Lösung von den Wiederherstellungsverfahren abhängig, um den Betrieb wiederherzustellen.

• Bereitstellungen mit mehreren Datencentern mit Redundanz, die sich bei den meisten Einzelfehlern automatisch wiederherstellen können. Eine Lösung mit mehreren Datencentern ermöglicht einer Organisation, einen Datencenterausfall zu überstehen, ohne Wiederherstellungsverfahren anwenden zu müssen. Nicht wiederherstellbare Fehler, wie beispielsweise ein Standorttotalausfall, erfordern ein manuelles Eingreifen zur Wiederherstellung.

Beide Bereitstellungsoptionen werden weiter unten in diesem Thema ausführlicher behandelt.

Einzeldatencenter-Konfigurationen

Einzeldatencenter-Konfigurationen für die Serverfunktionen UnifiedMessaging, Hub-Transport, ClientAccess und Edge-Transport greifen alle auf ähnlich konfigurierte, redundante Server zurück. Für Postfachserver gibt es drei Konfigurationen mit hoher Verfügbarkeit, die innerhalb eines einzelnen Datencenters Daten- und Dienstverfügbarkeit herstellen: SCC, CCR und fortlaufende lokale Replikation (Local Continuous Replication, LCR) Die folgende Abbildung illustriert eine allgemeine Bereitstellung für eine vollständig redundante Einzeldatencenter-Konfiguration.

Einzeldatencenter-Konfiguration mit vollständiger Redundanz

In der vorangehenden Abbildung wurde die Redundanzkonfiguration für die Serverfunktion Mailbox ausgelassen. Die Ursache hierfür ist, dass eine Organisation hierbei mehrere Möglichkeiten hat, einschließlich einer Vielzahl verschiedener Konfigurationen unter Verwendung von SCC und CCR.

Einzelkopiecluster

Die Clusterkonfiguration mit freigegebenem Speicher wird in Exchange 2007 als Einzelkopiecluster (Single Copy Cluster, SCC) bezeichnet. Ein Einzelkopiecluster verwendet den Clusterdienst sowie freigegebenen Speicher für die Aufnahme eines Postfachclusterservers. Ein Postfachclusterserver ist ein logischer Computer, der im Laufe seiner Lebenszeit zwischen physikalischen Knoten verschoben wird. Dies wird durch die Fähigkeit des Clusterdiensts ermöglicht, eine ungebundene Netzwerkidentität zu erstellen und zu verwalten. Die ungebundene Netzwerkidentität wird als Netzwerkidentität des Postfachclusterservers verwendet. Exchange-Setup erstellt diese Netzwerkidentität automatisch unter Verwendung des Hostnamens und der IP-Adresse, die vom Administrator angegeben werden. Die ungebundene Netzwerkidentität wird auf Grundlage der Knotenverfügbarkeit und Wartungsanforderungen zwischen den Knoten im Cluster verschoben. Diese Mechanismen erlauben Benutzern den Zugriff auf ihre Postfachdaten, wenn der Speicher verfügbar und mindestens einer der zwei Knoten in Betrieb ist. Damit die Wiederherstellung nach Fehlern funktioniert, arbeiten Exchange und der Clusterdienst zusammen, um den Postfachclusterserver nach einem Fehler auf einem verfügbaren Knoten online zu schalten.

Im Folgenden finden Sie zahlreiche wesentliche Verbesserungen von Exchange 2007 gegenüber der in früheren Versionen von Exchange Server vorhandenen Clusterfunktion mit freigegebenem Speicher:

• Nur die Serverfunktion Mailbox ist clusterabhängig, und sie ist die einzige Funktion, die in einem Failovercluster installiert werden kann.

• Das voreingestellte Failoververhalten wurde so optimiert, dass es nur dann zu einem Failover kommt, wenn die Wahrscheinlichkeit hoch ist, dass die Verfügbarkeit durch ein Failover verbessert wird. Lediglich ein vollständiger Knotenausfall oder die Unfähigkeit eines Knotens mit Clients zu kommunizieren führen zu einem Failover.

• Der Großteil der Administration wurde aus Cluster Administrator in die Exchange-Tools verschoben, z. B. die Exchange-Verwaltungsshell. Auf diese Weise verringert sich der Einarbeitungsaufwand für Administratoren von Einzelkopieclustern.

• Die Installation von Postfachclusterservern wurde in das Setup integriert, wodurch sie sich wie eine eigenständige Installation handhaben lässt.

Die folgende Abbildung zeigt eine typische Konfiguration für einen Einzelkopiecluster. Ein Einzelkopiecluster unterstützt bis zu acht Knotencluster, die über mindestens einen passiven Knoten verfügen.

Abbildung 2   Grundlegende Architektur eines Einzelkopieclusters

In der vorangehenden Abbildung sind die zwei Konten in einem Failovercluster zusammengefügt. Der Cluster verwendet einen freigegebenen Datenträger, um die Clusterquorumressource zu verwalten, die als der Datenträger "Quorum" dargestellt ist. Der aktive Knoten ist aktuell Besitzer der Datenträgerressourcen, auf denen sich die Protokolle und Datenbankdateien des Postfachclusterservers befinden. Dieser Besitzerstatus wird durch die blauen Linien zwischen dem aktiven Knoten und den Datenträgern dargestellt. In dieser Konfiguration hat der aktive Knoten Zugriff auf die Datenträger, aber der passive Knoten hat keinen gleichzeitigen Zugriff.

Der aktive und der passive Knoten sind über mindestens zwei Netzwerke (privat und gemischt) miteinander verbunden. Nur eins der zwei Netzwerke wird für die Clientkommunikation verwendet (das gemischte Netzwerk). Der Clusterdienst überprüft regelmäßig den Status der Kommunikation beider Netzwerke.

Weitere Informationen zu SCC finden Sie unter Einzelkopiecluster.

Fortlaufende Clusterreplikation

Wie der Name bereits impliziert, enthält ein Einzelkopiecluster nur eine einzige Kopie der Postfachdaten. Bei einem Fehler des Speichers, auf dem sich die Postfachdaten befinden, kommt es zu keiner automatischen Wiederherstellung. Tatsächlich führt ein solcher Fehler üblicherweise zu einem umfangreicheren Ausfall und Datenverlusten. Die Verbesserungen beim Einzelkopiecluster gegenüber früheren Clusterlösungen resultieren aus der Umsetzung des Feedbacks, das uns von Kunden bezüglich der früheren Lösungen für hohe Verfügbarkeit erreicht hat. Dennoch birgt der Einzelkopiecluster immer noch die Komplexität, die mit der Verwendung von freigegebenem Speicher einhergeht. Es gibt von vornherein mindestens zwei Einzelfehlerquellen (Single Point of Failure, SPoF): den einzigen Quorumdatenträger und die einzige Kopie der Exchange-Daten. In Exchange 2007 gibt es einen zweiten Typ von Konfiguration für hohe Verfügbarkeit, der vollständige Redundanz bietet, ohne dass die Hardware aus der Kategorie "Clusterlösungen" des Windows Server-Katalogs getesteter Produkte stammen muss. Diese Lösung trägt den Namen fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR).

Die CCR verwendet integrierten, asynchronen Protokollversand zum Replizieren der Postfachdaten zwischen zwei Servern in einem Failovercluster. Die Integration von Replikation und Clusterfunktion liefert eine Lösung, bei der es keine Einzelfehlerquelle (SPoF) gibt, und bietet automatische Wiederherstellung bei Serverfehlern. Darüber hinaus wird kein freigegebener Speicher mehr benötigt, was wiederum die Bereitstellungskosten senkt und die Komplexität verringert. CCR unterstützt Cluster mit zwei Knoten und höchstens zwei Kopien der Daten (die aktive und die passive Kopie). Die folgende Abbildung zeigt eine typische CCR-Umgebung.

Grundlegende Bereitstellung von CCR

Zwei wesentliche Veränderungen, die in der vorangehenden Abbildung illustriert werden, sind das Fehlen eines freigegebenen Quorumdatenträgers und das Vorhandensein einer Dateifreigabe auf einem dritten Computer, der sich außerhalb des Clusters befindet. Die Dateifreigabe ist Bestandteil der neuen Clusterquorumfunktionen, die mit dem Update eingeführt werden, das im Microsoft Knowledge Base-Artikel 921181 Eine Aktualisierung ist verfügbar, die ein Dateifreigabenzeugen-Feature und ein konfigurierbares Clustertaktfeature zu Windows Server 2003 Service Pack 1-basierten Serverclustern hinzufügt, beschrieben wird. Das Update ermöglicht dem Clusterdienst die Verwendung einer Quorumressource, die anstelle eines Wählerknotens im Cluster eine Dateifreigabe verwendet. Ohne das Update stehen als einzige Quorumoptionen die Verwendung eines freigegebenen Datenträgers oder eine konventionelle Konfiguration mit Hauptknotensatz zur Verfügung. Beide Optionen haben Nachteile und treiben die Kosten nach oben:

• Die Verwendung eines freigegebenen Datenträgers führt die Komplexität von freigegebenen Speichern wieder in die Lösung ein.

• Hauptknotensatzquoren erfordern mindestens drei Knoten. In dieser Konfiguration ist ein zusätzlicher Knoten (als Wählerknoten bezeichnet) erforderlich, der als Wählerknoten im Cluster fungiert.

Weitere Informationen zur fortlaufenden Clusterreplikation finden Sie unter Fortlaufende Clusterreplikation.

Fortlaufende lokale Replikation

CCR bietet vollständige Redundanz von Daten und Diensten, und Einzelkopiecluster bieten Dienstredundanz. Organisationen, die zwar Datenredundanz, aber keine Dienstredundanz benötigen, können die fortlaufende lokale Replikation (Local Continuous Replication, LCR) verwenden. LCR ist keine Clusterlösung, weshalb keine Dienstverfügbarkeit bereitgestellt wird. Die folgende Abbildung zeigt eine typische LCR-Umgebung.

Grundlegende Bereitstellung von fortlaufender lokaler Replikation

LCR verwendet die integrierte fortlaufende Replikationstechnologie, die im vorangehenden CCR-Abschnitt beschrieben wurde, zum Erstellen einer zweiten Kopie einer Speichergruppe (als passive Kopie bezeichnet) auf dem lokalen Computer. Bei dem Computer muss es sich um einen eigenständigen Postfachserver handeln (kein Cluster). In einer LCR-Umgebung legt der Administrator fest, welche Speichergruppen eine passive Kopie besitzen, und konfiguriert einen zweiten Speicherort für diese passiven Kopien auf demselben Server.

Bei Verwendung von LCR muss der Administrator explizit festlegen, welche Speichergruppen passive Kopien besitzen sollen. Administratoren können festlegen, dass eine passive Kopie von einer vorhandenen Speichergruppe erstellt wird, oder im Verlauf der Erstellung einer neuen Speichergruppe für diese LCR aktivieren. Der Administrator muss einen zweiten Speicherort für die Protokoll- und Datenbankdateien dieser LCR-aktivierten Speichergruppen konfigurieren.

Bei LCR muss die zweite Kopie manuell aktiviert werden. Es gibt kein Failover bei LCR, da es sich hierbei um einen Clustervorgang handelt. LCR ist aber keine Clusterlösung. Stattdessen muss der Administrator entscheiden, dass die aktive Kopie nicht mehr funktionsfähig ist, und dann die passive Kopie manuell aktivieren, wodurch diese zur neuen aktiven Kopie wird. Der Aktivierungsprozess der passiven Kopie ist einfach und schnell.

Der Administrator kann LCR jederzeit aktivieren und eine passive Kopie einer vorhandenen Datenbank erstellen. Alternativ kann LCR auch sofort bei der Erstellung einer neuen Datenbank aktiviert werden. Im Anschluss an die Aktivierung von LCR wird mithilfe eines Prozesses namens "Seeding" eine Basislinienkopie erstellt, woraufhin die Replikation (der Protokollversand) initiiert wird. Eine bewährte Methode besteht darin, die passive Kopie auf Datenträgern oder einer Speicheranlage anzusiedeln, die von der aktiven Kopie getrennt sind. Auf diese Weise minimiert sich das Risiko des Auftretens gleichzeitiger Mehrfachfehler. LCR hat hinsichtlich der Ressourcenanforderungen Auswirkungen auf den Postfachserver. Der Postfachserver führt alle Verarbeitungen im Zusammenhang mit der fortlaufenden Replikation aus, was bei der Kapazitätsplanung für den Server berücksichtigt werden muss. Die Eingabe-/Ausgabebelastung (E/A) der aktiven Kopie ist beschränkt, weil der Großteil der E/A-Aktivität für die passive Kopie durch deren Protokoll- und Datenbankdateien erzeugt wird.

LCR unterstützt Sicherungen der passiven Kopie mithilfe des Exchange-abhängigen Volumeschattenkopie-Diensts (Volume Shadow Copy, VSS). Wenn die Datenträgervolumes mit der aktiven Kopie entsprechend von der passiven Kopie getrennt sind, stellen VSS-Sicherungen ohne hardwarebasierte VSS-Unterstützung eine gute Lösung dar. Sicherungen der passiven Kopie verringern die Sicherungs-E/A-Auslastung der Datenträgervolumes der aktiven Kopie. Da die passive Kopie keine Echtzeitantworten an Clients ausführen muss, kann sie den Kosten Rechnung tragen, die mit dem Einsatz eines softwaregestützten VSS-Writers einhergehen. Zusätzlich kann es in Abhängigkeit von Ihrer Kapazitätsplanung praktisch sein, das Sicherungszeitfenster auf dem Server mithilfe von LCR zu erweitern. Der Hauptaspekt hierbei ist die Aufrechterhaltung der gleichmäßigen Prozessorauslastung durch den Sicherungs-Agent während des gesamten Sicherungszeitfensters.

Die passive Kopie ist die erste Verteidigungsmaßnahme bei Fehlern und Datenausfällen. Mit LCR kann die Wiederherstellungsdauer nach dem ersten Ausfall gemäß der Vereinbarung zum Servicelevel (SLA) relativ kurz gewählt werden. Bei einem doppelten Ausfall ist eine Wiederherstellung von einer Sicherung erforderlich. Bei diesem Modell kann der Zeitraum der Vereinbarung zum Servicelevel wesentlich länger ausfallen. Hieraus resultiert ein Ablauf wöchentlicher, vollständiger Sicherungen sowie täglicher inkrementeller Sicherungen als praktikable und empfohlene Strategie. Diese Strategie verringert darüber hinaus das Gesamtdatenvolumen, das auf Sicherungsmedien übertragen wird.

Zusammenfassend stellt die fortlaufende lokale Replikation (LCR) eine besonders gut geeignete Option für Organisationen dar, die eine schnelle Wiederherstellung nach einem Datenausfall oder bei fehlerhaften Daten benötigen, bei denen aber geplante und ungeplante Serverausfälle akzeptabel sind. LCR bietet die folgenden Vorzüge:

• Schnelle, zweistufige Wiederherstellung bei Fehlern oder Ausfall einer aktiven Datenbank

• Selektivität durch den Administrator, woraus Schutz für die Benutzer, die diesen am meisten benötigen, resultiert.

• Verfügbarkeit auf Postfachservern beliebiger Größe und in allen Produkten

• Minimale Auswirkungen auf die E/A-Vorgänge in der aktiven Datenbank und dem Protokoll

• Möglichkeit der Auslagerung von Sicherungs-E/A-Vorgänge aus der aktiven Datenbank und von Protokollvolumes

• Möglichkeit der Reduzierung der auf Sicherungsmedien zu übertragenden Gesamtdatenmenge bei gleichzeitiger Verlängerung des Zeitfensters für die Sicherung

• Trennung der Administration auf der Exchange-Ebene durch den Einsatz der Exchange-Verwaltungskonsole bzw. der Exchange-Verwaltungsshell.

Weitere Informationen zur fortlaufenden lokalen Replikation finden Sie unter Fortlaufende lokale Replikation.