ZFS auf Linux/ Deduplizierung

Deduplizierung

Allgemeines

Die Prüfsummen der Blöcke werden nicht nur für den Integritäts-Check verwendet, sondern auch für eine Deduplizierung auf Blockebene. Beim Einsatz von Deduplizierung wird automatisch zur Vermeidung von Kollisionen SHA256 als Prüfsummenalgorithmus eingesetzt. Sonst genügt "flechter2" bzw. "flechter4". Sollte die Deduplizierung zu einem späteren Zeitpunkt wieder abgeschaltet werden, so bleibt die bereits erreichte Deduplizierung bestehen, während neu geschriebene Blöcke nicht mehr dedupliziert werden.

Erfahrene Nutzer empfehlen: Komprimieren, aber nicht Deduplizieren.

Anforderungen

Damit die Deduplizierung nicht zu erheblichen Geschwindigkeitseinbußen führt, muss die Deduplizierungstabelle (DDT) komplett im Hauptspeicher gehalten werden. Eine Faustregel besagt, dass ca. 5-6 GB RAM pro 1 TB deduplizierter Daten benötigt werden. Der tatsächliche Speicherbedarf hängt von der Blockgrößen ab. ZFS arbeitet mit variablen Blockgrößen bis zu 1 MB. Alternativ kann eine SSD als Cache-Device eingesetzt werden, auf der dann Teile der DDT ausgelagert werden können. In der DDT werden die Prüfsummen aller geschrieben Blöcke abgelegt, um sie anschließend schneller vergleichen und nach Duplikaten suchen zu können.

Deduplizieren oder nicht

Man kann die zu erwartenden Einsparerfolge vorab abfragen ohne die Deduplizierung zu aktivieren. Daher soll über den Einsatz dieses Features erst entschieden werden, wenn eine aussagekräftige Menge an Daten auf den ZFS-Servern liegt. Um bereits abgelegte Daten tatsächlich zu deduplizieren müssen sie in einen anderen Pool kopiert werden. Wenn man die Deduplizierung wieder loswerden will, muss man die Daten in einen anderen ZFS-Pool kopieren.

Eine Simulation der Deduplizierung ist folgendermaßen möglich:

user@host:~$ zdb -S <POOLNAME>
Simulated DDT histogram:

bucket              allocated                       referenced          
------   ----------------------------     ----------------------------
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1     555K   69.3G   33.3G   33.3G     555K   69.3G   33.3G   33.3G
    2M        1    128K    128K    128K    2.13M    272G    272G    272G
 Total     555K   69.3G   33.3G   33.3G    2.67M    342G    306G    306G

dedup = 9.18, compress = 1.12, copies = 1.00, dedup * compress / copies = 10.26

Die für die Auswertung der Simulation relevanten Werte befinden sich in der letzten Zeile der Ausgabe. Der unter dedup ausgegebene Wert entspricht dem berechneten Deduplizierungsfaktor. Je größer dieser ist, desto wirkungsvoller ist die Deduplizierung. Der als compress angegebene Komprimierungsfaktor wird nicht berechnet, sondern entspricht dem tatsächlichen Zustand des Pools. Es wird demnach keine Simulation der Komprimierung durchgeführt. Sollte eine bestimmte Anzahl an Replikas konfiguriert sein, würde der Wert copies der Anzahl dieser Replikas entsprechen. Aus den drei beschriebenen Werten wird zusätzlich das Verhältnis zwischen den zu speichernden Daten und dem dafür benötigten Speicherplatz unter Berücksichtigung aller Einflussgrößen berechnet und ausgegeben.

Aktivierung der Deduplizierung

Die Deduplizierung kann durch Setzen einer der folgenden Werte für das Attribut dedup eines Pools oder Datasets erfolgen:

off - Deduplizierung ist deaktiviert
on - Deduplizierung ist aktiviert
verify - der Inhalt logischer Blöcke mit identischen Prüfsummen wird zur Vermeidung von Fehlern zusätzlich byteweise verglichen
sha256 - Deduplizierung wird basierend auf SHA256-Prüfsummen durchgeführt
sha256,verify - Deduplizierung wird basierend auf SHA256-Prüfsummen durchgeführt und der Inhalt der logischen Blöcke wird verglichen

Da bei aktivierter Deduplizierung immer SHA256 zum Einsatz kommt und alle anderen Prüfsummenparameter überschrieben werden, sind einige der Optionen theoretisch nicht von Nöten. Sowohl on und sha256, als auch verify und sha256,verify bewirken jeweils das gleiche Verhalten.

Geschwindigkeit der Deduplizierung

Bei Messungen mit gut bzw. schlecht deduplizierbaren Daten konnten folgende Werte ermittelt werden:

Bei schlecht deduplizierbaren Daten konnten nur geringe Lese- und Schreibgeschwindigkeiten erreicht werden. Die niedrigeren Lesegeschwindigkeiten werden durch die aufwändigere Verifikation der SHA256 Prüfsummen verursacht. Die Schreibgeschwindigkeiten sind hingegen aufgrund der Latenzen beim Vergleich der Prüfsummen so stark eingebrochen.

Da die DDT beim Schreiben gut deduplizierbarer Daten immer nur bis zur identischen Prüfsumme durchsucht werden muss, konnten höhere Schreibgeschwindigkeiten erreicht werden. Die Lesegeschwindigkeit konnte im Vergleich zur deaktivierten Deduplizierung sogar reichlich vervierfacht werden. Dies liegt am Caching der deduplizierten Blöcke, die bei wiederholten Zugriffen nicht erneut vom Pool gelesen werden müssen.

Siehe auch

ZFS: To Dedupe or not to Dedupe... von 2011