NetApp Tech OnTap
     

VMware Site Recovery Manager
für automatisiertes Disaster Recovery

Die Aussicht auf die Durchführung einer vollständigen Standortwiederherstellung nach einem Ausfall kann durchaus beängstigend sein und wenn dies überdies in einer Umgebung mit virtueller Infrastruktur von statten gehen soll, gestaltet sich diese Aufgabe noch schwieriger. VMware Site Recovery Manager (SRM) wurde mit dem Ziel entwickelt, das Disaster Recovery (DR) für VMware Infrastrukturen zu vereinfachen und zu beschleunigen. Darüber hinaus lassen sich Disaster Recovery-Pläne ohne Ausfallzeiten testen, um das einwandfreie Funktionieren des DR-Plans bereits vor Eintreten des Ernstfall sicherstellen zu können.

SRM bietet automatisiertes Failover der virtuellen Infrastruktur für virtuelle Maschinen (VMs) und Server; dabei werden bestehende Replizierungsfähigkeiten der Storage-Anbieter, sowie beispielsweise die NetApp SnapMirror Technologie, genutzt, anstatt eigene Mechanismen für die Replizierung der VM-Daten an den DR-Standort anzuwenden. NetApp hat in enger Kooperation mit VMware daran gearbeitet, die erweiterten Funktionen von SnapMirror und anderer NetApp Technologien voll für SRM verfügbar zu machen.

In diesem Artikel möchte ich die Herausforderungen der Disaster Recovery-Planung erläutern und erklären, wie sich die automatisierte Wiederherstellung für virtuelle Infrastrukturen mittels VMware SRM in Verbindung mit NetApp Storage-Systemen erheblich vereinfachen lässt.

Disaster Recovery-Planung

Die Planung und Ausführung sind die heikelsten Aspekte eines DR-Szenarios. Ausfälle, die die Datenverfügbarkeit gefährden können, treten aus verschiedenen Gründen auf und können von der Natur, menschlichem Versagen oder Computern verursacht werden. Was sind nun die häufigsten Probleme, die eine effiziente DR-Planung verhindern:

Es liegt keinerlei DR-Plan vor. In manchen Fällen sind die Kosten und die Komplexität des DR angesichts der personellen und finanziellen Ressourcen einfach übermächtig. Geplante Ausfallzeiten sind nicht möglich und die Erstellung sowie das unerlässliche Testen eines echten DR-Plans werden immer wieder verschoben.

Recovery-Zeitvorgaben (RTO) und Recovery-Punktvorgaben (RPO) können nicht erfüllt werden.
Viele unter Ihnen können die für die Aufrechterhaltung der Geschäftstätigkeit notwendigen RPO- und RTO-Vorgaben nicht einhalten, da Ihr Plan auf kostspieliger Infrastruktur, zeitaufwendigen Restores bzw. vollständigen Systemneuinstallationen beruht. Die Ressourcen, die aufgewendet werden müssten, um einen Testplan zu implementieren und durchzuspielen, sind, insbesondere wenn in Ihrem Unternehmen noch nie ein ernsthafter Ausfall aufgetreten ist, zu hoch.

Administration vs. RPO/RTO.
Das Failover von Geschäftsoperationen zur Wiederherstellung nach einem Ausfall erfordert zahlreiche manuelle und zeitintensive Schritte. Oftmals sind es die zu durchlaufenden Prozesse, die die realen Recovery-Zeitvorgaben, die mittels DR erreicht werden könnten, beeinträchtigen, obwohl eigene Scripts geschrieben und angewendet werden, um manche dieser Prozesse zu vereinfachen. Sehen wir uns den Ablauf eines typischen DR-Szenarios Schritt-für-Schritt an:

  1. Auftreten einer Situation, die das Failover auf einen DR-Standort erforderlich macht. (Dies kann z.B. ein Stromausfall sein, den die Geschäftstätigkeit ohne Failover nicht überdauern kann oder ein Ausfall, der Datenverlust bzw. Equipmentverlust am produktiven Standort zur Folge hat).
  2. Das DR-Team unternimmt die notwendigen Schritte, um den Ausfall zu bestätigen und trifft die Entscheidung zum Failover.
  3. Wir nehmen an, die notwendigen Tests zur Bestätigung der erfolgreichen Datenreplizierung wurden durchgeführt und der Recovery-Standort ist einsatzbereit:
    • Replizierter Storage muss an die ESX Systeme am Recovery-Standort weitergegeben werden.
    • Die Systeme müssen mit dem Storage verbunden werden.
    • Die korrekten virtuellen Maschinen müssen dem Inventory der ESX Systeme hinzugefügt werden.
    • Wenn sich Recovery-Standort und produktiver Standort nicht auf demselben Netzwerksegment befinden, kann eine Neukonfiguration der virtuellen Maschinen für das neue Netzwerk notwendig sein.
    • IT-Mitarbeiter müssen sicherstellen, dass die Umgebung ordnungsgemäß erstellt wurde, wobei die Systeme und Dienste in der richtigen Reihenfolge verfügbar gemacht werden müssen, um Benennungs- /IP-Konflikte zu verhindern.
  4. Sobald die Recovery-Umgebung fertig gestellt ist, erfolgt die Wiederaufnahme der Geschäftstätigkeit über das Equipment am Recovery-Standort. Nach einer gewissen Zeit ist der produktive Standort in der Regel wieder verfügbar, verlorenes Equipment wurde ersetzt.
  5. Wurden während des Zeitraums der Verlagerung der Geschäftstätigkeit auf den Recovery-Standort Daten verändert, müssen diese möglicherweise wieder an den Primärstandort repliziert werden (die Replizierung muss dazu umgekehrt werden).
  6. Der unter Schritt 3 beschriebene Vorgang muss erneut durchgeführt werden.
  7. Sobald die Produktionsumgebung wieder hergestellt ist, müssen auch das ursprüngliche Replikationsschema und die Replikationsbeziehungen wieder hergestellt werden (vom Produktionsstandort auf den DR-Standort).

Disaster Recovery-Prozesse sind in der Regel langwierig, zeitaufwendig und fehleranfällig. Nach Wiederherstellung müssen dieselben Prozesse am Produktionsstandort wiederholt werden, was wiederum ähnliche Probleme hervorruft. Dennoch ist eine Disaster Recovery-Lösung für jedes Business eine lebenswichtige Absicherung. Wollen Sie sich auf Ihre Lösung verlassen können, sind regelmäßige Tests Ihres DR-Plans unerlässlich.

Ein solcher Test umfasst typischerweise die planmäßige Ausführung der oben angeführten Schritte 1-7. Dieses Vorgehen kann (aufgrund Personalaufwand und Ausfallzeit) kostspielig sein und den normalen IT-Betrieb stören. Da physische Umgebungen begrenzt sind und beim Testen von DR-Plänen diverse Schwierigkeiten auftreten, können letztere an den meisten Standorten im besten Fall mehrmals im Jahr getestet werden, mancherorts ist ein Test unter realistischen Bedingungen gar nicht möglich. Mittels SRM kann der DR-Prozess automatisiert werden, womit die Risiken der Gefährdung der Wiederherstellung durch Bedienfehler minimiert werden.

SRM Grundlagen

Der schwierigste und zeitaufwendigste Teil des DR Failovers in einer VMware Umgebung ist die Ausführung der Schritte, die notwendig sind, um die virtuellen Maschinen mit einem Recovery-Standort zu verbinden, zu inventarisieren, neu zu konfigurieren und hochzufahren. VMware hat diese Probleme mit der Einführung von Site Recovery Manager gelöst: die Verwaltung des gesamten DR-Prozesses wird vereinfacht.
SRM bietet drei Hauptfunktionen:

  • Feststellung/Konfiguration
  • Failover
  • Test

Der kritischste Teil der DR ist die Planung der Reaktion auf verschiedene Szenarien. Mit SRM kann die Disaster Response vorprogrammiert werden; dies ist eines der leistungsfähigsten Features dieser Lösung. Das Hochfahren oder Abschalten von hunderten von Servern kann insbesondere in einer Krisensituation eine enorme Herausforderung sein, vom online bringen von Systemen in einer bestimmten Reihenfolge gar nicht zu sprechen.

Der Recovery-Plan, den Sie in der Einrichtungsphase der SRM Konfiguration erstellen, ermöglicht eine Vor-Konfiguration des gesamten Plans. Die Planerstellung mittels SRM erfolgt dank der eingebauten Erkennungsfunktionen und der engen Integration mit Virtual Center innerhalb kurzer Zeit. Nach Erstellung des Plans, kann dieser fehlerfrei und mit minimalem Eingreifen des Users ausgeführt werden. (Dazu muss bei Eintreten des Ausfalls lediglich der Recovery Prozess veranlasst werden). Die Erstellung eines solchen Plans mit traditionellen DR Methoden kann Jahre oder sogar Monate in Anspruch nehmen und umfasst viele fehleranfällige manuelle Schritte.

Die automatisierte Testlösung von SRM bietet DR-Tests ohne Störung der laufenden Replizierung und ohne Beeinträchtigung der SLAs, selbst wenn diverse virtuelle Maschinen gebootet und Datensets getestet werden. Desweiteren können replizierte Datensets geklont und für Entwicklungstest etc. verwendet werden.

Wenn Sie die Cloning-Technologie von NetApp in Kombination mit SMR zur Ausführung von VM Operationen verwenden, können Sie einen Standort online bringen und dort Tests durchführen, ohne die Produktion zu beeinträchtigen – all dies kann zentral verwaltet werden und erfordert wenig User-Intervention. Dies ist eine leistungsfähige Möglichkeit, eine Reihe von Tests zur Validierung einer bestimmten Anwendung oder eines Datensets durchzuführen, ohne den produktiven Standort oder die vereinbarten Service Level Agreements zu beeinflussen.

SRM und NetApp Storage

SRM ermöglicht zwei getrennten VMware Umgebungen, dem Primär- und dem Recovery-Standort, miteinander zu kommunizieren. Virtuelle Maschinen am primären Standort können rasch und einfach zu Protection Groups zusammengefasst werden, die über gemeinsame Ressourcen verfügen und gemeinsam wiederhergestellt werden können. Diese Protection Groups werden gemäß Recovery-Plänen am Recovery-Standort konfiguriert.

Traffic über Netzwerk-Switches
Abbildung 1) SnapMirror allein oder in Verbindung mit SMR, ermöglicht das flexible Mirroring von High-End Storage-Konfigurationen High-Performance Plattformen, FCP Disks, FC SAN Konfigurationen) auf günstigere Lösungen (günstigere Storage-Plattformen, SATA Disks, iSCSI).

In einer NetApp Storage-Umgebung kann SnapMirror so konfiguriert werden, dass er virtuelle Maschinen von lokalem NetApp Storage auf ein remote System repliziert, wodurch read-only Mirrors für remote Locations geschaffen werden. Ein Vorteil von SnapMirror ist die Möglichkeit der flexiblen Storage-Konfiguration für den Recovery-Standort, was die Storage-Kosten für den Recovery-Standort erheblich reduziert. Viele Replizierungslösungen erfordern eine identische Storage-Konfiguration an beiden Locations. Mit SnapMirror, können Sie High-End- auf Low-End-Plattformen spiegeln, FC Disks auf SATA Disks und Fibre Channel SAN auf iSCSI, unter der Vorraussetzung, dass an beiden Standorten NetApp Storage zum Einsatz kommt.

VMware SRM erkennt diese Beziehungen und ermöglicht die Programmierung einer Disaster Response, unter anderem das Promoten von Mirrors zur Aufhebung des Schreibschutzes, das Mounten von Filesystemen und das Booten von Systemen.

Wird der DR-Plan in einer NetApp Storage-Umgebung ausgeführt, führt SRM folgende Aktionen aus:

  • NetApp SnapMirror Beziehungen stilllegen und unterbrechen
  • LUN Mapping auf bestehende igroups (igroups sind Tabellen mit internationalen Port-Bezeichnungen (WWPNs), von Hosts, die Zugriff auf LUNs haben)
  • DR ESX Hosts triggern, um Rescan und Storage-Erkennung auszulösen
  • Virtuelle Maschinen gemäß Definition für das Netzwerk am DR-Standort konfigurieren
  • Virtuelle Maschinen in der im DR Plan festgelegten Reihenfolge hochfahren

Wird der DR-Plan in einer NetApp Umgebung ausgeführt, führt SRM folgende Aktionen aus:

  • FlexClone Volumes der FlexVol Volumes am DR Storage-System erstellen
  • Mapping der innerhalb dieser FlexVol Volumes vorhandenen LUNs auf bestehende igroups
  • DR ESX Hosts triggern, um Rescan und Storage-Erkennung auszulösen
  • Die VM Netzwerkadapter mit einem privaten Test-Netzwerk verbinden
  • Virtuelle Maschinen gemäß Definition für das Netzwerk am DR-Standort konfigurieren
  • Virtuelle Maschinen in der im DR Plan festgelegten Reihenfolge hochfahren

Fazit

Dank Automatisierung der ressourcenintensiven bzw. manuellen Aufgaben der DR-Planung, des Failover und des Testens, wie beispielsweise das Abbilden der virtuellen Maschinen auf Storage, das Booten in der richtigen Reihenfolge und die IP- Adressierung und die Verwaltung der Benennungsschemata, vereinfacht SRM das Disaster Recovery in virtuellen Umgebungen ungemein. Die inkrementellen Kosten für den Schutz einer VM gehen aus einer operationellen Perspektive gegen Null. Die einzigen echten Kosten werden von Festplattenplatz am Zielstandort und der Bandbreite, die für die Datenaustauschrate dieser VM notwendig ist, verursacht. Virtuelle Server und Storage können mit minimalem administrativem Aufwand verbunden werden. Ihr Disaster Recovery-Plan und die Wiederherstellungsprozesse können in kürzester Zeit und mit minimalen Ressourcen erstellt werden.

Haben Sie etwas zu DR für VMware Umgebungen oder Site Recovery Manager zu sagen?

Stellen Sie Fragen, tauschen Sie Ideen aus und teilen Sie Ihre Meinung mit der NetApp Online Community!

Darrin Chapman

Darrin Chapman
Datenschutzexperte und Technischer Marketing Manager
NetApp

Darrin Chapman ist Ihr Ansprechpartner für beinahe alle Fragen und Probleme rund um Disaster Recovery oder Backup/Recovery bei NetApp. Er hat an fast allen seit 2002 erstellten NetApp Best Practices Guides zum Thema Datenschutz mitgearbeitet und entwickelt in seiner verbleibenden Zeit, Schulungen für Kunden und NetApp Techniker. Nach seiner Ausbildung als Elektroingenieur war Darrin einige Jahre im Bereich Systemarchitektur bei AT&T, Nortel und EMC tätig.

Explore