NetApp Tech OnTap
     

Integrierte Datensicherung von NetApp:
Die richtige Auswahl für die Datensicherung

Einer der Vorteile von NetApp Storage besteht darin, dass alle Funktionen zur Sicherung geschäftskritischer Daten eng in die NetApp Hardware und mit Data ONTAP integriert sind. In der Regel brauchen Sie nichts weiter als einen Lizenzschlüssel. Sie müssen keine spezielle Anwendung kaufen oder komplizierte Software-Installationen durchführen, um Funktionen hinzuzufügen. Außerdem profitieren alle unsere Datensicherheitslösungen von integrierten Management-Fähigkeiten.

Der herkömmliche Ansatz für die Datensicherung führt zu mehr Komplexität und zu höheren Kosten.

Abbildung 1) Der herkömmliche Ansatz für die Datensicherung führt zu mehr Komplexität und zu höheren Kosten.

Die Grundlagen der integrierten Datensicherung von NetApp wurden in einem früheren Tech OnTap Artikel erläutert. In diesem Artikel möchte ich näher auf einige Details unserer Replizierungstechnologie eingehen. Für die wichtigsten Elemente der Datensicherung von NetApp wie Volume SnapMirror, qtree SnapMirror, SnapVault und MetroCluster wird entweder auf die Spiegelung oder auf die Replizierung zurückgegriffen. Wenn Sie ein besseres Verständnis für diese Technologien entwickeln und verstehen, wie sie sich voneinander unterscheiden, wird Ihnen die Auswahl der für Sie besten Datensicherungsstrategie leichter fallen. Zunächst gehe ich auf die verschiedenen Technologien ein und gebe dann einige Hilfestellungen für die Auswahl der richtigen Optionen für Ihre Anforderungen.

NetApp Replizierungsoptionen

In den vergangenen Jahren wurden SnapMirror, SnapVault und MetroCluster ausführlich in Tech OnTap behandelt. Diese Produkte verfügen jedoch über einige Kernfunktionen, die sich in wichtigen Punkten voneinander unterscheiden und nach meiner Kenntnis in noch keinem Artikel umfassend erläutert wurden. Als Erstes gehe ich auf SnapMirror ein und erkläre anschließend im Zusammenhang damit die anderen beiden Produkte. (Auch wenn Ihnen die SnapMirror Erläuterung etwas lang erscheint, können Sie beruhigt sein. Um SnapVault und MetroCluster zu verstehen, müssen Sie keine weitere so umfangreiche Erläuterung lesen.) In mehreren vergleichenden Tabellen finden Sie außerdem Antworten auf eventuelle Fragen.

SnapMirror
Sie wissen höchstwahrscheinlich, dass SnapMirror in erster Linie dazu dient, Mirrors für Disaster Recoverys an Remote-Standorten zu erstellen. Weniger bekannt ist die Tatsache, dass es zwei SnapMirror Betriebsarten gibt.

Volume SnapMirror wird auf der physischen Blockebene ausgeführt. Mithilfe dieser Technologie werden der gesamte Inhalt eines Volume und alle Volume-Attribute des Quell-Volume (primäres Volume) exakt auf dem Ziel-Volume (sekundäres Volume) repliziert. Infolgedessen muss auf dem Ziel-Storage-System dieselbe Version von Data ONTAP wie auf dem Quellsystem oder eine höhere Version ausgeführt werden. Wenn Deduplizierung oder NetApp Datenkomprimierung (hinzugefügt in Data ONTAP 8.0.1) auf dem Primärsystem ausgeführt wird, übernimmt das Ziel-Volume diese Einsparungen, da das Volume identisch ist. Außerdem wirken sich die Einsparungen auch auf das WAN aus.

Qtree SnapMirror repliziert einzelne qtrees. Da qtrees Teilmengen eines Volume sind, wird qtree SnapMirror auf der logischen Ebene ausgeführt. Ein qtree kann nicht einfach getreu repliziert werden, da einige der erforderlich Informationen auf Volume-Ebene für die Organisation des qtree im Zielsystem fehlen würden.

Da die Replizierung auf der logischen Ebene stattfindet, sind im Vergleich zu Volume SnapMirror einige wichtige Unterschiede zu beachten. Der erste Unterschied besteht darin, dass qtree SnapMirror keine Einsparungen durch Deduplizierung übernimmt. Wenn Sie den Kontext des Quell- und Zielsystems betrachten, macht dies auch durchaus Sinn. Auf dem Quellsystem kann ein qtree einen deduplizierten Datenblock enthalten, der nur ein Verweis auf einen Datenblock außerhalb des qtree ist. Dieser Datenblock ist demzufolge auf dem Zielsystem nicht vorhanden. Deshalb muss er mit dem qtree anstatt mit dem Verweis repliziert werden. Bei diesem Szenario ist qtree SnapMirror weniger netzwerk- und kapazitätseffizient als Volume SnapMirror.

qtree SnapMirror repliziert standardmäßig nur die zuletzt erstellte Snapshot Kopie. Dadurch ergibt sich eine asymmetrische Anzahl an Snapshot Kopien am Quell- und Zielspeicherort. (Volume SnapMirror verfügt definitionsgemäß über dieselben Snapshot Kopien am Quell- und Zielspeicherort.) Qtree SnapMirror behält nur die gemeinsamen Snapshot Kopien, die notwendig sind, um Replizierungs-Updates durchzuführen. Das bedeutet, dass qtree SnapMirror Snapshot Daten nicht aufbewahren kann.

Beide Versionen von SnapMirror beginnen mit einer Basiskopie, in der alle Daten des Volume oder des qtree vom Quellspeicherort am Zielspeicherort repliziert werden. Wenn die Basiskopie abgeschlossen ist, wird eine regelmäßige Replizierung durchgeführt. Volume SnapMirror unterstützt die asynchrone, halbsynchrone und synchrone Replizierung. Qtree SnapMirror unterstützt nur die asynchrone Replizierung.

Im asynchronen Modus werden regelmäßig Snapshot Kopien des Volume oder qtree am Quellspeicherort erstellt. Diese Methode ist im Hinblick auf den Overhead des Storage-Systems und die Netzwerkbandbreite sehr effizient, da nur Datenblöcke an den Zielspeicherort übertragen werden, die seit der letzten Replizierung geändert oder neu erstellt wurden.

Im synchronen Modus werden Updates nicht anhand eines vorab festgelegten Zeitplans vom Quell- zum Zielspeicherort gesendet, sondern sobald sie auftreten. Dadurch werden Daten, die auf das Quellsystem geschrieben werden, auf dem Zielsystem geschützt, selbst wenn das gesamte Quellsystem ausfällt. Dank der NVLOG- und Konsistenzpunkt-Weiterleitung (Consistency Point, CP) wird das Zielsystem stets auf dem neuesten Stand gehalten. Mithilfe der NVLOG-Weiterleitung werden Daten des Protokolls für Schreibvorgänge, das normalerweise im Cache des NVRAM des NetApp Storage gespeichert wird, mit dem Zielsystem synchronisiert. Mithilfe der Konsistenzpunktweiterleitung werden Images des Filesystems auf der Festplatte synchronisiert.

Der halbsynchrone Modus unterscheidet sich in zweifacher Weise vom synchronen Modus. Schreibvorgänge auf dem Quellsystem müssen nicht mehr auf die Bestätigung des Zielsystems warten, bevor sie durchgeführt und bestätigt werden. Darüber hinaus wird keine NVLOG-Weiterleitung verwendet. Durch diese beiden Unterscheidungen werden die Reaktionszeiten von Applikationen verkürzt und der Recovery-Zeitpunkt (RPO) wird nur minimal beeinträchtigt.

Weitere Informationen zu sämtlichen Betriebsarten finden Sie in TR-3446: SnapMirror Async Overview and Best Practices Guide und in TR-3326: SnapMirror Sync and SnapMirror Semi-Sync Overview and Design Considerations.

SnapMirror

Abbildung 2) SnapMirror

Abschließend möchte ich Sie noch auf einen der wichtigsten Aspekte von SnapMirror hinweisen: die Zielsysteme von Volume SnapMirror und qtree SnapMirror sind beschreibbar. In anderen Worten bedeutet das, dass Sie bei einem Ausfall der Quell- bzw. Primärsysteme ein Failover der Operationen durchführen und das Zielsystem beschreiben können. Wenn der Ausfall behoben ist, können Sie eine Failback-Resynchronisierung durchführen, um Deltawertveränderungen zurück auf das Quellsystem zu kopieren, und den normalen Betrieb wieder aufnehmen. Diese Fähigkeit ist ein zentrales Unterscheidungsmerkmal gegenüber SnapVault.

SnapVault
SnapVault dient hauptsächlich dem Disk-to-Disk Backup. Ähnlich wie der asynchrone Modus von SnapMirror nutzt SnapVault die NetApp Snapshot Technologie, um Systeme auf Blockebene zu sichern und wiederherzustellen. SnapVault erkennt auf ähnliche Weise nur die geänderten Blöcke auf einem System (nicht die geänderten Dateien) und kopiert sie zum Sekundär-Storage. Somit wird nicht nur die Performance verbessert, da die zu übertragende Datenmenge bei Backup- und Restore-Prozessen begrenzt ist, sondern es wird auch weniger Kapazität für das Speichern von Backups benötigt. Dadurch können Sie bei Bedarf häufiger Backups durchführen.

Im Hinblick auf die grundlegende Funktionsweise sind sich SnapVault und qtree SnapMirror sehr ähnlich, da auch SnapVault Replizierungen auf der logischen qtree Ebene durchführt. Ähnlich wie bei qtree SnapMirror handelt es sich dabei also nicht um eine getreue Kopie des Quell-Volume und der Zustand der Deduplizierung und Datenkomprimierung des Quell-Volume wird nicht übernommen. (Sie können wie bei jedem anderen NetApp Volume eine Deduplizierung bzw. Datenkomprimierung auf dem Ziel-Volume ausführen.)

Darüber hinaus ist ein SnapVault Volume im Gegensatz zu SnapMirror nicht beschreibbar (für ein sofortiges Recovery). Dies kann dazu führen, dass die Recovery-Zeiten von SnapVault wesentlich länger als die von SnapMirror sind, wenn Sie sehr viele Daten über ein Netzwerk übertragen. Wenn Sie auch SnapMirror besitzen, können Sie SnapVault Volumes beschreiben. Denken Sie jedoch daran, dass SnapVault unidirektional ist und keine Funktion zur Failback-Resynchronisierung hat, um das Quell-Volume auf den neuesten Stand zu bringen.

SnapVault. Open Systems SnapVault (nicht Gegenstand dieses Artikels) ermöglicht die Integration von Storage-Lösungen anderer Hersteller in das Backup Framework.

Abbildung 3) SnapVault. Open Systems SnapVault (nicht Gegenstand dieses Artikels) ermöglicht die Integration von Storage-Lösungen anderer Hersteller in das Backup Framework.

Da SnapVault auf der logischen Ebene ausgeführt wird, gehören die Snapshot Aufbewahrung und die Snapshot Zusammenführung zu den Geheimwaffen von SnapVault. Sie können auf einem SnapVault Volume so viele Snapshot Kopien aufbewahren, wie Sie möchten (max. 255 pro Volume), und diese automatisch entsprechend einem von Ihnen definierten Zeitplan verfallen lassen. Mithilfe der Zusammenführung können Sie mehrere SnapVault Prozesse von mehreren Quell-Volumes auf einem einzigen Ziel-Volume ausführen und anschließend eine einzelne Snapshot Kopie auf dem Ziel-Volume erstellen, in der alle Quell-Volumes enthalten sind. Dadurch entstehen weniger Snapshot Kopien. Wenn Sie dann die Deduplizierung auf dem Zielsystem ausführen, können Sie identische Datenblöcke in allen qtrees des Backup deduplizieren.

Weitere Informationen zu allen Aspekten von SnapVault finden Sie im SnapVault Best Practices Guide.

Tabelle 1) Vergleich von SnapMirror und SnapVault

Feature

Volume SnapMirror

Qtree SnapMirror

SnapVault

Replizierungstyp

Physisch

Logisch

Logisch

Replizierungsnetzwerk

FC oder IP

FC oder IP

Nur IP

Mehrere Pfade für die Replizierung

Ja

Ja

Nein

Data ONTAP versionsabhängig

Ja

Nein

Nein

Netzwerkkomprimierung

Ja

Ja (mit Genehmigung)

Nein

RPO (Den Verlust wie vieler Daten kann ich verkraften?)

1 Minute1

1 Minute2

1 Stunde

Failover-Funktion

Ja

Ja

Ja, in Verbindung mit SnapMirror

Snapshot Aufbewahrung für Backups

Nein

Möglich aber langwierig

Ja

Snapshot Zusammenführung

k. A.

Nein

Ja

Failback-Resynchronisierung

Ja

Ja

Nein

Deduplizierung

Zielspeicherort übernimmt Einsparungen durch Deduplizierung und Netzwerkeinsparungen

Zielspeicherort übernimmt Einsparungen durch Deduplizierung nicht

SnapVault und Deduplizierung sind integriert, Zielspeicherort übernimmt Einsparungen durch Deduplizierung nicht

 

1Updates in Abständen von einer Minute sind zwar möglich, werden jedoch nicht von NetApp empfohlen. Verwenden Sie SnapMirror Semi-Sync für einen kurzfristigen RPO (< drei Minuten).

2Updates in Abständen von einer Minute sind zwar möglich, werden jedoch nicht von NetApp empfohlen. SnapMirror Semi-Sync kann nicht mit eigenständigen qtrees verwendet werden.

MetroCluster
MetroCluster ist die NetApp Lösung für kontinuierliche Datenverfügbarkeit. Diese Lösung ist nur entfernt mit SnapMirror und SnapVault verwandt, da ihre Funktionsweise sehr verschieden ist. Ihr Konzept ist jedoch leicht zu verstehen. Wie der Name bereits erkennen lässt, bietet MetroCluster Stretch Clustering. Mit dieser Lösung können die Knoten eines standardmäßigen NetApp HA-Paares einen Abstand von bis zu 100 km haben. MetroCluster verwendet hierzu eine komplett gespiegelte Aktiv/Aktiv-Konfiguration, die jeweils eine vollständige Kopie aller gespiegelten Daten auf beiden Seiten des Clusters aufbewahrt. Diese Kopien heißen Plexe und werden kontinuierlich und synchron aktualisiert, sobald Data ONTAP Daten auf die Festplatte schreibt.

Jeder Controller besitzt Storage Volumes (Plexe) auf beiden Knoten. Dadurch wird die Deduplizierung auf beiden Knoten durchgeführt und Leseoperationen können auf beiden Festplatten aufgeteilt werden. Folglich verbessert sich die Lese-Performance um 80 %. Lesen Sie mehr zu MetroCluster in einer kürzlich veröffentlichten Tech OnTap Kundenreferenz oder sehen Sie sich zur Erläuterung ein umfassendes Video an.

Tabelle 2) Vergleich von MetroCluster und SnapMirror Sync

 

SnapMirror Sync

MetroCluster

Replizierungsnetzwerk

IP oder FC

FC

Begrenzung gleichzeitiger Transfers

Ja

Keine Begrenzung

Höchstentfernung

200 km
(> 200 km Semi-Sync)

100 km

Replizierung zwischen HA-Paaren

Ja

Nein

Failover

CLI

CLI (ein Befehl), System Center

Verwendung von Replikat

Ja

 

Unterstützung für Deduplizierung von Primärdaten

 

Ja



Welche Option ist die richtige für mich?

Tabelle 1 und Tabelle 2 im vorherigen Abschnitt sollen Ihnen dabei helfen, die für Ihre spezifischen Bedürfnisse beste Replizierungsoption auszuwählen. Beziehen Sie die folgenden Aspekte in Ihre Überlegungen ein, um die richtige Auswahl im Hinblick auf die zuvor besprochenen Technologien zu treffen. Als Erstes sollten Sie sich natürlich fragen, ob Sie Backup oder DR benötigen.

Backup
In Bezug auf Backup-Lösungen werden die Anforderungen der meisten Anwender durch einen regelmäßigen Snapshot Zeitplan für den Primär-Storage (normalerweise stündlich) eventuell in Verbindung mit der Erstellung einer SnapVault Kopie auf dem Sekundär-Storage (lokal oder remote) über Nacht erfüllt. Die meisten Datei-Restores können anhand von Snapshot Kopien auf dem Primär-Storage durchgeführt werden, während SnapVault Zugriff auf weiter zurückliegende Dateien bietet und umfangreichere Restores ermöglicht, falls es zu schwerwiegenderen Ausfällen kommt.

Sehen Sie sich das Video zu NetApp Syncsort Integrated Backup in der Randleiste an. Diese Technologie vereint für zahlreiche wichtige Applikationsumgebungen die Vorteile des Daten-Managements von Syncsort mit denen der NetApp Replizierung.

DR
Wenn Sie sich vor Standortausfällen schützen und Business Continuity sicherstellen möchten, ist MetroCluster oder SnapMirror die richtige Wahl für Sie. Die beliebteste Alternative hierzu stellt, gemessen an der Anzahl der Implementierungen, Volume SnapMirror mit asynchroner Replizierung dar. Der Grund dafür ist die Einfachheit und das hervorragende Preis-Leistungs-Verhältnis der Lösung in Verbindung mit einer effizienten Nutzung von Storage- und Netzwerkressourcen. NetApp hat sehr viel Arbeit in die Entwicklung von SnapMirror investiert und wertvolle Funktionen wie die Bandbreitendrosselung, die Netzwerkkomprimierung und die Integration mit der SnapManager Produkt-Suite zur Applikationsintegration entwickelt.

Sowohl qtree als auch Volume SnapMirror erreichen Recovery-Zeiten (RTO) von Sekunden bis Minuten und Recovery-Zeitpunkte (RPO) von nur einer Minute (hierzu müssen die Daten im Abstand von einer Minute repliziert werden), auch wenn NetApp in der Regel die asynchrone Replizierung im Abstand von einer Minute nicht empfiehlt. Für Recovery-Zeiten zwischen einer und drei Minuten ist SnapMirror im halbsynchronen Modus die bessere Wahl. (Weitere Informationen zu RPO und RTO finden Sie in der Randleiste.)

Wenn Sie einen ehrgeizigeren RPO benötigen, als mit dem asynchronen Modus von SnapMirror möglich ist, wählen Sie MetroCluster oder SnapMirror im synchronen Modus. Beachten Sie, dass für die Implementierung synchroner Lösungen in der Regel eine viel größere Netzwerkbandbreite und eine spezielle Netzwerkausstattung erforderlich sind. Demzufolge sind diese Lösungen wesentlich kostspieliger.

MetroCluster ist für Entfernungen von bis zu 100 km die bevorzugte Lösung, da sie kontinuierliche Datenverfügbarkeit, automatischen Failover und automatisches Recovery bietet. SnapMirror Sync unterstützt eine Reichweite von bis zu 200 km und SnapMirror Semi-Sync ist für noch größere Entfernungen geeignet. Beide Lösungen sind somit ideal, wenn Sie auf der Suche nach dem geringstmöglichen RPO über eine längere Entfernung sind.

Grenzfälle
Die zuvor skizzierten Beispiele sollten für die meisten Situationen zutreffen, aber es gibt natürlich immer Grenzfälle. Einige Anwender nutzen SnapMirror für Backups, in der Regel um bei Bedarf schnell und einfach ein beschreibbares Backup Volume zu erstellen. Andere wiederum nutzen SnapVault für DR, da sie mit dieser Lösung Wiederherstellungen für beliebige Zeitpunkte vornehmen können. SnapVault Volumes sind, wie zuvor erwähnt, allein mit SnapVault nicht beschreibbar. Sie können nur in Verbindung mit SnapMirror beschreibbar gemacht werden (dies wird nicht in diesem Artikel behandelt).

Erste Schritte

Viele NetApp Anwender implementieren mehrere der in diesem Artikel von mir besprochenen Lösungen, um sowohl Backup- als auch DR-Anforderungen zu erfüllen. In einem relativ üblichen Szenario werden z. B. mithilfe von SnapMirror kritische Volumes an einem Remote-Standort erstellt und mit einem regelmäßigen SnapVault Zeitplan werden Backups an dem Remote-Standort durchgeführt. An einige Standorten wird sogar eine Kombination von MetroCluster, SnapMirror und SnapVault implementiert, um die Datensicherungsanforderungen zu erfüllen.

Abbildung 4) Die integrierten Datensicherungsprodukte von NetApp (inklusive Funktionen, die nicht in diesem Artikel besprochen werden)

Weitere Informationen zu erweiterten Konfigurationen, zu den von mir in diesem Artikel behandelten Themen und Themen, für die ich keinen Platz hatte, wie z. B. die Planung der Datensicherung, finden Sie im NetApp Handbuch zur Datensicherung. Sehen Sie sich auch die anderen Ressourcen an, die ich in diesem Artikel erwähnt habe, um zusätzliche Einzelheiten zu erfahren. NetApp verfügt über eine umfassende Fachkompetenz für Datensicherungslösungen. Fragen Sie Ihre NetApp Community oder Ihr NetApp Team, wenn Sie Unterstützung bei der Entscheidungsfindung benötigen.

NetApp Community
 Ihre Meinung zur integrierten Datensicherung

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

Jason Blosil

Srinath Alapati
Technical Marketing Engineer
NetApp

Srinath Alapati arbeitet seit 2004 für NetApp und ist seit mehr als vier Jahren ein Mitglied der Arbeitsgruppe für Datensicherung. Er verfügt über mehr als zehn Jahre Erfahrung in der IT-Branche, insbesondere im Managen von Servern und Storage-Infrastruktur. Srinath Alapati ist Autor bzw. Mitautor mehrerer technischer Berichte zu SnapMirror, MetroCluster, VMware und Exchange und nimmt als Redner an zahlreichen Fachkonferenzen teil. Er ist außerdem ein Hauptmitglied des Teams für die Disaster Recovery-Implementierung von NetApp IT.

 
Weitere Infos hier
 
TRUSTe
Kontakt   |   Bezugsquelle   |   Feedback   |   Karriere  |   Abonnements   |   Datenschutzrichtlinie   |   © 2011 NetApp