Manual de Azure Virtual Desktop - Recuperación Ante Desastres

Manual de Azure Virtual Desktop: 2
Recuperación ante desastres
3/ 24 /
Introducción Prueba de recuperación
ante desastres
3 Información general de Azure Virtual Desktop
6 Introducción a la recuperación ante desastres
para Azure Virtual Desktop
25 /
9/ Optimizaciones y procedimientos
Configuración de la recuperación recomendados
ante desastres en Azure Virtual
Desktop
9 Red virtual 28 /
10 Máquinas virtuales Conclusión y recursos
14 Administración de las identidades de los usuarios
15 Configuración de datos de usuarios
y de aplicaciones
Introducción
A medida que avanza en su recorrido de habilitación del trabajo remoto para su organización
con Azure Virtual Desktop, es importante comprender las capacidades de recuperación ante
desastres y los procedimientos recomendados para reforzar la confiabilidad en todas las regiones
y proporcionar una buena experiencia de usuario.
En este manual se proporcionarán consideraciones sobre los requisitos previos de continuidad

del negocio y recuperación ante desastres (BCDR), los pasos de implementación y los
procedimientos recomendados. Esto le permitirá preparar un plan de BCDR exitoso, que le ayudará
a brindar más resiliencia a su negocio durante el tiempo de inactividad y las interrupciones. Si tiene
alguna pregunta sobre los requisitos técnicos o desea obtener asesoramiento sobre soluciones
a corto y largo plazo para habilitar el trabajo remoto, puede hablar con un especialista en ventas
de Azure.
Información general de Azure Virtual Desktop

Azure Virtual Desktop es un completo servicio de virtualización de escritorios y aplicaciones que
se ejecuta en Microsoft Azure y que ayuda a permitir una experiencia de escritorio remoto segura
desde cualquier lugar, lo que ayuda a las organizaciones a fortalecer la resiliencia empresarial. Ofrece
administración simplificada, varias sesiones de Windows 10 Enterprise, optimizaciones para Aplicaciones
Microsoft 365 para empresas y soporte para la migración de entornos de Servicios de escritorio
remoto (RDS). Azure Virtual Desktop también le permite implementar y escalar sus escritorios
y aplicaciones de Windows en Azure en cuestión de minutos, proporcionando así características
de seguridad y cumplimiento integradas para ayudarlo a mantener seguros sus datos y aplicaciones.
Como plataforma flexible de VDI en la nube, Microsoft administra muchas partes de la solución
relacionadas con la estructura en su nombre. Usted o un socio administran otras partes,
principalmente relacionadas con las cargas de trabajo de escritorio y de aplicaciones.
En la figura 1 se muestran los componentes agrupados en cuatro cubículos diferentes. Microsoft administra
los cubículos Servicio de Azure Virtual Desktop e Infraestructura de Azure. Usted administra los
cubículos Aplicaciones de escritorio y remotas y Administración y directivas, lo que le proporciona
la flexibilidad total de estar en control de los servidores host de sesión y los entornos de aplicaciones.
Figura 1: Componente y responsabilidades de Azure Virtual Desktop
Los componentes de back-end de la aplicación están en la red local. ExpressRoute extiende la red
local a la nube de Azure. Opcionalmente, los componentes de back-end también se pueden migrar
a Azure, en función de un escenario de migración de centro de datos. Los componentes de Azure AD
Connect sincronizan las identidades de Active Directory Domain Services (AD DS) o de Azure
Active Directory Domain Services (Azure AD DS) con Azure AD. Usted administra AD DS y
Azure AD, las suscripciones de Azure, las redes virtuales (VNets), Azure Files o Azure NetApp
Files, y los grupos de hosts y áreas de trabajo de Azure Virtual Desktop. En la figura 2 se muestra una
configuración arquitectónica típica para Azure Virtual Desktop.
Figura 2: Configuración de arquitectura típica de Azure Virtual Desktop
La arquitectura del servicio de Azure Virtual Desktop es similar a la de los RDS de Windows Server.
Sin embargo, con Azure Virtual Desktop, Microsoft administra la infraestructura y los componentes
de intermediación, mientras que usted administra sus propias máquinas virtuales (VM), datos
y clientes de host de escritorio. Esto le permite cambiar su enfoque hacia lo que realmente
le importa: la experiencia del usuario. Para entender las diferencias entre RDS locales, la migración
a Azure y la migración a Azure Virtual Desktop, eche un vistazo a la Tabla 1.
Responsabilidad RDS locales RDS en Azure Azure Virtual Desktop
Identidad
Dispositivos de usuario final

(móviles y PC)
Seguridad de aplicaciones
Funcionamiento de host de la sesión
Configuración de implementación
Controles de red
Plano de control de virtualización
Hosts físicos
Red física
Centro de datos físico
Cliente Microsoft
Tabla 1: Responsabilidades de RDS locales, RDS en Azure y Azure Virtual Desktop
Para obtener más información sobre Azure Virtual Desktop para la empresa, visite esta página.
Introducción a la recuperación ante desastres

para Azure Virtual Desktop
Para reforzar la disponibilidad de Azure Virtual Desktop de su organización y mantener los datos
seguros, debe implementar una estrategia de BCDR. Una buena estrategia de BCDR mantiene las
aplicaciones y cargas de trabajo en funcionamiento durante el servicio planeado y no planeado
o durante las interrupciones de Azure. En la figura 3 se muestra el objetivo de punto de
recuperación (RPO) como la pérdida de datos y el objetivo de tiempo de recuperación (RTO)
como el tiempo de recuperación ante un desastre.
Figura 3: Pérdida de RPO y tiempo de recuperación de RTO
El servicio Azure Virtual Desktop ofrece BCDR para conservar los metadatos del cliente durante las
interrupciones. Cuando se produzca una interrupción en una región de Azure, los componentes
de la infraestructura de servicio conmutarán por error a una ubicación secundaria y seguirán
funcionando según lo previsto.
Para asegurarse de que los usuarios aún puedan conectarse durante una interrupción de la región
de Azure, es posible que deba replicar las VM personales en otra región de Azure (la ubicación
secundaria). Durante las interrupciones, la región principal conmuta por error a las VM replicadas
en la ubicación secundaria. Los usuarios pueden seguir teniendo acceso a las aplicaciones desde la
ubicación secundaria sin interrupción. Además de la replicación de la VM, deberá asegurarse de que se
pueda tener acceso a las identidades de los usuarios en la ubicación secundaria. Esto se puede lograr
mediante el uso de contenedores de perfiles. Como alternativa a la replicación de VM, también puede
usar varios grupos de hosts agrupados con aprovisionamiento automatizado entre regiones.
Nota: Asegúrese de que las aplicaciones empresariales que dependen de los datos de la región
de Azure principal puedan conmutar por error con el resto de los datos.
Para asegurarse de que los usuarios estén conectados durante una interrupción, debe tener
en cuenta los cinco componentes que se muestran en la Tabla 2 en orden cronológico.
Componentes Descripción
1 Red virtual Tenga en cuenta la conectividad de red durante una interrupción.
2 Máquinas virtuales Replique las VM en una ubicación secundaria o implemente varios grupos
de hosts no persistentes en las regiones de Azure.
3 Datos de usuarios y Mediante contenedores de perfiles FSLogix, configure la replicación de datos
aplicaciones en la ubicación secundaria. La replicación de datos también es necesaria para
quienes usan la conexión de aplicaciones MSIX.
4 Identidades de los usuarios Asegúrese de que las identidades de los usuarios que configuró en la ubicación
principal estén disponibles en la ubicación secundaria.
5 Dependencias de las Asegúrese de que las aplicaciones de línea de negocio que dependen de los
aplicaciones datos de la ubicación principal se conmuten por error a la ubicación secundaria.
Tabla 2: Cinco áreas a tener en cuenta para la recuperación ante desastres de Azure Virtual Desktop
Ahora veremos los pasos para configurar los cinco componentes claves de la recuperación ante
desastres para Azure Virtual Desktop, comenzando con VNets de Azure.
Configuración de la
recuperación ante desastres
en Azure Virtual Desktop
Cada entorno de Azure Virtual Desktop es diferente en términos de diseño y configuración.
Al diseñar e implementar una solución de recuperación ante desastres para Azure Virtual Desktop,
se deben tener en cuenta los siguientes cinco componentes claves.
Red virtual
Como punto de partida, debe tener en cuenta la conectividad de red durante una interrupción.
Para que los recursos de Azure conmuten por error o se comuniquen con una región secundaria,
debe asegurarse de que se ha configurado una VNet en la región o ubicación secundaria.
Supongamos que los usuarios necesitan tener acceso a recursos y servicios locales. En este escenario,
también deberá configurar la VNet para acceder a ellos a través de una VPN. Las conexiones locales
se pueden establecer con ExpressRoute, VPN o WAN virtual. También puede usar un dispositivo
virtual de red (NVA) para conectarse a entornos locales.
Azure Site Recovery también se puede usar para configurar la VNet en una región de conmutación
por error, ya que conserva la configuración de la red principal y no requiere un emparejamiento
de red. Esto podría considerarse como un servicio plug-and-play para la implementación más
pequeña de Azure Virtual Desktop debido a su simplicidad en términos de requisitos de instalación.
En la figura 4 se muestra una gateway de VPN simple que se conecta a un sitio local. Este es
un método de conectividad común para conectarse a entornos locales desde Azure.
Figura 4: Gateway de VPN simple que se conecta a un sitio local

En la figura 5 se muestra el emparejamiento de VNet entre dos regiones de Azure. El emparejamiento

es útil para quienes desean conectar dos VNets sin usar una VPN.
Figura 5: Emparejamiento de VNet entre dos regiones de Azure
DNS
Un problema común al que se enfrentan los clientes con Azure Virtual Desktop son los problemas
de configuración de DNS relacionados con la VNet. Asegúrese de que la VNet está configurada
correctamente con DNS. Puede resolver los nombres de dominio completo (FQDN) de Azure Virtual
Desktop y AD DS entre las dos regiones.
Obtenga más información aquí, en la lista de direcciones URL necesarias para Azure Virtual Desktop.
Máquinas virtuales
Para los grupos de hosts de Azure Virtual Desktop, tanto las opciones de BCDR activo-
activo como activo-pasivo pueden ser viables.
Con la opción activo-activo, un único grupo de hosts puede tener VM de varias regiones de Azure.
En este escenario, sería necesario el uso de FSLogix Cloud Cache para replicar activamente los
contenedores de perfiles o de Office de los usuarios entre las regiones. Para las VM de cada región,
la entrada de registro de Cloud Cache que especifica las ubicaciones debe invertirse para dar
prioridad a la local. La opción activo-activo se puede resumir de la siguiente manera:
• Se trata de una configuración compleja. Si se elige la opción activo-activo, se proporciona a la empresa

protección contra interrupciones del almacenamiento sin necesidad de volver a registrar el usuario y,
al mismo tiempo, se habilita la realización de pruebas continuas de la ubicación de recuperación ante
desastres. Este tipo de configuración no se considera una solución de optimización rendimiento ni una
solución de optimización de costos; prueba continuamente la recuperación ante desastres.
• El equilibrio de carga de las conexiones de usuario entrantes no puede tener en cuenta

la proximidad: todos los hosts serán iguales y los usuarios pueden ser dirigidos a una VM
del grupo de hosts de Azure Virtual Desktop remota, pero no óptima.
• Esta configuración se limitada a un tipo de grupo de hosts agrupado (compartido). Para un
tipo personal (dedicado), una vez que se asigna un escritorio a un usuario en una VM de host
de sesión determinada, este se mantiene y no cambia, incluso si no está disponible.
Con la opción activo-pasivo, Azure Site Recovery o un grupo de hosts secundario (espera activa)
en la región de recuperación ante desastres, se pueden usar las siguientes opciones:
• Azure Site Recovery se admite para los tipos de grupo de hosts personal (dedicado)

y agrupado (compartido) y le permitirá mantener una única entidad de grupo de hosts.
• También es posible crear un nuevo grupo de hosts en la región de conmutación por error,
lo que le permite mantener todos esos recursos desactivados. Para este método, tendría que
configurar nuevos grupos de aplicaciones en la región de conmutación por error y asignarles
usuarios. A continuación, puede usar un “plan de recuperación” de Azure Site Recovery para
activar los grupos de hosts y crear un proceso organizado.
Se recomienda usar Azure Site Recovery para administrar la replicación de VM en otras regiones

de Azure, tal como se describe en Arquitectura de recuperación ante desastres de Azure a Azure.
También se recomienda usar Azure Site Recovery para grupos de hosts personales, ya que
Azure Site Recovery admite SKU basadas en servidor y cliente.
Para obtener más instrucciones sobre las consideraciones de diseño de recuperación ante desastres
de Azure Virtual Desktop, consulte esta documentación.
Nota: La cantidad máxima de VM en un conjunto de disponibilidad es de 200, tal como

se documenta en este artículo.
La opción de resiliencia predeterminada para la implementación del grupo de hosts de Azure Virtual
Desktop es un conjunto de disponibilidad: solo se garantizará la resiliencia del grupo de hosts en
el nivel de centro de datos de Azure único, con una alta disponibilidad formal del 99,95 %. Puede
encontrar más información aquí.
Se recomienda usar Azure Backup para proteger los escritorios personales, en especial si no
usa contenedores de perfiles para estos escritorios. Obtenga más información sobre el servicio
de Azure Backup aquí.
En la figura 6 se muestra el rol de Azure Site Recovery en la replicación de las cargas de trabajo
en tres VM ubicadas en las regiones este y oeste de los Estados Unidos.
Figura 6: Azure Site Recovery replicando cargas de trabajo de una región principal a una secundaria
Al usar Azure Site Recovery, no es necesario registrar estas VM manualmente. El agente de Azure Virtual
Desktop configurado en la VM secundaria usará automáticamente el token de seguridad más reciente
para conectarse a la instancia del servicio de Azure Virtual Desktop más cercana a ella. La VM (host de
sesión) de la región secundaria automáticamente pasará a formar parte del grupo de hosts. El cliente solo
tendrá que volver a conectarse durante este proceso, sin que se deban realizar otros procesos manuales.
Desconecte a los usuarios de Azure Virtual Desktop

No puede haber conexiones de usuarios existentes durante una interrupción. Antes de que el
administrador pueda iniciar la conmutación por error a la región secundaria, deberá “finalizar”
las conexiones de los usuarios en la región de Azure actual. Para desconectar a los usuarios de
Azure Virtual Desktop, puede ejecutar este cmdlet:
Remove-AzWvdUserSession
Una vez que todos los usuarios hayan cerrado sesión en la región de Azure principal, puede
continuar y conmutar por error las VM de la región principal. Una vez que finalice, puede permitir
que los usuarios se conecten a las VM de la región secundaria. Para obtener más información sobre
cómo funciona este proceso, consulte Replique VM de Azure en otra región de Azure.
Se recomienda crear un runbook o script para automatizar la desconexión de las sesiones de los
usuarios durante una conmutación por error a una segunda región. Hacer esta tarea manualmente
puede tardar mucho tiempo. Puede crear un runbook de Automatización de Azure con esta guía.
Protección de copia de seguridad

Como se mencionó al principio de esta sección Máquinas virtuales, es importante evitar la pérdida
de datos críticos del usuario. El primer paso es evaluar los datos que se deben guardar y proteger.
Estas son algunas consideraciones:
• Si usa OneDrive u otra forma de almacenamiento no local, es posible que no sea necesario
guardar los datos de contenedores de perfiles o de Office de los usuarios.
• Se debe considerar un mecanismo adecuado para proteger los datos críticos de los usuarios:
- El servicio de Azure Backup puede proteger los datos del contenedor de perfiles y Office
cuando se almacenan en Azure Files, ya sea en el nivel Standard o en el nivel Premium.
- Las instantáneas y directivas de Azure NetApp Files se pueden usar para Azure NetApp Files
(todos los niveles).
- Azure Backup también se puede usar para proteger las VM del grupo de hosts; esta práctica
se admite incluso si las VM del grupo de hosts deben ser de tipo sin estado.
Disponibilidad de imágenes doradas

Al usar imágenes personalizadas para implementar VM de un grupo de hosts de Azure Virtual
Desktop, es importante asegurarse de que esos artefactos estén disponibles en todas las
regiones, incluso en caso de un desastre grave. El servicio Azure Shared Image Gallery se puede
usar para replicar imágenes en todas las regiones donde se implementa un grupo de hosts, con
almacenamiento redundante y en varias copias.
Ahora que sabe cómo diseñar e implementar una solución de recuperación ante desastres con VM,
el siguiente componente claves es administrar las identidades de los usuarios, además de configurar
los datos de estos y de las aplicaciones.
Administración de las identidades

de los usuarios
En esta sección, veremos cómo administrar las identidades de los usuarios y también exploraremos
las diferentes opciones disponibles para usted.
En caso de una conmutación por error, debe asegurarse de que el controlador de dominio esté
disponible en la ubicación o región secundaria. Se dispone de las tres opciones siguientes para
mantener el controlador de dominio disponible durante una interrupción:
1. Implemente un controlador de dominio de AD en la ubicación secundaria. En la figura 7

se muestran dos VNets configuradas mediante el emparejamiento de red, lo que permite que
dos controladores de dominio se comuniquen entre dos VNets mediante el emparejamiento.
Figura 7: Ejemplo de emparejamiento de red
2. Use un controlador de dominio de AD local. En la figura 8 se muestra un entorno local que

conecta dos VNets de Azure mediante una gateway de VPN a un sitio local.
Figura 8: Varias regiones que se conectan a través de una gateway de VPN a un sitio local
3. Replique el controlador de dominio de AD mediante Azure Site Recovery. En la figura 9

se muestra un controlador de dominio de AD que se replica con Azure Site Recovery.
Figura 9: Replicación de un controlador de dominio en la región secundaria con Azure Site Recovery
Ahora que hablamos de las opciones de identidad de usuario disponibles para usted al diseñar
una solución de BCDR para Azure Virtual Desktop, veamos cómo configurar los datos de usuarios
y de aplicaciones.
Configuración de datos de usuarios

y de aplicaciones
Si usa perfiles locales, se recomienda que Azure Site Recovery se use para replicar los datos de los
usuarios y los hosts de sesión en la segunda región. Para la mayoría de las organizaciones que
usan contenedores de perfiles, el siguiente paso sería configurar la replicación de contenedores
de perfiles en la ubicación secundaria.
En una situación de BCDR, es posible reducir el tiempo que se necesita para realizar una copia
de seguridad, restaurar y replicar datos con la separación los discos contenedores de perfiles
y de Office de los usuarios. FSLogix ofrece la posibilidad y la capacidad de asignarlos en ubicaciones
de almacenamiento separadas. En el uso normal, el disco de Office puede consumir mucha más
capacidad (medida en GB) que el perfil. La copia de seguridad, la replicación y la restauración del
disco de perfiles será mucho más rápida sin la inclusión de los datos de la memoria caché. No es
necesario que el disco de Office se haga resiliente, ya que se puede descargar de nuevo; los datos
que contiene ya están presentes dentro de los servicios en línea de Office 365.
Nota: la característica FSLogix Cloud Cache es “reescritura” por diseño para aumentar las
características de rendimiento a objetivos de alta latencia, utilizando así la replicación asíncrona.
Hay tres opciones estándar para almacenar perfiles FSLogix:
• Azure Files
• Azure NetApp Files
• FSLogix Cloud Cache para replicación
Microsoft Azure ofrece varias soluciones de almacenamiento que puede usar para almacenar los
contenedores de perfiles y Office de FSLogix. Opciones de almacenamiento para contenedores de perfiles
de FSLogix en Azure Virtual Desktop compara las diversas soluciones de almacenamiento administrado
que Azure ofrece para los contenedores de perfiles de usuarios de FSLogix de Azure Virtual Desktop.
Al configurar la recuperación ante desastres para perfiles, tiene a su disposición las siguientes opciones:
• Configurar la replicación de Azure (por ejemplo, la replicación de cuentas de almacenamiento

de Azure Files Standard, la replicación de Azure NetApp Files o la sincronización de Azure Files
para servidores de archivos).
• Configurar FSLogix Cloud Cache para los datos de aplicaciones y usuarios. Obtenga más
información sobre cómo usar Cloud Cache para la resiliencia y la disponibilidad.
• La tercera opción es configurar la recuperación ante desastres para los datos de aplicaciones,
con el único fin de garantizar el acceso a los datos críticos del negocio en todo momento.
En este escenario, puede recuperar los datos de los usuarios una vez finalizada la interrupción.
Esto significa básicamente que los usuarios obtendrían nuevos perfiles de usuario y una
experiencia de inicio de sesión por primera vez durante el período de interrupción.
Nota: La replicación de NetApp es automática después de que se configura por primera vez. Con los
planes de Azure Site Recovery, puede agregar scripts previos y posteriores para conmutar por error
los recursos que no son de VM.
Ahora analicemos con más detalle Cloud Cache para ver cómo se puede beneficiar su diseño de BCDR.
Cloud Cache
Cloud Cache usa un perfil local para atender las lecturas de un contenedor de perfiles u Office
redirigido después de completar su primera lectura. Cloud Cache puede utilizar varias ubicaciones
remotas que se actualizan continuamente durante la sesión del usuario. Cloud Cache puede,
básicamente, proteger a los usuarios del riesgo de pérdida de conectividad a corto plazo
a contenedores de perfiles remotos. También es importante tener en cuenta que Cloud Cache
puede proporcionar redundancia de tipo activo-activo para contenedores de perfiles y Office.
Nota: Compruebe los factores claves con respecto a Cloud Cache en el capítulo Consideraciones
de diseño. Se recomienda configurar los hosts de sesión con discos SSD premium para el archivo
de memoria caché local con el fin de ayudar a garantizar que no se produzca pérdida de datos.
Configuración de contenedores de perfiles de FSLogix con varias ubicaciones de perfil

El agente FSLogix admite varias ubicaciones de perfil al configurar las entradas de registro para
FSLogix. Para configurar las entradas de registro:
1. Abra Registry Editor (Editor del Registro).

2. Vaya a Computer (Equipo) > HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
(Perfiles).
Figura 10: Configuración del registro para contenedores de perfiles de FSLogix
3. Haga clic con el botón derecho del mouse en VHDLocations y seleccione Edit Multi-String
(Editar varias cadenas).
Figura 11: La opción VHDLocations en el registro para contenedores de perfiles de FSLogix
4. En el campo Value data (Datos del valor), introduzca las ubicaciones de almacenamiento que

desea utilizar. Cuando haya terminado, seleccione OK.
Si la primera ubicación de almacenamiento no está disponible, el agente FSLogix conmutará por

error automáticamente a la segunda. Se recomienda configurar previamente el agente FSLogix con
una ruta de acceso de la ubicación secundaria al configurar los hosts de sesión de la región principal
(implementación inicial).
Consejo: Para configurarlos según directiva de grupo, consulte este enlace.
Supongamos que la región o ubicación principal se cierra. En ese caso, la configuración del agente
FSLogix se replicará como parte de la VM (replicación de Azure Site Recovery). Una vez que las
VM replicadas estén listas en la región secundaria, el agente intentará automáticamente la ruta
de acceso de la región secundaria, ya que esta ha sido configurada previamente.
Configuración de Cloud Cache del perfil de FSLogix
En los siguientes pasos se describen los requisitos para configurar Cloud Cache.
Figura 12: El registro para contenedores de perfiles de FSLogix
1. Abra Registry Editor (Editor del Registro).

2. Vaya a Computer (Equipo) > HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
(Perfiles).
3. Quite cualquier configuración de VHDLocations.
4. Agregue CCDLocations como REG_MULTI_SZ, además del siguiente valor para
incluir la ubicación 1 y la ubicación 2: type=smb,connectionString=<\Location1\
Folder1>;type=smb,connectionString=<\Location2\folder2>
Figura 13: CCDLocations para FSLogix Cloud Cache
Una vez completada la configuración, Cloud Cache replicará el perfil entre las dos ubicaciones.
Azure Files
Azure Files admite la replicación asincrónica entre regiones que puede especificar al crear una
cuenta de almacenamiento. Si la naturaleza asincrónica de Azure Files ya cubre los objetivos
de recuperación ante desastres, no es necesario realizar configuraciones adicionales.
Azure Files ofrece una opción de replicación de conmutación por error de la cuenta
de almacenamiento en la otra región configurada en el plan de redundancia de la cuenta
de almacenamiento. Esto solo se admite para el tipo de cuenta de almacenamiento estándar
mediante almacenamiento con redundancia geográfica (GRS). Otras opciones incluyen
el uso de AzCopy o cualquier otro mecanismo de copia de archivos, como Robocopy.
Nota: La GRS no está disponible con los niveles Standard o Premium de recurso compartido
de Azure Files que tienen habilitada la compatibilidad con archivos grandes. Obtenga más
información sobre la replicación entre regiones de volúmenes de Azure NetApp Files aquí.
Azure NetApp Files

Azure NetApp Files es un servicio de almacenamiento de archivos de alto rendimiento que puede
ejecutar las cargas de trabajo de archivos más exigentes de Azure sin necesidad de modificar
el código. Es un servicio principal de Azure, desarrollado con tecnología ONTAP de NetApp
y compatible con Microsoft. Con una configuración que está lista en solo unos minutos, Azure
NetApp Files permite que las aplicaciones de Linux y Windows se migren y ejecuten sin problemas
en la nube para una experiencia similar a la del entorno local, con su rendimiento correspondiente.
En la figura 14 se muestra un entorno de Azure Virtual Desktop con NetApp Files.
Figura 14: Diagrama arquitectónico de Azure Virtual Desktop con Azure NetApp Files
Obtenga más información sobre Azure NetApp Files en Cree un emparejamiento de replicación para
Azure NetApp Files. También se puede encontrar más información en FSLogix para la empresa: Guía
de arquitectura de Azure.
El uso de OneDrive
OneDrive puede redirigir carpetas conocidas (Escritorio, Documentos, Imágenes, Capturas
de pantalla y Álbum de cámara) si las hay. Esto aumentaría la resiliencia de estas carpetas especiales,
ya que OneDrive se encargaría de controlarlas en lugar de que necesiten una consideración especial
en un escenario de BCDR.
Conexión de aplicaciones MSIX

La conexión de aplicaciones MSIX es una característica de entrega de aplicaciones de Microsoft
en Azure Virtual Desktop diseñada para un área de trabajo moderna. Con la conexión de aplicaciones
MSIX, puede usar un formato de aplicación (MSIX) para ofrecer aplicaciones a escritorios agrupados
y personales dentro de Azure Virtual Desktop.
En la Figura 15 se muestra cómo funciona la conexión de aplicaciones MSIX. Observará que

es necesario contar con un recurso compartido de archivos para almacenar imágenes MSIX.
Figura 15: Pasos para ofrecer aplicaciones de la conexión de aplicaciones MSIX a un usuario
Se deben tener en cuenta dos áreas. En primer lugar, debe encargarse del almacenamiento para
garantizar el acceso a las imágenes MSIX en la segunda ubicación. Al igual que los contenedores
de perfiles, la conexión de aplicaciones MSIX requiere almacenamiento en red para guardar las imágenes
MSIX. Este podría ser Azure Files, NetApp Files o un recurso compartido de archivos. Según cual sea la
opción elegida, debe asegurarse de que estas imágenes MSIX estén disponibles en un escenario de BCDR.
La segunda consideración es que es posible que la ruta de acceso de la imagen MSIX haya cambiado
si ha optado por usar un nuevo recurso de almacenamiento en la segunda región. Al hacerlo, las rutas
de almacenamiento han cambiado. Esto significa que tendría que volver a configurar todas las rutas
de acceso de la imagen MSIX a través de PowerShell o de la interfaz de usuario de administración
de Azure antes de que los usuarios puedan acceder a estas aplicaciones mediante un grupo de hosts.
Para evitar las complicaciones que implica volver a configurar la conexión de aplicaciones MSIX y las
rutas de acceso de la imagen MSIX, use una de las siguientes opciones.
• Cree un grupo de hosts separado para la región secundaria.

• Use Azure Files con GRS.
• Implemente la replicación de Azure NetApp Files entre regiones.
Obtenga información sobre cómo puede configurar la conexión de aplicaciones MSIX a través
de Azure Portal con esta documentación.
Agregue dependencias
Una última área a tener en cuenta es la de aquellos datos o servicios que se ejecutan en la región
principal y se deben conmutar por error para evitar que se produzcan errores en la aplicación
empresarial durante una interrupción. Asegúrese de que las aplicaciones empresariales que
dependen de datos ubicados en la región principal puedan conmutar por error a la ubicación
secundaria. Estos podrían ser servicios web personalizados, bases de datos de SQL u otros.
También se debe asegurar de que las aplicaciones tengan configurados los valores requeridos.
Es posible que deban agregar configuraciones adicionales a estos servicios una vez que se haya
configurado la replicación o la alta disponibilidad. Un ejemplo es que si una de las aplicaciones
depende del back-end de SQL, asegúrese de replicar SQL en la ubicación secundaria y de configurar
las cadenas de conexión de alta disponibilidad de SQL.
Puede configurar la aplicación para que use la segunda región como parte del proceso
de conmutación por error o como su configuración predeterminada. También puede modelar
las dependencias de la aplicación en los planes de Azure Site Recovery.
Resumen:
• Si los usuarios de la infraestructura de Azure Virtual Desktop necesitan acceso a recursos locales,
también es crítica y se debe tener en cuenta la alta disponibilidad de la infraestructura de red
necesaria para conectarse.
• La resiliencia de la infraestructura de autenticación se debe evaluar.
• Se deben tener en cuenta los aspectos de la BCDR para aplicaciones independientes y otros
recursos necesarios para garantizar la disponibilidad en la ubicación de recuperación ante
desastres secundaria.
Para obtener más información, consulte la documentación sobre planes de recuperación.

Prueba de recuperación
ante desastres
Una vez que haya terminado de instalar y configurar la recuperación ante desastres para Azure
Virtual Desktop, debe probar el plan para asegurarse de que funciona y confirmar que los usuarios
aún pueden tener acceso a los recursos y servicios que necesitan.
Al probar el plan de BCDR de Azure Virtual Desktop, se deben tener en cuenta los siguientes puntos.
Figura 16: Consideraciones al probar el plan de BCDR de Azure Virtual Desktop
Consulte la siguiente guía para utilizar la herramienta de comprobación de URL requerida.
Consejo: También puede probar la conectividad a los servicios de Azure Virtual Desktop mediante
PsPing - Windows Sysinternals.
En el capítulo final, veremos algunas de las herramientas claves para la optimización y los
procedimientos recomendados para Azure Virtual Desktop.
Optimizaciones y procedimientos
recomendados
A continuación se presentan los procedimientos recomendados que se deben tener en cuenta para
la configuración del diseño de recuperación ante desastres:
Active Directory
La autenticación de AD debe estar disponible en la región de recuperación ante desastres o se debe
garantizar la conectividad con el dominio local.
Máquinas virtuales
Para la BCDR del modelo de implementación informática del grupo de hosts de Azure Virtual
Desktop, use la opción activo-pasivo si esto satisface sus requisitos de RPO y RTO.
Azure Site Recovery

Azure Site Recovery es compatible con los 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 secundaria
de recuperación ante desastres.
Nota: Se recomienda 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
utilizado por FSLogix.
Zonas de disponibilidad
Las zonas de disponibilidad se deben usar cuando se requiere la máxima resiliencia del grupo
de hosts en una sola región. En primer lugar, los clientes deben comprobar la disponibilidad
de características de la zona de disponibilidad en la región requerida y la disponibilidad
de referencias de almacén (SKU) de tipo de tamaño de VM específicas dentro de todas las zonas.
Azure Shared Image Gallery

Se debe usar Azure Shared Image Gallery para replicar imágenes doradas en diferentes regiones.
El almacenamiento utilizado para la creación de imágenes debe ser almacenamiento replicado
por zona (ZRS) y se deben mantener al menos dos copias por región.
FSLogix
Para la mayoría de los escenarios de clientes se recomienda almacenar los contenedores de perfiles
y de Office de los usuarios de FSLogix en Azure Files o Azure NetApp Files.
Nota: Se recomienda dividir los contenedores de perfiles y de Office de los usuarios.
Las opciones recomendadas para los tipos de almacenamiento de contenedores FSLogix se detallan
en la figura 17.
Figura 17: Opciones recomendadas para los tipos de almacenamiento de contenedores FSLogix.
El uso de un tipo de Azure Files depende de los recursos y la latencia que requiere la carga de trabajo
específica. Las organizaciones grandes suelen usar Azure Files Premium o Azure NetApp Files Premium.
Para un rendimiento óptimo, los contenedores FSLogix deben estar ubicados en el almacenamiento
lo más cerca posible de la VM en la que el usuario ha iniciado sesión, preferiblemente en el mismo
centro de datos.
Cuando sea posible, se deben usar los mecanismos de replicación integrados de almacenamiento
de Azure para BCDR; para entornos menos críticos, se recomienda ZRS o GRS para Azure Files.
Se puede usar el almacenamiento con redundancia local (LRS) con resiliencia solo local si no
se requiere protección de zona o región.
Nota: Para obtener información sobre el diseño, el tamaño y la implementación de una solución
de contenedor de perfiles de Microsoft FSLogix para grandes empresas, consulte este artículo.
Cloud Cache
Cloud Cache solo se debe usar cuando:
• Se requiere disponibilidad de datos de contenedores de perfiles o de Office de los usuarios;

el SLA de alta disponibilidad es crítico y debe ser resiliente a las fallas en la región.
• La opción de almacenamiento seleccionado no puede cumplir con los requerimientos de BCDR.
Por ejemplo, la GRS no está disponible con los niveles Standard o Premium de recurso
compartido de Azure Files que tienen habilitada la compatibilidad con archivos grandes.
• Cuando se requiere replicación entre almacenamiento dispar.
Cuando se usa Cloud Cache, se recomienda usar un SSD para el disco administrado de las VM del
grupo de hosts de Azure Virtual Desktop y que se establezca una solución de copia de seguridad
para proteger los contenedores de perfiles y Office de los usuarios.
Azure Backup
Puede usar Azure Backup para proteger los datos críticos de los usuarios de la pérdida de datos
o los daños lógicos cuando se usan niveles Standard o Premium de Azure Files. Tenga en cuenta
los siguientes puntos al usar Azure Backup:
• Use instantáneas y directivas cuando se use el servicio Azure NetApp Files.

• Incluso si se es compatible, no se recomienda el uso de Azure Backup para guardar un estado
de VM en el grupo de hosts, ya que debe ser de tipo sin estado.
• Revise atentamente los planes de resiliencia y BCDR para los recursos dependientes
(redes, autenticación, aplicaciones y otros servicios internos en Azure o en entornos locales).
• La infraestructura de red, como parte de la arquitectura de tipo hub-and-spoke o de WAN
virtual, también debe estar disponible en la región secundaria.
• La conectividad híbrida debe tener una alta disponibilidad tanto en la región principal como
en la secundaria.
Todos los procedimientos recomendados y consejos sobre consideraciones de recuperación ante

desastres que se comparten en este capítulo le ayudarán a garantizar que tiene una BCDR sólida
y resiliente.
Estos son algunos recursos que le ayudarán con su plan de recuperación ante desastres
• Desarrolle un plan de continuidad del negocio y recuperación ante desastres

• Use Azure Site Recovery como parte de su plan de BCDR
• Cree servicios de aplicaciones resilientes
• Establezca un plan de continuidad del negocio y recuperación ante desastres
Conclusión y recursos
Resumen
Comenzamos este manual con una breve introducción a Azure Virtual Desktop y la importancia
de planear una estrategia de recuperación ante desastres para su entorno. Es muy importante
que tenga una buena estrategia de BCDR. También es esencial tener en cuenta las áreas claves
de la recuperación ante desastres de Azure Virtual Desktop, que incluyen VNets, VM, identidades
de los usuarios y los datos de usuarios y de aplicaciones.
Más adelante, analizamos rápidamente cómo probar una implementación de recuperación ante
desastres de Azure Virtual Desktop. Junto con esto, es fundamental que siga los procedimientos
recomendados y las instrucciones que se analizaron con respecto a las consideraciones de diseño
al implementar una solución de BCDR para Azure Virtual Desktop.
Esperamos que este manual le ayude a sentirse más preparado con relación a cómo planear, diseñar
e implementar la recuperación ante desastres para Azure Virtual Desktop.
Consulte la sección Recursos para obtener lecturas y soporte adicionales que le ayudarán a
comenzar.
Recursos
A medida que avance en su recorrido con Azure Virtual Desktop y la BCDR, estos son algunos
recursos que pueden ayudarle:
• Obtenga más información sobre BCDR para Azure Virtual Desktop.

• Siga la orientación de Azure Security Baseline para Azure Virtual Desktop.
• Comience ahora con una cuenta gratuita de Azure.
• Póngase en contacto con un especialista en ventas de Azure para obtener orientación personalizada
y analizar los precios, los requisitos técnicos y las soluciones para proteger el trabajo remoto.
• Únase al Programa de modernización y migración Azure para obtener orientación y ayuda
experta en la migración de su VDI local.
Glosario
La siguiente tabla contiene un glosario de la terminología utilizada en este manual.
Nombre Descripción
Active Directory Domain Un directorio es una estructura jerárquica que almacena información sobre
los objetos en la red. Un servicio de directorio, como Active Directory Domain
Services (AD DS), proporciona los métodos para almacenar datos de un directorio
y poner estos datos a disposición de los usuarios y administradores de la red.
Azure Active Directory Azure AD es el servicio de administración de identidades y acceso basado
(Azure AD) en la nube de Microsoft, que ayuda a sus empleados a iniciar sesión y acceder
a los recursos.
Azure Files Azure Files ofrece recursos compartidos de archivos totalmente administrados en
la nube, accesibles a través del protocolo Bloque de mensajes del servidor (SMB)
o del protocolo Network File System (NFS).
Azure NetApp Files El servicio Azure NetApp Files es un servicio de almacenamiento de archivos
de clase empresarial medido y de alto rendimiento. Azure NetApp Files admite
cualquier tipo de carga de trabajo y está altamente disponible de forma
predeterminada.
Azure Site Recovery El servicio Azure Site Recovery administra la replicación de Azure Virtual Desktop
entre regiones.
FSLogix FSLogix está diseñado para recorrer perfiles en entornos informáticos remotos,
como Azure Virtual Desktop. Almacena un perfil de usuario completo en un
solo contenedor.
Múltiples sesiones Múltiples sesiones de Windows 10 Enterprise, conocido anteriormente como
de Windows 10 Windows 10 Enterprise for Virtual Desktops (EVD), es un nuevo host de sesión
de escritorio remoto que permite varias sesiones interactivas simultáneas.
Acerca del autor
Ryan Mangan es un especialista en informática para el usuario final (EUC), orador y presentador
que ayuda a los clientes y las comunidades técnicas con soluciones informáticas para el
usuario final, que van desde implementaciones empresariales pequeñas a globales con más de
30.000 usuarios en diversos campos. Ryan es el propietario y autor de ryanmangansitblog.com,
que tiene más de 3 millones de visitantes y más de 70 artículos sobre servicios de escritorio remoto
y Azure Virtual Desktop. Algunas de las publicaciones y de los premios técnicos y de la comunidad
de Ryan incluyen los siguientes:
• Es autor de:
- Guía de inicio rápido a Azure Virtual Desktop
- Una introducción a conexión de aplicaciones MSIX
• VMware vExpert, durante ocho años consecutivos
• VMware vExpert EUC 2021
• Parallels RAS VIPP: durante tres años consecutivos
• Asesor tecnológico de LoginVSI: durante dos años consecutivos
• Técnico del año 2017 KEMP Technologies
• Parallels RAS EMEA Technical Champion 2018
• Orador de la comunidad de Microsoft
• 50 blogs principales de TI 2020: Feed spot
• 50 blogs principales de Azure 2020: Feed spot
Blog: https://ryanmangansitblog.com
GitHub: https://github.com/RMITBLOG

Manual de Azure Virtual Desktop - Recuperación Ante Desastres

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual de Azure Virtual Desktop - Recuperación Ante Desastres

Cargado por

Copyright:

Formatos disponibles

Manual de Azure Virtual Desktop: 2

Recuperación ante desastres

En este manual se proporcionarán consideraciones sobre los requisitos previos de continuidad

Información general de Azure Virtual Desktop

Figura 1: Componente y responsabilidades de Azure Virtual Desktop

Figura 2: Configuración de arquitectura típica de Azure Virtual Desktop

Responsabilidad RDS locales RDS en Azure Azure Virtual Desktop

Dispositivos de usuario final

Funcionamiento de host de la sesión

Plano de control de virtualización

Centro de datos físico

Introducción a la recuperación ante desastres

Figura 3: Pérdida de RPO y tiempo de recuperación de RTO

1 Red virtual Tenga en cuenta la conectividad de red durante una interrupción.

Figura 4: Gateway de VPN simple que se conecta a un sitio local

En la figura 5 se muestra el emparejamiento de VNet entre dos regiones de Azure. El emparejamiento

Figura 5: Emparejamiento de VNet entre dos regiones de Azure

• Se trata de una configuración compleja. Si se elige la opción activo-activo, se proporciona a la empresa

• El equilibrio de carga de las conexiones de usuario entrantes no puede tener en cuenta

• Azure Site Recovery se admite para los tipos de grupo de hosts personal (dedicado)

Se recomienda usar Azure Site Recovery para administrar la replicación de VM en otras regiones

Nota: La cantidad máxima de VM en un conjunto de disponibilidad es de 200, tal como

Desconecte a los usuarios de Azure Virtual Desktop

Protección de copia de seguridad

Disponibilidad de imágenes doradas

Administración de las identidades

1. Implemente un controlador de dominio de AD en la ubicación secundaria. En la figura 7

Figura 7: Ejemplo de emparejamiento de red

2. Use un controlador de dominio de AD local. En la figura 8 se muestra un entorno local que

3. Replique el controlador de dominio de AD mediante Azure Site Recovery. En la figura 9

Configuración de datos de usuarios

Hay tres opciones estándar para almacenar perfiles FSLogix:

• Configurar la replicación de Azure (por ejemplo, la replicación de cuentas de almacenamiento

Configuración de contenedores de perfiles de FSLogix con varias ubicaciones de perfil

1. Abra Registry Editor (Editor del Registro).

Figura 10: Configuración del registro para contenedores de perfiles de FSLogix

Figura 11: La opción VHDLocations en el registro para contenedores de perfiles de FSLogix

4. En el campo Value data (Datos del valor), introduzca las ubicaciones de almacenamiento que

Si la primera ubicación de almacenamiento no está disponible, el agente FSLogix conmutará por

Consejo: Para configurarlos según directiva de grupo, consulte este enlace.

Configuración de Cloud Cache del perfil de FSLogix

Figura 12: El registro para contenedores de perfiles de FSLogix

1. Abra Registry Editor (Editor del Registro).

Figura 13: CCDLocations para FSLogix Cloud Cache

Azure NetApp Files

Conexión de aplicaciones MSIX

En la Figura 15 se muestra cómo funciona la conexión de aplicaciones MSIX. Observará que

• Cree un grupo de hosts separado para la región secundaria.

Para obtener más información, consulte la documentación sobre planes de recuperación.

Figura 16: Consideraciones al probar el plan de BCDR de Azure Virtual Desktop

Consulte la siguiente guía para utilizar la herramienta de comprobación de URL requerida.

Azure Site Recovery

Azure Shared Image Gallery

Nota: Se recomienda dividir los contenedores de perfiles y de Office de los usuarios.

• Se requiere disponibilidad de datos de contenedores de perfiles o de Office de los usuarios;

• Use instantáneas y directivas cuando se use el servicio Azure NetApp Files.

Todos los procedimientos recomendados y consejos sobre consideraciones de recuperación ante

• Desarrolle un plan de continuidad del negocio y recuperación ante desastres

• Obtenga más información sobre BCDR para Azure Virtual Desktop.

La siguiente tabla contiene un glosario de la terminología utilizada en este manual.

Acerca del autor

También podría gustarte