Consideraciones sobre continuidad empresarial y recuperación ante desastres para Azure Virtual Desktop

Azure Virtual Desktop es un servicio administrado por Microsoft que proporciona un plano de control para el entorno de virtualización del escritorio. Los costos del servicio se incluyen como parte de las licencias elegibles, consulte Precios de Azure Virtual Desktop. Microsoft no ofrece un Acuerdo de Nivel de Servicio (SLA) con respaldo financiero para estos servicios. A pesar de no tener ningún Acuerdo de Nivel de Servicio, intentamos lograr al menos un 99,9 % de disponibilidad para las URL del servicio Azure Virtual Desktop.

Nota:

La disponibilidad de las máquinas virtuales del host de sesión en la suscripción está cubierta por el Acuerdo de Nivel de Servicio de Azure Virtual Machines.

Una estrategia de continuidad empresarial y recuperación ante desastres (BCDR) adecuada mantiene las aplicaciones y cargas de trabajo críticas en ejecución durante las interrupciones del servicio o de Azure, sean planeadas o no. Su estrategia debe tener en cuenta los recursos que se implementan en la suscripción como parte del plano de datos de Azure Virtual Desktop, lo que incluye grupos de hosts y el almacenamiento.

Para garantizar la continuidad empresarial, Azure Virtual Desktop también conserva los metadatos del cliente durante las interrupciones regionales. Si se produce una interrupción, los componentes de la infraestructura del servicio realizan una conmutación por error en la ubicación secundaria y siguen funcionando de forma habitual.

Para obtener más información sobre las consideraciones de BCDR para los recursos de Azure, consulte Recuperación ante desastres de Azure Virtual Desktop.

Consideraciones de diseño

Al diseñar la infraestructura de Azure Virtual Desktop, tenga en cuenta estos factores de diseño.

Grupo de hosts activo-activo en comparación con uno activo-pasivo

En el caso de un grupo de hosts de Azure Virtual Desktop, puede usar un enfoque de continuidad empresarial y recuperación ante desastres activo-activo o activo-pasivo.

Grupo de hosts activo-activo

• Se mitigan las interrupciones del almacenamiento sin necesidad de que el usuario vuelva a autenticarse.
• Habilita pruebas continuas de la ubicación de recuperación ante desastres.
• Un único grupo de hosts puede contener máquinas virtuales de varias regiones. En este escenario, debe usar la caché en la nube para replicar activamente el perfil FSLogix del usuario y los contenedores de oficina entre las regiones.
• En cuanto a las máquinas virtuales (VM) de cada región, invierta la entrada del registro de caché en la nube que especifica ubicaciones para dar prioridad al registro de caché local.
• El equilibrio de carga de las conexiones de usuario entrantes no puede tener en cuenta la proximidad. Todos los hosts son iguales y es posible que los usuarios se dirijan a una máquina virtual remota (y no óptima) del grupo de hosts de Azure Virtual Desktop.
• Esta configuración se limita a un tipo de grupo de hosts agrupado (compartido). Para un tipo personal (dedicado), una vez que un dispositivo de escritorio se asigna a un usuario en una máquina virtual de host de sesión determinada, el escritorio no cambia, incluso si la máquina virtual no está disponible.
• Cloud Cache no mejora la experiencia de inicio de sesión y cierre de sesión de los usuarios cuando se usa un almacenamiento con un rendimiento deficiente. Es habitual que los entornos que usan Cloud Cache tengan tiempos de inicio de sesión y cierre de sesión ligeramente más lentos, en comparación con el uso de ubicaciones de VHD tradicionales, con el mismo almacenamiento. Revise la documentación de FSLogix Cloud Cache para obtener recomendaciones sobre el almacenamiento en caché local.
• La configuración del grupo de hosts activo-activo suele ser compleja. No se considera una optimización del rendimiento ni una optimización de costos.

Grupo de hosts activo-pasivo

• Puede utilizar Azure Site Recovery o un grupo de hosts secundario (espera activa) para mantener un entorno de copia de seguridad.
• Puede usar Site Recovery tanto para el tipo de grupo de hosts personal (dedicado) como para el agrupado (compartido) y puede mantener una única entidad de grupo de hosts.
• Puede crear un nuevo grupo de hosts en la región de la conmutación por error y mantener desactivados todos los recursos. Si aplica este método, configure nuevos grupos de aplicaciones en la región de conmutación por error y asigne usuarios a los grupos. A continuación, puede usar un plan de recuperación en Site Recovery para activar los grupos de hosts y crear un proceso organizado.

Resistencia del grupo de hosts

Para la resistencia de las máquinas virtuales del grupo de hosts, tenga en cuenta estos factores:

• Al crear un nuevo grupo de hosts de Azure Virtual Desktop, puede elegir entre diferentes opciones de disponibilidad.

• Es importante seleccionar la opción adecuada para sus requisitos al crear la máquina virtual. No se pueden cambiar más adelante las opciones de disponibilidad de la máquina virtual.

• Si tiene previsto implementar una instancia de máquina virtual única, el Acuerdo de Nivel de Servicio dependerá del tipo de disco de almacenamiento que use:

  • SSD Premium, Disco Ultra o SSD Premium v2: 99,9 %
  • Managed Disks SSD estándar: 99,5 %
  • Managed Disks HDD estándar: 95 %

• La opción de resistencia predeterminada para la implementación del grupo de hosts de Azure Virtual Desktop es usar un conjunto de disponibilidad.

• Mediante las zonas de disponibilidad, las máquinas virtuales del grupo de hosts se distribuyen entre distintos centros de datos. Las máquinas virtuales permanecen en la misma región y tienen una mayor resistencia y un Acuerdo de Nivel de Servicio formal de alta disponibilidad del 99,99 %. El planeamiento de capacidad debe incluir suficiente capacidad de proceso adicional para asegurarse de que Azure Virtual Desktop sigue funcionando incluso si se pierde una sola zona de disponibilidad.

Sugerencia

• Para comprobar si los recursos se implementan de forma resistente a la zona, consulte Iniciativa de Azure Policy para resistencia de zona.
• Para obtener más información sobre la iniciativa de Azure Policy para la resistencia de zona, consulte AzAdvertizer: los recursos deben ser resistentes a zonas.

• Esta opción permite la resistencia del grupo de hosts solo en el nivel de centro de datos Azure individual. Los conjuntos de disponibilidad de Azure para máquinas virtuales tienen un Acuerdo de Nivel de Servicio formal de alta disponibilidad del 99,95 %.

  Nota

  El número máximo de máquinas virtuales dentro de un conjunto de disponibilidad es de 200, como se documenta en Límites del servicio y la suscripción.

Antes de comenzar el planeamiento y el diseño de BCDR de Azure Virtual Desktop, tenga en cuenta qué aplicaciones a las que se accede a través de este servicio son críticas. Es posible que quiera separarlas de las aplicaciones no críticas para poder aprovisionar varios grupos de hosts con diferentes enfoques y funcionalidades de recuperación ante desastres.

Almacenamiento óptimo para contenedores de perfiles y oficina

La ubicación de almacenamiento que se usa para los contenedores de FSLogix es fundamental para garantizar la latencia más baja de la máquina virtual del grupo de hosts. Si configura la entrada de registro VHDLocations, el agente de FSLogix puede admitir varias ubicaciones de perfil para una resistencia más alta. Puede usar la caché en la nube o asegurarse de que haya un mecanismo de replicación adecuado en función del tipo de almacenamiento utilizado.

Azure ofrece varias soluciones de almacenamiento que puede usar para almacenar el perfil FSLogix y los contenedores de oficina.

• En Opciones de almacenamiento para los contenedores de perfiles de FSLogix de Azure Virtual Desktop se comparan las diferentes soluciones de almacenamiento administrado disponibles.
• Azure Files o Azure NetApp Files para empresas ofrecen el máximo valor a los clientes. Los servicios de Azure simplifican la administración de Azure Virtual Desktop y son las soluciones de almacenamiento preferidas para esta carga de trabajo.
• Los espacios de almacenamiento directo también con compatibles con FSLogix y Azure Virtual Desktop. Se trata de una solución de almacenamiento autoadministrada que está fuera del ámbito de este artículo.

Replicación y resistencia del almacenamiento de datos de usuario

Puede reducir el tiempo necesario para realizar copias de seguridad, restaurar y replicar datos después de una interrupción.

• Separe los discos de perfiles de usuario y de contenedores de oficina. FSLogix ofrece la posibilidad de colocarlos en ubicaciones de almacenamiento independientes.

• No haga que el disco de oficina sea resistente. Con un uso normal, el disco de oficina puede consumir muchos más gigabytes que el disco de perfil. Es una caché de datos que puede descargar de nuevo desde los servicios en línea de Microsoft 365.

• Use OneDrive para redirigir carpetas estándar como Escritorio, Documentos, Imágenes, Imágenes guardadas y Álbum de cámara. El redireccionamiento garantiza la resistencia de estos datos sin necesidad de una consideración especial en un escenario de continuidad empresarial y recuperación ante desastres.

• No incluya datos de caché para el disco de perfil, de modo que pueda realizar copias de seguridad, replicar y restaurar el disco más rápidamente.

  Nota

  La función de la caché en la nube de FSLogix es reescribir por diseño. Este diseño usa replicación asincrónica, lo que aumenta las características de rendimiento a los destinos de latencia alta.

Puede usar varios mecanismos y estrategias de replicación para los datos de usuario en contenedores de FSLogix.

• Patrón de perfil 1: use mecanismos de replicación Azure Storage nativos. Por ejemplo, use el almacenamiento con redundancia geográfica (GRS) para los recursos compartidos de archivos estándar. Puede usar la replicación entre regiones para Azure NetApp Files o usar Azure File Sync para servidores de archivos basados en máquinas virtuales.

• Patrón de perfil 2: la caché en la nube de FSLogix tiene un mecanismo automático integrado para replicar contenedores entre hasta cuatro cuentas de almacenamiento diferentes.

• Patrón de perfil 3: configure la recuperación ante desastres geográfica solo para datos de aplicación y no para contenedores de perfiles o datos de usuario. Almacene datos de aplicación importantes en ubicaciones de almacenamiento independientes, como OneDrive u otra opción de almacenamiento externo que tenga un mecanismo de recuperación ante desastres integrado.

Disponibilidad de imágenes de base

Si usa imágenes personalizadas para implementar máquinas virtuales del grupo de hosts de Azure Virtual Desktop, es importante asegurarse de que esos artefactos están disponibles en todas las regiones si se produce un desastre importante. Use el servicio Azure Compute Gallery para replicar imágenes en todas las regiones donde se implementa un grupo de hosts con almacenamiento redundante y varias copias.

Protección de copia de seguridad

Es importante evitar la pérdida de datos de usuario críticos. Para la protección de copia de seguridad, tenga en cuenta estos factores:

• Evalúe qué datos necesita guardar y proteger. Si usa OneDrive u otra opción de almacenamiento externo, es posible que no tenga que guardar los datos del perfil de usuario o del contenedor de oficina.
• Tenga en cuenta la manera óptima de proteger los datos críticos del usuario.
• Puede usar el servicio Azure Backup para proteger los datos de los contenedores de perfil y oficina cuando se almacenan en el nivel estándar o Premium de Azure Files.
• Puede usar instantáneas y directivas de Azure NetApp Files en todos los niveles.
• Puede usar Azure Backup para proteger las máquinas virtuales de grupo de hosts. Esta práctica se admite incluso si las máquinas virtuales del grupo de hosts no tienen estado.

Dependencias de infraestructura y aplicación

Si los usuarios de Azure Virtual Desktop necesitan acceso a los recursos locales, es fundamental tener en cuenta la alta disponibilidad en la infraestructura de red que es necesaria para conectarse a los recursos. Evalúe la resistencia de la infraestructura de autenticación y tenga en cuenta los aspectos de continuidad empresarial y recuperación ante desastres para las aplicaciones dependientes y otros recursos. Estas consideraciones ayudarán a garantizar la disponibilidad en la ubicación de recuperación ante desastres secundaria.

Ubicaciones de datos para Azure Virtual Desktop

Azure Virtual Desktop almacena varios datos para los objetos de servicio, como el nombre de los de hosts, el nombre de los grupos de aplicaciones, el nombre de las áreas de trabajo y el nombre principal de usuario. Estos se clasifican en diferentes tipos, como la entrada del cliente, los datos de cliente, los datos de diagnóstico y los datos generados por el servicio. Para más información, vea Ubicaciones de datos para Azure Virtual Desktop.

La información almacenada se cifra en reposo y los reflejos con redundancia geográfica se mantienen en la zona geográfica. Los datos generados por el servicio Azure Virtual Desktop se replican en la zona geográfica de Azure con fines de recuperación ante desastres.

La información relacionada con la aplicación o creada por el usuario, como la configuración de la aplicación y los datos de usuario, reside en la región de Azure que elija y no la administra el servicio Azure Virtual Desktop.

Recomendaciones de diseño

Se recomienda incorporar estos procedimientos recomendados al diseño de la infraestructura:

• Para el BCDR modelo de implementación de proceso de grupo de hosts de Azure Virtual Desktop, use la opción activo-pasivo si satisface sus requisitos para el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO).
• Recomendamos Azure Site Recovery para grupos de hosts personales (dedicados). La región de destino debe estar alineada con la recuperación ante desastres del back-end de almacenamiento que usa FSLogix.
• Azure Site Recovery también es compatible con grupos de hosts agrupados (compartidos). Esta opción se puede evaluar y comparar con la implementación de otro grupo de hosts en la región de recuperación ante desastres secundaria.
• Cuando se requiera la resistencia máxima del grupo de hosts en una sola región, use zonas de disponibilidad. Compruebe que la característica de las zonas de disponibilidad está disponible en la región específica. Compruebe que la SKU de máquina virtual específica está disponible en todas las zonas de disponibilidad.

En la mayoría de los escenarios, se recomienda utilizar Azure Files o Azure NetApp Files para almacenar el perfil de usuario FSLogix y los contenedores de oficina.

• Divida el perfil de usuario y los contenedores de oficina.

• Se recomiendan estas opciones para los tipos de almacenamiento en contenedores, en este orden:

  1. Azure Files de nivel Premium
  2. Azure NetApp Files de nivel estándar
  3. Azure NetApp Files de nivel Premium

• El tipo de almacenamiento óptimo depende de los recursos y la latencia que requiere la carga de trabajo.

• Para obtener un rendimiento óptimo, coloque los contenedores de FSLogix en el almacenamiento que está cerca de la máquina virtual a la que se ha conectado el usuario. Es mejor mantener los contenedores en el mismo centro de datos.

• Si es posible, use los mecanismos de replicación integrados de Azure Storage para BCDR en entornos menos críticos.

  • Use almacenamiento con redundancia de zona (ZRS) o GRS para Azure Files.
  • Use el almacenamiento con redundancia local (LRS) con resistencia solo local si no se requiere protección de zona o región.

  Nota

  GRS no está disponible con los niveles Premium o estándar de Azure Files cuando la compatibilidad con archivos grandes está habilitada.

• Use la caché en la nube solo en estas circunstancias:

  • La disponibilidad de los datos del contenedor de oficina o del perfil de usuario requiere alta disponibilidad, o bien un Acuerdo de Nivel de Servicio que debe ser resistente a errores en la región.
  • La opción de almacenamiento seleccionada no puede cumplir los requisitos de BCDR. Por ejemplo, GRS no está disponible con los niveles Premium o estándar de Azure Files si la compatibilidad con archivos grandes está habilitada.
  • Se requiere replicación entre almacenamientos distintos.

• Se recomienda seguir estas instrucciones si usa caché en la nube:

  • Use una unidad de estado sólido (SSD) para el disco administrado de las máquinas virtuales del grupo de hosts de Azure Virtual Desktop.
  • Tenga una solución de copia de seguridad para proteger los contenedores de perfiles de usuario y oficina.
  • Asegúrese de que el disco administrado de la máquina virtual local sea lo suficientemente grande como para alojar la caché local de todos los perfiles FSLogix y contenedores de oficina.

• Use Azure Compute Gallery para replicar imágenes de base en distintas regiones.

  • Las imágenes base no participan a la hora de proporcionar a los usuarios la capacidad de conectarse a su máquina virtual de host de sesión. Sin embargo, desempeñan un papel fundamental en la rapidez con la que puede ejecutar el proceso de aprovisionamiento de nuevas máquinas virtuales en un grupo de hosts y, por tanto, se debe hacer una copia de seguridad de ellas y tenerla disponible.
  • Use ZRS para crear la imagen. Mantenga al menos dos copias de la imagen por región.

• Use Azure Backup para proteger los datos de usuario críticos contra la pérdida de datos o daños lógicos al usar los niveles estándar o Premium de Azure Files.

  • Use instantáneas y directivas al usar el servicio de Azure NetApp Files.
  • Se recomienda no usar Azure Backup para guardar el estado de la máquina virtual en el host, incluso si se admite la opción. La máquina virtual que se guarda en el grupo de hosts debe ser sin estado.

• Revise con detenimiento la resistencia y los planes de BCDR para los recursos dependientes. Estos recursos incluyen redes, autenticación, aplicaciones y otros servicios internos en Azure o en su entorno local.

  • La infraestructura de red, como parte de una arquitectura radial o como una arquitectura de red de área amplia virtual (WAN virtual), debe estar disponible en la región secundaria.
  • La conectividad híbrida debe tener alta disponibilidad tanto en la región primaria como en la secundaria.
  • La autenticación de Active Directory debe estar disponible en la región de recuperación ante desastres o se debe garantizar la conectividad con el dominio local.

Pasos siguientes

• Revise con detenimiento la resistencia y los planes de BCDR para los recursos dependientes. Estos recursos incluyen redes, autenticación, aplicaciones y otros servicios internos en Azure o en el entorno local.

  • La infraestructura de red, como parte de una arquitectura radial o de red de área extensa virtual (WAN), debe estar disponible en la región secundaria.
  • La conectividad híbrida debe tener alta disponibilidad en las regiones primaria y secundaria.
  • La autenticación de Active Directory debe estar disponible en la región de recuperación ante desastres o se debe garantizar la conectividad con el dominio local.

• Aprenda sobre la seguridad, la gobernanza y el cumplimiento en un escenario de escala empresarial de Azure Virtual Desktop.

  Seguridad, gobernanza y cumplimiento