Clonazione delle macchine virtuali tramite l'isolamento rete

La gestione dei lab virtuali è un settore emergente nell'ambito dei cicli di vita di sviluppo del software. Visual Studio Lab Management è un prodotto di Visual Studio che mette la tecnologia di gestione dei lab virtuali a disposizione di sviluppatori e tester. Con Visual Studio Lab Management, i team di sviluppo possono sfruttare la tecnologia di virtualizzazione nei propri lab di sviluppo e test per comporre ambienti multilivello complessi da macchine virtuali. Possono quindi distribuire build di applicazioni ed eseguire test in questi ambienti.

Uno dei motivi per cui è utile usare la virtualizzazione nei laboratori di sviluppo e test è il fatto che consente di creare copie identiche, o cloni, delle macchine virtuali distribuite, semplicemente copiando alcuni file. La clonazione è utile in molti scenari. Ad esempio, uno sviluppatore che ha bisogno di una copia dell'ambiente di un tester per riprodurre un problema può crearne un clone. In un team di test, ogni singolo tester può clonare una copia di un ambiente di lavoro e coordinare le proprie attività di test con il resto del gruppo. La clonazione fa risparmiare tempo sia agli sviluppatori che ai tester, perché non sarà più necessario installare più volte sistemi operativi e altri software in ogni ambiente creato.

Requisiti

• Visual Studio Ultimate, Visual Studio Premium, Visual Studio Test Professional

Anche se clonare un ambiente virtuale è semplice, è necessario tenere in considerazione alcune conseguenze della clonazione. I computer di un ambiente clonato hanno lo stesso nome computer di quelli nell'ambiente originale. In alcuni casi, possono anche avere lo stesso indirizzo IP e MAC. Questo può provocare la perdita di connettività di rete da parte di un clone, oppure il traffico di rete indirizzato a un clone potrebbe essere recapitato a un altro. Infine, come conseguenza imprevista, può accadere di distribuire un'applicazione in un particolare clone e condurre i test su un altro.

Nota

La funzionalità di isolamento rete può essere usata solo negli ambienti SCVMM.Non è disponibile per gli ambienti standard.

Visual Studio Lab Management risolve questi problemi e agevola la clonazione sicura di ambienti virtuali mediante una tecnologia denominata isolamento rete. Questo argomento illustra il funzionamento dell'isolamento rete e confronta la clonazione con e senza isolamento rete. Il primo esempio descrive le varie forme di conflitti che possono verificarsi tra i cloni in assenza di isolamento rete. Negli esempi successivi vengono esaminate diverse soluzioni per evitare i conflitti usando Visual Studio Lab Management.

Conflitti di rete

La Figura 1 mostra un tipico ambiente virtuale creato con Lab Management. Questo ambiente, denominato ambiente originale, contiene due macchine virtuali: server Web server db. Questi computer svolgono rispettivamente il ruolo di server Web e server di database in un'applicazione Web a 3 livelli. Nell'esempio si suppone che un membro del team di sviluppo abbia creato l'ambiente e vi abbia implementato l'ultima build della propria applicazione Web. Si suppone inoltre che, dopo la distribuzione, sia stato creato uno snapshot dell'ambiente denominato "ultima build". Uno snapshot è un'istantanea dello stato dell'ambiente in uno specifico punto nel tempo. È possibile ripristinare e riprendere l'esecuzione da questo stato salvato in qualsiasi momento. La figura mostra i nomi computer, gli indirizzi IP e gli indirizzi MAC delle due macchine virtuali nell'ambiente originale.

Ambiente originale

La Figura 2 mostra, oltre all'ambiente originale, anche un ambiente clonato. Dopo la clonazione, quando entrambi gli ambienti vengono avviati, possono verificarsi i tipi di conflitti di rete illustrati di seguito:

1. Conflitti tra nomi computer

2. Conflitti tra indirizzi IP

3. Conflitti tra indirizzi MAC

Ambiente originale e clonato in una rete comune

L'esatto risultato di ognuno di questi conflitti dipende da numerosi fattori: il sistema operativo per le macchine virtuali, l'infrastruttura di rete del lab e così via. Nella Figura 2 si presuppone che in ogni macchina virtuale dell'ambiente originale siano stati configurati un indirizzo IP statico e un indirizzo MAC statico. Dopo la clonazione, pertanto, le macchine virtuali clonate avranno gli stessi indirizzi IP e MAC.

Conflitti tra nomi computer

Un nome computer è un nome descrittivo assegnato da un utente per identificare un computer in una rete. Per risolvere un nome computer nell'indirizzo IP corrispondente vengono in genere usati due protocolli, NetBIOS e DNS (Domain Name Server). Quando nello stesso segmento di rete vengono avviati due computer con lo stesso nome, NetBIOS rileva il conflitto di nome e avvisa l'utente. In genere, NetBIOS può rilevare i conflitti solo se i computer si trovano nello stesso segmento di rete. In caso contrario o se gli avvisi vengono ignorati, il livello di conflitto successivo avviene si verifica nel DNS. Il DNS è un repository centrale per la registrazione dei nomi computer. Quando due computer con lo stesso nome provano a registrarsi nel DNS, il secondo computer potrebbe sostituire la voce creata dal primo. In questo caso, il primo computer che viene avviato non è raggiungibile tramite la risoluzione dei nomi

Evitare o risolvere i conflitti tra nomi di computer è semplice. Anziché creare copie identiche degli ambienti, è possibile personalizzare ogni clone al momento della creazione usando un meccanismo denominato sysprep. Sysprep è parte dei sistemi operativi Windows. Quando si usa sysprep per clonare gli ambienti, ogni macchina virtuale dell'ambiente riceve un nome computer, un indirizzo IP e un indirizzo MAC univoco, diversi da quelli dell'ambiente originale. I cloni, tuttavia, non sono più identici.

L'impatto dell'assegnazione di un nome computer univoco a ogni clone, che l'operazione venga eseguita tramite sysprep o manualmente per evitare conflitti, dipende dal software installato nella macchina virtuale. Per comprendere questa situazione, guardare l'esempio. Quando l'applicazione viene distribuita nell'ambiente, nel server Web viene creato un file web.config. In questo file è stato configurato il nome computer db-server come parte della stringa di connessione. Di seguito è visualizzato un frammento del file:

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server"/>
  </appSettings>
</configuration>

Quando si modifica il nome computer del server di database nell'ambiente clonato, per usare il nuovo nome è necessario anche modificare manualmente il file web.config come segue (db-server2 è il nuovo nome computer assegnato alla macchina virtuale nell'ambiente clonato).

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server2"/>
  </appSettings>
</configuration>

Quando si modifica il nome computer, inoltre, SQL Server richiede alcuni passaggi aggiuntivi. Di seguito è visualizzato un frammento degli script SQL necessari a questo scopo:

sp_dropserver db-server
sp_addserver db-server2, local
GO

L'esempio precedente mostra in che modo è necessario riconfigurare un'applicazione se i nomi computer vengono modificati. Naturalmente, questa procedura varia in base all'applicazione. Se un'applicazione inserisce il nome computer nelle voci di un database, le voci devono essere modificate in modo analogo. In alcuni casi, quando il nome computer cambia può essere necessario reinstallare l'applicazione. Eseguire queste operazioni di riconfigurazione e reinstallazione è chiaramente ciò che si voleva in primo luogo evitare attraverso l'uso della clonazione. Per questo è necessaria una soluzione più affidabile e indipendente dall'applicazione, che consenta a più cloni di coesistere senza conflitti tra i nomi computer.

Conflitti tra indirizzi IP

Per comunicare tra loro in una rete TCP, i computer usano un indirizzo IP (Internet Protocol). Gli indirizzi IP vengono assegnati in modo statico o dinamico da un server DHCP in rete. Ogni interfaccia di rete connessa presente in un computer dispone di un indirizzo IP. Se una macchina virtuale configurata con un indirizzo IP statico viene clonata e quindi posta nella stessa rete della macchina virtuale originale, oltre a un conflitto tra i nomi computer si verifica anche un conflitto di indirizzi IP. Si può correggere manualmente questo conflitto modificando l'indirizzo IP di uno dei cloni. Anche in questo caso, l'impatto della modifica dell'indirizzo IP dipende dal modo in cui l'indirizzo IP statico viene usato dalle applicazioni installate nelle macchine virtuali.

Quando si avvia la clonazione di una macchina virtuale configurata con un indirizzo IP dinamico, per un breve periodo di tempo si verifica un conflitto di rete. Subito dopo la clonazione della prima macchina virtuale, la seconda macchina virtuale tenta la connessione alla rete, rileva il conflitto e corregge il problema rinnovando il proprio indirizzo IP. Un breve periodo di conflitto si verifica anche ogni volta che l'ambiente duplicato viene ripristinato in base a uno snapshot dell'ambiente originale. Questi periodi di conflitto non durano in genere abbastanza a lungo da compromettere l'applicazione.

Conflitti tra indirizzi MAC

Un indirizzo MAC (Media Access Control) è un indirizzo che viene assegnato a ogni interfaccia di rete presente in un computer. Nel caso dei computer fisici, viene assegnato a ogni interfaccia di rete dal produttore della scheda. Nel caso delle macchine virtuali, esistono due modi per assegnare gli indirizzi MAC: MAC statico o dinamico. Si può specificare un particolare indirizzo MAC da usare per un'interfaccia di rete di una macchina virtuale. Questo è il cosiddetto MAC statico. In alternativa, si può consentire all'hypervisor di assegnare un indirizzo MAC in modo dinamico. Questo è il cosiddetto MAC dinamico. Gli indirizzi MAC dinamici vengono assegnati da Hyper-V da un pool di indirizzi MAC ogni volta che viene avviata una macchina virtuale. Ogni host dispone di uno schema che consente di generare gli indirizzi MAC in modo che non entrino in conflitto con quelli delle macchine virtuali di un altro host.

Se le macchine virtuali dell'ambiente originale usano indirizzi MAC statici, le macchine virtuali dell'ambiente clonato avranno gli stessi indirizzi MAC. Questo provoca immediatamente conflitti MAC. Gli indirizzi MAC duplicati sono più difficili da rilevare, perché non sempre vengono segnalati dai computer. Anche quando vengono segnalati, questi messaggi vengono registrati nel Visualizzatore eventi di Windows. Per un utente finale, le possibili conseguenze della presenza di indirizzi MAC duplicati sono due. La prima è la perdita di connettività di rete di uno o entrambi i cloni. La seconda è che i pacchetti di rete indirizzati a un computer potrebbero essere recapitati all'altro. Quando un computer originale e il suo clone hanno gli stessi indirizzi MAC, anche gli indirizzi IP sono gli stessi. Anche se per ottenere gli indirizzi IP dinamici si usa DHCP, il server DHCP assegnerà ai computer gli stessi indirizzi IP, perché gli indirizzi MAC sono identici.

In una certa misura, è possibile evitare i conflitti MAC usando indirizzi MAC dinamici. Tuttavia, quando l'ambiente clonato viene ripristinato in base a uno snapshot dell'ambiente originale, viene ripristinato l'intero stato delle macchine virtuali, inclusi gli indirizzi MAC. Questo provoca di nuovo conflitti MAC e gli stessi problemi descritti in precedenza persistono finché la macchina virtuale clonata non viene riavviata. Al riavvio dell'ambiente clonato, l'hypervisor rilascia e rinnova gli indirizzi MAC con i valori dell'intervallo definito.

Rilevare e risolvere i tipi di conflitti appena descritti e quindi correggere manualmente l'applicazione o il sistema operativo per continuare a lavorare dopo la risoluzione, è un'operazione complessa per chi usa di frequente la gestione dei lab virtuali, richiede molto tempo ed è soggetta a errori. In molti casi, modificare uno di questi parametri modifica l'ambiente virtuale quanto basta per causare la perdita della riproduzione di un bug o un problema analogo nell'ambiente di produzione. Il principio di installare l'applicazione una sola volta in un ambiente virtuale e clonare senza problemi tale ambiente per creare più copie identiche è un approccio talmente sofisticato che non è pensabile che gli utenti comuni possano essere capaci di gestirlo.

Isolamento rete

Finora sono stati identificati due requisiti. Il primo è che le macchine virtuali in un ambiente duplicato devono avere gli stessi nomi computer, indirizzi IP e indirizzi MAC dei computer presenti nell'ambiente originale. Allo stesso tempo, tuttavia, deve essere possibile raggiungere indipendentemente i cloni dall'esterno dell'ambiente. Questo è necessario, ad esempio, perché un utente possa connettersi a ogni singolo clone dal desktop, per distribuire un'applicazione in uno specifico clone o per eseguire un test su uno specifico clone. Questo porta al secondo requisito, ovvero che le macchine virtuali all'interno di un ambiente clonato devono anche avere nomi computer, indirizzi IP e indirizzi MAC diversi rispetto ai computer presenti nell'ambiente originale. La soluzione più logica per soddisfare entrambi i requisiti è fare in modo che ogni macchina virtuale disponga di due interfacce: un'interfaccia privata per cui il nome computer, l'indirizzo IP e l'indirizzo MAC sono gli stessi in ogni clone e un'interfaccia pubblica per cui questi valori sono univoci in ogni clone.

Per impedire conflitti di rete per le interfacce private, è necessario che siano connesse a una rete privata in ogni clone. Una rete privata è una rete virtuale limitata alle sole macchine virtuali presenti all'interno di un ambiente. Poiché questa rete non è esposta oltre i confini di un ambiente, non esiste possibilità di conflitti anche se gli stessi nomi computer, indirizzi IP e indirizzi MAC sono usati in un altro clone. Per l'accessibilità dall'esterno dell'ambiente, tutte le interfacce pubbliche devono essere connesse a una rete pubblica comune. La rete pubblica o rete del lab è la rete in cui le macchine virtuali degli ambienti possono interagire con i client e con altri computer nel lab.

La Figura 3 illustra in che modo le interfacce pubbliche e private risolvono i conflitti di rete.

Isolamento rete in Visual Studio Lab Management

Visual Studio Lab Management implementa l'isolamento rete per gli ambienti SCVMM introducendo due interfacce di rete di ogni macchina virtuale. Una di queste interfacce di rete è un'interfaccia privata connessa a una rete privata, l'altra è un'interfaccia pubblica connessa alla rete pubblica.

Il software Lab Management, insieme a un agente installato in ogni macchina virtuale, assicura che l'ambiente originario e quello clonato possano coesistere senza conflitti.

Interfacce private in una rete privata

La descrizione che segue è un riepilogo delle modalità di assegnazione di nomi computer, indirizzi IP e indirizzi MAC alle interfacce private di un ambiente.

Nomi computer: i nomi di computer nella rete privata vengono risolti con NetBIOS e non richiedono gestione aggiuntiva da parte del software Lab Management. Le applicazioni configurate per l'uso di nomi computer NetBIOS funzioneranno come previsto in ogni clone. Nell'esempio, il computer server Web fa riferimento al computer server db usando il suo nome. I nomi sono gli stessi nell'ambiente originale e in quello clonato. Di conseguenza, non è necessario modificare il file web.config nell'ambiente clonato.

Poiché nella rete privata non è presente un server DNS, è necessario risolvere il caso in cui le macchine virtuali fanno riferimento l'una all'altra usando nomi di dominio completi (FQDN) anziché nomi NetBIOS. Ad esempio, se il file web.config facesse riferimento al server di database come server-db.lab.contoso.com, la risoluzione del nome in un indirizzo IP non sarebbe possibile senza DNS nella rete privata. Per risolvere il problema, l'agente lab nella macchina virtuale aggiunge nel file degli host voci corrispondenti alle altre macchine virtuali dello stesso ambiente. Il file degli host è un altro mezzo per indicare al sistema operativo che un nome deve essere risolto in uno specifico indirizzo IP. Nell'esempio, il file degli host nel server Web conterrà la voce seguente:

192.168.23.2 db-server.lab.contoso.com

Indirizzi IP: all'interfaccia di rete privata di ogni macchina virtuale viene assegnato un indirizzo IP statico nell'intervallo 192.168.23.1 - 255. Ad esempio, l'interfaccia privata del server Web ottiene 192.168.23.1 e l'interfaccia privata del server db ottiene 192.168.23.2. Lab Management garantisce che server Web e server db ottengano gli stessi indirizzi IP statici in ogni clone. Pertanto, anche se il file web.config nel server Web è configurato con l'indirizzo IP del server di database, non è necessario riconfigurarlo nell'ambiente clonato. In qualsiasi ambiente configurato con isolamento rete, le interfacce private ottengono indirizzi IP da questo stesso intervallo, a partire da 192.168.23.1. Il massimo numero di indirizzi necessari in questo intervallo è uguale al numero massimo di macchine virtuali in un ambiente. Poiché questo set di indirizzi IP non è instradabile dall'esterno della rete, è possibile usare in sicurezza un intervallo predefinito, purché lo stesso intervallo non sia usato nella rete pubblica.

Indirizzi MAC: in un ambiente con isolamento rete, all'interfaccia di rete privata di ogni macchina virtuale viene assegnato un indirizzo MAC statico casuale. Nell'esempio, all'interfaccia privata nel server Web originale è assegnato un indirizzo MAC come 00-15-5D-07-57-01. Lab Management assicura che questo server Web ottenga lo stesso indirizzo MAC anche nell'ambiente clonato. Poiché questo set di indirizzi MAC non è instradabile dall'esterno della rete, è possibile usare in sicurezza un indirizzo casuale, purché non sia compreso nell'intervallo degli indirizzi usati dall'hypervisor in quell'host.

Interfacce pubbliche in una rete pubblica

La descrizione che segue è un riepilogo delle modalità di assegnazione di nomi computer, indirizzi IP e indirizzi MAC alle interfacce pubbliche di un ambiente.

Nomi computer: non è desiderabile che NetBIOS risolva i nomi computer nella rete pubblica, perché questa operazione provocherebbe un conflitto tra nomi computer. Per evitare questo problema, Lab Management disabilita le trasmissioni NetBIOS sull'interfaccia pubblica di ogni macchina virtuale. Analogamente, non è desiderabile che le macchine virtuali registrino i propri nomi computer NetBIOS in DNS. Lab Management disabilita anche la registrazione DNS per ogni interfaccia pubblica. In mancanza di registrazione NetBIOS e DNS predefinita, si vuole comunque che le macchine virtuali dispongano di nomi univoci che possano essere usati in una rete pubblica. Lab Management genera un nome di alias univoco per conto di ogni macchina virtuale e lo registra come record "A" in DNS. Nell'esempio, il server Web nell'ambiente originale potrebbe essere registrato usando un nome di alias univoco simile a VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com. Nell'ambiente clonato lo stesso server Web verrebbe registrato con un nome diverso, simile a VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com.

Indirizzi IP: l'interfaccia di rete pubblica in ogni macchina virtuale è configurata in modo da ottenere un indirizzo IP dinamico da un server DHCP. Questo garantisce che le macchine virtuali negli ambienti originale e clonato dispongano di indirizzi IP univoci. Ad esempio, il server Web nell'ambiente originale potrebbe ottenere l'indirizzo IP 172.52.20.140 e lo stesso server Web nell'ambiente clonato potrebbe ottenere l'indirizzo 172.52.20.205.

Indirizzi MAC: per evitare conflitti MAC, è possibile configurare l'interfaccia di rete pubblica di ogni macchina virtuale in modo da ottenere un indirizzo MAC dinamico dall'hypervisor. In questo modo si garantisce che il computer server Web dell'esempio ottenga un indirizzo MAC diverso nell'ambiente originale e negli ambienti clonati. Come descritto in precedenza, tuttavia, quando un ambiente clonato viene ripristinato in base a uno snapshot dell'ambiente originale, gli indirizzi MAC e IP della macchina virtuale clonata assumono gli stessi valori dell'originale. Ad esempio, quando l'ambiente clonato viene ripristinato allo snapnshot dell'ultima build, l'indirizzo IP del server Web diventa 10.86.51.61 (vedere la Figura 3), che è lo stesso valore dell'ambiente originale. Lo stesso accade per l'indirizzo MAC. Mentre il conflitto di indirizzi IP è temporaneo e persiste solo fino al rinnovo da parte di DHCP, il conflitto MAC persiste finché le macchine virtuali non vengono riavviate. A causa di questa limitazione, l'uso di indirizzi MAC assegnati in modo dinamico dall'hypervisor per le interfacce pubbliche non rappresenta una soluzione valida.

Per risolvere questo problema, Lab Management usa uno specifico pool di indirizzi MAC. Alle interfacce pubbliche delle macchine virtuali vengono assegnati indirizzi MAC univoci compresi in questo pool. Ogni volta che l'ambiente clonato viene ripristinato in base a uno snapshot, Lab Management modifica automaticamente gli indirizzi MAC per evitare conflitti. Nell'esempio, l'indirizzo MAC del server Web è 1D-D8-B7-1C-00-05 nell'ambiente originale e 1D-D8-B7-1C-00-07 nell'ambiente clonato. Quando l'ambiente clonato viene ripristinato in base a uno snapshot dell'ambiente originale, l'indirizzo MAC del server Web diventa momentaneamente 1D-D8-B7-1C-00-05. Lab Management lo modificherà nuovamente in 1D-D8-B7-1C-00-07 per evitare conflitti di rete.

Interazioni tipiche con isolamento rete

Questa sezione illustra cosa accade quando due macchine virtuali all'interno dell'ambiente comunicano tra loro:

1. Il server Web usa NetBIOS o il file degli host per risolvere il nome computer "db-server" nell'indirizzo IP dell'interfaccia privata di db-server (192.168.23.2).

2. Il server Web comunica con db-server a questo indirizzo IP.

Quando un client esterno all'ambiente deve comunicare con il server Web in un ambiente clonato, viene seguita la procedura seguente:

1. Il client esegue una query nel software Lab Management per ottenere il nome di alias univoco del server Web nell'ambiente clonato.

2. Il software Lab Management risponde con il nome di alias univoco.

3. Il server DNS risolve il nome di alias univoco nell'indirizzo IP dell'interfaccia pubblica del server Web (10.86.51.63).

4. Il client comunica con il server Web a questo indirizzo IP.

Approcci alternativi all'isolamento rete

L'uso di due interfacce non è l'unico approccio possibile per implementare l'isolamento rete. Un approccio molto simile consiste nell'usare un NAT bidirezionale. Il NAT rappresenta un metodo comune per creare una rete privata di dispositivi che devono comunicare con dispositivi in una rete pubblica. Mentre in un NAT tipico la comunicazione deve sempre avere origine dalla rete privata, il NAT bidirezionale (o NAT a due vie) consente l'avvio della comunicazione sia dai computer nella rete privata che da quelli nella rete pubblica.

Per implementare l'isolamento rete usando questo approccio è necessario introdurre nell'ambiente un server NAT bidirezionale. A questo scopo, in genere si aggiunge all'ambiente una speciale macchina virtuale che svolge la funzione di server NAT bidirezionale. Quando si crea un ambiente con isolamento rete, gli indirizzi IP pubblici e privati delle macchine virtuali vengono assegnati come avviene per l'approccio a due interfacce. Tuttavia, anziché assegnare l'indirizzo IP pubblico a un'interfaccia di rete nella macchina virtuale, i mapping vengono archiviati in una tabella NAT nel server NAT bidirezionale.

I passaggi eseguiti per avviare la comunicazione tra due macchine virtuali all'interno dell'ambiente quando si adotta l'approccio NAT bidirezionale sono identici a quelli eseguiti nell'approccio a due interfacce:

1. Il server Web usa NetBIOS o il file degli host per risolvere il nome computer db-server nell'indirizzo IP dell'interfaccia privata di db-server (192.168.23.2).

2. Il server Web comunica con db-server a questo indirizzo IP.

I passaggi eseguiti quando un client esterno all'ambiente deve comunicare con il server Web in un ambiente clonato sono leggermente diversi e sono i seguenti:

1. Implementando l'approccio NAT, il client esegue una query nel software Lab Management per ottenere il nome di alias univoco del server Web nell'ambiente clonato. (Visual Studio Lab Management non implementa l'approccio NAT).

2. Il software Lab Management risponde con il nome di alias univoco.

3. Il server DNS risolve il nome di alias univoco nell'indirizzo IP pubblico del server Web (10.86.51.63).

4. Questo indirizzo IP è in realtà mappato a un'interfaccia nel server NAT bidirezionale, quindi il client comunica in effetti con il server NAT bidirezionale e non con il server Web.

5. Il server NAT recupera i mapping archiviati nelle tabelle di configurazione e converte l'indirizzo IP pubblico (10.86.51.63) in un indirizzo IP privato (192.168.23.1).

6. Il server NAT inoltra il messaggio dal client sulla rete privata a 192.168.23.1, ovvero l'indirizzo IP del server Web.

Il vantaggio di questo approccio rispetto all'approccio a due interfacce è che non è necessario modificare le macchine virtuali nell'ambiente in alcun modo. Non è necessario introdurre un'interfaccia di rete aggiuntiva in ogni macchina virtuale. Introdurre un'interfaccia di rete aggiuntiva in una macchina virtuale può provocare l'interruzione di alcune applicazioni.

Un altro vantaggio di questo approccio è che l'intera logica per l'implementazione dell'isolamento rete è incapsulata nella macchina virtuale supplementare e dunque non è necessario disporre di un agente in ognuna delle altre macchine virtuali. Eseguire il routing di tutti i pacchetti attraverso la macchina virtuale supplementare fornisce un ulteriore punto di controllo per il supporto delle funzionalità di isolamento rete più avanzate, ad esempio:

• Isolamento solo in entrata: non consente ai pacchetti di rete avviati da client esterni all'ambiente di raggiungere le macchine virtuali nell'ambiente.

• Solo in entrata con eccezioni per porte specifiche: non consente ai pacchetti di rete avviati da client esterni all'ambiente di raggiungere le macchine virtuali nell'ambiente, a meno che non vengano indirizzati a una porta specifica.

Queste funzionalità possono essere facilmente implementate nell'approccio NAT bidirezionale introducendo un firewall nel server NAT. Lo svantaggio principale dell'approccio NAT bidirezionale è che alcune applicazioni non funzionano tramite NAT. Ad esempio, i protocolli di comunicazione remota .NET e DCOM comunemente usati nelle applicazioni Windows non funzionano quando il client e il server sono separati da un server NAT. Questo è il motivo per cui Visual Studio Lab Management usa l'approccio a due interfacce. Un altro svantaggio dell'approccio NAT bidirezionale è che richiede la presenza di una macchina virtuale supplementare in ogni ambiente, generando un sovraccarico aggiuntivo durante la creazione o altre operazioni sugli ambienti virtuali.

Altri conflitti

Finora è stato descritto in che modo risolvere i conflitti tra nomi computer, indirizzi MAC e IP mediante l'isolamento rete. Quando gli ambienti vengono clonati, possono però verificarsi anche altri tipi di conflitti. Ogni volta che esiste una dipendenza da un componente esterno all'ambiente virtuale, nel momento in cui si clona l'ambiente può verificarsi un conflitto. In questa sezione vengono esaminati due casi comuni in cui possono verificarsi conflitti di questo tipo.

Conflitti di Active Directory

In genere i computer e le applicazioni Windows usano Active Directory (AD) per i servizi directory o per l'autenticazione e l'autorizzazione degli utenti. Gestire i computer Windows a livello centrale mediante criteri di gruppo di Active Directory è una prassi molto diffusa. Usando l'esempio, si supponga che il server Web e il server di database nell'ambiente originale appartengano a un dominio gestito da Active Directory. La directory è ospitata all'esterno dell'ambiente. Clonando l'ambiente si ottengono due cloni identici del server Web, ma in Active Directory è presente una sola voce. Questo ovviamente è un risultato indesiderato, che può provocare diversi problemi. Ad esempio, se un utente rimuove uno dei cloni del server Web dal dominio, verrà rimosso anche l'altro clone. Le modifiche apportate in un ambiente incidono involontariamente anche sull'altro ambiente.

Per evitare conflitti di Active Directory, è necessario che un server AD sia ospitato all'interno di una macchina virtuale dell'ambiente. Non devono esistere relazioni di trust tra il server AD e altre directory esterne all'ambiente.

Per la configurazione di Active Directory in un ambiente con isolamento rete sono necessarie alcune considerazioni aggiuntive. Prima di tutto, la macchina virtuale con Active Directory non deve essere connessa alla rete pubblica. Nell'approccio a due interfacce, questo vuol dire che la macchina virtuale con Active Directory non deve disporre di un'interfaccia pubblica. Nell'approccio NAT bidirezionale, vuol dire che la tabella NAT non deve disporre di un mapping per la macchina virtuale con Active Directory.

In secondo luogo, poiché Active Directory è una foresta indipendente, nell'ambiente deve essere presente un server DNS. Per la comunicazione corretta con Active Directory, le altre macchine virtuali all'interno dell'ambiente devono usare questo server DNS nella rete privata. Ad esempio, se le impostazioni del server DNS non sono configurate correttamente nell'interfaccia privata, per una macchina virtuale potrebbe non essere possibile unirsi al dominio Active Directory privato.

Quando si configura un ambiente per includere una macchina virtuale con Active Directory, Visual Studio Lab Management automatizza la disconnessione di Active Directory dalla rete pubblica e la configurazione delle interfacce private delle macchine virtuali con le impostazioni DNS.

In alcuni casi non è possibile ospitare Active Directory nell'ambiente. Questo può accadere ad esempio se l'applicazione in fase di sviluppo deve usare un'istanza di Active Directory aziendale per l'integrazione con altre applicazioni aziendali esistenti. Non esiste una soluzione nota per abilitare la clonazione sicura degli ambienti quando i computer sono connessi a un dominio esterno all'ambiente.

Conflitti di database

Un altro uso comune degli ambienti virtuali prevede l'hosting del database dell'applicazione all'esterno dell'ambiente. In genere questo approccio viene adottato quando il database è di dimensioni importanti, quando non è pratico clonarlo con ogni ambiente o se l'applicazione in fase di sviluppo è un semplice client Web che interagisce con un database ospitato altrove. In questi casi, quando due cloni identici interagiscono con il database, il server di database non è in grado di distinguere l'identità dei due client.

Riepilogo

La capacità di creare cloni identici di ambienti virtuali è essenziale per diversi scenari di gestione dei lab virtuali. Quando vengono creati cloni identici, tuttavia, si verificano conflitti tra nomi computer, indirizzi IP e indirizzi MAC. Tecniche molto semplici, come modificare i nomi computer o gli indirizzi IP per risolvere tali conflitti in genere richiedono la riconfigurazione o la reinstallazione dell'applicazione ed evitano efficacemente la creazione di cloni identici. L'isolamento rete risolve il problema consentendo di creare ed eseguire contemporaneamente due cloni.

Passaggi successivi

Pianificare l'ambiente SCVMM: è importante apprendere quando usare le diverse opzioni per gli ambienti SCVMM, ad esempio usare macchine virtuali in esecuzione, macchine virtuali archiviate, modelli, ambienti archiviati e isolamento rete. Vedere Linee guida per la creazione e la gestione di ambienti SCVMM.

Creare un ambiente con isolamento rete: passare a questo argomento se si è pronti a creare un ambiente con isolamento rete. Vedere Creazione e utilizzo di un ambiente di isolamento rete.

Vedere anche

Concetti

Automatizzare i test di sistema