Recuperación ante desastres de Azure Virtual Desktop

  • Artículo

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

Perfiles de usuario

Se recomienda usar FSLogix para administrar perfiles de usuario. Para obtener más información, consulte Continuidad empresarial y opciones de recuperación ante desastres para FSLogix.

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:

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.