Clonar máquinas virtuales mediante aislamiento de red

La Administración virtual del laboratorio es un área emergente en los ciclos de vida de desarrollo de software.Visual Studio Lab Management es un producto de Visual Studio que ofrece la administración virtual del laboratorio a los desarrolladores y evaluadores.Mediante lab management de Visual Studio, los equipos de desarrollo pueden aprovechar la tecnología de virtualización en sus procedimientos de desarrollo y de prueba para crear entornos de varios niveles complejos de las máquinas virtuales.Pueden luego mostrar la compilación de la aplicación y ejecutar pruebas en estos entornos.

Una de las motivaciones para utilizar la virtualización en los laboratorios de desarrollo y de pruebas es que se pueden crear copias idénticas, o clones, de máquinas virtuales implementadas mediante la copia de algunos archivos.La clonación es útil en muchos escenarios.Por ejemplo, un desarrollador que necesita una copia del entorno de un evaluador para reproducir un problema puede crear un clon de ese entorno.En un equipo de pruebas, cada evaluador individual puede clonar una copia de un entorno y después coordinar sus pruebas con el resto del equipo.La clonación ahorra tiempo a los desarrolladores y evaluadores porque no tienen que instalar repetidamente los sistemas operativos ni ningún otro software en cada entorno que crean.

Requisitos

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

Aunque es fácil clonar un entorno virtual, existen las consecuencias de clonación que debe considerar.Los equipos de un entorno clonado tienen los mismos nombres de equipo que los equipos del entorno original.En algunos casos, podrían incluso tener las mismas direcciones IP y MAC.Este hecho podría producir que uno de los clones pierda conectividad de red o que el tráfico de red destinado a un clon llegue al otro en su lugar.Finalmente, una consecuencia no deseada podría ser que se implemente una aplicación en un clon determinado y se realicen las pruebas en otro clon.

[!NOTA]

Puede utilizar el aislamiento de red con entornos de SCVMM.Esta característica no está disponible para los entornos estándar.

Lab management de Visual Studio resuelve estos problemas y facilita la clonación segura de entornos virtuales con una tecnología denominada aislamiento de red.Este tema describe cómo funciona el aislamiento de red y compara la clonación con y sin aislamiento de red.El primer ejemplo describe las diversos tipos de conflictos que se pueden producir entre clones a falta del aislamiento de red.Los ejemplos siguientes examinan varias soluciones para evitar conflictos mediante el uso del Visual Studio Lab Management.

Conflictos de red

La tabla 1 muestra un entorno virtual típico que puede crear utilizando lab management.Este entorno, denominado entorno original, tiene dos máquinas virtuales: un servidor web y un servidor de base de datos.Los equipos pueden servir como servidores de web y de bases de datos, respectivamente, en una aplicación web de 3 niveles.En este ejemplo, asumimos que un miembro de un equipo de desarrollo creó este entorno e implementó en dicho entorno la última compilación de la aplicación web.También asumimos que una instantánea denominada la última compilación se ha incorporado a este entorno después de que la compilación fuera implementada.Una instantánea es un estado en un momento dado del entorno.Se puede restaurar y reanudar la ejecución desde el estado guardado en cualquier momento.La ilustración muestra los nombres del equipo, las direcciones IP y MAC de las dos máquinas virtuales del entorno original.

Entorno original

La ilustración 2 muestra, además del original, un entorno clonado.Después de la clonación, cuando se inician los dos entornos, podrían aparecer los siguientes tipos de conflictos de red:

1. Conflictos por el nombre de equipo

2. Conflictos por la dirección IP

3. Conflictos por la dirección MAC

Entornos originales y clonados en una red común

El resultado exacto de cada uno de estos conflictos depende de varios factores: el sistema operativo en las máquinas virtuales, la infraestructura de red en el laboratorio, etc.En la ilustración 2, asumimos que se ha configurado una dirección IP estática y otra MAC también estática en cada máquina virtual del entorno original.Por consiguiente, cuando el entorno se clona, las máquinas virtuales clonadas tienen las mismas direcciones IP y MAC.

Conflictos por el nombre de equipo

Un nombre de equipo es un nombre descriptivo asignado por el usuario para identificar un equipo en una red.Normalmente se utilizan dos protocolos para asignar el nombre del equipo a su dirección IP: NetBIOS y el servidor de nombres de dominio (DNS).Cuando dos equipos que tienen el mismo nombre se inician en el mismo segmento de red, NetBIOS detecta el conflicto de nombres y advierte al usuario.Normalmente, NetBIOS puede detectar conflictos sólo si los equipos están en el mismo segmento de red.Si los equipos no están en el mismo segmento de red o si se desoyen las advertencias, el siguiente nivel de conflictos se produce en DNS.DNS es un repositorio central para que los equipos registren sus nombres.Cuando dos equipos que tienen el mismo nombre de equipo intentan registrarse en DNS, el segundo equipo puede invalidar la entrada creada por el primer equipo.En este caso, el primer equipo que comienza no está accesible a través de la resolución de nombres.

Hay varias sencillas maneras de evitar o de solucionar los conflictos por el nombre de equipo.En lugar de crear copias idénticas de entornos, se puede personalizar cada clon a medida que se crea utilizando un mecanismo denominado sysprep.Sysprep forma parte de los sistemas operativos Windows.Cuando se utiliza el sysprep para clonar entornos, cada máquina virtual del entorno tiene un nombre de equipo único, una dirección IP y una dirección MAC diferentes de los del entorno original.Sin embargo, los clones ya no son idénticos.

El impacto de tener un nombre de equipo único en cada clon, tanto si se hace a través de sysprep como si se hace a través de la intervención manual del usuario para evitar conflictos, depende del software instalado en la máquina virtual.Para comprenderlo, examine el ejemplo.Cuando la aplicación se ha implementado en el entorno, en el servidor web se habrá creado un archivo web.config.En el archivo, hemos configurado el nombre del equipo db-server como parte de la cadena de conexión.Un fragmento del archivo se muestra aquí:

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

Cuando cambiamos el nombre del equipo del servidor de bases de datos en el entorno clonado, también tenemos que cambiar manualmente el archivo web.config como se indica a continuación para utilizar el nuevo nombre (db-server2 es el nuevo nombre del equipo que se le dado a la máquina virtual en el entorno 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>

Además, SQL Server requiere algunos pasos adicionales cuando se cambia el nombre de equipo.A continuación se muestra un fragmento de scripts SQL para realizarlo:

sp_dropserver db-server
sp_addserver db-server2, local
GO

El ejemplo anterior muestra cómo una aplicación tiene que configurarse de nuevo si se cambian los nombres de equipo.Como es lógico, el procedimiento depende de la aplicación.Si una aplicación introduce el nombre del equipo en las entradas en una base de datos, dichas entradas necesitan cambiarse de la misma manera.En algunos casos, puede que haya que reinstalar una aplicación cuando cambia el nombre de equipo.Realizar tales reconfiguraciones y reinstalaciones es claramente lo que deseamos evitar en primer lugar con el uso de clonación.Esto necesita una solución independiente de la aplicación más sólida que permita con seguridad que varios clones coexistan sin conflictos de nombre de equipo.

Conflictos por la dirección IP

Una dirección de protocolo de Internet (IP) se utiliza para que los equipos se comuniquen entre sí a través de una red TCP.Las direcciones IP se asignan estática o dinámicamente por un servidor DHCP en la red.Cada interfaz de red conectada en un equipo tiene una dirección IP.Si se clona una máquina virtual que se configura con una dirección IP estática y después se coloca en la misma red que la máquina virtual original, entonces surge un conflicto de dirección IP, además de un conflicto de nombre del equipo.Se puede corregir manualmente el conflicto cambiando la dirección IP de uno de clones.De nuevo, el impacto de cambiar la dirección IP depende de cómo las aplicaciones que se instalan en máquinas virtuales utilizan la dirección IP estática.

Cuando se empieza a clonar una máquina virtual configurada con una dirección IP dinámica, hay un conflicto de la red por un corto período de tiempo.Poco después de clonar la primera máquina virtual, la segunda máquina virtual al conectarse a la red detecta el conflicto y se corrige al renovar su dirección IP.Un período corto similar de conflicto ocurre cada vez que el entorno clonado se restaura en una instantánea que se capturó en el entorno original.Los periodos de conflicto no suelen durar el tiempo suficiente para afectar a la aplicación.

Conflictos por la dirección MAC

Una dirección de control de acceso al medio (MAC) es una dirección asignada a cada interfaz de red en un equipo.En el caso de los equipos físicos, el fabricante de la tarjeta la asigna a cada interfaz de red.En el caso de las máquinas virtuales, hay dos maneras de asignar direcciones MAC: MAC estática o dinámica.Puede especificar una dirección MAC concreta que vaya a utilizar para una interfaz de red de una máquina virtual.Esto se denomina MAC estática.O bien, puede dejar al hipervisor asignar una dirección MAC dinámicamente.Esto se denomina MAC dinámica.Las direcciones MAC dinámicas se asignan por el Hyper-V desde un grupo de direcciones MAC cada vez que se inicia una máquina virtual.Cada host tiene un esquema para generar direcciones MAC de manera que no entren en conflicto con las máquinas virtuales en otro host.

Si se utilizan las direcciones MAC estáticas para las máquinas virtuales del entorno original, las máquinas virtuales del entorno clonado tendrán las mismas direcciones MAC.Esto rápidamente ocasiona conflictos de MAC.Las direcciones MAC duplicadas son más difíciles de detectar porque los equipos no siempre las notifican.Y en el caso de que se notifiquen, dichos mensajes se registran en el Visor de eventos de Windows.Para un usuario final, hay dos posibles consecuencias de direcciones MAC duplicadas.Una consecuencia es la pérdida de conectividad de red en uno o en ambos clones.Otra consecuencia es que los paquetes de red dirigidos a un equipo pueden llegar a otro equipo.Cuando un equipo original y su clon tienen las mismas direcciones MAC, sus direcciones IP también son iguales.Aunque DHCP se usa para obtener Direcciones IP dinámicas, el servidor DHCP asignará las mismas Direcciones IP ya que las direcciones MAC son idénticas.

Hast cierto punto, se pueden evitar conflictos MAC mediante direcciones MAC dinámicas.Sin embargo, cuando el entorno clonado se restaura en una instantánea tomada en el entorno original, el estado completo de esas máquinas virtuales se revierte, incluidas las direcciones MAC.De nuevo, esto da lugar a conflictos MAC y los mismos problemas descritos previamente existen hasta que se reinicia la máquina virtual clonada.Reiniciar el entorno clonado hace que el hipervisor libere y renueve las direcciones MAC con valores de su propio rango.

La detección y resolución de los tipos de conflictos que acabamos de describir, y después corregir manualmente de la aplicación OS para seguir trabajando después de la resolución, es muy importante, lleva mucho tiempo, y es proclive a errores para los usuarios frecuentes de la administración virtual del laboratorio.En muchos casos, cambiar cualquiera de los parámetros cambia el entorno virtual lo suficiente como para producir la pérdida de una reproducción de error o un problema similar con el entorno de producción.El principio de instalar la aplicación una vez en un entorno virtual y la clonación sin problemas de dicho entorno para crear varias copias idénticas requiere un enfoque más sofisticado de lo que se puede esperar que hagan los usuarios normales.

Aislamiento de red

Hasta ahora dos requisitos se han identificado.El primer requisito es que las máquinas virtuales de un entorno clonado deben tener los mismos nombres de equipo, y las mismas direcciones IP y MAC que los del entorno original.Pero, al mismo tiempo, estos clones tienen que ser independientemente direccionables desde fuera del entorno.Esto es necesario, por ejemplo, para que alguien se conecte a cada uno de los clones de sus mesas, para implementar una aplicación en un clon concreto o para que una prueba se ejecute en un clon concreto.Esto conduce al segundo requisito, que es que las máquinas virtuales de un entorno clonado también deben tener nombres de equipo únicos y direcciones IP y MAC diferentes de los del entorno original.La manera lógica de realizar ambos requisitos es que cada máquina virtual tenga dos interfaces: una interfaz privada para la que el nombre de equipo, la dirección IP y la dirección MAC son iguales en cada clon; y una interfaz pública para la que estos valores son únicos en cada clon.

Para evitar conflictos de red a las interfaces privadas, estas tienen que estar conectadas a una red privada en cada clon.Una red privada es una red virtual que está restringida sólo a las máquinas virtuales dentro de un entorno.Dado que esta red no se expone más allá de los límites de un entorno, no hay posibilidad de conflictos aunque se utilicen los mismos nombres de equipo y las direcciones IP y MAC en otro clon.Para la accesibilidad desde fuera del entorno, todas las interfaces públicas tienen que estar conectadas a una red pública común.La red pública o la red de laboratorio es la red en la que las máquinas virtuales de entornos pueden interactuar con los clientes y otros equipos del laboratorio.

La ilustración 3 muestra cómo las interfaces privadas y públicas tratan los conflictos de red.

Aislamiento de red en Visual Studio Lab Management

Visual Studio Lab Management implementa el aislamiento de red para los entornos de SCVMM introduciendo dos interfaces de red en cada máquina virtual.Una de estas interfaces de red es una interfaz privada conectada a una red privada y la otra es una interfaz pública conectada a la red pública.

El software de Lab Management, junto con un agente instalado en cada máquina virtual, garantiza que el entorno original y el entorno clonado pueden coexistir sin conflictos.

Interfaces privadas en la red privada

La siguiente descripción es un resumen de cómo se asignan los nombres de equipo y las direcciones IP y MAC a las interfaces privadas de un entorno.

Nombres de equipo: Los nombres de equipo en la red privada se resuelven con NetBIOS y no requieren ningún control adicional por parte del software de Lab Management.Las aplicaciones que se configuran para trabajar con nombres de equipo NetBIOS funcionan como se espera en cada clon.En nuestro ejemplo, el equipo servidor web hace referencia al equipo servidos de base de datos utilizando su nombre.Los nombres son iguales en los entornos original y clonado, respectivamente.Por consiguiente, el archivo web.config no tiene que cambiar en el entorno clonado.

Dado que no hay ningún servidor DNS en la red privada, necesitamos abordar la situación cuando los nombres de dominio completo (FQDN) usan las máquinas virtuales para referirse a cada uno en lugar de a los nombres de NetBIOS.Por ejemplo, si el archivo web.config hacía referencia al servidor de base datos como db-server.lab.contoso.com, entonces la asignación de ese nombre a una dirección IP no sería posible sin DNS en la red privada.Para resolverlo, el agente de laboratorio que se ejecuta en la máquina virtual agrega las entradas que corresponden a las otras máquinas virtuales del mismo entorno en el archivo de hosts.El archivo de hosts es otro modo de indicar al sistema operativo que hay que asignar un nombre a una dirección IP concreta.En nuestro ejemplo, el archivo de hosts en el servidor web tendrá la entrada siguiente:

192.168.23.2 db-server.lab.contoso.com

Direcciones IP: Una dirección IP estática desde el intervalo 192.168.23.1 - 255 se asigna a la interfaz de red privada de cada máquina virtual.Por ejemplo, la interfaz privada del servidor web tiene la dirección 192.168.23.1 y la interfaz privada del servidor de base de datos tiene la dirección 192.168.23.2.Lab management garantiza que el servidor web y los servidores de base de datos tienen las mismas direcciones IP estáticas en cada clon.Por consiguiente, incluso si el archivo web.config en el servidor web se configura con la dirección IP de los servidores de base de datos, no tiene que configurarse de nuevo en el entorno clonado.En cualquier entorno configurado con aislamiento de red, las interfaces privadas obtienen las direcciones IP del mismo intervalo, comenzando por 192.168.23.1.El número máximo de direcciones necesarias en el intervalo es igual que el número máximo de máquinas virtuales de un entorno.Dado que este conjunto de direcciones IP no es enrutable desde fuera de la red privada, es seguro utilizar un intervalo predefinido mientras el mismo intervalo no se utilice en la red pública.

Direcciones MAC: Una dirección MAC estática aleatoria es asignada a la interfaz de red privada de cada máquina virtual en un entorno de aislamiento de red.En nuestro ejemplo, a la interfaz privada en el servidor web original se le proporciona una dirección MAC como 00-15-5D-07-57-01.Lab management garantiza que el servidor web también consigue la misma dirección MAC en el entorno clonado.Dado que el conjunto de direcciones MAC no es enrutable desde fuera de la red privada, es seguro utilizar una dirección aleatoria mientras no estén dentro del intervalo de lo que utiliza el hipervisor en ese host.

Interfaces públicas en la red pública

La siguiente descripción es un resumen de cómo se asignan los nombres de equipo y las direcciones IP y MAC a las interfaces públicas de un entorno.

Nombres de equipo: No queremos NetBIOS para asignar nombres de equipo de la red pública porque el hacerlo causaría un conflicto de nombres de equipo.Para evitar esto, Lab Management deshabilita las difusiones de NetBIOS en la interfaz pública de cada máquina virtual.Parecido a NetBIOS, no queremos las máquinas virtuales para registrar sus nombres de equipo NetBIOS en DNS.Lab management también deshabilita el registro DNS para cada interfaz pública.A falta de NetBIOS y del registro DNS predeterminado, todavía queremos máquinas virtuales con nombres únicos que se puedan utilizar en la red pública.Lab Management genera un nombre de alias específico en nombre de cada máquina virtual y lo registra como un registro “A” en DNS.En nuestro ejemplo, el servidor web en el entorno original podría registrarse mediante un nombre de alias específico que se parezca a VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com.Se registra el mismo servidor web en el entorno clonado utilizando un nombre diferente que podría parecerse a VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com.

Direcciones IP: Se configura la interfaz de red pública en cada máquina virtual para conseguir la dirección IP dinámica desde un servidor DHCP.Esto garantiza que las máquinas virtuales en entornos originales y clonados tengan direcciones IP únicas.Por ejemplo, el servidor web en el entorno original podría tener una dirección IP de 172.52.20.140 y el mismo servidor web en el entorno clonado podría tener una dirección IP de 172.52.20.205.

Direcciones MAC: Para evitar conflictos de MAC, se puede configurar la interfaz de la red pública en cada máquina virtual para obtener las direcciones MAC dinámicas desde el hipervisor.Esto aseguraría que el equipo servidor web en nuestro ejemplo consigue otra dirección MAC en entornos originales y clonados.Sin embargo, como se ha descrito anteriormente, cuando un entorno clonado se restaura en una instantánea tomada en el entorno original, la dirección MAC e IP de la máquina virtual clonada asume los mismos valores que el original.Por ejemplo, cuando el entorno clonado se restaura para compilar lo más tarde posible la instantánea, la dirección IP del servidor web se convierte en 10.86.51.61 (vea el cuadro 3), que es el mismo valor que en el entorno original.Lo mismo sucede con la dirección MAC.Mientras el conflicto de la dirección IP es temporal hasta que se renueva por DHCP, el conflicto MAC existe hasta que las maquinas virtuales se reinician.Debido a esta limitación, utilizar direcciones MAC asignadas dinámicamente desde el hipervisor para las interfaces públicas no es una solución factible.

Para resolver esto, Lab Management utiliza su propio conjunto de direcciones MAC.Las direcciones MAC únicas de este conjunto se asignan a las interfaces públicas de las máquinas virtuales.Siempre que el entorno clonado se restaure en una instantánea, Lab Management cambia las direcciones MAC automáticamente para evitar conflictos.Para entender cómo funciona esto, considere que la dirección MAC del servidor web en el entorno original es 1D-D8-B7-1C-00-05 y que la dirección MAC del servidor web en el entorno clonado es 1D-D8-B7-1C-00-07.Cuando el entorno clonado se restablece en una instantánea tomada en el entorno original, la dirección MAC del servidor web es 1D-D8-B7-1C-00-05 momentáneamente.Lab Management cambia de nuevo a 1D-D8-B7-1C-00-07 para evitar el conflicto de la red.

Interacciones típicas con aislamiento de red

A continuación, se describirá qué ocurre cuando dos máquinas virtuales del entorno se comunican entre sí:

1. El servidor web utiliza NetBIOS o el archivo de hosts para asignar el nombre de equipo “db-server” a la dirección IP de la interfaz privada (192.168.23.2) db-server.

2. El servidor web se comunica con db-server en esta dirección IP.

Cuando un cliente fuera del entorno tiene que comunicarse con el servidor web en un entorno clonado, se sigue el proceso siguiente:

1. El cliente consulta el software Lab Management para conseguir el nombre del alias específico del servidor web en el entorno clonado.

2. El software Lab Management responde con el nombre de alias específico.

3. El servidor DNS asigna el nombre de alias específico a la dirección IP de la interfaz pública del servidor web (10.86.51.63).

4. El cliente se comunica con el servidor web en esta dirección IP.

Enfoques alternativos para el aislamiento de la red

Usar dos interfaces no es el único enfoque para el aislamiento de red.Un enfoque muy similar es utilizar un NAT bidireccional.NAT es un enfoque común para crear una red privada de dispositivos que necesitan comunicarse con dispositivos en una red pública.Aunque la comunicación típica en NAT debe iniciarse siempre en la red privada, NAT bidireccional (o 2 vías NAT) da un paso adelante y permite la comunicación iniciada por equipos dela red privada o por los de la red pública.

Para realizar el aislamiento de red mediante este enfoque, un servidor NAT bidireccional tiene que estar introducido en el entorno.Esto se hace normalmente agregando una máquina virtual especial al entorno que simplemente cumple el rol de un servidor NAT bidireccional.Cuando se crea un entorno de aislamiento de red, las direcciones IP públicas y privadas de las máquinas virtuales se asignan de la misma forma que en las dos interfaces aproximadas.Sin embargo, en lugar de asignar la dirección IP pública a una interfaz de red en la máquina virtual, las asignaciones se almacenan en una tabla NAT en el servidor NAT bidireccional.

Los pasos que hay que seguir para que dos máquinas virtuales del entorno se comuniquen entre sí utilizan un enfoque bidireccional NAT, son exactamente los mismos que en el enfoque de dos interfaces:

1. El servidor web utiliza NetBIOS o el archivo de hosts para asignar el nombre de equipo db-server a la dirección IP de la interfaz privada (192.168.23.2) db-server.

2. El servidor web se comunica con db-server en esta dirección IP.

Los pasos que hay que seguir cuando un cliente fuera del entorno tiene que comunicarse con el servidor web en el entorno clonado son ligeramente diferentes y son los siguientes:

1. Mediante la implementación del enfoque NAT, el cliente consulta al software Lab Management para obtener el nombre del alias específico del servidor web en el entorno clonado.(Visual Studio Lab Management no implementa el enfoque NAT).

2. El software Lab Management responde con el nombre de alias específico.

3. El servidor DNS asigna el nombre de alias específico a la dirección IP pública del servidor web (10.86.51.63).

4. Esta dirección IP realmente se asigna a una interfaz en el servidor NAT bidireccional.El cliente se comunica con el servidor NAT bidireccional mientras asume que se está comunicando con el servidor web.

5. El servidor NAT recupera las asignaciones almacenadas en las tablas de configuración y convierte la dirección IP pública (10.86.51.63) en la dirección IP privada (192.168.23.1).

6. El servidor NAT reenvía el mensaje del cliente en la red privada a 192.168.23.1, que es la dirección IP del servidor web.

La ventaja de este enfoque sobre el enfoque de dos interfaces es que las máquinas virtuales del entorno no tienen que ser modificadas en modo alguno.No es necesario introducir una interfaz de red adicional en cada máquina virtual.La introducción de una interfaz de red adicional en una máquina virtual puede hacer que algunas aplicaciones se interrumpan.

Otra ventaja de este enfoque es que toda a lógica para lograr el aislamiento de red está encapsulada en la máquina virtual adicional.No es necesario tener un agente en cada una de las otras máquinas virtuales.Enrutar todos los paquetes a través de la máquina virtual también proporciona un punto de control adicional para admitir características avanzadas de aislamiento de red tales como:

• Barrera de Out-only: No permite que los paquetes de red iniciados por los clientes fuera del entorno lleguen a las máquinas virtuales del entorno.

• Out-only con excepciones específicas de puerto: No permite que los paquetes de red iniciados por los clientes fuera del entorno lleguen a las máquinas virtuales del entorno a menos que se dirijan a un puerto concreto.

Estas características se pueden implementar con facilidad en el enfoque NAT bidireccional introduciendo un cortafuegos en el servidor NAT. El principal inconveniente del enfoque NAT bidireccional es que algunas aplicaciones no funcionan a través de NAT.Por ejemplo DCOM y los protocolos de .NET Remoting, que normalmente se utilizan en aplicaciones para Windows, no funcionan cuando el cliente y el servidor están separados por un servidor NAT.Es por esta razón que Visual Studio Lab Management utiliza el enfoque de interfaces duales.Otra desventaja del enfoque NACIONAL bidireccional es que requiere una máquina virtual adicional en cada entorno, que introduce sobrecarga adicional durante la creación u otras operaciones en entornos virtuales.

Otros conflictos

Hasta ahora, hemos descrito como los conflictos por el nombre del equipo y las direcciones IP y MAC pueden resolverse con el aislamiento de red.Cuando se clonan los entornos, hay otros tipos de conflictos que también se pueden producir.Siempre que hay dependencia de un componente externo que está fuera del entorno virtual, existe la posibilidad de que ocurra un conflicto cuando dicho entorno se clona.En esta sección, se estudian dos casos comunes, donde tales conflictos puede ocurrir.

Conflictos de Active Directory

Es habitual que los equipos y las aplicaciones de Windows se basen en Active Directory (AD) bien los servicios de directorio como para la autenticación y autorización de usuarios.Administrar los equipos de Windows centralmente mediante directivas de grupo de AD es una práctica muy común.Utilizando nuestro ejemplo, vamos a suponer que el servidor web y el servidor de base de datos en el entorno original se unen a un dominio administrado por un AD.El AD está alojado fuera del entorno.Cuando clonamos el entorno, tenemos dos clones de servidor web idénticos; sin embargo, solo hay una entrada en el AD.Esto claramente no se desea y puede provocar algunos problemas.Por ejemplo, si uno de clones del servidor web es independiente del dominio mediante una acción del usuario, el otro clon también se separa.Los cambios realizados en un entorno afectan involuntariamente el otro entorno.

Para evitar conflictos de Active Directory, un servidor de AD tiene que estar alojado en una máquina virtual dentro del entorno.El servidor de AD no debe tener ninguna relación de confianza con otros directorios fuera del entorno.

Hay algunas consideraciones adicionales para colocar un AD dentro de un entorno de aislamiento de red.Primero, la máquina virtual de AD no debe estar conectada a la red pública.En el enfoque de las dos interfaces, esto significa que la máquina virtual de AD no debe tener una interfaz pública.En el enfoque NAT bidireccional, esto significa que la tabla NAT no debe tener una asignación para la máquina virtual de AD.

Segundo, debido a que el AD está en un bosque independiente, debe haber un servidor DNS en el entorno.Otras máquinas virtuales del entorno deben utilizar este servidor DNS en la red privada para una comunicación correcta con el AD.Por ejemplo, una máquina virtual puede no ser capaz unirse al dominio en el AD privado a menos que la configuración del servidor DNS esté correctamente configurada en la interfaz privada.

Al configurar un entorno para incluir una máquina virtual de AD, Visual Studio Lab Management automatiza la desconexión de un AD desde la red pública y configura las interfaces privadas de las máquinas virtuales con los valores DNS.

Puede haber situaciones en las que no es posible alojar un AD dentro del entorno.Por ejemplo, esto podría suceder cuando la aplicación en desarrollo tiene que utilizar un AD corporativo para su integración con otras aplicaciones corporativas existentes.No hay ninguna solución conocida que permita la clonación segura de entornos cuando los equipos están unidos a un dominio fuera del entorno.

Conflictos de la base de datos

Otro uso frecuente de entornos virtuales implica hospedar de la base de datos de la aplicación fuera del entorno.Normalmente, esto se hace cuando la base de datos es bastante grande y cuando no es práctico clonar la base de datos con cada entorno.Esto también podría ocurrir cuando la aplicación en desarrollo es un cliente web simple que interactúa con una base de datos alojada en otra parte.En estos casos, cuando dos clones idénticos interactúan con la base de datos, el servidor de bases de datos no puede distinguir la identidad de los dos clientes.

Resumen

La capacidad de crear clones idénticos de entornos virtuales es esencial para varios escenarios de administración virtual de laboratorio.Sin embargo, al crear clones idénticos, surgen conflictos por los nombres de equipo y las direcciones IP y MAC.Las técnicas simples, tales como cambiar los nombres del equipo o las direcciones IP, para resolver estos conflictos normalmente requieren la reconfiguración o reinstalación de la aplicación y rechazan eficazmente la intención de crear clones idénticos.El aislamiento de red resuelve este problema permitiendo crear y ejecutar dos clones simultáneamente.

Pasos siguientes

Planeele entorno de SCVMM: Learn sobre cuándo utilizar las diferentes opciones para los entornos de SCVMM, como el uso de máquinas virtuales en ejecución, almacenó máquinas virtuales, plantillas, los entornos almacenados, y el aislamiento de red.Vea Guía para crear y administrar entornos SCVMM.

Uso de Cree un entorno de aislamiento de red: este tema si está listo para crear un entorno de aislamiento de red.Vea Crear y usar un entorno con aislamiento de red.

Vea también

Conceptos

Usar un entorno de laboratorio para el ciclo de vida de la aplicación