Storage Area Network (SAN): cos’è, come funziona e quando serve

Una Storage Area Network (SAN) è una rete specializzata che collega server e sistemi di storage e permette agli host di utilizzare risorse di archiviazione condivise come storage a blocchi. Il punto importante è proprio questo: una Storage Area Network non è semplicemente “un NAS più veloce” e non identifica nemmeno un singolo dispositivo.

È un’architettura composta da server, interfacce di accesso, rete storage, switch e sistemi di archiviazione che lavorano insieme per fornire ai workload uno storage condiviso con caratteristiche di prestazioni, disponibilità e gestione difficili da ottenere collegando ogni disco direttamente a un singolo server. La SNIA descrive una SAN come una rete specializzata ad alta velocità che può utilizzare tecnologie e protocolli differenti e che presenta lo storage all’host in modo simile a una risorsa collegata localmente.

Per capire se una Storage Area Network serve davvero, però, non basta fermarsi alla definizione. Bisogna capire che cosa vede il server, come attraversano la rete le operazioni di lettura e scrittura e quale problema stiamo cercando di risolvere.

Cos’è una Storage Area Network (SAN)

Una Storage Area Network separa lo storage dal singolo server e lo rende disponibile attraverso una rete dedicata o comunque progettata specificamente per il traffico di storage.

In una configurazione semplice puoi immaginare il percorso in questo modo:

server → interfaccia SAN → fabric di rete → sistema storage → volume logico

La differenza rispetto a uno storage locale è evidente. Se un disco è installato direttamente dentro un server, capacità e connettività appartengono a quella macchina. In una Storage Area Network, invece, un sistema storage centrale può mettere determinate risorse a disposizione di più host attraverso la rete.

Questo non significa che tutti i server possano accedere indiscriminatamente a tutti i dati. Una SAN reale utilizza meccanismi di configurazione e controllo che stabiliscono quali initiator possono raggiungere determinati target e quali risorse logiche devono essere presentate a ciascun host.

Perché una Storage Area Network non è semplicemente un NAS più veloce

SAN e NAS fanno entrambi parte dello storage collegato alla rete, ma risolvono il problema a livelli differenti.

Un NAS mette normalmente a disposizione file e cartelle attraverso protocolli di rete. Il client vede una condivisione e dialoga con un filesystem gestito dal NAS.

Una Storage Area Network, invece, presenta normalmente storage a blocchi. L’host riceve una risorsa che può apparire come un disco o volume disponibile localmente, anche se fisicamente i dati risiedono in uno storage array raggiunto attraverso la rete. La documentazione tecnica di SNIA sulle Storage Area Network e la panoramica di HPE sullo storage SAN distinguono questo modello di accesso dal file storage tipico di un NAS.

È questa differenza a spiegare gran parte delle conseguenze successive. Non stiamo semplicemente cambiando il mezzo di trasporto: cambia il livello al quale lo storage viene presentato al sistema operativo.

Anche per questo il confronto SAN vs NAS va letto prima di tutto come confronto tra modelli di accesso allo storage, non come una semplice gara fra dispositivi più o meno veloci.

Storage a blocchi, LUN e filesystem: cosa vede davvero il server

Il concetto di block storage può sembrare astratto finché non separi tre livelli che spesso vengono confusi: storage fisico, volume logico e filesystem.

Il sistema storage dispone di capacità fisica formata, per esempio, da SSD o altri supporti. Da questa capacità può creare risorse logiche che vengono presentate agli host. Nel mondo SAN incontrerai spesso il termine LUN, Logical Unit Number, usato nel contesto SCSI per identificare una logical unit.

Per il server quella risorsa non arriva normalmente come una cartella già pronta. Arriva come storage a blocchi.

Sarà poi il sistema operativo, l’hypervisor o un altro livello software a partizionare, formattare e utilizzare quella risorsa secondo il caso. È quindi sbagliato pensare alla Storage Area Network come al sistema che “contiene le cartelle”: la SAN fornisce il percorso e l’accesso allo storage, mentre la gestione del filesystem appartiene a un altro livello dell’architettura.

Questa separazione è fondamentale anche quando più server devono utilizzare storage condiviso. Il fatto che due host possano vedere una stessa risorsa a blocchi non significa automaticamente che possano montare e modificare contemporaneamente lo stesso filesystem tradizionale senza coordinamento. Cluster filesystem, hypervisor e applicazioni distribuite introducono regole proprie proprio per evitare corruzione o accessi concorrenti incompatibili.

Come funziona una Storage Area Network: dall’host allo storage

Per comprendere una Storage Area Network è utile seguire una richiesta di I/O invece di memorizzare un elenco di componenti.

Immagina un server che esegue un database. L’applicazione deve leggere alcuni blocchi dal volume su cui sono memorizzati i dati. La richiesta parte dal sistema operativo, attraversa lo stack storage dell’host e raggiunge l’interfaccia che collega il server alla SAN.

Da quel momento entra in gioco l’infrastruttura di storage networking.

Host, initiator e HBA o NIC

Dal punto di vista dei protocolli storage, l’host svolge normalmente il ruolo di initiator: è il sistema che avvia la comunicazione verso una risorsa storage.

L’interfaccia utilizzata dipende dalla tecnologia.

In un ambiente Fibre Channel può essere presente una HBA, Host Bus Adapter, progettata per collegare il server al fabric FC. In un ambiente iSCSI l’accesso può invece utilizzare interfacce Ethernet e un initiator software o hardware.

Questa distinzione ha conseguenze concrete.

Una Storage Area Network Fibre Channel dispone tipicamente di un’infrastruttura dedicata al traffico storage. iSCSI utilizza invece TCP/IP e può sfruttare tecnologie Ethernet comuni, pur richiedendo una progettazione della rete adeguata al carico e ai requisiti di disponibilità.

Dire quindi che “la SAN usa Fibre Channel” è troppo restrittivo. Fibre Channel è una delle tecnologie più importanti per le Storage Area Network, ma non è la definizione stessa di SAN. La SNIA include infatti differenti tecnologie di storage networking, fra cui fabric basati su Fibre Channel ed Ethernet.

SAN fabric, switch, target e storage array

Il fabric è il tessuto di connettività che permette agli initiator di raggiungere i target.

Nel caso Fibre Channel è normalmente composto da uno o più switch FC. I collegamenti non servono a trasportare il normale traffico web, email o navigazione degli utenti: sono progettati per collegare host e sistemi storage.

Sul lato opposto trovi il target, cioè l’endpoint che mette a disposizione le risorse storage.

Dietro al target può esserci uno storage array molto più complesso del semplice volume che vede il server: controller ridondanti, cache, pool di dischi, SSD, sistemi di protezione, snapshot, replica e funzioni di virtualizzazione dello storage possono essere completamente nascosti all’host.

Ed è proprio questo uno dei vantaggi architetturali della Storage Area Network: il server utilizza la risorsa assegnata senza dover conoscere ogni dettaglio del sistema fisico sottostante.

Cosa succede durante una lettura o una scrittura

Supponiamo che un’applicazione debba leggere un blocco.

L’host genera la richiesta attraverso il proprio stack di I/O. L’initiator la invia attraverso il percorso SAN appropriato; il fabric la trasporta verso il target; lo storage array identifica la risorsa logica richiesta e recupera i dati dal livello fisico sottostante. La risposta percorre poi il tragitto inverso.

Con iSCSI il modello SCSI viene trasportato sopra TCP/IP. La specifica RFC 7143 dedicata al protocollo iSCSI descrive il trasporto di comandi SCSI attraverso TCP e formalizza il rapporto tra initiator e target.

Il percorso può essere molto più sofisticato quando sono presenti più porte, controller e fabric. In quel caso l’host può disporre di più strade per raggiungere lo stesso storage. Il vantaggio non è soltanto prestazionale: con una progettazione corretta, la perdita di un percorso non rende necessariamente irraggiungibile il volume.

Fibre Channel, iSCSI e altri protocolli SAN

Una Storage Area Network non è legata a un solo protocollo. La scelta della tecnologia influenza hardware necessario, latenza, gestione, competenze e integrazione con l’infrastruttura esistente.

I due nomi che incontrerai più spesso sono Fibre Channel e iSCSI.

Fibre Channel

Fibre Channel è una tecnologia progettata specificamente per trasferimenti di dati ad alta velocità tra sistemi di calcolo e storage. Utilizza fabric dedicati e fornisce un trasporto ordinato dei dati a blocchi.

Nelle SAN enterprise è una scelta comune quando il requisito principale è avere un’infrastruttura storage prevedibile, separata dalla LAN generale e progettata con percorsi ridondanti. La SNIA, nella documentazione dedicata a Fibre Channel, spiega inoltre il ruolo dei fabric e delle architetture ridondanti nello storage networking.

Il prezzo da pagare è una maggiore specializzazione: switch FC, HBA, compatibilità fra componenti, zoning e competenze operative entrano nel progetto.

iSCSI

iSCSI, Internet Small Computer System Interface, trasporta il modello SCSI attraverso TCP/IP.

Il vantaggio concettuale è immediato: invece di richiedere necessariamente un fabric Fibre Channel, lo storage a blocchi può viaggiare su un’infrastruttura IP.

Questo non significa però che sia sufficiente collegare uno storage alla LAN esistente e considerare conclusa la progettazione.

Il traffico storage può essere sensibile a latenza, congestione, perdita di pacchetti e configurazioni incoerenti. Nelle implementazioni professionali è quindi comune progettare con attenzione segmentazione, percorsi, interfacce, multipathing e configurazione Ethernet. La documentazione Microsoft sul troubleshooting iSCSI considera proprio rete, VLAN, MTU, multipathing e configurazione dello storage tra gli elementi da verificare quando emergono problemi di connettività.

Fibre Channel vs iSCSI: quale differenza conta davvero

Il confronto Fibre Channel vs iSCSI non dovrebbe ridursi a “FC è veloce, iSCSI costa meno”.

Fibre Channel nasce come tecnologia specializzata per lo storage networking e crea un fabric separato dalla normale rete IP. Questo offre un forte isolamento operativo e un comportamento prevedibile, ma richiede hardware e competenze dedicate.

iSCSI utilizza invece TCP/IP. Può quindi integrarsi meglio con competenze e infrastrutture Ethernet già presenti, ma condivide anche molte delle complessità tipiche delle reti IP.

La scelta corretta dipende dal workload e dall’architettura.

Se stai progettando un ambiente molto sensibile alla latenza, con requisiti rigorosi di disponibilità e un team che gestisce già Fibre Channel, FC può essere perfettamente razionale. Se invece l’obiettivo è fornire block storage condiviso utilizzando infrastruttura Ethernet ben progettata, iSCSI può semplificare il progetto e ridurre la necessità di un fabric completamente separato.

Per questo Fibre Channel vs iSCSI è soprattutto una decisione di architettura: bisogna valutare failure domain, isolamento del traffico, competenze disponibili, infrastruttura esistente e requisiti del workload, non scegliere il protocollo sulla base di un’etichetta.

FCoE, NVMe/FC e NVMe/TCP: cosa sapere

Lo scenario non si esaurisce con FC e iSCSI.

FCoE, Fibre Channel over Ethernet, permette di trasportare frame Fibre Channel su Ethernet in architetture convergenti.

NVMe/FC utilizza Fibre Channel per trasportare il protocollo NVMe, mentre NVMe/TCP porta NVMe su reti TCP/IP. Le piattaforme SAN moderne possono quindi offrire più modalità di accesso a blocchi e non devono essere interpretate attraverso la sola coppia FC/iSCSI. La panoramica tecnica di HPE sulle Storage Area Network include FCP, iSCSI, FCoE, NVMe/FC e NVMe/TCP tra le tecnologie rilevanti in questo ambito.

Per un’introduzione alla Storage Area Network, però, non serve trasformare queste tecnologie in una gara di sigle. La domanda utile rimane la stessa: come viene presentato lo storage all’host e quale rete trasporta quel traffico?

Vantaggi e limiti di una Storage Area Network

Una Storage Area Network può migliorare molto l’architettura dello storage, ma solo quando risolve un problema reale.

Dire semplicemente che offre “prestazioni, scalabilità e affidabilità” è troppo generico, perché nessuna di queste proprietà nasce automaticamente dall’acronimo SAN.

Prestazioni, latenza e isolamento del traffico storage

Separare il traffico storage dalla rete utilizzata da utenti e applicazioni può rendere il comportamento dell’I/O più prevedibile.

Questo è particolarmente utile quando database, hypervisor o altri workload generano grandi quantità di operazioni e non vuoi che il percorso verso lo storage dipenda dalla stessa rete che sta trasportando tutto il resto.

Ma una Storage Area Network non rende magicamente veloce uno storage lento.

La latenza complessiva dipende da molti elementi: host, protocollo, switch, numero e qualità dei percorsi, controller, cache, supporti fisici, queue depth e comportamento dell’applicazione. Se il collo di bottiglia si trova nello storage array o nel workload, aggiungere un fabric sofisticato non lo fa scomparire.

Centralizzazione, condivisione e scalabilità

Uno dei vantaggi più concreti è poter separare la crescita dello storage dalla crescita dei singoli server.

Invece di aumentare continuamente i dischi locali di ogni macchina, puoi creare pool di capacità centralizzati e presentare agli host soltanto le risorse necessarie.

Questo modello diventa interessante quando l’infrastruttura cresce.

Nuovi server possono accedere allo storage senza spostare fisicamente i dischi da una macchina all’altra. Le risorse possono essere riallocate o ampliate secondo le capacità del sistema storage. Le funzioni di gestione e protezione possono inoltre essere concentrate a livello dell’array anziché replicate su ogni host.

È uno dei motivi per cui Storage Area Network e data center compaiono spesso nello stesso contesto: una SAN è uno dei possibili sottosistemi dell’infrastruttura IT, non il luogo fisico che la ospita.

Costi e complessità operativa

La flessibilità ha un costo.

Una Storage Area Network può richiedere storage array, switch, HBA o schede dedicate, cablaggio, licenze, strumenti di gestione e competenze specifiche. Più importante ancora, aggiunge relazioni fra componenti che devono rimanere coerenti.

Firmware, driver, sistemi operativi, switch, adattatori e storage non sono elementi indipendenti.

Questo rende l’interoperabilità un aspetto progettuale, non una formalità.

Per una piccola infrastruttura che deve semplicemente condividere documenti, centralizzare backup o archiviare contenuti multimediali, una SAN può quindi essere una soluzione tecnicamente elegante ma economicamente e operativamente sproporzionata.

A cosa serve una Storage Area Network e quando ha senso usarla

La domanda più utile non è “quali aziende usano le SAN?”, ma quali workload beneficiano realmente di storage condiviso a blocchi e percorsi progettati per continuità e prestazioni.

Tre scenari aiutano a capire il confine.

Virtualizzazione e cluster di server

La virtualizzazione è uno degli esempi più intuitivi.

Se più host devono eseguire macchine virtuali e la piattaforma deve poter spostare workload fra nodi o riavviarli su un altro host dopo un guasto, avere i dati vincolati ai dischi locali di una singola macchina diventa un limite.

Uno storage condiviso consente invece a più host autorizzati di raggiungere le risorse necessarie.

Questo non significa che ogni ambiente virtualizzato debba usare una Storage Area Network tradizionale: esistono anche storage distribuito, HCI e servizi cloud. Ma spiega bene perché il modello SAN si è affermato nelle infrastrutture con più server.

Database e workload con I/O intensivo

I database possono generare molte operazioni di lettura e scrittura e spesso richiedono latenza prevedibile, disponibilità e capacità di crescere senza riprogettare continuamente lo storage locale.

Una Storage Area Network può offrire un percorso a blocchi dedicato e permettere di concentrare capacità e funzioni avanzate nello storage array.

Ancora una volta, però, “database” non equivale automaticamente a “serve una SAN”.

Un database relativamente piccolo può funzionare perfettamente su storage locale o cloud. La Storage Area Network diventa interessante quando requisiti di prestazioni, ridondanza, condivisione, gestione e crescita giustificano l’architettura aggiuntiva.

Replica e disaster recovery: cosa può fare una SAN e cosa no

Le piattaforme storage possono offrire replica locale o remota, snapshot e altre funzioni utili alla continuità operativa. Le Storage Area Network possono inoltre estendersi fra ambienti diversi o far parte di una strategia di disaster recovery. La SNIA include business continuity e protezione dei dati tra i contesti nei quali l’architettura SAN può essere utilizzata.

Il caveat è importante: avere una SAN non significa avere automaticamente un piano di disaster recovery.

Replica, backup, retention, immutabilità, procedure di failover, sito secondario e test di ripristino risolvono problemi differenti.

Se replichi immediatamente una cancellazione o una corruzione sul secondo storage, hai due copie dello stesso problema. Una vera strategia di resilienza deve quindi essere progettata oltre il semplice fatto che lo storage sia condiviso.

SAN vs NAS vs DAS: differenze e scelta

La tabella più utile non confronta le tre architetture in base a una classifica assoluta, ma al modo in cui lo storage viene raggiunto.

Anche IBM distingue DAS, NAS e SAN in base al modo in cui capacità e accesso allo storage vengono organizzati.

Block storage, file storage e connessione diretta

Nel DAS lo storage appartiene sostanzialmente al sistema a cui è collegato.

Nel NAS il filesystem viene gestito dal sistema NAS e i client lavorano con file e directory condivise.

Nella SAN il server accede normalmente a storage a blocchi e gestisce il livello superiore attraverso il proprio sistema operativo, hypervisor, cluster o applicazione.

Questa distinzione vale più di molte tabelle basate soltanto su “velocità” e “prezzo”.

Un NAS moderno può essere molto veloce. Un DAS locale con NVMe può avere latenze estremamente ridotte. Una Storage Area Network può essere configurata male.

La categoria tecnologica non sostituisce la progettazione.

Quando scegliere SAN, NAS o DAS

DAS ha senso quando lo storage deve appartenere a un singolo sistema e semplicità, costo o latenza locale sono prioritari.

NAS ha senso quando il problema principale è mettere file a disposizione di utenti e dispositivi, centralizzare dati e backup o creare uno spazio condiviso facilmente amministrabile.

SAN diventa interessante quando più server devono utilizzare storage a blocchi condiviso e requisiti di disponibilità, I/O, centralizzazione o crescita giustificano una rete storage dedicata o progettata specificamente per quel traffico.

Il confronto SAN vs NAS porta quindi a una decisione abbastanza concreta: se il job principale è distribuire file e cartelle, il NAS è normalmente il modello più naturale; se devi fornire storage condiviso a blocchi agli host, una Storage Area Network risponde a un problema diverso.

Se il requisito è semplicemente “voglio salvare tutti i file dell’ufficio in un posto solo”, partire da una SAN significa quasi certamente partire dalla tecnologia sbagliata.

Sicurezza e alta disponibilità: cosa non è automatico

Una delle semplificazioni più pericolose è associare automaticamente una Storage Area Network all’alta disponibilità.

Una SAN può essere progettata per tollerare diversi guasti. Ma se tutti gli host dipendono da un unico switch, una sola porta, un solo controller o un unico percorso, hai semplicemente costruito uno storage condiviso attorno a un nuovo single point of failure.

Zoning e controllo dell’accesso alle LUN

Negli ambienti Fibre Channel lo zoning serve a controllare quali porte del fabric possono comunicare fra loro.

A un altro livello, il sistema storage deve stabilire quali initiator possono accedere alle singole LUN. Il principio è semplice: la presenza fisica sul fabric non deve equivalere all’accesso indiscriminato a ogni volume.

Le implementazioni variano fra vendor e piattaforme, ma il modello resta utile: limitare connettività e visibilità dello storage al minimo necessario.

La documentazione NetApp sullo zoning Fibre Channel mostra, per esempio, configurazioni nelle quali initiator e target vengono organizzati in modo esplicito per controllare i percorsi verso lo storage.

Dual fabric e multipathing

L’alta disponibilità richiede percorsi alternativi.

Una configurazione può utilizzare due fabric indipendenti in modo che il guasto di uno switch o di un percorso non interrompa automaticamente l’accesso allo storage. Sul server, il multipathing permette di gestire più percorsi verso la stessa risorsa e di spostare l’I/O su una strada alternativa quando necessario.

La parte importante è l’indipendenza del failure domain.

Due cavi collegati allo stesso switch non equivalgono a due fabric indipendenti. Due percorsi che convergono sullo stesso componente critico possono continuare a condividere un singolo punto di guasto.

Per questo la ridondanza va letta sempre chiedendo: quale componente può rompersi senza fermare l’accesso ai dati?

SAN, RAID, snapshot, replica e backup non sono sinonimi

Sono livelli di protezione differenti.

RAID può proteggere dalla perdita di uno o più supporti fisici, in base alla configurazione.

Uno snapshot conserva uno stato logico dei dati secondo le caratteristiche della piattaforma.

La replica crea o mantiene una copia su un altro sistema o sito.

Il backup produce una copia destinata al ripristino secondo una politica di conservazione.

La Storage Area Network fornisce invece l’architettura attraverso cui gli host accedono allo storage.

Mettere tutti questi concetti sotto l’etichetta generica “ridondanza” impedisce di capire da quale incidente sei realmente protetto.

Storage Area Network, cloud block storage, HCI e software-defined storage

La Storage Area Network non vive più in un mondo in cui l’unica alternativa è installare dischi direttamente nei server.

Cloud block storage, hyper-converged infrastructure e software-defined storage possono risolvere parti dello stesso problema con modelli operativi differenti.

Questo non rende automaticamente obsolete le SAN. Rende più importante capire quale livello vuoi gestire direttamente.

Cosa cambia con cloud block storage, HCI e SDS

Con il cloud block storage consumi volumi a blocchi come servizio. Il provider nasconde gran parte dell’infrastruttura fisica e della rete storage sottostante.

Con una HCI, compute e storage vengono combinati in nodi che cooperano attraverso software, riducendo la necessità di un array SAN esterno per molti scenari.

Il software-defined storage sposta invece una parte crescente dell’intelligenza dal dispositivo storage dedicato verso un livello software che aggrega e gestisce risorse differenti.

Il risultato è che la decisione non è più semplicemente SAN sì o no.

La domanda diventa: vuoi un sottosistema storage centralizzato e specializzato, un’infrastruttura distribuita costruita insieme al compute oppure una risorsa consumata come servizio?

Quando una Storage Area Network dedicata resta una scelta sensata

Una Storage Area Network dedicata continua ad avere senso quando i requisiti rendono utile mantenere storage e compute come layer separati e controllabili.

Può essere il caso di infrastrutture con grandi quantità di storage condiviso a blocchi, workload consolidati, esigenze rigorose di disponibilità, investimenti già presenti in fabric e competenze operative mature.

Ha meno senso sceglierla per inerzia.

Se l’ambiente è piccolo, il team non dispone delle competenze necessarie o l’infrastruttura può essere semplificata usando storage distribuito o servizi gestiti, la maggiore specializzazione della SAN può diventare un costo senza un beneficio equivalente.

La scelta corretta arriva quindi dal workload, dai failure domain e dal modello operativo, non dal prestigio della tecnologia.

Conclusione

Il modo più semplice per capire una Storage Area Network è smettere di pensarla come a un dispositivo di archiviazione.

Una SAN è l’infrastruttura che permette ai server di raggiungere storage condiviso a livello di blocco. Il server genera l’I/O, l’initiator lo porta sul fabric, la rete lo indirizza verso il target e lo storage array presenta all’host le risorse logiche autorizzate.

Da qui derivano sia i vantaggi sia i costi.

Centralizzare lo storage può facilitare virtualizzazione, cluster, crescita e gestione. Fabric ridondanti e multipathing possono aumentare la continuità. Fibre Channel e iSCSI permettono di costruire il percorso con modelli differenti.

Nessuno di questi elementi, però, rende una Storage Area Network automaticamente più veloce, più sicura o più affidabile di qualsiasi alternativa.

Se devi condividere file, probabilmente stai cercando un NAS. Se lo storage appartiene a un solo sistema, il DAS può essere sufficiente. Se più server devono utilizzare storage condiviso a blocchi e il valore di disponibilità, prestazioni prevedibili e gestione centralizzata supera la complessità dell’infrastruttura, allora una Storage Area Network diventa una scelta tecnicamente coerente.