Failover Clustering: le fondamenta dell’alta disponibilità dello storage

Un failover cluster è un insieme di nodi Windows Server che condividono l’accesso allo stesso storage e presentano i workload come risorse spostabili da un nodo all’altro. Se un nodo cade, le sue risorse migrano (failover) su un nodo sano. La disponibilità del cluster dipende dal quorum: la maggioranza dei voti (nodi più witness) deve restare online. Nei cluster con numero pari di nodi, e in particolare in quelli a due nodi, serve un witness. In contesto ibrido la scelta tipica è il Cloud Witness, che usa un Azure Storage account come voto arbitrale al posto di un disk witness o un file share witness on-premises — utile quando non esiste un terzo sito fisico.

Su questa base poggiano due tecnologie chiave per lo storage condiviso: i Cluster Shared Volumes e lo Scale-Out File Server.

Cluster Shared Volumes (CSV)

Un CSV è un volume NTFS o ReFS a cui tutti i nodi del cluster accedono simultaneamente in lettura/scrittura. Senza CSV, un LUN classico può essere di proprietà di un solo nodo alla volta: il failover richiede smontaggio e rimontaggio, con interruzione. Con CSV, invece, ogni nodo vede lo stesso file system contemporaneamente sotto il path unificato C:\ClusterStorage\, eliminando il vincolo “un disco = un solo proprietario”.

Questo abilita la mobilità dei workload: una VM Hyper-V può fare Live Migration tra nodi senza spostare il volume, perché il volume è già attivo su tutti. Un nodo coordinatore gestisce le operazioni sui metadati, ma l’I/O dei dati va diretto allo storage. CSV è anche il layer su cui si appoggiano Storage Spaces Direct (S2D) e lo Scale-Out File Server.

Attenzione al formato: con ReFS il volume CSV lavora in file system redirected mode, incanalando l’I/O attraverso il nodo coordinatore — comportamento corretto ma con implicazioni di performance rispetto a NTFS.

Scale-Out File Server (SOFS)

Lo SOFS è un ruolo di file server clusterizzato pensato per i dati applicativi, non per i dati utente. La sua caratteristica distintiva è l’active-active: tutti i nodi servono la stessa share SMB contemporaneamente (\\SOFS\share), distribuendo il carico e offrendo continuous availability. Si appoggia sempre a CSV per lo storage sottostante.

Sfrutta le funzionalità di SMB 3: Transparent Failover (le sessioni sopravvivono alla caduta di un nodo senza errori applicativi), SMB Multichannel (aggregazione di più NIC) e SMB Direct (RDMA) per bassa latenza. È lo storage ideale per i file di VM Hyper-V e i database SQL Server ospitati su file share, dove servono throughput e failover trasparente.

SOFS o general-purpose file server?

Il general-purpose (o “classico”) file server è active-passive: un solo nodo possiede la share alla volta, con failover in caso di interruzione. È la scelta per dati utente, home folder e profili, e supporta funzionalità come DFS Replication, quote FSRM e folder redirection. Lo SOFS, al contrario, non è adatto ai workload con molte operazioni sui metadati (apertura/chiusura/rinomina di file, tipiche degli Information Worker): eccelle invece con pochi file grandi e I/O intenso, come VHDX e database.

Nota d’esame: AZ-801 è in ritiro il 30 settembre 2026; il passing score è 700/1000. Verifica sempre i dettagli sulla documentazione ufficiale Microsoft prima della prova.

Trappole tipiche d’esame

  • Serve alta disponibilità per share di home folder e profili utente → general-purpose file server: lo SOFS è active-active ma penalizza i workload con molte operazioni sui metadati; per i dati utente si usa il file server classico con DFS Replication e FSRM.
  • Hyper-V o SQL su file share con failover trasparente → Scale-Out File Server: l’active-active con SMB Transparent Failover garantisce continuous availability sui pochi file grandi tipici di questi workload.
  • Più nodi devono scrivere sullo stesso volume contemporaneamente → CSV: un LUN NTFS non condiviso appartiene a un solo nodo; solo CSV consente accesso simultaneo sotto C:\ClusterStorage\.
  • Cluster a due nodi in scenario ibrido senza terzo sito → Cloud Witness: fornisce il voto di quorum tramite un Azure Storage account, evitando disk o file share witness locali.
  • CSV formattato ReFS con performance inattese → file system redirected mode: ReFS su CSV redirige l’I/O sul coordinatore; se serve I/O diretto, valutare NTFS.
  • “SOFS senza CSV” → configurazione non valida: lo Scale-Out File Server richiede volumi CSV come storage sottostante e non si crea su un LUN classico.