Home > NetApp > Storage Compression

Storage Compression

NetApp Storage Compression und Deduplication richtig einsetzen

NetApp bietet, wie andere Storage Hersteller auch, Storage Compression an. Im Unterschied zu den meisten anderen Anbietern, kennt NetApp aber zwei Arten von Compression. Wir haben uns diese im Zusammenhang mit der Oracle Datenbank genauer angesehen und die Erkenntnisse zusammengefasst.

NetApp Deduplication

Die Deduplizeriung bei NetApp basiert auf WAFL Blöcken, welche 4k groß sind. Wird ein IDENTER Block erkannt, werden die überflüssigen Kopien freigegeben und nur noch eine Version des Blocks aufbehalten. Die Deduplizierung erfolgt bis 8.3.x mittels JOB, der auf der NetApp von Zeit zu Zeit läuft und wurde mit ab 9.0 komplett auf einen inline Prozess umgestellt.

Da Oracle Datenbank Blöcke eindeutige Blocknummern in jedem Block haben, sind Datenbanken selbst nicht deduplizierbar. Lediglich RMAN Backups von Datenbankfiles, die nicht komprimiert oder verschlüsselt sind, lassen sich auf diese Weise platzsparend unterbringen.

Deduplication eignet sich optimal für Virtualisierung, da beispielsweise die viele Blöcke vom Betriebsystem in mehreren/vielen VMs vorkommen.

NetApp Data Compression (für HDD und SSD) - auch Secondary Compression genannt

Ebenfalls schon lange verfügbar ist die normale Data Compression. Hier werden Bereiche von bis zu 32k mittels Komprimierung (Zippen) entsprechend auf weniger Blöcke komprimiert. Beim Lesen dieses Bereiches muss die CPU der Storage entsprechend Dekomprimieren. Diese Art der Datenkomprimierung kann wahlweise Inline (ab ONTAP 8.2) oder mittels Jobs (wie Deduplication) eingesetzt werden - im Fall von All Flash FAS Systemen ab ONTAP 9.0 per Default ebenfalls Inline. Es gibt auch einen Mindestfaktor für die Komprimierungsrate - wird diese nicht erreicht (Default = 25%) werden die Daten unkomprimiert gespeichert.

Diese Art der Komprimierung eignet sich Ideal für Daten, die einmal geschrieben und vielleicht nie wieder gelesen werden (RMAN Backup, Archivelogs) oder für Tablespaces in in denen Daten archiviert werden - aber auch für große DWHs, die viele historische (Read Only) Daten enthalten.

NetApp Adaptive/Advanced Compression

Die erst mit ONTAP 8.3.1 eingeführte Adaptive/Advanced Compression arbeitet immer Inline (also direkt beim Schreiben) und arbeitet auf 8k Stücken, die entweder auf 4k komprimiert werden können oder 8k bleiben. Adaptive Compression ist bei All Flash FAS (nur SSDs) automatisch eingeschaltet. Wenn man HDD oder Hybrid Aggregate einsetzt, muss man Adaptive Compression explizit einschalten.

Der Vorteil von Adaptive Compression ist, dass man - abhängig von den Daten in der Datenbank - viele Oracle Datenbank Blöcke auf 4k komprimieren kann. Davon ausgenommen sind grundsätzlich BLOBs (Binäre Files), verschlüsselte Daten (Oracle TDE,...) aber auch mittels Oracle Compression Funktionalität (Table und Index Compression) komprimierte Bereiche.

Speziell bei All Flash FAS Lösungen ermöglicht die Inline Adaptive Compression eine deutliche Platzersparnis, die man schon während des Befüllens der Datenbank nutzen kann.

Oracle Datenbank Files und die Optimale Konfiguration von Compression und Deduplication bei NetApp Storages

Filetype NetApp Einstellungen Platzersparnis Anmerkung
Online Logfiles kein DEDUP, Advanced oder Data Compression 25-50% Da die Online Logfiles permanent überschrieben werden, macht die Out Of Line Compression/Deduplication keinen Sinn
Archivelogs kein DEDUP, Data Compression 20%-75% Blöcke von Archivelogs sind nicht deduplizierbar, lassen sich aber sehr gut komprimieren. Bei HDD Aggregaten ist die normale Data Compression sinnvoller (da besser komprimiert wird). Bei Flash Aggregaten lieber Advanced Compression, damit sofort komprimiert wird.
Datenbankfiles OLTP kein DEDUP, nur Advanced Compression 10%-30% Dedup auf Oracle Datenblöcke ist nicht möglich. Da Oracle speziell bei OLTP Applikationen immer 8k Blöcke schreibt, müsste die Storage sehr oft 32k Blöcke dekomprimieren um die alten Blöcke frei zu bekommen - das geht massiv auf die Storage CPU. Die meisten Oracle Blöcke lassen sich aber auf 4k komprimieren, womit Advanced Inline Compression optimal ist.
Datenbankfiles DWH kein DEDUP, Advanced oder Data Compression 25%-75% Dedup auf Oracle Datenblöcke ist nicht möglich. Da in DWH Daten normalerweise mittels Batchjobs im Bulk geladen werden, sind beide Komprimierungsarten nutzbar. Data Compression wird in den meisten Fällen eine höhere Komprimierung erreichen (aber eben nicht Inline).
verschlüsselte Datenbankfiles (TDE) kein DEDUP, keine Compression n/a Durch die Verschlüsselung reduziert sich die Komprimierbarkeit massiv. Bei unseren Tests die Platzersparnis meist so gering, dass der NetApp Compressionsjob meist nicht komprimiert hat.
Oracle Table/Index Compression kein DEDUP, keine Compression n/a Oracle Compression ist in Wirklichkeit eine "In-Block Deduplizierung", die allerdings meist effizient genug ist, dass die NetApp Komprimierung nicht mehr effizient Arbeiten kann.
RMAN Backupsets möglicherweise DEDUP, Advanced oder Data Compression 25%-75% Dedup wirkt nur, wenn man mehrere Backups der gleichen Files - zb: 2 oder 3 Generationen Datenbankbackups liegen lässt. Die normale Data Compression erreicht eine merklich bessere Komprimierung wie Advanced Compression, daher ist Data Compression sinnvoller.
RMAN Compressed Backupset möglicherweise DEDUP, keine Compression bis zu 25% Dedup wirkt nur, wenn man mehrere Backups der gleichen Files liegen lässt, sofern sich die Files nicht verändert haben - Filesperset muss sehr niedrig eingestellt sein (1-3)! Da die Daten schon komprimiert sind, machen weitere Komprimierungsversuche keinen Sinn.
Oracle Home (Software> Dedup und Advanced oder Data Compression deutlich über 30% Die Oracle Software, speziell wenn verschiedene Oracle Homes verschiedener Server auf dem gleichen Volumn liegen, lassen sich sehr gut Deduplizieren und komprimieren.

Damit Wiedersprechen wir teilweise den Ergebnissen von NetApps NetApp Data Compression and Deduplication Deployment and Implementation Guide, das liegt an mehreren Gründen:

  • Berechnungsweise: Mit der Platzersparnis geben wir an, wie viel Platz im Vergleich zur Originalgröße weniger benötigt wird. NetApp berechnet die Ersparnis indem Sie sagen wie viel erspart man sich für die Kopie (RMAN BACKUP) - das Original braucht den Platz aber trotzdem.
  • Datenbankfiles und Deduplication: NetApp behauptet, dass Deduplication auf Datenbankfiles eine Platzersparnis verspricht, dass konnten wir in keinem Fall nachvollziehen und entspricht auch nicht der Logic, da Oracle Datenbank Blöcke ja immer eine eindeutige Adresse enthalten und somit nicht ident sein können. Das wäre nur dann möglich, wenn man größere Datenbank Blöcke einsetzen würde und keine Daten in diesen Blöcken wären - eine nicht ganz realistische Annahme. Lediglich bei (fast) leeren Datenbankfiles kann Deduplizierung auch bei 4k Blocksize Platz sparen, da der "untere" Teil des Oracle Blocks nur den Blocktail enthält und dieser bei leeren Blöcken durchaus öfter vorkommen kann.

Erkenntnis

Durch den richtigen Einsatz von Komprimierung auf der Storage kann man den Footprint einer Oracle Datenbank deutlich reduzieren. In den meisten Fällen konnten wir den Platzverbrauch halbieren. Leider verhindert der Einsatz von Oracle Table/Index Compression, Backup Compression und TDE die Storage Komprimierung (das wird auch bei anderen Storage Herstellern nicht anders sein).

Referenzen