Untersuchen von Datenbankverfügbarkeitsgruppen für mehrere Standorte in Exchange 2010

Mithilfe von Datenbankverfügbarkeitsgruppen für mehrere Standorte in Exchange 2010 können Unternehmen Postfächer nahezu in Echtzeit an verschiedenen Standorten replizieren. Sie reduzieren auch die Zeit, die für die Wiederherstellung benötigt wird, wenn eine Katastrophe ein Rechenzentrum trifft. Wenn Sie erwägen, eine Datenbankverfügbarkeitsgruppe mit aktiven Benutzern auf mehrere Standorte zu verteilen, ist es wichtig, sich mit potenziellen Problemen vertraut zu machen, die eine DAG mit mehreren Standorten verursachen kann, sowie mit den verfügbaren Optionen.

Allgemeine Szenarien für eine Datenbankverfügbarkeitsgruppe mit mehreren Standorten

Es gibt einige gute Gründe, Ihre DAG auf mehrere Standorte auszudehnen, insbesondere wenn Sie über die entsprechenden Ressourcen verfügen.
Diese Gründe umfassen:

  • Replizieren von Postfachdatenbanken auf einen Disaster Recovery-Standort
  • Verwenden von zwei oder mehr Rechenzentren, um Remote-Büros einen ausfallsicheren Service zu bieten
  • Aufteilung einer DAG auf zwei Hauptbüros, um Benutzern in beiden Ländern lokale Dienste bereitzustellen und gleichzeitig Hochverfügbarkeit und Notfallwiederherstellung bereitzustellen

In diesem Tipp werde ich mich auf den endgültigen Anwendungsfall konzentrieren. In einem Exchange-Shop wird häufig eine einzelne DAG bevorzugt, die zwei Büros mit jeweils eigenem Rechenzentrum bedient.

Wo eine DAG mit mehreren Standorten Probleme verursachen kann

Schauen wir uns eine Multisite-DAG an, die ihren Benutzern einen hochverfügbaren E-Mail-Dienst bietet (Abbildung 1). Dies ist eine DAG mit sechs Knoten und drei Knoten pro Standort. Datenbanken sind an dem Standort aktiv, der ihren Benutzern am nächsten liegt.

Probentag

Abbildung 1: Ein kurzer Blick auf unsere Beispiel-DAG.

Wie Sie sehen, ist die DAG auf zwei Hauptbüros verteilt: eines in London und eines in Birmingham. Es gibt auch eine schnelle Verbindung mit geringer Latenz zwischen beiden Standorten. Das Ziel hierbei ist eine einzelne konfigurierte DAG zusammen mit Postfachdatenbanken für Benutzer an jedem Standort.
Im Rahmen des DAG-Entwurfs gibt es drei Kopien pro Postfachdatenbank sowie zwei Kopien, die mit Benutzern in ihren jeweiligen Büros und einer dritten Kopie am gegenüberliegenden Standort zusammengestellt werden. Sofern kein Problem vorliegt, besteht das Ziel darin, dass die aktiven Datenbankkopien den tatsächlichen Benutzern am nächsten kommen.
Es gibt auch den File Share Witness (FSW) zu berücksichtigen. Wir haben die Möglichkeit, es am Standort London, am Standort Birmingham oder an einem dritten Standort zu platzieren, der eine gute Anbindung sowohl an den Standort London als auch an den Standort Birmingham bietet.
Diese Optionen können jedoch Probleme verursachen. Mal sehen, was schief gehen kann, wenn wir eine einzelne DAG haben, die auf Standorte mit jeweils aktiven Datenbanken aufgeteilt ist.
Das erste, was schief gehen kann, ist a VAN Verbindungsfehler (Abbildung 2).

Die Verbindung zwischen den Websites wurde unterbrochen

Figur 2: Die Verbindung zwischen den Websites wurde unterbrochen.

Wie Sie sehen können, wurde die Konnektivitätsverbindung zwischen Standorten getrennt. Abhängig von der Platzierung des FSW wird eine der folgenden Aktionen ausgeführt:

  • Wenn sich der FSW in London befindet, werden die Knoten in Birmingham gestoppt und die DAG bleibt für Londoner Benutzer online.
  • Wenn sich der FSW in Birmingham befindet, werden die Knoten in London gestoppt und die DAG bleibt für Birmingham-Benutzer online.
  • Wenn sich der FSW an einem dritten Standort befindet, ist es sehr wahrscheinlich, dass sowohl London als auch Birmingham offline gehen. Mit etwas Glück kann eine Site die Konnektivität zur dritten Site – einschließlich des FSW – beibehalten und online bleiben.

Diese Ergebnisse stehen im Widerspruch zu dem, was das Design ursprünglich erreichen wollte, nämlich dass es Benutzern in beiden Büros hochverfügbare Exchange-E-Mails bereitstellen würde. Ein einfacher WAN-Verbindungsfehler hat die Dienste für mindestens einen Standort und in einigen Szenarien für beide Standorte beeinträchtigt.
Andere Arten von Fehlern führen zu ähnlichen Ergebnissen. Mit anderen Worten, ein Ausfall des Rechenzentrums in einem der beiden Hauptbüros kann die gesamte DAG stoppen, wenn der Standort, an dem sich der FSW befindet, einen Ausfall aufweist.

Verwenden mehrerer Datenbankverfügbarkeitsgruppen zum Schutz vor Fehlern

Welche Optionen stehen also zum Schutz vor ähnlichen Fehlern zur Verfügung, während für beide Standorte ausfallsichere Dienste bereitgestellt werden, bei denen ein Fehler an einem Standort keine Auswirkungen auf Benutzer am anderen Standort hat?
Wenn Sie zwei DAGs bereitstellen, wird jede aktive Datenbank nur an dem Standort kopiert, den sie hauptsächlich bedient. Auf diese Weise stellen Sie sicher, dass bei einem schwerwiegenden Ausfall des Rechenzentrums die Benutzer der überlebenden Site nicht offline bleiben und dass bei einem WAN-Verbindungsfehler – oder ähnlichem – die Benutzer an beiden Sites nicht auf Exchange-E-Mails zugreifen können.
Wie Abbildung 3 zeigt, haben wir unser Design so geändert, dass weiterhin dieselbe Anzahl von Postfachservern und dieselbe Anzahl von Datenbankkopien verwendet wird. Wir haben jedoch auch zwei separate DAGs mit der Mehrheit der Knoten für jede DAG an den Standorten konfiguriert, an denen sich die Mehrheit der Benutzer befindet.

Beispiel für zwei DAGs, die dieselbe Anzahl von Postfachservern und Datenbankkopien verwenden

Figur 3: Ein Beispiel für zwei DAGs, die dieselbe Anzahl von Postfachservern und Datenbankkopien verwenden.

Im Falle eines WAN-Verbindungsfehlers können beide Standorte weiterhin die lokalen Benutzer in jedem Büro bedienen. Im Falle eines vollständigen Ausfalls des Rechenzentrums sind die Benutzer am anderen Standort nicht betroffen, während der verbleibende DAG-Knoten für die einzelne ausgefallene DAG auf kontrollierte Weise online geschaltet werden kann.
Der einzige Nachteil dieses Ansatzes besteht darin, dass Sie bei einem Ausfall des Rechenzentrums an einem Standort den verbleibenden DAG-Knoten der einzelnen ausgefallenen DAG manuell online schalten müssen. Das heißt, dieses Fehlerszenario ist nicht nur vorhersehbar, es ist auch weniger schwerwiegend als die Alternativen, die wir untersucht haben.
Über den Autor
Steve Goodman ist ein Exchange MVP und arbeitet als technischer Architekt für einen der führenden britischen Microsoft Gold-Partner, die Phoenix IT Group. Goodman ist seit 14 Jahren in der IT-Branche tätig und arbeitet seit Version 5.5 intensiv mit Microsoft Exchange zusammen.

Similar Posts

Leave a Reply