Cluster Shared Volumes (CSV) : parte 3

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 / Save :

Lascia un commento

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