Resistencia de cargas de trabajo para Azure Local

La recuperación ante desastres para cargas de trabajo que se ejecutan en máquinas virtuales (VM) locales de Azure requiere un enfoque en capas que alinea las protecciones de nivel de infraestructura con estrategias de continuidad específicas de la aplicación. Tanto si hospeda bases de datos de SQL Server como si ofrece escritorios virtuales a través de Azure Virtual Desktop, cada tipo de carga de trabajo tiene requisitos y dependencias de recuperación únicos. Azure Local admite una amplia gama de tecnologías de recuperación ante desastres que le permiten adaptar los planes de recuperación para cumplir los objetivos de continuidad empresarial y garantizar una recuperación rápida de las interrupciones.

SQL Server habilitado para Arc

Las máquinas virtuales locales de Azure pueden hospedar instancias de alto rendimiento de SQL Server habilitadas para Arc, incluidas las que usan grupos de disponibilidad Always-On para proporcionar funcionalidades de alta disponibilidad (HA) y recuperación ante desastres (DR) de nivel empresarial. El objetivo principal de la recuperación ante desastres de SQL Server es cumplir el objetivo de tiempo de recuperación (RTO) específico de la aplicación y el objetivo de punto de recuperación (RPO) en caso de interrupción. SQL Server proporciona un amplio conjunto de características integradas para alta disponibilidad (HA) dentro de un único sitio o clúster y recuperación ante desastres (DR) en un sitio o clúster secundario.

En el caso de las cargas de trabajo de SQL Server que se ejecutan en máquinas virtuales locales de Azure, una estrategia de recuperación ante desastres completa debe combinar mecanismos de protección de nivel de host con las propias características nativas de alta disponibilidad y recuperación ante desastres de SQL Server. Aunque la protección de nivel de host protege toda la instancia del servidor, incluidos los archivos binarios de SQL Server y el sistema operativo, las soluciones nativas de SQL, como Always-On grupos de disponibilidad y trasvase de registros, ofrecen un control más granular sobre la disponibilidad de la base de datos, proporcionan protección de datos coherente con la aplicación y a menudo pueden lograr RPO más bajos, especialmente para bases de datos muy transaccionales. Mediante las propias funcionalidades de recuperación ante desastres de SQL Server, además de las protecciones de nivel de host de Azure Local, las organizaciones pueden lograr una protección de datos más sólida y tiempos de recuperación más rápidos.

Funcionalidades de recuperación ante desastres de SQL Server en máquinas virtuales locales de Azure

SQL Server habilitado para Arc proporciona una variedad de tecnologías de recuperación ante desastres probadas, todas ellas totalmente compatibles con las implementaciones locales de Azure. Puede elegir uno o combinar varios, según los requisitos de la aplicación y los objetivos de objetivo de punto de recuperación (RPO) o objetivo de tiempo de recuperación (RTO).

Entre las principales características de recuperación ante desastres de SQL Server y las recomendaciones de procedimientos recomendados para usarlas en Azure Local se incluyen:

  • Grupos de disponibilidad AlwaysOn (AG)

    • Un grupo de disponibilidad Always On es una característica de primera de alta disponibilidad/recuperación ante desastres que protege un conjunto de bases de datos de usuario mediante la replicación de transacciones desde una replica principal a una o varias replicas secundarias.
    • En un entorno local de Azure, los grupos de disponibilidad (AGs) se pueden usar dentro de un único clúster para lograr una alta disponibilidad y entre clústeres o sitios para la recuperación ante desastres. Para la conmutación automática por error, implemente Grupos de Disponibilidad en un clúster de conmutación por error de Windows Server (WSFC) y use el modo de compromiso sincrónico entre réplicas cercanas (red de baja latencia). Use el modo de confirmación asincrónica para las réplicas distantes (mayor latencia) para maximizar el rendimiento. Los grupos de disponibilidad distribuidos también pueden abarcar varios clústeres para escenarios avanzados. Los Grupos de Disponibilidad Always On en Azure Local son la solución recomendada para proteger las bases de datos críticas que requieren un tiempo de inactividad mínimo, y admiten la conmutación por error automática y manual cuando se configuran correctamente.
    • Para obtener más información, consulte ¿Qué es un grupo de disponibilidad AlwaysOn?

  • Instancias Always On de clúster de conmutación por error (FCI):

    • Una instancia de clúster de conmutación por error Always On es una solución de alta disponibilidad a nivel de instancia basada en WSFC que proporciona la conmutación por error de toda la instancia de SQL Server (incluidas todas las bases de datos) a otro nodo en el clúster a nivel de invitado de VM.
    • Una FCI en Azure Local usa el almacenamiento compartido del clúster (proporcionado por los volúmenes S2D de Azure Local) para asegurarse de que la instancia de SQL puede reiniciarse en un segundo nodo con los mismos datos.
    • Práctica recomendada: Utilice FCIs para proteger aplicaciones que requieren conmutación por error a nivel de instancia o cuando hay almacenamiento compartido disponible.
    • Para más información, consulte Instancias de clúster de conmutación por error AlwaysOn.

  • Envio de registros:

    • El envío de registros realiza copias de seguridad periódicas de los registros de transacciones en una base de datos principal y los restaura en una base de datos secundaria. Esto establece un servidor en espera activo que se puede poner en línea en un desastre. En Azure Local, el trasvase de registros es totalmente compatible y puede ser una opción de recuperación ante desastres de bajo costo para bases de datos menos sensibles al tiempo.
    • Procedimiento recomendado: asegúrese de que la frecuencia de copia de seguridad del registro se alinea con el RPO. Monitorea también el retraso de restauración en la base de datos secundaria para estimar el tiempo de conmutación por error. Para obtener más información, consulte Acerca del envío de registros.

  • Creación de reflejo de la base de datos:

    • El reflejo mantiene dos copias de una base de datos y se puede configurar de forma sincrónica o asincrónica. Sin embargo, la creación de reflejo está en desuso en versiones recientes de SQL y no se recomienda para nuevas implementaciones. En su lugar, use grupos de disponibilidad básicos o grupos de disponibilidad Always On completos, que proporcionan funcionalidades similares en Azure local sin las limitaciones de la duplicación.
    • Para obtener más información, consulte Creación de reflejo de la base de datos.

  • Copia de seguridad y restauración:

    • Las copias de seguridad de base de datos normales, incluidas las copias de seguridad completas, diferenciales y del registro de transacciones, son la base de cualquier estrategia de recuperación ante desastres. SQL Server admite la copia de seguridad en un disco o en una dirección URL como Azure Blob Storage. Los clientes pueden usar Microsoft Azure Backup Server (MABS) o herramientas de asociados que no son de Microsoft para realizar copias de seguridad de todas sus máquinas virtuales o aplicaciones en discos locales y en el almacenamiento en la nube. SQL Server también ofrece copia de seguridad administrada en Azure, que puede programar automáticamente copias de seguridad en el almacenamiento en la nube sin MABS ni ninguna solución de copia de seguridad que no sea de Microsoft.
    • Mejor práctica: Use cualquier herramienta que tenga sentido para su entorno, realice copias de seguridad frecuentes para cumplir los objetivos de punto de recuperación (RPO) y probar la restauración de manera rutinaria.
    • Para obtener más información, consulte Copia de seguridad y restauración de bases de datos de SQL Server.

  • Replicación:

    • La replicación de SQL Server (transaccional, combinación o instantánea) permite copiar y distribuir datos de una base de datos a otras casi en tiempo real. Aunque normalmente se usa para distribuir copias de solo lectura o sincronizar datos, la replicación también puede servir como parte de una estrategia de recuperación ante desastres. En Azure Local, se admiten todas las formas de replicación de SQL Server.
    • Advertencia: la replicación no conmuta por error automáticamente todas las bases de datos y podría requerir reconfiguración manual en un desastre.
    • Para obtener más información, vea Replicación de SQL Server.

Todas las funcionalidades anteriores se pueden mezclar para lograr un resultado deseado. Por ejemplo, use un grupo de disponibilidad Always On para lograr alta disponibilidad sin pérdida de datos en su sitio primario, y simultáneamente utilice la replicación asincrónica a una instancia secundaria de Azure fuera del sitio para la recuperación ante desastres. La elección debe guiarse por los requisitos de RPO/RTO de la aplicación y si la solución proporciona conmutación automática ante fallos o requiere un proceso manual.

Beneficios de SQL Server habilitado para Arc

Todas las máquinas virtuales locales de Azure habilitadas para invitados están habilitadas para Arc, por lo tanto, el SQL Server dentro de la máquina virtual se habilitará automáticamente como SQL Server habilitado para Arc. A través de la integración de Azure Arc, obtendrá visibilidad y administración basada en la nube para la configuración de recuperación ante desastres de SQL Server local. Azure Arc no reemplaza las características de recuperación ante desastres nativas de SQL anteriores, pero proporciona herramientas unificadas para supervisar, administrar y mejorar estas funcionalidades desde Azure Portal.

Entre las características clave de SQL Server habilitadas para Azure Arc para la recuperación ante desastres se incluyen las siguientes:

  • Administración de grupos de disponibilidad AlwaysOn:

    • Vea y administre los grupos de disponibilidad Always-On en servidores SQL Server habilitados para Arc en el portal de Azure. Esto incluye ver la lista de grupos de disponibilidad, sus réplicas y estado de sincronización, y realizar la conmutación por error manual si es necesario.
    • Para obtener más información, consulte Administración de grupos de disponibilidad AlwaysOn.

  • Visibilidad de la instancia del clúster de conmutación por error:

  • Copia de seguridad y restauración automatizadas:

    • Configure copias de seguridad automatizadas a través de Azure Policy o el portal. La extensión de SQL Server de Arc puede programar y ejecutar copias de seguridad según una directiva definida. También puede restaurarlos desde el portal.
    • Para obtener más información, consulte Administrar y Restauración a un momento dado.

  • Respaldo a URL con Identidad Administrada

Azure Virtual Desktop

Azure Virtual Desktop proporciona una plataforma completa para ofrecer de forma segura escritorios y aplicaciones virtualizados de Windows a los usuarios en cualquier lugar, integrando sin problemas con entornos locales y en la nube.

La arquitectura de Azure Virtual Desktop consta de varios componentes principales, incluidas las máquinas virtuales del host de sesión, el plano de control de Azure Virtual Desktop (que administra las conexiones de usuario, el agente y los servicios de puerta de enlace desde la nube), el almacenamiento de perfiles de usuario (como FSLogix) y las configuraciones de red que proporcionan una experiencia de escritorio virtual fluida. Una estrategia de recuperación ante desastres eficaz para Azure Virtual Desktop en Azure Local debe tener en cuenta la recuperación y continuidad de cada uno de estos componentes para garantizar una transición sin problemas tras la conmutación por error.

Los hosts de sesión de Azure Virtual Desktop son máquinas virtuales que ejecutan los entornos reales de escritorio y aplicación a los que se conectan los usuarios al acceder a Azure Virtual Desktop. Cada host de sesión ofrece recursos, administra las sesiones de usuario y garantiza que las cargas de trabajo están aisladas y tienen un rendimiento. Como resultado, muchas de las opciones de recuperación de máquinas virtuales enumeradas para máquinas virtuales locales de Azure también se aplican a Azure Virtual Desktop, pero requieren consideraciones adicionales para tener en cuenta los otros componentes principales de una solución de escritorio virtual.

Grupos de hosts agrupados

En el modelo agrupado, los usuarios se asignan a cualquier host de sesión disponible de un grupo y las máquinas virtuales son idealmente sin estado. Los datos y la configuración específicos del usuario se gestionan mediante contenedores de perfiles de FSLogix, que almacenan todo el perfil de usuario en un archivo VHD(X) conectado dinámicamente durante el inicio de sesión. Para la recuperación ante desastres, el objetivo principal de los hosts agrupados es garantizar la disponibilidad de la imagen dorada que se utiliza para implementar hosts de sesión, los contenedores de perfil de FSLogix y cualquier paquete de adjunción de aplicaciones MSIX para reconstruir la imagen. Dado que las máquinas virtuales no se asignan directamente a un usuario, es posible que no se necesiten métodos completos de copia de seguridad y conmutación por error de máquinas virtuales como Hyper-V Réplica.

El enfoque de recuperación ante desastres recomendado para los hosts de sesión agrupados es crear un grupo de hosts en un sitio secundario, ya sea Azure u otro clúster, y configurarlo para que coincida con el grupo de hosts principal. Estos hosts pueden permanecer inactivos y activarse en el momento de conmutación o pueden estar siempre activos. Es importante asegurarse de que el grupo de hosts secundarios tenga acceso a los mismos perfiles de FSLogix y esté creado a partir de la misma imagen de los hosts principales para proporcionar la misma experiencia a los usuarios. Puede usar el redireccionamiento de OneDrive para asegurarse de que los perfiles de FSLogix permanecen sincronizados entre los dos sitios.

En el momento de la conmutación por error, si los hosts están inactivos, deben activarse y los usuarios se reasignan al grupo de hosts secundario. Si siempre están activos, no se necesita ninguna intervención de administrador en el momento de la conmutación por fallo. El retroceso después de que se restaura el estado del clúster principal se realiza de manera similar una vez que los hosts originales vuelven a estar en línea.

Grupos de hosts personales

Con los hosts de sesión personales, a cada usuario se le asigna una máquina virtual dedicada como host de sesión. Estas máquinas virtuales tienen estado, ya que los usuarios pueden instalar aplicaciones o almacenar datos directamente en ellas. Por lo tanto, la recuperación ante desastres para hosts de sesión personales normalmente requiere una copia de seguridad y replicación completa de nivel de máquina virtual (mediante Hyper-V réplica) para conservar el estado único del escritorio de cada usuario.

Conmutación por error a otro clúster local de Azure mediante Hyper-V Réplica

Un clúster secundario de Azure Local se puede utilizar como un sitio de conmutación por error para mantener los anfitriones de sesión en las instalaciones. La estrategia sigue en gran medida las recomendaciones para la resiliencia de las máquinas virtuales mediante Hyper-V Replica, con consideraciones especiales para los hosts de sesión personales.

La estrategia sigue en gran medida las recomendaciones de la sección réplica de Hyper-V anterior, con consideraciones especiales para los hosts de sesión agrupados y personales.

  • Preparar el clúster para la conmutación por error: asegúrese de que el clúster secundario tiene suficiente capacidad de proceso y almacenamiento para admitir una conmutación por error, tiene una configuración de red coincidente y se puede enrutar al clúster principal. Asegúrese de que la configuración de AD DC y DNS estén configuradas iguales en el clúster secundario para que las máquinas virtuales replicadas se puedan autenticar sin problemas.

  • Habilitar Hyper-V Replica: Hyper-V Replica debe configurarse mediante PowerShell o el Administrador de clústeres de conmutación por error, no puede hacerse desde el portal de Azure. La replicación debe estar habilitada en los clústeres principal y secundario, y la configuración de replicación debe definirse para cada máquina virtual, incluida la frecuencia de recuperación y el método de replicación inicial.

  • Replicación de hosts de sesión: Para los hosts de sesión personales, asegúrese de que cada máquina virtual se replique periódicamente en el clúster secundario y que la asignación de usuario a VM sea coherente con el clúster principal. Se recomienda mantener las máquinas virtuales replicadas aprovisionadas y asignadas al grupo de hosts antes de la conmutación por error, pero, si no es así, deben asignarse tras la conmutación por error.

Conmutación por error de Réplica de Hyper-V

En el proceso de conmutación por error, el primer paso es confirmar que el controlador de dominio está completamente operativo y que la configuración de DNS está actualizada antes de iniciar cualquier host. Los servidores de sesión personal deben tener la última configuración de replicación activada y verificada para asegurarse de que el perfil está asignado correctamente.

Es importante tener en cuenta que después de la conmutación por error mediante Hyper-V Replica, las máquinas virtuales del sitio secundario quedarán sin administración. Los usuarios finales pueden usar Azure Virtual Desktop como lo harían normalmente, pero las máquinas virtuales no se podrán administrar desde el portal de la forma en que estaban antes de la conmutación por error. Para restaurar las funcionalidades de administración, se recomienda volver al sitio primario en cuanto se pueda restaurar.

retorno de réplica de Hyper-V

Se recomienda planear una ventana de mantenimiento para restaurar las máquinas virtuales al sitio primario una vez que esté operativo y funcional. Efectúe la replicación revertida de las máquinas virtuales al sitio primario, y verifique que los hosts sean accesibles y que la configuración de DNS sea la esperada.

Resistencia de varios clústeres

Otro enfoque de resistencia ante desastres para los grupos de hosts agrupados es dividir los hosts de sesión dentro de un grupo de hosts entre varios clústeres. Esto ofrece una redirección sin problemas en el caso de un único error de clúster con redundancia limitada.

Para configurar este enfoque:

  • Asegúrese de que ambos clústeres están configurados de la misma manera y que tienen la configuración de AD y DNS coincidentes.
  • Implemente hosts de sesión en ambos clústeres y agréguelos manualmente a los grupos host mediante el portal de Azure Virtual Desktop, PowerShell o la CLI de Azure.
  • Las sesiones equilibrarán la carga automáticamente entre clústeres según sea necesario. En este caso, use un servidor de archivos de Scale-Out para almacenar perfiles de FSLogix a los que ambos clústeres puedan acceder.

Para más información, consulte Azure Virtual Desktop para Azure Local.

Pasos siguientes

Más información sobre:

  • Last updated on