Il block storage è il modo più diretto per dare a un server un “disco” che non vive fisicamente dentro la macchina. Dal punto di vista del sistema operativo si presenta come un device a blocchi, quindi lo puoi partizionare, formattare, montare e usare come un normale volume locale. La differenza è che dietro non c’è necessariamente un SSD nel server: spesso c’è uno storage di rete, una SAN, un backend cloud o un cluster distribuito che espone volumi persistenti separati dal nodo di calcolo.
Questa distinzione conta più di quanto sembri. Se separi storage e compute, puoi spostare workload, fare snapshot, ridimensionare capacità e ricostruire server senza perdere dati. Però sposti anche la complessità: latenza, throughput, failover, consistenza e policy di backup diventano parte dell’architettura, non dettagli secondari.
Che cosa significa davvero “block”
Un volume block non ti offre file già pronti o oggetti con metadati accessibili via API, ma una sequenza di blocchi numerati. Il file system sta sopra quel device e decide come organizzare directory, inode, journal e blocchi liberi. In pratica il block storage è la base grezza su cui costruisci tutto il resto.
Questo modello è il motivo per cui il block storage è usato per database, VM disk, volumi applicativi, filesystem condivisi indiretti e sistemi che richiedono controllo stretto su layout e performance. Se ti serve un mount point con semantica POSIX, il block storage è spesso la scelta più naturale. Se invece ti servono molti file piccoli, accesso multi-client o integrazione nativa con oggetti, potresti essere fuori strada.
Tre proprietà che devi avere chiare
Come funziona su un server Linux
Il flusso tipico è semplice: il provider o il cluster storage espone un volume, il kernel lo vede come device a blocchi, tu lo inizializzi con una tabella partizioni o direttamente con un filesystem, poi lo monti nel punto desiderato. Da quel momento il server usa quel volume come storage persistente.
Il punto critico è che il device può apparire “locale” anche quando non lo è. Un `lsblk` mostra un disco, ma non ti dice nulla sulla distanza logica dal backend, sulla replica, sul percorso di rete o sul comportamento in failover. Per l’operatore conta saper leggere i segnali giusti: latenza I/O, errori di timeout, reset del path, congestione del backend, throttling e degrado del filesystem.
Verifiche minime sul server
Quando vuoi capire se un volume è davvero quello atteso, parti da qui:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT,MODEL,SERIAL,TYPEblkiddf -hTSe il volume è presente ma non montato, controlla anche la gerarchia dei device e l’eventuale uso di LVM:
pvs; vgs; lvs -a -o +devicesIl dato utile non è solo “c’è o non c’è”. Devi capire se il device è online, se il filesystem è coerente, se il mount point è quello corretto e se la capacità disponibile corrisponde alla policy prevista.
Perché il block storage piace ai server applicativi
La ragione è banale: dà controllo. Con un volume block scegli filesystem, opzioni di mount, dimensionamento, RAID software o LVM, snapshot e strategia di crescita. Per un database questo è spesso più importante della comodità di un file share o di un oggetto remoto.
Un DB su block storage può usare un filesystem journaling ben noto, oppure andare quasi in raw device se il motore lo preferisce. Un server web può tenerci upload, cache persistente, code o contenuti che devono sopravvivere a un rebuild del nodo. Una VM può usare volumi block come dischi virtuali e beneficiare di snapshot coerenti lato storage.
Il vantaggio vero è architetturale: separi il ciclo di vita della macchina da quello dei dati. Puoi rifare un server da zero e riagganciare i volumi. In ambienti dove il nodo è effimero ma i dati non lo sono, questa è la differenza tra operatività e caos.
Limiti pratici: latenza, IOPS e colli di bottiglia
Il block storage non è magia. Se il backend è remoto, ogni I/O attraversa una rete, un layer di controllo e spesso un sistema di replica. Il risultato è che la latenza media e soprattutto la coda di attesa possono crescere rapidamente sotto carico.
Qui conviene ragionare su metriche concrete. Per un database o un servizio sensibile, non basta la banda teorica. Devi guardare almeno p95 latency, IOPS sostenuti, queue depth e percentuale di errori I/O. Se il volume ha buone prestazioni in idle ma degrada appena saturi il backend, il problema non è “il disco lento”: è il disegno del throughput o il profilo del carico.
Un esempio tipico: un volume cloud da 100 GB può offrire un certo numero di IOPS di base, ma se l’applicazione fa molte scritture sync o fsync frequenti, il collo di bottiglia arriva prima del previsto. In questi casi il tuning del filesystem aiuta solo fino a un certo punto; spesso serve cambiare classe di volume, aumentare la capacità per ottenere più IOPS o ripensare il pattern di scrittura.
Comandi utili per misurare
Per una verifica rapida del comportamento I/O, `iostat` e `fio` sono i primi strumenti sensati:
iostat -xz 1fio --name=randread --filename=/mnt/dati/testfile --size=1G --rw=randread --bs=4k --iodepth=16 --numjobs=1 --time_based --runtime=60 --group_reportingSe `await` sale molto rispetto alla media attesa o il device mostra saturazione costante, hai un segnale forte che il blocco storage non regge il profilo d’uso. L’interpretazione va sempre fatta insieme al carico applicativo: un volume può essere sano ma inadatto a quel workload.
Snapshot, clone e backup non sono la stessa cosa
Lo snapshot è una fotografia puntuale del volume, utile per rollback rapidi e clonazione. Non è automaticamente un backup. Se lo storage sottostante si corrompe, se perdi il dominio di storage o se cancelli il volume e i suoi metadati, lo snapshot può sparire con lui.
Un backup serio vive in un dominio separato, con retention diversa e test di restore. Il block storage rende gli snapshot comodi, ma proprio per questo induce a confonderli con la protezione dati. È un errore classico. Lo snapshot è una misura operativa, il backup è una misura di sopravvivenza.
In pratica: snapshot prima di patch o change rischiosi, backup per disaster recovery e retention normativa. Se usi LVM, ZFS, storage cloud o SAN, il principio non cambia. Cambia solo il meccanismo tecnico con cui lo realizzi.
Sequenza prudente prima di un change
Block storage locale, SAN e cloud: stesso concetto, rischi diversi
Il termine è lo stesso, ma l’implementazione cambia parecchio. Su un server con dischi locali, il blocco storage coincide con hardware interno o con un array locale. Su una SAN, il volume arriva da una rete dedicata e può essere presentato a più host con regole precise. Nel cloud, il volume è quasi sempre un servizio gestito con limiti, classi di performance e API di attach/detach.
Questo significa che la domanda non è solo “dove sta il dato?”, ma anche “chi controlla il failure domain?”. Un disco locale fallisce in modo relativamente semplice: perdi quel server o quel disco. Un backend condiviso, invece, introduce dipendenze di piattaforma, percorsi di rete, orchestrazione e policy del provider. In cambio ottieni flessibilità e, spesso, replica automatica.
Su cloud, il volume può essere scollegato da una VM e ricollegato a un’altra in pochi minuti. È una caratteristica comoda per manutenzione e recovery, ma impone disciplina: il filesystem deve essere consistente, il servizio fermato correttamente e il mount point verificato prima di riaprire il traffico.
Filesystem sopra il volume: scelta tecnica, non dettaglio secondario
Il block storage diventa utile davvero quando scegli il filesystem in funzione del carico. Ext4 resta una scelta solida per molti casi generici. XFS è spesso preferito per file grandi, crescita dinamica e carichi con molta concorrenza. Altri scenari richiedono logiche diverse, ma il principio resta uguale: il filesystem deve adattarsi al profilo di accesso, non il contrario.
Se il volume è destinato a database o applicazioni con scritture sensibili, devi considerare journaling, barrier, mount options e comportamento in crash recovery. Non esiste una combinazione perfetta per tutto. Esiste la combinazione meno sbagliata per quel workload.
Un controllo pratico che vale sempre è questo:
mount | grep -E ' /mnt/dati | /var/lib/'cat /etc/fstabQui verifichi se il mount è persistente, se le opzioni sono quelle previste e se un reboot ti riporterà esattamente nello stato atteso. È un controllo noioso, ma evita più incidenti di quanto si ammetta volentieri.
Rischi operativi tipici
Il primo rischio è montare il volume sbagliato. Succede quando i device cambiano nome dopo un reboot o quando si confida troppo in `/dev/sdX` senza usare UUID o label. Il secondo è corrompere i dati per attach multiplo non previsto: un volume pensato per un solo writer non va condiviso a caso. Il terzo è scoprire troppo tardi che il backend ha limiti di performance inferiori al carico reale.
Per ridurre questi rischi, usa identificatori stabili, documenta il mapping tra volume e servizio, e controlla sempre il comportamento al reboot. Se hai automazione, il file `/etc/fstab` o la configurazione del servizio di mount deve essere versionata come codice, non trattata come nota a margine.
Un minimo di hardening aiuta anche qui: permessi stretti sul mount point, niente servizi che scrivono dove non dovrebbero, monitoring su spazio libero e latenza I/O, e alert su errori del kernel legati allo storage.
Quando il block storage è la scelta giusta
È la scelta giusta quando ti serve un disco persistente, montabile, controllabile e riattaccabile. È particolarmente adatto a VM, database, volumi applicativi, filesystem persistenti e migrazioni in cui separare dati e calcolo semplifica il ciclo di vita del server.
Non è invece la risposta universale. Se hai bisogno di accesso multi-regione nativo, condivisione massiva di file o semantica oggetti, probabilmente stai cercando un altro livello di storage. Il blocco storage è forte quando vuoi un disco; è meno naturale quando vuoi un servizio di contenuti.
La regola pratica è questa: se il carico ragiona bene in termini di filesystem locale ma vuoi che quel filesystem sopravviva al server, il block storage è quasi sempre il candidato da valutare per primo.
Checklist operativa da tenere a portata di mano
Se queste sei condizioni non sono coperte, il block storage è già in uso ma non ancora sotto controllo. Ed è una differenza che in produzione si paga presto.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.