Clonando máquinas virtuais por meio do isolamento da rede

 

Publicado: abril de 2016

Gerenciamento de laboratório virtual é uma área emergente em ciclos de vida de desenvolvimento de software. Visual Studio Lab Management é um produto no Visual Studio que leva o gerenciamento de laboratório virtual para desenvolvedores e testadores. Usando o Visual Studio Lab Management, as equipes de desenvolvimento podem aproveitar a tecnologia de virtualização nos laboratórios de desenvolvimento e teste para compor ambientes de várias camadas complexos com base em máquinas virtuais. Em seguida, elas podem implantar compilações de aplicativo e executar testes nesses ambientes.

Uma das motivações para usar a virtualização em laboratórios de desenvolvimento e teste é que é possível criar cópias idênticas, ou clones, de máquinas virtuais implantadas copiando-se apenas alguns arquivos. A clonagem é útil em muitos cenários. Por exemplo, um desenvolvedor que precise de uma cópia de um ambiente do testador para reproduzir um problema pode criar um clone desse ambiente. Em uma equipe de teste, cada testador individual pode criar uma cópia de um ambiente e coordenar seus esforços de teste com o restante da equipe. A clonagem economiza tempo de desenvolvedores e testadores porque não eles não precisam instalar repetidamente os sistemas operacionais e o outro software em cada ambiente criado.

Requisitos

• O Visual Studio Enterprise, Visual Studio Test Professional

Ainda que seja fácil clonar um ambiente virtual, existem consequências da clonagem que você precisa considerar. Computadores em um ambiente clonado têm os mesmos nomes de computador que os computadores no ambiente original. Em alguns casos, eles poderiam ter os mesmos endereços IP e MAC. Isso poderia resultar na perda de conectividade de rede de um dos clones, ou no alcance do tráfego de rede destinado a um clone a outro lugar. Uma consequência indesejada poderia ser a implantação de um aplicativo em um determinado clone e a realização de testes em outro clone.

Dica

Só é possível usar o isolamento de rede com ambientes SCVMM.Esse recurso não está disponível para ambientes padrão.

O Visual Studio Lab Management resolve esses problemas e facilita a clonagem segura de ambientes virtuais por meio de uma tecnologia chamada isolamento da rede. Este tópico discute como funciona o isolamento de rede e compara a clonagem com e sem o isolamento de rede. O primeiro exemplo descreve as diversas formas de conflitos que podem ocorrer entre clones na ausência do isolamento de rede. Os exemplos subsequentes examinam várias soluções para evitar conflitos usando o Visual Studio Lab Management.

Conflitos de rede

A Figura 1 mostra um ambiente virtual típico que você poderia criar usando o Lab Management. Esse ambiente, chamado de ambiente original, tem duas máquinas virtuais: web-server e db-server. Esses computadores oferecem a função de servidores Web e de banco de dados respectivamente em um aplicativo Web de três camadas. Neste exemplo, pressupomos que um membro de uma equipe de desenvolvimento criou esse ambiente e implantou a compilação mais recente do aplicativo Web. Também pressupomos que um instantâneo chamado compilação mais recente tenha sido feito nesse ambiente após a implantação da compilação. Um instantâneo é um ponto em estado de tempo do ambiente. É possível restaurar e retomar a execução desse estado salvo a qualquer momento. A figura mostra os nomes de computador, os endereços IP e os endereços MAC das duas máquinas virtuais no ambiente original.

Ambiente original

A Figura 2 mostra um ambiente clonado além do original. Após a clonagem, quando ambos os ambientes forem iniciados, os seguintes tipos de conflitos de rede poderão ocorrer:

1. Conflitos de nome de computador

2. Conflitos de endereço IP

3. Conflitos de endereço MAC

Ambientes originais e clonados em uma rede comum

O resultado exato de cada um desses conflitos depende de vários fatores: o sistema operacional nas máquinas virtuais, a infraestrutura de rede no laboratório etc. Na Figura 2, pressupomos que um endereço IP estático e um endereço MAC estático foram configurados em cada máquina virtual do ambiente original. Por isso, quando o ambiente foi clonado, as máquinas virtuais clonadas tinham os mesmos endereços IP e MAC.

Conflitos de nome de computador

Um nome de computador é um nome amigável atribuído por um usuário para identificar um computador em uma rede. Dois protocolos costumam ser usados para resolver um nome de computador para o endereço IP: NetBIOS e DNS (servidor de nomes de domínio). Quando dois computadores com o mesmo nome de computador forem iniciados no mesmo segmento de rede, o NetBIOS detectará o conflito de nome e avisará o usuário. Normalmente, o NetBIOS só poderá detectar conflitos se os computadores estiverem no mesmo segmento de rede. Se os computadores não estiverem no mesmo segmento de rede ou se os avisos forem ignorados, o próximo nível de conflitos ocorrerá no DNS. DNS é um repositório central para que computadores registrem seus nomes. Quando dois computadores com o mesmo nome de computador tentarem se registrar no DNS, o segundo computador poderá substituir a entrada criada pelo primeiro computador. Nesse caso, o primeiro computador iniciado não é alcançável por meio da resolução de nomes.

Existem maneiras simples de evitar ou corrigir conflitos de nome de computador. Em vez de criar cópias idênticas de ambientes, é possível personalizar cada clone conforme você o cria usando um mecanismo chamado sysprep. Sysprep faz parte dos sistemas operacionais Windows. Quando você usa sysprep para clonar ambientes, cada máquina virtual do ambiente recebe um nome de computador exclusivo, um endereço IP e um endereço MAC diferentes daqueles do ambiente original. No entanto, os clone não são mais idênticos.

O impacto de ter um nome de computador exclusivo em cada clone, independentemente disso ser feito por meio de sysprep ou da intervenção manual do usuário para evitar conflitos, depende do software instalado na máquina virtual. Para compreender isso, observe o exemplo. Quando o aplicativo fosse implantado no ambiente, um arquivo web.config seria criado no servidor web. Nesse arquivo, configuramos o nome do computador db-server como parte da cadeia de conexão. Um trecho desse arquivo é mostrado aqui:

<?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>

Ao alterarmos o nome do computador do servidor de banco de dados no ambiente clonado, também precisamos alterar manualmente o arquivo web.config da forma a seguir para usar o novo nome (db-server2 é o novo nome do computador dado à máquina virtual no ambiente clonado).

<?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>

Além disso, o SQL Server exigirá etapas adicionais quando o nome do computador for alterado. Um trecho de scripts SQL para realizar isso é mostrado aqui:

sp_dropserver db-server
sp_addserver db-server2, local
GO

O exemplo anterior mostra como um aplicativo precisará ser reconfigurado se os nomes de computador forem alterados. Compreensivelmente, esse procedimento depende do aplicativo. Se um aplicativo gravar o nome do computador em entradas em um banco de dados, essas entradas precisarão ser alteradas de maneira semelhante. Em alguns casos, você talvez precise reinstalar um aplicativo quando o nome do computador é alterado. A realização dessas reconfigurações e reinstalações é claramente o que queremos evitar em primeiro lugar por meio do uso da clonagem. Isso necessita de uma solução independente do aplicativo mais robusta que possa permitir que vários clones coexistam com segurança sem conflitos de nome de computador.

Conflitos de endereço IP

Um endereço IP (Internet Protocol) é usado para computadores se comunicarem entre si em uma rede TCP. Os endereços IP são atribuídos estática ou dinamicamente por um servidor DHCP na rede. Cada interface de rede conectada em um computador tem um endereço IP. Se uma máquina virtual configurada com um endereço IP estático for clonada e colocada na mesma rede da máquina virtual original, haverá um conflito de endereço IP, além de um conflito de nome de computador. É possível corrigir manualmente esse conflito alterando-se o endereço IP de um dos clones. Mais uma vez, o impacto de alterar o endereço IP depende de como o endereço IP estático é usado pelos aplicativos instalados em máquinas virtuais.

Quando você começa a clonar uma máquina virtual configurada com um endereço IP dinâmico, há um conflito de rede por um curto período de tempo. Logo após a primeira máquina virtual ser clonada, a segunda máquina virtual a ser conectada à rede detectará esse conflito e se corrigirá renovando seu endereço IP. Um período curto de conflito semelhante acontece sempre que o ambiente clonado é restaurado para um instantâneo feito no ambiente original. Esses períodos de conflito não costumam ser longos o suficiente para afetar o aplicativo.

Conflitos de endereço MAC

Um MAC (controle de acesso à mídia) é um endereço atribuído a cada interface de rede em um computador. No caso de computadores físicos, ele é atribuído a cada interface de rede pelo fabricante do cartão. No caso de máquinas virtuais, existem duas formas de atribuir endereços MAC: MAC estático ou dinâmico. É possível especificar um endereço MAC específico a ser usado em uma interface de rede de uma máquina virtual. Ele é chamado de MAC estático. Ou é possível deixar o hipervisor atribuir dinamicamente um endereço MAC. Ele é chamado de MAC dinâmico. Os endereços MAC dinâmicos são atribuídos por Hyper-V com base em um pool de endereços MAC sempre que uma máquina virtual é iniciada. Cada host tem um esquema para gerar endereços MAC de maneira que eles não entrem em conflito com as máquinas virtuais em outro host.

Se os endereços MAC estáticos forem usados em máquinas virtuais no ambiente original, as máquinas virtuais no ambiente clonado terão os mesmos endereços MAC. Isso resulta prontamente em conflitos MAC. Os endereços MAC duplicados são mais difíceis de detectar porque nem sempre são relatados por computadores. Mesmo quando são relatados, essas mensagens são registradas em log no Visualizador de Eventos do Windows. Para um usuário final, há duas consequências possíveis de endereços MAC duplicados. Uma consequência é a perda de conectividade de rede em um ou em ambos os clones. Em vez disso, outra consequência é que os pacotes de rede destinados a um computador podem alcançar a outro computador. Quando um computador original e seu clone têm os mesmos endereços MAC, seus endereços IP também são iguais. Mesmo quando DHCP for usado para obter um endereço IP dinâmico, o servidor DHCP atribuirá os mesmos endereços IP porque seus endereços MAC são idênticos.

Até certo ponto, é possível evitar conflitos MAC usando-se endereços MAC dinâmicos. No entanto, quando o ambiente clonado é restaurado para um instantâneo feito no ambiente original, todo o estado desses computadores virtuais é revertido, incluindo os endereços MAC. Isso mais uma vez resulta em conflitos MAC, e os mesmos problemas descritos anteriormente permanecem até a máquina virtual clonada ser reiniciada. A reinicialização do ambiente clonado causa a liberação do hipervisor e renova os endereços MAC com valores de seu próprio intervalo.

A detecção e a resolução dos formulários de conflitos recém-descritos, além da correção manual do sistema operacional/aplicativo para continuar funcionando após a resolução, são significativas, demoradas e sujeitas a erros para usuários frequentes do gerenciamento de laboratório virtual. Em muitos casos, a alteração de qualquer um desses parâmetros altera o ambiente virtual o suficiente para causar a perda de uma reprodução de bug ou de um problema semelhante com o ambiente de produção. O princípio de instalação do aplicativo uma única vez em um ambiente virtual e de clonagem sem preocupação desse ambiente para criar várias cópias idênticas exige uma abordagem mais sofisticada do que os usuários comuns podem esperar.

Isolamento de rede

Dois requisitos foram identificados até o momento. O primeiro requisito é que as máquinas virtuais em um ambiente clonado devem ter os mesmos nomes de computador, endereços IP e endereços MAC dos presentes no ambiente original. Mas, ao mesmo tempo, esses clone precisam ser endereçáveis independentemente fora do ambiente. Isso é obrigatório, por exemplo, para que alguém se conecte a cada um dos clone com base em suas áreas de trabalho, para que um aplicativo seja implantado em um clone específico ou para que um teste seja executado em um clone específico. Isso leva ao segundo requisito, que é que as máquinas virtuais em um ambiente clonado também devem ter nomes de computador exclusivos, endereços IP e endereços MAC diferentes dos presentes no ambiente original. A maneira lógica de realizar ambos os requisitos é que cada máquina virtual tenha duas interfaces: uma interface privada para a qual o nome de computador, o endereço IP e o endereço MAC são iguais em todos os clones e uma interface pública para a qual esses valores são exclusivos em cada clone.

Para evitar conflitos de rede para as interfaces privadas, eles precisam estar conectados a uma rede privada em cada clone. Uma rede privada é uma rede virtual limitada apenas às máquinas virtuais dentro de um ambiente. Como essa rede não é exposta além dos limites de um ambiente, não há nenhuma possibilidade de conflitos, mesmo que os mesmos nomes de computador, endereços IP e endereços MAC sejam usados em outro clone. Tendo em vista a acessibilidade fora do ambiente, todas as interfaces públicas precisam estar conectadas a uma rede pública comum. A rede pública ou a rede do laboratório é a rede na qual as máquinas virtuais de ambientes podem interagir com clientes e os outros computadores em laboratório.

A Figura 3 mostra como interfaces privadas e públicas resolvem conflitos de rede.

Isolamento de rede no Visual Studio Lab Management

O Visual Studio Lab Management implementa o isolamento de rede para ambientes SCVMM apresentando duas interfaces de rede em cada máquina virtual. Uma dessas interfaces de rede é uma interface privada conectada a uma rede privada, e a outra é uma interface pública conectada à rede pública.

O software Lab Management, com um agente instalado em cada máquina virtual, garante que o ambiente original e o ambiente clonado possam coexistir sem conflitos.

Interfaces privadas na rede privada

A descrição a seguir é um resumo de como os nomes de computador, endereços IP e endereços MAC são atribuídos a interfaces privadas de um ambiente.

Nomes de computador: nomes de computador na rede privada são resolvidos por meio do NetBIOS e não exigem tratamento adicional pelo software Lab Management. Os aplicativos configurados para funcionar com nomes de computador NetBIOS funcionarão conforme esperado em cada clone. Em nosso exemplo, o computador web-server se refere ao computador db-server que usa seu nome. Esses nomes são iguais nos ambientes original e clonado. Por isso, o arquivo web.config não precisa ser alterado no ambiente clonado.

Como não há servidor DNS na rede privada, precisamos resolver a situação quando FQDNs (nomes de domínios totalmente qualificados) são usados por máquinas virtuais para fazer referência entre si, em vez de nomes NetBIOS. Por exemplo, se o arquivo web.config usasse como referência para db-server como db-server.lab.contoso.com, a resolução desse nome para um endereço IP não seria possível sem DNS na rede privada. Para resolver isso, o agente de laboratório em execução na máquina virtual adiciona entradas correspondentes às outras máquinas virtuais do mesmo ambiente no arquivo de hosts. O arquivo de hosts é outra maneira de indicar para o sistema operacional que um nome precisa ser resolvido para um endereço IP específico. Em nosso exemplo, o arquivo de hosts em web-server terá a seguinte entrada:

192.168.23.2 db-server.lab.contoso.com

Endereços IP: um intervalo de endereços IP estáticos 192.168.23.1 - 255 é atribuído à interface de rede privada de cada máquina virtual. Por exemplo, a interface privada de web-server recebe 192.168.23.1 e a interface privada de db-server recebe 192.168.23.2. O Lab Management garante que web-server e db-servers recebam os mesmos endereços IP estáticos em cada clone. Por isso, mesmo se o arquivo web.config no web-server estiver configurado com endereço IP de db-server, ele não precisará ser reconfigurado no ambiente clonado. Em qualquer ambiente configurado com o isolamento de rede, as interfaces privadas recebem endereços IP desse mesmo intervalo, começando com 192.168.23.1. O número máximo de endereços necessários nesse intervalo é igual ao número máximo de máquinas virtuais em um ambiente. Como esse conjunto de endereços IP não é roteável fora da rede privada, é seguro usar um intervalo predefinido desde que o mesmo intervalo não seja usado na rede pública.

Endereços MAC: um endereço MAC estático aleatório é atribuído à interface de rede privada de cada máquina virtual em um ambiente de rede isolado. Em nosso exemplo, a interface privada no web-server original recebe um endereço MAC como, por exemplo, 00-15-5D-07-57-01. O Lab Management garante que esse web-server receba o mesmo endereço MAC no ambiente clonado também. Como esse conjunto de endereços MAC não é roteável fora da rede privada, é seguro usar um endereço aleatório desde que eles não estejam dentro do intervalo do que o hipervisor usa nesse host.

Interfaces públicas na rede pública

A descrição a seguir é um resumo de como os nomes de computador, endereços IP e os endereços MAC são atribuídos a interfaces públicas de um ambiente.

Nomes de computador: não queremos que o NetBIOS resolva nomes de computador na rede pública, porque isso resultaria em um conflito de nome de computador. Para evitar isso, o Lab Management desabilita transmissões NetBIOS na interface pública de cada máquina virtual. Semelhante ao NetBIOS, não queremos que as máquinas virtuais registrem seus nomes de computador NetBIOS em DNS. O Lab Management desabilita o registro DNS, bem como toda interface pública. Na ausência do NetBIOS e do registro DNS padrão, ainda queremos que as máquinas virtuais tenham nomes exclusivos que possam ser usados na rede pública. O Lab Management gera um nome de alias exclusivo em nome de cada máquina virtual e registra isso como um registro "A" no DNS. Em nosso exemplo, o web-server no ambiente original poderia ser registrado usando-se um nome de alias exclusivo semelhante a VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com. O mesmo web-server no ambiente clonado é registrado usando-se um nome diferente que poderia ser semelhante a VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com.

Endereços IP: a interface de rede pública em cada máquina virtual é configurada para obter o endereço IP dinâmico de um servidor DHCP. Isso garante que as máquinas virtuais em ambientes original e clonado tenham endereços IP exclusivos. Por exemplo, o web-server no ambiente original poderia receber um endereço IP 172.52.20.140 e o mesmo web-server no ambiente clonado poderia receber um endereço IP 172.52.20.205.

Endereços MAC: para evitar conflitos MAC, a interface de rede pública em cada máquina virtual poderia ser configurada para obter endereços MAC dinâmicos de um hipervisor. Isso garantiria que o computador web-server em nosso exemplo recebesse um endereço MAC diferente em ambientes original e clonado. No entanto, conforme descrito anteriormente, quando um ambiente clonado é restaurado para um instantâneo feito no ambiente original, os endereços MAC e IP da máquina virtual clonada pressupõem os mesmos valores originais. Por exemplo, quando o ambiente clonado é restaurado para o instantâneo de compilação mais recente, o endereço IP do web-server se torna 10.86.51.61 (consulte a Figura 3), que é o mesmo valor presente no ambiente original. O mesmo acontece com o endereço MAC também. Quando o conflito de endereço IP é temporário até ser renovado pelo DHCP, o conflito de MAC permanece até as máquinas virtuais serem reiniciadas. Por conta dessa limitação, o uso de endereços MAC atribuídos dinamicamente do hipervisor para interfaces públicas não é uma solução viável.

Para resolver isso, o Lab Management usa seu próprio pool de endereços MAC. Os endereços MAC exclusivos desse pool são atribuídos a interfaces públicas de máquinas virtuais. Sempre que o ambiente clonado é restaurado para um instantâneo, o Lab Management altera os endereços MAC automaticamente para evitar conflitos. Para entender como isso funciona, considere que o endereço MAC do web-server no ambiente original é 1D-D8-B7-1C-00-05 e que o endereço MAC do web-server no ambiente clonado é 1D-D8-B7-1C-00-07. Quando o ambiente clonado é restaurado para um instantâneo feito no ambiente original, o endereço MAC do web-server se torna 1D-D8-B7-1C-00-05 momentaneamente. O Lab Management altera novamente para 1D-D8-B7-1C-00-07 a fim de evitar conflito de rede.

Interações típicas com isolamento de rede

Em seguida, abordaremos o que acontece quando duas máquinas virtuais no ambiente se comunicam:

1. Web-server usa NetBIOS ou arquivo de hosts para resolver o nome do computador "db-server" para o endereço IP da interface privada de db-server (192.168.23.2).

2. Web-server se comunica com db-server nesse endereço IP.

Quando um cliente fora do ambiente precisar se comunicar com o web-server em um ambiente clonado, o seguinte processo será acompanhado:

1. O cliente consulta o software Lab Management para obter o nome do alias exclusivo do web-server no ambiente clonado.

2. O software Lab Management responde com o nome do alias exclusivo.

3. O servidor DNS resolve o nome do alias exclusivo para o endereço IP da interface pública do web-server (10.86.51.63).

4. O cliente se comunica com o web-server nesse endereço IP.

Abordagens alternativas para isolamento de rede

O uso de duas interfaces não é a única abordagem para o isolamento de rede. Uma abordagem muito semelhante é usar uma NAT bidirecional. NAT é uma abordagem comum para criar uma rede privada de dispositivos que precisam se comunicar com dispositivos em uma rede pública. Mesmo que a comunicação em uma NAT típica sempre deva se originar na rede privada, a NAT bidirecional (ou NAT bidirecional) dá um passo adiante e permite a comunicação iniciada por computadores na rede privada ou por aqueles na rede pública.

Para realizar o isolamento de rede usando essa abordagem, um servidor NAT bidirecional precisa ser introduzida no ambiente. Isso costuma ser feito adicionando-se uma máquina virtual especial ao ambiente que apenas cumpre a função de um servidor NAT bidirecional. Quando um ambiente de rede isolado é criado, os endereços IP públicos e privados das máquinas virtuais são atribuídos da mesma maneira como são na abordagem de duas interfaces. Porém, em vez de atribuir o endereço IP público a uma interface de rede na máquina virtual, os mapeamentos são armazenados em uma tabela NAT no servidor NAT bidirecional.

As etapas para duas máquinas virtuais dentro do ambiente para se comunicar entre si usando uma abordagem NAT bidirecional são exatamente o mesmo quando forem abordagem de duas interfaces:

1. Web-server usa NetBIOS ou arquivo de hosts para resolver o nome do computador db-server para o endereço IP da interface privada de db-server (192.168.23.2).

2. Web-server se comunica com db-server nesse endereço IP.

As etapas quando um cliente fora do ambiente precisar se comunicar com o web-server em um ambiente clonado são um pouco diferentes e são as seguintes:

1. Implementando a abordagem NAT, o cliente consulta o software Lab Management para obter o nome do alias exclusivo do web-server no ambiente clonado. (O Visual Studio Lab Management não implementa a abordagem NAT.)

2. O software Lab Management responde com o nome do alias exclusivo.

3. O servidor DNS resolve o nome do alias exclusivo para o endereço IP público do web-server (10.86.51.63).

4. Esse endereço IP é, na verdade, mapeado para uma interface no servidor NAT bidirecional. O cliente se comunica com o servidor NAT bidirecional enquanto pressupõe se comunicar com o web-server.

5. O servidor NAT recupera os mapeamentos armazenados nas tabelas de configuração e traduz o endereço IP público (10.86.51.63) para o endereço IP privado (192.168.23.1).

6. O servidor NAT encaminha a mensagem do cliente na rede privada para 192.168.23.1, que é o endereço IP do web-server.

O benefício dessa abordagem em relação à abordagem de duas interfaces é que as máquinas virtuais no ambiente não precisam ser modificadas de forma alguma. Não há necessidade de introduzir uma interface de rede adicional em cada máquina virtual. A introdução de uma interface de rede adicional em uma máquina virtual pode interromper alguns aplicativos.

Outro benefício dessa abordagem é que toda a lógica para obter o isolamento de rede é encapsulada na máquina virtual extra. Não há necessidade de ter um agente em cada uma das outras máquinas virtuais. O encaminhamento de todos os pacotes por meio da máquina virtual extra também fornece um ponto de controle adicional para dar suporte a recursos mais avançados de isolamento de rede como:

• Isolamento somente de saída: não permite que pacotes de rede iniciados por clientes fora do ambiente alcancem máquinas virtuais dentro do ambiente.

• Somente de saída com exceções de porta específicas: não permite que pacotes de rede iniciados por clientes fora do ambiente alcancem máquinas virtuais dentro do ambiente, a menos que sejam destinados a uma porta específica.

Esses recursos podem ser facilmente implementados na abordagem NAT bidirecional introduzindo-se um firewall no servidor NAT. A principal desvantagem da abordagem NAT bidirecional é que alguns aplicativos não funcionam em NAT. Por exemplo, DCOM e protocolos remotos .NET, normalmente usados em aplicativos do Windows, não funcionam quando o cliente e o servidor são separados por um servidor NAT. É por esse motivo que o Visual Studio Lab Management usa a abordagem de interfaces duplas. Outra desvantagem da abordagem NAT bidirecional é que ela exige uma máquina virtual adicional em cada ambiente, o que inclui uma sobrecarga adicional durante a criação ou outras operações em ambientes virtuais.

Outros conflitos

Até agora, descrevemos como o nome do computador, o endereço IP e o endereço MAC podem ser resolvidos por meio do isolamento de rede. Quando os ambientes são clonados, existem outras formas de conflitos que também poderiam ocorrer. Sempre que há uma dependência em um componente externo fora do ambiente virtual, existe um potencial de um conflito quando esse ambiente é clonado. Nesta seção, observamos dois casos comuns, em que esses conflitos poderiam ocorrer.

Conflitos do Active Directory

É comum que computadores e aplicativos do Windows dependam do AD (Active Directory) para serviços de diretório ou para autenticação e autorização do usuário. O gerenciamento centralizado de computadores do Windows usando-se políticas de grupo AD é uma prática muito comum. Usando nosso exemplo, suponhamos que o web-server e o db-server no ambiente original sejam adicionados a um domínio gerenciado por um AD. O AD está fora do ambiente hospedado. Ao clonarmos esse ambiente, temos agora dois clones idênticos do web-server; no entanto, existe apenas uma entrada no AD. Isso é claramente indesejável e pode resultar em vários problemas. Por exemplo, se um clone do web-server for desassociado do domínio por uma ação do usuário, o outro é clone também será desassociado. As alterações feitas em um ambiente não intencionalmente afetam o outro ambiente.

Para evitar conflitos do Active Directory, um servidor AD precisa ser hospedado em uma máquina virtual dentro do ambiente. O servidor AD não deve ter relações de confiança com outros diretórios fora do ambiente.

Há algumas considerações adicionais para configurar um AD dentro de um ambiente de rede isolado. Primeiro, a máquina virtual AD não deve estar conectada à rede pública. Na abordagem das duas interfaces, isso significa que a máquina virtual AD não deve ter uma interface pública. Na abordagem NAT bidirecional, isso significa que a tabela NAT não deve ter um mapeamento para a máquina virtual AD.

Segundo, como o AD está em uma floresta independente, deve haver um servidor DNS dentro do ambiente. Outras máquinas virtuais no ambiente devem usar esse servidor DNS na rede privada correta tendo em vista a comunicação adequada com o AD. Como exemplo, uma máquina virtual talvez não consiga adicionar o domínio no AD privado, a menos que a configuração do servidor DNS esteja correta na interface privada.

Quando você configura um ambiente para incluir uma máquina virtual AD, Visual Studio Lab Management automatiza a desconexão de um AD da rede pública e configurando interfaces privadas de máquinas virtuais com configurações de DNS.

Talvez haja situações nas quais não é possível hospedar um AD dentro do ambiente. Por exemplo, isso poderia acontecer quando o aplicativo em desenvolvimento tivesse que usar um AD corporativo para integração com outros aplicativos corporativos existentes. Não há solução conhecida para habilitar a clonagem segura de ambientes quando os computadores são adicionados a um domínio fora do ambiente.

Conflitos de banco de dados

Outro uso comum de ambientes virtuais envolve a hospedagem do banco de dados do aplicativo fora do ambiente. Normalmente, isso é feito quando o banco de dados é grande o suficiente e quando não é prático clonar o banco de dados com cada ambiente. Isso também poderia ocorrer quando o aplicativo em desenvolvimento fosse um cliente web simples que interagisse com um banco de dados hospedado em outro lugar. Nesses casos, quando dois clone idênticos interagem com o base de dados, o servidor de base de dados é incapaz de distinguir a identidade dos dois clientes.

Resumo

A capacidade de criar clone idênticos de ambientes virtuais é essencial para vários cenários no gerenciamento de laboratório virtual. Porém, quando os clones idênticos são criados, existem conflitos de nome de computador, endereço IP e endereço MAC. As técnicas simples, como alterar nomes de computador ou endereços IP, para corrigir esses conflitos normalmente exigem a reconfiguração ou a reinstalação do aplicativo, e acabam efetivamente com a intenção de criar clones idênticos. O isolamento de rede resolve esse problema permitindo criar e executar dois clones simultaneamente.

Próximas Etapas

Planejar o ambiente SCVMM: saiba quando usar as opções diferentes para ambientes SCVMM como, por exemplo, o uso de máquinas virtuais em execução, máquinas virtuais armazenadas, modelos, ambientes armazenados e isolamento de rede. Consulte Orientação para a criação e gerenciamento de ambientes SCVMM.

Criar um ambiente de rede isolado: use este tópico se você estiver pronto para criar um ambiente de rede isolado. Consulte Criando e usando um ambiente de rede isolado.

Consulte também

Automatizar testes do sistema