Exchange 2016 & SnapManager Exchange 7.2

Im Rahmen diese Blogs möchte ich die Neuerungen des SnapManager for Exchange 7.2 kurz SME näher vorstellen. Aber, anders als sonst, möchte ich eine kleine Story drum herum erzählen.

 

bilder all.pngIch persönlich hatte meine ersten SME Installationen Ende der 90er Jahre. Damals gab es noch die Exchange Versionen 5.5 und die Exchange Datenbanken hatte eine Größe von rund 10-16 GB. Ja, richtig gelesen, 16GB… so groß wie heute eine Mailbox.

 

In dieser Zeit kam Microsoft auf NetApp zu und fragte, ob man nicht die coole NetApp Snapshot Technologie nutzen könnte um die Exchange DB zu sichern. Eigentlich eine super Idee, nur leider gab es zu dieser Zeit in unserem Betriebssystem DataONTAP (damals Version 6.1) noch kein Block Protokoll (FC oder iSCSI). Damals war NetApp noch Network Appliance und NAS-only.

 

Aber, NetApp war innovativ genug und hat ein eigenes Protokoll geschrieben, das sogenannte VLD (Virtual Logical Disk). Man hat sozusagen SCSI Pakete über NFS verschickt und die SnapDrive/SnapManager Kommunikation von Server zum Storage mittels RDP und RSH gemacht. Damit war der Weg für den ersten SnapManager Version 1.0 für Exchange 5.5 und 2000 geebnet.

 

So… warum erzähle ich heute den ganzen „alten Kram“. Ganz einfach, meines Erachtens hat sich in den vergangenen 16 Jahren aus Architektursicht im Exchange Umfeld, mal abgesehen von den neuen Clustering Technologien (Shared Cluster mit Exchange 5.5, 2000 und 2003, CCR mit 2007, DAG ab 2010) eigentlich nicht so viel verändert. Noch immer hat MS selbst kein geeignetes Produkt um die Exchange Datenbanken zu sichern. Und noch immer vertrauen viele Kunden, Service Provider und natürlich Partner unserem SME. Alleine in Deutschland, Österreich und der Schweiz werden täglich über eine Million Postfächer mittels SnapManager for Exchange gesichert.

 

Auch in der aktuellen Version SME 7.2, die kurz nach Erscheinen von Exchange 2016 verfügbar war, wurden einige neue Features implementiert. Mehr dazu weiter unten.

 

OK einige werden vielleicht denken: „… MS behauptet doch immer, man braucht gar kein Backup für Exchange mehr…“

 

Tja… das ist dann wohl eher eine Philosophiefrage. Microsoft bzw. die Exchange Fraktion versucht die Backup Herausforderung mit Datenbankkopien (vielen Datenbankkopien) unter dem Motto „Exchange Native Data Protection“ zu lösen. Naja, aus Microsoft Sicht sicherlich ein valider Ansatz, denn jede Kopie braucht einen Server und jeder Server eine Lizenz ;-)

 

Um das gleich mal vorweg zu nehmen, persönlich stehe ich diesem „Exchange Nativ Data Protection“ Ansatz sehr kritisch gegenüber. Auch die Neuerungen in Exchange 2013 und Exchange 2016 u.a. der sogenannte Replay Lag Manager sind m.E. eher bedenklich. Sie fragen sich warum?

 

Im Falle einer DAG mit JBOD Disk empfiehlt MS in der Regel eine Aktive- und zwei Passive- Datenbankkopien sowie eine sogenannte „Lagged“ Datenbankkopie. Die Lagged Copy ist gewissermaßen der letzte „Notnagel“ oder anders ausgedrückt: The purpose of the lagged database copy is to provide a recovery mechanism for the rare event of system-wide, catastrophic logical corruption. It is not intended for individual mailbox recovery or mailbox item recovery.

 

Was macht nun dieser Replay Lag Manager?

Kommt es zum Ausfall einer JBOD Disk und sind nur noch zwei gültige DB Kopien vorhanden, wird die Lagged Copy zur Passiven Kopie (when the feature is enabled, it replays Exchange Server transaction logs when fewer than three healthy copies remain).

Unterm Strich heißt das, fällt eine JBOD Disk aus, ist für einen gewissen Zeitraum der „Notnagel“ auch weg.

Sicherlich könnte man argumentieren und behaupten, das kommt ja so gut nie vor. Aber was, wenn doch?

 

Aus diesem Grund würde ich im Falle eines JBOD Designs für eher 5 oder besser 6 Datenbankkopien (also einer Aktiven, zwei oder drei Passiven und zwei Lagged Kopien) plädieren. Aber die Wirtschaftlichkeit einer solchen Lösung mit 5 oder sogar mehr Kopien, würde ich dann doch mal in Frage stellen.

 

Exchange Nativ Data Protection bietet aber m.E. noch ganz andere Herausforderungen. Zum Beispiel stelle ich mir die Frage, wie geht man mit der Situation um, wenn ein Exchange- oder Server Admin versehentlich oder mutwillig „alle“ Datenbanken löscht. Klar kann man argumentieren, unsere Admins machen das nicht. Aber was, wenn doch ?

 

Lange Rede kurzer Sinn, ich bin der Meinung auch mit Exchange 2016 kommt man um eine valide Datensicherung nicht herum. Wobei wir damit beim eigentlichen Thema wären, d.h. was ist neu in unserem SnapManager for Exchange 7.2 und was gibt es aus Architektursicht im Umgang mit Exchange 2016 zu beachten?

 

3.png

Neuerungen im SME 7.2:

  • Support für unser aktuelles Betriebssystem clustered Data ONTAP 8.3.2
  • Support für Exchange 2016, 2013 und 2010
  • Support für DAG ohne einem Administrative Access Point (Cluster-Administratorzugriffspunkt)

Architektur-Neuerungen im Umgang mit Exchange 2016:

In einigen Blog Einträgen hat Microsoft über die bevorzugte Exchange 2016 Architektur gesprochen, u.a. hier. Im Folgenden habe ich die vier für mich wichtigen Exchange 2016 Neuerungen aufgegriffen. Aufgrund der unterschiedlichen Architektur Microsoft mit JBOD vs. NetApp mit SAN/iSAN ergeben sich daraus auch unterschiedliche Empfehlungen, die ich ebenfalls erwähnen möchte:

 

  • Weniger Server-Rollen (nur noch Edge und Mailbox Server): Exchange 2016 hat keine Client Access Server oder Hub Transport Server mehr. Deren Funktionen wurden in die Mailbox Rolle übernommen.
  • DAG ohne Cluster-Administratorzugriffspunkt: Hochverfügbarkeit in Exchange 2016 wird weiterhin über eine DAG ermöglich. Neuerung hier, es ist nicht mehr notwendig, einer DAG eine virtuelle IP-Adresse zuzuweisen. Diese Funktion, auch als DAG ohne Cluster-Administratorzugriffspunkt genannt, wird, wie bereits erwähnt, von unserem SME unterstützt.
  • Einsatz von ReFS Datenträgern: Lt. den Microsoft Architekturvorschlägen sollen die Daten der Mailbox Server auf dem ReFS Filesystem installiert werden. Dies mag für JBOD Disken gelten, aber in Verbindung mit clustered ONTAP raten wir davon ab. Zum einen haben unsere internen Benchmarks gezeigt, dass ReFS im Vergleich zu NTFS eine deutliche Verschlechterung der Performance hat, d.h. schlechtere Antwortzeiten und weniger IOPs. Zum anderen ist wichtig zu erwähnen, dass ReFS in Verbindung mit unserem SnapManager for Exchange nicht freigegeben ist.
  • Einsatz von BitLocker für die Verschlüsselung der Daten: In Verbindung mit JBOD Disk sicherlich eine sinnvolle Maßnahme gegen Datenklau, denn auf jeder JBOD Disk liegt letztlich eine „leicht zu lesende“ Datenbank (.edb File) mit vielen Benutzerdaten. Ähnlich, wie im o.g. Falle mit ReFS, mag das für JBOD Lösungen sicherlich Sinn machen. Im Fall clustered ONTAP bieten unsere Technologien andere Möglichkeiten zum Schutz und zur Verschlüsselung der Daten.

 

Ich hoffe, der heutige Blog war für Sie hilfreich !