(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Geographisch verteilte Cluster in Exchange Server 2003

 

Letztes Änderungsdatum des Themas: 2005-09-12

Geographisch verteilte Cluster ermöglichen einen Datenzugriff mit hoher Verfügbarkeit. Häufig ist die Implementierung einer geographisch verteilten Clusterbildung so kostspielig, dass es sich der Kunde gründlich überlegt und erst einmal nach einer anderen Lösung sucht, mit der sich die gewünschte zusätzliche Daten- und Betriebssicherheit realisieren lässt. Für den Kunden, der die zusätzliche Redundanz für eine fehlertolerante Installation benötigt, sind geographisch verteilte Cluster jedoch eine hervorragende Lösung.

Dieser Artikel gibt Antworten auf einige häufig gestellten Fragen und hilft auf diese Weise, die Grundlagen von geographisch verteilten Clustern besser zu verstehen. Angaben zur Leistung und Testempfehlungen vervollständigen die Beschreibung. Im Artikel werden außerdem die von Microsoft unterstützten Lösungen erläutert und wertvolle Ressourcen vorgestellt, die weitere Informationen über geographisch verteilte Cluster enthalten.

noteAnmerkung:
Für die Implementierung eines geographisch verteilten Clusters müssen Sie mit einem Drittanbieter zusammenarbeiten. Daher können die in diesem Artikel enthaltenen Informationen im Widerspruch zu den Informationen Ihres Drittanbieters stehen.

Geographisch verteilte Cluster, auch Stretched Cluster oder Multi-Site Cluster genannt, sind Cluster, die sich aus Knoten an unterschiedlichen räumlichen Standorten zusammensetzen. Geographisch verteilte Cluster sollen beim Ausfall eines Standorts aufgrund von Stromversorgungsproblemen, Naturkatastrophen oder unvorhersehbaren Ereignissen Ausfallsicherheit (Failover) bieten.

Wenn Sie genau verstehen wollen, wie eine geographisch verteilte Clusterbildung mit Microsoft® Exchange Server 2003 funktioniert, müssen Sie zunächst die Grundvoraussetzungen für eine derartige Lösung kennen. Ein geographisch verteilter Cluster setzt sich aus Hardware und Software zusammen. Mit anderen Worten: Ein geographisch verteilter Cluster besteht aus einzelnen Bruchstücken, die von unterschiedlichen Anbietern geliefert werden. Aufgrund der komplexen Natur dieser Konfigurationen und der Konfigurationseinschränkungen, die der Microsoft Windows® Clustertechnik eigen sind, sollten geographisch verteilte Cluster nur in Zusammenarbeit mit Anbietern realisiert werden, die geeignete Konfigurationen bereitstellen. Wenn Exchange Server 2003 in einer geographisch verteilten Clusterlösung ausgeführt werden soll, muss die Lösung die folgenden Kriterien erfüllen:

  • Für die Knoten muss ein gemeinsames Datenträgersubsystem verwendet werden.
  • Die Knoten müssen sich im selben lokalen Netzwerk (LAN)/Subnetz befinden.
  • Der Netzwerk-Heartbeat zwischen den einzelnen Knoten muss niedrige Latenzzeiten (unter 500 ms) aufweisen.

Bei geographisch verteilten Clustern sind die oben genannten Kriterien erfüllt, wenn Sie Daten auf Datenträgerebene replizieren und ein virtuelles LAN (VLAN) erstellen, mit dessen Hilfe sich das Subnetz über WAN-Verknüpfungen erstrecken kann.

noteAnmerkung:
Durch die Verwendung eines Hauptknotensatzquorums lässt die Windows-Clustertechnik die Erstellung eines Clusters ohne gemeinsames Datenträgerarray und gemeinsamen Quorumdatenträger zu. In Exchange Server wird diese Methode der Clusterbildung unterstützt. Die Lösung muss jedoch im WindowsServer Catalog im Bereich Cluster Solutions > Geographically Dispersed Cluster Solution gelistet sein. Unterstützt werden außerdem nur Lösungen mit synchroner Replikation.

Für die Unterstützung einer geographisch verteilen Clusterlösung gibt es viele verschiedene Replikationstechniken. Bei allen Techniken wird eine von zwei möglichen Replikationsarten verwendet: synchron oder asynchron.

Bei einem geographisch verteilten Exchange-Cluster unterscheiden sich die beiden Replikationsarten hauptsächlich dadurch, dass die synchrone Replikation unterstützt wird, während das bei der asynchronen Replikation nicht der Fall ist. Darüber hinaus weisen die beiden Replikationsarten die folgenden Hauptunterschiede auf:

  • Art und Zeitpunkt des Schreibvorgangs von Datenblöcken am lokalen Standort und an den Remotestandorten
  • Art der Rückmeldung derartiger Schreibvorgänge an das Betriebssystem
  • Status der Datensynchronisation auf den lokalen und Remotedatenträgern zum jeweiligen Zeitpunkt

Bei der synchronen Replikation wird ein Vorgang, der von einer Anwendung an einem Standort ausgeführt wird, nicht eher abgeschlossen, bis die Änderung auch an den anderen Standorten vorgenommen wurde.

Betrachten Sie als Beispiel die synchrone Replikation auf Blockebene. Eine Anwendung am Standort A schreibt einen Datenblock auf einen Datenträger, der auf den Standort B gespiegelt wird. Der E/A-Vorgang wird nicht eher abgeschlossen, bis die Änderung sowohl auf dem Datenträger am Standort A als auch auf dem Datenträger am Standort B vorgenommen wurde. Diese Vorgehensweise beruht auf der Methode, mit der die Replikationssoftware dem Schreibvorgang die Kommunikation mit dem Betriebssystem ermöglicht. Die Replikationssoftware meldet den Schreibvorgang dem Betriebssystem erst dann als abgeschlossen zurück, wenn der Schreibvorgang an den beiden Standorten A und B ausgeführt wurde.

Bei der asynchronen Replikation gelangt die Änderung, die am Standort A an den Daten vorgenommen wird, letztlich auch zum Standort B. Mit „letztlich“ ist dabei gemeint, dass bei der asynchronen Replikation das Betriebssystem und die Replikationssoftware nicht die Bestätigung des Remotestandorts über den Abschluss des Schreibvorgangs abwarten.

Um beim obigen Beispiel zu bleiben: Eine Anwendung am Standort A schreibt einen Datenblock auf einen Datenträger, der auf den Standort B gespiegelt wird. Der E/A-Vorgang wird unmittelbar nach dem Schreiben der Änderung auf den Datenträger am Standort A beendet. Die Replikationssoftware überträgt die Änderung in einem separaten Prozess an den Standort B, wo dann die entsprechende Änderung vorgenommen wird.

Wenn ein Failover zu einem Zeitpunkt stattfindet, an dem aufgrund der Schreibverzögerung die Daten nicht übereinstimmen, kann der Failover aufgrund der asynchronen Replikation fehlerhaft sein. Da die Schreibvorgänge am Remotestandort und die Schreibvorgänge am lokalen Standort nicht synchron erfolgen, gibt es keine Möglichkeit, die Übereinstimmung der Daten an beiden Standorten sicherzustellen. Bei einer geographisch verteilten Clusterlösung gibt es keinen Failover mit asynchroner Replikation. Stattdessen muss der Benutzer einen Standby-Server online schalten und die replizierten Daten am Failover-Standort bereitstellen.

Bei Exchange Server wird keine asynchrone Replikation unterstützt, weil die Schreibreihenfolge von der Replikationssoftware gesteuert wird und der Lösungsanbieter dies unterstützen muss. Bei einer asynchronen Replikation können außerdem leichter Datenfehler auftreten, da bei Exchange die Reihenfolge der Schreibbefehle eine Rolle spielt.

Bei zwei Standorten, die eine asynchrone Replikation verwenden, sind inkonsistente Daten unvermeidbar. Daher wird Exchange Server von Microsoft nur in einem Umfeld mit synchroner Replikation unterstützt, für das Hardware verwendet wird, die im WindowsServer Catalog im Bereich Cluster Solutions > Geographically Dispersed Cluster Solution gelistet ist.

Weitere Informationen zu Replikationsmethoden finden Sie in den folgenden Ressourcen:

Eine geographisch verteilte Clusterinstallation unterscheidet sich hauptsächlich durch die höheren Kosten von dem standardmäßigen Test- und Überwachungsbedarf einer Exchange Server-Installation. Daher sollten Sie der Datenträgerlatenz besondere Beachtung schenken. Die Vorgehensweise zum Testen der Datenträgerlatenz wurde bereits ausreichend dokumentiert. Ausführliche Informationen zu den Datenträgerleistungseinstellungen und den Testverfahren finden Sie unter Optimieren von Speichersystemen für Exchange Server 2003.

Für einige geographisch verteilte Cluster ist eine Glasfaserverbindung zwischen dem primären Standort und den Backup-Standorten erforderlich, wodurch sich gewisse Einschränkungen in Bezug auf die zulässige Entfernung zwischen den Standorten ergeben. Bei anderen Lösungen werden die Daten als IP-Paket über eine Ethernet-Verbindung oder einen Datenübertragungsrahmen übertragen. Ungeachtet der verwendeten Verbindungsart ist mit zunehmender Entfernung zwischen den Standorten mit höheren Latenzzeiten zu rechnen. Durch die höheren Latenzzeiten reduziert sich im Gegenzug der Nutzen der Lösung, die zudem schwieriger zu unterstützen ist.

Bei einer geographisch verteilten Lösung gehen höhere Latenzzeiten auch zu Lasten der Anzahl der Benutzer, die auf einem einzelnen Server unterstützt werden können. Die Anzahl der Benutzer, die pro Server unterstützt werden können, nimmt mit der Zunahme der Latenz ab. Daher müssen zur Unterstützung der Umgebung mehr Server eingesetzt werden, wodurch sich wiederum die Gesamtkosten der Exchange-Installation erhöhen.

Die meisten zertifizierten Lösungen wurden zur Unterstützung eines ganz speziellen Szenarios entwickelt. Zu den Bausteinen dieses Szenarios zählt auch die maximal unterstützte Entfernung zwischen den Standorten. Bei zunehmender Entfernung nimmt die Anzahl der verfügbaren Lösungen ab.

Neben der Entscheidung, welche Lösung am besten für Ihre Exchange-Organisation geeignet ist, müssen Sie auch noch viele andere Voraussetzungen und Anforderungen bedenken, wenn Sie Überlegungen in Bezug auf eine geographisch verteilte Clusterlösung anstellen. Unbedingt zu beachten sind beispielsweise die folgenden Punkte:

  • Stellen Sie sich die Frage: „Müssen neben Exchange-Daten noch weitere Daten repliziert werden?“ Müssen beispielsweise Dateiserver repliziert werden?
  • Die LAN- und WAN-Netzwerke müssen eine ausreichende Fehlertoleranz aufweisen, damit die Clientcomputer bei Ausfall des primären Standorts nahtlos mit dem neuen Standort kommunizieren können.
  • Am Failover-Standort muss eine ausreichende Anzahl von Domänencontrollern und globalen Katalogservern bereitstehen. Die Domänencontroller und globalen Katalogserver müssen das Anforderungsvolumen unterstützen, das für ein Funktionieren der Exchange-Server und Clientcomputer auf akzeptablen Levels erforderlich ist. Diese Levels sollten in einer SLA-Anforderung (Service Level Agreement) definiert werden.
  • Die Hardware am Failover-Standort muss die Benutzeranforderungen auf einem akzeptablen Level unterstützen können. Dieser Level sollte in einer SLA-Anforderung dokumentiert werden.
  • Die Replikationsverknüpfung zwischen Failover-Standort und primärem Standort muss über genügend Bandbreite verfügen und ausreichend schnell sein, damit die durch das E-Mail-Volumen vorgegebenen Anforderungen an die Datenreplikation unterstützt werden können.
  • Es wäre von Vorteil, wenn Sie Mitarbeiter hätten, die die Lösung umfassend unterstützen könnten.

Möglicherweise sind bei Ihrer speziellen Implementierung noch weitere Anforderungen zu berücksichtigen, wie beispielsweise ein auf einem anderen Server gehosteter Webdienst, für den Exchange erforderlich ist, Unterstützung für VPN-Remotebenutzer (Virtual Private Network), Replikation einer Datenarchivierungslösung usw.

Nachdem Sie Überlegungen in Bezug auf alle in Frage kommenden Bausteine und Dienstanforderungen angestellt haben, müssen Sie sich mit den Unterstützungsrichtlinien von Microsoft vertraut machen. Nachfolgend eine Liste der Systemvoraussetzungen für geographisch verteilte Exchange-Cluster:

Microsoft empfiehlt seinen Kunden dringend, mit den Anbietern der Replikationslösung folgende Punkte zu klären:

  • Zählt die Lösung zur Kategorie der geographisch verteilten Clusterlösungen?
  • Werden durch die Replikationslösung sämtliche Risiken eines Datenverlusts ausgeschaltet (außer bei gleichzeitigem Ausfall aller Standorte)?
  • Welche Verfahren werden für Failover und Failback verwendet?
  • Kann mit der Replikationslösung und der voraussichtlichen Latenz die geplante Exchange-Benutzerlast bewältigt und eine qualitativ hochwertige Clientleistung bereitgestellt werden?

Im vorliegenden Artikel haben Sie einen Überblick über die geographisch verteilte Clusterbildung in Exchange Server 2003 erhalten. Es gibt jedoch noch eine Reihe von ausführlichen Unterlagen, die Ihnen bei der Entscheidung für die richtige Lösung behilflich sein können:

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft