DAG - Die Antwort auf alle High Availability Fragen, oder?
Database Availability Groups sind ein Weg um Exchange Datenbanken im Betrieb zu replizieren und bis zu 16 Instanzen aktiv / passiv oder auch im Lag zu betreiben. Ist eine Replika kaputt weil zum Beispiel das billige RAID 0 darunter ausfällt, so wird einfach auf eine verbleibende Kopie gefailovert (automatisch) und die kaputte Kopie neu geseeded (manuelles Wiederherstellen durch Kopieren der DB und Nachspielen der entstandenen Logs in diesem Zeitfenster.)
Im Zuge dessen wurde auch immer wieder ein Gerücht laut, das Backup von Exchange 2010 sowieso unnötig wäre und durch ein entsprechendes DAG überflüssig. Man kann ja jetzt die Datenbanken auf billiges Storage mit SATA Platten legen und dadurch allein schon Kosten sparen. Dann ist auch nicht mehr relevant das man die eine oder andere Kopie davon noch zusätzlich hat.
Möglich wird das durch massive Änderungen im eigentlichen Datenbank Layout. Bis Exchange 2007 waren Exchange Datenbanken immer nach folgendem Schema aufgebaut.
Alle Mailboxen waren quasi in einem gemeinsamen Topf und wurden gemeinsam verwaltet. Dadurch sind I/Os auf den Platten auch entsprechend "Random" verteilt wenn User innerhalb ihrer eigenen Mailbox zwar auf sequentielle Daten zugreifen, ist der Datenbankzugriff aber vollkommen "Random".
In Exchange 2010 wurde dies insofern verbessert, das jede Mailbox als eigene Einheit innerhalb der Datenbank gesehen wird. Dadurch ist es möglich Zugriffe stark zu optimieren und wir bekommen aus Storage Sicht ein wesentlich gleichmäßigeres I/O Muster. Zugriffe werden "sequentieller".
Dadurch verliert man aber auch ein relativ bekanntes Feature, genannt Single Instanze Store. Dieser ist in Exchange 2010 nicht mehr vorhanden. Um dem Datenwachstum entgegen zu wirken hat man als Gegenmaßnahme aber die Header und Text / HTML Komprimierung eingeführt. Dadurch wachsen Exchange Datenbanken in Summe "nur" ca. 20 % im Vergleich zu Exchange 2007.
Aber - warum dann eigentlich teure Storagelösungen?
DAG allein ist eine gute Lösung um auf Applikationslevel Ausfallsicherheit zu erreichen. Aber es hat nun mal auch seine Grenzen. Als erstes Beispiel sei genannt - die Replikation ist darauf begrenzt das die Round Tripe Time zwischen den Nodes maximal 250 ms betragen darf. Damit sind Cluster über große Entfernungen ein Problem. Genau hier setzt nun das Storagesystem an und in unserem Fall mit altbewährten Mitteln.
Ein lokaler DAG Cluster mit zwei Nodes dient dazu einen applikatorischen Ausfall abzufangen und danach für Desaster Zwecke in ein zweites weit entferntes Rechenzentrum zu replizieren. Wie geschaffen für Snapmirror. Die Daten müssen dafür aber konsistent per VSS gesnapshotted werden und dafür brauchen wir wieder eine Applikationsintegration. Auch hier ist die SnapManager Familie bereits altbewährt und bestens integriert.
Snapmirror ist somit keine Alternative zu DAG sondern vielmehr eine Ergänzung.
Auch sei hier generell kurz erwähnt - es gibt die technische Möglichkeit den DAG eigenen Replikationsmechanismus durch Third Party Produkte zu erweitern. Man wird sehen wann es hier zu entsprechenden Entwicklungen kommt. Ich darf da mal nicht mehr dazu sagen... ;)
Weiters ist es möglich bis zu 16 Kopien einer Datenbank zu betreiben. Eine davon aktiv, alle weiteren passiv sowie mit bis zu 2 Wochen Verzögerung. Damit habe ich quasi die Möglichkeit wenn alle Stricke reissen auf eine alte Version meiner Datenbank zurück zu greifen. Bedeutet aber, bei mehreren Ständen jeweils einen eigenen Server. (Kopien können nicht mehrfach auf einem Server angelegt werden) Was jetzt allein von Platz und Anzahl von Servern doch etwas ineffizient ist. Viel sinnvoller ist es doch Point in Time Kopien der Datenbanken anzulegen um mal eine in der Hinterhand zu haben. Davon aber natürlich wesentlich mehr als nur 16 Versionen. Klingt doch vernünftig oder?
Schon sind wir bei Backups angelangt und schon bei Snapshots (VSS ist die einzig supportete Backup Schnittstelle von Exchange 2010) und der damit wunderbaren Integration von Netapp Snapshots mit dem SnapManager for Exchange. Damit - wieder, keine LAG Kopie verwenden sondern lieber Snapshots, dafür mehr davon und schon ist wieder ne Menge an Datenplatz gespart worden und noch dazu der Vorteil das wir einfach mehr davon haben die durch ESEUtil beim Backup auch noch auf Konsistenz überprüft werden.
Und warum noch?
Snapmirror ist natürlich nicht der einzige Grund eine NetApp Storagelösung als Basis für Exchange 2010 einzusetzen. Einfach gesagt - SnapRestore wär ja auch noch da.
Man stelle sich vor das eine DAG Kopie aus unerklärlichen Gründen inkonsistent wird und nicht mehr repliziert. Die Replika steht auf Failed und der Exchange Admin sieht sich schon Gigabyte-weise neue Datenbanken seeden. Mit SnapRestore kann abgeholfen werden. Anstatt die gesamte Datenbank neu zu replizieren geht man einfach auf einen bestehenden Snapshot zurück der Konsistent war und muss nur mehr die Logs bis zum aktuellen Stand nachspielen. Ein Prozess der je nach Alter des Snapshots sogar vom DAG selbst erledigt wird. Es muss nur eine konsistente Datenbank vorhanden sein und das ist durch den SnapManager for Exchange und der ESEUtil Überprüfung der Datenbank bei jedem Backup gewährleistet.
Cool eigentlich - aber war das schon alles?
Wie auch in jeder guten Kochshow haben wir da mal was vorbereitet und natürlich noch ein Feature gratis dabei. Deduplication greift bei Exchange 2010 Stores natürlich entsprechend besser da der Single Instance aufgebrochen wurde. Dedup Raten zwischen 10 - 20 % sind durchaus realistisch und bringen gerade bei großen Stores natürlich entsprechende Einsparungen. Wie im Screenshot anbei zu sehen sind 16% auf einem lächerlichen 150 GB LUN durchaus möglich und bringen schon 47 GB Platz zurück.
Flexibilität sei hier ein zweites Stichwort. Der physische Server stößt auch bei großen SATA Festplatten bald an die Grenzen. Ein Storagesystem ist wesentlich skalierbarer und auch hier ist es natürlich technisch möglich mit großen SATA Platten notwendige Kapazitäten von vielen TB schnell zu erreichen.
Die Exchange eigene Archivmailbox, die seit SP1 endlich in einen dedizierten Mailboxstore verschiebbar ist, ist ein gutes Beispiel für die Ablage auf SATA Platten mit viel Kapazität und wenig Spindeln wenn Performance nicht das Thema ist.
Zusammenfassend sei gesagt, Exchange auf Storage Systemen macht natürlich auch weiterhin Sinn. Wenn gleich sich die Gründe etwas verschoben haben ist mit der entsprechenden Intelligenz der Box trotzdem noch Platz für Exchange auf NetApp und ein Mehrwert durchaus vorhanden.