Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Microsoft Exchange Server 2010 enthält ein neues einheitliches Framework für die Ausfallsicherheit von Postfächern, das neue Funktionen wie die Database Availability Group (DAG) und Postfachdatenbankkopien umfasst. Obwohl sich die Bereitstellung dieser neuen Funktionen schnell und einfach gestaltet, muss vorab eine sorgfältige Planung erfolgen, um sicherzustellen, dass alle Lösungen für hohe Verfügbarkeit und Ausfallsicherheit von Standorten, die diese Funktionen verwenden, Ihren Erwartungen und den Anforderungen im Unternehmen entsprechen.

Während der Planungsphase sollten die Systemarchitekten, Administratoren und andere Entscheidungsträger die Anforderungen für die Bereitstellung identifizieren, insbesondere die Anforderungen für hohe Verfügbarkeit und Ausfallsicherheit von Standorten. Für die Bereitstellung dieser Funktionen müssen allgemeine Anforderungen sowie Hardware-, Software- und Netzwerkanforderungen erfüllt werden. Weitere Informationen zu den Speicheranforderungen für DAGs finden Sie unter Speicherentwurf für Postfachserver.

Inhalt

Allgemeine Anforderungen

Hardwareanforderungen

Speicheranforderungen

Softwareanforderungen

Netzwerkanforderungen

Zeugenserveranforderungen

Planen der Ausfallsicherheit von Standorten

Planen eines Datencenterswitchovers

Allgemeine Anforderungen

Stellen Sie sicher, dass die folgenden systemweiten Anforderungen erfüllt sind, bevor Sie eine DAG bereitstellen und Postfachdatenbankkopien erstellen:

  • DNS (Domain Name System) muss ausgeführt werden. Der DNS-Server sollte im Idealfall dynamische Updates akzeptieren. Wenn der DNS-Server keine dynamischen Updates akzeptiert, müssen Sie einen DNS-Hosteintrag (A-Eintrag) für jeden Exchange-Server erstellen. Andernfalls funktioniert Exchange nicht ordnungsgemäß.

  • Jeder Postfachserver in einer DAG muss ein Mitgliedsserver in derselben Domäne sein.

  • Das Hinzufügen eines Exchange 2010-Postfachservers, der gleichzeitig ein Verzeichnisserver für eine DAG ist, wird nicht unterstützt.

  • Der von Ihnen der DAG zugeordnete Name muss ein gültiger, verfügbarer und eindeutiger Computername mit maximal 15 Zeichen sein.

Hardwareanforderungen

Grundsätzlich gibt es keine besonderen Hardwareanforderungen für DAGs oder Postfachdatenbankkopien. Die verwendeten Server müssen allen Anforderungen entsprechen, die in den Themen für Exchange 2010 Prerequisites und Exchange 2010 – Systemanforderungen dargelegt wurden. Informationen zur Hardwareplanung finden Sie in den folgenden Themen:

Speicheranforderungen

Grundsätzlich gibt es keine besonderen Speicheranforderungen für Database Availability Groups (DAGs) oder Postfachdatenbankkopien. Für DAGs ist kein clusterverwalteter gemeinsamer Speicher erforderlich, er wird von DAGs auch nicht verwendet. Clusterverwalteter gemeinsamer Speicher wird für die Verwendung in einer DAG nur unterstützt, wenn die DAG so konfiguriert ist, dass eine Lösung mit einer in Exchange 2010 integrierten Replikations-API von Drittanbietern verwendet wird. Weitere Informationen zur Speicherplanung finden Sie unter Speicherentwurf für Postfachserver.

Softwareanforderungen

DAGs sind sowohl in der Exchange 2010 Standard Edition als auch in der Exchange 2010 Enterprise Edition verfügbar. Außerdem kann eine DAG eine Kombination von Servern enthalten, die Exchange 2010 Standard Edition und Exchange 2010 Enterprise Edition ausführen.

Alle Mitglieder der DAG müssen auch dasselbe Betriebssystem ausführen. Exchange 2010 wird sowohl auf Windows Server 2008- als auch auf Windows Server 2008 R2-Betriebssystemen unterstützt. Alle Mitglieder einer DAG müssen entweder Windows Server 2008 oder Windows Server 2008 R2 ausführen. Eine Kombination aus Windows Server 2008 und Windows Server 2008 R2 ist nicht möglich.

Zusätzlich zur Einhaltung der Voraussetzungen für die Installation von Exchange 2010 müssen Betriebssystemanforderungen eingehalten werden. DAGs verwenden das Windows-Failoverclustering und machen somit die Enterprise-Version von Windows erforderlich.

Netzwerkanforderungen

Für jede DAG und für jedes Mitglied einer DAG müssen bestimmte Netzwerkanforderungen eingehalten werden. DAG-Netzwerke sind vergleichbar mit den öffentlichen, gemischten und privaten Netzwerken, die in früheren Versionen von Exchange verwendet wurden. Anders als bei früheren Versionen wird die Verwendung eines einzelnen Netzwerks in jedem Mitglied einer DAG unterstützt. Darüber hinaus hat sich die Terminologie geringfügig geändert. Anstelle von öffentlichen, privaten oder gemischten Netzwerken verfügt jede DAG über ein einzelnes MAPI-Netzwerk, das von anderen Servern verwendet wird (z. B. anderen Exchange 2010-Servern, Verzeichnisservern usw.), um mit dem Mitglied der DAG und möglicherweise mit Replikationsnetzwerken zu kommunizieren, bei denen es sich um Netzwerke handelt, die für den Protokollversand und das Seeding vorgesehen sind.

Obwohl ein einzelnes Netzwerk unterstützt wird, empfehlen wir, dass jede DAG mindestens zwei Netzwerke verwendet: ein einzelnes MAPI-Netzwerk und ein einzelnes Replikationsnetzwerk. Dadurch wird für das Netzwerk und den Netzwerkpfad eine Redundanz zur Verfügung gestellt. Außerdem wird es dem System ermöglicht, zwischen einem Serverfehler und einem Netzwerkfehler zu unterscheiden. Die Verwendung eines einzelnen Netzwerkadapters verhindert, dass das System zwischen diesen beiden Fehlertypen unterscheiden kann.

Hinweis

Die Produktdokumentation in diesem Inhaltsbereich wurde unter der Annahme geschrieben, dass jedes Mitglied einer DAG mindestens zwei Netzwerkadapter enthält und dass jede DAG mit einem MAPI-Netzwerk und mindestens einem Replikationsnetzwerk konfiguriert ist. Außerdem wird davon ausgegangen, dass das System in der Lage ist, zwischen einem Netzwerkfehler und einem Serverfehler zu unterscheiden.

Ziehen Sie folgende Punkte in Betracht, wenn Sie die Netzwerkinfrastruktur für Ihre DAG entwerfen:

  • Jedes Mitglied der DAG muss mindestens einen Netzwerkadapter besitzen, der mit allen anderen Mitgliedern der DAG kommunizieren kann. Bei einem einen einzelnen Netzwerkpfad wird empfohlen, ein Gigabit-Ethernet zu verwenden. Bei Verwendung eines einzelnen Netzwerkadapters in den einzelnen Mitgliedern der DAG muss das DAG-Netzwerk für die Replikation aktiviert werden und sollte ferner als MAPI-Netzwerk konfiguriert sein. Da keine weiteren Netzwerke vorhanden sind, verwendet das System das MAPI-Netzwerk auch als Replikationsnetzwerk. Außerdem wird bei Verwendung eines einzelnen Netzwerkadapters in den jeweiligen Mitgliedern der DAG empfohlen, dass Sie die Gesamtlösung unter Berücksichtigung des einzelnen Netzwerkadapters entwerfen.

  • Durch die Verwendung von zwei Netzwerkadaptern in den einzelnen Mitgliedern der DAG erhalten Sie ein MAPI-Netzwerk und ein Replikationsnetzwerk sowie die folgenden Verhaltensweisen bei der Wiederherstellung:

    • Falls ein Fehler auftritt, der das MAPI-Netzwerk beeinflusst, tritt ein Failover des Servers auf (unter der Annahme, dass fehlerfreie Postfachdatenbankkopien vorhanden sein, die aktiviert werden können).

    • Falls ein Fehler in Bezug auf das Replikationsnetzwerk auftritt, werden die Protokollversand- und Seedingoperationen so zurückgesetzt, dass sie das MAPI-Netzwerk verwenden, sofern dieses von dem Fehler nicht betroffen ist. Dies gilt selbst dann, wenn für das MAPI-Netzwerk die Eigenschaft ReplicationEnabled auf "False" festgelegt ist. Wenn das fehlerhafte Replikationsnetzwerk wiederhergestellt wurde und die Protokollversand- und Seedingoperationen fortgesetzt werden können, müssen Sie manuell zum Replikationsnetzwerk zurückwechseln. Zum Ändern der Replikation vom MAPI-Netzwerk auf ein wiederhergestelltes Replikationsnetzwerk können Sie die fortlaufende Replikation entweder mit den Cmdlets "Suspend-MailboxDatabaseCopy" und "Resume-MailboxDatabaseCopy" anhalten und wieder fortsetzen, oder Sie starten den Microsoft Exchange-Replikationsdienst neu. Es wird empfohlen, die Vorgänge anzuhalten und wieder fortzusetzen, um den kurzen Ausfall zu vermeiden, der durch einen Neustart des Microsoft Exchange-Replikationsdiensts entsteht.

  • Jedes DAG-Mitglied muss über die gleiche Anzahl von Netzwerken verfügen. Wenn Sie z. B. planen, einen einzelnen Netzwerkadapter in einem Mitglied einer DAG zu verwenden, dann müssen alle anderen Mitglieder dieser DAG ebenfalls einen einzelnen Netzwerkadapter verwenden.

  • Jede DAG darf nicht mehr als ein MAPI-Netzwerk besitzen. Das MAPI-Netzwerk muss Verbindungen mit anderen Exchange-Servern sowie mit anderen Diensten wie Active Directory und DNS bereitstellen.

  • Zusätzliche Replikationsnetzwerke können je nach Bedarf hinzugefügt werden. Durch die Verwendung von NIC-Teaming (Bündelung von Netzwerkkarten) oder ähnlichen Technologien können Sie außerdem verhindern, dass ein einzelner Netzwerkadapter die einzige Fehlerquelle darstellen kann. Selbst durch die Bündelung wird jedoch nicht verhindert, dass das Netzwerk selbst die einzige Fehlerquelle sein kann.

  • Jedes Netzwerk der einzelnen DAG-Mitgliedsserver muss sich in einem eigenen Subnetz des Netzwerks befinden. Jeder Server in der DAG kann sich in einem anderen Subnetz befinden, aber die MAPI- und Replikationsnetzwerke müssen routingfähig sein und Verbindungen bereitstellen, damit Folgendes zutrifft:

    • Jedes Netzwerk der einzelnen DAG-Mitgliedsserver befindet sich in einem eigenen Subnetz, das von den Subnetzen getrennt ist, die von den anderen Netzwerken auf dem Server verwendet werden.

    • Jedes MAPI-Netzwerk des DAG-Mitgliedsservers kann mit dem MAPI-Netzwerk aller anderen DAG-Mitglieder kommunizieren.

    • Jedes Replikationsnetzwerk des DAG-Mitgliedsservers kann mit dem Replikationsnetzwerk aller anderen DAG-Mitglieder kommunizieren.

    • Es erfolgt kein direktes Routing, das den Taktdatenverkehr vom Replikationsnetzwerk auf einem DAG-Mitgliedsserver zum MAPI-Netzwerk auf einem anderen DAG-Mitgliedsserver (oder umgekehrt) sowie zwischen mehreren Replikationsnetzwerken in der DAG gestattet.

  • Unabhängig vom ihrem relativ zu anderen DAG-Mitgliedern gesehenen geografischen Standort darf kein Mitglied der DAG eine Roundtrip-Netzwerklatenz aufweisen, die zwischen den einzelnen Mitgliedern mehr als 500 Millisekunden (ms) beträgt. Wenn die Roundtriplatenz zwischen zwei Postfachservern, die Kopien einer Datenbank hosten, größer wird, steigt auch die Gefahr, dass die jeweilige Replikation nicht aktuell ist. Ungeachtet der Latenz der Lösung sollten Kunden sich vergewissern, dass das Netzwerk zwischen allen DAG-Mitgliedern in der Lage ist, die Datenschutz- und Verfügbarkeitsziele der Bereitstellung zu erfüllen. Für Konfigurationen mit größeren Latenzwerten kann eine spezielle Optimierung von DAG-, Replikations- und Netzwerkparametern erforderlich sein (z. B. Erhöhen der Anzahl von Datenbanken oder Verringern der Anzahl von Postfächern pro Datenbank), um die gewünschten Ziele zu erreichen.

  • Roundtrip-Latenzanforderungen sind vielleicht nicht die strikteste Anforderung an Netzwerkbandbreiten und Latenz für eine Konfiguration mit mehreren Datencentern. Sie müssen die gesamte Netzwerklast berechnen, zu welcher Clientzugriff, Active Directory, Transport, fortlaufende Replikation und anderer Anwendungsdatenverkehr gehört, um die erforderlichen Netzwerkvoraussetzungen für die Umgebung zu bestimmen.

  • DAG-Netzwerke unterstützen IPv4 (Internetprotokoll, Version 4) und IPv6. IPv6 wird nur unterstützt, wenn IPv4 ebenfalls verwendet wird. Reine IPv6-Umgebungen werden nicht unterstützt. Die Verwendung von IPv6-Adressen und IP-Adressbereichen wird nur unterstützt, wenn auf diesem Computer sowohl IPv6 als auch IPv4 aktiviert sind und wenn das Netzwerk beide IP-Adressversionen unterstützt. Wenn Exchange 2010 in dieser Konfiguration implementiert ist, können alle Serverrollen Daten an Geräte, Server und Clients senden bzw. von diesen empfangen, die IPv6-Adressen verwenden.

  • Die automatische Privat-IP-Adressierung (Automatic Private IP Addressing, APIPA) ist eine Funktion von Microsoft Windows, mit dem IP-Adressen automatisch zugeordnet werden, wenn kein DHCP-Server (Dynamic Host Configuration Protocol) im Netzwerk verfügbar ist. APIPA-Adressen (einschließlich manuell zugeordneter Adressen aus dem APIPA-Adressbereich) werden nicht für die Verwendung durch DAGs oder Exchange 2010 unterstützt.

Anforderungen an den DAG-Namen und die IP-Adresse

Während der Erstellung erhält jede DAG einen eindeutigen Namen und ihr wird mindestens eine statische IP-Adresse zugeordnet, sofern sie nicht für die Verwendung von DHCP konfiguriert wird. Unabhängig davon, ob Sie die Adressen statisch oder dynamisch zuordnen, müssen sich die einer DAG zugeordneten IP-Adressen im MAPI-Netzwerk befinden.

Jede DAG erfordert mindestens eine IP-Adresse im MAPI-Netzwerk. Eine DAG erfordert weitere IP-Adressen, wenn sich das MAPI-Netzwerk über mehrere Subnetze erstreckt. In der folgenden Abbildung ist eine DAG dargestellt, bei der sich das MAPI-Netzwerk aller Knoten in der DAG im gleichen Subnetz befinden.

DAG mit MAPI-Netzwerk im gleichen Subnetz

In diesem Beispiel befindet sich das MAPI-Netzwerk der einzelnen DAG-Mitglieder im Subnetz 172.19.18.x. Daher erfordert die DAG in diesem Subnetz eine einzelne IP-Adresse.

In der nächsten Abbildung wird eine DAG mit einem MAPI-Netzwerk dargestellt, das sich über zwei Subnetze erstreckt: 172.19.18.x und 172.19.19.x.

Database Availability Group mit MAPI-Netzwerk in mehreren Subnetzen

In diesem Beispiel befindet sich das MAPI-Netzwerk der einzelnen DAG-Mitglieder in einem separaten Subnetz. Daher erfordert die DAG zwei IP-Adressen, eine für jedes Subnetz im MAPI-Netzwerk.

Sobald das MAPI-Netzwerk der DAG ein weiteres Subnetz umfasst, muss für dieses Subnetz eine weitere IP-Adresse für die DAG konfiguriert werden. Jeder für diese DAG konfigurierten IP-Adresse wird der der DAG zugrunde liegende Failovercluster zugeordnet, von dem diese Adresse auch verwendet wird. Der Name der DAG wird auch als Name für den zugrunde liegenden Failovercluster verwendet.

Der Cluster für die DAG verwendet jeweils nur eine der zugeordneten IP-Adressen. Diese IP-Adresse wird vom Windows-Failoverclustering im DNS registriert, wenn die IP-Adresse und die Netzwerknamensressourcen des Clusters online gestellt werden. Zusätzlich zur Verwendung einer IP-Adresse und eines Netzwerknamens wird ein Clusternamenobjekt (CNO) in Active Directory erstellt. Der Name, die IP-Adresse und der CNO für den Cluster werden intern vom System verwendet, um die DAG zu schützen und die interne Kommunikation zu unterstützen. Administratoren und Endbenutzer müssen keine Verbindung zu dem Namen oder der IP-Adresse der DAG herstellen.

Hinweis

Obwohl die IP-Adresse und der Netzwerkname des Clusters intern vom System verwendet werden, ist die Verfügbarkeit dieser Ressourcen in Exchange 2010 nicht zwingend erforderlich. Selbst wenn die IP-Adresse und die Netzwerknamensressourcen des zugrunde liegenden Clusters offline sind, erfolgt die interne Kommunikation weiterhin innerhalb der DAG, indem die Servernamen des DAG-Mitglieds verwendet werden. Es wird jedoch empfohlen, dass Sie die Verfügbarkeit dieser Ressourcen regelmäßig überwachen, um sicherzustellen, dass sie nicht länger als 30 Tage offline sind. Wenn der zugrunde liegende Cluster für mehr als 30 Tage offline ist, wird das Konto des Clusternetzwerkobjekts möglicherweise vom Garbage Collection-Mechanismus in Active Directory außer Kraft gesetzt.

Netzwerkadapterkonfiguration für DAGs

Jeder Netzwerkadapter muss entsprechend dem gewünschten Verwendungszweck konfiguriert werden. Die Konfiguration eines Netzwerkadapters, der für ein MAPI-Netzwerk verwendet wird, unterscheidet sich von der Konfiguration eines Netzwerkadapters, der für ein Replikationsnetzwerk verwendet wird. Zusätzlich zum ordnungsgemäßen Konfigurieren der einzelnen Netzwerkadapter müssen Sie auch die Netzwerkverbindungsreihenfolge in Windows konfigurieren, damit sich das MAPI-Netzwerk am Anfang der Verbindungsreihenfolge befindet. Genaue Anweisungen zum Ändern der Netzwerkverbindungsreihenfolge finden Sie unter Ändern der Bindungsreihenfolge für Protokolle.

Konfiguration des MAPI-Netzwerkadapters

Ein Netzwerkadapter, der für die Verwendung in einem MAPI-Netzwerk vorgesehen ist, sollte gemäß der Beschreibung in der folgenden Tabelle konfiguriert werden.

Netzwerkfunktionen Einstellung

Client für Microsoft-Netzwerke

Aktiviert

QoS-Paketplaner

Optional aktivieren

Datei- und Druckerfreigabe für Microsoft-Netzwerke

Enable

Internetprotokoll, Version 6 (TCP/IP v6)

Optional aktivieren

Internetprotokoll, Version 4 (TCP/IP v4)

Aktiviert

E/A-Treiber für Verbindungsschicht-Topologieerkennungszuordnung

Aktiviert

Antwort für Verbindungsschicht-Topologieerkennung

Aktiviert

Die TCP/IP v4-Eigenschaften für einen MAPI-Netzwerkadapter werden wie folgt konfiguriert:

  • Die IP-Adresse für das MAPI-Netzwerk eines DAG-Mitglieds kann manuell zugeordnet oder zur Verwendung von DHCP konfiguriert werden. Bei der Verwendung von DHCP wird empfohlen, dauerhafte Reservierungen für die IP-Adresse von Servern zu verwenden.

  • Das MAPI-Netzwerk verwendet normalerweise ein Standardgateway, obwohl es nicht erforderlich ist.

  • Es muss mindestens eine DNS-Serveradresse konfiguriert werden. Aus Gründen der Redundanz wird empfohlen, mehrere DNS-Server zu verwenden.

  • Das Kontrollkästchen Adressen dieser Verbindung in DNS registrieren sollte aktiviert sein.

Konfiguration des Replikationsnetzwerkadapters

Ein Netzwerkadapter, der für die Verwendung in einem Replikationsnetzwerk vorgesehen ist, sollte gemäß der Beschreibung in der folgenden Tabelle konfiguriert werden.

Netzwerkfunktionen Einstellung

Client für Microsoft-Netzwerke

Deaktiviert

QoS-Paketplaner

Optional aktivieren

Datei- und Druckerfreigabe für Microsoft-Netzwerke

Deaktiviert

Internetprotokoll, Version 6 (TCP/IP v6)

Optional aktivieren

Internetprotokoll, Version 4 (TCP/IP v4)

Aktiviert

E/A-Treiber für Verbindungsschicht-Topologieerkennungszuordnung

Aktiviert

Antwort für Verbindungsschicht-Topologieerkennung

Aktiviert

Die TCP/IP v4-Eigenschaften für einen Replikationsnetzwerkadapter werden wie folgt konfiguriert:

  • Die IP-Adresse für das Replikationsnetzwerk eines DAG-Mitglieds kann manuell zugeordnet oder zur Verwendung von DHCP konfiguriert werden. Bei der Verwendung von DHCP wird empfohlen, dauerhafte Reservierungen für die IP-Adresse von Servern zu verwenden.

  • Replikationsnetzwerke verfügen normalerweise nicht über Standardgateways. Wenn das MAPI-Netzwerk über ein Standardgateway verfügt, sollten keine anderen Netzwerke Standardgateways besitzen. Das Routing des Netzwerkverkehrs in einem Replikationsnetzwerk kann mithilfe beständiger, statischer Routen zu entsprechenden Netzwerken auf anderen DAG-Mitgliedern konfiguriert werden, die Gatewayadressen verwenden, mit denen das Routing zwischen den Replikationsnetzwerken ausgeführt werden kann. Sämtlicher anderer Datenverkehr, der nicht dieser Route entspricht, wird vom Standardgateway verarbeitet, der am Adapter für das MAPI-Netzwerk konfiguriert wurde.

  • DNS-Serveradressen sollten nicht konfiguriert werden.

  • Das Kontrollkästchen Adressen dieser Verbindung in DNS registrieren sollte nicht aktiviert sein.

Allgemeine Anforderungen

Zeugenserveranforderungen

Ein Zeugenserver ist ein Server außerhalb einer DAG, der zum Erreichen und Erhalten des Quorums verwendet wird, wenn die DAG über eine gerade Anzahl von Mitgliedern verfügt. DAGs mit ungerader Anzahl von Mitgliedern verwenden keinen Zeugenserver. Alle DAGs mit gerader Anzahl von Mitgliedern verwenden einen Zeugenserver. Der Zeugenserver kann ein beliebiger Computer sein, auf dem Windows Server ausgeführt wird. Es ist nicht erforderlich, dass die Version des Windows Server-Betriebssystems des Zeugenservers mit dem Betriebssystem der DAG-Mitglieder übereinstimmt.

Das Quorum wird auf Clusterebene unterhalb der DAG aufrechterhalten. Für eine DAG besteht das Quorum, wenn die Mehrzahl ihrer Mitglieder online sind und mit den anderen Mitgliedern der DAG kommunizieren können, die ebenfalls online sind. Diese Auffassung eines Quorums stellt einen Aspekt des Quorumkonzepts beim Windows-Failoverclustering dar. Ein verwandter und erforderlicher Aspekt von Quoren in Failoverclustern ist die Quorumressource. Die Quorumressource ist eine Ressource innerhalb eines Failoverclusters, die einen Mechanismus für Entscheidungen bezüglich Mitgliedschaft und Clusterzustand bereitstellt. Die Quorumressource stellt außerdem einen permanenten Speicher zum Speichern von Konfigurationsinformationen bereit. Ein Begleiter der Quorumressource ist das Quorumprotokoll, bei dem es sich um eine Konfigurationsdatenbank für den Cluster handelt. Das Quorumprotokoll enthält z. B. Informationen dazu, welche Server Mitglieder des Clusters sind, welche Ressourcen im Cluster installiert sind sowie zum Zustand anderer Ressourcen (z. B. "online" oder "offline").

Es ist entscheidend, dass jedes DAG-Mitglied über eine konsistente Ansicht darauf verfügt, wie der der DAG zugrunde liegende Cluster konfiguriert ist. Das Quorum dient als definitives Repository für alle Konfigurationsinformationen über den Cluster. Mit dem Quorum werden Verbindungen getrennt, um ein "Split Brain-Syndrom" zu vermeiden. Das "Split Brain-Syndrom" stellt eine Bedingung dar, die auftritt, wenn DAG-Mitglieder aktiv sind, aber nicht miteinander kommunizieren können. Das "Split Brain-Syndrom" wird verhindert, indem immer eine Mehrheit der DAG-Mitglieder (bei einer geraden Anzahl der Mitglieder wird der DAG-Zeugenserver einbezogen) verfügbar und aktiv sein muss, damit die DAG funktionsfähig ist.

Planen der Ausfallsicherheit von Standorten

Täglich erkennen immer mehr Unternehmen, dass der Zugriff auf ein zuverlässiges und verfügbares Messagingsystem für ihren Erfolg entscheidend ist. Für zahlreiche Unternehmen ist das Messagingsystem im Rahmen der Geschäftskontinuitätspläne erforderlich und die Ausfallsicherheit des Standorts muss in der Bereitstellung von Messagingdiensten berücksichtigt werden. Im Wesentlichen beinhalten viele Lösungen zur Ausfallsicherheit von Standorten die Bereitstellung von Hardware in einem zweiten Datencenter.

Letztendlich hängt der Gesamtentwurf einer DAG, einschließlich der Anzahl der DAG-Mitglieder und der Anzahl der Postfachdatenbankkopien, von den Vereinbarungen zum Servicelevel (SLA) für Wiederherstellungen im Unternehmen ab, die verschiedene Fehlerszenarien abdecken. Während der Planungsphase sollten die Architekten und Administratoren der Lösung die Anforderungen für die Bereitstellung identifizieren, insbesondere die Anforderungen für die Ausfallsicherheit von Standorten. Sie identifizieren die zu verwendenden Standorte und die erforderlichen Ziele für die Vereinbarungen zum Servicelevel für Wiederherstellungen. Die Vereinbarung zum Servicelevel identifiziert zwei bestimmte Elemente als Basis für den Entwurf einer Lösung, die eine hohe Verfügbarkeit und die Ausfallsicherheit von Standorten bietet: die angestrebte Wiederherstellungsdauer (Recovery Time Objective, RTO) und der angestrebte Wiederherstellungszeitpunkt (Recovery Point Objective, RPO). Beide Werte werden in Minuten gemessen. RTO bezeichnet die Dauer, die für die Wiederherstellung des Diensts erforderlich ist. RPO bezieht sich darauf, wie aktuell die Daten sind, nachdem die Wiederherstellung abgeschlossen ist. Es kann auch eine Vereinbarung zum Servicelevel für die Wiederherstellung des uneingeschränkten Diensts des primären Datencenters nach der Behebung seiner Probleme definiert werden.

Die Architekten und Administratoren der Lösung identifizieren außerdem, welche Benutzer den Ausfallsicherheitsschutz für Standorte erfordern und bestimmen, ob die Lösung für mehrere Standorte eine Active/Passive- oder eine Active/Active-Konfiguration darstellen wird. Bei einer Active/Passive-Konfiguration werden normalerweise keine Benutzer im Ersatzdatencenter gehostet. Bei einer Active/Active-Konfiguration werden die Benutzer an beiden Standorten gehostet und ein Prozentsatz der Gesamtanzahl von Datenbanken in der Lösung verfügt über einen bevorzugten aktiven Standort in einem sekundären Datencenter. Wenn der Dienst für die Benutzer eines Datencenters ausfällt, werden diese Benutzer im anderen Datencenter aktiviert.

Die Erstellung der entsprechenden Vereinbarungen zum Servicelevel erfordert häufig die Beantwortung folgender grundlegender Fragen:

  • Welcher Servicelevel ist nach Ausfall des Hauptdatencenters erforderlich?

  • Benötigen Benutzer ihre Daten oder nur Messagingdienste?

  • Wie schnell werden die Daten benötigt?

  • Wie viele Benutzer müssen unterstützt werden?

  • Wie sollen die Benutzer auf ihre Daten zugreifen?

  • Wie lautet die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) zur Aktivierung des Ersatzdatencenters?

  • Wie wird das Hauptdatencenter wieder in Betrieb genommen?

  • Sind die Ressourcen für die Ausfallsicherheitslösung von Standorten reserviert?

Durch die Beantwortung dieser Fragen bildet sich ein erster Entwurf Ihrer Messaginglösung für die Ausfallsicherheit von Standorten heraus. Eine wesentliche Anforderung der Wiederherstellung nach einem Standortausfall besteht in der Erstellung einer Lösung, mit der die erforderlichen Daten an das Sicherungsdatencenter übergeben werden, das den Ersatzmessagingdienst hostet.

Namespaceplanung

Exchange 2010 ändert die Art und Weise in der Sie Ihren Namespaceentwurf beim Bereitstellen einer Konfiguration für die Ausfallsicherheit von Standorten planen. Die richtige Namespaceplanung ist erforderlich, damit Datencenterswitchover erfolgreich ausgeführt werden können. Aus Sicht des Namespaces wird jedes bei der Konfiguration für die Ausfallsicherheit von Standorten verwendete Datencenter als aktiv betrachtet. Daher erfordert jedes Datencenter einen eigenen eindeutigen Namespace für die verschiedenen Exchange 2010-Dienste an diesem Standort, einschließlich Namespaces für Outlook Web App, Outlook Anywhere, Exchange ActiveSync, Exchange-Webdienste, RPC-Clientzugriff, POP3 (Post Office Protocol, Version 3), IMAP4 (Internet Message Access Protocol, Version 4) und SMTP (Simple Mail Transfer Protocol). Außerdem hostet eines der Datencenter auch den Namespace für AutoErmittlung. Mithilfe dieses Entwurfs können Sie auch einen einzelnen Datenbankswitchover vom Hauptdatencenter zu einem zweiten Datencenter ausführen, um die Konfiguration der zweiten Daten im Rahmen der Gültigkeitsprüfung und Übung für einen Datencenterswitchover zu validieren.

Als bewährte Methode wird empfohlen, dass Sie ein geteiltes DNS für die von den Clients verwendeten Exchange-Hostnamen einsetzen. Beim geteilten DNS handelt es sich um eine DNS-Serverkonfiguration, in der interne DNS-Server eine interne IP-Adresse für einen Hostnamen und externe (mit dem Internet verbundene) DNS-Server eine öffentliche IP-Adresse für den gleichen Hostnamen zurückgeben. Da bei geteiltem DNS intern und extern die gleichen Hostnamen verwendet werden, wird mit dieser Methode die Anzahl der benötigten Hostnamen minimiert.

Die folgende Abbildung veranschaulicht die Namespaceplanung für eine Konfiguration mit Standortausfallsicherheit.

Namespaces für die DAG-Bereitstellung mit der Ausfallsicherheit von Standorten

Wie zuvor veranschaulicht, verwendet jedes Datencenter einen separaten und eindeutigen Namespace und enthält für diese Namespaces DNS-Server in einer geteilten DNS-Konfiguration. Das Datencenter in Redmond, das als Hauptdatencenter betrachtet wird, ist mit dem Namespace protokoll.contoso.com konfiguriert. Das Datencenter in Portland ist mit dem Namespace protokoll.standby.contoso.com konfiguriert. Namespaces können Ersatzziele einbeziehen, wie in der Beispielabbildung, sie können auf Regionen (z. B. protokoll.portland.contoso.com) oder auf anderen Namenskonventionen basieren, die den Anforderungen Ihres Unternehmens entsprechen. Die Hauptanforderung besteht unabhängig von der verwendeten Namenskonvention darin, dass jedes Datencenter einen eigenen eindeutigen Namespace besitzen soll.

FailbackURL-Konfiguration

Einige Webbrowser, darunter Microsoft Internet Explorer, verwalten während jeder Browsersitzung einen DNS-Namenscache, der getrennt vom DNS-Cache des Betriebssystems vorliegt. Bei einem Failback zum primären Datencenter nach einem Datencenterswitchover kann die Nutzung dieses getrennten Caches durch den Webbrowser für Outlook Web App-Benutzer zu Anmeldeschleifen führen, in denen Benutzer in einer wiederholten Schleife zur selben URL umgeleitet werden.

Im Verlauf des Failbackvorgangs wird die IP-Adresse für den Outlook Web App-Namespace in DNS von einem Endpunkt im Standby-Datencenter in ihren ursprünglichen Endpunkt im primären Datencenter geändert. Webbrowser, die einen eigenen getrennten Namenscache verwalten, versuchen möglicherweise selbst nach Ablauf der Gültigkeit eines DNS-Eintrags und sogar nach dem Löschen der Inhalte des DNS-Caches des Betriebssystems Verbindungen mit dem Endpunkt im Standby-Datencenter herzustellen – selbst wenn der Namespace im primären Datencenter gehostet wird.

Normalerweise genügt es, den Webbrowser zu schließen, damit der Inhalt seines getrennten Namenscache gelöscht wird und Anmeldeschleifen verhindert werden. Zur Vermeidung dieses Problems für alle Webbrowser und Outlook Web App-Benutzer können Sie die Eigenschaft FailbackURL für Ihr virtuelles Outlook Web App-Verzeichnis konfigurieren. Der Parameter FailbackUrl gibt den Hostnamen an, den Outlook Web App verwendet, um nach einem Failback zum primären Standort eine Verbindung mit dem Clientzugriffsserver herzustellen. Für diesen Namespace ist ein eigener DNS-Eintrag erforderlich, der auf die IP-Adresse des ursprünglichen Clientzugriffsservers verweist. Der Wert des Parameters FailbackUrl darf nicht mit dem Wert des Parameters ExternalUrl für das virtuelle Verzeichnis für Outlook Web App identisch sein. Wenn ein Outlook Web App-Benutzer seine Anmeldeinformationen bereitstellt, erkennt der Clientzugriffsserver, ob die Umleitungs-URL mit der URL identisch ist, die der Benutzer besucht. Sind die URLs identisch, prüft der Clientzugriffsserver, ob der Parameter FailbackUrl konfiguriert ist:

  • Ist der Parameter FailbackUrl konfiguriert, leitet der Clientzugriffsserver den Benutzer zu dieser URL um, über die der Zugriff auf Outlook Web App möglich sein sollte.

  • Ist der Parameter FailbackUrl nicht konfiguriert, erhält der Benutzer eine Fehlermeldung mit dem Hinweis, dass durch eine Serverkonfigurationsänderung der Zugriff auf sein Poostfach verhindert wird. In dieser Meldung wird der Benutzer gebeten, alle Browserfenster zu schließen (wodurch der Inhalt des Namenscache des Browsers gelöscht wird) und den Vorgang in einigen Minuten zu wiederholen.

Zertifikatsplanung

Bei der Bereitstellung einer DAG in einem einzelnen Datencenter müssen hinsichtlich des Entwurfs von Zertifikaten keine eindeutigen oder speziellen Aspekte berücksichtigt werden. Wenn sich eine DAG jedoch in einer Konfiguration für die Standortausfallsicherheit über mehrere Datencenter erstreckt, gibt es hinsichtlich der Zertifikate einige bestimmte Überlegungen. Im Allgemeinen hängt der Zertifikatsentwurf von den verwendeten Clients sowie von den Zertifikatanforderungen anderer Anwendungen ab. Es gibt jedoch einige bestimmte Empfehlungen und bewährte Methoden, die Sie hinsichtlich des Typs und der Anzahl von Zertifikaten befolgen sollten.

Als bewährte Methode sollten Sie die Anzahl der für die Clientzugriffsserver, Reverseproxyserver und Transportserver (Edge und Hub) verwendeten Zertifikate minimieren. Es wird empfohlen, für all diese Dienstendpunkte in den einzelnen Datencentern ein einzelnes Zertifikat zu verwenden. Bei diesem Ansatz wird die Anzahl der erforderlichen Zertifikate minimiert, wodurch Kosten und Komplexität der Lösung verringert werden.

Für Outlook Anywhere-Clients wird empfohlen, dass Sie für jedes Datencenter ein einzelnes SAN-Zertifikat (Subject Alternative Name) verwenden und mehrere Hostnamen im Zertifikat einbeziehen. Damit die Outlook Anywhere-Konnektivität nach einem Datenbank-, Server- oder Datencenterswitchover sichergestellt ist, müssen Sie auf jedem Zertifikat denselben Zertifikatprinzipalnamen verwenden und das Outlook-Anbieterkonfigurationsobjekt Active Directory mit demselben Prinzipalnamen im Microsoft-Standardformular (msstd) konfigurieren. Wenn Sie z. B. den Zertifikatprinzipalnamen "mail.contoso.com" verwenden, würden Sie die Attribute wie folgt konfigurieren:

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Einige Anwendungen, die mit Exchange integriert werden, weisen bestimmte Zertifikatanforderungen auf, die möglicherweise die Verwendung zusätzlicher Zertifikate erfordern. Exchange 2010 kann gleichzeitig mit Office Communications Server (OCS) installiert sein. OCS erfordert Zertifikate mit 1024-Bit oder stärkerer Verschlüsselung, die den OCS-Servernamen als Zertifikatprinzipalnamen verwenden. Da bei Verwendung eines OCS-Servernamens als Zertifikatprinzipalnamen Outlook Anywhere nicht ordnungsgemäß ausgeführt werden kann, müssten Sie ein zusätzliches und separates Zertifikat für die OCS-Umgebung verwenden.

Weitere Informationen zur Verwendung von SAN-Zertifikaten für den Exchange 2010-Clientzugriff finden Sie unter Konfigurieren von SSL-Zertifikaten zur Verwendung mehrerer Hostnamen für Clientzugriffsserver.

Netzwerkplanung

Zusätzlich zu den bestimmten Netzwerkanforderungen, die für die einzelnen DAGs sowie für die einzelnen Server eingehalten werden müssen, die Mitglied einer DAG sind, gibt es einige Anforderungen und Empfehlungen, die nur für Konfigurationen mit Ausfallsicherheit von Standorten gelten. Wie bei allen DAGs, unabhängig davon, ob die DAG-Mitglieder an einem oder mehreren Standorten bereitgestellt werden, darf die Roundtrip-Netzwerklatenz zwischen DAG-Mitgliedern und DAG nicht mehr als 500 Millisekunden (ms) betragen. Außerdem gibt es bestimmte Konfigurationseinstellungen, die für DAGs empfohlen werden, die sich über mehrere Standorte erstrecken:

  • MAPI-Netzwerke sollten von Replikationsnetzwerken getrennt werdenWindows-Netzwerkrichtlinien, Windows-Firewallrichtlinien oder Routerzugriffssteuerungslisten sollten verwendet werden, um den Datenverkehr zwischen MAPI-Netzwerk und dem/den Replikationsnetzwerk(en) zu blockieren. Diese Konfiguration ist notwendig, um die Überkoppelung des Netzwerktakts zu verhindern.

  • Den Clients zugewandte DNS-Datensätze sollten eine Gültigkeitsdauer (Time to Live, TTL) von 5 Minuten aufweisen Der Umfang der Downtime, die bei Clients auftritt, hängt nicht nur davon ab, wie schnell ein Switchover erfolgen kann, sondern auch davon, wie schnell die DNS-Replikation ausgeführt wird und wie schnell die Clients Abfragen nach aktualisierten DNS-Informationen stellen. Für die DNS-Datensätze aller Exchange-Clientdienste, einschließlich Outlook Web App, Exchange ActiveSync, Exchange-Webdienste, Outlook Anywhere, SMTP, POP3, IMAP4 und RPC-Clientzugriff auf internen und externen DNS-Servern, sollte eine Gültigkeitsdauer von 5 Minuten eingestellt werden.

  • Verwenden Sie statische Routen, um die Konnektivität zwischen Replikationsnetzwerken zu konfigurieren Verwenden Sie beständige statische Routen, um die Netzwerkkonnektivität zwischen den einzelnen Replikationsnetzwerkadaptern bereitzustellen. Dies ist eine schnelle und einmalige Konfiguration, die auf jedem DAG-Mitglied ausgeführt wird, wenn statische IP-Adressen verwendet werden. Wenn Sie zum Abrufen der IP-Adressen für die Replikationsnetzwerke DHCP verwenden, können Sie damit auch statische Routen für die Replikation zuordnen und so den Konfigurationsprozess vereinfachen.

Allgemeine Planung der Ausfallsicherheit für Standorte

Zusätzlich zu den zuvor aufgeführten Anforderungen für die hohe Verfügbarkeit gibt es weitere Empfehlungen für die Bereitstellung von Exchange 2010 in einer Konfiguration mit Ausfallsicherheit für Standorte (z. B. die Ausweitung einer DAG auf mehrere Datencenter). Was Sie während der Planungsphase ausführen, wirkt sich direkt auf den Erfolg der Lösung zur Standortausfallsicherheit aus. Ein schlechter Namespaceentwurf kann z. B. zu Problemen bei Zertifikaten führen und eine falsche Zertifikatskonfiguration kann Benutzer am Zugriff auf Dienste hindern.

Damit die Zeit minimiert wird, die erforderlich ist, um ein zweites Datencenter zu aktivieren es dem zweiten Datencenter zu ermöglichen, die Dienstendpunkte eines fehlerhaften Datencenters zu hosten, muss die entsprechende Planung abgeschlossen werden. Beispiel:

  • Die Ziele der Vereinbarung für den Servicelevel für die Lösung zur Standortausfallsicherheit müssen eindeutig sein und umfassend dokumentiert werden.

  • Die Server im zweiten Datencenter müssen über eine ausreichende Kapazität verfügen, um den kombinierten Benutzerbestand beider Datencenter zu hosten.

  • Für das zweite Datencenter müssen alle Dienste aktiviert sein, die im Hauptdatencenter bereitgestellt werden (sofern der Dienst nicht im Rahmen der Vereinbarung für den Servicelevel zur Standortausfallsicherheit enthalten ist). Dies umfasst Active Directory, die Netzwerkinfrastruktur (DNS, TCP/IP usw.), Telefoniedienste (wenn Unified Messaging verwendet wird) und die Standortinfrastruktur (Energie, Kühlung usw.).

  • Damit einige Dienste die Benutzer des fehlerhaften Datencenters versorgen können, müssen für sie die richtigen Serverzertifikate konfiguriert werden. Einige Dienste gestatten keine Instanziierung (z. B. POP3 und IMAP4) und erlauben nur die Verwendung eines einzelnen Zertifikats. In diesen Fällen muss das Zertifikat entweder ein SAN-Zertifikat (Subject Alternative Name) sein, das mehrere Namen umfasst, oder die Namen müssen ähnlich genug sein, damit ein Platzhalterzertifikat verwendet werden kann (vorausgesetzt, die Sicherheitsrichtlinien des Unternehmens gestattet die Verwendung von Platzhalterzertifikaten).

  • Die erforderlichen Dienste müssen im zweiten Datencenter definiert werden. Wenn das erste Datencenter z. B. über drei verschiedene SMTP-URLs auf unterschiedlichen Transportservern verfügt, muss die entsprechende Konfiguration im zweiten Datencenter konfiguriert werden, um zumindest einen (wenn nicht alle drei) Transportserver als Host für die Arbeitsauslastung zu aktivieren.

  • Zur Unterstützung des Datencenterswitchovers muss die erforderliche Netzwerkkonfiguration vorhanden sein. Es muss u. U. sichergestellt werden, dass die Konfigurationen für den Lastenausgleich vorhanden sind, das globale DNS konfiguriert und die Internetverbindung mit entsprechend konfiguriertem Routing aktiviert ist.

  • Die Strategie zur Aktivierung der DNS-Änderungen, die für einen Datencenterswitchover erforderlich sind, muss verstanden werden. Die bestimmten DNS-Änderungen, einschließlich der Einstellungen für die Gültigkeitsdauer (Time to Live, TTL), müssen definiert und dokumentiert werden, um die betroffene(n) Vereinbarung(en) für den Servicelevel zu unterstützen.

  • Eine Strategie zum Testen der Lösung muss ebenso eingerichtet und in der Vereinbarung für den Servicelevel berücksichtigt werden. Die regelmäßige Überprüfung der Bereitstellung stellt die einzige Möglichkeit dar, um sicherzustellen, dass sich die Qualität und Durchführbarkeit der Bereitstellung im Lauf der Zeit nicht verschlechtern. Nach der Überprüfung der Bereitstellung wird empfohlen, dass der Teil der Konfiguration explizit dokumentiert wird, der sich direkt auf den Erfolg der Lösung auswirkt. Außerdem wird empfohlen, dass Sie Ihre Änderungsverwaltungsprozesse um diese Segmente der Bereitstellung herum erweitern.

Allgemeine Anforderungen

Planen eines Datencenterswitchovers

Die richtige Planung und Vorbereitung umfasst nicht nur die Bereitstellung der Ressourcen des zweiten Datencenters, z. B. Live-Clientzugriff und Hub-Transport-Server, sondern auch die Vorkonfiguration dieser Ressourcen, um die Änderungen zu minimieren, die im Rahmen eines Datencenterswitchovers erforderlich sind.

Hinweis

Clientzugriff- und Hub-Transport-Dienste sind im zweiten Datencenter erforderlich, auch wenn die automatische Aktivierung der Postfachdatenbanken im zweiten Datencenter blockiert ist. Diese Dienste sind erforderlich, um Datenbankswitchover sowie Tests und Überprüfungen der Dienste und Daten im zweiten Datencenter auszuführen.

Um den Prozess eines Datencenterswitchovers besser zu verstehen, ist es hilfreich, den grundlegenden Betrieb eines Exchange 2010-Datencenterswitchovers zu kennen.

Wie in der folgenden Abbildung veranschaulicht, besteht die Bereitstellung mit Ausfallsicherheit für einen Standort aus einer DAG, die über Mitglieder in beiden Datencentern verfügt.

Database Availability Group mit Mitgliedern in zwei Datencentern

Wenn eine DAG sich über mehrere Datencenter erstreckt, sollte sie so entworfen werden, dass sich entweder die Mehrheit der DAG-Mitglieder im Hauptdatencenter befindet oder, wenn jedes Datencenter dieselbe Anzahl von Mitgliedern enthält, das Hauptdatencenter den Zeugenserver hostet. Dieser Entwurf garantiert, dass der Dienst im Hauptdatencenter bereitgestellt wird, auch wenn die Netzwerkkonnektivität zwischen den beiden Datencentern fehlschlägt. Es bedeutet außerdem, dass bei einem Fehler des Hauptdatencenters das Quorum für die Mitglieder im zweiten Datencenter verloren geht.

Partielle Datencenterfehler sind ebenfalls möglich und wahrscheinlich. Wenn im Hauptdatencenter so viel Funktionalität verloren gegangen ist, dass ein effektiver Service und eine effektive Verwaltung unmöglich ist, sollte zum Aktivieren des zweiten Datencenters ein Datencenterswitchover ausgeführt werden. Der Aktivierungsprozess umfasst die Konfiguration der verbleibenden, teilweise funktionsfähigen Server durch den Administrator, um den Dienst zu beenden. Die Aktivierung kann dann im zweiten Datencenter fortgesetzt werden. So soll ausgeschlossen werden, dass beide Dienstsätze zur gleichen Zeit getestet und ausgeführt werden.

Durch den Verlust des Quorums können die DAG-Mitglieder im zweiten Datencenter nicht automatisch online gehen. Zur Aktivierung der Postfachserver im zweiten Datencenter ist ebenfalls ein Schritt erforderlich, in dem die DAG-Mitgliedsserver gezwungen sind, ein Quorum zu erstellen. An diesem Punkt werden die Server im fehlerhaften Datencenter intern (aber nur temporär) aus der DAG entfernt. Dadurch wird eine Lösung mit einem partiellen Dienst bereitgestellt, der stabil ist und trotz einer begrenzten Anzahl zusätzlicher Fehler weiter ausgeführt werden kann.

Hinweis

Eine Voraussetzung für die Funktionstüchtigkeit trotz Fehler ist, dass die DAG über mindestens vier Mitglieder verfügt, die über zwei Active Directory-Standorte verteilt sind (z. B. mindestens zwei Mitglieder in jedem Datencenter).

Dies ist der Standardprozess, der zum erneuten Einrichten der Funktionalität der Postfachrolle im zweiten Datencenter verwendet wird. Die Aktivierung der anderen Rollen im zweiten Datencenter umfasst keine expliziten Aktionen auf den betroffenen Servern im zweiten Datencenter. Stattdessen werden die Server im zweiten Datencenter zu Dienstendpunkten für diese Dienste, die normalerweise vom Hauptdatencenter gehostet werden. Ein Benutzer, der z. B. normalerweise im Hauptdatencenter gehostet wird, kann die Verbindung zu Outlook Web App über "https://mail.contoso.com/owa" herstellen. Nach dem Datencenterfehler werden diese Dienstendpunkte im Rahmen des Switchovervorgangs zu Endpunkten im zweiten Datencenter verschoben. Während des Switchovervorgangs werden die Dienstendpunkte für das Hauptdatencenter erneut auf alternative IP-Adressen für dieselben Dienste im zweiten Datencenter ausgerichtet. Dadurch wird der Umfang der Änderungen minimiert, die an den Konfigurationsinformationen vorgenommen werden müssen, die in Active Directory während des Switchoverprozesses gespeichert werden. Im Allgemeinen gibt es zwei Möglichkeiten, um diesen Schritt auszuführen:

  • Aktualisieren Sie die DNS-Datensätze, oder

  • Konfigurieren Sie das DNS und den Lastenausgleich so, dass alternative IP-Adressen aktiviert und deaktiviert und somit die Dienste zwischen Datencentern verschoben werden können.

Es muss eine Strategie zum Testen der Lösung eingerichtet werden. Sie muss in der Vereinbarung zum Servicelevel berücksichtigt werden. Die regelmäßige Überprüfung der Bereitstellung ist die einzige Möglichkeit, um sicherzustellen, dass sich die Bereitstellung im Lauf der Zeit nicht verschlechtert.

Der sorgfältige Abschluss dieser Planungsschritte wirkt sich direkt auf den Erfolg eines Datencenterswitchovers aus. Ein schlechter Namespaceentwurf kann z. B. zu Problemen bei Zertifikaten führen und eine falsche Zertifikatskonfiguration kann Benutzer am Zugriff auf Dienste hindern.

Nach der Überprüfung der Bereitstellung wird empfohlen, dass alle Teile der Konfiguration explizit dokumentiert werden, die sich direkt auf den Erfolg des Datencenterswitchovers auswirken. Außerdem ist es möglicherweise ratsam, die Änderungsverwaltungsprozesse um diese Bereiche der Bereitstellung herum zu erweitern.

Weitere Informationen zum Datencenterswitchover, einschließlich dem Aktivieren eines sekundären Datencenters und dem erneuten Aktivieren eines fehlerhaften (primären) Datencenters, finden Sie unter Datencenterswitchover.

Allgemeine Anforderungen

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.