wikiVDO - Virtual Data Optimizer
VDO (Virtual Data Optimizer) ist ein Linux Device-Mapper-Target, das Inline-Deduplizierungs-, Komprimierungs- und Thin-Provisioning-Funktionen auf Blockebene bietet. VDO wird über LVM verwaltet und kann in jeden bestehenden Storage-Stack integriert werden.
Zentrale Funktionen
VDO bietet als zentrale Funktionen:
- Deduplizierung
- Komprimierung
- Thin-Provisioning
VDO arbeitet dabei für Anwandungen vollständig transparent. Alle drei Funktionen sind für Anwendungen, die den Speicher nutzen, unsichtbar. Die Anwendungen lesen und schreiben Blöcke genau so, als wenn VDO nicht vorhanden wäre.
Deduplizierung
Deduplizierung verringert den erforderlichen Speicherplatz, indem Kopien von doppelten Blöcken entfernt werden.
Wenn Daten mehrmals gespeichert werden, werden bereits vorhandene Daten durch die Inline-Deduplizierung erkannt. Anstatt die Daten ein weiteres Mal zu schreiben, wird nur ein Verweis auf den ursprünglichen Block gespeichert.
Beispiel:
- Ein Foto (Auto.jpg, 5 MB Dateigröße) ist bereits gespeichert.
- Dieses Foto wird nun in einer Präsentation eingebaut und ein PDF daraus generiert. Die Größe des PDF ist um 5 MB größer als zuvor.
- Der tatsächlich physisch belegte Speicherplatz wächst durch das Einbauen des Fotos in die Präsentation jedoch kaum. Durch die Deduplizierung wurden nur Verweise auf die bereits vorhandenen Datenblöcke des Bildes geschrieben.
VDO verwaltet eine Zuordnung von logischen Blockadressen zu physischen Blockadressen auf der Speicherschicht unter VDO. Nach der Deduplizierung können mehrere logische Blockadressen auf dieselbe physikalische Blockadresse abgebildet werden. Diese werden als Shared Blocks bezeichnet.
Wenn ein gemeinsam genutzter Block überschrieben wird, wird ein neuer physischer Block für die Speicherung der neuen Blockdaten zugewiesen.
Komprimierung
Zur weiteren Datenreduzierung verwendet VDO eine verlustfreie Datenkomprimierung. Einzelne Blöcke werden dabei mit Hilfe von Kodierungsalgorithmen verkleinert.
Bei der VDO-Komprimierung werden die Blöcke mit dem LZ4-Algorithmus[1] komprimiert und nach Möglichkeit so zusammengefasst, dass mehrere komprimierte Blöcke in einen einzigen 4-KB-Block auf dem zugrunde liegenden Speicherplatz passen.
LZ4 bietet einen guten guten Kompromiss zwischen Geschwindigkeit und Kompressionsverhältnis. In der Regel hat er zwar ein geringeres (d.h. schlechteres) Kompressionsverhältnis als der ähnliche LZO-Algorithmus. Dafür hat LZ4 sowohl höhere Komprimierungs- als auch Dekomprimierungsgeschwindigkeiten. LZ4 kommt neben VDO auch z.B. bei Open-ZFS[2] oder SquashFS[3] zum Einsatz.
Thin-Provisioning
Thin Provisioning verwaltet die Zuordnung von logischen Blockadressen, die von VDO präsentiert werden, zu den Adressen des darunter liegenden Speichers. Dabei werden auch alle Blöcke mit Nullen eliminiert.
Begriffe
Slab
Der physische Speicher von VDO Volumes ist in eine Reihe von Slabs ("Scheiben") unterteilt:[4]
- Jeder Slab ist ein zusammenhängender Bereich des physischen Speichers.
- Alle Slabs eines Datenträgers haben die gleiche Größe (beliebige Potenz von 2 zwischen 128 MB bis zu 32 GB).
- Die Standardgröße eines Slabs ist 2 GB, um die Evaluierung von VDO auf kleineren Testsystemen zu erleichtern.
- Ein einzelner VDO-Datenträger kann bis zu 8.192 Slabs haben. In der Standardkonfiguration mit 2-GB-Slabs beträgt der maximal zulässige physische Speicher daher 16 TB.
- Bei der Verwendung von 32-GB-Slabs beträgt der maximal zulässige physikalische Speicher 256 TB.
- VDO reserviert immer mindestens einen ganzen Slab für Metadaten, so dass der reservierte Slab nicht für die Speicherung von Nutzdaten verwendet werden kann.
- Die Slab-Größe hat keinen Einfluß auf die Performance des VDO-Volumes.
| Eigenschaft | Wert |
|---|---|
| Größe eines Slabs | 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB |
| Anzahl an Slabs | 2 bis 8.192 |
| Maximal zulässiger physischer Speicher | 256 TB (bei 8.192 Slabs á 32 GB) |
Universal Deduplication Service (UDS)
Der Deduplizierungsindex (genannt UDS) wird zum Auffinden doppelter Daten verwendet.
VDO wurde entwickelt, um doppelte Daten effizient zu identifizieren. Dabei nutzt es einige gemeinsame Merkmale doppelter Daten (aus empirischen Beobachtungen):[5]
- In den meisten Datensätzen, die eine signifikante Menge an Duplikaten enthalten, sind die Duplikate in der Regel zeitlich lokalisiert. Wenn ein Duplikat entdeckt wird, ist es wahrscheinlicher, dass weitere Duplikate entdeckt werden und dass diese Duplikate ungefähr zur gleichen Zeit geschrieben wurden. Aus diesem Grund werden die Datensätze im Index in chronologischer Reihenfolge gespeichert.
- Die zweite Erkenntnis ist, dass neuere Daten eher jüngere Daten duplizieren als ältere Daten und dass es im Allgemeinen immer weniger sinnvoll ist, weiter in die Vergangenheit zu schauen. Wenn der Index voll ist, sollten daher die ältesten Datensätze gelöscht werden, um Platz für neue Datensätze zu schaffen.
Beim Indexdesign geht es darum, durch Deduplizierung Speicherplatz zu reduzieren. Dabei muss ein Kompromiss zwischen dem eingesparten Speicherplatz und dem Aufwand gefunden werden. Es reicht daher, die meisten Redundanzen zu entfernen.
Metadaten Anforderungen
Jedes vdo-Volume reserviert 3 GB Speicherplatz für Metadaten, je nach Konfiguration auch mehr.[6] Es ist sinnvoll zu prüfen, ob der durch Deduplizierung und Komprimierung eingesparte Platz nicht durch den Bedarf an Metadaten wieder aufgehoben wird. Eine Schätzung der Platzersparnis für einen bestimmten Datensatz kann mit dem vdo estimator Tool berechnet werden, das unter folgender Adresse verfügbar ist:
Platzierung von LVM-VDO im Storage Stack
VDO fügt sich wie andere Device Mapper Target im Linux Storage Stack ein.
Da VDO eine Deduplizierung, Komprimierung und Thin-Provisioning durchführt, werden diese Funktionen automatisch für alle Schichten, die auf VDO aufsetzen, genutzt.
Um negative Effekte auszuschließen, sollen daher die folgenden Targets nur unterhalb von VDO verwendet werden:
- DM Crypt
- Software RAID (LVM oder MD RAID)
Da LVM-VDO seinen deduplizierten Speicher als reguläres logisches Volume (LV) darstellt, kann es mit Standard-Dateisystemen und auch als iSCSI-/FC-/NVMe Target verwendet werden.
LVM-VDO Volume erstellen
Das folgende Beispiel zeigt die Erstellung eines virtuellen Volumes mit 100 GB (bei 40 GB tatsächlich verfügbaren physischen Speicher).
lvcreate
Mit lvcreate --type vdo kann ein VDO Volume erstellt werden:
tk@lmde:~$ sudo lvcreate --type vdo --name vdo-test --size 40G --virtualsize 100G vg-sata
The VDO volume can address 36.00 GB in 18 data slabs, each 2.00 GB.
It can grow to address at most 16.00 TB of physical storage in 8192 slabs.
If a larger maximum size might be needed, use bigger slabs.
Logical volume "vdo-test" created.
tk@lmde:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 223,6G 0 disk
└─sda1 8:1 0 223,6G 0 part
└─vg--sata-vpool0_vdata 254:0 0 40G 0 lvm
└─vg--sata-vpool0-vpool 254:1 0 100G 0 lvm
└─vg--sata-vdo--test 254:2 0 100G 0 lvm
nvme0n1 259:0 0 111,8G 0 disk
├─nvme0n1p1 259:1 0 286M 0 part /boot/efi
├─nvme0n1p2 259:2 0 8,2G 0 part [SWAP]
└─nvme0n1p3 259:3 0 103,3G 0 part /
Dateisystem erstellen
Das Erstellen eines Ext4 Dateisystems dauert ohne weitere Konfiguration ca. 19 Sekunden am Testsystem:
tk@lmde:~$ time sudo mkfs.ext4 /dev/vg-sata/vdo-test mke2fs 1.47.0 (5-Feb-2023) Discarding device blocks: done Creating filesystem with 26214400 4k blocks and 6553600 inodes Filesystem UUID: 801ce445-1bd4-4414-b41f-e694fa0704ce Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 Allocating group tables: done Writing inode tables: done Creating journal (131072 blocks): done Writing superblocks and filesystem accounting information: done real 0m18,591s user 0m0,010s sys 0m0,001s
Der Grund für diese lange Dauer ist die bislang noch limitierte Performance bei Discard/Trim Operationen.[7] Bei Verwendung der Option mkfs.ext4 -E nodiscard dauert das Erstellen < 1 Sekunde.
Statistiken
Das folgende Beispiel zeigt, dass beim Kopieren von Daten nur wenige zusätzliche physische Blöcke belegt werden:
tk@lmde:~$ sudo mount /dev/mapper/vg--sata-vdo--test /mnt tk@lmde:~$ sudo dd if=/dev/urandom of=/mnt/testfile-1.bin bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 2,03686 s, 527 MB/s tk@lmde:~$ sync tk@lmde:~$ sudo vdostats Device 1k-blocks Used Available Use% Space saving% vg--sata-vpool0-vpool 41943040 5274020 36669020 13% 67% tk@lmde:~$ sudo cp /mnt/testfile-1.bin /mnt/testfile-2.bin tk@lmde:~$ sudo cp /mnt/testfile-1.bin /mnt/testfile-3.bin tk@lmde:~$ sudo cp /mnt/testfile-1.bin /mnt/testfile-4.bin tk@lmde:~$ sudo cp /mnt/testfile-1.bin /mnt/testfile-5.bin tk@lmde:~$ sync tk@lmde:~$ sudo vdostats Device 1k-blocks Used Available Use% Space saving% vg--sata-vpool0-vpool 41943040 5279324 36663716 13% 85%
Geschichte
VDO wurde ursprünglich von Permabit Technology als proprietäre Kernel-Module und Userspace-Tools entwickelt. Rad Hat hat im Juli 2017 die Firma und Technologie gekauft und die Software unter der GPL neu lizenziert.[8] Das Kernelmodul wurde schließlich als dm-vdo in den Linux Kernel 6.9 integriert. Zuvor war es als out-of-tree modul kvdo im Einsatz.
Weitere Informationen
- vdo (github.com/dm-vdo/vdo)
Einzelnachweise
- ↑ LZ4 (compression algorithm) (en.wikipedia.org)
- ↑ OpenZFS Compression and Encryption (klarasystems.com)
- ↑ SquashFS (docs.kernel.org)
- ↑ Slab size in VDO (docs.redhat.com)
- ↑ Design of dm-vdo (docs.kernel.org/admin-guide)
- ↑ dm-vdo (docs.kernel.org/admin-guide)
- ↑ man 7 lvmvdo (man7.org) The performance of TRIM/Discard operations is slow for large volumes of VDO type. Please try to avoid sending discard requests unless necessary because it might take considerable amount of time to finish the discard operation.
- ↑ Red Hat Acquires Permabit Assets, Eases Barriers to Cloud Portability with Data Deduplication Technology (redhat.com, 31.07.2017)
 |
Autor: Werner Fischer Werner Fischer arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.
|
