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 2010 Recommend DAG Update
http://blogs.technet.com/b/rmilne/archive/2012/02/29/exchange-2010-recommend-dag-update.aspx

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/2013 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:

  • Kein RAID
    Weniger Disks in den einzelnenn Server
  • Kein Backup
    Keine Gigabytes, die tag für Tag auf andere Disks oder gar Bänder übertragen werden und SAN, Disk-IO oder sogar Netzwerke belasten
  • Mehrere einfache Server
    Die einzelnen Server können kleiner und vor allem einfacher dimensioniert werden. Wenn ein Server-Team sich die Arbeit teilt, kann ein einzelner Server auch ausfallen. Denkbar sind der Verzicht auf redundante Netzteile, redundante Netzwerkanbindungen etc etc.
  • Lokal Disks - Kein SAN
    Viele Server können heute schon mehrere TB Disks "im Bauch" tragen. Die komplette SAN-Infrastruktur
  • Geografische Verteilung
    Mit diesen Optionen wird es auch einfacher, die verschiedenen Server in verschiedene Rechenzentren zu verteilen. Zwar wird es weiterhin Einschränkungen geben, da die Änderungen und Clientzugriffe natürlich durch die Leitungen gequetscht werden müssen, aber viele Firmen haben zumindest zwei Datenräume, in denen nun die Server abgestellt werden können, ohne viel "Sonderarbeit" für SAN und LAN.
  • "Standard statt kompliziert"
    Alles in allem geht der Weg zu mehreren einfachen Standardservern, die jeder Admin oder Dienstleister im Fehlerfall recht einfach tauschen oder reparieren kann. Spezialknowhow zu Adapter-Teaming, SAN-Zoning etc. entfällt.

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 und Kopien als Backup

Die Replikation von Datenbanken hat nicht nur das Ziel, die Verfügbarkeit zu erhöhen. Sicher ist eine Kopie einer Datenbank beruhigend, da beim Ausfall eines Storage damit nicht sofort ein Backup wiederhergestellt werden muss. Zudem kann mit der passenden Software einfach die "nicht aktive Kopie" gesichert werden. Das entlastet den Server, der aktuell die Benutzer bedient. Aber Fakt ist ebenfalls, dass früher bei Servern mit einem Datenspeicher meist täglich eine Sicherung erfolgte. Durch die permanente Replikation in einer DAG kann dieses Verfahren abgewandelt werden, denn die erste Kopie kann als Ersatz für das tägliche Backup angesehen werden. Wer sogar mehr Kopien in der DAG anlegt, kann das Backup noch weiter reduzieren. Ab vier Kopien spricht selbst Microsoft davon, dass ein Backup eingespart werden kann.

Aber selbst wenn sie weiterhin "klassisch" sichern, können sie eine Reduzierung der Intervalle überdenken und die "teuren" Vollsicherungen seltener durchführen oder bei mehreren Datenbank an verschiedenen Tagen durchführen. Das entlastet den Exchange Server (Storagre, LAN) aber auch das Backupsystem.

Die Anzahl der Kopien ist natürlich durch die Anzahl der Server in der DAG beschränkt. Wenn wir zur Vereinfachung einfach jedem Server eine Kopie zuweisen, dann könnte sich folgende Tabelle ergeben:

AnzahlServer FSW Backup Beschreibung

1

kein

Täglich

Ein einzelner Server ist noch keine DAG. Es ist der klassishe

2

Erforderlich

Täglich Log
Wöchentlich Full

Ab zwei Servern in einem Cluster kann mit einer DAG eine Datenbank als Kopie vorgehalten werden. Sie können die passive Datenbank sichern und zudem das Intervall zwischen Vollsicherungen dehnen. Allerdings dürfen Sie einen Server nur bis zu 50% " belasten", da er im Fehlerfall die komplette Last abdecken muss.

3

Nein

Täglich Log
Monatlich Full

Mit drei Servern ersparen Sie sich das FSW, da die Anzahl der Cluster "ungerade" ist und sie haben natürlich drei Instanzen. Selbst beim Ausfall eines Servers sind also immer noch zwei Datenbank aktiv und damit nicht kritisch. Bedenken Sie aber dass beim Ausfall des zweiten Servers der Cluster kein "Majority" mehr hat und manuelle Eingriffe erforderlich sind. Das wird oft vergessen, wenn so ein Dreigestirn in zwei Datacenter aufgebaut wird. Das "Backup-RZ" mit einem Knoten geht nicht automatisch live, wenn das Haupt-RZ ausfällt.

4

Erforderlich

könnte entfallen

Mit dem vierten Server können sie vier Kopien anlegen. Das ist interessant, wenn das Backup damit komplett eingespart wird. Auch kann in zwei Datacentern ein Paar stehen und damit ist der Ausfall eines RZ nicht "kritisch". Allerdings ist auch hier wieder das Majority zu beachten, welches als Share vorliegt

5-8

Ja/Nein

Könnte entfallen

DAGs mit bis zu 8 Servern sind möglich aber meist wird eine Datenbank dann nicht auf mehr als 4 Server repliziert. Jedes Replikat kostet nicht nur Speicherplatz, sondern erzeugt ja zusätzlich Replikationslast. Mehrere Server erlauben aber eine flexiblere Platzierung von Datenbanken über Server hinweg.

Bei einer geraden Anzahl von Servern müssen Sie ein "File Share Witness" konfigurieren, welches auf einem anderen Server liegt.

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"

Bei der Installation einer Ex2013 DAG auf Windows 2012 müssen Sie das "Cluster Network Objekt" vorher manuell anlegen:
Pre-Stage the Cluster Name Object für a Database Availability Group
http://technet.microsoft.com/en-us/library/ff367878(v=exchg.150).aspx

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

File Share Witness

Der Exchange Assistent versucht bei einem Cluster mit einer geraden Anzahl von Knoten automatisch den erforderlichen Witness-Share auf einem CAS-Server anzulegen. Oft ist aber kein CAS vorhanden (z.B.: 2-Server-DAG), so dass ein anderer Server dazu herhalten muss. Der Share muss dort dann manuell auf einem anderen Server angelegt werden.

  1. Ordner auf dem Server anlegen
    z.B. C:\FilesWitness\DAGNAME
  2. Rechte auf dem Ordner anpassen
    Exchange Trusted Subsystem: Owner Permission
    Exchange Trusted Subsystem: NTFS Full Control
  3. Dateifreigabe (Share) einrichten
    Name des Share: "DAGNAME.FQDN"
  4. Rechte auf Share eintragen
    Computeraccount DAGNAME$: Full Control

Dann können Sie den Assistenten weiter durchführen. Eventuell kommen noch einige Warnungen. Prüfen Sie am Ende einfach im Clustermanager, ob die Ressourcen sauber online sind.

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.

Monitoring

Nur weil Sie eine DAG mit Cluster haben, wird ein Monitoring nicht überflüssig. Ein Ausfall eines Systems wird von den Anwender in der Regel nicht bemerkt aber ohne Überwachung bekommen Sie auch nichts mehr mit und können keine Gegenmaßnahmen ergreifen. Daher ist ein Monitoring noch viel wichtiger. Hier ein paar Links:

Weitere Links