Ivan Salvade’

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

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • 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 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