Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten

Gilt für: Exchange Server 2013

Während der Planungsphase sollten die Systemarchitekten, Administratoren und andere Entscheidungsträger die geschäftlichen Anforderungen und die Anforderungen im Hinblick auf die Architektur für die Bereitstellung identifizieren, insbesondere die Anforderungen für hohe Verfügbarkeit und Ausfallsicherheit von Standorten.

Es gibt allgemeine Anforderungen, die für die Bereitstellung dieser Features erfüllt werden müssen, sowie Hardware-, Software- und Netzwerkanforderungen, die ebenfalls erfüllt werden müssen.

Allgemeine Anforderungen

Stellen Sie sicher, dass die folgenden systemweiten Anforderungen erfüllt sind, bevor Sie eine Database Availability Group (DAG) bereitstellen und Postfachdatenbank-Kopien 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 2013-Postfachservers, der auch ein Verzeichnisserver ist, zu einer DAG 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 alle Anforderungen erfüllen, die in den Themen für Exchange 2013-Voraussetzungen und Exchange 2013-Systemanforderungen beschrieben sind.

Speicheranforderungen

Grundsätzlich gibt es keine besonderen Speicheranforderungen für DAGs oder Postfachdatenbankkopien. Für DAGs ist kein clusterverwalteter gemeinsamer Speicher erforderlich, er wird von DAGs auch nicht verwendet. Der vom Cluster verwaltete freigegebene Speicher wird nur für die Verwendung in einer DAG unterstützt, wenn die DAG für die Verwendung einer Lösung konfiguriert ist, die die in Exchange 2013 integrierte Replikations-API von Drittanbietern verwendet.

Softwareanforderungen

DAGs sind sowohl in Exchange 2013 Standard als auch in Exchange 2013 Enterprise verfügbar. Darüber hinaus kann eine DAG eine Mischung aus Servern enthalten, auf denen Exchange 2013 Standard und Exchange 2013 Enterprise ausgeführt werden.

Jedes Mitglied der DAG muss auch dasselbe Betriebssystem ausführen. Exchange 2013 wird unter den Betriebssystemen Windows Server 2008 R2, Windows Server 2012 und Windows Server 2012 R2 unterstützt. Alle Mitglieder einer bestimmten DAG müssen dasselbe Betriebssystem ausführen. Windows Server 2012 R2 wird nur für DAG-Mitglieder unterstützt, die Exchange 2013 Service Pack 1 oder höher ausführen.

Zusätzlich zur Erfüllung der Voraussetzungen für die Installation von Exchange 2013 müssen Betriebssystemanforderungen erfüllt werden. DAGs verwenden die Windows-Failoverclustering-Technologie und erfordern daher die Enterprise- oder Datacenter-Version von Windows Server 2008 R2 oder die Standard- oder Datacenter-Version des Windows Server 2012- oder Windows Server 2012 R2-Betriebssystems.

Netzwerkanforderungen

Es gibt bestimmte Netzwerkanforderungen, die für jede DAG und für jedes DAG-Mitglied erfüllt werden müssen. Jede DAG muss über ein einzelnes MAPI-Netzwerk verfügen, das von einem DAG-Mitglied für die Kommunikation mit anderen Servern (z. B. anderen Exchange 2013-Servern oder Verzeichnisservern) verwendet wird, und über keine oder mehr Replikationsnetzwerke, bei denen es sich um Netzwerke handelt, die für den Protokollversand und das Seeding vorgesehen sind.

In früheren Versionen von Exchange wurden mindestens zwei Netzwerke (ein MAPI-Netzwerk und ein Replikationsnetzwerk) für DAGs empfohlen. In Exchange 2013 werden mehrere Netzwerke unterstützt, aber unsere Empfehlung hängt von Ihrer physischen Netzwerktopologie ab. Wenn Sie über mehrere physische Netzwerke zwischen DAG-Mitgliedern verfügen, die physisch voneinander getrennt sind, bietet die Verwendung eines separaten MAPI- und Replikationsnetzwerks mehr Redundanz. Wenn Sie mehrere Netzwerke haben, die teilweise physisch getrennt sind, aber letztlich in einem einzigen physischen Netzwerk zusammenlaufen (z. B. eine einzige WAN-Verbindung), wird die Verwendung eines einzelnen Netzwerks (vorzugsweise 10 Gigabit Ethernet) für den MAPI- und Replikationsdatenverkehr empfohlen. Dieser Ansatz bietet Einfachheit für das Netzwerk und den Netzwerkpfad.

Berücksichtigen Sie beim Entwerfen der Netzwerkinfrastruktur für Ihre DAG die folgenden Faktoren:

• Jedes Mitglied der DAG muss mindestens einen Netzwerkadapter besitzen, der mit allen anderen Mitgliedern der DAG kommunizieren kann. Bei einem einzelnen Netzwerkpfad wird empfohlen, ein Ethernet mit mindestens 1 Gigabit, vorzugsweise jedoch 10 Gigabit, zu verwenden. 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 mit Redundanz für das Replikationsnetzwerk sowie die folgenden Verhaltensweisen bei der Wiederherstellung:

  • Wenn sich ein Fehler auf das MAPI-Netzwerk auswirkt, erfolgt ein Serverfailover (vorausgesetzt, dass fehlerfreie Postfachdatenbankkopien vorhanden sind, die aktiviert werden können).

  • Wenn sich ein Fehler auf das Replikationsnetzwerk auswirkt und das MAPI-Netzwerk vom Fehler nicht betroffen ist, werden protokollversand- und seeding-Vorgänge zurückgesetzt, um das MAPI-Netzwerk zu verwenden, auch wenn die ReplicationEnabled-Eigenschaft für das MAPI-Netzwerk auf False festgelegt ist. Wenn das fehlerhafte Replikationsnetzwerk wiederhergestellt wird und bereit ist, protokollversand- und seeding-Vorgänge fortzusetzen, müssen Sie manuell zum Replikationsnetzwerk wechseln. Um die Replikation vom MAPI-Netzwerk in ein wiederhergestelltes Replikationsnetzwerk zu ändern, können Sie die fortlaufende Replikation entweder mit den Cmdlets Suspend-MailboxDatabaseCopy und Resume-MailboxDatabaseCopy anhalten und fortsetzen oder den Microsoft Exchange-Replikationsdienst neu starten. Es wird empfohlen, Unterbrechungs- und Fortsetzungsvorgänge zu verwenden, um den kurzen Ausfall zu vermeiden, der durch einen Neustart des Microsoft Exchange-Replikationsdiensts verursacht wird.

• 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, 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.

• Bei Bedarf können weitere Replikationsnetzwerke 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 wenn Teaming verwendet wird, verhindert diese Technologie jedoch nicht, dass das Netzwerk selbst ein Single Point of Failure ist. Darüber hinaus führt die Bündelung zu unnötiger Komplexität der DAG.

• 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 von ihrem geografischen Standort im Verhältnis zu anderen DAG-Mitgliedern muss jedes Mitglied der DAG eine Roundtrip-Netzwerklatenz von nicht mehr als 500 Millisekunden zwischen jedem anderen Mitglied aufweisen. Mit zunehmender Roundtriplatenz zwischen zwei Postfachservern, die Kopien einer Datenbank hosten, steigt auch das Potenzial, dass die Replikation nicht auf dem neuesten Stand ist. Unabhängig von der Latenz der Lösung sollten Kunden überprüfen, ob die Netzwerke zwischen allen DAG-Mitgliedern in der Lage sind, 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.

• Roundtriplatenzanforderungen sind möglicherweise nicht die strengste Anforderung an Netzwerkbandbreite und Latenz für eine Konfiguration mit mehreren Rechenzentren. Bewerten Sie die gesamte Netzwerklast, einschließlich Clientzugriff, Active Directory, Transport, fortlaufender Replikation und anderer Anwendungsdatenverkehr, um die erforderlichen Netzwerkanforderungen für Ihre Umgebung zu ermitteln.

• DAG-Netzwerke unterstützen IPv4 (Internet Protocol Version 4) und IPv6. IPv6 wird nur unterstützt, wenn auch IPv4 verwendet wird. Eine reine IPv6-Umgebung wird nicht unterstützt. Die Verwendung von IPv6-Adressen und IP-Adressbereichen wird nur unterstützt, wenn sowohl IPv6 als auch IPv4 auf diesem Computer aktiviert sind und das Netzwerk beide IP-Adressversionen unterstützt. Wenn Exchange 2013 in dieser Konfiguration bereitgestellt wird, können alle Serverrollen Daten an Geräte, Server und Clients senden und von diesen empfangen, die IPv6-Adressen verwenden.

• Die automatische Privat-IP-Adressierung (APIPA) ist ein Feature von 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 zugewiesener Adressen aus dem APIPA-Adressbereich) werden nicht für die Verwendung durch DAGs oder Exchange 2013 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, die unter Windows Server 2008 R2 oder Windows Server 2012 ausgeführt wird, erfordert mindestens eine IP-Adresse im MAPI-Netzwerk. Eine DAG erfordert mehr IP-Adressen, wenn das MAPI-Netzwerk über mehrere Subnetze erweitert wird. DAGs, die auf Windows Server 2012 R2 ausgeführt werden und ohne einen Clusteradministratorzugriffspunkt erstellt werden, benötigen keine IP-Adresse.

In der folgenden Abbildung ist eine DAG dargestellt, bei der sich das MAPI-Netzwerk aller Knoten in der DAG im gleichen Subnetz befinden.

In diesem Beispiel befindet sich das MAPI-Netzwerk in jedem DAG-Mitglied im Subnetz 172.19.18.*x_. Daher erfordert die DAG in diesem Subnetz eine einzelne IP-Adresse.

Die nächste Abbildung zeigt eine DAG mit einem MAPI-Netzwerk, das sich über zwei Subnetze erstreckt: 172.19.18.*x_ und 172.19.19.*x_.

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.

Jedes Mal, wenn das MAPI-Netzwerk der DAG über ein anderes Subnetz erweitert wird, muss eine weitere IP-Adresse für dieses Subnetz 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 das 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 mit dem Namen oder der IP-Adresse der DAG herstellen.

Hinweis

Obwohl die IP-Adresse und der Netzwerkname des Clusters intern vom System verwendet werden, besteht in Exchange 2013 keine feste Abhängigkeit, dass diese Ressourcen verfügbar sind. Auch wenn der administrative Zugriffspunkt des zugrunde liegenden Clusters (z. B. ip-Adresse und Netzwerkname-Ressourcen) offline ist, findet die interne Kommunikation innerhalb der DAG weiterhin unter Verwendung der DAG-Mitgliedsservernamen statt. 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.

Netzwerkfeatures	Einstellungen
Client für Microsoft-Netzwerke	Aktiviert
QoS-Paketplaner	Optional aktiviert
Datei- und Druckerfreigabe für Microsoft-Netzwerke	Aktiviert
Internetprotokoll, Version 6 (TCP/IP v6)	Aktiviert
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 des Servers 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.

Netzwerkfeatures	Einstellungen
Client für Microsoft-Netzwerke	Deaktiviert
QoS-Paketplaner	Optional aktiviert
Datei- und Druckerfreigabe für Microsoft-Netzwerke	Deaktiviert
Internetprotokoll, Version 6 (TCP/IP v6)	Aktiviert
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 des Servers zu verwenden.
• Replikationsnetzwerke verfügen in der Regel nicht über Standardgateways, und wenn das MAPI-Netzwerk über ein Standardgateway verfügt, sollten keine anderen Netzwerke Über Standardgateways verfügen. Das Routing von Netzwerkdatenverkehr in einem Replikationsnetzwerk kann mithilfe persistenter, statischer Routen zum entsprechenden Netzwerk auf anderen DAG-Mitgliedern konfiguriert werden, indem Gatewayadressen verwendet werden, die die Möglichkeit haben, zwischen den Replikationsnetzwerken zu routen. Der gesamte andere Datenverkehr, der nicht mit dieser Route übereinstimmt, wird vom Standardgateway verarbeitet, das auf dem Adapter für das MAPI-Netzwerk konfiguriert ist.
• DNS-Serveradressen sollten nicht konfiguriert werden.
• Das Kontrollkästchen Adressen dieser Verbindung in DNS registrieren sollte deaktiviert sein

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 einer ungeraden Anzahl von Mitgliedern verwenden keinen Zeugenserver. Alle DAGs mit gerader Anzahl von Mitgliedern müssen einen Zeugenserver verwenden. 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. Eine DAG verfügt über ein Quorum, wenn die meisten ihrer Mitglieder online sind und mit den anderen Onlinemitgliedern der DAG kommunizieren können. 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 wichtig, dass jedes DAG-Mitglied eine konsistente Ansicht darüber hat, wie der zugrunde liegende Dag-Cluster konfiguriert ist. Das Quorum dient als definitives Repository für alle Konfigurationsinformationen über den Cluster. Mit dem Quorum werden zudem Konflikte gelöst, um ein Split Brain-Syndrom zu vermeiden. Das Split Brain-Syndrom stellt einen Zustand dar, der eintritt, wenn DAG-Mitglieder aktiv sind, aber nicht miteinander kommunizieren können. Das Split Brain-Syndrom wird verhindert, indem immer die meisten DAG-Mitglieder (und wenn die DAGs eine gerade Anzahl von Mitgliedern haben, der DAG-Zeugenserver) zur Verfügung stehen und interagieren müssen, damit die DAG betriebsbereit 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 und der angestrebte Wiederherstellungszeitpunkt. Beide Werte werden in Minuten gemessen. Die angestrebte Wiederherstellungsdauer bezeichnet die Dauer, die für die Wiederherstellung des Diensts erforderlich ist. Der angestrebte Wiederherstellungszeitpunkt 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 für die Aktivierung des Standbydatencenters?
• 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.

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 Ihr Zertifikatentwurf von den verwendeten Clients und den Zertifikatanforderungen anderer Anwendungen ab, die Zertifikate verwenden. 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 von Zertifikaten minimieren, die für Ihre Exchange-Server und Reverseproxyserver verwendet werden. 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 empfiehlt es sich, für jedes Rechenzentrum ein einzelnes SAN-Zertifikat (Alternative Subject Name) zu verwenden und mehrere Hostnamen in das Zertifikat aufzunehmen. Um die Outlook Anywhere-Konnektivität nach einem Datenbank-, Server- oder Rechenzentrumswechsel sicherzustellen, müssen Sie für jedes Zertifikat denselben Zertifikatprinzipalnamen verwenden und das Outlook-Anbieterkonfigurationsobjekt in Active Directory mit demselben Prinzipalnamen in Microsoft-Standard Form (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 in Exchange integriert werden, weisen bestimmte Zertifikatanforderungen auf, die möglicherweise die Verwendung weiterer Zertifikate erfordern. Exchange 2013 kann zusammen mit Office Communications Server (OCS) vorhanden sein. OCS erfordert Zertifikate mit 1024-Bit oder stärkerer Verschlüsselung, die den OCS-Servernamen als Zertifikatprinzipalnamen verwenden. Da die Verwendung eines OCS-Servernamens für den Zertifikatprinzipalnamen verhindern würde, dass Outlook Anywhere ordnungsgemäß funktioniert, müssen Sie ein zusätzliches und separates Zertifikat für die OCS-Umgebung verwenden.

Netzwerkplanung

Zusätzlich zu den spezifischen Netzwerkanforderungen, die für jede DAG und für jeden Server, der Mitglied einer DAG ist, erfüllt werden müssen, gibt es einige Anforderungen und Empfehlungen, die speziell für Standortresilienzkonfigurationen 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 nicht mehr als 500 Millisekunden betragen. Außerdem gibt es bestimmte Konfigurationseinstellungen, die für DAGs empfohlen werden, die sich über mehrere Standorte erstrecken:

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

• Clientseitige DNS-Einträge sollten den Wert gültigkeitsdauer (Time to Live, TTL) von 5 Minuten haben: Die Anzahl der Ausfallzeiten, die bei Clients auftreten, hängt nicht nur davon ab, wie schnell ein Wechsel erfolgen kann, sondern auch davon, wie schnell die DNS-Replikation erfolgt und wie die Clients aktualisierte DNS-Informationen abfragen. DNS-Einträge für alle Exchange-Clientdienste, einschließlich Outlook Web App, Exchange ActiveSync, Exchange-Webdienste, Outlook Anywhere, SMTP, POP3 und IMAP4 auf den internen und externen DNS-Servern, sollten mit einer Gültigkeitsdauer von 5 Minuten festgelegt werden.

• Verwenden statischer Routen zum Konfigurieren der Konnektivität zwischen Replikationsnetzwerken: Verwenden Sie persistente statische Routen, um netzwerkkonnektivität zwischen den einzelnen Replikationsnetzwerkadaptern bereitzustellen. Dieser Prozess ist eine schnelle und einmalige Konfiguration, die für jedes 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 oben aufgeführten Anforderungen für Hochverfügbarkeit gibt es weitere Empfehlungen für die Bereitstellung von Exchange 2013 in einer standortresilienten Konfiguration (z. B. Das Erweitern einer DAG auf mehrere Rechenzentren). 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 und es dem zweiten Datencenter zu ermöglichen, die Dienstendpunkte eines fehlerhaften Datencenters zu hosten, muss die entsprechende Planung abgeschlossen werden. Es folgen Beispiele:

• Die Ziele der Vereinbarung zum 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 primären Datencenter bereitgestellt werden (außer der Dienst ist nicht im Rahmen der Vereinbarung zum Servicelevel für die Standortausfallsicherheit enthalten). Zu diesen Diensten gehören Active Directory, Netzwerkinfrastruktur (z. B. DNS oder TCP/IP), Telefoniedienste (wenn Unified Messaging verwendet wird) und Standortinfrastruktur (z. B. Stromversorgung oder Kühlung).

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

• Die erforderlichen Dienste müssen im zweiten Datencenter definiert werden. Wenn das erste Rechenzentrum beispielsweise drei verschiedene SMTP-Ziele auf verschiedenen Transportservern aufweist, muss die entsprechende Konfiguration im zweiten Rechenzentrum definiert werden, damit mindestens ein (wenn nicht alle drei) Transportserver die Workload hosten können.

• Zur Unterstützung des Datencenterswitchovers muss die erforderliche Netzwerkkonfiguration vorhanden sein. Diese Anforderung kann bedeuten, sicherzustellen, dass die Lastenausgleichskonfigurationen vorhanden sind, dass globales DNS konfiguriert ist und dass die Internetverbindung mit dem entsprechenden konfigurierten 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, müssen definiert und dokumentiert werden, um die geltende Vereinbarung zum 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.