Separando ambientes de teste

2

Estamos utilizando o TFS e o Hyper-V com o SCVMM para nossos ambientes de teste, mas infelizmente não temos nenhuma separação de rede no momento. Tivemos que criar nosso próprio domínio para usar de forma mais eficiente a implantação do SCVMM e o gerenciamento do TFS sem precisar obter acesso de domínio a toda a rede corporativa.

Isso é problemático para nós por alguns motivos. Por um lado, estamos enviando spam de descoberta de rede com nossas VMs (não pode ser desativado, é necessário para certas funções do TFS). Para dois, temos que ir manualmente para cada VM na criação, definir estaticamente o DNS para o TFS, ingressar no domínio de teste, redefinir para DHCP e reinicializar a máquina. Isso torna a implantação um pesadelo, além de adicionar hosts Hyper-V adicionais ou criar controladores.

Não queremos isolamento total, ainda precisamos de acesso à Internet para extrair arquivos do Azure durante os ciclos de teste de implantação implícita, mas precisamos ter mais controle sobre o ambiente. A solução mais fácil para isso é mover tudo para sua própria sub-rede?
O maior problema que vejo com isso é a conexão com o TFS ou com qualquer um dos hosts do Hyper-V para manutenção ou acesso a casos de teste.

O segundo, e me disseram que esta é uma idéia terrível, é adicionar o domínio de teste no DNS primário da rede. Mas isso nos deixaria com dois domínios detectáveis de domínio em uma sub-rede.

    
por Koala Bear 29.07.2015 / 18:13

1 resposta

1

we're spamming network discovery with our VMs - O que isso significa? Você pode elaborar sobre isso?

we have to manually go in to each VM on creation, statically set the DNS to the TFS, join the test domain, reset to DHCP, and reboot the machine. - Por que você está redefinindo-os para DHCP? Você deve usar endereços IP estáticos nas máquinas de teste para: 1. Não consumir endereços IP do pool DHCP de produção. 2. Controle melhor a atribuição de servidores DNS às VMs de teste. 3. Gerencie melhor as VMs sabendo quais endereços IP você atribuiu a elas.

The second, and I'm told this is a terrible idea, is to add the test domain into the primary DNS for the network. But that would leave us with two domain discoverable domains on one network subnet. - O que você quer dizer com isso?

Além de uma pequena quantidade de tráfego de transmissão, eu realmente não vejo por que haveria problemas reais em executá-los na mesma rede física e sub-rede que os computadores de produção. Não há interação entre os dois domínios.

    
por 29.07.2015 / 18:24