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

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 »

      Hyper-V presente in Windows 8 (client)

      Scritto da Ivan Salvade' il 28 ottobre 2011

      Hyper-V sarà incluso in Windows 8 client!!

      Questa è indubbiamente una delle maggiori novità presenti nel prossimo sistema operativo client di Microsoft.

      Avrete bisogno di processori Intel o AMD a 64 bit, di Windows 8 a 64 bit, di almeno 4 Gb di RAM, ma sarete poi in grado di utilizzare Hyper-V anche sul vostro Desktop o Portatile con installato Windows 8, ed eseguire, anche in contemporanea, macchine virtuali a 32 bit e a 64 bit.

      Oggi, per ottenere lo stesso ambiente, sareste costretti ad utilizzare un dual-boot tra Windows 7 e Windows Server 2008 o 2008 R2 (utilizzando Windows 7 Enteprise o Ultimate, il dual boot con Windows Server 2008 R2 potrebbe essere fatto anche utilizzando un VHD, ambiente che utilizzo, per esempio, sul mio portatile personale).

      Hyper-V in Windows 8 avrà le seguenti caratteristiche fondamentali :

      • Allocazione dinamica della memoria (già presente in Hyper-V 2008 R2 SP1)
      • Collegamento alle macchine virtuali con la VM Console oppure tramite Connessione Desktop Remoto
      • Spostamento di macchine virtuali da un disco all’altro, anche se accese
      • Possibilità di effettuare snapshot
      • Aggiornamenti automatici tramite Windows Update
      • Possibilità di far comunicare una macchina virtuale con il mondo esterno attraverso la connessione Wireless del vostro desktop/portatile, oltre che con la connessione Wired

      Quest’ultima tecnica è stata implementata modificando la precedente architettura, che prevedeva la possibilità di creazione di uno switch virtuale (External Network Switch) da collegare ad una scheda di rete fisica del vostro computer.  Così facendo, la scheda di rete fisica doveva essere in grado di far fluire pacchetti aventi diversi MAC address di origine (quello della scheda di rete fisica e quelli delle macchine virtuali) : questo è supportato sulle schede di rete fisiche (facendole funzionare in modalità promiscua), ma non sulle schede di rete wireless, in quanto il canale wi-fi stabilito tra la scheda wireless e l’Access Point consente il flusso solo di pacchetti con il MAC address della scheda wi-fi, e niente altro.

      E’ stata allora implementata la soluzione “Microsoft Bridging”, che ha il compito di sostituire, per i pacchetti in uscita,  i MAC address delle macchine virtuali con il MAC address della scheda wi-fi.  “Microsoft Bridge” mantiene anche una sorta di mappatura interna per consentire al traffico di risposta di raggiungere la corretta macchina virtuale.

      Quindi, se mappo l’External Network Switch ad una scheda di rete wireless, Hyper-V eseguirà le seguenti operazioni :

      1. Creazione del “Microsoft Bridge”, collegato alla scheda di rete wireless
      2. Creazione dell’External Network Switch, che continuerà ad eseguire funzioni di Ethernet switching
      3. Binding dell’External Network Switch al Microsoft Bridge, invece che alla scheda wi-fi fisica

      L’uscita di Windows 8 è, al momento, prevista per la seconda metà del 2012, o addirittura inizio 2013.

      • Share/Bookmark

      Pubblicato in Hyper-V, Windows 8 | 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 »

      Hyper-V R2, event ID 3040 e set di istruzioni AVX

      Scritto da Ivan Salvade' il 22 aprile 2011

      Intel ha ormai immesso sul mercato i cosidetti “Processori Core di Seconda Generazione”, basati sulla microarchitettura a 32nm con nome in codice “Sandy Bridge”, che succede alla microarchitettura “Nehalem” a 45nm.

      I processori della famiglia “Sandy Bridge” sfruttano il nuovo set di istruzioni AVX (Advanced Vector Extensions), che estendono il precedente set di istruzioni SSE (Streaming Single-instruction-multiple-data Extensions).   AVX garantisce un cospicuo aumento delle prestazioni dei processori.   Per chi è curioso, una panoramica del set di istruzioni AVX si può trovare a questo link :

      http://software.intel.com/en-us/avx/

      Purtroppo Hyper-V R2 non è nativamente compatibile con AVX.  Quindi se si installa Hyper-V R2 su macchine fisiche con processori della famiglia Sandy Bridge, e si creano successivamente delle macchine virtuali, queste non partono a causa del mancato supporto a AVX.   Un errore Event ID 3040 viene registrato nel registro “Hyper-V Worker” nel nodo “Application and Services Logs” del Visualizzatore Eventi.

      La soluzione migliore è installare il SP1 di Windows Server 2008 R2, che introduce in Hyper-V il completo supporto al set di istruzioni AVX, sfruttabili quindi anche dalle macchine virtuali.

      Se non si vuole installare il SP1, Microsoft ha creato un hotfix che semplicemente disabilita AVX sui processori virtuali, in modo che le macchine virtuali possano inizializzarsi correttamente.    L’hotfix, nonchè la spiegazione del problema, sono reperibili nell’articolo di KB 2517374, al seguente link :

      http://support.microsoft.com/kb/2517374

      Per completezza, riporto qua sotto una lista di processori Intel di nuova generazione che supportano il set di istruzioni AVX,  sui quali si presenterebbe quindi il problema suddetto :

      Processori Server

      • Xeon-E3 1280, 1275, 1270, 1260L, 1245, 1240, 1235, 1230, 1225, 1220, 1220L
      • Xeon-E5 46xx, 26xx, 24xx, 16xx

      Processori Desktop

      • Core i7 Extreme
      • Core i7 2600K, 2600, 2600S
      • Core i5 2500K, 2500, 2500S, 2500T, 2400, 2405S, 2400S, 2300, 2390T
      • Core i3 2120, 2105, 2100, 2100T
      • Pentium G850, G840, G620, G620T

      Processori Mobile

      • Core i7 Extreme 2920XM
      • Core i7 2820QM, 2720QM, 2715QE, 2710QE, 2635QM, 2620M, 2649M, 2629M, 2657M, 2617M
      • Core i5 2537M, 2540M, 2520M, 2515E, 2510E, 2410M
      • Core i3 2310M
      • Celeron B810, B847
      • Share/Bookmark

      Pubblicato in Hyper-V, Virtualizzazione | Nessun commento »

      Microsoft iSCSI Software Target è ora gratuito

      Scritto da Ivan Salvade' il 5 aprile 2011

      Dal 4 aprile 2011 Microsoft ha deciso di rendere pubblico e gratuito il “Microsoft iSCSI Software Target”.

      Essenzialmente è un software che permette di trasformare un server Windows in un dispositivo di storage (una sorta di SAN) raggiungibile via rete tramite protocollo iSCSI.  Può essere utile per diversi scopi :

      • Fornire storage condiviso ai cluster (in particolare cluster Hyper-V su cui attivare Live e Quick Migration)
      • Consolidare lo storage su un unico server, utilizzabile da diverse applicazioni e diversi server della rete
      • Abilitare il boot remoto di computer senza disco, utilizzando un’immagine di un sistema operativo raggiungibile via iSCSI

      Microsoft iSCSI Software Target era già disponibile per l’uso in produzione a partire dal 2007, ma era incluso solo in Windows Storage Server;  dal 2009 era diventato disponibile in download per tutti i sottoscrittori di abbonamenti Technet e MSDN, a scopo di test e sviluppo.

      Ora “Microsoft iSCSI Software Target 3.3″ è scaricabile gratuitamente (da qui) ed è installabile sui seguenti sistemi operativi :

      • Windows Server 2008 R2 e Windows Server 2008 R2 SP1 Standard Edition (Full installation)
      • Windows Server 2008 R2 e Windows Server 2008 R2 SP1 Enterprise Edition (Full installation)
      • Windows Server 2008 R2 e Windows Server 2008 R2 SP1 Datacenter Edition (Full installation)

      E’ essenzialmente la stessa release presente in Windows Storage Server 2008 R2, ed è fornito ovviamente solo in piattaforma a 64 bit.  Non è installabile su Windows Server 2008 o Windows Server 2003.

      E’ interessante tenere presente le Support Policies di Microsoft per iSCSI Software Target 3.3, visualizzabili al seguente link :

      http://technet.microsoft.com/en-us/library/gg983493(WS.10).aspx

      L’annuncio ufficiale del rilascio lo trovate qui :

      http://blogs.technet.com/b/josebda/archive/2011/04/04/microsoft-iscsi-software-target-3-3-for-windows-server-2008-r2-available-for-public-download.aspx

      Buona giornata!  :-)

      • Share/Bookmark

      Pubblicato in Clustering, Generale, Gestione dei Sistemi, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

      Hyper-V e Virtual Server/Virtual PC sullo stesso computer

      Scritto da Ivan Salvade' il 23 ottobre 2010

      A volte è necessario, soprattutto in ambienti di laboratorio/testing, eseguire sullo stesso host fisico macchine virtuali create/compatibili con Hyper-V e macchine virtuali create/compatibili con Virtual Server 2005 o Virtual PC.
      In ogni caso, è impossibile eseguirle contemporaneamente : non posso cioè utilizzare allo stesso tempo Hyper-V e Virtual Server/Virtual PC su un host fisico.

      La notevole differenza di architettura tra Hyper-V e Virtual Server/Virtual PC, rendono il suddetto scenario NON supportato.   Se su un server (Windows Server 2008 o Windows Server 2008 R2) con il ruolo Hyper-V installato, provo a lanciare macchine virtuali dalle console di Virtual Server o Virtual PC, il risultato è una loro esecuzione talmente lenta, da renderle praticamente inutilizzabili.
      Uno scenario possibile è, invece, eseguire sullo stesso host macchine virtuali Hyper-V e macchine virtuali Virtual Server/Virtual PC, ma NON contemporaneamente : cioè, in breve, o decido di utilizzare sull’host i servizi di Hyper-V, oppure i servizi di Virtual Server/Virtual PC.

      Il trucco consiste nel configurare l’host fisico con una sorta di “Dual-Boot” : se voglio usare Hyper-V, eseguo il boot dell’host in modo che faccia regolarmente partire i servizi di Hyper-V (e questo è il boot di default per un server con il ruolo Hyper-V installato); se voglio usare Virtual Server/Virtual PC, eseguo il boot dell’host in modo che venga mantenuto arrestato l’Hypervisor.
      Non si tratta, quindi, di un canonico dual-boot per far partire due differenti sistemi operativi : parte sempre Windows Server 2008, ma con l’Hypervisor attivo oppure disattivo.
      Come si implementa il dual boot? Con la seguente sequenza di comandi dal Command Prompt :

      BCDEDIT /copy {current} /d “Boot senza Hyper-V”
      Questo comando copia il profilo di boot corrente (cioè quello in cui l’Hypervisor è attivo), e ne crea un altro di nome “Boot senza Hyper-V”, associando a quest’ultimo un GUID di riconoscimento (per esempio un GUID simile a questo  {838c30bb-fea4-11de-a8a7-e62ffbd6d081}).
      Per visualizzare il GUID assegnato al nuovo profilo di boot, è sufficiente digitare
      BCDEDIT /enum

      BCDEDIT /set {GUID del nuovo profilo ricavato col precedente comando}  hypervisorlaunchtype off
      Questo comando imposta il nuovo profilo di boot a mantenere arrestato l’Hypervisor in fase di startup.  Così facendo, è possibile lanciare macchine virtuali Virtual Server/Virtual PC con performance ottimali.

      Da notare che, anche se si lancia l’host fisico con il profilo di boot senza Hypervisor, nella console dei servizi (Services.msc) i tre servizi utilizzati da Hyper-V appaiono “Avviati”.
      I tre servizi sono :

      • Hyper-V Image Management Service
      • Hyper-V Networking Management Service
      • Hyper-V Virtual Machine Management

      Questa situazione è regolare:  lo switch “hypervisorlaunchtype off” non arresta i servizi di gestione, ma proprio l’intero Hypervisor, sottile strato di software che si interpone tra l’hardware e il sistema operativo Host, componente essenziale dell’architettura di Hyper-V.

      • Share/Bookmark

      Pubblicato in Hyper-V, Virtualizzazione | Nessun commento »

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