Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    novembre 2017
    L M M G V S D
    « gen    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Tag Cloud

Cluster Shared Volumes (CSV) : parte 8

Scritto da Ivan Salvade' il 26 giugno 2011

In questa ottava parte dell’articolo su CSV, dimostrerò step-by-step come rendere altamente disponibile, in un cluster CSV,   una macchina virtuale dotata di dischi Pass-Through.   Ecco i link alle precedenti parti dell’articolo :

Come già spiegato nella Parte 3 di questo articolo, nella sezione “Utilizzo dei Pass-Through Disk con CSV”, è possibile eseguire una Live Migration di una macchina virtuale dotata di dischi Pass-Through, a patto di configurarla correttamente nell’ambiente di Cluster CSV.   La configurazione deve prevedere :

  1. l’inserimento nello spazio CSV del vhd contenente il sistema operativo della macchina virtuale
  2. l’inserimento, come “dipendenza” della macchina virtuale”, di uno o più dischi pass-through in dotazione alla macchina virtuale, che verranno utilizzati tipicamente per la parte dati

Vediamo in questo articolo le procedure step-by-step per questo tipo di implementazione.

In questa dimostrazione, parto dall’assunzione di aver già reso altamente disponibile una macchina virtuale, come illustrato nella Parte 7 di questo articolo.

Per prima cosa, vado a ricavare sull’iSCSI Target Software un LUN da dedicare come disco pass-through alla macchina virtuale. Nella figura, il LUN è il Virtual Disk 2 inserito in LUN-02 (Fig. 1) :

lun-da-dedicare-come-passthrough.jpg      Fig. 1

Non appena rendo visibile il nuovo LUN al Nodo 1 tramite l’iSCSI Initiator, eccolo comparire nella console Gestione Disco (Fig. 2) :

lun-visto-da-nodo1.jpg      Fig. 2

Eseguo il solito Online del disco (Fig. 3) …

online-lun.jpg      Fig. 3

…e la solita inizializzazione per rendere il disco riconoscibile dal sistema operativo e dai servizi di Clustering (Fig. 4) :

initialize-lun.jpg      Fig. 4

Ora riportare Offline il disco appena inizializzato : Hyper-V richiede che il disco sia Offline affinchè lo si possa agganciare come pass-through alla macchina virtuale; inoltre non serve formattarlo già ora, in quanto ci penserà il sistema operativo della macchina virtuale (Fig. 5) :

riportare-offline-il-lun-se-no-non-si-aggiunge-come-passthrough.jpg      Fig. 5

Il disco deve essere reso visibile tramite iSCSI Initiator anche al Nodo 2, altrimenti il Cluster restituisce il seguente errore (Fig. 6) :

se-lun-non-mappato-a-entrambi-i-nodi-cluster-non-lo-vede.jpg      Fig. 6

Dopo che il disco è stato reso visibile a entrambi i nodi, si procede a dichiarare il disco al Cluster, con l’azione “Add Disk” della console del Failover Cluster, sezione Storage (Fig. 7) :

aggiunta-disco-al-cluster-storage.jpg      Fig. 7

Ecco il riassunto dello storage ora disponibile : il Disk 1 in Quorum, il Disk 2 in CSV, il nuovo Disk 3 compare nello storage disponibile (Fig.8) :

riassunto-storage.jpg      Fig. 8

Come già detto, non è possibile assoggettare a CSV un disco che si pensa di utilizzare come pass-through in una macchina virtuale.  Il tentativo di eseguire questa operazione (Fig. 9) …

tentativo-di-mettere-in-csv-il-lun-passthrough.jpg      Fig. 9

… porta a degli errori, visibili in Fig. 10 e Fig. 11 :

esito-1.jpg      Fig. 10

esito2.jpg  

Fig. 11

Quali sono le motivazioni dell’errore di Fig. 11 ?   La tecnica CSV richiede che i dischi siano dotati di almeno una partizione formattata NTFS per poter ospitare i vhd delle macchine virtuali, e inoltre devono essere in stato Online, altrimenti CSV non riesce a leggere le informazioni di partizionamento dei dischi.   Nel nostro caso, però, dobbiamo tenere il disco Offline, perchè solo in questo stato è possibile inserirlo come pass-through in una macchina virtuale.   Questi due concetti antagonisti creano il suddetto errore.

Ora proviamo ad inserire il Disk 3 come pass-through disk della macchina virtuale, utilizzando la voce Settings nelle proprietà della macchina in console del Failover Cluster (Fig. 12) :

tentativo-di-assegnare-il-lun-passthrough-a-vm.jpg      Fig. 12

Essendo il disco Offline, lo si può vedere nella sezione “Physical Hard Disk” (Fig. 13) :

disco-9-messo-come-passthrough.jpg      Fig. 13

Ora, nella sezione “Disk Drives”, compare il “Cluster Disk 3″.   Eseguo anche un Refresh (essenziale!!) della configurazione della macchina virtuale (Fig. 14) :

refresh-della-vm.jpg      Fig. 14

Il primo refresh, però, comporta dei (giusti…) ”Warning” indicati in Fig. 15 , Fig. 16 e Fig. 17 :

refresh-e-warning-della-vm.jpg      Fig. 15

avviso-rosso.jpg

Fig. 16

avviso-giallo.jpg

               Fig. 17

La motivazione dei warning di Fig. 17 è la seguente : eseguendo il refresh della macchina virtuale nella console del cluster, il cluster si è accorto che il “Cluster Disk 3″ (quello identificato dal cluster come \\.\PhysicalDrive9) non è ancora sotto il suo controllo.  In effetti, come si nota in Fig. 8, quel disco è visibile solo nella sezione “Available Storage”;  non è mai stato dichiarato in uso da qualche risorsa del cluster.   Il refresh della macchina virtuale esegue proprio questa operazione.  Infatti, appena sotto i due warning gialli, si nota proprio la dichiarazione del disco al cluster : “Adding the new storage required by virtual machine ‘HA-Test to the cluster“.

Ora, rieseguendo un secondo refresh a scopo di controllo, si nota il differente esito (Fig. 18 e Fig. 19) :

rifatto-con-lun-in-possesso-del-cluster.jpg      Fig. 18

il-refresh-e-ora-corretto.jpg      Fig. 19

Ora il disco è completamente sotto il controllo del cluster, ed inoltre è dichiarato come dipendenza della macchina virtuale.  Qualunque operazione di migrazione della macchina virtuale si porterà dietro pure il pass-through disk (Fig. 20) :

lun-ora-in-dipendenza.jpg      Fig. 20

Nella precedente Fig. 20, notare come la macchina virtuale era in esecuzione su Nyc-Host1.  Ecco ora l’esecuzione di una nuova Live Migration della macchina virtuale HA-Test (Fig. 21) :

migrazione-in-corso.jpg      Fig. 21

Al completamento della Live Migration, si nota che l’owner è diventato NYC-Host2 (Fig. 22) :

migrazione-finita.jpg      Fig. 22

Eseguendo un Diskpart all’interno della macchina virtuale, si nota come il disco pass-through venga correttamente visto (Disk 1).  E’ addirittura in stato Offline : è possibile ora procedere a partizionarlo e formattarlo secondo le esigenze, utilizzando il sistema operativo della macchina virtuale (Fig. 23) :

lun-visto-da-dentro-vm.jpg      Fig. 23

Conclusione : la Live Migration di una macchina virtuale dotata di dischi Pass-Through funziona! Eccome se funziona!!  :-)

Buona implementazione a tutti!!  :-)

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | 1 Commento »

Cluster Shared Volumes (CSV) : parte 5

Scritto da Ivan Salvade' il 28 maggio 2011

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/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 3

Scritto da Ivan Salvade' il 17 maggio 2011

In questa terza parte dell’articolo su CSV, analizzerò più nel dettaglio il dimensionamento e il posizionamento dei LUN, dei volumi e dei files vhd in un ambiente di Cluster CSV.

Ecco i link alle precedenti parti dell’articolo :

Posizionamento e dimensionamento di LUN, volumi e VHD

Se ci trovassimo di fronte ad un semplice server fisico, su cui dovessimo disporre i dischi nella maniera migliore per garantire massime performance di accesso al sistema operativo e ai dati, la configurazione migliore sarebbe la seguente :

  • I file di sistema (compreso il file di paging) su un disco fisico
  • I dati su un altro disco fisico

Ulteriori migliorie della configurazione prevederebbero :

  • La creazione di un volume RAID 1 (su due dischi fisici) per i files di sistema
  • La creazione di un volume RAID 5 o RAID 1+0 o RAID 6 (su una moltitudine di dischi fisici) per i dati
  • L’eventuale separazione del file di paging dai files di sistema, ponendolo su un volume RAID 0 creato su una moltitudine di dischi fisici

Per un server virtuale clusterizzato, la disposizione dei dischi dovrebbe ricalcare il precedente modello, e cioè :

  • I files di sistema (incluso il file di paging) in un VHD posto su un volume assoggettato a CSV
  • I dati in un altro VHD posto su un altro volume assoggettato a CSV

L’aggiunta di successive macchine virtuali, dovrebbe sempre ricalcare lo stesso modello.  Dato che è possibile posizionare diverse macchine virtuali sullo stesso LUN (vedi “Architettura e principi di funzionamento” nella parte 1 dell’articolo), dovremmo sempre piazzare i VHD dei files di sistema sul volume a loro dedicato, e i VHD dei dati sull’altro volume a loro dedicato.  La seguente figura illustra la topologia appena discussa :

csv1.jpg

In generale, bisogna sempre cercare di riprodurre con i VHD la configurazione dei dischi che si utilizzerebbe se i server fossero fisici piuttosto che virtuali.   E’ importante valutare anche il carico di lavoro che le applicazioni all’interno delle macchine virtuali esercitano sui dischi (per es. Sql Server o Exchange Server generano tipicamente un elevato numero di operazioni I/O sui dischi).

Più è elevato il numero di operazioni di I/O, più bisogna orientarsi verso configurazioni RAID (sui dischi fisici dove sono creati i LUN assoggettati a CSV) che garantiscano massime performance oltre che ridondanza (RAID 1+0 e RAID 5 su un buon numero di dischi sono tipicamente le migliori configurazioni RAID.  Consultare anche le Best Practices del vendor del sistema di storage, a questo proposito).

Per le applicazioni basate su database, è molto frequente adottare la best practice di separare su LUN diversi i database e i files delle transazioni;  questo per un discorso di performance, ma anche di miglior recuperabilità in caso di disastro.   La stessa best practice andrebbe utilizzata se l’applicazione risiedesse in una macchina virtuale.   Quindi potremmo avere una disposizione dei VHD come segue :

  • Un VHD contenente file di sistema e file di paging, posto su un LUN assoggettato a CSV, creato a sua volta in modalità RAID 1 su due dischi fisici
  • Un VHD contenente il database applicativo, posto su un LUN separato assoggettato a CSV, creato a sua volta in modalità RAID 1+0 o RAID 5 su un certo numero di dischi fisici (più sono, più otteniamo performance)
  • Un VHD contenente i files di transazione dell’applicazione, posto su un LUN separato assoggettato a CSV, creato a sua volta in modalità RAID 1 su due dischi fisici

Se disponiamo di multiple macchine virtuali con requisiti simili, potremmo dedicare un LUN ad ospitare tutti i VHD dei file di sistema, un LUN ad ospitare tutti i VHD dei database, un LUN ad ospitare tutti i VHD dei files di transazione delle varie macchine virtuali.

Quanti LUN si devono creare per ospitare i VHD delle macchine virtuali?    Dipende ovviamente dal carico di lavoro sui dischi che esercitano le applicazioni all’interno delle macchine virtuali.   Se queste generano poco I/O, si possono piazzare anche più VHD di più macchine virtuali su uno stesso LUN assoggettato a CSV, altrimenti separare opportunamente i VHD su più LUN, e utilizzare soluzioni RAID sui dischi fisici che garantiscano il massimo delle performance.

Configurazione ottimale dei VHD

In Hyper-V è possibile utilizzare dischi VHD di tre tipi :

  1. Fixed
  2. Dynamically Expanding
  3. Differencing

E’ importante scegliere opportunamente il tipo di VHD, per non andare incontro a problemi di performance.   Tutti e tre questi tipi di VHD sono comunque supportati dalla tecnica CSV.

Fixed Disk

In fase di creazione viene richiesta una dimensione massima (127 GB di default, massino 2TB).  Il file VHD viene immediatamente creato con una dimensione pari a quella impostata.  Il contenuto viene poi man mano scritto nel VHD, ma questo non comporta l’espansione del file VHD, che rimane sempre della stessa grandezza.

Vantaggi : conosco in anticipo l’occupazione di spazio sui LUN fisici, non corro il rischio di avere in futuro un over-commit sui dischi, la frammentazione è ridotta, le performance sono ottimali e paragonabili a quelle dei dischi fisici.

Svantaggi : difficilmente trasportabile, soprattutto se molto grande

Dynamically Expanding Disk

In fase di creazione viene richiesta una dimensione massima (127 GB di default, massino 2TB).  Il file VHD viene però creato molto piccolo (pochi KB), e viene espanso man mano che si procede ad inserire dati.  L’espansione massima sarà pari alla dimensione massima indicata in fase di creazione.

Vantaggi : facilmente trasportabile, in quanto inizialmente la sua dimensione può essere molto contenuta

Svantaggi : frammentazione più accentuata, performance minori a causa dell’overhead di attività necessaria ad espandere continuamente il VHD e a causa della frammentazione stessa, minor controllo dell’occupazione di spazio su disco (devo continuamente controllare l’espansione per evitare l’esaurimento di spazio sul LUN fisico), alcune applicazioni possono non supportare i VHD di questo tipo (per esempio Microsoft non supporta Exchange 2007 o 2010 virtualizzati su VHD di tipo Dynamically Expanding)

I VHD di questo tipo sono consigliati in ambiente di test e sviluppo.  Con Hyper-V R2 SP1, le performance dei Dynamically Expanding Disk sono molto migliorate, e in alcuni casi sono simili a quelle dei Fixed Disk, ma per macchine virtuali con grossa attività di I/O sui dischi sono comunque consigliati i Fixed Disk.

Differencing Disk

Un Differencing Disk è un disco virtuale associato ad un altro disco virtuale in relazione Parent-Child.  Il Differencing Disk è il “Child”, mentre il disco virtuale associato è il “Parent”.  Il Parent Disk può essere qualunque tipo di VHD.  Il differencing disk memorizza un record di tutti i cambiamenti fatti al parent disk,  e dà la possibilità di salvare questi cambiamenti senza modificare il parent disk.   In ogni momento, è possibile “unire” il differencing disk con il parent disk, se necessario.

Il parent disk può essere reso di sola lettura, ed è agganciabile a diversi differencing disk, per poterlo utilizzare quindi da diverse macchine virtuali.  Questo è ottimo in ambiente di test e sviluppo.

Il differencing disk è sempre di tipo Dynamically Expanding, e non posso dichiararne una dimensione massima.  Inoltre non può essere compattato direttamente, ma solo dopo un’eventuale unione con il parent disk.

Essendo di tipo Dynamically Expanding, hanno i loro stessi vantaggi/svantaggi.  Sono consigliati in ambiente di test, ma non in produzione.

Utilizzo dei Pass-Through Disk con CSV

Oltre ai VHD, è possibile dedicare alle macchine virtuali un intero disco fisico/LUN, detto “Pass-Through Disk”.   Le macchine virtuali scriveranno i dati direttamente nei volumi fisici, senza eseguire l’incapsulamento nei VHD.   E’ possibile utilizzare come Pass-Through Disk i dischi fisici interni di un server, oppure dei LUN ottenuti su una SAN raggiungibile in fibra ottica o iSCSI.

Ecco alcune caratteristiche dei Pass-Through Disk :

  • Le richieste di lettura/scrittura sono spedite direttamente al volume fisico
  • Non sono soggetti al limite di 2 TB, che è invece la grandezza massima per i files VHD
  • Non supportano la creazione degli snapshot
  • Sono associabili ad una macchina virtuale solo se presenti in stato “Offline” sul server Hyper-V
  • Le performance sono ottime, spesso superiori a quelle dei VHD di tipo Fixed
  • La loro portabilità è problematica

Considerando vantaggi e svantaggi dei Pass-Through Disk, è da considerare il loro utilizzo se necessitiamo di massime performance e se vogliamo sfruttare volumi con grandezza superiore ai 2 Tb.

Ma in ambiente CSV, sono supportati i Pass-Through Disk?

Noto su alcuni forum una secca risposta “NO” a questo tipo di domanda.  In realtà non è propriamente così.   Ci sono alcune cose supportate e altre no, ma già da ora posso dire che una Live Migration di una macchina virtuale dotata di dischi Pass-Through in un ambiente di cluster CSV, è perfettamente possibile.  Bisogna solo adottare alcuni accorgimenti in fase di configurazione del cluster.

Ciò che veramente non è supportato, è aggiungere un disco Pass-Through nello spazio CSV del cluster : un Pass-Through è un LUN dedicato all’uso esclusivo di una macchina virtuale, mentre CSV significa condividere un volume NTFS a multiple macchine virtuali.  Sono quindi due concetti antagonisti, e il tentativo di aggiungere (nella console del cluster) un disco Pass-Through allo spazio CSV, genera veramente un errore.

Il trucco sta nel dichiarare il disco Pass-Through come semplice “dipendenza” della macchina virtuale clusterizzata, che avrà invece il VHD da cui esegue il boot caricato su un volume CSV.

In un prossimo articolo della serie, questo scenario verrà implementato e spiegato step-by-step.

In conclusione, è possibile utilizzare in un cluster CSV macchine virtuali dotate di dischi Pass-Through, a patto che la macchina virtuale esegua un boot da un VHD inserito nel volume CSV, mentre il disco Pass-Through verrà dichiarato come dipendenza della macchina virtuale, e conterrà tipicamente solo la parte Dati.   Di questa macchina virtuale così configurata, sarà possibile eseguire senza problemi una Live Migration o una Quick Migration.

Nella quarta parte di questo articolo, analizzerò la configurazione di rete necessaria per la migliore implementazione della tecnica CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 2

Scritto da Ivan Salvade' il 3 maggio 2011

Nella Parte 1 di questo articolo ho trattato dell’architettura generale di CSV e dei suoi principi di funzionamento.   Vediamo ora gli scopi precisi di utilizzo ed i requisiti necessari per l’implementazione della tecnica.

Scopi di utilizzo e benefici della tecnica CSV

Ripartiamo dalla constatazione che NON è strettamente obbligatorio configurare CSV quando si vuole implementare l’alta disponibilità delle macchine virtuali in Hyper-V, ma grazie ai suoi benefici, è altamente raccomandato utilizzarla.

Quali sono i vantaggi?

  1. Ridotto numero di LUN da creare.  Si può utilizzare CSV per ridurre il numero di LUN richiesti dalle macchine virtuali.  Quando si attiva e configura CSV, si possono memorizzare multiple macchine virtuali su un singolo LUN, e multipli “host server” possono accedere allo stesso LUN simultaneamente.
  2. Cluster Validation più veloce.  Utilizzando un minor numero di  LUN, il wizard che controlla la validità dello storage (”Cluster Validation Wizard” nella console del “Failover Cluster) viene eseguito più speditamente
  3. Miglior utilizzo di spazio su disco.  Invece di piazzare ogni singolo vhd su un disco separato con dello spazio libero in modo che il vhd possa espandersi, posso più facilmente occupare lo spazio libero su un LUN memorizzando su di lui multipli vhd (e se questi sono di tipo “Fixed”, posso già dall’inizio calcolare l’occupazione di spazio sul LUN).
  4. Nessun particolare requisito hardware necessario.  Si può implementare CSV su qualunque configurazione di dischi supportata, e su SAN a fibra ottica, iSCSI o SAS.
  5. Miglior recuperabilità.   CSV aumenta la recuperabilità in quanto il cluster può rispondere correttamente anche se la connettività tra un nodo e la SAN è interrotta, oppure una parte della rete è caduta.  Il cluster re-instrada il traffico CSV attraverso una parte intatta della SAN e/o della rete.   Le caratteristiche di ridondanza di CSV saranno oggetto di un futuro articolo di questa serie.
  6. La configurazione delle macchine virtuali in Cluster è molto più semplice di prima

Quindi l’utilizzo di CSV è altamente consigliato negli scenari in cui sono vere tutte le seguenti condizioni, o la maggior parte di esse :

  • presenza di numerose macchine virtuali, alla maggior parte delle quali bisogna garantire un’alta ridondanza
  • in caso di disastri, le macchine virtuali devono essere recuperate col minor downtime possibile
  • il trasferimento di macchine virtuali da un host all’altro (per es. per necessità di manutenzione di uno degli host) deve essere eseguito senza downtime delle macchine virtuali
  • l’ottimizzazione dei costi dello storage è importante

Requisiti per l’implementazione di CSV

I nodi del cluster devono avere i seguenti prerequisiti :

  • Tutti i nodi devono eseguire Windows Server 2008 R2 Enterprise o Datacenter Edition (Full o Server Core Installation), oppure Hyper-V Server 2008 R2.   E’ possibile combinare nello stesso cluster nodi che eseguono Hyper-V Server 2008 R2 con nodi che eseguono Windows Server 2008 R2 Enterprise o Datacenter Server Core Installation
  • La partizione di sistema su tutti i nodi deve avere la stessa lettera di drive (per es. C:)
  • I Ruoli Hyper-V e Failover Cluster devono essere installati su ogni nodo che esegue una supportata edizione di Windows Server 2008 R2
  • I processori di tutti i nodi devono supportare le tecniche Intel VT o AMD-V (attivabili nel BIOS)
  • Non utilizzare nei nodi processori di differente fornitori (es. Intel e AMD)
  • L’Hardware dei nodi dovrebbe essere il più simile possibile
  • Assicurarsi di dotare ogni nodo di adeguata RAM, in modo da supportare il failover delle macchine virtuali da altri nodi

Lo Storage deve avere i seguenti prerequisiti :

  • Lo storage su SAN deve essere compatibile con il Windows Server 2008 R2 Failover Cluster
  • I LUN creati sulla SAN devono essere raggiungibili da tutti i nodi, via Fibre Channel, SAS o iSCSI
  • Per assoggettare un LUN a CSV, questo deve essere visibile nella console del Cluster come “Physical Disk Resource” disponibile
  • Se una macchina virtuale è dotata di un “Pass-Through Disk”, questo non può essere assoggettato a CSV, ma ciò non significa che una Live Migration della macchina virtuale non possa essere eseguita.  Questo scenario verrà illustrato in un successivo articolo della serie
  • I dischi in CSV sono identificati con un nome di percorso.  Questi percorsi appaiono nella partizione di sistema dei nodi, nella cartella \ClusterStorage.  I percorsi non sono altro che dei “Junction Point” verso i LUN
  • I LUN possono essere creati col software di gestione del vendor della SAN, utilizzando configurazioni RAID di qualunque tipo : RAID 0, RAID 1, RAID 1+0, RAID 5, RAID 6.  Consiglio la soluzione RAID 1+0 per le migliori performance nonchè ridondanza, anche se è accettabile anche un RAID 5 su un buon numero di dischi fisici

I prerequisiti di rete devono essere i seguenti :

  • Installare un numero sufficiente di Schede di Rete in ogni nodo, in modo che una rete sia disponibile per CSV e altre reti siano disponibili per altri scopi (es. operazioni di gestione, traffico pubblico, traffico privato del cluster, connessioni via iSCSI allo storage)
  • Per tutte le Schede di rete che trasportano comunicazioni del cluster, assicurarsi di attivare “Client for Microsoft Networks” e “File and Print Sharing for Microsoft Networks”, allo scopo di supportare SMB 2.0 (Server Message Block), che è richiesto da CSV.   Solo una scheda di rete sarà la “preferred network” per le comunicazioni CSV, ma abilitare SMB 2.0 su tutte le schede di rete, permette al cluster di rispondere meglio alle rotture
  • Tutti i nodi di un cluster con CSV attiva, devono risiedere sulla stessa sottorete logica.  Questo significa che, in caso di Cluster Multisito che usano CSV, bisogna utilizzare una VLAN
  • Ulteriori considerazioni sull’ambiente di rete CSV saranno illustrate nella parte 4 di questo articolo

Nella terza parte di questo articolo analizzerò più nel dettaglio il dimensionamento e il posizionamento dei LUN, dei volumi e dei files vhd in un ambiente di Cluster CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 1

Scritto da Ivan Salvade' il 25 aprile 2011

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/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok