Daten-Deduplizierung: Das steckt dahinter

Data & StorageNetzwerk-ManagementNetzwerkeStorage

Daten-Deduplizierung bezeichnet verschiedene Verfahren, um automatisiert redundante Files, Bytes oder Datenblöcken zu entfernen. Die eliminierten Daten werden durch Pointer ersetzt. Ziel ist es, die Menge zu speichernder Daten entweder bereits an der Quelle (Source) oder am Ziel (Target) zu reduzieren. Das hierzu nötige Repository (Metadaten-Index) zur Identifikation von nicht-redundanten Daten liefert im Zusammenspiel mit der eigentlichen Deduplizierung-Engine (Software, Algorithmen) die Grundlage zu Implementierung entsprechender Lösungen. Es kommen in der Regel so genannte Pattern-Matching- (Delta-based Suchmuster) oder hashbasierte Technologien zur Anwendung.

Die Deduplizierung kann derzeit sowohl über (Backup-) Software als auch mittels dedizierter Hardware (Appliance, Array, Virtual-Tape-System) umgesetzt werden.

Grundsätzliche Begriffe und verwendete Techniken

Beim Single Instancing werden ganze Objekte (zum Beispiel Files) nur einmal abgespeichert. Nachteil: Auch wenn sich nur ein Zeichen in einer Datei ändert, wird der gesamte Inhalt doppelt gespeichert. Der Einspareffekt ist hier also geringer als beim Entfernen von Block-basierten Redundanzen. Beispiel: Von 20 Kopien eines Word Dokuments enthält jedes Doppel nur eine unterschiedliche Seite; einem Datenreduktionssystem auf Dateiebene erscheinen die Kopien als 20 unterschiedliche Files. Das Single-Instancing-Verfahren wird häufig in Verbindung mit inkrementeller oder differentieller Datensicherung eingesetzt.

Deduplizierung auf Block-Level ist die Form des Single Instancing auf der Ebene unterhalb von Dateien (Sub-File-Level). Der Begriff »Deduplikation« wird deshalb meist in diesem Zusammenhang verwendet. Bei Deduplizierung auf Blockebene lassen sich alle redundanten Daten entfernen und weniger Speicherplatz auf der Festplatte wird benötigt.

Ein leistungsstarkes Deduplizierungsverfahren beruht auf Blocks mit variabler Länge. Die Methode analysiert eine Sequenz von Daten und teilt sie in verschiedene Blöcke von variabler Länge auf. Wird ein redundanter Block erkannt, legt das System einen auf den Originalblock verweisenden Pointer ab (Metadaten), statt den Block erneut zu speichern. Da der Pointer deutlich weniger Platz in Anspruch nimmt als der Block selbst, wird Speicherplatz einspart. Bei Backup-Jobs, in denen dieselben Blöcke immer wieder vorkommen, kann so das 10- bis 50-fache an Daten auf dem entsprechenden Speichersystem gespeichert werden. Welches ist für welche Anwendung das jeweils effizienteste Verfahren und was der Algorithmus mit der höchsten beziehungsweise sichersten Deduplizierungsrate? Bevor wir uns dieser Fragestellung widmen, soll noch kurz auf den Unterschied zwischen Deduplizierung und Komprimierung hingewiesen werden.

Deduplizierung ist eine Weiterentwicklung von Kompressionsalgorithmen, die für Files benutzt wurden. Ausgangspunkt war das so genannte »Check Sum Verfahren« aus der Kryptografie, um verschlüsselte Signaturen zu erzeugen (SHA0,1, MD5 etc.), es ist also prinzipiell keine neue Technik. Jedoch wurden die mathematischen Verfahren bei der Deduplizierung fortentwickelt und für Block-, Byte-, Bit-Ebene und File-Level erweitert. Bei der Datenkomprimierung wird die Darstellung von Daten so modifiziert, dass weniger Platz dafür benötigt wird. Eine Sequenz gleicher Gruppen von Zeichen zum Beispiel lässt sich durch eines dieser Zeichen oder Zeichengruppen mit dem jeweiligen Wiederholungsfaktor ersetzen. Ebenso wie bei der Deduplizierung speichert die Komprimierung die redundanten Daten nicht weiter ab, liefert allerdings im Ergebnis eine geringere Effizienz (realistische Werte liegen bei 1:2 – abhängig vom Datentyp). Die Deduplizierung sollte idealerweise durch eine lokale Komprimierung ergänzt werden, wodurch die Datengröße noch einmal halbiert wird und damit eine erhebliche Datenreduzierung erreichen wird.

Wie arbeitet Deduplizierung?

Deduplizierung funktioniert mit Algorithmen, die nach doppelten Datenobjekten – Chunks oder Blöcken – suchen und zu diesem Zweck eine eindeutige Identifikation über den Hash-Wert der Objekte bilden. Dazu muss ein Katalog aller bisherigen Werte erzeugt werden (Metadaten-Index). Als nächstes vergleicht man die Hash-Werte und speichert bei erstmaligem Auftreten eines Objektes dieses dann ab (ein Chunk ist in etwa wie der menschliche Fingerabdruck, also einmalig). Die Chunk-Inhalte werden nun miteinander verglichen und nur dann gesichert, wenn sie als Inhalt bislang noch nicht identifiziert wurden. Das bedeutet: Bei redundanten Objekten wird nur ein Pointer zum ersten gespeicherten Objekt erzeugt.

Es wurde über die Möglichkeit von Datenverlusten bei der Deduplizierung durch Hash-Kollisionen berichtet und auf Grund von fehlerhaften Kalkulationen bei den ersten Hash-Code-Implementierungen auch vereinzelt in der Praxis beobachtet. Eine Kollision bedeutet, dass zwei überprüfte Datensätze dieselbe Identifikationsnummer erhalten – also denselben Hash-Code erzeugen – obwohl sie aus jeweils unterschiedliche Bitfolgen bestehen. Dies ist möglich (als Funktion der Datenmenge bzw. der Hash-Implementierung), allerdings verfügen moderne Hash-Codes über eine ausgefeilte Integritätsprüfung und die Fehlerrate ist laut Aussagen von Anbietern damit beispielsweise geringer als die mögliche Bitfehler-Rate bei heutigen LTO-Tapes.

Anforderungen an Deduplizierungslösungen

In modernen Speichersystemen werden immer öfter verschiedene Standardprotokolle verwendet, zum Beispiel NFS, CIFS, Block, iSCSI, FC und VTL (siehe auch »Unified Storage«), da diverse Anwendungen unterschiedliche Protokolle zur selben Zeit benötigen. Benutzer-Startverzeichnisse können sich auf einem NAS-Server befinden; der Exchange-Server sollte in Blöcken ausgeführt werden und für Sicherung wird eine VTL bevorzugt.

Im Laufe eines Lebenszyklus werden dieselben Daten möglicherweise mit allen Protokollen gespeichert. Eine Präsentation, die in einem Startverzeichnis beginnt, kann per E-Mail gesendet oder vom E-Mail-Server in Blockformat gespeichert und dann von einer E-Mail-Archivierung auf einem NAS-Server abgespeichert werden. Diese kann vom Startverzeichnis, E-Mail-Server und von der Archivierungsanwendung in der VTL gesichert werden. Bei der Deduplizierung sollten somit unabhängig von der Art der Speicherung möglichst alle redundante Daten gefunden werden.

Verschiedene Deduplizierungsverfahren

Wo wird dedupliziert? Beim Deduplizieren an der Quelle – Source-based Deduplication – wird der Hash-Wert am Backup-Client erzeugt und verglichen.

Vorteil: Es werden weniger Daten durch das Netzwerk transferiert. Nachteil: Der Deduplizierungs-Index kann je nach Implementierung über das Netzwerk verteilt sein und ist schwieriger zu verwalten; daneben sind Verfügbarkeitsaspekte zu beachten. Das Auslesen von deduplizierten Daten kostet normalerweise hier etwas mehr Zeit (potentielle Performance-Probleme), was für die Online-Arrays problematisch sein kann. Auch gilt es zu beachten: Wenn während des Backups die Deduplizierung auf dem Server läuft, werden zwar weniger Daten über die Backup-Verbindung übertragen, jedoch muss Software auf allen gesicherten Hosts verwaltet werden. Der Backup-Prozess selbst verlangsamt sich, da die Deduplizierung systembedingt einen Overhead erzeugt; andere auf dem Server laufende Anwendungen können davon auch betroffen werden.

Grundsätzlich stellt die Deduplizierung des Primärspeichers derzeit eine sehr interessante Option dar, speziell im Bereich des Virtual-Machine-Managements, da hier viele redundante Daten entstehen, die zeitnah gesichert werden sollten. Source-based Deduplication empfiehlt sich deshalb für Unternehmen, die erst kürzlich Investitionen in die Storage-Hardware getätigt haben oder keine weitere separate Hardwareplattform für Backup und Deduplizierung verwalten wollen.

Bei der Deduplikation am Ziel (Target) müssen die Daten zuerst durch das Netzwerk, bevor eine Reduzierung erreicht wird.

Vorteil: Alle Komponenten zur Verwaltung dieser Systeme sind zentralisiert und damit leichter zu administrieren. Wenn Sie am Backup-Ziel deduplizieren, wird eine größere Menge an Daten über die Verbindung übertragen; jede gängige Backup-Software kann in der Regel verwendet werden. Die Leistung ist höher, da das Hardwaresystem speziell für die Deduplizierung optimiert wurde. Zielsysteme (Targets) sind für diesen Zweck optimierte Disk-Arrays mit schnellem Halbleiter-Cache und Solid-State-Disks (SSDs). Moderne Lösungen lassen sich meist als Virtual Tape Library (VTL) konfigurieren, stellen sich der Backup-Software also wie reale Tape-Bibliotheken dar. Sie erlauben aber natürlich weiterhin den Anschluss von realen Tape Drives für Archiv- oder Desaster-Recovery-Zwecke. Klassische VTLs mit Datensicherung auf Tape anstelle Disk verwenden typischerweise Standard-Komprimierungsverfahren anstatt Deduplikation.

Nachteil: Beim Post-Processing (siehe auch »Wann soll dedupliziert werden«) können größere Investitionen in schnelle SAS- oder FC-Disk-Arrays nötig sein. Des Weiteren fallen je nach Anbieter bzw. Lizenzpolitik zusätzliche Software-Lizenzkosten für entsprechende Sicherungskapazitäten an.

Target-Deduplizierung ist also für Organisationen interessant, die derzeit über keine weiteren leistungsfähigen Kapazitäten für D2D-Backup und Deduplizierung verfügen oder eine Backup-Software einsetzen, die Deduplizierung nicht gut unterstützt. Hier ist die Anschaffung einer dedizierten Disk-Backup Deduplizierungslösung (Array und/oder Appliance) eine Alternative.

Rein Software-basierte Deduplizierungslösungen erfordern eine sorgfältige Planung, da sich aus ihr Folgen für die Serverbelastung, Festplattenkapazitäten und den Netzwerkdurchsatz ergeben können. Andererseits bietet die Software per se den Vorteil von Hardware-Unabhängigkeiten: In der Regel lassen sich auch die bestehende Backup-Prozesse unverändert weiterführen und es wird kein zusätzlicher neuer Management-Layer neben der bereits verwendeten Backup-Software erzeugt.

Wann soll dedupliziert werden? Post-Processing bedeutet, dass die Daten erst dedupliziert werden, nachdem sie auf das Speicherarray geschrieben wurden. Es ist deshalb nötig, entsprechende Speicherkapazität plus weiteren Platz für die deduplizierte Daten vorzuhalten.

Vorteil: Die Prozesse können ohne Beeinträchtigung des Backup-Vorgangs offline durchgeführt werden und die hierfür nötige CPU-Belastung ist in der Regel sehr gering. Nachteil: Sollte die für eine nachträgliche Deduplizierung benötigte Zeit bis zum nächsten Backup nicht reichen, werden weitere Sicherungsläufe davon negativ betroffen; somit müssen natürlich auch die verbundenen Prozesse für weitergehende Desaster-Recovery-Mechanismen (Datenreplizierung) bis zum erfolgreichen Beenden des Deduplizierungsprozesses beeinträchtigt (Latency).

Inline-Deduplizierung hingegen ermöglicht die Deduplizierung »on the fly«, d.h. schreibt Daten direkt auf das Speichermedium.

Vorteil: Die Kapazitätsreduzierung arbeitet sofort, da die Deduplizierungsalgorithmen in »Realtime«durchgeführt werden. Nachteil: Es müssen genügend leistungsfähige und skalierbare (Anforderungen steigen mit der Zeit) Server- plus CPU-Ressourcen zur Verfügung stehen. Dank Multicore-CPUs und optimierter Algorithmen ist die Inline-Deduplizierung inzwischen aus Performancesicht ein empfehlenswertes Verfahren (die Leistung skaliert linear mit der Hardware-Performance).

Deduplizierung in Verbindung mit Datenreplikation

Bei der Replikation werden duplizierte Daten von einer Quelle an ein Ziel übertragen und es werden normalerweise alle Backup-Daten repliziert. Dazu ist allerdings ein leistungsfähiges Netz erforderlich. Bei der Deduplizierung sucht das Quellsystem im Replikationsstrom nach duplizierten Blöcken. Wenn bereits ein Block an das Zielsystem übertragen wurde, ist dieser nicht mehr zu übertragen, sondern nur ein entsprechender Verweis darauf. Da der Pointer deutlich kleiner als der Block ist, wird zur Replikation geringere Netzbandbreite benötigt.

Welche Applikationen sind geeignet?

Virtualisierte Umgebungen mit sehr vielen virtuellen Maschinen sind gute Kandidaten. Zu beachten ist: Wenn Daten der VMs durch Source-Deduplizierung bereits reduziert worden sind, müssen diese vor dem Backup jedoch zur Verfügung stehen; dies kann einen Mehraufwand für die Administration bedeuten und Automatisierungstools sind nötig. Als effektiv hat sich die Sicherung auf schnelle Disk-basierte Backupsysteme (integrierte Arrays / Appliances) mit Deduplizierungsfunktionalitäten herausgestellt. Folgende Vorgehensweise ist prinzipiell sinnvoll (Skripting nötig):

1. Mittels konsistenten Snapshots VMDKs in das D2D-Backup-/Deduplizierungssystem kopieren.
2. Diese Sicherungsdaten in das zweite System am Desaster-Recovery (DR-)Standort replizieren.

Wenn Deduplizierung für das Backup eingesetzt wird, sind alle gängigen Anwendungen wie Mail, Datenbanken, File-Services sowie alle gängigen Backup-Lösungen unterstützt. Bei der Deduplizierung mit variabler Blocklänge lassen sich in der Regel für nahezu alle Anwendungen im Backup-Strom redundante Blöcke finden. Für bestimmte Dateitypen entstehen beim ersten Deduplizierungslauf nur geringe Vorteile, weil die Anwendung selbst im Vorfeld Redundanzen beseitigt. Werden allerdings mehrere Backup-Läufe durchgeführt – oder nachdem Änderungen vorgenommen wurden – kann Deduplizierung sehr wirksam sein (Beispiel: MultiMedia Apps).

Erfolgt die Source-basierte Deduplikation in den Außenstellen von Unternehmen, dann reduziert sich das Volumen der zentral zu sichernden Daten und es müssen deutlich weniger Daten transferiert werden, was wiederum eine geringere Netzbandbreite zwischen Außenstelle und Zentrale erfordert und damit reduzierte Kosten nach sich zieht.

In Verbindung mit geeigneten WAN-Optimierungsverfahren (siehe z.B. Riverbed-Lösungen) verbessert dies die Planbarkeit und Durchführung von DR-Prozessen und der Backup-Effizienz durch die Zentralisierung und Automation der Verfahren über weniger Hardware und Verwaltungsaufwand, geringere Fehlerquoten beim Backup und höhere Datenintegrität. Verschlüsselte Daten lassen sich natürlich nicht sinnvoll Deduplizieren, d.h. zuerst eine Reduktion der Redundanz und dann die Verschlüsselung durchführen.

 


Norbert E. Deuschle ist unabhängiger Analyst, Industrieexperte und Betreiber des Storage Consortiums, das technisches und wissenschaftliches Wissen für IT-Organisationen und Unternehmen bereitstellt – vor allem zum Thema Storage, aber auch zu Netzwerk- und Server-Infrastrukturen sowie Cloud-Services.

Lesen Sie auch :