Cluster Shared Volumes (CSV) : parte 5

In questa quinta parte dell’articolo su CSV, analizzerò il funzionamento del “Redirected Access” (aka “Redirected  I/O”, aka “Redirected Mode”) in un cluster CSV.   Ecco i link alle precedenti parti dell’articolo :

Il Redirected I/O in scenari di Fault-Tolerance

E’ una feature molto utile, ma anche pericolosa se non se ne conoscono i principi di funzionamento.   Utilizza la “Cluster Network” dedicata alle comunicazioni CSV.

Lo scopo primario del Redirected I/O è fornire ridondanza al percorso di accesso allo storage del cluster.

Come spiegato nella Parte 1 di questo articolo, ogni volume CSV ha il proprio Coordinator Node, che rappresenta l’owner del volume e gestisce direttamente (Direct I/O) le operazioni sui metadati dei files inerenti le macchine virtuali.   Se gli host non-coordinator avessero bisogno di eseguire pure essi tali operazioni, dovrebbero trasmetterle al Coordinator Node tramite la rete dedicata alle comunicazioni CSV, utilizzando il protocollo SMB2 (Redirected I/O).  Questo traffico è raro, e utilizza poca banda.

Tutti i nodi, invece, eseguono operazioni di lettura/scrittura nei VHD utilizzando il proprio collegamento allo storage (Direct I/O).

Dopo questo ripasso, nella figura che segue, si suppone la caduta del collegamento allo storage dell’Hyper-V Host 2.

redirected-mode-theory.jpg

A questo punto, si attiva automaticamente il Redirected Mode, che inoltra all’altro nodo (tramite la NIC CSV) il traffico diretto allo storage.  Questo “inoltro” viene effettuato tramite una connessione SMB2 tra i due nodi : tra l’altro, questo è il motivo per cui si obbliga a lasciare attivo “Client for Microsoft Networks” e “File and Print Sharing” sulle schede di rete dedicate al traffico CSV.  Quando si è in Redirected I/O sulle operazioni di lettura/scrittura  nei VHD, l’utilizzo di banda della NIC CSV è alto.

Per capire quale nodo ha perso la connessione allo storage CSV, è sufficiente ricercare l’evento 5121 tra gli eventi del cluster, nella console del Failover Cluster.

Questa è la parte utile del Redirected I/O : senza di esso, le macchine virtuali sull’Host 2 si fermerebbero in assenza del collegamento diretto allo storage.  In questo modo, invece, continuano a funzionare, seppur con minori performance.

Perché minori performance?  Naturalmente, far transitare le comunicazioni SCSI in una sessione SMB è notevolmente più lento che farle transitare su una connessione iSCSI dedicata o addirittura su una connessione Fibre Channel!

Bisogna anche dire che, se la connessione allo storage fosse ridondata da MPIO, non sussisterebbe il problema.  Ma MPIO non è la scelta di tutti, naturalmente…

N.B : il Redirected I/O può anche essere attivato manualmente nella console del cluster, come illustrato nella seguente figura :

turn-on-redirected-mode.jpg

Ecco il warning che compare se si esegue l’attivazione del Redirected Access :

warning-redirected-mode.jpg

Nella prima delle due figure, si nota come sia disponibile anche una seconda opzione assieme al Redirected Access : l’opzione è “Turn On maintenance for this Cluster Shared Volume”.    E’ interessante capire le differenze tra le due azioni.

  • Redirected Access : in questo stato, CSV è disponibile a tutti i nodi nello spazio C:\ClusterStorage, ma tutti i nodi (tranne il Coordinator Node) eseguono le proprie operazioni di I/O tramite il Coordinator Node.  Queste operazioni sono trasportate via SMB2
  • Maintenance Mode : in questo stato, il servizio Cluster su ogni nodo cerca quali risorse (macchine virtuali) stanno utilizzando CSV, e le “spegne” utilizzando il loro metodo predefinito di spegnimento, che può essere un completo “Shut Down” o un “Save State” (configurabile in ogni macchina virtuale).  Quindi nessuno può più usare CSV, che è rimosso dallo spazio C:\ClusterStorage.  Il LUN sarà però ancora disponibile sul Coordinator Node, ed utilizzabile per eseguirci certe operazioni, per esempio un comando Chkdsk per controllare eventuali settori difettosi.  Quando si termina lo stato di Maintenance, bisogna riavviare manualmente tutte le macchine virtuali precedentemente arrestate.

Il Redirected I/O in altri scenari

In altri scenari, il Redirected Mode può essere “meno entusiasmante”.   Per esempio, in tutti quegli scenari in cui certe operazioni di gestione sul cluster o sull’Hyper-V richiedono accesso esclusivo al File System.

L’esempio più lampante è la necessità/volontà di eseguire un backup del volume CSV, utilizzando un software di backup che sappia eseguire una Volume Shadow Copy a livello host (per es. Data Protection Manager 2010).

Una tale operazione richiede l’accesso esclusivo (da parte del Coordinator Node) al CSV nello storage.   L’unico modo per garantirlo, è iniziare una sessione di Redirected I/O del volume CSV, costringendo tutti gli altri nodi a comunicare con lo storage attraverso la NIC CSV e il Coordinator Node.

Ricordando già da ora che Windows Server Backup non supporta i volumi CSV, rimando alla successiva sesta parte di questo articolo la trattazione del backup in ambiente di cluster CSV e non-CSV.

Share / Save :

Lascia un commento

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