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 7

Scritto da Ivan Salvade' il 20 giugno 2011

In questa settima parte dell’articolo su CSV, dimostrerò step-by-step l’implementazione di un Cluster 2008 R2 con attivazione dell’architettura CSV.   Ecco i link alle precedenti parti dell’articolo :

Finalmente, dopo tanta teoria, ecco la prima parte di articolo con un po’ di pratica e dimostrazioni step-by-step!!  :-)

Implementazione del Cluster CSV : preparare lo Storage Condiviso

Prima della creazione del cluster CSV, è necessario preparare lo storage condiviso.   Seguendo le best practices del fornitore dello storage, bisogna opportunamente creare i LUN da presentare ai nodi del cluster, già configurati in base alle soluzioni di ridondanza progettate (livelli di RAID).

Lo storage condiviso può essere raggiunto dai nodi con 3 tecniche : FC (Fibre Channel), SAS (Serial Attached SCSI) o iSCSI.  La soluzione meno costosa è indubbiamente iSCSI, facilmente utilizzabile anche in ambiente di test/laboratorio.

iSCSI prevede la presenza di un dispositivo di storage (anche un server stesso) chiamato “iSCSI  Target”, che conterrà tutti i LUN da presentare ai nodi.   I nodi si collegheranno all’ iSCSI Target utilizzando un “iSCSI Initiator”.   Microsoft fornisce via software entrambi questi componenti :

  • Microsoft iSCSI Software Target : dal 4 aprile 2011  è stato reso pubblico e gratuito per tutti.  Trovate le opportune spiegazioni  e il link per il download in quest’altro mio post : http://ivansalvade.it/2011/04/05/microsoft-iscsi-software-target-e-ora-gratuito/ 
  • Microsoft iSCSI Initiator : è presente per default in Windows 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008; è scaricabile da Microsoft come package per Windows XP SP2 o successivi, Windows Server 2003 SP1 o successivi, Windows 2000 SP4

Nella seguente dimostrazione, ho installato il Microsoft iSCSI Software Target su un server di rete.  La prima operazione è proprio creare gli iSCSI Target, cioè i contenitori dei LUN a cui i nodi si collegheranno (Fig. 1) :

create-iscsi-target.jpg      Fig. 1

Per ogni iSCSI Target creato, ci viene chiesto quali sono i nodi che potranno collegarsi a lui : è comodo localizzarli tramite indirizzo IP (10.10.0.101 e 10.10.0.102 non sono altro che i due nodi del cluster che verrà poi creato) (Fig. 2) :

create-advanced-identifiers.jpg      Fig. 2

Ecco due iSCSI Target creati (non c’è un limite massimo di iSCSI Target creabili : il limite è lo spazio su disco dello storage!) (Fig. 3) :

lun1-e-lun2-creati.jpg      Fig. 3

  

Ora, nella sezione “Devices”, si creano i “Virtual Disk”: sono i LUN veri e propri, partizionabili e formattabili a piacimento, accessibili dai nodi via TCP/IP (Fig. 4) :

inizia-a-creare-virtual-disk.jpg      Fig. 4

Un “iSCSI Virtual Disk” non è altro che la simulazione di un disco fisico, eseguita utilizzando un file .vhd creato in un certa cartella sul server base (Fig. 5) :

  disk-01vhd.jpg      Fig. 5

Ecco due Virtual Disk da 8GB e 20GB, entrambi associati al Target “LUN-01”.   Questi saranno i due LUN effettivi che dovranno essere presentati ai nodi del cluster, e che appariranno come dischi fisici di base nella console “Gestione Disco” (Fig. 6) :

  vhd-creati-ad-accesso-lun-01.jpg      Fig. 6

Implementazione del Cluster CSV : collegare i nodi allo Storage Condiviso

Ora, sul primo dei nodi del cluster, ci si collega ai Virtual Disk utilizzando l’iSCSI Initiator.  Dagli Strumenti Amministrativi, la prima volta che si clicca “iSCSI initiator”,  si viene avvisati che il relativo servizio è spento.  Cliccando su “Yes”, si avvia il servizio e lo si imposta su un tipo di startup “Automatico” (Fig. 7) :

  connette-iscsi-a-server.jpg      Fig. 7

Nel tab “Targets”, nel campo “Target”, è sufficiente inserire l’indirizzo IP del server con il Microsoft iSCSI Software Target e cliccare “Quick Connect”.  Vengono visti entrambi i Target creati nella mia procedura esemplificativa, e utilizzando i tasti “Connect” e/o “Disconnect”, è possibile rendere attivi (“connected”) o disattivi (”inactive”) i Target necessari (Fig. 8 ) :

  targets-connesso.jpg      Fig. 8

Una volta che ci si è connessi al Target voluto, nel tab “Volumes and Devices” cliccare il tasto “Auto Configure” per far comparire automaticamente i Virtual Disk configurati nel Target (Fig. 9) :

  volumes-and-devices-visti.jpg      Fig. 9

Ecco i due nuovi dischi visti nella console “Disk Management”.  Sono inizialmente in stato Offline.  La prima operazione da fare è portarli Online (Fig. 10) :

  portiamo-online-i-dischi.jpg      Fig. 10

Una volta portati Online, lo stato dei dischi è “Not initialized”.  Bisogna eseguire l’inizializzazione, con la quale si sceglie lo stile di partizionamento (MBR o GPT, entrambi supportati da Windows Server 2008 R2).  L’inizializzazione appone al disco anche una “signature”, che permette al sistema operativo (e ai servizi di Cluster) di riconoscere il disco da quel momento in poi (Fig. 11) :

  inizializziamo-i-dischi.jpg      Fig. 11

Si creano ora le partizioni sui dischi.   Nel mio esempio, ho assegnato lettere di drive e label opportune per far capire l’utilizzo delle partizioni (“Q:” verrà utilizzata per il Quorum del cluster, chiamato anche “Witness Disk” in Windows Server 2008;  “M:” verrà utilizzata per memorizzare i vhd delle macchine virtuali).    N.B. : il Quorum del cluster richiede poco spazio : è opportuno creare per lui una partizione molto piccola (pochi GB), perché il wizard di creazione del cluster assegnerà in automatico al Quorum la partizione più piccola trovata fra quelle disponibili (Fig. 12) :

  volumi-creati.jpg      Fig. 12

Sul secondo nodo, si ripetono i passi illustrati nelle figure 7, 8, 9.   Non serve portare Online e inizializzare i dischi, né creare le partizioni, in quanto operazioni già eseguite sul primo nodo.

Implementazione del Cluster CSV : creazione del cluster

Su entrambi i nodi, si installa la Feature “Failover Clustering” da Server Manager (Fig. 13) :

  installa-cluster-sui-server.jpg      Fig. 13

Sul primo dei nodi, si entra nello strumento Failover Clustering, e dal pannello centrale si lancia il wizard “Validate a Configuration” (Fig. 14) :

  cluster-validation.jpg      Fig. 14

Si indica di validare la configurazione hardware di entrambi i nodi (che devono essere due server già inseriti nel dominio Active Directory) (Fig. 15) :

  validazione-di-entrambi-i-server.jpg      Fig. 15

Il report presentato al termine del wizard deve validare correttamente tutti i componenti.  Analizzare con attenzione eventuali warning o errori rilevati.  Risolvere i problemi e rieseguire il wizard finchè non si raggiunge la perfetta validazione : creare un cluster ignorando gli avvisi del wizard,  può portare a una configurazione non corretta per la quale Microsoft potrebbe non supportarvi, o peggio ancora a problemi di stabilità del cluster.

Sempre dal primo nodo, si può ora procedere alla creazione del cluster.  Oltre a selezionare i nodi, il wizard chiede il nome e l’indirizzo IP di amministrazione del cluster; entrambi verranno registrati nel Server DNS a cui punta il nodo (Fig. 16) :

  creazione-cluster.jpg      Fig. 16

Il wizard di creazione del cluster sceglie in automatico la modalità di Quorum (in base al numero di nodi inseriti) e il LUN da utilizzare come Witness Disk (Quorum); inoltre crea in automatico tutte le “Cluster Networks” (in base alle schede di rete trovate sui nodi; per la spiegazione, vedi la parte 4 di questo articolo, al paragrafo “Creazione delle Cluster Networks”) e rende utilizzabili dal cluster i dischi condivisi presentati ai nodi tramite iSCSI.

Implementazione del Cluster CSV : attivazione e configurazione di CSV

Attiviamo subito la tecnica CSV.  Un’opportuna finestra ci avvisa di utilizzare CSV solo se vogliamo dare alta disponibilità alle macchine virtuali Hyper-V (Fig. 17) :

  enable-csv.jpg      Fig. 17

Una volta abilitato CSV, nel pannello a sinistra compare la voce “Cluster Shared Volumes”. Nel pannello centrale ci viene indicato che nessun LUN è ancora stato assoggettato alla tecnica CSV (Fig. 18) :

  csv-abilitato.jpg      Fig. 18

Con “Add Storage” procediamo a farlo (Fig. 19) :

  add-csv-storage.jpg      Fig. 19

Nella finestra “Add Storage” vengono elencati i LUN disponibili al cluster, e non già utilizzati per altri scopi nel cluster (per es. come Witness Disk) (Fig. 20) :

  cluster-disk-2-come-csv.jpg      Fig. 20

Ora il LUN è inserito nello spazio CSV, e lo si evince dal percorso “C:\ClusterStorage\Volume1” indicato in (Fig. 21) :

  summary-of-csv.jpg      Fig. 21

Implementazione del Cluster CSV : creazione della macchina virtuale altamente disponibile

Ora, banalmente, tramite Esplora Risorse del primo nodo, copiamo il vhd di un’immagine virtuale nel percorso “C:\ClusterStorage\Volume1”.  Ho creato una cartella “HA-Test” che faccia da contenitore dei files della macchina virtuale (Fig. 22) :

  copia-vhd-in-csv.jpg      Fig. 22

Ora, dalla console Hyper-V del primo nodo, possiamo creare la macchina virtuale (Fig. 23) :

  crea-vm-in-hyper-v.jpg      Fig. 23

Al momento di inserire la locazione della macchina virtuale, scelgo il LUN sotto CSV, rappresentato dal solito percorso “C:\ClusterStorage\Volume1” (Fig. 24) :

  store-in-csv.jpg      Fig. 24

Al momento di agganciare il vhd, scegliere quello precedentemente copiato in “C:\ClusterStorage\Volume1\HA-Test” (Fig. 25) :

  connect-vhd-in-csv.jpg      Fig. 25

In presenza di processori diversi sui nodi del cluster, è sempre opportuno attivare l’opzione “Migrate to a physical computer with a different processor version” nelle proprietà della macchina virtuale che renderemo altamente disponibile (Fig. 26) :

  migrate-diff-proc-flag.jpg    

  Fig. 26

Rimanendo nelle proprietà (“Settings”) della macchina virtuale, è anche opportuno regolare i suoi settaggi di Startup Automatico; si va nella sezione “Automatic Start Action”, e si imposta l’opzione “Nothing”.  Perché?  Quando una macchina virtuale è altamente disponibile, la gestione del suo stato viene gestito dal Cluster, e non ci devono essere azioni automatiche impostate.

Ora si configura la macchina virtuale ad essere altamente disponibile, utilizzando la console del Failover Cluster e la sezione “Services and Applications” (Fig. 27) :

  config-svc-or-appl.jpg      Fig. 27

Si indica “Virtual Machine” come applicazione da rendere altamente disponibile (Fig. 28) :

  risorsa-virtual-machine.jpg      Fig. 28

Dalla lista di macchine virtuali rilevate sui due nodi, si seleziona quella configurata con il vhd nello spazio CSV, ovvero “HA-Test” nel mio esempio (Fig. 29) :

  risorsa-ha-test.jpg      Fig. 29

Ora la macchina virtuale è altamente disponibile, pronta per subire una Quick Migration o una Live Migration, o per essere spostata in automatico sul secondo nodo in caso di disastri improvvisi del primo nodo.  Quick e Live Migration sono eseguibili dalla console del cluster, come mostrato in figura 30.  Notare che, inizialmente, la macchina virtuale HA-Test è in esecuzione su Nyc-Host1 (il primo nodo) (Fig. 30) :

  live-migrate.jpg      Fig. 30

Durante la Live Migration, si può notare come la macchina virtuale resta perfettamente in linea e raggiungibile via rete (al massimo viene perso qualche ping…) (Fig. 31) :

  1-ping-perso.jpg      Fig. 31

Al termine della Live Migration, la macchina virtuale risulta in esecuzione su Nyc-Host2 (il secondo nodo) (Fig. 32) :

  dopo-la-live-migration.jpg      Fig. 32

Nell’ottava parte di questo articolo, dimostrerò step-by-step le procedure di implementazione dell’alta disponibilità di una macchina virtuale in ambiente cluster CSV (con possibilità di eseguirne una Live Migration), quando questa è dotata di dischi pass-through.

  • Share/Bookmark

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

Cluster Shared Volumes (CSV) : parte 6

Scritto da Ivan Salvade' il 13 giugno 2011

In questa sesta parte dell’articolo su CSV, analizzerò le tecniche per eseguire il backup delle macchine virtuali in un ambiente di Cluster CSV.  Le stesse tecniche sono comunque adatte anche al di fuori dell’ambiente di Cluster.  Ecco i link alle precedenti parti dell’articolo :

Le procedure di backup e restore in ambiente virtuale a volte differiscono dalle medesime procedure in ambiente non virtuale.

Rimanendo in ottica Microsoft, è possibile eseguire il backup di macchine virtuali utilizzando due prodotti : Windows Server Backup (incluso in Windows Server 2008 R2),  System Center Data Protection Manager 2010 (a pagamento).   Ognuno ha le proprie caratteristiche e limitazioni.   Bisogna subito dire che Windows Server Backup non supporta il backup di macchine virtuali in un ambiente di Cluster CSV : quindi l’unica soluzione Microsoft, a questo scopo, è utilizzare System Center Data Protection Manager 2010.

“Host Level Backup” e “Guest Level Backup”

Esistono due generali strategie di backup delle macchine virtuali Hyper-V :

  • “Host level Backup” : è quello eseguito dall’host fisico Hyper-V, utilizzando il software/agent di backup installato sull’host fisico.  Durante il backup le macchine virtuali possono essere accese (Online Backup) o in stato di “spegnimento/stato salvato” (Offline Backup)
  • Guest level Backup” : è quello eseguito direttamente all’interno delle macchine virtuali, tramite un software e/o un agent di backup installato in ogni macchina virtuale.

Tipicamente, alle aziende con un’importante infrastruttura virtuale si consiglia sempre di eseguire entrambi questi tipi di backup, opportunamente configurati e schedulati.

L’Host Backup (soprattutto se di tipo Full) permette di proteggere tutti i dati necessari per rispristinare l’intero server, comprese le macchine virtuali e i loro snapshot (con l’eccezione delle reti virtuali, che dovranno sempre essere documentate a parte, e all’occorrenza ricreate).

Il Guest Backup garantisce un backup a livello file/applicazione all’interno della macchina virtuale. Questo ci permette di avere un controllo più granulare dei dati da backuppare. Per esempio, con un Host Backup posso restorare l’intero server fisico o, al massimo, un’intera macchina virtuale; con un Guest Backup posso restorare anche un singolo file all’interno della macchina virtuale, oppure eseguire il backup di intere applicazioni (es. Exchange o SQL), in modo da poter ripristinare in maniera granulare solo i dati relativi all’applicazione.

Uno svantaggio del Guest Backup è il probabile aumentato costo di licensing/gestione, soprattutto se utilizzo un software di backup Enterprise : dovrò installare l’agent di backup in molte macchine virtuali, mentre se eseguissi solo degli Host Backup, gli agent sarebbero necessari solo sugli host fisici.

Ci sono anche scenari in cui sono obbligato (pur non volendo) ad eseguire dei Guest Backup : per esempio se mi ritrovo nelle casistiche dei punti 8 e 9 della  sezione “Online Backup e Offline Backup”, più avanti in questo articolo.

Tipicamente, per la maggior parte delle aziende una combinazione di Host Backup e Guest Backup rappresenta la soluzione più appropriata, in quanto ci consente velocemente il ripristino completo in caso di grossi disastri (Host Backup) e il ripristino granulare dei dati in caso di disastri minimi o necessità day-by-day (Guest Backup).

L’importanza del  Volume Shadow-Copy Service (VSS)

Il modo più semplice per backuppare una macchina virtuale sarebbe spegnerla, e quindi copiare manualmente (o tramite il software di backup) i files che compongono la macchina virtuale e trasferirli sullo storage di backup (questo sarebbe un backup di tipo “Offline”).   Ma questo, tipicamente, non è accettabile in ambiente di produzione, dove spesso le macchine virtuali contengono applicazioni business-critical, e non possono essere spente.

La soluzione è backuppare la macchina virtuale mentre è “in linea” (backup di tipo “Online”), e questo è possibile con opportune tecniche, che ruotano attorno ad un componente essenziale, il “Microsoft Volume Shadow-Copy Service (VSS)”.

VSS è stato introdotto da Microsoft con la piattaforma Windows Server 2003, e permette di coordinare le azioni necessarie a creare una “fotografia” immediata e consistente dei dati (dove i “dati” possono essere files e cartelle, databases, intere applicazioni o intere macchine virtuali), da utilizzare poi per certi scopi, per esempio il Backup.

Hyper-V fornisce completo supporto VSS per eseguire un backup di macchine virtuali (Windows 2003 o 2008) senza causare tempi morti.  Però è necessario anche un opportuno software di backup.

N.B. : se la macchina virtuale non esegue Windows Server 2003 o 2008, verrà sempre posta in “stato salvato” durante il backup, e quindi ci sarà del downtime.

Nella seguente figura sono rappresentati i componenti dell’infrastruttura VSS :

teoria-vss.jpg

I componenti principali sono :

  • Il VSS Requestor : per esempio il software di backup.  E’ il componente che ha il compito di richiedere l’intervento di VSS per la creazione della fotografia dei dati·
  • Il VSS Provider : tipicamente fornito da Microsoft, si coordina con i VSS Writers delle applicazioni per eseguire il “congelamento” dei dati
  • Il VSS Writer : tipicamente fornito dall’applicazione per la quale si vogliono eseguire le fotografie dei dati.  Per esempio, SQL Server, Exchange Server, il servizio AD DS, il servizio DHCP sono tutti dotati di un VSS Writer, che permette di ottenere fotografie consistenti dei propri dati.  Anche Hyper-V ha un proprio Writer, l’”Hyper-V VSS Writer”, che permette di creare copie puntuali e consistenti delle macchine virtuali, anche se sono accese.

Per avere dei backup integri e consistenti delle macchine virtuali mentre queste sono accese, è necessario che la macchina virtuale esegua un sistema operativo “VSS-compatibile” (per esempio Windows Server 2003 o successivi) e che il software di backup sappia correttamente interagire con il VSS Writer di Hyper-V.   In realtà esistono anche altri piccoli pre-requisiti, che elencherò più avanti in questo articolo.

“Online Backup” e “Offline Backup”

Nella figura precedente, è presente un host fisico dotato di opportuno software di backup, dell’Hyper-V VSS Writer e di opportuno storage su cui posizionare i backup.  Inoltre su di esso sono eseguite due macchine virtuali, una con un sistema operativo VSS-compatibile, l’altra con un sistema operativo non-VSS-compatibile (per es. Windows 2000, Linux, Unix).   Vediamo come funziona il backup online (o il tentativo di farlo :-) …  ) in un caso e nell’altro.

Backup della macchina virtuale con sistema operativo VSS-compatibile

  • Si controlla se la macchina virtuale ha gli Integration Services installati (su Windows Server 2008 e successivi sono installati per default)
  • Si controlla se l’Integration Service “Backup (Volume Snapshot)” è abilitato (di solito lo è per default)
  • Se i due precedenti requisiti sono soddisfatti, la richiesta di snapshot da parte del software di backup dell’host fisico viene proxata all’interno della macchina virtuale, dove l’infrastruttura VSS del sistema operativo virtuale gestisce il “congelamento” momentaneo delle applicazioni : in pratica, tutte le operazioni di scrittura sono inserite in una coda, la fotografia viene eseguita, e poi la coda viene svuotata.
  • Lo Snapshot così ottenuto viene passato all’host fisico, che ne esegue il backup.   In questo modo si riesce a creare un backup senza downtime della macchina virtuale : non sussiste la necessità di salvare la RAM della macchina virtuale su disco, come invece avverrà nel prosssimo esempio.   Questo è un effettivo “Online Backup”.

Backup della macchina virtuale con sistema operativo non-VSS-compatibile

  • Non essendo in partenza soddisfatto il requisito principale (cioè avere un sistema operativo virtuale VSS-compatibile), Hyper-V esegue un “salva stato” della macchina virtuale.  Questo significa che la sua esecuzione è messa in pausa, e il contenuto della memoria della macchina virtuale viene salvato su disco.   Una volta che VSS ha salvato la RAM, viene creato lo snapshot, e la macchina virtuale viene rimessa in esecuzione.
  • Lo Snapshot così ottenuto viene passato al software di backup dell’host fisico, che ne esegue il backup.   In questo modo ho un downtime della macchina virtuale, tipicamente tanto più lungo quanta maggiore è la quantità di RAM assegnata alla macchina virtuale.   Questo è un effettivo “Offline Backup”.

N.B. : viene eseguito un Offine Backup anche se il sistema operativo virtuale è VSS-compatibile, ma gli Integration Services non sono installati nelle macchine virtuali, oppure sono installati ma non è abilitato il “Backup Integration Service”.

Come già accennato, ci sono anche altri pre-requisiti per la perfetta riuscita di un Online Backup.  Per comodità, li riassumo qui :

  1. Il sistema operativo virtuale deve essere VSS-compatibile (Windows Server 2003 o successivi lato server, Windows Vista o successivi lato client; per Windows XP non è supportato l’Online Backup)
  2. Gli “Integration Services” di Hyper-V devono essere installati nelle macchine virtuali (lo sono di default da Windows Server 2008 in poi, vanno installati in Windows Server 2003)
  3. L’Integration Service “Backup (Volume Snapshot)” deve essere attivo (lo è di default, se gli Integration Services sono installati)
  4. Tutti i dischi usati dalla macchina virtuale (e quindi visibili nel sistema operativo virtuale) devono essere dischi di tipo “Basic” e devono essere formattati NTFS.  La presenza di dischi di tipo “Dynamic” o formattati FAT32 obbliga l’esecuzione di un Offline Backup
  5. Il “Volume Shadow Copy Service” (servizio “Copia Shadow del Volume”) non deve essere disabilitato nella console dei servizi, sia dell’host fisico che delle macchine virtuali.  Il tipo di startup “Manuale” è appropriato
  6. Tutti i volumi utilizzati dalla macchina virtuale devono avere il Volume Shadow Copy abilitato e configurato in modo che la posizione di creazione degli snapshot sia il volume stesso (usare il comando “VSSAdmin List ShadowStorage” per un controllo immediato della configurazione).  Per esempio :
    • volume C : Volume Shadow Copy abilitato, e la locazione di storage degli snapshot deve essere C:
    • volume F : Volume Shadow Copy abilitato, e la locazione di storage degli snapshot deve essere F:
    • per attivare Volume Shadow Copy su un certo volume (ad esempio sul Volume F: , con memorizzazione su F: stesso e spazio massimo occupabile di 1 GB), è possibile utilizzare il comando “VSSAdmin Add ShadowStorage /For=F: /On=F: /MaxSize=1000MB“  (”/For” indica il volume per cui si vuole attivare la Shadow Copy, “/On” indica il volume di memorizzazione della Shadow Copy)
  7. Se utilizzo “Windows Server Backup” per eseguire un Online Backup, bisogna aggiungere ad esso il supporto per il VSS Writer dell’Hyper-V, che non è per default registrato con Windows Server Backup.   La KB 958662 spiega la procedura (oppure consultare la sezione opportuna, più avanti in questo articolo)
  8. Le macchine virtuali devono far uso di dischi virtuali (VHD), che possono essere sia di tipo Fixed, che di tipo Dynamically Expanding.  I dischi fisici direttamente collegati alle macchine virtuali (Pass-Through Disks) NON possono invece essere backuppati dall’Hyper-V VSS Writer.  Quindi qualunque software di backup che si appoggia all’Hyper-V VSS Writer non potrà backuppare i Pass-Through Disks.  In questo caso, i dati sul Pass-Through Disk dovranno essere backuppati con una procedura di backup interna alla macchina viruale (Guest Backup).
  9. I dischi presentati via iSCSI al’interno delle macchine virtuali (utilizando quindi un iSCSI Initiator installato all’interno delle macchine virtuali) non saranno inclusi in un Online Backup eseguito dall’host fisico.  Anche in questo caso bisognerà backuppare tali dischi con un Guest Backup

N.B. : relativamente al precedente punto 9, segnalo che l’Online Backup è invece possibile se i dischi iSCSI sono presentati all’host Hyper-V, e utilizzati per posizionare i files VHD delle macchine virtuali.

Host Backup utilizzando Windows Server Backup di Windows Server 2008 R2

Windows Server Backup è gratuito e già integrato nel sistema operativo.  Può essere scelto come software di backup a livello host, ma bisogna tenere conto di alcune sue limitazioni.

Ecco tutte le sue caratteristiche e, sottolineate, le sue limitazioni :

  • E’ in grado di utilizzare i VSS Writers inbox di Windows Server 2008 R2, ed è quindi in grado di eseguire sia un file-level backup che un block-level backup (per esempio l’immagine di un intero disco)
  • E’ in grado di supportare protezione e recupero a livello applicativo, se le applicazioni forniscono un proprio VSS Writer che si registri con Windows Server Backup (es. Exchange Server o Hyper-V stesso)
  • Non supporta i nastri come storage su cui posizionare i backup
  • Non può essere usato per backuppare e restorare macchine virtuali singole : può solo proteggere l’host fisico intero
  • Non può essere utilizzato per backuppare macchine virtuali posizionate sui volumi CSV di un cluster
  • Non è per default registrato con l’Hyper-V VSS Writer.  Per farlo occorre eseguire i seguenti passaggi sull’Host fisico :
    1. Installare la feature “Windows Server Backup” da Server Manager
    2. Aprire Regedit e posizionarsi in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    3. Creare una nuova sottochiave di nome “WindowsServerBackup
    4. Posizionarsi su “WindowsServerBackup” e creare una nuova sottochiave di nome “Application Support
    5. Posizionarsi su “Application Support” e creare una nuova sottochiave di nome “{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}“   (N.B. : le parentesi graffe fanno parte del nome)
    6. Posizionarsi su {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} e creare un nuovo valore stringa di nome “Application Identifier“.   Assegnare alla stringa il valore “Hyper-V
  • In fase di configurazione del backup, per avere un restore corretto di tutte le macchine virtuali e dell’intera applicazione Hyper-V, è necessario selezionare gli interi volumi che contengono files relativi alle macchine virtuali o all’Hyper-V stesso.  Per esempio, se ho una situazione di questo tipo :
    • C:  volume di installazione di Hyper-V
    • D:  volume dove ho posizionato i files VHD delle immagini virtuali
    • E:  volume dove ho posizionato eventuali snapshot delle immagini virtuali
    • F:  volume dove ho posizionato i files di configurazione delle immagini virtuali

devo impostare il backup degli interi volumi C,D,E,F.   Non è consentito selezionare solo le cartelle che contengono i files inerenti le macchine virtuali, ma sempre gli interi volumi, perchè il servizio VSS lavora per intero volume.

Host Backup utilizzando System Center Data Protection Manager 2010

Garantisce sicuramente maggiori possibilità di configurazione di un Host Backup, e risolve praticamente tutte le limitazioni di Windows Server Backup.   Ha un certo costo, necessita di un certo licensing, ed è però una soluzione Enterprise per aziende che hanno bisogno di un software di backup/protezione di una certa qualità.

Ecco le sue caratteristiche sommarie :

  • Permette protezione e recupero dei dati, memorizzandoli sia su dischi che su nastri (questi ultimi non supportati in Windows Server Backup)
  • Esegue Replica, Sincronizzazione, Creazione di Punti di Recupero
  • Si appoggia completamente all’infrastruttura VSS
  • Si può installare solo su Windows Server 2008/2008 R2 a 64 bit,  Standard o Enterprise Edition
  • Necessita dei componenti Powershell 2.0, .NET Framework 3.5 SP1, Windows Installer 4.5, Windows Single Instance Store, oltre ad un’istanza su un SQL Server 2008 SP1 32 o 64 bit, Standard o Enterprise Edition
  • Supporta il restore granulare anche delle singole macchine virtuali (a differenza di Windows Server Backup)
  • Necessita di un agent (Protection Agent) installato su ogni server Hyper-V su cui si vuole attivare la protezione
  • E’ in grado di attivare la protezione degli host Hyper-V anche sotto Failover Cluster
  • E’ in grado di backuppare le macchine virtuali memorizzate in uno storage CSV di un cluster (a differenza di Windows Server Backup)

In un successivo articolo della serie mostrerò le procedure step-by-step per impostare il backup delle macchine virtuali con Windows Server Backup e con Data Protection Manager 2010 (per il supporto CSV).

Nella settima parte di questo articolo, dimostrerò step-by-step le procedure di implementazione di un Failover Cluster Windows Server 2008 R2, con attivazione dell’infrastruttura CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun 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 4

Scritto da Ivan Salvade' il 23 maggio 2011

In questa quarta parte dell’articolo su CSV, analizzerò la configurazione di rete necessaria per la migliore implementazione della tecnica CSV.  Ecco i link alle precedenti parti dell’articolo :

Terminologie

E’ importante non fare confusione tra diverse terminologie utilizzate quando si parla di configurazione di rete in ambiente Cluster / Hyper-V:

  • Schede di rete (Physical Network Adapters) : rappresentano l’hardware, cioè le schede di rete fisicamente inserite nei server che rappresentano i nodi del cluster
  • Reti del Cluster (Cluster Networks) : rappresentano le reti create durante la formazione del cluster, che collegano le schede di rete appartenenti ad una stessa sottorete, presenti sui nodi del cluster.   Per esempio, se durante la creazione del cluster venissero rilevate su 2 nodi le seguenti schede di rete :
    • Nodo 1 : scheda di rete con indirizzo IP 192.168.1.1/24
    • Nodo 2 : scheda di rete con indirizzo IP 192.168.1.2/24
    • … verrebbe creata una Cluster Network chiamata “Cluster Network 1″, con Network ID 192.168.1.0 e subnet mask 255.255.255.0, visualizzabile nella console del Cluster; questa Cluster Network verrebbe ritenuta LAN utile a far transitare su di essa traffico di rete relativo al cluster, collegando le schede di rete suddette

  • Reti Virtuali (Virtual Networks) : rappresentano le reti create sugli host Hyper-V (è molto comodo immaginarle come degli “switch di rete” veri e propri), utilizzate per collegare tra di loro in rete le macchine virtuali, gli host fisici e il resto della LAN aziendale

Le reti da utilizzare in un cluster CSV

Sicuramente vi è la necessità di dotare i nodi del cluster di più schede di rete. Si va da un minimo di 2-3 schede di rete per nodo in piccoli ambienti, ad un massimo di 7-8 schede di rete per nodo in grandi ambienti, dove è anche importante la ridondanza delle reti stesse.

N.B. : questa sezione non può essere esaustiva : la configurazione di rete, soprattutto in grossi ambienti di virtualizzazione, deve essere opportunamente progettata e testata a seconda delle necessità. Quelle che seguono sono solo generali linee guida.

Detto questo, quali sono le reti necessarie ? Ecco l’elenco completo :

  • GESTIONE : rete su cui si effettuano le operazioni di gestione del cluster, dell’Hyper-V e delle macchine virtuali, oltre ad ospitare il flusso di dati di un’eventuale backup via rete della Parent Partition e/o delle Child Partitions
  • PUBBLICA : rete su cui fluiscono i dati destinati alle macchine virtuali. Si deve affacciare alla rete di produzione e tipicamente possiede un gateway
  • iSCSI : rete dedicata alle comunicazioni iSCSI verso lo storage. Se si utilizza uno storage raggiungibile in fibra ottica, questa rete non è necessaria
  • PRIVATA : rete su cui fluiscono le comunicazioni interne del cluster (Hearthbeat) e anche le comunicazioni CSV (se CSV è implementato)
  • LIVE MIGRATION : rete su cui fluisce una Live Migration di Hyper-V·
  • CSV : rete dedicata alle comunicazioni CSV, se non si vuole utilizzare la PRIVATA a tale scopo

La seguente tabella può riassumere la massima dotazione di schede di rete necessaria (per nodo), a seconda del tipo di connessione allo storage, in un cluster Hyper-V configurato con CSV e su cui si vogliono eseguire le Live Migrations :

Gestione

Pubblica

iSCSI

Privata

Live Mig.

CSV

Totali

FC

1

1 / 2

/

1

1

1

5 / 6

iSCSI

1

1 / 2

2

1

1

1

7 / 8

Nelle colonne “Pubblica” e “iSCSI”, la seconda scheda di rete indica la possibilità/necessità di ridondare quel tipo di rete. Se si sceglie la ridondanza, è necesario implementare opportunamente una soluzione MPIO (Multipath I/O).

In un piccolo ambiente, è possibile ridurrre anche a 2/3 il numero di reti necessarie, sebbene in questo caso non si possano ottenere né le massime performance del cluster, né la ridondanza dei percorsi di rete. Bisognerebbe poi ricorrere all’implementazione di VLAN e/o QoS per isolare i vari tipi di traffico e garantire loro la necessaria banda. Esempi potrebbero essere questi :

  • Scheda di rete 1 : Gestione + Pubblica + Iscsi (comunque sconsigliata : iSCSI richiederebbe sempre una scheda di rete riservata!)
  • Scheda di rete 2 : Privata + Live Migration + CSV

Oppure

  • Scheda di rete 1 : Gestione + Pubblica
  • Scheda di rete 2 : Iscsi
  • Scheda di rete 3 : Privata + Live Migration + CSV

Tutte le suddette schede di rete dovrebbero essere almeno di tipo 1GbE. Le generali performance non possono altro che migliorare se abbiamo in dotazione le 10GbE : queste andrebbero implementate preferibilmente sulle reti iSCSI, CSV e Live Migration, soprattutto se utilizzate per più scopi.

Il Teaming delle schede di rete

Microsoft non supporta direttamente il NIC teaming per Hyper-V, in quanto non possiede drivers proprietari di tutte le marche di schede di rete esistenti al mondo. D’altro canto i drivers forniti dai produttori delle schede di rete spesso riportano il teaming come “opzione possibile”.

In definitiva, si può affermare che il teaming è utilizzabile anche in ambiente Hyper-V, ma a patto che il supporto in caso di problematiche venga dato dal fornitore del driver.

Ricordo anche che non è supportato il teaming delle schede di rete utilizzate per le comunicazioni iSCSI. Quindi non si può utilizzare una scheda di rete logica (cioè creata su due fisiche in teaming) quando si utilizza il “Microsoft iSCSI Software Initiator” per presentare i LUN ad una Parent Partition di Hyper-V.

Creazione delle Cluster Networks

Prima di procedere alla creazione di un cluster, è opportuno pianificare con precisione quante Cluster Networks si vogliono utilizzare, e di conseguenza quante schede di rete è necessario installare sui nodi.     A questo scopo, consultare la precedente sezione “Le reti da utilizzare in un cluster CSV”.

Una volta installate le schede di rete nei nodi (possibilmente tutte dello stesso costruttore e tutte con gli stessi parametri di configurazione), è opportuno assegnare loro un nome preciso per meglio riconoscerle (es. Rete Pubblica, Rete Privata, Rete iSCSI, ecc.), oltre alla configurazione IP prevista.

Per controllare se le schede di rete sono configurate correttamente, si utilizza il wizard “Validate a Configuration” dalla console del Failover Cluster.   Questo wizard esegue i seguenti test :

  • Inventario hardware e software dei nodi
  • Test della configurazione di rete
  • Test dello storage
  • Test della configurazione del sistema

E’ opportuno eseguire singolarmente e ripetutamente il test della configurazione di rete (molto veloce), finchè il report non presenta una valutazione positiva della configurazione di rete effettuata.   Il test esegue i seguenti controlli :

  • controlla l’ordine dei “Bindings” delle schede di rete sui nodi
  • presenta in anteprima le Cluster Networks che verrebbero create nel cluster, in base alle schede di rete fisiche installate nei nodi
  • controlla che, per una particolare Cluster Network, tutte le schede di rete abbiano l’indirizzo IP assegnato con la stessa modalità (o tutti statici, o tutti dinamici)
  • controlla che, per una particolare Cluster Network, tutte le schede di rete utilizzino la stessa versione di IP (o tutte IPV4, o tutte IPV6)
  • controlla che non ci siano schede di rete con indirizzi IP duplicati
  • controlla il numero di schede di rete presenti su ogni nodo : se ne viene trovata una sola, viene segnalato il “single point of failure” della Cluster Network mappata a quella scheda di rete
  • controlla che nessun nodo abbia multiple schede di rete sulla stessa subnet
  • controlla che i nodi possano comunicare su tutte le reti con una latenza accettabile
  • controlla che il Windows Firewall sia configurato correttamente su tutti i nodi

Le schede di rete vanno configurate sui nodi in maniera speculare.  Ecco un esempio nella seguente illustrazione :

cluster-network-diagram.jpg   (clicca per ingrandire)

Nella seguente figura, ecco le schede di rete opportunamente create e rinominate su un nodo del cluster :

elenco-connessioni-rete-consigliate-per-csv.jpg

Facendo trovare le schede di rete già perfettamente configurate al wizard di creazione del cluster, questo creerà le Cluster Networks in maniera pulita e consistente, associando alla stessa Cluster Network le schede di rete appartenenti alla stessa subnet.

Il cluster crea le Cluster Networks con una nomenclatura di default : “Cluster Network 1″, “Cluster Network 2″, ecc… .   E’ opportuno rinominarle in maniera appropriata appena si accede alla console del Failover Cluster.

L’ordine di creazione rispetta l’ordine di binding delle schede di rete dei nodi.  Quindi, come si vede nella figura, se l’ordine di binding prevede “Rete di Gestione” al primo posto e “Rete iSCSI” al secondo, le schede “Rete di Gestione” dei vari nodi saranno associate alla “Cluster Network 1″, mentre le schede “Rete iSCSI” dei vari nodi saranno associate alla “Cluster Network 2″, e via dicendo.

Se i bindings sui vari nodi non sono regolati in maniera identica, viene tenuto buono l’ordine di binding del “primo nodo”, dove con “primo nodo” si intende quello il cui nome DNS è primo in ordine alfabetico (non è tenuto in considerazione l’ordine degli indirizzi IP).

Ordine di binding delle schede di rete consigliato in un cluster CSV

E’ importante regolare l’ordine di binding dei server Hyper-V dotati di multiple schede di rete, soprattutto se sono inseriti in un cluster.  Supponendo di utilizzare una scheda di rete per ogni scopo, l’ordine di binding consigliato è il seguente :

  1. Rete dedicata alla gestione dell’Hyper-V
  2. Rete dedicata alle comunicazioni iSCSI
  3. Rete dedicata alla Live Migration
  4. Rete dedicata agli Heartbeat del cluster e alle comunicazioni CSV
  5. Rete pubblica (col gateway) su cui sono collegate le Virtual Networks degli host Hyper-V

In Windows Server 2008 R2, per regolare l’ordine di binding delle schede di rete, si utilizza lo strumento “Network and Sharing Center”, si entra in “Change Adapter Settings”, e si preme il tasto ALT : compare in alto una barra dei menù, dove si utilizza l’elenco “Advanced” per la regolazione :

come-accedere-ai-bindings.jpg

bindings.jpg

Dedicare una rete alle comunicazioni CSV

Come accennato in anteprima nella parte 2 di questo articolo, la raccomandazione principale in ambiente CSV è quella di dedicare una rete (”Cluster Network”) alle comunicazioni CSV.

Per default, il cluster sceglie in automatico la rete da utilizzare per le comunicazioni CSV.  La scelta è effettuata ricercando le schede di rete che appaiono essere “le migliori” (più veloci) tra quelle disponibili nei nodi.   E’ tuttavia possibile imporre al cluster una scelta obbligata, utilizzando due particolari parametri delle reti di un cluster : ”Metric e “Autometric“.

Al parametro “Metric” possono essere assegnati (manualmente da noi o in automatico dal cluster) valori numerici che indicano il “costo” di una certa rete : più il valore è basso, più quella rete è ritenuta veloce, e quindi idonea per le comunicazioni CSV.

Il parametro Autometric è booleano.  Può assumere i valori True (default) o False.  Quando è posto a True, il cluster regola in automatico il valore del parametro Metric delle reti.   Non appena imposto manualmente il parametro Metric, il parametro Autometric viene automaticamente modificato in False.

Quando il parametro Autometric è posto a True, il cluster assegna in automatico un valore 1000 o superiore per quelle  reti che non hanno un default gateway impostato (per esempio le reti private), mentre assegna un valore 10000 o superiore per le reti che sono dotate di default gateway (per esempio le reti pubbliche, usate per collegarsi al parco client o a Internet).

Ecco un esempio :

comandi-shell-get-su-5-reti-copy.jpg   (clicca sulla figura per ingrandire)

Per imporsi sulla rete da usare per le comunicazioni CSV, assegnare al parametro Metric della rete prescelta un valore inferiore a 1000, o comunque inferiore a qualunque altro parametro Metric impostato su altre reti.

Per eseguire questa operazione, si utilizza un comando di Powershell, disponibile dopo aver caricato il modulo di comandi per il Failover Cluster.   Il comando è : Get-ClusterNetwork.

Per caricare il modulo di comandi, aprire Powershell e digitare :

Import-Module FailoverClusters

Per visualizzare la situazione del momento, si può utilizzare la seguente sintassi :

Get-ClusterNetwork | Ft  Name, Address, Metric, Autometric, Role

Questo comando elenca le proprietà attuali delle reti presenti sul cluster (nome, indirizzo IP, valori assegnati ai parametri Metric e Autometric, ruolo).     La proprietà “Ruolo” può avere i seguenti valori :

  • 1 :  rete ad uso privato
  • 3 :  rete ad uso misto pubblico/privato
  • 0 :  rete ignorata dal cluster (non sono permesse le comunicazioni del cluster)

Per modificare il parametro Metric di una rete (es. per impostarlo a 100), usare la seguente sintassi :

(Get-ClusterNetwork “Cluster Network x“).metric = 100

Il ruolo delle reti viene scelto dal Cluster in base alle seguenti valutazioni :

  • Rete con il parametro Metric più basso : rete per CSV e comunicazioni interne del cluster
  • Rete con il secondo parametro Metric più basso : rete utilizzata per la Live Migration
  • Reti  con parametri Metric più alti : reti utilizzate per il traffico pubblico e di gestione

Ecco un esempio di settaggio statico del parametro Metric delle Cluster Network :

regolazione-statica-delle-metriche.jpg    (clicca sulla figura per ingrandire)

Nota : la rete utilizzata per la Live Migration può essere scelta anche dalla console grafica del Failover Cluster, nelle proprietà di una macchina virtuale clusterizzata, nel tab “Network for Live Migration”.    E’ possibile indicare anche più di una rete :  verranno utilizzate nell’ordine di preferenza indicato.   Il parametro è globale : una volta configurato per una macchina virtuale, si applica anche alle altre dello stesso cluster.

Nella quinta parte di questo articolo, analizzerò il funzionamento del Redirected Access in un cluster 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 »

Le prossime tematiche trattate nel mio blog…

Scritto da Ivan Salvade' il 25 aprile 2011

Ciao a tutti

Rieccomi!!  :-) 

Dopo un periodo di lunghe e continue trasferte lavorative, che mi hanno costretto a trascurare il blog,  riprendo da oggi a postare articoli con una maggiore frequenza :-)

Ecco un’anteprima delle tematiche trattate nei prossimi articoli :

  • Architettura e funzionamento di “Cluster Shared Volumes” (CSV) e “Live Migration” in Windows Server 2008 R2
  • Strategie di Backup delle immagini virtuali Hyper-V
  • Il “Redirected Mode” nel Failover Clustering di Windows Server 2008 R2
  • Prime impressioni sul beta testing di “System Center Virtual Machine Manager 2012″
  • Prime impressioni sul beta testing di “System Center Configuration Manager 2012″
  • Architettura e implementazione del “Remote Desktop Connection Broker” in una farm aziendale di Server Terminali (Remote Desktop Session Hosts)
  • Gestione centralizzata e personalizzata delle firme e dei disclaimer in Exchange Server 2010 SP1

Come potete vedere, ce n’è per tutti i gusti!!

Buona lettura a tutti :-)

  • Share/Bookmark

Pubblicato in Generale | Nessun commento »

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