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

Archivi per la categoria 'Virtualizzazione' Categoria


Le novità di Hyper-V 2016

Scritto da Ivan Salvade' il 7 ottobre 2015

Ecco alcune delle novità salienti della piattaforma Hyper-V 2016…

Versione di Configurazione delle macchine virtuali

Spostando o importando macchine virtuali da un server Hyper-V 2012 a un server Hyper-V 2016, la versione di configurazione della macchina virtuale rimane impostata a valore 5 (compatibilità garantita con Hyper-V 2012 R2).   L’aggiornamento della versione di configurazione a valore 6 (compatibilità solo con Hyper-V 2016) deve essere eseguita manualmente su ogni macchina virtuale (o in maniera massiva utilizzando comandi powershell).

Per interrogare lo stato della versione, utilizzare il seguente comando powershell :

Get-VM nome_macchina | FT name,version

Per aggiornare la versione, utilizzare il seguente comando powershell :

Update-VMConfigurationVersion nome_macchina

L’operazione di aggiornamento deve essere eseguita a macchina spenta, e non è reversibile.  Non è più inoltre possibile spostare la macchina virtuale su un server Hyper-V 2012.

Nuova estensione del file di configurazione delle macchine virtuali

.VMCX è la nuova estensione dei files di configurazione (invece di .XML).  Inoltre i nuovi file .VMRS contengono i dati di Runtime della macchina virtuale (invece dei vecchi .VSV).

Console di gestione Hyper-V

Con la console di gestione Hyper-V 2016, caricata su un server 2016 o su un client Windows 10, è possibile (finalmente!!) gestire anche piattaforme Hyper-V downlevel, cioè macchine virtuali configurate su Windows Server 2012 e 2012 R2, oppure Windows 8 e 8.1

Aggiornamento in-place di un cluster Hyper-V

Un cluster Hyper-V potrà ora contenere nodi con differenti sistemi operativi : è infatti possibile aggiungere “al volo” un nodo Hyper-V 2016 ad un cluster Hyper-V contenente nodi Hyper-V 2012 R2, senza dover passare dalla creazione di un nuovo cluster parallelo. Il cluster così formato funzionerà in modalità “2012 R2″ (senza cioè poter sfruttare tutte le nuove features 2016) finché non saranno eliminati tutti i nodi 2012 R2.  Quando tutti i nodi saranno 2016, sarà possibile innalzare il livello di funzionamento del cluster con il comando powershell “Update-ClusterFunctionalLevel”.

In un cluster “ibrido”, è sempre possibile spostare a caldo le macchine virtuali dai nodi 2012 R2 a quelli 2016, o viceversa.

Quando la modalità del cluster è 2012 R2 con nodi 2016 già inseriti, tenere presente che :

  • la gestione deve essere eseguita dalla console Hyper-V 2016 o da un client Windows 10
  • la versione di configurazione delle macchine virtuali esistenti rimane a 5 (cioè compatibile con 2012 R2)
  • l’aggiornamento della versione di configurazione a valore 6 (compatibile solo 2016), potrà essere eseguita solo quando il livello di funzionamento del cluster è innalzato a 2016
  • le nuove macchine virtuali create sono sempre con versione di configurazione pari a 5

Quando la modalità del cluster viene innalzata a 2016,  tenere presente che :

  • la versione di configurazione di ogni macchina virtuale deve essere innalzata a 6 (da console grafica o tramite il comando powershell “Update-VMConfigurationVersion”) per poter sfruttare le nuove features di Hyper-V 2016
  • non si possono più aggiungere nodi 2012 R2 al cluster

Aggiunta a caldo di memoria e schede di rete alle macchine virtuali

E’ possibile eseguire questa operazione sia su macchine virtuali di Generazione 1 che su quelle di Generazione 2, contenenti sistemi operativi Windows o Linux.

La RAM è modificabile anche se la macchina virtuale non è mai stata impostata ad utilizzare la Memoria Dinamica.

Production Checkpoint

E’ una tecnica che permette di creare snapshot (fotografie) “consistenti” di una macchina virtuale.  “Consistenti” significa che questi snapshot possono essere utilizzati in tempi successivi, con il pieno supporto Microsoft per tutti  i workload di produzione.

I Production Checkpoint utilizzano la tecnologia di backup VSS interna alle macchine virtuali, piuttosto che utilizzare la tecnologia “Salva Stato” esterna alle macchine virtuali, che realizzerebbe snapshot probabilmente inconsistenti in caso di loro creazione a macchina accesa.

Sono comunque ancora utilizzabili i normali Checkpoint, presenti nelle release precedenti di Hyper-V.

Protocolli di gestione remota

Hyper-V Manager può gestire server Hyper-V remoti utilizzando il protocollo WS-MAN (Web Services Management) su porta 80.  E’ possibile eseguire le autenticazioni tra server Hyper-V remoti utilizzando Kerberos, NTLM o CredSSP.   Usando CredSSP è possibile lanciare una Live Migration di una macchina virtuale senza prima configurare la Constrained Delegation in Active Directory (necessaria invece in piattaforma 2012).

Esecuzione di comandi powershell all’interno di una macchine virtuale

E’ possibile ora eseguire comandi powershell nel sistema operativo Guest, lanciandoli dall’Host Hyper-V.

Unici prerequisiti sono :

  • la presenza dei sistemi operativi Windows Server 2016 o Windows 10, sia sull’Host che nella macchina virtuale; nessuna modifica di rete o sui firewall è richiesta
  • credenziali amministrative complete sia sull’Host che sulla macchina virtuale
  • la macchina virtuale deve essere in esecuzione localmente sull’Host

Bisogna creare una sessione powershell verso la macchina virtuale con il seguente comando :

Enter-PSSession -VMName nome_macchina_virtuale

Successivamente si possono lanciare comandi powershell nel modo seguente :

Invoke-Command -VMName nome_macchina_virtuale -ScriptBlock {comando}


  • Share/Bookmark

Pubblicato in Hyper-V, Virtualizzazione | Nessun commento »

Windows Server 2012 R2 alle porte…

Scritto da Ivan Salvade' il 3 giugno 2013

Parecchie novità segnalate nella seconda release di Windows Server 2012.

Le più interessanti, secondo me, riguardano Hyper-V.  Eccone una veloce panoramica :

  • Nuovo tipo di macchine virtuali creabili (”Generation 2 VMs”) : eseguono boot da UEFI e non hanno devices emulati.  Compatibili solo ad ospitare Windows Server 2012 e Windows 8 come sistema operativo Guest.  Hanno lo “scopo” di assomigliare il più possibile ad un’effettiva macchina fisica.  Si affiancano alle macchine virtuali di vecchia generazione, naturalmente ancora presenti
  • Live Migration più veloce con compressione dei dati
  • Live Migration over SMB
  • Ridimensionamento a caldo dei dischi virtuali in formato VHDX
  • Live Virtual Machine Cloning, in pratica la possibilità di esportare a caldo uno snapshot di una macchina virtuale, a scopo di eseguire la risoluzione di un problema in laboratorio
  • Hyper-V Replica con frequenza di replica configurabile tra 30 secondi e 15 minuti
  • Data Deduplication supportata su librerie di VHD online
  • Live Migration, Live Backup, Memoria Dinamica e ridimensionamento VHDX anche per macchine virtuali Linux (dotate di Hyper-V Linux Integration Services)

Non vedo l’ora di testare queste novità. Voi?  :-)

  • Share/Bookmark

Pubblicato in Cafè, Hyper-V, Virtualizzazione, Windows Server 2012 | Nessun commento »

Le novità di Windows Server 2012 - parte 2 - : Hyper-V Virtual Switch

Scritto da Ivan Salvade' il 15 novembre 2012

Link per tornare all’indice degli articoli della serie “Le novità di Windows Server 2012” :

http://ivansalvade.it/2012/09/06/le-novita-di-windows-server-2012-indice-generale-degli-articoli/

—————————————————————————————————————————————————————————————————————————–

Come spesso ho detto nei corsi su Hyper-V in versione 1 e 2, ho sempre ritenuto il termine “Virtual Network” piuttosto ambiguo, ed infatti è ora stato sostituito con il più appropriato termine “Virtual Switch”.

In effetti, una rete virtuale di Hyper-V è ben di più di una semplice rete virtuale, come il termine Virtual Network poteva far pensare :  è, a tutti gli effetti, una vera e propria versione virtuale di uno switch di rete (per la precisione, è una rappresentazione software di uno switch di rete Layer 2), e ad esso possono essere collegate le schede di rete delle macchine virtuali e le schede di rete fisiche dei server fisici, permettendo le comunicazioni tra le macchine virtuali, gli host fisici e gli altri dispositivi presenti in rete.

E’ quindi assolutamente appropriata la scelta di Microsoft di rinominarlo “Virtual Switch”.

Essendo dotato di numerose estensioni e personalizzazioni, il Virtual Switch è denominato anche “Hyper-V Extensible Switch”.

Come nella precedente release, Hyper-V 3.0 supporta tre differenti tipi di Virtual Switch :

  • External : da utilizzare per mappare una rete ad una specifica scheda di rete fisica dell’host (o team di schede di rete fisiche) e permettere le comunicazioni delle macchine virtuali verso intere reti fisiche.  La novità In Hyper-V 3.0 è la possibilità di mappare un virtual switch External ad una scheda di rete wireless, a patto che il server Hyper-V abbia una scheda wireless compatibile ed il servizio “Wireless Local Area Network” installato
  • Internal : da utilizzare per permettere le comunicazioni tra le macchine virtuali presenti su un host hyper-V e l’host stesso (ma non permettere comunicazioni verso altri dispositivi presenti in rete)
  • Private : da utilizzare per permettere comunicazioni solo tra le macchine virtuali presenti su un certo host

Per un virtual switch di tipo External o Internal, è possibile configurare anche un VLAN ID (numero compreso tra 1 e 4094) che possa essere associato alla rete.  Questo permette di estendere le VLAN esistenti sulla rete esterna alle VLAN configurate sui virtual switch degli host Hyper-V.  Le VLAN permettono di partizionare il traffico di rete , e funzionano come reti logiche separate.  Il traffico può passare da una VLAN all’altra solo se attraversa un router.

In Hyper-V 3.0 è ora possibile dotare un virtual switch di particolari estensioni :

  • si possono installare “Filtri NDIS (Network Driver Interface Specification) personalizzati” oppure “Filtri WFP (Windows Filtering Platform) personalizzati”, agganciati come estensioni all’Hyper-V Virtual Switch, che possono eseguire diverse operazioni ausiliarie, come per esempio la cattura e il monitoraggio dei pacchetti, oppure il filtraggio e l’inoltro (es. ispezione ed eliminazione di alcuni pacchetti, o reindirizzamento verso opportune VLAN).   Tutti questi filtri possono essere realizzati da Microsoft oppure da terze parti, rispettando l’architettura “NDIS Filter Driver”.   Le estensioni sono visibili nelle proprietà di un certo Virtual Switch, come mostrato in Fig. 1 :

1virtswext.JPG   Fig. 1

Ulteriori capacità avanzate sono utilizzabili dai Virtual Switch.  Sono reperibili nella sezione “Advanced Features” di ogni Network Adapter di ogni macchina virtuale : sono quindi capacità attivabili per macchina virtuale e/o per scheda di rete virtuale.  Ecco l’elenco :

  • è attivabile il DHCP Guard (Fig. 2) : è una tecnica che evita la spedizione di messaggi DHCP da parte di macchine virtuali che “pretendono” di essere Server DHCP.  Questo è utile, per esempio, in un’azienda dotata di un lab, dove spesso i sistemisti creano ambienti virtuali di test, e dove può accadere che qualche macchina virtuale server con i servizi DHCP installati inizi a distribuire indirizzi IP a destra e a manca in produzione.  Questo può essere evitato anche con altri accorgimenti (netta separazione tra produzione e lab, blocco dell’autorizzazione dei server DHCP virtuali in Active Directory, configurazione di regole a livello degli switch/router di rete, ecc…), ma indubbiamente la semplicità di questo metodo (un banale flag) è lampante :-)
  • è attivabile il Router Guard (Fig. 2) : è una tecnica simile al DHCP Guard, con lo scopo di evitare la spedizione di messaggi di tipo “Router Advertisement” (messaggi rilasciati periodicamente, o su sollecitazione di un host, da un router, per indicare la propria presenza e la propria configurazione) e di tipo “Redirection” (indicano la necessità, per una certa comunicazione, di dover utilizzare - o no - un certo router per raggiungere la destinazione) da parte di macchine virtuali configurate come dei router (es. RRAS installato)
  • è attivabile il MAC Address Spoofing (Fig. 2) : è una tecnica (già presente in Hyper-V 2.0) che permetterebbe alle macchine virtuali (o a del software all’interno delle macchine virtuali) di modificare il MAC Address sorgente dei pacchetti uscenti in un MAC Address non assegnato alle macchine virtuali stesse.   Questa possibilità è disabilitata per default, per ovvi motivi di sicurezza (MAC address spoofing usato a scopo malizioso), ma potrebbe essere utile in alcuni scenari : per esempio quando configuro le macchine virtuali in NLB utilizzando la modalità Unicast, oppure quando utilizzo una macchina virtuale dentro un’altra (es. quando eseguo una VM Virtual PC dentro una VM Hyper-V, oppure quando utilizzo i simulatori virtuali dei palmari in una VM Hyper-V)

2macdhcprout.JPG   Fig. 2

  • è attivabile il Port Mirroring (Fig. 3) : permette di monitorare il traffico di rete di una macchina virtuale, inoltrando copie dei suoi pacchetti entranti o uscenti (configurabile) ad un’altra macchina virtuale, utilizzata  a scopo di monitoraggio

3portmirteam.JPG   Fig. 3

  • è attivabile il NIC Teaming (Fig. 3) : permette ad una macchina virtuale di avere schede di rete virtuali connesse a più di uno switch virtuale, e di continuare ad avere connettività anche se la scheda di rete fisica agganciata ad uno degli switch virtuali smettesse di funzionare
  • nella sezione “Hardware Acceleration” è attivabile “Virtual Machine Queue” (Fig. 4) : questa tecnica permette di generare, sulla scheda di rete dell’host, una coda dedicata per ogni scheda di rete virtuale.  E’ in pratica un modo per far apparire, alle macchine virtuali, la singola scheda di rete dell’host come se fosse un “insieme” di schede di rete, e ogni scheda di rete virtuale può creare ed utilizzare una propria coda specifica per il proprio traffico di rete.  Questo comporta un generale miglioramento delle operazioni di I/O
  • nella sezione “Hardware Acceleration” è attivabile “IPSec Task Offloading” (Fig. 4) :  ora anche la macchina virtuale può trasferire in offload alla scheda di rete fisica dell’host fisico.  Questo libera risorse CPU.   La regolazione del numero delle Security Associations (SA) tra 1 e 4096, permette di bilanciare la necessità di eseguire IPSec Offloading da parte di più macchine virtuali

4hwacc.JPG      Fig. 4

  • Nelle proprietà di una scheda di rete virtuale esiste la possibilità di utilizzare “Bandwidth Management” (Fig. 5) : questo permette di indicare per ogni macchina virtuale le quantità minima e massima (in Mb al secondo) di utilizzo della rete.

5bdwthmgm.JPG      Fig. 5

    Un’ulteriore funzionalità è disponibile nelle proprietà di un Virtual Switch.  Si tratta di ”Single-root I/O Virtualization (SR-IOV)” (Fig. 6) : è una tecnica che sfrutta il supporto dei chipset per le tecnologie di virtualizzazione, e che permette la ri-mappatura di DMA e interrupt in modo che alcune periferiche (che supportino SR-IOV) possano essere mappate direttamente alle macchine virtuali.  La disponibilità di SR-IOV nel Virtual Switch permette l’applicazione di questa tecnica a schede di rete fisiche presenti nell’host Hyper-V, a patto che la scheda di rete ed il suo driver siano compatibili con SR-IOV (il driver deve essere presente sia nel sistema operativo dell’host che in quello della macchina virtuale).

      9-sr-iov.JPG      Fig. 6

      • Share/Bookmark

      Pubblicato in Hyper-V, Virtualizzazione, Windows Server 2012 | Nessun commento »

      Le novità di Windows Server 2012 - parte 1 - : i nuovi limiti di Hyper-V

      Scritto da Ivan Salvade' il 10 settembre 2012

      Link per tornare all’indice degli articoli della serie “Le novità di Windows Server 2012” :

      http://ivansalvade.it/2012/09/06/le-novita-di-windows-server-2012-indice-generale-degli-articoli/

      —————————————————————————————————————————————————————————————————————————–

      Hyper-V 3.0 in Windows Server 2012 implementa nuovi limiti (per host e per macchina virtuale), molti dei quali ampiamente superiori alla precedente release.

      Eccoli riassunti nelle seguenti tabelle :

      Limiti per host Hyper-V

      hypervlimxsrv.jpg

      Fig. 1 : limiti per singolo Host Hyper-V

      Limiti per macchina virtuale

      hypervlimxvm2.jpg

      Fig. 2 : limiti per singola macchina virtuale

      Ecco qua sotto ulteriori delucidazioni sul contenuto delle tabelle precedenti.

      (1)     (2)

      Differenza tra processori logici e virtuali

      Per capire bene la differenza tra Processori Logici (Logical Processor) e Processori Virtuali (Virtual Processor), nel modo in cui la concepisce Microsoft,  è necessario avere un minimo di conoscenza dell’architettura dei processori e delle tecniche di MultiThreading.

      I concetti base si possono sintetizzare così :

      1. Un processore è un dispositivo che esegue istruzioni (chiamate “Thread”)
      2. Inzialmente i processori eseguivano i thread in maniera seriale, uno alla volta
      3. Dai primi anni 2000 è stata introdotta la tecnica “MultiThreading”, che permette ad un processore di eseguire più thread in contemporanea.  Intel ha chiamato questa tecnica “Hyper-Threading”, ed ha cominciato ad implementarla sui suoi processori a partire dal 2002, limitando i suoi processori all’esecuzione di non più di 2 thread in contemporanea
      4. Dal punto di vista del sistema operativo, un processore con la tecnica Hyper-Threading viene visto (per esempio nel Task Manager) come un doppio processore, e le due CPU condividono RAM e Cache.  Per sfruttare correttamente l’Hyper-Threading (e migliorare le prestazioni), le applicazioni devono saper interagire con questa tecnica
      5. Intel ha abbandonato la tecnologia Hyper-Threading con l’avvento dei processori dual-core, per poi reintrodurla intorno al 2008 con l’architettura Nehalem.
      6. Quindi ora esistono processori multi-core e multi-threading : per fare un esempio, un processore quad-core multi-threaded può eseguire 4*2=8 thread in contemporanea, e quindi viene visto dal sistema operativo come un processore “a 8 vie” (vedi Fig. 3) :

      taskmgrcores.JPG

      Fig. 3 : rappresentazione in Task Manager di un processore Intel I7 Q720 (Quad-Core con Hyper-Threading)

      Chiariti questi concetti base, ora possiamo dare le seguenti definizioni :

      • Processore fisico : il chip fisico inserito in un socket nelle mainboard
      • Processore logico : può rappresentare un Core o un Thread a seconda delle caratteristiche del processore fisico :
        • Se non è dotato di tecnologia Hyper-Threading (e quindi esegue solo un thread alla volta), allora 1 Processore Logico = 1 Core (quindi si dice che un processore fisico quad-core è dotato di 4 processori logici)
        • Se è dotato di tecnologia Hyper-Threading (e quindi esegue due thread alla volta), allora 1 Processore Logico = 1 thread (quindi si dice che un processore fisico quad core è dotato di 8 processori logici)
      • Processore virtuale : il processore assegnato in utilizzo alle macchine virtuali

      Ulteriori chiarimenti sono necessari per comprendere come Microsoft utilizza i Processori Virtuali : essi sono associati ai processori logici, e non ai Core o ai processori fisici.

      E’ stata fatta questa scelta per avere una misura più precisa e accurata della potenza di calcolo dei processori : se i processori virtuali fossero stati associati ai Core, sarebbe stata ignorata l’architettura del processore fisico (single-threaded o multi-threaded).  Associando un processore virtuale ai processori logici, si tiene invece conto dell’architettura del processore fisico.

      Ecco perché, nella tabella di Fig. 1, sono riportati due limiti :

      • Il numero massimo di Processori Virtuali per Processore Logico
      • Il numero massimo di Processori Virtuali per intero Server

      (3)

      In Windows Server 2008 R2 SP1, è supportato un massimo di 12 processori virtuali per processore logico, ma solo se tutti i sistemi operativi guest del server eseguono  Windows 7 (quindi per ambienti VDI); altrimenti il numero massimo supportato di processori virtuali per processore logico è 8.

      In Windows Server 2012 ogni limite è stato rimosso.

      (4)

      In Windows Server 2008 R2 SP1, il numero massimo supportato di processori virtuali per Server dipende dal numero massimo supportato di processori virtuali per processore logico : in ambienti VDI, con il rapporto 12:1, allora possiamo avere 64*8=512 processori virtuali; in ambienti non-VDI, con il rapporto 8:1, possiamo avere 64*12=768 processori virtuali.

      In Windows Server 2012 il limite è stato aumentato a 2048.

      (5)

      La grandezza massima è determinata dal sistema operativo guest

      (6)

      Sia Windows Server 2008 R2 SP1 che Windows Server 2012 supportano un massimo di 8 schede di rete di tipo sintetico e 4 schede di rete di tipo legacy (queste ultime utilizzabili per effettuare un boot PXE, in quanto il loro driver è emulato via software).

      Inoltre Windows Server 2012 supporta anche 4 adattatori a fibra ottica (FCA) per il collegamento delle macchine virtuali a un “Virtual Fibre Channel per Hyper-V”, che permette alle macchine virtuali stesse di collegarsi direttamente a SAN raggiungibili in fibra ottica.  Questo consente, per esempio, ad un’applicazione come SQL, in esecuzione in una macchina virtuale, di connettersi direttamente ai LUN di una SAN a fibra ottica.

      • Share/Bookmark

      Pubblicato in Hyper-V, Virtualizzazione, Windows Server 2012 | Nessun commento »

      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 »

      Windows Thin PC è RTM

      Scritto da Ivan Salvade' il 7 giugno 2011

      Il 6 giugno 2011 è terminato lo sviluppo di Windows Thin PC.  Sarà disponibile per il download ai clienti Microsoft Software Assurance dal 1 luglio 2011.

      Windows Thin PC permette alle aziende di riutilizzare come “thin pc” computer vecchi e destinati alla dismissione.   Windows Thin PC non è altro che un piccolo sistema operativo Windows 7, il cui scopo principale è permettere una connessione Desktop Remoto verso i desktop aziendali virtualizzati tramite VDI (Virtual Desktop Infrastructure).

      Il deploy di Windows Thin PC è gestibile centralmente, per grandi aziende, tramite i prodotti della suite System Center.

      I requisiti hardware sono minimi :

      • Processore a 32 bit a 1 GHz
      • 1 GB di RAM
      • 16 GB di spazio su disco
      • Scheda grafica compatibile con DirectX 9 e un driver WDDM 1.0 o superiore
      • Un DVD-ROM che possa fare boot

      Windows Thin PC è utilizzabile anche sui portatili (ha il supporto per le schede di rete Wireless), mentre non è supportato il suo utilizzo in una macchina virtuale.

      Per ulteriori informazioni e per accedere all’elenco di FAQ (Frequently Asked Questions) su Windows Thin PC, potete collegarvi al seguente sito :

      http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/thinpc.aspx

      Buona visione del prodotto!!  :-)

      • Share/Bookmark

      Pubblicato in Generale, Virtualizzazione | 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 »

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