Oft sind die Funktionen der Deduplizierung in so genannten NAS-/ und DAS-Appliances bereits integriert. Oder eine spezielle Backup-Lösung bietet die Deduplizierung als Zusatz-Feature zum Sparen von Speicherplatz bei der Datensicherung. Mit lessfs gibt eine freie Software-Lösung für Linux, die auf der Filesystem-in-Userspace (FUSE) Umgebung basiert. Hierbei leitet der Kernel I/O-Operationen über definierte Schnittstellen an das Programm im Userspace um. Die Open-Source-Deduplizierung nutzt dabei das sogenannte Inline-Verfahren.
Die Inline-, oder auch In-Band-Deduplizierung bearbeitet einen eingehenden Datenstrom sofort. Im Gegensatz zur Out-of-Band-Variante, welche die eintreffenden Daten erst physikalisch speichert und dann später automatisiert oder on-demand dedupliziert. So wird zwar mehr Speicherplatz für die Zwischenspeicherung benötigt, aber die Rechenleistung für das Erstellen der Prüfsummen erst später. Beide Verfahren haben Vor- und Nachteile.
Ein eingehender Datenstrom - beispielsweise eine Datei - wird in Chunks oder Blöcken variabler Größen von 64-2048 Byte zerlegt. Anstelle eines Vergleichs der Inhalte der Chunks, wird über diese eine Hash-Funktion laufen gelassen, die dann einen eindeutigen Hash-Wert (Fingerprint) für diesen Chunk generiert. Bis auf wenige Ausnahmen kann davon ausgegangen werden, dass bei gleichen Hash-Werten auch die Chunks identischen Inhalts sind. Im weiteren Verlauf des Workflows werden die Chunks durch die generierten Hashwerte ersetzt und letztere in einer Datenbank gesichert. Gleiche Hashwerte werden durch einen Zeiger auf den ersten ersetzt und benötigen daher weniger Speicherplatz. Bekannte Kompressionsprogramme ersetzen oft vorkommende Bytefolgen durch einen kürzeren und weniger oft erscheinende Folgen durch einen längeren Code (Huffmann-Code).
Ein Kompressionslauf über das /usr-Verzeichnis bei 1000 nahezu identischen Linux-Systemen würde eine hohe Redundanz der Daten auf einem zentralen Backupsystem ergeben, obwohl die Daten komprimiert wurden. Denn es liegen dann dort zirka 1000 mal die gleichen Dateien in komprimiertem Zustand. Die Deduplizierung jedoch hätte die gleichen Datenblöcke maximal einmal vorliegen und sonst nur Referenzen auf bereits vorhandene Datenblöcke darauf.
Der administrative Aufwand ist selbsterklärend größer, jedoch der eingesparte Speicherplatz rechtfertigt diese Methode.
Konfiguration
Für diesen Workshop wurde lessfs in der Version 1.3.3.8 für Linux 64 Bit verwendet, die aus dem verfügbaren tar-Archiv übersetzt wurde.
Nach dem erfolgreichen Build (configure; make; sudo make install) erhält man vier ausführbare Programme, nämlich mklessfs, lessfsck, defrag_lessfs und lessfs. Ein Manual existiert zur Zeit nur für lessfs. Obligatorisch ist eine Konfigurationsdatei: lessfs.cfg
Im Verzeichnis ./etc finden sich dafür Beispiele. Es empfiehlt sich diese Datei nach /etc zur systemweiten Nutzung zu kopieren.
Für die Funktion setzt lessfs auf zwei Flat-Datenbanken, die Hamster- und Tokyocabinet-DB. Letztere ist Default und über die Option "--with-hamsterdb" bei configure, kann die andere ausgewählt werden.
-
mklessfs: Mittels des Aufrufs "mklessfs -c /etc/lessfs.cfg" wird die Datenbank mit den Einstellungen aus der Konfigurationsdatei initiiert.
-
lessfsck: Ist das Dateisystem noch nicht eingehängt (mount), kann man mit diesem Aufruf ein Dateisystemcheck optional mit Optimierungen für die Tokyocabinet-DB ausführen: "lessfsck -c /etc/lessfs.cfg". Per Default ist jedoch die Option "ENABLE_TRANSACTIONS=on" gesetzt, so daß dieses Kommando nur selten zur Ausführung kommen wird.
-
defrag_lessfs: Hat man die Option "DYNAMIC_DEFRAGMENTATION=on" in der Konfigurationsdatei gesetzt, dann erübrigt sich das manuelle Defragmentieren der Datenbank über "defrag_lessfs /etc/lessfs.cfg". Auch kann man dies per Remote-Konsole online triggern.
-
lessfs: Dies ist die Kommandozentrale und erlaubt das Einhängen des lessfs-Dateisystems über "lessfs /etc/lessfs.cfg /mnt/data [-o ..]". Wer diese Aktivierung gleich nach dem Systemstart möchte, kopiert sich das SysV-Init-Skript aus ./etc nach /etc/init.d, passt es an und richtet die Links entsprechend ein.
Konfigurationsdatei lessfs.cfg
In der Konfigurationsdatei "lessfs.cfg" erkennt man zwei Verzeichnisstrukturen: "dta" für die Datenblöcke und "mta" für Metadaten, wie Hard- und Softlinks, Dateiblöcke, Verzeichniseinträge, Blockauslastung und Freieblockliste. Nutzt man Tokyocabinet als Datenbank, dann erkennt man die Dateiendung "tcb".
Die eigentlichen Datenblöcke des lessfs-Dateisystems werden im Verzeichnis "dta" als Datei "blockdata[.tcb |.dta]" gespeichert. Hier kommen also die Vor- und Nachteile des darunter liegenden Dateisystems zum Tragen. Je schneller dieses I/O-Operationen abwickeln kann, desto weniger Zeit werden die lessfs-Threads im Status Wait-IO verbringen.
Die Dateien im Verzeichnis gesetzt durch die Optionen BLOCKUSAGE_PATH und FILEBLOCK_PATH sollten wenn möglich nicht im gleichen Dateisystem abgelegt werden, das heißt idealerweise nutzt man unabhängige Disks dafür.
lessfs ist in der Lage, auch die Datenblöcke mit einem Komprimierungsalgorithmus in der Auswahl zu bearbeiten. Die Option "COMPRESSION" bietet hierfür die Möglichkeiten "qlz", "lzo", "bzip", und "deflate" oder auch "disabled" an. Dabei ist zu beachten, dass dies bei der Kompilierung mit angegeben wird.
Hat man die Option "DEBUG=5" gesetzt, erkennt man ein erfolgreiches Einhängen des Dateisystems im Systemlog an der Ausgabe der nachfolgenden Zeilen:
The selected data store is tokyocabinet.
Lessfs transaction support is enabled.
config->blockdata = /dedup/dta
Threaded background delete is enabled
Hash MHASH_TIGER192 has been selected
Lessfs uses a 24 bytes long hash.
Automatic defragmentation is enabled.
cache 1024 data blocks
Tuning the bucketsize for /dedup/mta/fileblock.tch to 1048576
Tuning the bucketsize for /dedup/mta/blockusage.tch to 1048576
Tuning the bucketsize for /dedup/mta/metadata.tcb to 1048576
Tuning the bucketsize for /dedup/dta/blockdata.tch to 1048576
Tuning the bucketsize for /dedup/mta/symlink.tch to 1048576
The filesystem is clean.
Sun Mar 27 16:49:44 2011
Raum für Verbesserungen
Verbose- und Debugmeldungen vermisst man doch hier und da. Fehler sollten nicht nur im Systemlog erscheinen, sondern für den Anwender sichtbar auf der ausführenden Konsole (stderr).
Gelöschte Dateien und somit freigegebene Blöcke sind nicht sofort als solche über die gewohnten Dateisystem Tools zu ermitteln. Erst wenn das Dedup-Dateisystem erneut aktiviert wird, lässt sich der effektive Platz berechnen.
Problematisch wird es, wenn das Wirts-Dateisystem keine freien Blöcke mehr zur Verfügung hat. Denn dann suspendiert lessfs jeglichen I/O zum lessfs-Dateisystem und ein "Aufräumen" wird recht schwierig.
Zusatz-Features
Für die Funktion nicht unbedingt notwendig, jedoch je nach Anwendungsfall nützlich, sind folgende Möglichkeiten von lessfs:
-
Daten- und Metadaten-Verschlüsselung
-
Master-Slave Betrieb
Wurde lessfs bei configure mit "--with-crypto" übersetzt, dann wird auch noch die openssl-Bibliothek mit eingebunden und es besteht die Möglichkeit, die Ursprungs- und Metadaten noch zu verschlüsseln. Dazu gibt es die zwei Optionen "ENCRYPT_DATA=on" und "ENCRYPT_META=on". "mklessfs" erwartet dann ein Passwort bei der Dateisystem Erzeugung und ebenso die anderen Tools zur Bestätigung des korrekten Passworts.
Bereits seit Version 1.1.6 gibt es den synchronen, seit Version 1.1.9 den asynchronen Master-Slave-Betrieb. Beide befinden sich noch im Alpha-Stadium. In der synchronen Betriebsart sendet der Master alle Schreib-I/O-Daten zum Nur-Lese-Slave und blockiert, wenn der Slave nicht erreichbar ist.
Werden die nachfolgenden Zeilen in der Konfigurationsdatei aktiviert, dann repliziert lessfs jeglichen I/O-Verkehr vom Master- zum Slave-System im asynchronen Modus und sichert diese Netzwerkpakete per CRC32-Prüfsumme:
REPLICATION=masterslave
REPLICATION_PARTNER_IP=192.168.2.2
REPLICATION_PARTNER_PORT=201
REPLICATION_ROLE=master
REPLICATION_ENABLED=on
Sowohl auf dem Master, als auch auf dem Slave kann per "echo 1 > MYMOUNT/.lessfs/replication/enabled" die Replikation jederzeit aktiviert oder mit dem Wert 0 deaktiviert werden. Während die Replikation nicht aktiv ist, schreibt der Master jeglichen Schreib-I/O in ein so genanntes Backlog, dessen Status unter MYMOUNT/.lessfs/replication/backlog eingesehen werden kann.
Remote-Konsole
Ist die Remote-Konsole über die Optionen "LISTEN_IP=.." und "LISTEN_PORT=100" aktiv, kann man dort die Kommandos
-
defrag
-
defrost
-
freeze und
-
lockstatus
ausführen lassen. Die Erläuterungen dazu sind etwas dürftig. "defrag" dürfte das Dateisystem online defragmentieren, "lockstatus" eine Ausgabe über gelockte Dateien geben und "freeze" jeglichen I/O-Verkehr des Dateisystems suspendieren. Die gegenteilige Aktion wäre dann mit "defrost" möglich, was jedoch bei einem gefüllten Wirtsdateisystem nicht so recht funktionieren wollte.
Optimierungen
Neben einer verteilten Datenablage für die Ausgangs- und Metadaten, sollte man darauf achten, eine möglichst große Blockdimension zu wählen. Empfohlen werden 64- oder 128-KByte-Blöcke, damit der Overhead nicht so groß wird (BLKSIZE=131072).
Die standardmäßig vorgegebene Hash-Länge von 24 Byte (=192 Bit), sowie die Hash-Methode "Tiger-192" brauchen kaum Anpassungen. Alternativ existiert noch "Midnight-Blue-Wish" als Hash-Algorithmus mit einer möglichen Hash-Länge von 20 bis 32Byte. Je kleiner die Hash-Länge, desto mehr Performance gibt es. Jedoch steigt gleichzeitig auch die Wahrscheinlichkeit einer Hash-Kollision.
Der Autor von lessfs empfiehlt jedoch die Blockdaten nicht in der TokyocabinetDB abzulegen, sondern als normale Datei.
Dafür passt man den Eintrag in der Konfiguration an (In "/dedup" liegen die Dateien vom Autor - bitte anpassen!) und kommentiert folgende Einträge aus:
# tokyocabinet
#BLOCKDATA_PATH=/dedup/dta
#BLOCKDATA_BS=1048576
Folgende Einträge sind ohne Kommentarzeichen zu versehen:
BLOCKDATA_IO_TYPE=file_io
BLOCKDATA_PATH=/dedup/dta/blockdata.dta
Dabei werden die bisherigen Dateien in "blockdata.tcb" nicht mehr genutzt und sie sind somit nicht mehr sichtbar. Hängt man jedoch ein neues Verzeichnis mit den Anpassungen ein und passt vorher die Konfiguration an, dann kann man die Dateien so verschieben.
Die CACHESIZE in Megabyte sollte man nicht all zu groß wählen, denn sonst ist das System mit I/O beschäftigt und nicht sehr reaktiv.
Im eingehängten Verzeichnis, das heißt die zweite Option von lessfs, gibt es ein Verzeichnis mit Namen ".lessfs". Dort findet sich eine Datei "lessfs_stats", die über den Deduplizierungs- und Komprimierungserfolg Auskunft gibt.
Fazit
Mit lessfs steht eine Deduplizierungs-Lösung basierend auf OpenSource (GNU GPLv3 license) zur Verfügung, die sich keinesfalls in der Funktion zu verstecken braucht. Stabilität und Sicherheit sind aus unserer Sicht überwiegend vorhanden, jedoch fehlen noch Manualseiten und eine klare Struktur. Auch sollten die Programm-Optionen, wie "-h", "-?", "--help" oder eine fehlende Option nicht gleich mit einem Fehler enden. An den Konfigurationsmöglichkeiten, wie dem Verändern der Blockgrößen ohne Datenverlust oder dem Wechsel auf eine andere DB, sollte noch optimiert werden.
Doch selbst kommerzielle Dedup-Lösungen bringen nicht immer den gewünschten Reduktionsfaktor, den uns die Marketingabteilungen oft vormachen wollen. Hier ist lessfs eine kostengünstige Alternative. (cvi)
Dieser Artikel basiert auf einem Beitrag der CW-Schwesterpublikation TecChannel.