NetApp Tech OnTap
     

Diskussion: DR für Microsoft Applikationen
mit VMware SRM und NetApp

In Ausgabe 1/2010 von Tech OnTap fanden Sie einen Artikel über die Virtualisierung von Microsoft Applikationen mit VMware, NetApp und Cisco. An diesen Artikel anknüpfend untersuchte Tech OnTap gemeinsam mit Wen Yu von VMware und Larry Touchette von NetApp die Details des Disaster Recovery von Microsoft Applikationen, um zu ermitteln, warum die Einführungsquote für DR in VMware/NetApp Umgebungen höher ist.

Tech OnTap: Die meisten Benutzer sind mit Disaster Recovery in Umgebungen mit Microsoft Applikationen sehr zurückhaltend. Woran liegt das Ihrer Meinung nach?


Wen Yu (VMware): Wie wir bei VMware herausgefunden haben, hat dies in der Regel drei Gründe. Der erste und vermutlich wichtigste sind die Kosten für DR. Man braucht nicht nur eine zweite Einrichtung, sondern auch zusätzliche Server, mehr Netzwerkausrüstung und doppelt so viel Speicherplatz. Das kann sowohl mit physischen als auch mit virtuellen Servern schnell zu teuer werden.

Zweitens war Disaster Recovery schon immer äußerst komplex, besonders in Umgebungen mit physischen Servern. Noch schwieriger ist der Versuch, DR applikationsübergreifend durchzuführen. Ein unüberschaubares Sammelsurium aus Produkten und Technologien kann die Folge sein. Viele Produkte erfordern darüber hinaus auf beiden Seiten identische Konfigurationen, was den Preis zusätzlich in die Höhe treibt.

Und drittens scheitern viele an der Netzwerkbandbreite, die für einen vernünftigen Recovery-Zeitpunkt (RPO) erforderlich ist. Viele Windows-Unternehmen haben keine ausreichende Bandbreite für die Replizierung. Sie zögern jedoch mit Investitionen in eine höhere Bandbreite.

Die gemeinsame Lösung von NetApp, Cisco und VMware setzt genau an diesen Herausforderungen an.

Larry Touchette (NetApp): Lassen Sie mich Wens letzten Punkt weiter ausführen: Mit NetApp und VMware ist DR günstiger und einfacher. Sie können eine Lösung bereitstellen, die eine weit höhere Anzahl an Applikationen abdeckt. Wenn Sie wollen, sogar Ihre komplette VMware-Umgebung. Einige gemeinsame Kunden konnten mit dem Geld, das sie durch den Einsatz der NetApp Deduplizierung für VMware-Primärspeicher sparten, Speicher für eine DR-Umgebung ausgleichen oder vollständig finanzieren. Wer Tech OnTap regelmäßig verfolgt, kennt die Vorzüge der NetApp Deduplizierung in Verbindung mit VMware. [Dieser Artikel ist ein guter Einstieg in das Thema VMware DR und Deduplizierung. – Anm. der Red. von TechOnTap]

Im Hinblick auf die Bandbreite ist die NetApp SnapMirror Technologie bei Verwendung mit NetApp Deduplizierung sehr effizient, da nur eindeutige Blöcke dedupliziert werden. Vor kurzem hat NetApp zur WAN-Beschleunigung Data ONTAP mit SnapMirror Komprimierung ausgestattet. Dadurch funktionieren Umgebungen mit begrenzter Bandbreite noch besser, denn die Bandbreitenauslastung wird je nach Komprimierbarkeit der Daten um bis zu 70 % gesenkt. [Die SnapMirror Komprimierung wurde in einem kürzlich erschienen Tech OnTap Artikel erörtert. – Anm. der Red. von TechOnTap]

Die Akzeptanz von DR ist in kombinierten VMware/NetApp Umgebungen ziemlich hoch. Ich vermute, dass dies auf die eben genannten Faktoren zurückzuführen ist.

TOT: Warum ist VMware Site Recovery Manager (SRM) in einer DR-Konfiguration mit VMware/NetApp sinnvoll?


Wen: Für virtualisierte Applikations-Server besteht der schwierigste Teil des Disaster Recovery darin, die erforderlichen Schritte zum Verbinden, Inventarisieren, Neukonfigurieren und Hochfahren der Virtual Machines am DR-Standort auszuführen. Die manuelle Ausführung dieser Aufgaben kann kompliziert und fehleranfällig sein, insbesondere wenn Abhängigkeiten verlangen, dass eine VM vor der anderen gestartet wird. Der Versuch, diese Schwierigkeiten durch automatisierte DR-Prozesse mithilfe von Skripten zu beheben, ist sehr kostspielig und wartungsintensiv.

Site Recovery Manager vereinfacht das Management im gesamten DR-Prozess, einschließlich Bestandsaufnahme, Konfiguration, Failover und Tests. Mit dem Recovery-Plan, den Sie in der Setup-Phase der SRM-Konfiguration erstellen, können Sie Ihren gesamten Plan vorkonfigurieren. Die enthaltenen Funktionen zur Bestandsaufnahme und die nahtlose Integration mit vCenter beschleunigen den Prozess.

Sobald Sie einen Plan erstellt haben, können Sie diesen automatisch ausführen. Benutzereingriffe sind dafür kaum nötig. SRM setzt alle erforderlichen Schritte um und startet die Virtual Machines in der richtigen Reihenfolge. Beispielsweise können Virtual Machines, die die Infrastruktur unterstützen, wie Active Directory (AD)- und DNS-Server, zuerst gestartet werden. Danach folgen Datenbank-, Applikations- und schließlich Web-Server.

Ein weiterer Pluspunkt ist die Möglichkeit, Tests durchzuführen. Bei den meisten DR-Lösungen ist es fast unmöglich, die Funktionsweise zu testen, ohne die normalen Produktionsvorgänge und die fortlaufende Replizierung zu unterbrechen. Mit SRM und NetApp sind DR-Tests unkompliziert und effizient. Sie müssen beispielsweise nur ein isoliertes Testnetzwerk erstellen (damit nicht versehentlich zwei aktive Instanzen jeder VM in Ihrem Firmennetzwerk vorhanden sind). SRM automatisiert den Prozess, sodass Ihre Tests isoliert stattfinden.

Larry: Wenn Sie die NetApp FlexClone Technologie mit SRM DR-Tests kombinieren, können Sie Ihren DR-Standort verwenden und dort Tests ausführen – und das ohne Unmengen von zusätzlichem Speicher und ohne die fortlaufende Replizierung zwischen den Standorten oder die Vorgänge am Primärstandort zu unterbrechen. So ist es ganz einfach, das Disaster Recovery zu testen, ohne den Produktionsstandort zu beeinträchtigen oder SLA-Vereinbarungen zu gefährden.

Manche Replizierungslösungen benötigen doppelte Kapazität, um auch während der Tests Speicherreplikate am DR-Standort zu erstellen. Dadurch wird kostbare Zeit verschwendet. Vorhandene Testumgebungen lassen sich nicht lange nutzen, und häufige Wiederholungen von Tests sind ebenfalls nicht möglich. FlexClone verringert den Speicherbedarf erheblich und beschleunigt den Prozess.

 

Inkrementelle Speicheranforderung für DR-Tests mit FlexClone

Abb. 1) Inkrementelle Speicheranforderung für DR-Tests mit FlexClone

TOT: Was sollte ich also beachten, wenn ich eine DR-Lösung mit VMware SRM und NetApp Storage bereitstellen will?


Wen: Hinsichtlich SRM ist einiges zu beachten. Zunächst brauchen Sie einen VMware vCenter-Server an jedem Standort und einen Microsoft SQL-Server, um die SRM-Datenbank und die Server zu speichern, auf denen die unterstützten ESX-Versionen ausgeführt werden.

Der Primär- und der Recovery-Standort müssen mit einem zuverlässigen IP-Netzwerk verbunden sein. Der Recovery-Standort sollte auf dieselben öffentlichen und privaten Netzwerke zugreifen können wie der Primärstandort. Und schließlich sollte der Recovery-Standort über aktuelle Active Directory- und DNS-Server verfügen.

Bei der eigentlichen Replizierung hängt SRM vom Speicher ab, in diesem Fall von NetApp. Kunden, die Tier-1-Applikationen ausführen, erreichen sofort erstellte RPOs, wenn sie SnapMirror für eine synchrone Replizierung konfigurieren. Neben der Replizierung ist die Konsistenz auf Betriebssystem- und Applikationsebene entscheidend.

Larry: NetApp sorgt mit einer Reihe von Komponenten für eine konsistente Replizierung, sowohl für die VMs als auch für Microsoft Applikationen (Exchange, SQL Server und SharePoint Server). Beachten Sie im Hinblick auf VMs und Applikationen unbedingt, dass es nicht ausreicht, die Daten in regelmäßigen Abständen zu replizieren. Sie müssen in einem Zustand sein, der mit den Applikationen konsistent ist und aus dem jede Komponente neu gestartet werden kann. Den gesamten Ansatz haben wir in einem kürzlich erschienenen technischen Bericht eingehend erläutert. Wen hat diesen Bericht gegengelesen, damit auch alle Informationen zu VMware stimmen.

Die VMs befinden sich in gemeinsam genutzten Datenspeichern, entweder VMFS (FC- oder iSCSI-LUNs) oder NFS. NetApp SnapManager für virtuelle Infrastrukturen bietet konsistente Snapshot-Kopien und Replizierung für VM-Daten.

Ein wichtiges Design-Element besteht darin, dass wir die Applikationsdaten getrennt von den VM-Datenspeichern im physischen Modus in RDM-LUNs (iSCSI oder FC) speichern. So können wir mit den NetApp SnapManager Produkten für jede Applikation konsistente Recovery-Punkte erstellen oder unterschiedliche Replizierungspläne für die einzelnen Applikationen verwenden. Durch die Erstellung unterschiedlich vieler Recovery-Punkte sind wir in der Lage, verschiedene RPOs einzurichten.

 

Replizierungsarchitektur

Abb. 2) Replizierungsarchitektur

TOT: Wir haben viel Zeit investiert, um Applikationen von verschiedenen Recovery-Punkten ausgehend neu starten zu können. Können Sie unseren Lesern Näheres dazu sagen?


Larry: NetApp SnapManager Produkte für SQL Server, Exchange und SharePoint erhöhen die Flexibilität, da mehrere Recovery-Punkte für die Replizierung auf dem Recovery-Standort erstellt und überprüft werden können. Die SnapManager Applikationen erstellen vollständige Backups, die auf Applikationskonsistenz überprüft werden, und häufigere Backups, die nur die inkrementellen Protokolle mit den zwischen den vollständigen Backups entstandenen Änderungen enthalten. Diese inkrementellen Backups werden als FRP-Backups (Frequent Recovery Point, häufige Recovery-Punkte) bezeichnet. Durch die Anpassung des Zeitraums zwischen FRP-Backups kann der gewünschte RPO für jede einzelne Applikation flexibel festgelegt werden.

Falls in den wiederhergestellten Applikationsdaten am Recovery-Standort Fehler auftreten, können diese Applikationen einzeln auf jeden beliebigen Recovery-Punkt zurückgesetzt werden. In diesem Fall kann SnapManager sämtliche nicht festgeschriebene Datenbankprotokolle verlängern, um den Verlust neuer Daten zu verhindern, die nach dem Failover am Recovery-Standort geschrieben wurden.

Mit SRM lassen sich benutzerdefinierte Befehle in Ihren Recovery-Plan einfügen. Wir nutzen diese Funktion, um mittels eines Befehls im Recovery-Plan SnapDrive so zu konfigurieren, dass am DR-Standort ausgeführte VMs den gesamten Verlauf der Backups, die vom Produktionsstandort repliziert wurden, anzeigen. Wer Zugriff auf NetApp NOW (NetApp on the Web) hat, erfährt in KB56952 alle Einzelheiten zu diesem Prozess.

TOT: Könnte einer von Ihnen die Bedeutung von Active Directory in einer SRM-Umgebung erläutern?


Wen: Die korrekte Funktionsweise von Microsoft Applikationen hängt stark von Active Directory und DNS ab. Die richtige Konfiguration am DR-Standort ist daher entscheidend. Wenn Sie DR-Tests durchführen, müssen Sie sicherstellen, dass auch im isolierten Testnetzwerk ein ordnungsgemäß konfigurierter und aktueller Active Directory-Server vorhanden ist. Bei einem Failback vom Recovery-Standort zum Primärstandort müssen Sie ebenfalls für einen korrekten Umgang mit Active Directory-/DNS-Servern sorgen. Versäumen Sie dies, kann es zu Schwierigkeiten beim Rollback von USNs (Update Sequence Number) und Beschädigungen an der Active Directory-Datenbank kommen. Diese Themen sind im Microsoft Knowledge Base-Artikel 875495 beschrieben.

Am einfachsten überprüfen Sie, ob Active Directory am Recovery-Standort korrekt ist, indem Sie am Recovery-Standort mindestens einen Active Directory-Server verwenden, der mit dem Primärstandort synchronisiert wird.

Zum Testen des DR klonen Sie diesen AD-Server unmittelbar bevor Sie den Test durchführen. Stellen Sie nach dem Klonen und vor dem Hochfahren der VM sicher, dass der geklonte AD-Server nur mit dem DR-Testnetzwerk verbunden ist. Nachdem die AD-VM im Testnetzwerk hochgefahren wurde, müssen fünf FSMO-Funktionen (Flexible Single Master Operation) in der Active Directory-Gesamtstruktur gemäß Microsoft Knowledge Base-Artikel 255504 übertragen werden.

Tritt ein tatsächlicher Failover auf, ist dieser Klonprozess nicht nötig, jedoch müssen die FSMO-Funktionen manuell übertragen werden. Nach dem Disaster Recovery und vor dem Failback müssen Sie – unabhängig von der Ursache des Verlusts – die Active Directory-Dienste am Originalstandort neu einrichten. Dazu können Sie die AD-Server an diesem Standort wiederherstellen und sie zu einer erneuten Synchronisierung mit den AD-Servern am Recovery-Standort zwingen oder neue AD-Server einrichten.

Diese Aktionen sind alle im Artikel NetApp TR-3822 näher beschrieben, den Larry bereits erwähnt hat.

TOT: Könnten Sie beide abschließend etwas zu den Methoden sagen, die für Failbacks zum Originalstandort zur Verfügung stehen?


Wen: Wie bereits erwähnt, sollten Sie Active Directory einrichten, sobald Ihr Originalstandort bereit ist. In SRM sind Umkehrung und Failback zwar noch nicht voll automatisiert, aber wir empfehlen den Einsatz von SRM, um die Software so zu konfigurieren, dass der Failback in umgekehrter Richtung erfolgt.

Larry: Für den Failback müssen Sie die Daten zwischen dem Recovery- und dem Originalstandort synchronisieren. SnapMirror Beziehungen können leicht umgekehrt und erneut synchronisiert werden. Die Neusynchronisierung hängt vom Problem ab, das aufgetreten ist. Wenn der Originalspeicher nicht zerstört wurde, muss SnapMirror nur das Delta replizieren, nämlich die Änderungen, die hinzugekommen sind, als der Originalstandort offline war. Andernfalls ist eine vollständige Neusynchronisierung notwendig. In beiden Fällen verringern NetApp Deduplizierung und SnapMirror Komprimierung die Beeinträchtigung des WAN. Die Deduplizierung reduziert das Gesamtdatenvolumen in Ihrer VMware-Umgebung. Sie beseitigt die Duplizierung, die infolge einer sehr großen Anzahl an Kopien derselben Gastbetriebssysteme auftritt. Die Komprimierung stellt sicher, dass alle Daten, die über das WAN übertragen werden, möglichst wenig Bandbreite benötigen.

Wir hoffen, dass diese Zusammenfassung der Diskussion für Sie hilfreich ist, und freuen uns auf Ihr Feedback zu diesem Artikel. Die Einzelheiten zu den besprochenen Themen finden Sie im Artikel TR-3822.

Community Center
 Möchten Sie sich an der Diskussion über Disaster Recovery mit SRM und NetApp beteiligen?

Stellen Sie Fragen, tauschen Sie Ideen aus und äußern Sie Ihre Ansichten online in den NetApp Communities.


Wen Yu

Wen Yu
Senior Technical Alliance Manager
VMware

Wen ist seit über fünf Jahren für VMware tätig. Er unterstützt und befürwortet Virtualisierungsprodukte für unterbrechungsfreie Verfügbarkeit, Disaster Recovery und Desktops. Derzeit ist er Mitglied des Infrastructure Alliance Technology Teams.

Larry Touchette

Larry Touchette
Technical Marketing Engineer
NetApp

Larry ist seit neun Jahren bei NetApp. Er unterstützt, implementiert und entwirft NetApp Storage- und Disaster Recovery-Lösungen. Derzeit gehört er dem NetApp Server Virtualization Technical Marketing Team an.

Weitere Infos