Cluster Shared Volumes (CSV) : parte 1

Facebooktwittergoogle_plusredditlinkedin

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.

Come installare Ubuntu Server 10.10 su una macchina virtuale Hyper-V R2

Facebooktwittergoogle_plusredditlinkedin

Per poter installare e configurare correttamente Ubuntu Server come sistema operativo guest all’interno di una macchina virtuale su Hyper-V, è necessario effettuare manualmente modifiche ad alcuni file di sistema, in quanto alcune delle periferiche virtuali non vengono riconosciute in modo automatico.

Durante la fase di installazione di Ubuntu Server 10.10 verrà visualizzato un messaggio che ci avvisa che non è presente nessuna scheda di rete :

ignorare tale messaggio e portare a termine l’installazione secondo le nostre necessita.

Una volta terminata l’installazione, al primo avvio della VM è necessario eseguire questa sequenza di operazioni per effettuare il corretto riconoscimento di tutte le periferiche ed avere quindi tutte le funzionalità attive :

  1. Editare il file /etc/initramfs-tools/modules , aggiungendo queste linee alla fine del file :
    hv_vmbus
    hv_storvsc
    hv_blkvsc
    hv_netvsc
     
  2. Terminata  la modifica lanciare il comando “update-initramfs –u” e riavviare la VM; in questo modo verranno caricati i driver compatibili con Hyper-V per lo storage e la rete.
    Per verificare il corretto caricamento dei driver dopo il riavvio utilizzare il comando “lsmod”.

  3. Il passo successivo consiste nel configurare i parametri per la scheda di rete, in quanto durante l’installazione questa fase è stata saltata.
    Tramite il comando “ifconfig –a” possiamo recuperare il nome assegnato alla scheda di rete (nell’esempio seguente eth0) ed editare il file /etc/network/interfaces :

    Per utilizzare un server DHCP già presente sulla rete :
    Auto eth0 
    iface eth0 inet dhcp

    Per impostare un indirizzo IP statico:
    Auto eth0 
    iface eth0 inet static
    address [indirizzo IP ] 
    netmask [netmask] 
    Gateway [indirizzo IP del gateway]

    Riavviare quindi il servizio di rete col comando /etc/init.d/networking restart e controllare che le impostazioni siano corette lanciando il comando ifconfig.

A questo punto la nostra macchina virtuale è pronta.

Autostart delle macchine virtuali su Hyper-V

Facebooktwittergoogle_plusredditlinkedin

Al contrario di VMWare, dove i parametri di autostart delle macchine virtuali sono nelle impostazioni di configurazione dell’host di virtualizzazione, in Hyper-V le opzioni di Avvio ed Arresto Automatico si trovano nella configurazione delle singole VM.

Aprire la Console di Gestione d Hyper-V, selezione la macchina virtuale interessare e cliccare sulla voce Impostazioni; nella finestra di configurazione della nostra macchina virtuale, nella barra di sinistra all’interno del gruppo Gestione sono presenti le due voci Azione avvio automatico e Azione arresto automatico :

 

Le opzioni per l’Avvio Automatico sono le seguenti :

  • Nessuna operazione
  • Avvia automaticamente questa macchina virtuala se era in esecuzione quando il servizio è stato arrestato
  • Avvia sempre automaticamente questa macchina virtuale
  • Ritardo avvio automatico : questo parametro permette di ritardare l’avvio della VM per evitare il rallentamento dell’host in fase di avvvo

 

Le opzioni per l’Arresto Automatico sono invece le seguenti :

  • Salva lo stato della macchina virtuale
  • Spegni la macchina virtuale
  • Arresta il sistema operativo guest

Come aprire file VHD (Virtual Hard Disk) su Windows 7 e Windows Server 2008

Facebooktwittergoogle_plusredditlinkedin

E’ possibile aprire i dischi virtuali in formato VHD (acronimo di Virtual Hard Disk) creati con Hyper-V o Virtual PC su macchine dotate di Windows 7 o Windows Server 2008 senza l’ausilio di software aggiuntivo.

E’ necessario “montare” il disco virtuale per vederlo tra le unità del sistema e renderlo quindi accessibile in lettura e scrittura.

Dopo aver aperto Gestione Computer dal Pannello di Controllo, espandere la voce Archiviazione e selezionare Gestione Disco.
Selezionare dal menù Azione la voce Collega file VHD e selezionare nella finestra successiva il file VHD tramite il pulsante Sfoglia…; è inoltre possibile selezionare se aprile il disco virtuale in Sola lettura

Una volta che il disco è collegato, lo troveremo tra le unità a disco. Una volta terminato l’uso del disco virtuale, basta cliccarci sopra col tasto destro nella parte inferiore di Gestione Disco e selezionare Scollega file VHD.

Tunnel Brokers IPv6

Facebooktwittergoogle_plusredditlinkedin

Vuoi collegarti a Internet in IPv6 e il tuo ISP offre solo il servizio in IPv4 ? Utilizza un Tunnel Broker IPv6 e configura il tuo computer per utilizzarlo. Per qualche informazione in più su come funziona il tunneling puoi anche leggere il post Come connettersi alla rete internet in IPv6. I seguenti provider forniscono una connettività […]

L’articolo Tunnel Brokers IPv6 sembra essere il primo su KISS Keep IT Simple Stupid.

IPv6 questo sconosciuto

Facebooktwittergoogle_plusredditlinkedin

E’ ormai giunta la fine ! Quella degli indirizzi IP, le sequenze che identificano univocamente un dispositivo collegato a una rete informatica, al pari di un indirizzo stradale o un numero telefonico, consentendo l’accesso a internet. Internet è infatti basato sul protocollo TCP/IP, dove IP sta per Internet Protocol – è tuttora in uso il […]

L’articolo IPv6 questo sconosciuto sembra essere il primo su KISS Keep IT Simple Stupid.

Collegare dischi USB su macchine virtuali Hyper-V

Facebooktwittergoogle_plusredditlinkedin

Quando si utilizza Hyper-V, il collegamento di un disco esterno USB ad una macchina virtuale è un’operazione semplice e veloce.

Sulla macchina host, dopo che il disco USB è stato collegato e riconosciuto, lanciare Server Manager e cliccare sulla voce Gestione disco sotto Archiviazione .
Cliccare quindi col tasto destro nella parte inferiore della finestra sul nuovo disco e selezionare la voce Offline; questo passaggio è necessario per permettere alla macchina virtuale di riconoscere il disco.

A questo punto, dopo aver aperto la Console di gestione di Hyper-V; se stiamo utilizzando Hyper-V R2 l’operazione può essere effettuata anche con la macchina virtuale accesa, altrimenti è necessario spegnere la VM prima di procedere.

Apriamo quindi la finestra delle Impostazioni della macchina virtuale che ci interessa e selezioniamo dall’elenco di sinistra la voce Controller SCSI e fare click sul pulsante Aggiungi con la voce Unità disco rigido selezionata.

Nella schermata successiva, selezionare nella tendina Percorso il primo numero libero (si riconoscono in quanto senza la dicitura “(in uso)”), cliccare su Disco rigido fisico e selezionare nella tendina l’unità precedentemente “messa offline”. Cliccando quindi Ok o Applica abbiamo aggiunto il nuovo disco alla macchina virtuale, che quindi vedremo comparire nelle periferiche collegate sotto la voce Unità disco.
Se abbiamo effettuato l’operazione su Hyper-V R2 con la macchina accesa potrebbe essere necessario fare un “refresh” dell’elenco hardware.

Blog italiani (e in italiano) nel mondo IT/ICT