Guía de pruebas de clonación de controladores de dominio virtualizados para proveedores de aplicaciones
En este tema se explica qué proveedores de aplicaciones deben ayudar a garantizar que su aplicación siga funcionando según lo previsto después de que se complete el proceso de clonación del controlador de dominio (DC) virtualizado. Trata los aspectos del proceso de clonación que interesan a los proveedores de aplicaciones y escenarios que pueden garantizar pruebas adicionales. Se recomienda a los proveedores de aplicaciones que hayan validado que su aplicación funciona en controladores de dominio virtualizados que se han clonado que muestren el nombre de la aplicación en el contenido de la comunidad situado en la parte inferior de este tema, junto con un vínculo al sitio web de la organización donde los usuarios puedan obtener más información sobre la validación.
Introducción a la clonación de controladores de dominio virtualizados
El proceso de clonación de controladores de dominio virtualizados se describe en detalle en Introducción a la virtualización de Active Directory Domain Services (AD DS) (nivel 100) y Referencia técnica de controladores de dominio virtualizados (nivel 300). Desde la perspectiva de un proveedor de aplicaciones, estas son algunas consideraciones que se deben tener en cuenta al evaluar el impacto de la clonación en la aplicación:
El equipo original no se destruye. Permanece en la red, interactuando con los clientes. A diferencia de un cambio de nombre en el que se quitan los registros DNS del equipo original, permanecen los registros originales del controlador de dominio de origen.
Durante el proceso de clonación, el nuevo equipo se ejecuta inicialmente durante un breve período de tiempo bajo la identidad del equipo antiguo hasta que se inicia el proceso de clonación y se realizan los cambios necesarios. Las aplicaciones que crean registros sobre el host deben asegurarse de que el equipo clonado no sobrescriba los registros sobre el host original durante el proceso de clonación.
La clonación es una funcionalidad de implementación específica solo para controladores de dominio virtualizados, no una extensión de uso general para clonar otros roles de servidor. Algunos roles de servidor no se admiten específicamente en la clonación:
Protocolo de configuración dinámica de host (DHCP)
Active Directory Certificate Services (AD CS)
Active Directory Lightweight Directory Services (AD LDS)
Como parte del proceso de clonación, se copia toda la máquina virtual que representa el controlador de dominio original, por lo que también se copia cualquier estado de la aplicación de esa máquina virtual. Compruebe que la aplicación se adapta a este cambio en el estado del host local en el controlador de dominio clonado o si se requiere alguna intervención, como un reinicio del servicio.
Como parte de la clonación, el nuevo controlador de dominio obtiene una nueva identidad de máquina y se aprovisiona como un controlador de dominio de réplica en la topología. Compruebe si la aplicación depende de un dato de la identidad de la máquina, como su nombre, cuenta, SID, etc. ¿Se adapta automáticamente al cambio de identidad de máquina en el clon? Si esa aplicación almacena datos en caché, asegúrese de que no se basa en datos de identidad de la máquina que se pueden almacenar en caché.
¿Qué resulta interesante para los proveedores de aplicaciones?
CustomDCCloneAllowList.xml
Un controlador de dominio que ejecuta la aplicación o el servicio no se puede clonar hasta que la aplicación o el servicio:
- Se agreguen al archivo CustomDCCloneAllowList.xml mediante el cmdlet Get-ADDCCloningExcludedApplicationList de Windows PowerShell
-O bien-
- Se eliminen del controlador de dominio
La primera vez que el usuario ejecuta el cmdlet Get-ADDCCloningExcludedApplicationList, este devuelve una lista de servicios y aplicaciones que se ejecutan en el controlador de dominio, pero no están en la lista predeterminada de servicios y aplicaciones compatibles con la clonación. De forma predeterminada, el servicio o la aplicación no aparecerán en la lista. Para agregar el servicio o la aplicación a la lista de aplicaciones y servicios que se pueden clonar de forma segura, el usuario vuelve a ejecutar el cmdlet Get-ADDCCloningExcludedApplicationList con la opción -GenerateXML para agregarlo al archivo CustomDCCloneAllowList.xml. Para más información, consulte Paso 2: Ejecución del cmdlet Get-ADDCCloningExcludedApplicationList.
Interacciones del sistema distribuido
Normalmente, los servicios aislados en el equipo local se ejecutan correctamente o producen un error al participar en la clonación. Los servicios distribuidos deben preocuparse por tener dos instancias del equipo host en la red simultáneamente durante un breve período de tiempo. Esto puede manifestarse como una instancia de servicio que intenta extraer información de un sistema asociado donde el clon se ha registrado como el nuevo proveedor de la identidad. O ambas instancias del servicio pueden insertar información en la base de datos de AD DS al mismo tiempo con resultados diferentes. Por ejemplo, no está determinado con qué equipo se mantendrá la comunicación si dos equipos que tienen el servicio Windows Testing Technologies (WTT) están en la red con el controlador de dominio.
Para el Servicio de nombres de dominio distribuido, el proceso de clonación evita cuidadosamente sobrescribir los registros DNS del controlador de dominio de origen cuando el controlador de dominio clonado se inicia con una nueva dirección IP.
No debe confiar en el equipo para eliminar toda la identidad antigua hasta el final de la clonación. Después de promover el nuevo controlador de dominio dentro del nuevo contexto, seleccione proveedores de Sysprep para limpiar el estado adicional del equipo. Por ejemplo, en este momento se eliminan los certificados antiguos del equipo y se cambian los secretos de criptografía a los que puede acceder el equipo.
El mayor factor que varía el tiempo de la clonación es el número de objetos que hay que replicar desde el controlador de dominio principal (PDC). Los elementos multimedia más antiguos aumentan el tiempo necesario para completar la clonación.
Como el servicio o la aplicación son desconocidos, se deja en ejecución. El proceso de clonación no cambia el estado de los servicios que no son de Windows.
Además, el nuevo equipo tiene una dirección IP diferente a la del equipo original. Estos comportamientos pueden causar efectos secundarios en el servicio o la aplicación en función de cómo se comporten en este entorno.
Escenarios adicionales sugeridos para las pruebas
Error de clonación
Los proveedores de servicios deben probar este escenario porque cuando se produce un error en la clonación, el equipo arranca en modo de reparación de servicios de directorio (DSRM), una forma de modo seguro. En este momento, el equipo no ha completado la clonación. Puede que algunos estados hayan cambiado y otros sigan igual en el controlador de dominio original. Pruebe este escenario para comprender qué impacto puede tener en la aplicación.
Para inducir un error de clonación, intente clonar un controlador de dominio sin concederle permiso para clonarse. En este caso, el equipo solo habrá cambiado las direcciones IP y seguirá teniendo la mayoría de su estado en el controlador de dominio original. Para más información sobre cómo conceder a un controlador de dominio permiso para clonarse, consulte Paso 1: Conceder al controlador de dominio virtualizado de origen el permiso para clonarse.
Clonación del emulador del PDC
Los proveedores de servicios y aplicaciones deben probar este escenario porque hay un reinicio adicional cuando se clona el emulador del PDC. Además, la mayoría de la clonación se realiza bajo una identidad temporal para permitir que el nuevo clon interactúe con el emulador del PDC durante el proceso de clonación.
Controladores de dominio en los que se puede escribir en comparación con los de solo lectura
Los proveedores de servicios y aplicaciones deben probar la clonación usando el mismo tipo de controlador de dominio (es decir, en un controlador de dominio en el que se puede escribir o en uno de solo lectura) en el que se planea ejecutar el servicio.