Clonar máquinas virtuales mediante aislamiento de red

La administración del laboratorio virtual 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 del laboratorio virtual a los desarrolladores y evaluadores. Al usar Visual Studio Lab Management, los equipos de desarrollo pueden aprovechar la tecnología de virtualización en sus laboratorios de desarrollo y de pruebas para crear complejos entornos de varios niveles a partir de las máquinas virtuales. Después pueden implementar las compilaciones 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 consiste en que se pueden crear copias idénticas (clones) de las máquinas virtuales implementadas mediante la copia de unos pocos 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 su trabajo de pruebas con el del 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, se deben tener en cuenta algunas consecuencias de la clonación. Los equipos de un entorno clonado tienen los mismos nombres de equipo que los del entorno original. En algunos casos, podrían incluso tener las mismas direcciones IP y MAC. Esto podría tener como resultado 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 una aplicación se implemente en un clon determinado y las pruebas se realicen en otro clon.

Nota

El aislamiento de red solo se puede utilizar con entornos de SCVMM.Esta característica no está disponible para los entornos estándar.

Visual Studio Lab Management resuelve estos problemas y facilita la clonación segura de entornos virtuales con una tecnología denominada aislamiento de red. En este tema se describe cómo funciona el aislamiento de red y se compara la clonación con y sin aislamiento de red. En el primer ejemplo se describen varios tipos de conflictos que se pueden producir entre clones si no se utiliza el aislamiento de red. En los ejemplos siguientes se examinan varias soluciones para evitar conflictos mediante Visual Studio Lab Management.

Conflictos de red

La figura 1 muestra un entorno virtual típico que se puede crear con Lab Management. Este entorno, denominado entorno original, tiene dos máquinas virtuales: web-server y db-server. Estos equipos proporcionan los roles de servidor web y servidor de bases de datos, respectivamente, en una aplicación web de 3 capas. En este ejemplo, se supone que un miembro de un equipo de desarrollo creó este entorno e implementó en él la compilación más reciente de la aplicación web. También se supone que, una vez implementada la compilación, se ha tomado una instantánea de este entorno denominada compilación más reciente. Una instantánea es un estado del entorno en un momento dado. Se puede restaurar y reanudar la ejecución desde el estado guardado en cualquier momento. En la ilustración se muestran los nombres de equipo y las direcciones IP y MAC de las dos máquinas virtuales del entorno original.

Entorno original

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

1. Conflictos de nombre de equipo

2. Conflictos de dirección IP

3. Conflictos de 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 de las máquinas virtuales, la infraestructura de red del laboratorio, etc. En la figura 2, se supone que se han configurado direcciones IP y MAC estáticas en cada máquina virtual del entorno original. Por consiguiente, cuando se clonó el entorno, las máquinas virtuales clonadas tenían las mismas direcciones IP y MAC.

Conflictos de 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 resolver un nombre del equipo en su dirección IP: NetBIOS y servidor DNS. Cuando dos equipos que tienen el mismo nombre se inician en el mismo segmento de red, NetBIOS detecta el conflicto de nombres y avisa al usuario. Normalmente, NetBIOS puede detectar conflictos solo 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 omiten las advertencias, el siguiente nivel de conflicto 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 se inicia no está accesible a través de la resolución de nombres.

Hay varias maneras sencillas de evitar o solucionar los conflictos de nombre de equipo. En lugar de crear copias idénticas de los entornos, se puede personalizar cada clon a medida que se crea mediante un mecanismo denominado sysprep. Sysprep forma parte de los sistemas operativos Windows. Cuando se utiliza sysprep para clonar entornos, cada máquina virtual del entorno tiene un nombre de equipo único, así como una dirección IP y una dirección MAC diferentes de las 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 de equipo db-server como parte de la cadena de conexión. Aquí se muestra un fragmento del archivo:

<?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 de 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 de equipo asignado 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 realizarlos:

sp_dropserver db-server
sp_addserver db-server2, local
GO

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

Conflictos de 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. Un servidor DHCP de la red asigna las direcciones IP de forma estática o dinámica. Cada interfaz de red conectada en un equipo tiene una dirección IP. Si una máquina virtual configurada con una dirección IP estática se clona y, después, se coloca en la misma red que la máquina virtual original, surge un conflicto de dirección IP, además de un conflicto de nombres de equipo. Este conflicto se puede corregir manualmente cambiando la dirección IP de uno de los clones. De nuevo, el impacto de cambiar la dirección IP depende de cómo se use la dirección IP estática en las aplicaciones instaladas en las máquinas virtuales.

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

Conflictos de dirección MAC

Una dirección MAC (Media Access Control) 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: 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 que el hipervisor asigne una dirección MAC dinámicamente. Esto se denomina MAC dinámica. Hyper-V asigna las direcciones MAC dinámicas 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 ocasiona rápidamente 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, esos 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 de los clones o en ambos. Otra consecuencia es que los paquetes de red dirigidos a un equipo puedan 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 les asignará las mismas direcciones IP, ya que las direcciones MAC son idénticas.

Hasta cierto punto, se pueden evitar los conflictos de MAC si se usan direcciones MAC dinámicas. Sin embargo, cuando el entorno clonado se restaura en una instantánea tomada en el entorno original, se revierte el estado completo de esas máquinas virtuales, incluidas las direcciones MAC. De nuevo, esto da lugar a conflictos MAC y existen los mismos problemas descritos previamente hasta que se reinicia la máquina virtual clonada. El reinicio del 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 la posterior corrección manual de la aplicación o del SO 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 del laboratorio virtual. 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 errores 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 del que se puede esperar de los usuarios normales.

Aislamiento de red

Hasta ahora se han identificado dos requisitos. El primer requisito lo constituye el 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 desde su escritorio, 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 consiste en que las máquinas virtuales de un entorno clonado también deben tener nombres de equipo únicos y direcciones IP y MAC diferentes de las del entorno original. La manera lógica de cumplir ambos requisitos es hacer que cada máquina virtual tenga dos interfaces: una interfaz privada donde el nombre de equipo, la dirección IP y la dirección MAC sean iguales en cada clon, y una interfaz pública donde estos valores sean únicos en cada clon.

Para evitar conflictos de red en 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 solo a las máquinas virtuales 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 mismas 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 los entornos pueden interactuar con los clientes y con otros equipos del laboratorio.

La figura 3 muestra cómo las interfaces privadas y públicas resuelven 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 e introduce 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 Lab Management, junto con un agente instalado en cada máquina virtual, garantiza que el entorno original y el entorno clonado puedan 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 de la red privada se resuelven con NetBIOS y no requieren ningún control adicional por parte del software 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 web-server hace referencia al equipo db-server mediante su nombre. Los nombres son iguales en el entorno original y en el clonado. Por consiguiente, el archivo web.config no tiene que modificarse en el entorno clonado.

Dado que no hay ningún servidor DNS en la red privada, necesitamos abordar la situación en la que las máquinas virtuales usan nombres de dominio completos (FQDN), en lugar de nombres NetBIOS, para hacerse referencia a entre sí. Por ejemplo, si el archivo web.config hiciera referencia a db-server como db-server.lab.contoso.com, la resolución de ese nombre en una dirección IP no sería posible sin el servicio 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 resolver un nombre en una dirección IP concreta. En nuestro ejemplo, el archivo de hosts en web-server tendrá la entrada siguiente:

192.168.23.2 db-server.lab.contoso.com

**Direcciones IP:**una dirección IP estática en 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 de web-server obtiene la dirección 192.168.23.1 y la interfaz privada de db-server obtiene la dirección 192.168.23.2. Lab Management se asegura de que web-server y db-server tengan las mismas direcciones IP estáticas en cada clon. Por consiguiente, incluso si el archivo web.config de web-server se configura con la dirección IP de db-server, no es necesario configurarlo de nuevo en el entorno clonado. En cualquier entorno configurado con aislamiento de red, las interfaces privadas obtienen las direcciones IP de este mismo intervalo, a partir de 192.168.23.1. El número máximo de direcciones necesarias en este 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, resulta seguro utilizar un intervalo predefinido mientras no se utilice el mismo intervalo en la red pública.

**Direcciones MAC:**se asigna una dirección MAC estática aleatoria a la interfaz de red privada de cada máquina virtual en un entorno con aislamiento de red. En el ejemplo, se asigna una dirección MAC a la interfaz privada de web-server original, por ejemplo 00-15-5D-07-57-01. Lab Management se asegura de que web-server también obtenga 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, resulta seguro utilizar una dirección aleatoria mientras no esté 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 que NetBIOS resuelva los nombres de equipo de la red pública, porque esto 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. De forma similar a NetBIOS, no queremos que las máquinas virtuales registren sus nombres de equipo NetBIOS en DNS. Lab Management también deshabilita el registro DNS para cada interfaz pública. En ausencia de NetBIOS y del registro DNS predeterminado, todavía queremos que las máquinas virtuales tengan nombres únicos que se puedan utilizar en la red pública. Lab Management genera un nombre de alias único en nombre de cada máquina virtual y lo registra como un registro “A” en DNS. En el ejemplo, el equipo web-server del entorno original podría registrarse mediante un nombre de alias único que se parezca a VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com. El mismo web-server se registra en el entorno clonado con un nombre diferente que podría parecerse a VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com.

**Direcciones IP:**la interfaz de red pública de cada máquina virtual se configura para obtener la dirección IP dinámica desde un servidor DHCP. Esto garantiza que las máquinas virtuales del entorno original y del clonado tengan direcciones IP únicas. Por ejemplo, el equipo web-server del entorno original podría obtener una dirección IP de 172.52.20.140 y el mismo web-server del entorno clonado podría obtener una dirección IP de 172.52.20.205.

**Direcciones MAC:**para evitar conflictos de MAC, podría configurarse la interfaz de la red pública de cada máquina virtual para obtener las direcciones MAC dinámicas desde el hipervisor. Esto aseguraría que el equipo web-server del ejemplo obtenga una dirección MAC diferente en el entorno original y en el clonado. Sin embargo, como se describió 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 en la instantánea de compilación más reciente, la dirección IP de web-server se convierte en 10.86.51.61 (vea la figura 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 DHCP la renueva, el conflicto de MAC existe hasta que las maquinas virtuales se reinician. Debido a esta limitación, el uso de 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. Cada vez que el entorno clonado se restaura 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 de web-server en el entorno original es 1D-D8-B7-1C-00-05 y que la dirección MAC de web-server 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 de web-server 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 red.

Interacciones típicas con el aislamiento de red

A continuación, describiremos lo que ocurre cuando dos máquinas virtuales del entorno se comunican entre sí:

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

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

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

1. El cliente consulta el software Lab Management para obtener el nombre de alias único de web-server en el entorno clonado.

2. El software Lab Management responde con el nombre de alias único.

3. El servidor DNS resuelve el nombre de alias único en la dirección IP de la interfaz pública de web-server (10.86.51.63).

4. El cliente se comunica con web-server en esta dirección IP.

Enfoques alternativos para el aislamiento de red

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

Para realizar el aislamiento de red mediante este enfoque, debe introducirse un servidor NAT bidireccional en el entorno. Esto se hace normalmente agregando al entorno una máquina virtual especial que simplemente cumple el rol de servidor NAT bidireccional. Cuando se crea un entorno con aislamiento de red, las direcciones IP públicas y privadas de las máquinas virtuales se asignan de la misma forma que en el enfoque de dos interfaces. 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í mediante un enfoque de NAT bidireccional son exactamente los mismos que en el enfoque de dos interfaces:

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

2. El equipo web-server 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 web-server 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 de alias único de web-server en el entorno clonado. (Visual Studio Lab Management no implementa el enfoque NAT).

2. El software Lab Management responde con el nombre de alias único.

3. El servidor DNS resuelve el nombre de alias único en la dirección IP pública de web-server (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 supone que se está comunicando con web-server.

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 de web-server.

La ventaja de este enfoque sobre el enfoque de dos interfaces consiste en que no es necesario modificar las máquinas virtuales del entorno 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 podría causar interrupciones en algunas aplicaciones.

Otra ventaja de este enfoque radica en 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 adicional también proporciona un punto de control adicional para admitir características más avanzadas de aislamiento de red tales como:

• **Barrera solo hacia fuera:**no permite que los paquetes de red iniciados por los clientes fuera del entorno lleguen a las máquinas virtuales del entorno.

• **Solo hacia fuera con excepciones de puerto específicas:**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 si se introduce un firewall en el servidor NAT. El principal inconveniente del enfoque NAT bidireccional consiste en que algunas aplicaciones no funcionan a través de NAT. Por ejemplo, DCOM y los protocolos de .NET Remoting, que normalmente se utilizan en las aplicaciones Windows, no funcionan cuando el cliente y el servidor están separados por un servidor NAT. Por este motivo, Visual Studio Lab Management utiliza el enfoque de interfaces duales. Otra desventaja del enfoque NAT bidireccional consiste en que requiere una máquina virtual adicional en cada entorno, lo que introduce una sobrecarga adicional durante la operación de creación u otras operaciones en entornos virtuales.

Otros conflictos

Hasta ahora, hemos descrito cómo pueden resolverse los conflictos de nombre de equipo y de direcciones IP y MAC a través del 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 se clona dicho entorno. En esta sección, veremos dos casos comunes, donde pueden ocurrir tales conflictos.

Conflictos de Active Directory

Es habitual que los equipos y las aplicaciones Windows confíen en Active Directory (AD), ya sea para los servicios de directorio o 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 los equipos web-server y db-server del entorno original se unen a un dominio administrado por AD. AD está hospedado fuera del entorno. Cuando clonamos el entorno, tenemos dos clones idénticos de web-server; sin embargo, solo hay una entrada en AD. Esto claramente no se desea y puede provocar algunos problemas. Por ejemplo, si uno de clones de web-server se desune del dominio por una acción del usuario, el otro clon también se desune. Los cambios realizados en un entorno afectan involuntariamente al otro entorno.

Para evitar los conflictos de Active Directory, un servidor de AD tiene que estar hospedado 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 AD dentro de un entorno con 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 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 AD. Por ejemplo, una máquina virtual puede no ser capaz unirse al dominio en el AD privado, a menos que los parámetros del servidor DNS estén correctamente configurados en la interfaz privada.

Al configurar un entorno para incluir una máquina virtual de AD, Visual Studio Lab Management desconecta automáticamente AD de la red pública y configura las interfaces privadas de las máquinas virtuales con los parámetros de DNS.

Puede haber situaciones en las que no es posible hospedar 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 base de datos

Otro uso frecuente de los entornos virtuales implica hospedar 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 hospedada 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 los entornos virtuales es esencial para varios escenarios de administración del laboratorio virtual. Sin embargo, al crear clones idénticos, surgen conflictos de nombres de equipo y de direcciones IP y MAC. Algunas técnicas simples, tales como cambiar los nombres de equipo o las direcciones IP, para resolver estos conflictos normalmente requieren la reconfiguración o reinstalación de la aplicación y contradicen por completo lo que se pretende al crear clones idénticos. El aislamiento de red puede resolver este problema, ya que permite crear y ejecutar dos clones simultáneamente.

Pasos siguientes

**Planificar el entorno de SCVMM:**conozca cuándo usar las diferentes opciones para los entornos de SCVMM, como el uso de máquinas virtuales en ejecución, máquinas virtuales almacenadas, plantillas, entornos almacenados y aislamiento de red. Vea Guía para crear y administrar entornos SCVMM.

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

Vea también

Conceptos

Automatizar pruebas del sistema