DAG - Database Availability Groups

Diese Funktion löst alle bisherigen Clustermodelle (SCC,SCR,CCR,LCR) von Exchange 5.5 bis 2007 ab.

Exchange 2010 Standard kann schon eine DAG mit bis zu zwei Servern und 5 Datenbanken betreiben

Eine DAG nutzt als Unterbau den Windows 2008 Cluster. Insofern muss jeder Knoten in der DAG auf Windows 2008 Enterprise Server installiert sein.

Exchange 2007 hat mit der Einführung von CCR und SCR schon einen großen Schritt bezüglich der Verfügbarkeit von Exchange Servern gemacht. Der Verzicht auf einen gemeinsamen Speicher (Vergleiche Exchangecluster) zugunsten einer Replikation hat viele Probleme eliminiert. Allerdings waren gerade beim CCR immer genau zwei Server für einen virtuellen Server zuständig und ein Failover hat immer den kompletten virtuellen Server betroffen. Ein Defekt einer Datenbank mit einem Failover zur Lösung bedeutet also eine Downtime der bis zu 49 anderen Datenbanken.

Exchange 2010 geht hier ganz anders vor. Sie können mit Windows Cluster Mitteln bis zu 16 Server zu einem Clusterverbund zusammen schalten und jeder Server ist dabei ein Mailbox Server. Sie legen weiterhin eine Datenbank an, aber können nun auf den anderen Servern (1-15) ein entsprechendes Replikation anlegen. Insgesamt können pro Server bis zu 100 Datenbanken betrieben werden. Wer also eine Datenbank auf 3, 4 oder noch mehr Server repliziert kann sich nun selbst die Wahrscheinlichkeit eines Ausfalls ausrechnen. Zudem kann der Administratoren die Datenbanken auch gezielt "nachlaufen" lassen, d.h. die Protokolldateien  mit Verzögerung einbinden lassen.

Schauen wir uns die drei Evolutionsstufen einfach noch einmal an. Zur Vereinfachung wurden Domain Controller, Client und Hub und ClientAccess Server weg gelassen.

Bild Beschreibung

Exchange 5.5 -2003

Exchange 5.5, 2000 und 2003 konnten über den klassischen Windows Cluster entsprechend Hochverfügbar installiert werden. Zwei bis vier Server (Je nach Version) konnte über ein SAN gemeinsame Massenspeicher ansprechen. Jeder Server hat dabei "seine" Disks genutzt, welche beim Failover auf den anderen Knoten geschwenkt wurden. Natürlich wurden die Disks in dem SAN-Storage "redundant" ausgelegt und wer alles doppelt, muss natürlich auch den SAN-Speicher in zwei Brandabschnitten vorhalten und die Datensicherung geografisch auslagern.

Alles in allem kommt man so für 100 GB Nutzdaten schnell auf 400 GB (RAID1) brutto für Festplatten zzgl. Betriebssystem, Transaktionsprotokolle und Backupspeicher.

Die Kosten für das SAN, den Storage und die Replikation sind auch nicht zu unterschätzen.

Exchange 2007 CCR

Mit Exchange 2007 hat Microsoft erstmals einen "Shared Noting" Cluster für Exchange entwickelt, der zwar weiter auf "Windows Cluster" aufsetzt, aber kein SAN mit gemeinsamen Disks mehr benötigt.

Damit können die Disks nun lokal am Server angeschlossen werden. Viele Firmen haben aber ihre bestehenden SAN-Strukturen einfach weiter verwendet, da aufgrund der erwünschten Redundanz der Festplatten (RAID) bei größeren Server nicht genug Platz in den Servergehäusen selbst war.

Viele Firmen habe aber auch weiter die Techniken des SANs (Storage Virtualisierung, Snapshots, Clones etc.) genutzt.

Exchange 2010 DAG

Exchange 2010 führt CCR und SCR nun in der DAG zusammen. Bis zu 16 Server mit Windows Cluster können nun bis zu 100 Datenbanken pro Server betreiben und jede Datenbank wird auf mehrere Server repliziert. Ein Failover findet nun "pro Datenbank" und nicht mehr pro Server statt, was schneller geht. Zudem lässt sich Last einfacher verteilen und über gezielte Verzögerungen beim Replizieren kann man auch mehrere Versionen vorhalten.

Bei entsprechender Auslegung kann man sich sogar überlegen, die lokalen Disks gar nicht mehr per RAID abzusichern, da im Fehlerfall die Datenbank auf einem anderen Server weiter betrieben werden kann. Quasi einem Art Raid über Server statt einem "Disk-RAID".

Denken Sie dann noch einmal über ihr Backup nach. Die meisten Datensicherungen werden genutzt, um im Fehlerfall einen möglichst aktuellen Stand wiederherzustellen. Genau das kann ein Backup nur leisten, wenn man nicht nur einmal Nachts eine Sicherung durchführt, sondern auch unter Tage zumindest eine Sicherung der Protokolldateien durchführt. Meist halten Firmen aber eh nur wenige Versionen vor, da eine Archivlösung für langfristige Ablagen eingesetzt wird. Provokativ gefragt: Warum sollten sie ein Backup machen, wenn die Daten sowieso auf mehrere Server verteilt sind ? In der richtigen Konfiguration können Sie mit Exchange 2010 DACs und Windows Cluster eine ganz neue Storage-Architektur betreiben:

DAGs sind natürlich um so interessanter, je größer die Installation wird, .h. große Firmen oder natürlich "Hoster", die für Kunden diese Dienstleistung erbringen. Aber auch für den "Mittelstand" kann eine DAG den gestiegenen Anforderungen entsprechen.

DAG Praxis

Eigentlich ist die DAG eine ganz einfach Geschichte, das die GUI ihnen fast alles abnimmt. Aber an der ein oderanderen Stelle knirscht es doch noch. Hier zwei Beispiele.

Installation des DAG scheitert

In "sicheren" Umgebungen ist es meist nicht möglich, mal eben so ein Computerkonto anzulegen. Genau das versucht der Assistent bei der Installation der DAG. In solchen Fällen müssen Sie das Computerkonto von Hand vorab anlegen und dem ersten Exchange Server als auch dem "Exchange Trusted Subsystem"

Beachten Sie, dass das Computerkonto zur Installation des ersten DAG-Knotens deaktiviert und "Exchange Trusted Subsystem" berechtigt sein muss.

Seeding schlägt fehl

Wenn Sie einen einzelnen Server schon einige Tage betreiben und natürlich auch schön gesichert haben, dann werden dadurch natürlich auch Transaktionsprotokolle abgeschnitten. Wenn Sie nun einen zweiten Server installieren und diese beiden Server in eine DAG überführen, dann ist es mir schon passiert, dass das initiale Kopieren (Seeding) nicht funktioniert. Zwar kopiert der passive Server die Datenbank aber nach dem Copy versucht er die zwischenzeitlich aufgelaufenen Transaktionsprotokolle zu kopieren und sucht dabei nach Logdateien, die es gar nicht mehr gibt. Sie wurden nämlich von dem Backup schon gelöscht. Lösung:

Sie dismounten die Datenbank auf dem aktiven Knoten, prüfen dann mit "ESEUTIL /MH", dass die Datenbank" CleanShutdown" ist und löschen dann alle Transaktionsprotkolle. Nun starten Sie die Datenbank wieder. Sie beginnt nun wieder die Logdateien von 000001 an hochzuzählen. Und nun kann auch das erstmalige Kopieren fehlerfrei laufen.

Backup der aktiven Kopie mit Windows Bordmitteln.

Lesenswert ist der Artikel auf der Seite Using Windows Server Backup to Back Up and Restore Exchange Data (http://technet.microsoft.com/en-us/library/dd876851.aspx). Er beschreibt gut, wie mit "Windows Server Backup" auch Exchange und insbesondere DAG-Systeme gesichert werden können. Windows Server Backup kann nämlich nur die aktive Kopie sichern. Das ist aber nicht alles. Damit die Sicherung funktioniert, muss der "Microsoft Exchange Replication service VSS writer " deaktiviert werden. Das erfolgt per Registrierung auf allen DAG-Servern.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v14\Replay\Parameters]
"EnableVSSWriter"=dword:00000000

Sollten Sie später eine Drittsoftware einsetzen, die auch passive Datenbanken kopieren kann, dann müssen Sie diesen Eintrag wieder rückgängig machen.

Weitere Links

Keywords:Exchange2010 DAC