Recuperación ante desastres de Azure Virtual Desktop

Para mantener la seguridad de los datos de su organización, debería adoptar y administrar una estrategia de continuidad empresarial y recuperación ante desastres (BCDR). Una estrategia de BCDR adecuada mantiene las aplicaciones y cargas de trabajo en ejecución durante las interrupciones del servicio o de Azure, sean planeadas o no. Estos planes deben abarcar las máquinas virtuales (VM) del host de sesión administradas por los clientes, en lugar del servicio Azure Virtual Desktop administrado por Microsoft. Para más información sobre las áreas de administración, consulte Conceptos de recuperación ante desastres de Azure Virtual Desktop.

El servicio Azure Virtual Desktop está diseñado teniendo en cuenta la alta disponibilidad. Azure Virtual Desktop es un servicio global administrado por Microsoft, con varias instancias de sus componentes independientes distribuidos entre varias regiones de Azure. Si hay una interrupción inesperada en cualquiera de los componentes, el tráfico se desviará a una de las instancias restantes, o Microsoft iniciará una conmutación por error completa a una infraestructura redundante en otra región de Azure.

Para asegurarse de que los usuarios todavía pueden conectarse durante una interrupción de la región en las máquinas virtuales del host de sesión, debe diseñar la infraestructura teniendo en cuenta la alta disponibilidad y la recuperación ante desastres. Un plan de recuperación ante desastres habitual incluye la replicación de máquinas virtuales (VM) en una ubicación diferente. Durante las interrupciones, el sitio primario realiza una conmutación por error en las máquinas virtuales replicadas en la ubicación secundaria. Los usuarios podrán seguir accediendo a las aplicaciones desde la ubicación secundaria sin interrupciones. Además de la replicación de las máquinas virtuales, tendrá que mantener las identidades de los usuarios accesibles en la ubicación secundaria. Si utiliza contenedores de perfiles, también tendrá que replicarlos. Por último, asegúrese de que las aplicaciones empresariales que se basan en los datos de la ubicación principal puedan realizar una conmutación por error con el resto de los datos.

En resumen, para mantener a los usuarios conectados durante una interrupción, deberá hacer lo siguiente:

• Replique las máquinas virtuales en una ubicación secundaria.
• Si utiliza contenedores de perfiles, configure la replicación de datos en la ubicación secundaria.
• Asegúrese de que las identidades de los usuarios que configuró en la ubicación principal estén disponibles en la ubicación secundaria. Para garantizar la disponibilidad, asegúrese de que los controladores de dominio de Active Directory estén disponibles en o desde la ubicación secundaria.
• Asegúrese de que las aplicaciones de línea de negocio y los datos de la ubicación principal se conmuten también por error a la ubicación secundaria.

Planes de recuperación ante desastres activo-pasivo y activo-activo

Hay dos tipos diferentes de infraestructura de recuperación ante desastres: activo-pasivo y activo-activo. Cada tipo de infraestructura funciona de forma diferente, así que vamos a ver cuáles son esas diferencias.

Los planes activo-pasivo son cuando se tiene una región con un conjunto de recursos que está activo y otro que está desactivado hasta que sea necesario (pasivo). Si una interrupción o un desastre desconecta la región activa, la organización puede cambiar a la región pasiva si la activa y dirige a todos los usuarios allí.

Otra opción es una implementación activa-activa, donde se usan los dos conjuntos de infraestructura al mismo tiempo. Aunque algunos usuarios pueden verse afectados por interrupciones, el impacto se limita a los usuarios de la región que ha dejado de funcionar. Los usuarios de la otra región que todavía están en línea no se verán afectados, y la recuperación se limita a los usuarios de la región afectada que se vuelven a conectar a la región activa en funcionamiento. Las implementaciones activa-activa pueden adoptar muchas formas, entre las que se incluyen:

• La infraestructura de aprovisionamiento excesivo en cada región para dar cabida a los usuarios afectados en caso de que una de las regiones deje de funcionar. Un posible inconveniente de este método es que el mantenimiento de los recursos adicionales cuesta más.
• Tenga hosts de sesión adicionales en ambas regiones activas, pero desasígnelos cuando no sean necesarios, lo que reduce los costos.
• Aprovisione solo la nueva infraestructura durante la recuperación ante desastres y permita a los usuarios afectados conectarse a los hosts de sesión recién aprovisionados. Este método requiere pruebas periódicas con herramientas de infraestructura como código para que pueda implementar la nueva infraestructura lo antes posible durante un desastre.

Para más información sobre los tipos de planes de recuperación ante desastres que puede usar, consulte Conceptos de recuperación ante desastres de Azure Virtual Desktop.

Identificar qué método funciona mejor para su organización es lo primero que debe hacer antes de empezar. Una vez que tenga su plan en marcha, puede empezar a crear el plan de recuperación.

Replicación de máquina virtual

En primer lugar, debe replicar las máquinas virtuales en la ubicación secundaria. Las opciones para ello dependen de cómo estén configuradas las máquinas virtuales:

• Puede configurar la replicación de todas las máquinas virtuales tanto en grupos de hosts agrupados como en los personales con Azure Site Recovery. Para obtener más información sobre cómo funciona este proceso, consulte Replicación de máquinas virtuales de Azure en otra región de Azure. Sin embargo, si ha agrupado grupos de hosts creados a partir de la misma imagen y no tiene ningún dato de usuario personal almacenado localmente, puede optar por no replicarlos. En su lugar, tiene la opción de compilar las máquinas virtuales con antelación y mantenerlas apagadas. También puede optar por aprovisionar solo nuevas máquinas virtuales en la región secundaria mientras se produce un desastre. Si elige estos métodos, solo tendrá que configurar un grupo de hosts, y sus áreas de trabajo y grupos de aplicaciones relacionados.
• Puede crear un nuevo grupo de hosts en la región de la conmutación por error a la vez que mantiene desactivados todos los recursos de la ubicación de la conmutación por error. Con este método, debe configurar las nuevas áreas de trabajo y los grupos de aplicaciones en la región de la conmutación por error. Luego, puede usar un plan de Azure Site Recovery para activar los grupo de hosts.
• Puede crear un grupo de hosts que las máquinas virtuales compiladas en la región primaria y la de la conmutación por error rellenen mientras se mantienen desactivadas las máquinas virtuales de la región de la conmutación por error. En este caso, solo tendrá que configurar un grupo de hosts, y sus áreas de trabajo y grupos de aplicaciones relacionados. Puede usar un plan de Azure Site Recovery para activar grupos de hosts con este método.

Se recomienda usar Azure Site Recovery para administrar la replicación de máquinas virtuales en otras ubicaciones de Azure, tal y como se describe en Arquitectura de recuperación ante desastres de Azure a Azure. Se recomienda usar especialmente Azure Site Recovery para grupos de hosts personales porque, fieles a su nombre, los grupos de hosts personales tienden a tener algo personal en ellos para sus usuarios. Azure Site Recovery admite SKU basadas en servidor y en cliente.

Si usa Azure Site Recovery, no tendrá que registrar estas máquinas virtuales manualmente. El agente de Azure Virtual Desktop de la máquina virtual secundaria usará automáticamente el token de seguridad más reciente para conectarse a la instancia de servicio más cercana. La máquina virtual (host de sesión) de la ubicación secundaria se convierte automáticamente en parte del grupo de hosts. El usuario final tendrá que volver a conectarse durante el proceso, pero, aparte de eso, no hay ninguna otra operación manual.

Si hay conexiones de usuarios existentes durante la interrupción, para que el administrador pueda iniciar la conmutación por error en la región secundaria, habrá que finalizar las conexiones de los usuarios en la región actual.

Para desconectar usuarios de Azure Virtual Desktop (clásico), ejecute este cmdlet:

Invoke-RdsUserSessionLogoff

Para desconectar usuarios de Azure Virtual Desktop, ejecute este cmdlet:

Remove-AzWvdUserSession

Cuando haya cerrado la sesión de todos los usuarios de la región primaria, podrá realizar la conmutación por error de las máquinas virtuales de la región primaria y permitir que los usuarios se conecten a las máquinas virtuales de la región secundaria.

Virtual network

A continuación, observe la conectividad de red durante la interrupción. Tendrá que asegurarse de haber configurado una red virtual (VNET) en la región secundaria. Si los usuarios necesitan tener acceso a recursos locales, deberá configurar esta red virtual para acceder a ellos. Puede establecer conexiones locales con una VPN, ExpressRoute o Virtual WAN.

Se recomienda usar Azure Site Recovery para configurar la red virtual en la región de la conmutación por error porque conserva la configuración de la red principal sin necesidad de emparejamiento.

Identidades de usuarios

A continuación, asegúrese de que el controlador de dominio esté disponible en la ubicación secundaria.

Hay tres formas de mantener el controlador de dominio disponible:

• Tener uno o varios controladores de dominio de Active Directory en la ubicación secundaria
• Usar un controlador de dominio de Active Directory local
• Replicar el controlador de dominio de Active Directory con Azure Site Recovery

Replicación de datos de perfil de usuario y aplicación

Si utiliza contenedores de perfiles, el paso siguiente consiste en configurar la replicación de datos en la ubicación secundaria.

Tiene cinco opciones para almacenar perfiles de FSLogix:

• Espacios de almacenamiento directo (S2D)
• Unidades de red (máquinas virtuales con unidades adicionales)
• Azure Files
• Azure NetApp Files
• Servicios de almacenamiento de terceros disponibles en Azure Marketplace

Para obtener más información, consulte Opciones de almacenamiento para los contenedores de perfiles de FSLogix de Azure Virtual Desktop.

Si va a configurar la recuperación ante desastres para perfiles de usuario, deberá usar el servicio de almacenamiento para replicar los datos en otra región o utilizar la caché en la nube de FSLogix para administrar la replicación sin usar el servicio de almacenamiento subyacente para replicar los datos.

Veamos las cinco opciones para los planes de recuperación ante desastres del perfil de usuario con más detalle en las secciones siguientes.

Replicación nativa de Azure

Una manera de configurar la recuperación ante desastres es configurar la replicación nativa de Azure. Por ejemplo, puede configurar la replicación nativa de Azure con replicación de la cuenta de Azure Files Standard Storage, replicación de Azure NetApp Files o Azure Files Sync para los servidores de archivos.

Nota

La replicación de NetApp es automática después de configurarla por primera vez. Con los planes de Azure Site Recovery, puede agregar scripts previos y posteriores para conmutar por error aquellos recursos que no sean de máquinas virtuales y que repliquen otros recursos de Azure Storage.

Espacios de almacenamiento directo

Otra opción que puede usar es Espacios de almacenamiento directo. Como Espacios de almacenamiento directo controla la replicación entre regiones internamente, no es necesario configurar la ruta de acceso secundaria de forma manual.

Unidades de red (máquinas virtuales con unidades adicionales)

También puede usar máquinas virtuales con unidades adicionales para la recuperación ante desastres. Si replica las máquinas virtuales del almacenamiento de la red mediante Azure Site Recovery como máquinas virtuales del host de la sesión, la recuperación mantendrá la misma ruta de acceso, por lo que no será necesario volver a configurar FSLogix.

Azure Files

Azure Files admite la replicación asincrónica entre regiones, que se puede especificar al crear la cuenta de almacenamiento. Si la naturaleza asincrónica de Azure Files ya cubre sus objetivos en materia de recuperación ante desastres, no es necesario que aplique ninguna configuración adicional.

Si necesita replicación sincrónica para minimizar la pérdida de datos, se recomienda usar la caché en la nube de FSLogix en su lugar.

Nota

En esta sección no se trata el mecanismo de autenticación de conmutación por error para Azure Files.

Azure NetApp Files

También puede usar Azure NetApp Files para replicar los recursos de Azure. Obtenga más información sobre Azure NetApp Files en Creación de un emparejamiento de replicación para Azure NetApp Files.

Configuración de FSLogix

El agente de FSLogix puede admitir varias ubicaciones de perfil mediante la opción VHDLocations estándar. Este método no tiene nada que ver con la caché en la nube, por lo que si prefiere usar la memoria caché, vaya directamente a Caché en la nube de FSLogix. Esta opción tampoco replica datos, sino que permite acceder a varios proveedores de almacenamiento en los que el agente de FSLogix puede buscar para encontrar o crear el perfil de usuario. Esta opción requiere por separado la replicación de almacenamiento para que el perfil pueda estar disponible en la región secundaria.

Para configurar las entradas del registro:

1. Abra el Editor del Registro.

2. Vaya a Equipo>HKEY_LOCAL_MACHINE>SOFTWARE>FSLogix>Profiles.

   

3. Haga clic con el botón derecho en VHDLocations y seleccione Modificar cadenas múltiples.

   

4. En el campo Información del valor: , escriba las ubicaciones que quiera usar.

5. Cuando finalice, seleccione Aceptar.

Si la primera ubicación no está disponible, el agente de FSLogix realizará una conmutación por error automáticamente en la segunda, y así sucesivamente.

Se recomienda establecer la configuración del registro VHDLocation del agente de FSLogix con ambas ubicaciones de almacenamiento en las dos ubicaciones de Azure en las que las haya implementado. Para configurar la configuración del registro VHDLocation, deberá configurar dos directivas de grupo diferentes. La primera directiva de grupo es para los hosts de sesión ubicados en la región primaria con las ubicaciones de almacenamiento correspondientes ordenadas con la primaria primero y la secundaria después. La segunda directiva de grupo sería para los hosts de sesión en la ubicación secundaria con las opciones de almacenamiento invertidas, de modo que la ubicación de almacenamiento secundaria aparezca primero solo para las máquinas virtuales del sitio secundario o de conmutación por error.

Por ejemplo, supongamos que las máquinas virtuales del host de la sesión principal se encuentran en la región Centro de EE. UU., y su contenedor de perfiles está también en la región Oeste de EE. UU. por motivos de rendimiento. En este caso, deberá configurar el agente de FSLogix con una ruta de acceso al almacenamiento en la región Centro de EE. UU. enumerada en primer lugar. A continuación, configuraría el servicio de almacenamiento que ha utilizado en el ejemplo anterior para replicar en la región Oeste de EE. UU. Una vez que se produzca un error en la ruta de acceso a Centro de EE. UU., el agente intentará cargar el perfil en Oeste de EE. UU.

VHDLocations

VHDLocations contribuye a la continuidad empresarial, pero esta configuración no solo se ha diseñado para formar parte de una solución completa de alta disponibilidad o de recuperación ante desastres. La configuración VHDLocations permite a los usuarios usar un perfil replicado o nuevo en caso de desastre, manteniendo a los usuarios productivos incluso en caso de interrupción.

Este es el funcionamiento de VHDLocations, así como algunas cosas que debe tener en cuenta si tiene previsto crear VHDLocations como parte de la estrategia de recuperación ante desastres:

• Si el almacenamiento principal no está disponible por el motivo que sea, y un usuario inicia sesión, el agente de FSLogix no podrá acceder al perfil de usuario existente desde ese recurso compartido principal. El usuario todavía puede iniciar sesión, pero FSLogix usará el perfil que encuentre en la ubicación de almacenamiento secundaria (si ya lo ha replicado con replicación de almacenamiento) o creará un nuevo perfil en el recurso compartido secundario. Como el usuario ahora utiliza un perfil replicado o nuevo, no usará su perfil original. Cuando usa este perfil secundario, las actualizaciones que realice solo se aplicarán al perfil secundario. No podrá acceder a su perfil original hasta que el almacenamiento principal vuelva a estar disponible e inicie sesión de nuevo.

• Una vez que el almacenamiento principal vuelva a estar disponible, el usuario no podrá combinar los cambios realizados en el perfil secundario o nuevo con el perfil original. Cuando un usuario inicia sesión después de que el recurso compartido principal esté de nuevo disponible, volverá a usar su perfil original tal y como estaba antes del desastre. Se perderán los cambios realizados en el perfil secundario o nuevo durante el desastre.

Caché en la nube de FSLogix

FSLogix admite la replicación de contenedores de usuarios y de Office desde el agente que se ejecuta en el propio host de sesión. Aunque tendrá que implementar varios proveedores de almacenamiento en varias regiones para almacenar los perfiles replicados, no tendrá que configurar las funcionalidades de replicación del servicio de almacenamiento con varias entradas como ha hecho con la configuración de VHDLocations en la sección anterior. Sin embargo, antes de empezar a configurar la caché en la nube de FSLogix, debe tener en cuenta que este método requiere un procesamiento y un espacio de almacenamiento adicionales en el propio host de sesión. Asegúrese de revisar Caché en la nube para crear resistencia y disponibilidad antes de empezar.

Puede configurar la caché en la nube de FSLogix directamente en el registro en función del ejemplo de VHDLocations de la sección anterior. Sin embargo, se recomienda configurar la caché en la nube mediante una directiva de grupo. Para crear o editar un objeto de directiva de grupo, vaya a Configuración del equipo>Plantillas administrativas>FSLogix>Contenedores de perfiles (y Contenedores de Office 365, si es necesario) > Caché en la nube: ubicaciones de caché en la nube. Una vez que haya creado o editado el objeto de directiva, deberá habilitarlo y, después, enumerar todas las ubicaciones del proveedor de almacenamiento en las que desea que FSLogix lo replique, tal como se muestra en la siguiente imagen.

Realización de una copia de seguridad de los datos

También tiene la opción de hacer una copia de seguridad de los datos. Puede elegir uno de los métodos siguientes para realizar copias de seguridad de los datos de Azure Virtual Desktop:

• En el caso de los datos de proceso, se recomienda que solo se realicen copias de seguridad de grupos de hosts personales con Azure Backup.
• Para los datos de Storage, la solución de copia de seguridad que se recomienda varía en función del almacenamiento de back-end que ha utilizado para almacenar perfiles de usuario:
  • Si ha utilizado un recurso compartido de Azure Files, se recomienda usar Azure Backup para el recurso compartido de archivos.
  • Si ha utilizado Azure NetApp Files, se recomienda usar Instantáneas/Directivas o Copia de seguridad de Azure NetApp Files.

Dependencias de aplicaciones

Por último, asegúrese de que las aplicaciones empresariales que se basan en los datos ubicados en la región primaria puedan realizar una conmutación por error en la ubicación secundaria. Además, asegúrese de configurar los valores que las aplicaciones deban usar en la nueva ubicación. Por ejemplo, si una de las aplicaciones depende del back-end de SQL, asegúrese de replicar SQL en la ubicación secundaria. Debe configurar la aplicación para que use la ubicación secundaria como parte del proceso de conmutación por error o como su configuración predeterminada. Puede modelar las dependencias de la aplicación en planes de Azure Site Recovery. Para obtener más información, consulte Acerca de los planes de recuperación.

Pruebas de recuperación ante desastres

Cuando haya terminado de configurar la recuperación ante desastres, conviene que pruebe el plan para asegurarse de que funcione.

Estas son algunas sugerencias sobre cómo probar el plan:

• Si las máquinas virtuales de prueba tienen acceso a Internet, se ocuparán de cualquier host de sesión existente para las nuevas conexiones, pero todas las conexiones existentes en el host de la sesión original permanecerán activas. Asegúrese de que el administrador que ejecute la prueba cierre la sesión de todos los usuarios activos antes de probar el plan.
• Solo debe realizar pruebas de recuperación ante desastres completas durante una ventana de mantenimiento para no interrumpir a los usuarios.
• Asegúrese de que la prueba cubra todas las aplicaciones y datos críticos para la empresa.
• Se recomienda que solo conmute por error un máximo de 100 máquinas virtuales a la vez. Si tiene más máquinas virtuales, le recomendamos que las conmute por error por lotes con una diferencia de 10 minutos.

Pasos siguientes

Si, además de sobre cómo planear las interrupciones, tiene alguna pregunta sobre cómo mantener los datos seguros, consulte nuestra guía de seguridad.