Confiabilidad en Azure Site Recovery

Azure Site Recovery es un servicio de replicación y conmutación por error administrado para máquinas virtuales (VM) que mantiene las cargas de trabajo disponibles durante las interrupciones. Replica continuamente las cargas de trabajo de los sitios primarios a las ubicaciones secundarias y limita la pérdida de datos y el tiempo de inactividad. Durante el mantenimiento planificado o interrupciones inesperadas, gestiona la conmutación por error y el retorno al estado operativo normal. Este servicio admite la recuperación ante desastres (DR) para entornos locales y máquinas virtuales de Azure, lo que ayuda a las organizaciones a mantener la continuidad empresarial.

Al usar Azure, relibilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Site Recovery sea resistente a varias posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. También resalta información clave sobre el acuerdo de nivel de servicio (SLA) de Site Recovery.

Nota:

En este artículo se describe cómo el servicio Site Recovery es resistente o cómo puede hacer que sea resistente a varios problemas. No explica cómo usar Site Recovery para proteger las máquinas virtuales u otros recursos. Para obtener más información, consulte Acerca de Site Recovery.

Recomendaciones de implementación de producción para la confiabilidad

Al usar Site Recovery con cargas de trabajo de producción, se recomienda realizar estas acciones:

  • Implemente la bóveda de Recovery Services en la región de destino para replicación.

  • Para la recuperación ante desastres de Azure a Azure, use la característica de alta renovación de Site Recovery para las máquinas virtuales que tienen una alta tasa de cambios en los datos. El soporte de alta rotación mejora el objetivo de punto de recuperación (RPO) y permite la replicación para muchas cargas de trabajo de bases de datos a gran escala.

  • Para la recuperación ante desastres de Azure a Azure, configure la cuenta de almacenamiento en caché para usar el almacenamiento con redundancia de zona (ZRS).

  • Realice pruebas de conmutación por error periódicamente como parte de los simulacros de recuperación ante desastres. Ejecute simulacros de recuperación ante desastres cada trimestre o semestralmente para comprobar que los procesos de replicación y conmutación por error son correctos.

  • Use reservas de capacidad a petición para asegurar que los recursos de computación están disponibles en la región de destino para la conmutación por falla.

  • Habilite las actualizaciones automáticas para agentes de movilidad.

  • Supervise el estado de la replicación y configure alertas para que se le notifique si se produce un problema.

Introducción a la arquitectura de confiabilidad

Cuando se usa Site Recovery, se define un origen y un destino, que representan las máquinas virtuales replicadas:

  • El origen puede ser una máquina virtual de Azure o una máquina virtual o un servidor de otro origen compatible, incluidos los servidores físicos locales, las máquinas virtuales de VMware y las máquinas virtuales de Hyper-V.

  • El target siempre es una máquina virtual de Azure. Para la replicación de máquinas virtuales de Azure a Azure, el destino puede ser una región o zona de disponibilidad diferente de la máquina virtual de origen.

Usted es responsable de implementar y configurar recursos y opciones relacionadas, entre las que se incluyen:

  • Recovery Services vault, que Site Recovery usa para almacenar las opciones de configuración de replicación. La bóveda no guarda tus datos replicados. La configuración de redundancia del almacén no es importante para Site Recovery, pero es importante si usa el mismo almacén para Azure Backup.

    Una bóveda puede incluir configuraciones adicionales, como:

    • Directiva de replicación, que configura la frecuencia de las instantáneas y la duración de retención.

    • Un plan de recuperación, que coordina el orden en el que las máquinas conmutan por error y pueden incluir scripts y acciones manuales. Los planes de recuperación son especialmente útiles para las workloads que tienen múltiples niveles, tales como los niveles de aplicación y base de datos, que deben realizar un failover en un orden específico.

  • Para la replicación de Azure a Azure, una cuenta de almacenamiento cache que almacena una copia de los datos de origen en su región antes de que se replique en el destino. La configuración de redundancia de la cuenta de almacenamiento en caché puede afectar a la confiabilidad durante una interrupción de la zona de disponibilidad.

Diagrama que muestra la relación entre la bóveda de Recovery Services, la cuenta de almacenamiento en caché, el origen y el destino en Site Recovery.

Nota:

Esta guía se centra en la confiabilidad de los componentes basados en Azure de Site Recovery y en la relación de replicación. Si replica datos o máquinas virtuales desde un entorno local u otro proveedor de nube, considere la confiabilidad de los componentes fuera de Azure.

Para obtener más información sobre los componentes que implemente, consulte los siguientes artículos:

El servicio principal Site Recovery se ejecuta en la infraestructura que Administra Microsoft. En este artículo se hace referencia a estos componentes colectivamente como el servicio principal de Site Recovery.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Site Recovery controla automáticamente los errores transitorios que se producen durante el proceso de replicación mediante el reintento de sus operaciones. No es necesario configurar el control de errores transitorios para Site Recovery.

Resistencia a errores de zona de disponibilidad

Availability zones son grupos de centros de datos físicamente independientes dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Para comprender cómo se comporta la replicación de Site Recovery durante los errores de zona de disponibilidad, debe tener en cuenta los siguientes componentes de servicio:

  • Servicio Core Site Recovery: El servicio principal de Site Recovery está diseñado para ser resistente a los errores de zona de disponibilidad en las regiones admitidas. Los componentes internos del servicio apoyan automáticamente la redundancia de zona sin necesidad de configuración por parte del cliente.

  • Bóveda de Recovery Services: La bóveda almacena los datos de configuración. En las regiones en las que Site Recovery admite la resiliencia de zona, los datos de configuración del almacén también son resilientes a la zona.

  • Cuenta de almacenamiento en caché: Para la replicación de Azure a Azure, usted es responsable de asegurarse de que la cuenta de almacenamiento de caché sea redundante a nivel de zona mediante su implementación en el nivel ZRS.

    Si usa el nivel de replicación de Azure Storage con almacenamiento redundante local (LRS) para su cuenta de almacenamiento en caché y falla una zona, Site Recovery podría no replicar los datos modificados recientemente a su destino.

Nota:

Site Recovery puede ayudarle a conmutar por error entre máquinas virtuales en diferentes zonas de disponibilidad. Para más información, consulte Habilitar la recuperación ante desastres de máquinas virtuales de Azure entre zonas de disponibilidad.

Requisitos

Compatibilidad con regiones:

  • Almacenes principales de Site Recovery Service y Recovery Services: Site Recovery es resistente a la zona en las siguientes regiones.

    Americas Europa Oriente Medio Asia Pacífico
    Centro de Chile Este de Austria Israel Central Centro de Indonesia
    Centro de México Norte de Italia Japón Occidental
    Oeste de EE. UU. 3 Centro de Polonia Oeste de Malasia
    Centro de España Norte de Nueva Zelanda

    Site Recovery está implementando compatibilidad con zonas de disponibilidad en todas las regiones habilitadas para zonas de disponibilidad. En las regiones que no aparecen en la tabla anterior como resistentes a la zona, los errores de zona pueden afectar a las operaciones.

  • Cuenta de almacenamiento en caché: Puede implementar una cuenta de almacenamiento de ZRS en todas las regiones habilitadas para zonas de disponibilidad.

Cost

Site Recovery se factura en función del número de instancias de máquina virtual protegidas, independientemente de su configuración de zona de disponibilidad. Para obtener más información, consulte Precios de Site Recovery.

Configurar soporte de zonas de disponibilidad

  • Core Site Recovery service: No se configura la resistencia de zona en el servicio principal Site Recovery. Microsoft proporciona resiliencia de zona en las regiones compatibles.

    Si Microsoft habilita la resistencia de zona en una región más adelante, los recursos de Site Recovery se benefician automáticamente de la resistencia de zona. No es necesario realizar ninguna acción.

  • Almacén de Recovery Services: Los almacenes de Recovery Services tienen una configuración de redundancia, pero Site Recovery no usa la configuración de redundancia del almacén. No es necesario configurar la bóveda para la redundancia de zona cuando usas Site Recovery.

  • Cache storage account: Cuando se usa la replicación de Azure a Azure, es responsable de crear la cuenta de almacenamiento de caché y de configurarla con el nivel adecuado de redundancia. Para que sea redundante de zona, configúrelo para el tipo de replicación ZRS. Para obtener más información, consulte Reliability en Azure Blob Storage.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando se usa Site Recovery en una región con compatibilidad con zonas de disponibilidad para el servicio principal, la cuenta de almacenamiento en caché está configurada para usar ZRS y todas las zonas de disponibilidad están operativas.

  • Operación entre zonas: El proceso de replicación puede usar la infraestructura en varias zonas de disponibilidad para desencadenar y ejecutar trabajos de replicación. El servicio administra esta infraestructura de forma transparente.

  • Replicación de datos entre zonas: Site Recovery y Storage controlan la replicación de datos de zona:

    • Configuración de Site Recovery: Site Recovery replica los datos de configuración entre zonas, incluso si configura el almacén para usar LRS.

    • Cuenta de almacenamiento en caché: Si configura la cuenta de almacenamiento de caché para que use ZRS, Storage replica de forma sincrónica los datos almacenados en caché entre zonas.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando se usa Site Recovery en una región con compatibilidad con la zona de disponibilidad para el servicio principal, la cuenta de almacenamiento en caché está configurada para usar ZRS y se produce una interrupción de zona de disponibilidad.

Nota:

Si la zona con errores contiene la máquina virtual de origen, usted es responsable de iniciar la conmutación por error al destino. Para obtener más información, consulte los artículos siguientes:

  • Detección y respuesta: La plataforma Site Recovery detecta automáticamente errores en una zona de disponibilidad e inicia una respuesta. No es necesario iniciar manualmente una conmutación por error de zona para el servicio principal de Site Recovery. Sin embargo, si la interrupción de zona afecta a la máquina virtual de origen, es posible que tenga que iniciar la conmutación por error de la máquina virtual.
  • Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

  • Solicitudes activas: El efecto en los trabajos de replicación activa depende del tipo de replicación:

    • Replicación de zona a zona y región a región de máquinas virtuales de Azure: Si la instancia de origen o de destino está en la zona con errores, la replicación se detiene hasta que ambas instancias estén disponibles de nuevo.

      Si la zona con errores no contiene la máquina virtual de origen o de destino y configuró la cuenta de almacenamiento en caché para usar ZRS, la replicación continúa ejecutándose.

    • On-premises para Azure: Si la instancia de destino está en la zona con errores, la replicación se detiene hasta que la instancia esté disponible de nuevo.

      Si la zona con errores no contiene la máquina virtual de destino, la replicación continúa ejecutándose.

  • Pérdida de datos esperada: No se espera ninguna pérdida de datos durante un error de zona.

  • Tiempo de inactividad esperado: Si la zona con errores contiene la máquina virtual de origen o de destino, la replicación se detiene hasta que ambas instancias estén disponibles de nuevo.

  • Redistribución: Site Recovery y Storage se adaptan automáticamente a errores de zona:

    • Servicio Core Site Recovery: El servicio principal de Site Recovery usa automáticamente la infraestructura en zonas de disponibilidad correctas para realizar la replicación. No es necesario realizar ninguna acción.

    • Cuenta de almacenamiento en caché: El almacenamiento enruta automáticamente las solicitudes de datos de caché a zonas correctas.

Recuperación de zona

Cuando se recupera la zona de disponibilidad afectada, Site Recovery reanuda automáticamente los trabajos de replicación que se pausan durante la interrupción de la zona.

Es responsable de iniciar la conmutación por recuperación para servidores o máquinas virtuales conmutadas por error durante la interrupción de la zona. Para obtener más información, consulte los artículos siguientes:

Prueba de fallos de zona

La plataforma Site Recovery administra la resistencia de zona para sus componentes internos. Esta característica está totalmente administrada, por lo que no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

Es importante realizar simulacros regulares de recuperación ante desastres, que deben probar la conmutación por error de la VM y los procedimientos generales de respuesta. Diseñe los simulacros de recuperación ante desastres para evitar el impacto en el entorno de producción. Para obtener más información, consulte los artículos siguientes:

Resistencia a errores en toda la región

Para la replicación de Azure a Azure, Site Recovery proporciona resistencia a los fallos de región al habilitar la conmutación por error de las máquinas virtuales (VMs) a una región de destino saludable. Para más información, consulte Replicar máquinas virtuales de Azure a otra región de Azure.

Consideraciones

  • Región del almacén: Implemente un almacén de Recovery Services en una región de Azure específica que seleccione. La región de la bóveda es importante. La replicación continúa durante una interrupción en la región de la bóveda. Sin embargo, no puede realizar operaciones de administración de Site Recovery, incluida la conmutación por error y el restablecimiento, hasta que la región se recupere.

    La implementación del almacén en la región de destino ayuda a garantizar que las operaciones de conmutación por error y recuperación permanezcan disponibles durante una interrupción de la región de origen. También evita que una interrupción en una tercera región afecte las operaciones de conmutación y recuperación.

    Nota:

    Si su bóveda está en la región que normalmente usa como región de destino, entonces, después de la conmutación por error y restablecimiento de la replicación, esa región se convierte en su nueva región de origen. Si esa región experimenta posteriormente un problema, posiblemente no pueda realizar la reversión de la conmutación hasta que ambas regiones estén funcionales.

  • Reservas de capacidad: Es responsable de comprobar que la región de destino admite los tipos de máquina virtual que necesita y que tiene capacidad disponible para la carga de trabajo. Se recomienda usar reservas de capacidad a petición para asegurarse de que los recursos de cómputo están disponibles para su carga de trabajo si se produce una conmutación por error.

Configuración de la compatibilidad con varias regiones

  • Almacén de Recovery Services: Debe seleccionar la región del almacén. Para más información, consulte Consideraciones.

    Las bóvedas de Servicios de Recuperación tienen una configuración de redundancia, pero Site Recovery no utiliza la configuración de redundancia de la bóveda. No es necesario configurar la bóveda para la redundancia geográfica al usar Site Recovery.

  • Cuenta de almacenamiento en caché: La cuenta de almacenamiento en caché solo se usa como ubicación temporal para los datos antes de que se replique, por lo que no debe configurarla para usar el almacenamiento con redundancia geográfica (GRS).

Comportamiento durante una falla de región

El comportamiento específico del servicio principal de Site Recovery durante un error de región depende de la región en la que experimente el error:

  • Error en la región de origen: Para la replicación de Azure a Azure, puede activar una conmutación por error automática cuando la región de origen no esté disponible.

    Dado que la región de origen no está disponible, la replicación se detiene hasta que la máquina virtual de la región de origen está en buen estado.

    Diagrama que muestra el comportamiento cuando se produce un error en la región de origen. El origen no está disponible y la replicación se detiene hasta que se recupera la región de origen.

  • Error en la región de destino: Dado que la región de destino no está disponible, la replicación se detiene y no se puede recuperar el destino hasta que la región esté operativa.

    Diagrama que muestra el comportamiento cuando se produce un error en la región de destino. La replicación se detiene y la conmutación por error no está disponible hasta que se recupera la región de destino.

  • Fallo en la región que contiene la bóveda: Si despliega la bóveda en una tercera región (no en la región de origen o de destino) y esa región experimenta un fallo, Site Recovery continuará replicando sus datos. Sin embargo, no puede iniciar ninguna operación, incluida la conmutación por error o la reversión, hasta que la bóveda esté en buen estado.

    Diagrama que muestra el comportamiento cuando se produce un error en la región de la bóveda. La replicación continúa, pero las operaciones de conmutación no están disponibles hasta que la región de la bóveda se restablezca.

Recuperación de regiones

Es responsable de iniciar la reversión para servidores o máquinas virtuales que conmutó durante la interrupción de la región. Para obtener más información, consulte los artículos siguientes:

Prueba de fallos de región

Es importante realizar simulacros de recuperación ante desastres regulares que prueben la conmutación por error de la VM y los procedimientos generales de respuesta. Diseñe los simulacros de recuperación ante desastres para evitar el impacto en el entorno de producción. Para obtener más información, consulte los artículos siguientes:

Resistencia a problemas de configuración y replicación

Una solución de recuperación ante desastres solo es confiable cuando sabe que funciona antes de que se produzca un desastre. Supervise Site Recovery para detectar problemas como errores de configuración o problemas de mantenimiento de replicación de máquinas virtuales. Para obtener más información, consulte Supervisión de Site Recovery.

Se recomienda configurar alertas de Azure Monitor para que se le informe sobre los problemas con el estado de replicación. Para más información, consulte Alertas integradas de Azure Monitor para Site Recovery.

Resistencia al mantenimiento del servicio

Azure administra automáticamente las actualizaciones y el mantenimiento del servicio principal Site Recovery. Las operaciones de mantenimiento no requieren tiempo de inactividad y no interrumpen la replicación de las máquinas virtuales y los servidores.

Sin embargo, es responsable de aplicar actualizaciones a los componentes de Site Recovery en las máquinas virtuales y servidores, incluido el agente de movilidad cuando sea necesario.

Importante

Se recomienda encarecidamente habilitar las actualizaciones automáticas para los agentes. Si la versión del agente queda más de cuatro versiones atrás, la replicación se desactiva y la capacidad de recuperación de la carga de trabajo se ve comprometida.

Para obtener más información, consulte actualizaciones de Service en Site Recovery.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, vea SLAs for online services.

Para Site Recovery, los Acuerdos de Nivel de Servicio independientes cubren:

  • Disponibilidad del servicio, lo que significa que Site Recovery está disponible para realizar una conmutación por error de las instancias protegidas. Una instancia protegida es una máquina virtual o un servidor físico que se replica en una ubicación secundaria. Para poder optar a este Acuerdo de Nivel de Servicio, debe reintentar los intentos fallidos de conmutación por error al menos cada 30 minutos.

  • Objetivo de tiempo de recuperación (RTO), que es el tiempo desde que se desencadena una conmutación por fallo (o cuando los scripts lo desencadenan) hasta cuando se ejecuta la máquina virtual de destino. Esta vez excluye acciones manuales o ejecución de scripts.

El Acuerdo de Nivel de Servicio solo proporciona créditos de servicio cuando la región secundaria tiene suficiente capacidad de proceso.

Contenido relacionado

  • Last updated on