NAS o SAN: differenze e come scegliere lo storage di rete

NAS (Network Attached Storage) e SAN (Storage Area Network) descrivono modi diversi di fornire storage attraverso un’infrastruttura di rete. In generale, un NAS serve file e directory ai client; una SAN fornisce storage a blocchi che un server può utilizzare come dispositivo di archiviazione. La differenza non riguarda semplicemente le dimensioni dell’apparecchiatura o il numero di dischi: conta quale risorsa vede il sistema client e chi gestisce il file system.

In un NAS, il dispositivo o server di storage gestisce in genere il file system e pubblica risorse condivise per utenti o applicazioni. In una SAN, il server collegato riceve volumi o unità logiche e normalmente vi gestisce il proprio file system. Perciò chiamare “NAS” qualsiasi server con dischi condivisi o “SAN” qualsiasi storage veloce può nascondere decisioni importanti su accesso, amministrazione e compatibilità.

Entrambe le architetture possono essere usate in azienda e possono coesistere. Un’organizzazione potrebbe condividere cartelle di team tramite NAS e riservare una SAN ai server che richiedono volumi a blocchi. Non esiste un vincitore universale: se il problema è agevolare l’accesso ai documenti, le priorità sono diverse rispetto a quelle di un’applicazione che deve gestire un volume a blocchi.

Con l’accesso ai file, il client richiede operazioni su elementi identificati come file e directory: aprire, leggere, scrivere o modificare attributi. Gli utenti possono esplorare cartelle condivise e le applicazioni usano percorsi e autorizzazioni forniti dal servizio. Protocolli come SMB e NFS supportano questo modello. I client vedono una struttura di file condivisa, anche se implementazione e opzioni disponibili dipendono da server e protocollo.

Con l’accesso a blocchi, lo storage presenta al server un’unità logica come dispositivo che può essere partizionato o formattato. Il protocollo trasmette operazioni sui blocchi, non una cartella pronta da esplorare. Il sistema operativo del server gestisce il file system, mentre lo storage sottostante fornisce i blocchi. iSCSI è un metodo standardizzato per trasportare comandi di storage SCSI sulle reti IP; la relativa specifica descrive il protocollo, ma non garantisce di per sé prestazioni, disponibilità o facilità di distribuzione.

La distinzione ha conseguenze operative. Nel modello a file, la gestione di autorizzazioni, percorsi condivisi e accesso da parte di più client è una parte centrale del servizio. Nel modello a blocchi, bisogna definire chi presenta e utilizza ogni volume e come impedire a più server di scrivere su un file system non progettato per l’accesso simultaneo. Non si deve presumere che un volume condiviso a blocchi possa essere montato in sicurezza su più server: dipende dal file system, dal cluster e dalla configurazione supportata.

SMB è una famiglia di protocolli per la condivisione di file in rete, ampiamente associata agli ambienti Windows, anche se non è limitata a un solo sistema operativo. La documentazione Microsoft descrive le funzionalità del protocollo e la sua implementazione in Windows e Windows Server. Per valutare un NAS, verifica quali versioni SMB offre il dispositivo, quali opzioni di autenticazione e autorizzazione supporta e se le funzioni necessarie all’organizzazione sono compatibili con i client. Il solo nome del protocollo non risponde a queste domande.

Anche NFS offre accesso a file e directory attraverso la rete. La relativa documentazione per Windows Server illustra il supporto NFS in quel sistema; le opzioni effettive dipendono dalle versioni e dalle implementazioni di server e client. Se sistemi Unix o Linux convivono con altre piattaforme, verifica l’interoperabilità concreta: versioni compatibili, mappatura delle identità, autorizzazioni, blocco dei file e configurazione delle esportazioni. NFS non trasforma automaticamente un dispositivo in una SAN: resta un protocollo di accesso ai file.

iSCSI viene usato per presentare storage a blocchi sulle reti IP. La RFC 7143 definisce il protocollo iSCSI, mentre la RFC 7146 tratta i requisiti di sicurezza per i protocolli di storage a blocchi su IP mediante IPsec. Questi riferimenti tecnici aiutano a comprendere l’ambito delle tecnologie, ma non sostituiscono la documentazione del fornitore, la progettazione della rete o le politiche di sicurezza. Prima di scegliere iSCSI, verifica la compatibilità degli initiator, dei target, dei sistemi operativi e degli strumenti di amministrazione previsti.

La capacità dichiarata non basta per confrontare le implementazioni. Dimensiona la rete in funzione dei carichi di lavoro previsti e valuta congestione, ridondanza, latenza, percorsi alternativi e possibili singoli punti di guasto. Una SAN può usare iSCSI su Ethernet; quindi non bisogna presumere che ogni SAN richieda una rete fisica separata. Tuttavia, separare o segmentare il traffico di storage può essere una scelta progettuale appropriata, da valutare in termini di operatività, isolamento e disponibilità nel contesto specifico.

Anche il carico amministrativo fa parte del costo. Con un NAS, il team responsabile può gestire risorse condivise, utenti, quote, autorizzazioni, backup e aggiornamenti del servizio. Con una SAN, oltre a gestire i volumi, può essere necessario coordinare la loro presentazione ai server, la connettività, il multipathing e l’amministrazione del file system sugli host. Sono responsabilità di progettazione comuni, non una lista identica per tutti i prodotti: funzioni incluse e lavoro richiesto variano secondo la soluzione.

La sicurezza va verificata end-to-end. Individua come si autenticano i client, come vengono autorizzati gli accessi, quale traffico può raggiungere i servizi di storage e come vengono protette le comunicazioni in base all’architettura e al prodotto. Per iSCSI, la RFC 7146 fornisce un contesto sulla protezione dei protocolli a blocchi su IP; non dimostra che una particolare installazione sia sicura. Documenta anche la gestione delle modifiche, il failover e i test di ripristino. La ridondanza non sostituisce i backup: protegge da determinati guasti, ma non necessariamente da cancellazioni, errori operativi o incidenti che coinvolgono dati replicati.

Non è rigoroso affermare che il NAS costi sempre meno o che la SAN sia sempre più scalabile senza specificare capacità, prestazioni, disponibilità, supporto e durata prevista. Il confronto economico dovrebbe includere storage, rete e adattatori necessari, licenze, garanzie, consumi, spazio, supporto e ore di amministrazione. Un NAS semplice può ridurre il lavoro iniziale in uno scenario di cartelle condivise; un’esigenza di blocchi integrata nei server può giustificare una SAN. Sono ipotesi di valutazione, non conclusioni valide per ogni fornitore.

Chiedi a ogni opzione di rispondere allo stesso carico di lavoro e allo stesso livello di servizio. Definisci lo spazio utilizzabile necessario, la crescita prevista, il numero di client, i modelli di lettura e scrittura rilevanti e il tempo di ripristino richiesto. Verifica poi che la documentazione del prodotto supporti tali caratteristiche e quali componenti siano esclusi dall’offerta. Non confrontare la capacità lorda con quella utilizzabile, né un massimo commerciale con una garanzia di prestazioni per il tuo carico.

È utile anche distinguere la capacità dalla facilità di espansione. Verifica i limiti documentati per unità, volumi, client, protocolli ed espansione, oltre alle condizioni di supporto e ai percorsi di migrazione. Le guide generali sullo storage aiutano a comprendere le categorie, ma non attestano le prestazioni di un dispositivo specifico. Senza modello, configurazione e condizioni d’uso definiti, non ci sono basi per pubblicare un confronto di prezzi o prestazioni tra soluzioni.

Come primo filtro, individua cosa devono utilizzare le applicazioni: cartelle condivise oppure volumi a blocchi gestiti dai server. Poi convalida protocolli e sistemi operativi e infine assegna un responsabile alle attività operative, di sicurezza e ripristino. Questo ordine evita di scegliere in base a un dato isolato di velocità o al nome di un’architettura.

La tabella è un punto di partenza, non una certificazione dell’idoneità di una tecnologia a un caso specifico. Alcune soluzioni commerciali combinano servizi di file e di blocchi; questa combinazione non annulla le differenze tra i modelli di accesso né dimostra che ogni protocollo sia disponibile in tutte le configurazioni. Verifica le capacità specifiche nella documentazione del modello da distribuire e delle versioni software pertinenti.

Prima di decidere, raccogli una descrizione di applicazioni, client, dati e obiettivi di ripristino. Se l’organizzazione non è ancora in grado di specificare requisiti di latenza, disponibilità, crescita o concorrenza, registra queste lacune e non presentare una scelta preliminare come definitiva. Non è necessario iniziare da un marchio: prima si stabilisce il modello di accesso, poi si valutano i prodotti in grado di supportarlo.

Una breve lista di verifica aiuta a trasformare il confronto in una decisione verificabile:

• L’applicazione richiede accesso ai file o ai blocchi?
• Quali versioni di SMB, NFS o iSCSI supporta ciascun estremo?
• Come vengono assegnate identità e autorizzazioni, e chi gestisce volumi e risorse condivise?
• Quale progettazione di rete, ridondanza e isolamento richiede la soluzione?
• Come vengono eseguiti i backup, verificato il ripristino e gestite le interruzioni?
• Quali costi di acquisto, supporto, operatività ed espansione sono inclusi nel calcolo?

La risposta più utile è spesso un’architettura adeguata a requisiti dimostrabili, non un’etichetta più prestigiosa. Per condividere file, inizia valutando NAS e i relativi protocolli; quando il server deve gestire blocchi, esamina SAN o servizi equivalenti e i relativi requisiti di coordinamento. Se servono entrambe le funzioni, valuta di soddisfarle in modo distinto. Decidi sulla base di requisiti, compatibilità e responsabilità documentati e indica chiaramente ciò che non è ancora stato misurato o confermato.