Stratis e Virtual Data Optimizer (VDO): la compressione online e deduplica integrata in LVM su Red Hat Enterprise Linux 9 che non sapevate di avere
Come avevamo menzionato alcune settimane fa, la nuova release di Red Hat Enterprise Linux porta con sè diverse novità in vari ambiti, tra cui la sicurezza, ma anche lato storage vi sono delle differenze che potrebbero essere sfuggite a chiunque non sia andato a leggere le release notes.
RHEL 9, purtroppo, non supporterà il filesystem di nuova generazione btrfs nonostante esso sia oggetto di nuove e frequenti migliorie, sia ormai stato da anni implementato di default su SUSE Linux Enterprise e lo sia ancora persino su Fedora stessa, da cui ogni nuova release di Red Hat prende forma.
Non sappiamo se avverrà un retro front nelle prossime versioni ma, alla base della scelta, sembra esserci la volontà di offrire Stratis, il nuovo demone di configurazione filesystem e volumi scritto in Rust che combina tecnologie Linux già mature e presenti da più di un decennio come device mapper, XFS e lvm e che, attualmente, è presente nella release come technology preview.
Esso è un’interessante implementazione, per quanto ancora neonata, di feature e concetti normalmente afferenti soltanto a filesystem avanzati come ZFS e btrfs, i quali mettono in tavola tecnologie come compressione trasparente, deduplica dei dati, copy-on-write, snapshotting e creazione di raid software.
Stratis è ancora un progetto work in progress e non offre ancora tutte le feature appena listate. Alcune delle feature non ancora offerte da Stratis sono compressione trasparente e data deduplication ma, se queste dovessero servirvi adesso e non potete o volete utilizzare i fileystem appena menzionati, si può far affidamento a Virtual Data Optimizer (VDO), già presente nelle precedenti release di Red Hat ma che è ora stato reso parte integrante del gestore dei volumi linux (LVM).
Purtroppo le 2 tecnologie non sono, al momento, combinabili tra di loro ed è ancora assente la possibilità di poter avere un checksumming di ogni blocco dati per assicurare l’assoluta integrità dei dati nel tempo e prevenire problemi di bit-rot, feature presenti in btrfs e ZFS, ma si tratta sicuramente di un passo nella direzione giusta che risponde alla moderna esigenza di avere qualcosa di più di un semplice filesystem.
Tra gli obiettivi di Stratis c’è, comunque, l’idea di avere una gestione da riga di comando facile e intuitiva. Scettici? Vediamoli brevemente all’opera in uno scenario di esempio.
La situazione da cui partiamo è quella di un’istanza virtualizzata di Red Hat Enterprise Linux 9 appena installata, con 3 dischi virtuali aggiuntivi vuoti:
[root@server.lab.local redhat]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 252:0 0 70G 0 disk ├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 69G 0 part ├─rhel-root 253:0 0 44.3G 0 lvm / ├─rhel-swap 253:1 0 3.1G 0 lvm [SWAP] └─rhel-home 253:2 0 21.6G 0 lvm /home
vdb 252:16 0 250G 0 disk vdc 252:32 0 250G 0 disk vdd 252:48 0 250G 0 disk
Se volessimo iniziare a testare compressione e deduplica, quindi creando un lvm con il VDO, andremo, molto banalmente, a creare il physical volume su uno dei dischi per permetterci, subito dopo, di poter aggiungere un volume group e, infine, un logical volume che creeremo con VDO dal momento che, ricordiamo, adesso è parte integrante di LVM e basterà quindi usare una variante del solito comando lvcreate, che vi sarà sicuramente già familiare.
Scriveremo poi un filesystem e lo monteremo in una cartella qualunque per poterlo efffettivamente utilizzare.
Nella pratica:
[root@server.lab.local redhat]# pvcreate /dev/vdb Physical volume "/dev/vdb" successfully created. [root@server.lab.local redhat]# vgcreate vg-mmul /dev/vdb Volume group "vg-mmul" successfully created [root@server.lab.local redhat]# lvcreate --type vdo --name vdo-mmul --size=249G --virtualsize=2490G vg-mmul The VDO volume can address 246 GB in 123 data slabs, each 2 GB. It can grow to address at most 16 TB of physical storage in 8192 slabs. If a larger maximum size might be needed, use bigger slabs. Logical volume "vdo-mmul" created. [root@server.lab.local redhat]# mkfs.xfs /dev/vg-mmul/vdo-mmul -K
meta-data=/dev/vg-mmul/vdo-mmul isize=512 agcount=4, agsize=16090880 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=1 inobtcount=1
data = bsize=4096 blocks=64363520, imaxpct=25 = sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=31427, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0 [root@server.lab.local redhat]# mount /dev/vg-mmul/vdo-mmul /MMUL_VDO [root@server.lab.local redhat]# df -hT /MMUL_VDO
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/vg--mmul-vdo--mmul xfs 246G 1.8G 244G 1% /MMUL_VDO Come avrete notato, con –virtualsize ci è stato possibile presentare un volume più grande di quanto non sia realmente, cosa che abbiamo fatto poichè le dimensioni dei file che il sistema operativo vede continueranno a essere quelle naturali, anche se nella realtà essi non occuperanno così tanto dal momento che verranno compressi e deduplicati. Non è possibile prevedere in anticipo gli aspetti quantitativi della cosa in quanto non è generalmente possibile conoscere in anticipo quali dati verranno scritti, per cui, in questo caso, abbiamo seguito il suggerimento di Red Hat di presentare un volume 10 volte più grande di quanto non sia realmente, che sarà quindi di 2,5TB:
[root@server.lab.local redhat]# df -hT /MMUL_VDO
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/vg--mmul-vdo--mmul xfs 2.5T 18G 2.5T 1% /MMUL_VDOCreeremo adesso un file di esempio, con dati random, di 400MB:
[root@server.lab.local redhat]# dd if=/dev/urandom of=/MMUL_VDO/mmul-test-file bs=4M status=progress count=100
419430400 bytes (419 MB, 400 MiB) copied, 55 s, 7.6 MB/s 100+0 records in
100+0 records out
419430400 bytes (419 MB, 400 MiB) copied, 55.3566 s, 7.6 MB/s
E lo copieremo per un numero arbitrario di volte per far si che la deduplica entri in gioco ed eviti di scrivere nuovamente gli stessi dati ripetuti. Possiamo scegliere un numero arbitrario per testare il concetto e, volendo fare le cose in grande (ma non troppo), proveremo a generare 20.000 copie:
[root@server.lab.local MMUL_VDO]# time for i in {1..20000}; do cp /MMUL_VDO/mmul-test-file /MMUL_VDO/mmul-test-file-$i; done real 0m33.949s
user 0m8.389s
sys 0m25.799s [root@server.lab.local MMUL_VDO]# du --max-depth=1 -h /mnt
7.7T /mnt [root@server.lab.local MMUL_VDO]# df -hT /MMUL_VDO
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/vg--mmul-vdo--mmul xfs 2.5T 18G 2.5T 1% /MMUL_VDO [root@server.lab.local mnt]# vdostats --human-readable
Device Size Used Available Use% Space saving%
vg--mmul-vpool0-vpool 249.0G 3.6G 245.4G 1% 74%
Alcune cose avranno sicuramente colto la vostra attenzione: abbiamo scritto 7,7 terabyte di dati in 33 secondi (la nostra macchina è un comune desktop con dischi rotanti), il df continua a mostrare 18GB usati come all’inizio e, si, abbiamo 20.000 copie dello stesso file al ‘prezzo’ di una, in quanto tutte uguali. Il risparmio di spazio sarebbe stato simile anche se i file avessero avuto delle differenze, purchè minime, merito della deduplicazione dei dati a livello di blocco.
Dubbi? Non possiamo mostrarvi qui l’intero output di ls, ma possiamo darvi un assaggio mostrandovi le ultime 10 righe:
[root@server.lab.local MMUL_VDO]# ls -lh1v /MMUL_VDO | tail
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19991
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19992
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19993
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19994
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19995
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19996
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19997
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19998
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-19999
-rw-r--r--. 1 root root 400M Sep 2 16:50 mmul-test-file-20000Si, i file sono tutti lì, tutti e 20 mila da 400MB l’uno, che fanno 7,7TB in totale. Interessante, no? Gli use case per questa feature sono facilmente individuabili in ogni situazione in cui abbiamo file che tendono a ripetersi e a differire di poco tra loro, oppure file che incorporano lunghe sequenze che si ripetono.
Spostandoci, invece, su Stratis, si può iniziare molto facilmente in pochi secondi e, ricordiamo, non è al momento possibile combinarlo con il VDO, per cui useremo gli altri dischi della macchina virtuale che avevamo lasciato ancora inutilizzati.
Ciò che faremo è installare i due pacchetti, abilitare il servizio e creare un semplice pool, che faremo diventare un jbod di due dischi nel comando successivo per simulare un aggiunta avvenuta a posteriori. Come si può poi notare, troveremo già il tutto formattato in xfs:
[root@server.lab.local mnt]# dnf install -y stratis-cli stratisd Updating Subscription Management repositories.
Last metadata expiration check: 3:04:50 ago on Fri 02 Sep 2022 02:26:48 PM CEST.
Package stratis-cli-2.4.3-2.el9.noarch is already installed.
Package stratisd-2.4.2-3.el9.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete! [root@server.lab.local mnt]# systemctl enable --now stratisd [root@server.lab.local mnt]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
(...)
vdc 252:32 0 250G 0 disk vdd 252:48 0 250G 0 disk [root@server.lab.local mnt]# stratis pool create MMUL_POOL /dev/vdc [root@server.lab.local mnt]# stratis pool list
Name Total Physical Properties UUID
MMUL_POOL 250 GiB / 52.11 MiB / 249.95 GiB ~Ca,~Cr 535999d9-0f9d-485f-aba8-e0a69ab78e4d [root@server.lab.local mnt]# stratis pool add-data MMUL_POOL /dev/vdd [root@server.lab.local mnt]# stratis blockdev list MMUL_POOL
Pool Name Device Node Physical Size Tier
MMUL_POOL /dev/vdc 250 GiB Data
MMUL_POOL /dev/vdd 250 GiB Data [root@server.lab.local redhat]# mount /dev/stratis/MMUL_POOL/filesystem1 /MMUL_POOL [root@server.lab.local redhat]# df -hT /MMUL_POOL
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/stratis-1-535999d90f9d485faba8e0a69ab78e4d-thin-fs-1b6de4f44e524a79a531ff3f7f4a8f56 xfs 1.0T 7.9G 1016G 1% /MMUL_POOL
Ed ecco che, come annunciato, nello spazio di un minuto abbiamo creato un setup Stratis con più dischi, senza dover chiamare in causa altre utility come lvm o mdadm e senza dover attendere una lunga inizializzazione. Il nostro setup, infatti, è instantaneamente disponibile e può diventare anche parecchio complesso prevedendo, ad esempio, interi dischi come cache per casi d’uso avanzati.
Al momento
Se tutto ciò vi ha incuriosito, vista la complessità dell’argomento, vi rimandiamo all’esaustiva documentazione ufficiale, preannunciandovi soltanto che esso vi offrirà diverse feature che ricorderanno in tutto e per tutto ZFS con il quale non è ancora in parità di feature ma, se il progetto continua come ci aspettiamo, il gap dovrebbe colmarsi quanto prima e, perchè no, potremmo vedere presto delle funzionalità che non avevamo ancora visto su nessun filesystem, grazie alla facile espandibilità con cui è stato pensato.
Non è, comunque, un gioco a somma zero, poichè tra le tante cose che il mondo open source ci regala, ve n’è una che non finiremo mai di apprezzare: la possibilità di scegliere.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
