# Deduplication and Compression – Maximale Speichereffizienz im Enterprise-Umfeld

TL;DR / Management Summary Deduplizierung und Komprimierung sind essenzielle Technologien zur Reduzierung des Speicherbedarfs bei Backup-Targets, Archivspeichern und virtualisierten Umgebungen (VDI/VMs). Während Inline-Komprimierung (z.B. LZ4 oder ZSTD) fast immer ohne signifikante Nachteile aktiviert werden sollte, ist die Deduplizierung eine hochkomplexe, RAM-intensive Funktion, die nur nach sorgfältiger Dimensionierung und in Umgebungen mit hoher Datenredundanz (z.B. identische OS-Images) eingesetzt werden darf. Der Hauptvorteil ist die massive Reduktion des TCO; der Hauptnachteil ist die Gefahr des ‘Dedupe Traps’ – katastrophaler Performance-Absturz durch Speichermangel für die Deduplication Table (DDT).

# 1. Einführung & Architektur

Im modernen Rechenzentrum wird der Speicherplatz durch exponentielles Datenwachstum und hohe Virtualisierungsdichten schnell knapp. Standard-Thin-Provisioning oder dateibasiertes Archivieren reichen oft nicht aus. Wir benötigen Block-Level-Techniken, die Redundanz eliminieren, bevor die Daten physisch auf die Platte geschrieben werden.

# Warum brauchen wir das?

• Problemstellung aus der Praxis: Große VM-Umgebungen (VDI) verwenden hunderte identischer Basis-OS-Images. Backup-Systeme speichern täglich nahezu identische Full Backups. Ohne Deduplizierung wird diese Redundanz 1:1 gespeichert.
• Komprimierung (Compression): Reduziert die logische Größe eines Datenblocks (z.B. Textdateien, Logs) vor dem Schreiben. Sie ist CPU-intensiv, aber reduziert I/O und Platz.
• Deduplizierung (Deduplication): Eliminiert redundante Datenblöcke systemweit. Sie ist I/O- und RAM-intensiv, da ein Index (DDT) verwaltet werden muss.
• Vergleich: ZFS bietet beides effizient und atomar. Herkömmliche Filesysteme (EXT4, XFS) bieten dies nicht nativ. Die Alternative wäre Appliance-basierte Deduplizierung (z.B. Dell Data Domain) oder Software-Defined Backuplösungen. Wir fokussieren uns hier auf die Filesystem-integrierte Lösung (ZFS/Btrfs).

# Architektur-Diagramm: Das Innenleben von ZFS (DDT & ARC)

Die Effizienz der Deduplizierung hängt direkt von der Verwaltung des Deduplication Table (DDT) ab.

# Kernel-Sicht: Wo im Linux-Subsystem klinkt sich das ein?

Deduplizierung und Komprimierung finden oberhalb des Block Layers, direkt im Filesystem-Layer (User Space ZFS/Kernel ZFS) statt. Bevor Datenblöcke zur ZPool-Logik (Block Allocation) gelangen, durchlaufen sie diese Pipeline:

1. Checksumming: Block wird geprüft (z.B. Fletcher4).
2. Hashing (Dedupe): Ein kryptografischer Hash (SHA-256 oder FNV) wird vom Block generiert.
3. DDT Lookup: Der Hash wird im Deduplication Table (DDT) nachgeschlagen.
   • Match: Der Block wird nicht geschrieben; der Block-Pointer im Metadatenbaum verweist auf den bereits vorhandenen Block. (Dedupe-Hit)
   • No Match: a. Compression: Der Block wird komprimiert (z.B. LZ4). b. Write: Der komprimierte Block wird auf das physische Speichermedium geschrieben. c. DDT Update: Der Hash und der neue Block-Pointer werden in die DDT geschrieben.

graph TD
    A[Datenblock von Applikation] --> B{Hashing (SHA-256)};
    B --> C[DDT Lookup im RAM/ARC];
    C -- Hash Match (Hit) --> D[Metadaten-Update: Shared Pointer];
    C -- No Match (Miss) --> E{Kompression (LZ4/ZSTD)};
    E --> F[Checksumme generieren];
    F --> G[Physischer Write auf Disk];
    G --> H[DDT Update: Neuen Hash speichern];

    style C fill:#f9f,stroke:#333,stroke-width:2px
    style E fill:#ccf,stroke:#333,stroke-width:2px

Das kritische Element ist die DDT. Sie muss schnell sein. Da Disks immer langsamer sind als RAM, residiert die DDT (oder zumindest der heißeste Teil davon) im Adaptive Replacement Cache (ARC), einem Teil des System-RAMs.

# 2. Installation & Grundkonfiguration (Praxis)

Wir verwenden ZFS on Linux (ZoL) als Referenzimplementierung.

# Voraussetzungen

1. RAM (Dedupe): Absolut kritisch. Faustregel: 1 GB RAM pro 1 TB logischer, deduzierbarer Daten, um die DDT im ARC zu halten. Bei 50 TB Daten und einer 40 Byte DDT-Eintragungsgröße benötigen Sie 50 GB dedizierten RAM zusätzlich zum OS/Applikations-RAM. Dies ist die häufigste Ursache für Produktionsausfälle bei Deduplizierung.
2. CPU (Compression): Moderne, schnelle Kerne (mindestens 2 GHz), idealerweise mit AES-NI-Support für schnelle Kompression.
3. ZFS Version: Stabil (z.B. OpenZFS 2.x).

# Schritt-für-Schritt Setup (Der “Happy Path”)

Wir erstellen einen Pool und konfigurieren die Daten-Datasets. Wir trennen die Konfiguration für Komprimierung und Deduplizierung, da die Empfehlungen stark divergieren.

# 2.1 Komprimierung (Immer Empfohlen)

LZ4 ist der De-facto-Standard, da er extrem schnell ist und nur minimalen CPU-Overhead hat, während er signifikante Einsparungen (~30-50% bei VMs) liefert.

# 1. Pool erstellen
zpool create -f my_data_pool raidz2 /dev/nvme0n1 /dev/nvme0n2 /dev/nvme0n3

# 2. Dataset für allgemeine Daten erstellen
zfs create my_data_pool/archive

# 3. Komprimierung aktivieren (LZ4 ist Standard und der schnellste Algorithmus)
# Wir setzen 'compression=lz4'. Dies ist inline und gilt für alle neuen Writes.
zfs set compression=lz4 my_data_pool/archive

# Überprüfung des Status
zfs get compression my_data_pool/archive
# Ergebnis: my_data_pool/archive  compression  lz4

# 2.2 Deduplizierung (Nur nach sorgfältiger Planung)

Die Deduplizierung wird nur auf Datasets aktiviert, wo der Administrator weiß, dass eine hohe Redundanz vorliegt (z.B. VM Clones).

# 1. Dataset für Dedupe-lastige Daten erstellen (z.B. VDI Master Images)
zfs create my_data_pool/vdi_data

# 2. Deduplizierung aktivieren.
# Achtung: Standardmäßig wird SHA-256 (stark, aber langsam) oder FNV (schneller, weniger stark) verwendet, 
# abhängig von der Pool-Version und 'dedupditto' Einstellung.
zfs set deduplication=on my_data_pool/vdi_data

# 3. (Optional, aber empfohlen): Datenintegrität erhöhen und Redundanz für DDT sicherstellen
# 'dedupditto=2' stellt sicher, dass jede DDT-Eintragung zweimal geschrieben wird
# (zusätzlich zur Pool-Redundanz), falls die DDT selbst korrumpiert wird.
zfs set dedupditto=2 my_data_pool/vdi_data

# 4. Überprüfung des DDT-Status
zfs get deduplication my_data_pool/vdi_data

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning

Die Wahl des Algorithmus und die richtige Speicherzuteilung sind entscheidend.

# Compression Algorithmen

Ich empfehle, standardmäßig compression=lz4 zu nutzen und für Backup-Targets, auf denen Daten länger verweilen, compression=zstd zu testen, da es moderner und effizienter als GZIP ist, ohne dessen extremen Performance-Nachteil.

# Deduplication Tuning: Der Cache

Die Leistung der Deduplizierung steht und fällt mit der Geschwindigkeit des DDT-Zugriffs.

1. RAM-Dimensionierung: Wie in 1. beschrieben, muss der RAM überdimensioniert sein. Nutzen Sie arc_max und zfs_arc_max im modprobe.d/zfs.conf, um sicherzustellen, dass das Betriebssystem den benötigten RAM für die DDT (im ARC) nicht freigibt.
2. Special Allocation Class (ZFS Feature): Für Pools, die nur aus HDDs bestehen, wird die Performance bei aktiviertem Dedupe katastrophal. ZFS ermöglicht es, einen Teil des Pools, z.B. schnelle NVMe-SSDs, ausschließlich für Metadaten und die DDT zu reservieren (via special VDEV).

# Beispiel: Dedizierte NVMe für Metadaten (DDT)
# Dies beschleunigt Dedupe Lookups massiv, wenn die DDT nicht in den RAM passt.
zpool add my_data_pool special /dev/nvme_fast_ssd

# Hardening & Security

ZFS verwendet integrierte Prüfsummen (Checksumming) für jeden Block, unabhängig von Dedupe/Comp. Diese sind essenziell, um ‘Silent Data Corruption’ (SDC) zu erkennen.

• Verschlüsselung (LUKS/ZFS native): Wenn Sie ZFS-native Verschlüsselung nutzen, erfolgt die Komprimierung/Deduplizierung nach der Entschlüsselung und vor der Verschlüsselung. Dies ist der empfohlene Pfad, um von der Effizienz zu profitieren, während die Daten auf der Platte verschlüsselt bleiben.

# 4. Day-2 Operations: Wartung & Alltag

# Typische Tasks

# 4.1 DDR und CR prüfen (Deduplication Ratio / Compression Ratio)

Diese Kennzahlen sind das Maß für den Erfolg:

# Zeigt die Effizienz des Datasets an
zfs get all my_data_pool/vdi_data | grep ratio

# Beispiel-Output:
# my_data_pool/vdi_data  compressratio  2.50x  # 250% Einsparung durch Kompression
# my_data_pool/vdi_data  dedup         1.80x  # 180% Einsparung durch Deduplizierung
# Der gesamte Platzbedarf ist 2.50 * 1.80 = 4.50x effizienter.

# 4.2 Deduplizierung / Komprimierung nachträglich ändern

Wichtig: Deduplizierung und Komprimierung sind Inline-Operationen. Das Ändern des Property (z.B. von lz4 auf zstd) wirkt sich nur auf neue Schreibvorgänge aus.

Um bereits geschriebene Daten zu optimieren (z.B. von unkomprimiert auf zstd migrieren), muss ein Daten-Move durchgeführt werden:

# 1. Neues Dataset mit optimierter Einstellung erstellen
zfs create my_data_pool/archive_new
zfs set compression=zstd my_data_pool/archive_new

# 2. Daten migrieren (über zfs send/receive, um Metadaten zu erhalten)
zfs send my_data_pool/archive@snapshot_today | zfs receive my_data_pool/archive_new

# ODER einfach:
rsync -av /mnt/my_data_pool/archive/ /mnt/my_data_pool/archive_new/

# Automatisierung (Ansible)

Idempotenz ist bei ZFS-Properties einfach zu erreichen.

# Ansible Playbook zur Sicherstellung von ZSTD Komprimierung
- name: Ensure ZFS dataset has optimal compression settings
  hosts: storage_servers
  tasks:
    - name: Set compression to zstd-3 for archive data
      community.general.zfs_set:
        name: "{{ item }}"
        properties:
          compression: zstd-3  # Stufe 3 bietet guten Kompromiss
          deduplication: off   # Sicherstellen, dass Dedupe deaktiviert ist (Sicherheit geht vor)
          checksum: sha512     # Hochwertigere Checksumme für Integrität
      loop:
        - my_data_pool/archive
        - my_data_pool/logs

# 5. Troubleshooting & “War Stories”

# Top 3 Fehlerbilder

# 1. Symptom A: Der “Dedupe Trap” (Katastrophaler Performance-Einbruch)

• Symptom: Das System friert periodisch ein, I/O-Latenzen springen auf hunderte von Millisekunden, zpool iostat zeigt extrem hohe Lese-Latenzen.
• Ursache: Die Deduplication Table (DDT) ist zu groß für den verfügbaren System-RAM (ARC). Das System muss ständig DDT-Blöcke von der langsamen Disk laden, um Hashes nachzuschlagen. Dies führt zum sogenannten ‘Thrashing’, da jeder Lese- oder Schreibvorgang mehrere langsame I/O-Vorgänge erfordert, um die DDT abzufragen.
• Lösung:
  1. Sofortige Analyse des RAM-Bedarfs.
  2. Falls möglich: Massive Aufrüstung des RAMs.
  3. Falls nicht möglich: Deaktivierung der Deduplizierung (zfs set deduplication=off <dataset>). Achtung: Dies beendet das Problem nur für zukünftige Writes. Die alten Daten bleiben deduziert.
  4. Langfristig: Daten auf ein neues, nicht-dedupliziertes Dataset migrieren (siehe 4.2).

# 2. Symptom B: Hohe CPU-Auslastung bei Backups/Snapshots

• Symptom: Bei Schreiblasten oder vollen Backups steigt die System-CPU-Auslastung auf über 80% (System Context).
• Ursache: Zu aggressive Komprimierung (gzip-9) oder eine sehr hohe Dedupe-Write-Rate, die Hashing-Operationen erfordert.
• Lösung: Umstellen auf den Algorithmus mit der geringsten CPU-Last (lz4). Falls ZSTD verwendet wird, die Kompressionsstufe reduzieren (z.B. von zstd-6 auf zstd-3).

# 3. Symptom C: Unlogische Speicherplatzauslastung

• Symptom: Trotz hoher Dedupe-Ratio zeigt df -h nicht die erwartete Platzersparnis.
• Ursache: Der Befehl df -h liest die physische Auslastung. Die effektiven Ratios sehen Sie nur über zfs list oder zpool list. Zudem können Snapshots massive Mengen an Shared Blocks halten, die die Dedupe-Ratio logisch hochhalten, aber physisch den Platz binden.
• Lösung: Regelmäßig alte Snapshots bereinigen. Der Speicherplatz wird erst freigegeben, wenn der letzte Block-Pointer auf diesen deduzierten Block entfernt wird (entweder durch Löschen der Datei oder des Snapshots).

# Recovery Szenarien

Metadata Corruption: Bei kritischen Problemen (oft durch Hardwarefehler im RAM oder Controller verursacht) können ZFS-Metadaten korrumpiert werden. Da die DDT Teil der Metadaten ist, ist hier höchste Gefahr.

graph TD
    A[Datenzugriff fehlerhaft/Pool offline] --> B{Pool Metadata Corruption?};
    B -- Ja --> C[zpool status -v prüfen];
    C --> D{Können wir scrub starten?};
    D -- Nein --> E[Versuch mit zpool import -F (force)];
    E --> F[Wenn import fehlschlägt: zpool import -F -X (extreme force)];
    F --> G[Letztes funktionierendes Backup nutzen];
    D -- Ja --> H[zpool scrub (Datenintegritätsprüfung)];
    H -- Erfolg --> I[System läuft wieder];

    style E fill:#f99,stroke:#333
    style F fill:#f00,stroke:#333

# 6. Monitoring & Alerting

Die Überwachung muss sowohl die Effizienz (Ratio) als auch die Stabilität (DDT RAM Usage) abdecken.

# Metriken: Key Performance Indicators (KPIs)

1. Deduplication Ratio (DDR) und Compression Ratio (CR): Misst die Effizienz. Wenn die DDR plötzlich sinkt, deutet dies auf eine Änderung der Datenstruktur hin (z.B. Verschlüsselung der Quell-Daten, die die Deduplizierung unmöglich macht).
   • Tool: zfs get compressratio,dedup <dataset>
2. ARC Hit Ratio: Der Prozentsatz der Cache-Anfragen, die im RAM (ARC) beantwortet werden. Ein niedriger ARC-Hit-Ratio bei Dedupe-Datasets ist ein Frühwarnzeichen für den ‘Dedupe Trap’. Muss über 95% liegen.
   • Tool: /proc/spl/kstat/zfs/arcstats (speziell hits vs. misses).
3. DDT Size vs. Free RAM: Die absolute Größe der DDT muss bekannt sein. Ein Alarm muss ausgelöst werden, wenn die geschätzte DDT-Größe (über ZFS-Tools) 75% des verfügbaren ARC-RAMs überschreitet.
   • Tool: zpool iostat -v (um die I/O-Statistiken der VDEVs zu sehen) und arcstats.
4. CPU Utilization (System Time): Spikes im Kernel-CPU-Verbrauch können auf intensive Kompressions-/Hashing-Vorgänge hindeuten.

# Alerting-Regeln

• Kritisch (Pager Alert): ARC Hit Ratio fällt unter 90% für mehr als 15 Minuten.
• Warnung: DDR oder CR sinken um 20% in 24 Stunden (Indikator für eine geänderte Workload).
• Warnung: zpool scrub meldet erhöhte Fehlerzahlen (SDC erkannt).

# Prometheus Exporter Config (Auszug)

Wir nutzen den zfs-exporter um wichtige Metriken zu exportieren:

# Prometheus Alert Rule Beispiel
groups:
- name: zfs_storage_alerts
  rules:
  - alert: ZFSDedupeThrashing
    expr: |
      (rate(zfs_arc_stats_misses{type="DDT_lookup_misses"}[5m]) / 
       rate(zfs_arc_stats_hits{type="DDT_lookup_hits"}[5m]) * 100) > 10
    for: 15m
    labels:
      severity: critical
    annotations:
      summary: "Deduplication Cache Thrashing Detected"
      description: "Hohe DDT Cache Miss Rate deutet auf RAM-Mangel für die Deduplication Table hin. Absturz droht."

# 7. Fazit & Empfehlung

Wann würde ich es einsetzen?

• Komprimierung (LZ4/ZSTD): Immer. Der I/O-Vorteil (weniger Daten müssen von der Platte gelesen/geschrieben werden) übersteigt den geringen CPU-Overhead in 99% der Fälle.
• Deduplizierung: Nur in klar definierten Szenarien:
  1. Backup-Targets mit hoher täglicher Redundanz.
  2. VDI-Umgebungen (identische Betriebssysteme).
  3. Archivspeicher von Logs oder Metadaten.

Wann würde ich es nicht einsetzen?

• Zufällig verteilte, bereits komprimierte/verschlüsselte Daten: (z.B. JPGs, Videos, verschlüsselte Datenbanken). Hier ist die Deduplizierungs-Ratio nahezu 1.0x, der Overhead für Hashing und DDT-Verwaltung ist reiner Performance-Verlust.
• Latency-kritische Datenbanken (OLTP): Die zusätzlichen Hashing- und DDT-Lookup-Schritte können die Schreiblatenz inakzeptabel erhöhen, selbst mit viel RAM.

Ausblick: Neuere ZFS-Versionen verbessern die Verwaltung des DDT-Speichers und führen effizientere Algorithmen ein (z.B. dedup=sha256,verify als Standard für höhere Sicherheit), aber die Grundregel bleibt: RAM ist der limitierende Faktor für Deduplizierung.

# Anhang: Cheatsheet

# Referenzen

• OpenZFS Documentation: Deduplication
• ZFS Performance Tuning Guide (ARC & L2ARC)
• The Deadly ZFS Deduplication Trap (Blogpost) (Empfohlene Lektüre!)
• man zfs / man zpool (immer die aktuell installierte Version konsultieren)