Cybrain - Fotolia

Die richtige Snapshot-Methode wählen

Snapshots und Replikation sind beliebte Data-Protection-Tools, allerdings kann die Suche nach der optimalen Snapshot-Methode anspruchsvoll sein.

IT-Verantwortliche verlassen sich immer mehr auf Snapshots, um ihre Daten in virtuellen Umgebungen zu sichern. In Sekunden stellen Snapshots „eingefrorene“, sekundäre Instanzen der Daten bereit. Diese Instanz kann ins Backup einfließen, repliziert werden oder als Basis für eine andere virtuelle Maschine (VM) genutzt werden.

Trotzdem gibt es zwei Herausforderungen, wenn man Snapshots für die Data Protection nutzen will. Zunächst ist ein Snapshot eben nur eine Instanz – eine Momentaufnahme – und keine vollständige Kopie. Des Weiteren können Snapshots in der VM, im Hypervisor, in der Backup-Software oder im Storage-Array implementiert sein. Es kann verwirrend sein, wenn man entscheiden muss, an welcher Stelle der Snapshot erfolgen und verwaltet werden soll. Hier finden sich einige Hinweise, wie man die Schwächen der Snapshots bewältigt und wie IT-Manager die richtige Snapshot-Methode für ihr Rechenzentrum bestimmen.

Was ist ein Snapshot

Snapshots ziehen Vorteil daraus, wie Daten in einem Storage-System organisiert sind, um eine Point-in-Time-Instanz des originalen Datensatzes anzulegen. Die meisten File- und Storage-Systeme haben eine Zwei-Tier-Methode für ihre Daten. Der erster Tier sind Metadaten. Dieser Tier ist ein kleiner Katalog, der auf den zweiten Tier verweist – auf den aktuellen Standort der Daten auf der Disk.

Anstatt alle physischen Daten in den Tier 2 zu kopieren, erstellen Snapshots nur eine Kopie der Metadaten im Tier 1. Diese Kopie wird sofort angelegt und nimmt nur wenig zusätzlichen Speicherplatz ein. Danach werden die Blöcke, die Teile des Snapshots sind, als read-only, also als schreibgeschützt markiert. Daraufhin hält der Snapshot-Manager zwei Kopien der Metadaten: eine aktive Kopie, die von der Produktionsapplikation aktualisiert wird, und eine statische Kopie, die von anderen Anwendungen genutzt wird, wie vom Backup oder von Replikationsapplikationen. Die Anzahl der Metadatenkopien wächst mit der Anzahl aktiver Snapshots.

Ein entscheidender Unterschied zwischen Snapshot-Verfahren ist, wie diese mit Veränderungen von Datenblocks durch Nutzer oder Produktionsanwendungen umgehen. Es gibt zwei Methoden, wie sich Veränderungen verwalten und gleichzeitig die Snapshot-Integrität aufrecht erhalten lassen. Die erste Möglichkeit ist die, alte Daten an neue Standorte zu kopieren und die Snapshot-Metadaten zu aktualisieren, dass sie Zugriff auf die alten Blöcke gewährleisten. Die zweite Option ist, die modifizierten Blöcke an einen neuen Standort zu schreiben und die aktive Metadatenkopie zu aktualisieren. Jedes Produkt hat seine individuellen Facetten, aber generell kann man sie in diese zwei Lösungswege einteilen.

In jedem Fall hängt der Datensatz des Snapshots davon ab, dass die primäre Kopie verfügbar ist und dass die Kapazitäten dann genutzt werden, wenn sich die Anzahl der Snapshots erhöht  und sich die Speicherzeit der Snapshots verlängert.

Snapshot und Replikation

Da Snapshots völlig abhängig vom Quell-Datensatz sind, gehen Snapshots verloren, wenn die Quell-Daten aufgrund von Ausfällen in der Infrastruktur oder des Standortes verloren gehen. Durch diesen Nachteil sind Snapshots eingeschränkt, wenn es darum geht, korrumpierte Daten oder versehentlich gelöschte Files wiederherzustellen.

Trotzdem lässt sich die Technologie seit Track Block-Level Changes (oder auch Changed Block Tracking) auch für effiziente Datenreplikationen nutzen. Snapshot-basierte Replikation kopiert nur die Blöcke, die sich seit dem originalen Snapshot geändert haben. Nach der ersten Replikation der Daten lassen sich mit diesen kleinen Block-Transfers per WAN andere Systeme an einem externen Standort aktualisieren. Hierbei verbleibt der Snapshots auf dem sekundären System, so dass sie nicht länger vom primären System abhängig sind.

Diese Unabhängigkeit macht Replikation wichtig, um Snapshots für weitere Einsatzszenarien nützlich beziehungsweise geeignet zu machen. Eine andere Option ist es, die Snapshots auf einem sekundären System im primären Rechenzentrum abzulegen, zusätzlich zur Kopie an einen externen Standort. Fällt dann das primäre System aus, so hat das sekundäre, lokale System alle gesicherten Daten für eine schnelle Wiederherstellung, während das externe System über alle Daten für ein Disaster Recovery verfügt. Je nach verwendetem Snapshot-Manager, kann das sekundäre System kostengünstiger sein, was die Gesamtkosten verringert.

Was ist der Snapshot Manager?

Der Snapshot Manager ist die Software, die den Snapshot auslöst und die zahlreichen Kopien der Metadaten verwaltet und diese aktualisiert, wenn sich die aktiven Daten ändern. Der Snapshot Manager ist oft Teil einer anderen Komponente, wie zum Beispiel einer Anwendung, eines File-Systems, eines Hypervisors, eines Software-defined Storage oder eines Storage-Arrays. Alle diese Implementierungen haben individuelle Vorteile und viele Rechenzentren entscheiden sich für einen Mix an Produkten, um ihre Data-Protection-Anforderungen und Wiederherstellungsvorgaben zu erfüllen.

Applikations-Snapshots

Einige Anwendungen können Snapshots erstellen und verwalten und ebenso Replikationsaufgaben für diese Daten übernehmen. Snapshot- und Replikationsfunktionen von Drittanbietern sind oft für spezifische Applikationen konzipiert. Auch wenn diese häufig im Leistungsumfang eingeschränkt sind, so haben sie doch den Vorteil, dass sie die Applikation kennen. Sie können die Anwendung in einen stillgelegten Modus versetzen, während sie spezifische Prozesse überwachen, um sicherzustellen, dass die Datenbank noch läuft. Sollte einer dieser Prozesse nicht reagieren, so kann der Snapshot ein automatisches Recovery in Gang setzen. Ein weiterer Vorteil Applikations-agnostischer Snapshots ist, dass diese Produkte Daten direkt an nahezu jedes beliebige sekundäre Storage-Gerät replizieren können, was wiederum die Gesamt-Storage-Kosten reduziert. Die Schwäche dieser Produkte ist, dass sie auf die Anwendungen begrenzt sind, die sie unterstützen, was bedeutet, dass das Rechenzentrum mehrere Snapshot-Prozesse für unterschiedliche Applikationen benötigt.

File-System-Snapshots

Immer öfter sind Snapshot-Funktionalitäten in File-Systemen integriert. Diese Methode ist ähnlich der Applikations-Snapshots, funktioniert aber innerhalb eines gesamten File-Systems und nicht nur innerhalb einer Anwendung. Das ist ein wichtiger Punkt, da File-System-APIs genutzt werden können, um Snapshots von Anwendungen zu erstellen. Diese Snapshots funktionieren anwendungsübergreifend, sind aber an das Betriebssystem und die virtuelle Maschine gebunden. Das heißt, dass jedes Betriebssystem in der IT-Umgebung seine eigene Snapshot-Technologie benötigt. Ebenso lassen sich die meisten File-System-Snapshots nicht zentral verwalten. Der Snapshot-Zeitplan jedes Servers muss individuell überwacht und verwaltet werden. Für große Rechenzentren könnte das bedeuten, hunderte an individuellen Snapshot-Prozessen zu verfolgen.

Hypervisor-Snapshot

In einer virtuellen Umgebung lassen sich Snapshots auf Hypervisor-Ebene anlegen, was das Snapshot-Management vereinfacht. Statt die Snapshots pro virtueller Maschine oder Anwendung anzulegen und zu verwalten, ist die Kontrolle im Hypervisor konsolidiert. VMware-Snapshots lassen sich beispielsweise im vCenter managen. Wie bei Applikations- und File-System-Snapshots auch, kann das Snapshot- und Replikationsziel ein beliebiges sekundäres Storage-System sein, da die Snapshot-Funktion auf Hypervisor-Ebene implementiert ist.

Die drei erwähnten Snapshot-Methoden bringen typischerweise auch Probleme mit sich, wenn die Anzahl und das Alter der Snapshots steigen. Um das zu vermeiden, kann man die Storage-basierte Snapshot-Methode wählen.

Storage-Infrastruktur-Snapshots

Die gebräuchlichste Snapshot-Variante ist die über die Storage-Infrastruktur, normalerweise durchgeführt von der Storage-Hardware. Diese hardwarebasierten Snapshots haben mehrere Vorteile. Zunächst werden Snapshots pro Volume oder System erstellt, also müssen weniger Snapshot-Prozesse verwaltet werden. Des Weiteren lassen sich in den meisten Fällen hunderte von Snapshots vorhalten, ohne das dies die Performance beeinträchtigt. Das resultiert daraus, dass dedizierte Storage-Prozessoren die unterschiedlichen Metadatentabellen verarbeiten.

Der Nachteil der hardwarebasierten Snapshots liegt in den begrenzten Replikationszielen. In vielen Fällen müssen beide Storage-Systeme vom gleichen Hersteller stammen. Allerdings ermöglichen immer mehr Hardwareanbieter auch kostengünstige Systeme als Sekundärziel anzusprechen. Ein weiterer Nachteil ist, dass RZs mehrere Storage-Systeme haben, von denen jedes seinen eigenen Snapshot-Manager besitzt, die alle separat überwacht werden müssen.

Software-defined Storage (SDS) – vorausgesetzt mit Support für Snapshot und Replikation – löst diese Probleme, indem es eine allgemeine Engine für alle unterschiedlichen Systeme zur Verfügung stellt. Somit wird das Management in einem einzigen Interface zusammengefasst.

Backup-Applikations-Snapshots

Backup-Anwendungen dienen zwei Einsatzszenarien, wenn es um Snapshots geht. Im ersten übernimmt die Software die Erstellung und Verwaltung der Snapshots. Im zweiten Fall kann die Software den Snapshot auf einem anderen Gerät anstoßen und die Verwaltung hierfür zur Verfügung stellen. Im ersten Szenario ersetzt die Backup-Anwendung die Snapshot-Funktionalität aller anderen oben erwähnten Methoden. Im zweiten verwaltet, orchestriert und organisiert die Software die Snapshot-Daten.

Das zweite Einsatzszenario ist interessanter, da es due Nutzung der besten Snapshot-Technologien verschiedener Hersteller erlaubt sowie die effiziente Suche nach Daten innerhalb des Snapshots. Nachteilig hier ist auch ein eingeschränkter Support an Storage-Systemen, der aber auch immer mehr von Herstellern erweitert wird.

Die richtige Snapshot-Methode für virtuelle Umgebungen wählen

Viele RZs benötigen mehrere Snapshot-Methoden. So kann zum Beispiel die Applikations-Agnostik nützlich sein. In diesem Falle sollte man Snapshots für geschäftskritische Anwendungen separat mit einer anwendungsspezifischen Snapshot-Methode verwalten

Die meisten großen RZ werden nicht in der Lage sein, nur File-System- oder Hypervisor-basierte Snapshots einzusetzen, da dies Performance-Probleme mit sich bringen kann. Große Unternehmen nutzen typischerweise native Storage-System- der Backup-Software-Snapshots. Trotzdem sind die Snapshot-Funktionen von File-Systemen und Hypervisoren notwendig, da die Storage- und Backup-Snapshots diese als Framework nutzen können, um die Snapshot-Daten genau zu erfassen.

Wenn IT-Manager eine Snapshot-Methode wählen wollen, so sollten sie zunächst nach der Variante suchen, die am meisten abdeckt und bei Bedarf noch zusätzliche Verfahren auswählen, die spezifische Anforderungen bedienen.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Januar 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Datenmanagement-Tools

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close