Come funziona il Failover Clustering

Un failover cluster è un insieme di server (i nodi) che collaborano per garantire alta disponibilità a un ruolo o carico — una VM Hyper-V, un file server, un’istanza SQL Server. I ruoli clusterizzati girano su un nodo alla volta; se quel nodo o le sue risorse falliscono, il Cluster Service sposta (failover) il ruolo su un altro nodo, riavviandolo con lo stesso nome e indirizzo. La condivisione dello stato passa da storage condiviso, Cluster Shared Volumes (CSV) o Storage Spaces Direct (S2D).

Il rischio principale di un sistema distribuito è lo split brain: se la rete si partiziona, due sottoinsiemi di nodi potrebbero entrambi credersi autoritativi e scrivere sugli stessi dati, corrompendoli. Il quorum esiste proprio per evitarlo: stabilisce quale partizione ha il diritto di restare online.

Il quorum: voti e maggioranza

Il quorum è un meccanismo di voto. Ogni nodo ha di norma un voto; a questi si può aggiungere il voto di un witness. Il cluster resta operativo finché possiede la maggioranza dei voti: perdere la maggioranza porta l’intero cluster offline, anche se alcuni nodi sono sani. La regola pratica è mantenere sempre un numero totale di voti dispari.

Il witness è un arbitro che rompe la parità quando i nodi sono in numero pari. Esistono tre tipi:

  • Disk witness: un piccolo disco clusterizzato su storage condiviso; conserva anche una copia del cluster database. Adatto ai cluster single-site con storage condiviso, non a quelli stretched (il disco non si replica facilmente tra siti).
  • File share witness (FSW): una condivisione SMB su un server esterno al cluster; non conserva la copia del database, solo un puntatore alla versione più aggiornata. Utile senza storage condiviso o senza Azure.
  • Cloud witness: usa Azure per l’arbitraggio (vedi sotto).

Cloud witness e scelta del witness

Il cloud witness (da Windows Server 2016) usa un Azure Storage account come punto di arbitraggio: memorizza un piccolo blob nel container msft-cloud-witness, identificato dall’ID univoco del cluster. Non conserva una copia del cluster database, solo il dato minimo per stabilire la maggioranza, e richiede connettività HTTPS in uscita (443) verso l’endpoint dello storage. Si configura con nome dello storage account e access key (Set-ClusterQuorum -CloudWitness).

È la scelta ideale per i cluster stretched multi-sito (evita di dover mantenere un terzo datacenter per il FSW), per S2D/Azure Stack HCI e per i cluster senza storage condiviso. Criterio di scelta: cloud witness se hai connettività Azure affidabile; FSW se sei isolato da internet ma hai un terzo sito; disk witness solo per cluster single-site con storage condiviso.

Dynamic quorum e dynamic witness

Dal 2012, il dynamic quorum ricalcola automaticamente i voti dei nodi al variare del loro stato: quando un nodo lascia il cluster in modo pulito, il suo voto viene rimosso e la maggioranza si ricalcola sui nodi rimasti. Questo consente il last man standing, cioè un cluster che scende ordinatamente fino a un solo nodo restando disponibile.

Il dynamic witness (2016) fa lo stesso per il witness: gli assegna un voto solo quando i nodi votanti sono in numero pari, e lo azzera quando sono dispari. Conseguenza pratica: conviene configurare sempre un witness e lasciare che il cluster decida se contarne il voto — non serve più rimuoverlo manualmente per mantenere il numero dispari.

Trappole tipiche d’esame

  • Cluster a numero pari di nodi senza witness → configura un witness: senza arbitro un guasto singolo può creare una parità e mandare offline tutto; il dynamic witness vota solo quando serve.
  • Cluster stretched multi-sito con disk witness → usa cloud witness o FSW in un terzo sito: il disk witness non si replica tra siti, quindi la caduta del sito che lo ospita compromette il quorum.
  • Cloud witness in ambiente isolato da internet → ripiega sul file share witness: il cloud witness richiede HTTPS in uscita verso Azure Storage; senza connettività non è utilizzabile.
  • File share witness ospitato su un nodo del cluster → mettilo su un server indipendente: collocarlo su un nodo lo rende un single point of failure e vanifica la sua funzione.
  • “Il cloud witness conserva una copia del cluster database” → falso: solo il disk witness conserva la copia; cloud witness e FSW mantengono unicamente un puntatore/arbitraggio minimo.
  • Cluster che ha perso il quorum dopo un disastro → avvio forzato con forcequorum sul sito autoritativo: ripristina il servizio quando la maggioranza è irraggiungibile, ma va fatto sul sottoinsieme corretto per evitare lo split brain.