Identificar el escenario adecuado de recuperación ante desastres
Para ayudar a limitar el impacto causado por un error en un centro de datos o por una interrupción regional, la organización debe planificar una adecuada protección de recuperación ante desastres. La configuración para llevar a cabo una adecuada estrategia de protección, depende principalmente de cuál de los diferentes escenarios de error podría afectar la funcionalidad de su Azure Virtual Desktop.
Objetivos y métricas
El proceso de recuperación ante desastres requiere coordinación entre cada uno de los procedimientos que se llevan a cabo para que una organización vuelva a estar operativa completamente. Lo que une a estos procedimientos de forma colectiva es la presencia de objetivos a nivel de servicio comunes y claramente definidos. Los servicios de recuperación ante desastres (DR) deben incluir las siguientes métricas:
- Objetivo de punto de recuperación (RPO): la cantidad mínima de datos permitida que debe volver a los clientes para el servicio y que se basa en los activos respaldados que se consideran recuperados. Esta cantidad también podría considerarse como la pérdida de datos máxima aceptable, expresada como un porcentaje que se resta de 100.
- Objetivo de tiempo de recuperación (RTO): el período máximo de tiempo permitido para que se lleve a cabo un proceso de restauración, que también se podría considerar como la cantidad de tiempo de inactividad que la organización se puede permitir.
- Período de retención: el período máximo de tiempo permitido para que un conjunto de copias de seguridad se guarde antes de que sea necesario actualizarlo y reemplazarlo.
El RPO y el RTO pueden percibirse como equilibrados entre sí, de modo que un cliente puede decidir permitir tiempos de recuperación más largos para lograr puntos de recuperación más altos. Si el tiempo de recuperación es un problema para un cliente debido al ancho de banda disponible o al riesgo de tiempo de inactividad, es posible que ese cliente no pueda lograr un RPO alto.
El resto de la unidad explorará tres escenarios de error diferentes y cómo planificar la continuidad empresarial y los BCDR para Azure Virtual Desktop:
- Escenario 1: daños locales de datos, metadatos y recursos
- Escenario 2: fallo de un solo centro de datos de la zona de disponibilidad dentro de una región de Azure
- Escenario 3: interrupción en la región de Azure
Nota:
Para obtener más información sobre cómo proteger componentes individuales de Azure Virtual Desktop, consulte la sección "Más información" en la unidad de resumen de este módulo.
Escenario 1: daños locales de datos, metadatos y recursos
Supongamos que el entorno de Azure Virtual Desktop se ve afectado por un error del host de sesión o un daño del perfil de FSLogix. En tales situaciones, el método de recuperación más común es restaurar los perfiles a partir de una copia de seguridad o recompilar el host de sesión. En esta unidad se revisa cómo se aplica cada uno de estos métodos a cada componente de entorno de Azure Virtual Desktop.
Servicio de Azure Virtual Desktop
El servicio de Azure Virtual Desktop seguirá siendo totalmente funcional y no se verá afectado por estos tipos de errores. Microsoft se hace responsable de que todo esté en funcionamiento nuevamente según el acuerdo a nivel de servicio (SLA) que se ha proporcionado.
AD DS y Microsoft Entra Domain Services
Los controladores de dominio de Active Directory son componentes fundamentales de Azure Virtual Desktop y siempre deben permanecer accesibles. Para asegurarse de que el error no afecta a la funcionalidad, asegúrese de haber creado varios controladores de dominio. Si tiene controladores de dominio en Azure Virtual Machines, asegúrese de que los ha configurado para que estén en el mismo conjunto de disponibilidad. Si los controladores de dominio se ejecutan como equipos locales, debe diseñar la conectividad entre la red local y la red virtual de Azure mediante redundancia. Use Azure ExpressRoute para administrar rutas de acceso y conexiones redundantes. Realice una copia de seguridad del estado del sistema de Active Directory y restáurelo si es necesario. Si usa Microsoft Entra Domain Services, Microsoft es responsable de mantener controladores de dominio redundantes y ayudarles a protegerlos de errores no planeados.
Grupo de hosts
Los grupos de hosts podrían dejar de estar disponibles en el curso normal de funcionamiento. Los grupos de hosts entregan aplicaciones y escritorios virtuales de Azure a los usuarios. Se configuran a partir de la imagen de escritorio, por lo que si se produce un error y hay una imagen de escritorio disponible, puede volver a crearlos. Puede usar un grupo de hosts independiente para las aplicaciones que se consumen a través de Azure Virtual Desktop. También debería considerar un enfoque similar de recuperación ante desastres para este grupo de hosts.
Redes virtuales
Las redes virtuales son servicios administrados y no se ven afectadas por este tipo de errores. Azure Virtual Network proporciona un bloque de direcciones IP privadas en el que puede implementar todos los recursos para la conectividad privada y, a continuación, proteger esos recursos dentro de un límite. Por lo tanto, una red virtual nunca dejará de funcionar ni experimentará una interrupción en caso de que ocurra un error local del recurso en un centro de datos único.
Perfiles de FSLogix y conexión de aplicaciones MSIX
En función de la tecnología de almacenamiento de FSLogix que elija, puede configurar Azure Backup para recursos compartidos de Azure Files e instantáneas de Azure NetApp Files. Como alternativa, puede usar el servicio de copia de seguridad para proteger archivos y carpetas en máquinas virtuales del servidor.
Imágenes
A menudo, puede realizar cambios en las imágenes de escritorio durante el curso normal del mantenimiento del entorno de Azure Virtual Desktop. Debe mantener copias de seguridad de imágenes para que pueda recuperarlas rápidamente en caso de daños.
Escenario 2: fallo de un solo centro de datos de la zona de disponibilidad dentro de una región de Azure
Una región de Azure es un conjunto de centros de datos que se implementan dentro de un perímetro definido por latencia y que están conectados a través de una red regional dedicada de baja latencia. En caso de una interrupción de un centro de datos o una zona en una región de Azure, el BCDR de Azure Virtual Desktop debe incluir las recomendaciones que se enumeran en las secciones siguientes.
Servicio de Azure Virtual Desktop
El servicio de Azure Virtual Desktop seguirá siendo totalmente funcional y no se verá afectado por este tipo de error. Microsoft es responsable de hacer que todo esté de nuevo en funcionamiento en función al Contrato de nivel de servicio (SLA) proporcionado.
AD DS y Microsoft Entra Domain Services
Para evitar un único error en un centro de datos, implemente al menos dos controladores de dominio en una zona de disponibilidad. Si usa Microsoft Entra Domain Services, Microsoft administra los dos controladores de dominio del inquilino en una zona de disponibilidad independiente, si es compatible con la región.
Grupo de hosts
Para la resistencia de las máquinas virtuales del grupo de hosts, puede implementar un grupo de hosts de Azure Virtual Desktop mediante zonas de disponibilidad para máquinas virtuales. Puede distribuir máquinas virtuales en el grupo de hosts entre distintos centros de datos que todavía están dentro de la misma región.
Red virtual
Las redes virtuales son servicios administrados y no se ven afectadas por este tipo de error. Debe asegurarse de que los recursos confiables siempre estén configurados con la conectividad de red adecuada. Por ejemplo, el uso de un equilibrador de carga básico podría verse afectado por este tipo de error, ya que no admite la disponibilidad de zonas.
Perfiles de FSLogix y conexión de aplicaciones MSIX
Use Azure Files con almacenamiento con redundancia de zona Premium para aprovechar la compatibilidad con las zonas de disponibilidad. En este escenario, los perfiles de FSLogix y los VHD de conexión de aplicaciones MSIX permanecen disponibles si se produce una interrupción del centro de datos.
Imágenes
Este tipo de error no afecta a las imágenes porque están disponibles en otra zona.
Escenario 3: interrupción en la región de Azure
El error de las regiones completas de Azure es muy poco probable y poco frecuente. Pero también debe estar preparado en caso de que se produzca un error de este tipo. Considere la posibilidad de aplicar las siguientes recomendaciones para implementar BCDR para Azure Virtual Desktop.
Servicio de Azure Virtual Desktop
El servicio de Azure Virtual Desktop seguirá siendo totalmente funcional y no se verá afectado por este tipo de error. Microsoft es responsable de hacer que todo esté de nuevo en funcionamiento en función al Contrato de nivel de servicio (SLA) proporcionado.
AD DS y Microsoft Entra Domain Services
Para prepararse para este tipo de error, puede expandir un dominio administrado para tener más de un conjunto de réplicas por inquilino de Microsoft Entra. Los conjuntos de réplicas se pueden agregar a cualquier red virtual emparejada en cualquier región de Azure que admita Microsoft Entra Domain Services.
Si usa controladores de dominio locales, debe configurar la conectividad con la red virtual de la nueva región mediante una VPN, ExpressRoute o una red de área extensa virtual (VIRTUAL WAN). Si usa Microsoft Entra Domain Services, puede crear un conjunto de réplicas adicional en otra región. La red virtual de la región adicional que hospeda el nuevo conjunto de réplicas debe poder comunicarse con la red que hospeda el conjunto principal de Microsoft Entra Domain Services. Se recomienda usar el emparejamiento entre redes virtuales para la replicación dentro de sitios entre conjuntos de réplicas.
Grupo de hosts
Puede implementar un grupo de hosts de Azure Virtual Desktop en configuraciones activas yactivas y pasivas :
Activo-activo: la configuración de tipo activo-activo permite que un único grupo de hosts tenga máquinas virtuales de varias regiones. Debe combinar las características de caché en la nube para replicar activamente el perfil de FSLogix de un usuario en el almacenamiento de varias regiones. Para la asociación de aplicaciones MSIX, use otra copia en un recurso compartido de archivos adicional en la otra región. Las máquinas virtuales de cada región deben contener el registro de caché en la nube para especificar las ubicaciones. Además, debe configurar las directivas de grupo para dar prioridad a la ubicación de almacenamiento local. Esta implementación de Azure Virtual Desktop proporciona la máxima eficacia desde la perspectiva del usuario. Esto se debe a que si se produce un error, los usuarios de la región restante pueden seguir usando el servicio sin tener que volver a iniciar sesión. Sin embargo, esta configuración es más costosa y compleja de implementar y no está optimizada para el rendimiento.
Activo-pasivo: en el caso de la configuración de tipo activo-pasivo, puede usar Azure Site Recovery para replicar las máquinas virtuales de la región secundaria mediante los controladores de dominio. Si usa Azure Site Recovery, no tendrá que registrar estas máquinas virtuales manualmente. En su lugar, el agente de Azure Virtual Desktop en la máquina virtual secundaria usa automáticamente el token de seguridad más reciente para conectarse a la instancia de servicio más cercana. Esto garantiza que el host de sesión se una automáticamente al grupo de hosts y que el usuario solo necesita volver a conectarse para acceder a sus máquinas virtuales. Para esta configuración, también puede crear un grupo de hosts secundario (conocido como espera activa) en la región de conmutación por error con todos los recursos desactivados. A continuación, puede usar un plan de recuperación en Azure Site Recovery para activar los grupos de hosts y crear un proceso organizado. También debe crear un nuevo grupo de aplicaciones en la región de conmutación por error y asignarles usuarios.
Redes virtuales
Los errores de región afectan a las redes virtuales y a los servicios implementados en dichas redes. Debe planear una red virtual en la región secundaria. Puede crear una red virtual manualmente y, a continuación, configurarla con emparejamiento con la red principal. También puede usar Azure Site Recovery para configurar la red virtual en la región de conmutación por error y conservar la configuración de su red principal.
En una Azure Virtual Desktop conectada a la red local, debe configurar la red virtual en la región secundaria con conectividad a la red local.
Perfiles de FSLogix y conexión de aplicaciones MSIX
Puede usar Azure NetApp Files como opción de almacenamiento para los perfiles de FSXlogix y la conexión de aplicaciones MSIX, ya que admiten la replicación entre regiones. Azure Files con rendimiento estándar también admiten la replicación entre regiones. Puede configurar el agente de FSLogix para admitir varias ubicaciones de perfil, lo que ayuda a garantizar la disponibilidad si se produce un error. Si se produce un error en la ubicación principal, el agente de FSLogix se replica como parte de la máquina virtual Azure Site Recovery. El agente intenta usar automáticamente la ruta de acceso del perfil que apunta a la región secundaria.
Para el escenario activo-activo y si el RTO o RTA es inferior a un día, se recomienda usar perfiles de FSLogix para usar Cloud Cache. Cloud Cache es una característica de FSLogix que se debe habilitar y configurar de forma específica. Permite usar varias ubicaciones remotas que se actualizan continuamente durante la sesión de usuario.
Imágenes
Debe replicar imágenes en la región secundaria después de cada modificación de la imagen de escritorio principal. Puede usar una galería de Proceso de Azure para compartir imágenes personalizadas entre regiones. Durante un error en la región primaria, puede usar imágenes de escritorio clonadas como orígenes para la creación de los grupos de hosts.
Dependencias de aplicación
Las aplicaciones que dependen de los recursos disponibles en la región primaria requieren los mismos recursos en la ubicación secundaria. Por ejemplo, si algunas de las aplicaciones están conectadas con el back end de SQL que se implementa en una región, asegúrese de replicar el SQL en la ubicación secundaria. Para SQL Server en Azure Virtual Machines, puede usar Azure Site Recovery. Para SQL como plataforma de servicio PaaS, puede usar la replicación geográfica activa o los grupos de conmutación por error automáticos. Debe incluir estos recursos en el plan general de BCDR. Adicionalmente, debe incluir un plan de Azure Site Recovery que pueda modelar las dependencias de la aplicación en el plan de protección.