Come avevamo menzionato alcune settimane fa, la nuova release di RHEL 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 due 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:
[[email protected] 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 diskSe 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:
[[email protected] redhat]# pvcreate /dev/vdb Physical volume "/dev/vdb" successfully created. [[email protected] redhat]# vgcreate vg-mmul /dev/vdb Volume group "vg-mmul" successfully created [[email protected] 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. [[email protected] 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 [[email protected] redhat]# mount /dev/vg-mmul/vdo-mmul /MMUL_VDO [[email protected] 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_VDOCome 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:
[[email protected] 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:
[[email protected] 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/sE 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:
[[email protected] 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 [[email protected] MMUL_VDO]# du --max-depth=1 -h /mnt 7.7T /mnt [[email protected] 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 [[email protected] 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:
[[email protected] 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:
[[email protected] 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! [[email protected] mnt]# systemctl enable --now stratisd [[email protected] mnt]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS (...) vdc 252:32 0 250G 0 disk vdd 252:48 0 250G 0 disk [[email protected] mnt]# stratis pool create MMUL_POOL /dev/vdc [[email protected] 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 [[email protected] mnt]# stratis pool add-data MMUL_POOL /dev/vdd [[email protected] 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 [[email protected] redhat]# mount /dev/stratis/MMUL_POOL/filesystem1 /MMUL_POOL [[email protected] 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_POOLEd 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.
English (US)