Cluster Shared Volumes (CSV) : parte 1

Questa è la prima parte di un lungo articolo, in cui tratterò in maniera esaustiva la tecnica CSV (Cluster Shared Volumes), implementata nella feature “Failover Clustering” in Windows Server 2008 R2.

Architettura e principi di funzionamento

Si tratta di una sorta di “file system ad accesso distribuito”, studiato appositamente per funzionare con Hyper-V, quando si vuole rendere altamente disponibili le macchine virtuali.   CSV è un componente fondamentale (anche se non obbligatorio) per la riuscita di una ”Live Migration” con il minor downtime possibile.   Lo scopo principale di CSV è quello di supportare macchine virtuali attive su diversi nodi di un cluster, dove i files VHD risiedano però su uno storage comunemente accessibile (anche su un unico LUN).

Per farvi comprendere come funziona CSV, faccio un salto all’indietro per osservare come erano gestite le risorse disco in Windows Server 2008 e precedenti.

In ambiente di cluster, uno dei componenti fondamentali su cui si appoggiano le applicazioni altamente disponibili sono le Risorse Disco (”Physical Disk Resources”).   Queste non sono altro che dei volumi (LUN) ricavati in uno storage condiviso (per esempio una SAN fibra ottica, iSCSI o SAS), opportunamente presentati ai nodi del cluster.  In Windows Server 2008 e precedenti, tipicamente solo un nodo alla volta poteva accedere alla risorsa disco sullo storage condiviso : se multipli nodi in contemporanea avessero avuto accesso in scrittura alla risorsa disco, ciò avrebbe causato una corruzione dei dati.

La proprietà di una risorsa disco da parte di un nodo è garantita (in Windows 2008) dal protocollo SCSI-3 PR (SCSI 3 Persistent Reservation) : sul disco viene inserita una “reservation” da parte del nodo proprietario, che da quel momento viene identificato come unico nodo autorizzato a leggere e scrivere sul disco.  Qualunque altro nodo desideri la proprietà della risorsa disco, deve richiederla al nodo proprietario, che può concederla o negarla.  Se viene concessa, la risorsa disco esegue un “failover” verso il nuovo nodo, che inizierà l’accesso al LUN.

Dato che solo un nodo alla volta poteva accedere ad un LUN, questo significava che il LUN era la più piccola unità di failover.  Se un’applicazione in esecuzione sul LUN (per es. una macchina virtuale) necessitava di spostarsi su un altro nodo, costringeva a spostarsi anche altre applicazioni (per es. altre macchine virtuali) presenti sullo stesso LUN.

Le aziende erano così costrette ad eseguire su un LUN solo singole applicazioni, in modo che fosse proprio la singola applicazione a rappresentare la più piccola unità di failover.   Ma questo comportava anche l’implementazione di un numero spesso spropositato di LUNs, soprattutto se le applicazioni erano rappresentate da immagini virtuali.

CSV in Windows Server 2008 R2 risolve proprio questo problema.    CSV permette a tutti i nodi del cluster di condividere l’accesso alle risorse disco.  E’ implementato tramite dei banali “junction point” del file system NTFS : in pratica il LUN viene presentato in contemporanea a tutti i nodi del cluster tramite un punto di montaggio, visibile nella partizione di sistema (C:) di tutti i nodi, e rappresentato dalla cartella protetta “C:\ClusterStorage”.   La partizione di sistema DEVE essere la stessa su tutti i nodi.   Grazie a CSV, è possibile memorizzare su un unico LUN i VHD appartenenti a diverse macchine virtuali, e riuscire ad eseguire il failover delle singole macchine virtuali, piuttosto che il failover dell’intera risorsa disco (cioè dell’intero LUN, con tutto il suo carico di macchine virtuali).

Come risolvere il problema della corruzione dei dati, nel caso di accesso multiplo alla risorsa disco, come avviene in CSV?   La risposta è : il “Coordinator Node”.

Il “Coordinator Node” è il nodo che realmente detiene la proprietà della risorsa disco, e gestisce l’accesso alla stessa da parte degli altri nodi.  Se in un cluster abbiamo più LUN assoggettati a CSV, esiste un Coordinator Node per ogni LUN.

Il Coordinator Node di un certo LUN può essere qualunque nodo del cluster, così come le macchine virtuali che lavorano su quel LUN possono essere attive su qualunque nodo del cluster.  Possiamo dare le due seguenti definizioni :

  • Coordinator Node : il nodo che detiene la proprietà di una certa risorsa disco (LUN)
  • Active Node : il nodo che detiene la proprietà di una macchina virtuale

Per fare un esempio, in un cluster a 3 nodi, con 8 LUN assoggettati a CSV, e 21 macchine virtuali equamente distribuite sui nodi (7 per ogni nodo), ho una situazione di questo tipo :

  • 8 Coordinator Nodes (uno per ogni LUN), con la possibilità che un nodo sia Coordinator Node anche per più di un LUN
  • 3 Active Nodes, dato che tutti e 3 i nodi detengono la proprietà di almeno una macchina virtuale (7, nel nostro caso. Ognuno dei 3 nodi rappresenta l’Active Node per 7 macchine virtuali).

Il Coordinator Node è responsabile della gestione dei metadati dello storage (es. struttura del File System, attributi dello storage ecc.), mentre gli altri nodi avranno accesso solo al contenuto dei files vhd appartenenti alle immagini virtuali.    Tenendo presente questo, non appena una macchina virtuale vuole scrivere sul LUN, essa deve inoltrare una richiesta di autorizzazione al Coordinator Node di quel LUN.   Il Coordinator Node deve valutare se la richiesta di accesso comporterà un cambiamento della struttura del File System oppure un’operazione di lettura/scrittura all’interno del vhd : tipicamente la richiesta di accesso di una macchina virtuale è del secondo tipo, ed il Coordinator Node garantirà alla macchina virtuale un accesso diretto (e quindi performante) al vhd, restituendo all’Active Node gli indirizzi dei blocchi di File System ove scrivere direttamente i dati.

Se la richiesta di accesso richiede un cambiamento della struttura del File System (per es. creazione, cancellazione, ridimensionamento, spostamento, modifica degli attributi del file vhd), allora dovrà essere il Coordinator Node stesso ad eseguire queste operazioni.   Quindi viene stabilita una sessione SMB tra l’Active Node e il Coordinator Node (se sono macchine diverse), le operazioni di I/O sono passate via SMB dall’Active Node al Coordinator Node, e da qui passate ancora allo storage condiviso attraverso le connessioni SCSI, iSCSI o FC.

Da quest’ultimo paragrafo, si deduce già come sia preferibile eseguire la copia di un vhd verso un disco CSV utilizzando direttamente il Coordinator Node (visibile nella console del Failover Cluster), altrimenti i tempi di copia si allungherebbero drammaticamente!

Nella seconda parte di questo articolo, analizzerò i benefici di utilizzo di CSV e i prerequisiti per l’implementazione.

Share / Save :

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.