Mit Datenbankverfügbarkeits-Gruppen Exchange-Datenbanken vor Ausfällen schützen

Mit Datenbankverfügbarkeitsgruppen lassen sich in Exchange 2010/2013 die Postfach-Datenbanken vor Ausfällen schützen. Wir erläutern die Funktionen.

Dieser Artikel behandelt

Exchange-Management

Eine Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) ist der primäre Mechanismus ab Exchange Server 2010, um Postfachdatenbanken gegen Ausfall zu schützen. Eine DAG basiert auf Failover-Cluster-Mechanismen in Windows Server und Datenbank-Replikation. Administratoren müssen keinen zusätzlichen Cluster erstellen. Die komplette Verwaltung läuft über die Exchange-Verwaltungskonsole und Exchange-Verwaltungsshell. Die Technologie lässt sich mit Exchange Server 2010/2013 Standard sowie Servern mit Windows Server 2008 R2 Enterprise/Data Center und Windows Server 2012 Standard/Data Center einsetzen. Ab Exchange Server 2013 SP1 können Administratoren Exchange 2013 auch auf Servern mit Windows Server 2012 R2 installieren. Ohne das SP1 ist Exchange 2013 nicht kompatibel mit Windows Server 2012 R2.

Eine Postfachdatenbank kann über mehrere DAG-Mitglieder repliziert werden und dadurch Exchange-Datenbanken vor Ausfällen schützen. Fällt ein Daternbank-Server aus, schaltet ein anderer Datenbank-Server seine Kopie der Datenbank online. Ein Neustart von Outlook ist unter Umständen auf dem Client notwendig. Ist der ursprüngliche Datenbank-Server wieder aktiv, lässt sich dieser wieder vollständig in die DAG-Struktur integrieren und Datenbanken auf dem Server online schalten.

Dieses Konzept ist in der Theorie einfach, aber es gibt eine Reihe von Faktoren, welche die Effektivität der DAG beeinflussen können. Ein Hauptfaktor für den Schutz der Datenbanken ist die Anzahl der Kopien: mehr Datenbankkopien bieten einen besseren Schutz.

Zusätzliche Datenbankkopien sind aber allein nicht ausreichend. Die DAG muss so konstruiert sein, dass die Datenbankkopien bei einem Ausfall online geschaltet werden und über eine aktuelle Datenbasis verfügen. Administratoren können beim Erstellen der DAG - oder danach - festlegen, in welchem Zeitraum die Transaktionsprotokolle der produktiven Datenbank auf die Kopie übertragen werden. Regelmäßige Kopien sind somit obligatorisch.

Administratoren können konfigurieren, in welchem Zeitrahmen neue Kopien von produktiven Datenbanken erstellt werden sollen. Diese Konfiguration sollte man überprüfen.

Eine DAG basiert auf Failover-Clustern, das heißt der Cluster muss immer funktionieren, damit eine einzelne Kopie zugeordnet und bei Bedarf aktiv geschaltet werden kann. Wichtig ist dabei das Quorum, das erkennt und bestimmt, welcher Knoten online oder offline ist. Bei einer gerade Anzahl von Knoten, zum Beispiel zwei Servern, ist es die beste Option, wenn neben den Exchange-Servern noch ein sogenannter „Witness Server“ in der DAG ist. Dieser entscheidet, ob der Server mit der produktiven Kopie offline ist oder der Server mit der Sicherungskopie das nur annimmt und sich online schaltet. Quorum und Witness Server entscheiden darüber, welche Cluster-Knoten funktionieren und teilt die produktiven Datenbankkopien entsprechend ein.

Cluster-Bildung in Exchange

Die Anforderung für ein Failover-Cluster-Quorum lässt sich damit begründen, dass größere Cluster besseren Schutz bieten als kleinere. Das liegt vor allem an der Anzahl der Servern die den produktiven Betrieb auch dann aufrecht erhalten, wenn einzelne Server ausgefallen sind.  Zur Veranschaulichung ein Beispiel: Stellen Sie sich vor, dass Sie eine DAG mit drei Postfach-Servern erstellt haben und eine Kopie jeder Mailbox-Datenbank auf jedem DAG-Server vorhanden ist. Das ist durchaus sinnvoll, da jeder Postfach-Server den Ausfall jedes anderen Servers kompensieren kann. Wenn ein Postfach-Server ausfällt, bleiben die Postfachdatenbanken online, da ein anderer Server im Cluster seine Offline-Kopie aktiv schaltet. Welcher das ist, entscheidet Exchange auf Basis der vorhandenen Informationen und der Aktualität der Datenbank. Ein Drei-Knoten-Cluster erfordert, dass zwei Knoten online bleiben müssen, um das Quorum aufrecht zu erhalten.  Wenn ein einzelner Knoten ausfällt, darf nicht noch ein weiterer Knoten ausfallen, da sonst der Cluster nicht mehr feststellen kann, welcher Knoten offline ist. In diesem Fall hilft der Witness Server, der entscheidet, welcher Knoten online ist.

Zuvor war der einzige Weg, um Exchange-Postfächer gegen mehrere Server-Ausfälle zu schützen, die Erstellung einer Datenbankverfügbarkeitsgruppen mit fünf oder mehr Mitgliedern. Allerdings ist das mit hohen Kosten verbunden. In Exchange 2010/2013 sind daher auch kleine DAGs mit nur zwei Servern stabil, wenn ein Witness Server im Einsatz ist. Microsoft hat somit eine wichtige Änderung in Windows Server 2012 Failover Clustering integriert: das dynamische Quorum. Dadurch lässt sich ein Cluster auch dann ausführen, wenn die Mehrheit der Cluster-Knoten nicht verfügbar ist. Ein Cluster kann sogar aktiv bleiben, wenn nur ein einzelner Knoten online ist.

Was ist ein dynamisches Quorum?

Das dynamische Quorum ist eine Funktion im Windows-Server-Failover-Cluster, mit der ein Quorum neu berechnet wird, wenn Knoten ausfallen oder abgeschaltet werden. Diese Funktion wird durch eine „Abstimmung“ der beteiligten Knoten möglich. Der Cluster erfasst die Gesamtzahl der Knoten, die online sind. Diese Zahl wird verwendet, um die Funktionsfähigkeit festzustellen. Wenn nur zwei Cluster-Knoten online sind, bilden beide die Mehrheit und die Funktionsfähigkeit ist gegeben. Der Cluster bleibt aktiv.

In der Clusterverwaltung können Administratoren das Quorum anpassen.

Die Idee hinter dem dynamischen Quorum ist es, dass sich die Quorum-Anforderungen ändern, wenn die Server-Knoten manipuliert werden. Angenommen Unternehmen setzen einen Drei-Knoten-Cluster ein, aber zwei Knoten fallen aus. Ein einzelner Cluster-Knoten ist somit in der Lage alleine die Funktionsfähigkeit zu bestimmen. Die beiden anderen Knoten können offline gehen, das Cluster-Quorum bleibt erhalten.

Um das Quorum zu manipulieren, öffnen Administratoren den Failover Cluster Manager und wählen den gewünschten Cluster. Im Bereich Aktionen\Weitere Aktionen lassen sich die Einstellungen ändern.  In diesem Bereich starten Administratoren anschließend den Cluster-Quorum-Assistenten. Hierüber lassen sich die Einstellungen schließlich konfigurieren.

Folgen Sie SearchEnterpriseSoftware auf Twitter @sentsoftwarede.

Artikel wurde zuletzt im April 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Exchange-Management

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close