Compartir a través de

Protección de máquinas virtuales implementadas en Azure Stack Hub

Use este artículo como guía para ayudarle a desarrollar una estrategia de protección de datos y recuperación ante desastres para máquinas virtuales IaaS implementadas por el usuario implementadas en Azure Stack Hub.

Para protegerse contra la pérdida de datos y el tiempo de inactividad extendido, implemente un plan de recuperación de copia de seguridad o recuperación ante desastres para las aplicaciones de usuario y sus datos. Cada aplicación debe evaluarse como parte de la estrategia completa de continuidad empresarial y recuperación ante desastres (BC/DR) de su organización.

Consideraciones para proteger máquinas virtuales IaaS

Roles y responsabilidades

En primer lugar, asegúrese de que hay un conocimiento claro de los roles y responsabilidades que se atribuyen a los propietarios y operadores de la aplicación en el contexto de la protección y recuperación.

Los usuarios son responsables de proteger las máquinas virtuales. Los operadores son responsables de mantener Azure Stack Hub en línea y en buen estado. Azure Stack Hub incluye un servicio que realiza una copia de seguridad de los datos de servicio internos de los servicios de infraestructura y no incluye ningún dato de usuario, incluidas las máquinas virtuales creadas por el usuario, las cuentas de almacenamiento con datos de usuario o de aplicación o bases de datos de usuario.

Propietario o arquitecto de la aplicación Operador de Azure Stack Hub
- Alineación de la arquitectura de aplicaciones con principios de diseño en la nube.
- Modernizar las aplicaciones tradicionales según sea necesario, para prepararlas para el entorno en la nube.
- Definir RTO y RPO aceptables para la aplicación.
- Identificar los recursos de la aplicación y los repositorios de datos que deben protegerse.
- Implemente un método de recuperación de datos y aplicaciones que mejor se alinee con la arquitectura de la aplicación y los requisitos de los clientes.		 - Identificar los objetivos de continuidad empresarial y recuperación ante desastres de la organización.
- Implemente suficientes instancias de Azure Stack Hub para cumplir los objetivos de BC/DR de la organización.
- Diseñar y operar la infraestructura de protección de datos y aplicaciones.
- Proporcionar soluciones administradas o acceso de autoservicio a los servicios de protección.
- Trabaje con propietarios o arquitectos de aplicaciones para comprender el diseño de aplicaciones y recomendar estrategias de protección.
- Habilite la copia de seguridad de infraestructura para la recuperación del servicio y la recuperación en la nube.

Combinaciones de origen y destino

Los usuarios que necesitan protegerse frente a una interrupción del centro de datos o del sitio pueden usar otra instancia de Azure Stack Hub o Azure para proporcionar alta disponibilidad o recuperación rápida. Con la ubicación principal y secundaria, los usuarios pueden implementar aplicaciones en una configuración activa,activa o activa/pasiva en dos entornos. Para cargas de trabajo menos críticas, los usuarios pueden usar la capacidad en la ubicación secundaria para realizar la restauración a petición de las aplicaciones desde la copia de seguridad.

Una o varias nubes de Azure Stack Hub se pueden implementar en un centro de datos. Para sobrevivir a un desastre catastrófico, la implementación de al menos una nube de Azure Stack Hub en un centro de datos diferente garantiza que puede conmutar por error las cargas de trabajo y minimizar el tiempo de inactividad no planeado. Si solo tiene una instancia de Azure Stack Hub, debe considerar la posibilidad de usar la nube pública de Azure como nube de recuperación. La determinación de dónde se puede ejecutar la aplicación se determinará mediante normativas gubernamentales, directivas corporativas y requisitos estrictos de latencia. Tiene la flexibilidad de determinar la ubicación de recuperación adecuada por aplicación. Por ejemplo, puede hacer que las aplicaciones de una suscripción realicen copias de seguridad de datos en otro centro de datos y en otra suscripción, replicando datos en la nube pública de Azure.

Objetivos de recuperación de aplicaciones

Los propietarios de aplicaciones son principalmente responsables de determinar la cantidad de tiempo de inactividad y pérdida de datos que la aplicación y la organización pueden tolerar. Al cuantificar el tiempo de inactividad aceptable y la pérdida de datos aceptable, puede crear un plan de recuperación que minimice el impacto de un desastre en su organización. Para cada aplicación, tenga en cuenta lo siguiente:

  • Objetivo de tiempo de recuperación (RTO)
    RTO es el tiempo máximo aceptable que una aplicación puede no estar disponible después de un incidente. Por ejemplo, un RTO de 90 minutos significa que debe poder restaurar la aplicación a un estado en ejecución en un plazo de 90 minutos desde el inicio de un desastre. Si tiene un RTO bajo, es posible que mantenga una segunda implementación ejecutándose continuamente en espera para protegerse frente a una interrupción regional.
  • Objetivo de punto de recuperación (RPO)
    El RPO es la duración máxima de la pérdida de datos que es aceptable durante un desastre. Por ejemplo, si almacena datos en una base de datos única, que se realiza una copia de seguridad por hora y no tiene replicación en otras bases de datos, podría perder hasta una hora de datos.

Otra métrica es Tiempo medio de recuperación (MTTR), que es el tiempo medio que se tarda en restaurar la aplicación después de un error. MTTR es un valor empírico para un sistema. Si MTTR supera el RTO, un error en el sistema provoca una interrupción empresarial inaceptable porque no será posible restaurar el sistema dentro del RTO definido.

Opciones de protección

Copia de seguridad y restauración

La copia de seguridad de las aplicaciones y los conjuntos de datos le permite recuperarse rápidamente del tiempo de inactividad debido a daños en los datos, eliminaciones accidentales o desastres. En el caso de las aplicaciones basadas en máquinas virtuales iaaS, puede usar un agente invitado para proteger los datos de la aplicación, la configuración del sistema operativo y los datos almacenados en volúmenes.

Copia de seguridad mediante el agente invitado

La copia de seguridad de una máquina virtual mediante un agente del sistema operativo invitado normalmente incluye la captura de la configuración del sistema operativo, archivos o carpetas, discos, archivos binarios de aplicaciones o datos de la aplicación.

La recuperación de una aplicación de un agente requiere volver a crear manualmente la máquina virtual, instalar el sistema operativo e instalar el agente invitado. En ese momento, los datos se pueden restaurar en el sistema operativo invitado o directamente en la aplicación.

Copia de seguridad mediante instantánea de disco para máquinas virtuales detenidas

Los productos de copia de seguridad pueden proteger la configuración de máquinas virtuales IaaS y los discos conectados a una máquina virtual detenida. Use productos de copia de seguridad que se integran con las API de Azure Stack Hub para capturar la configuración de la máquina virtual y crear instantáneas de disco. Si es posible un tiempo de inactividad planeado para la aplicación, asegúrese de que la máquina virtual está en un estado detenido antes de iniciar el flujo de trabajo de copia de seguridad.

Copia de seguridad mediante instantánea de disco para ejecutar máquinas virtuales

Importante

El uso de instantáneas de disco desde el portal no se admite actualmente para la máquina virtual en un estado en ejecución. La creación de una instantánea de un disco conectado a una máquina virtual en ejecución puede degradar el rendimiento o afectar a la disponibilidad del sistema operativo o la aplicación en la máquina virtual. La recomendación es usar una solución de proveedor de copia de seguridad que se integre con la funcionalidad de instantánea incremental de RP de almacenamiento o un agente invitado para proteger la aplicación si el tiempo de inactividad planeado no es una opción.

Máquinas virtuales de un conjunto de escalado o un conjunto de disponibilidad

Las máquinas virtuales de un conjunto de escalado o un grupo de disponibilidad que se consideran recursos efímeros no se deben realizar copias de seguridad en el nivel de máquina virtual, especialmente si la aplicación no tiene estado. Para las aplicaciones con estado implementadas en un conjunto de escalado o un conjunto de disponibilidad, considere la posibilidad de proteger los datos de la aplicación (por ejemplo, una base de datos o un volumen en un grupo de almacenamiento).

Replicación/conmutación por error manual

En el caso de las aplicaciones que requieren una pérdida de datos mínima o un tiempo de inactividad mínimo, la replicación de datos se puede habilitar en el nivel de sistema operativo invitado o aplicación para replicar datos en otra ubicación. Algunas aplicaciones, como Microsoft SQL Server, admiten de forma nativa la replicación. Si la aplicación no admite la replicación, puede usar software en el sistema operativo invitado para replicar discos o una solución de asociado que se instale como agente en el sistema operativo invitado.

Con este enfoque, la aplicación se implementa en una nube y los datos se replican en la otra nube local o en Azure. Cuando se desencadena una conmutación por error, la aplicación del destino debe iniciarse y adjuntarse a los datos replicados antes de poder iniciar las solicitudes de mantenimiento.

Alta disponibilidad/conmutación automática por error

En el caso de las aplicaciones sin estado que solo pueden tolerar unos segundos o minutos de tiempo de inactividad, considere una configuración de alta disponibilidad. Las aplicaciones de alta disponibilidad están diseñadas para implementarse en varias ubicaciones en una topología activa o activa donde todas las instancias pueden atender las solicitudes. En el caso de los errores de hardware local, la infraestructura de Azure Stack Hub implementa alta disponibilidad en la red física mediante dos conmutadores de bastidor superior. En el caso de los errores de nivel de proceso, Azure Stack Hub usa varios nodos en una unidad de escalado y conmutará por error automáticamente una máquina virtual. En el nivel de máquina virtual, puede usar conjuntos de escalado o máquinas virtuales en el conjunto de disponibilidad para asegurarse de que los errores de nodo no quitan la aplicación. La misma aplicación tendría que implementarse en una ubicación secundaria en la misma configuración. Para que la aplicación esté activa o activa, se puede usar un equilibrador de carga o DNS para dirigir las solicitudes a todas las instancias disponibles.

Sin recuperación

Es posible que algunas aplicaciones del entorno no necesiten protección contra el tiempo de inactividad no planeado o la pérdida de datos. Por ejemplo, las máquinas virtuales que se usan para el desarrollo y las pruebas normalmente no necesitan recuperarse. Es la decisión de hacerlo sin protección para una aplicación o un conjunto de datos.

Consideraciones importantes para la implementación de Azure Stack Hub:

Recomendación Comentarios
Copia de seguridad o restauración de máquinas virtuales en un destino de copia de seguridad externo ya implementado en el centro de datos Recomendado Aproveche las ventajas de las aptitudes operativas y la infraestructura de copia de seguridad existentes. Asegúrese de ajustar el tamaño de la infraestructura de copia de seguridad para que esté listo para proteger las instancias de máquina virtual adicionales. Asegúrese de que la infraestructura de copia de seguridad no está cerca del origen. Puede restaurar máquinas virtuales al origen de Azure Stack Hub, a una instancia secundaria de Azure Stack Hub o a Azure.
Copia de seguridad y restauración de máquinas virtuales en un destino de copia de seguridad externo dedicado a Azure Stack Hub Recomendado Puede comprar una nueva infraestructura de copia de seguridad o aprovisionar una infraestructura de copia de seguridad dedicada para Azure Stack Hub. Asegúrese de que la infraestructura de copia de seguridad no está cerca del origen. Puede restaurar máquinas virtuales al origen de Azure Stack Hub, a una instancia secundaria de Azure Stack Hub o a Azure.
Copia de seguridad o restauración de máquinas virtuales directamente en Azure global o en un proveedor de servicios de confianza Recomendado Siempre que pueda cumplir los requisitos normativos y privacidad de los datos, puede almacenar las copias de seguridad en Azure global o en un proveedor de servicios de confianza. Lo ideal es que el proveedor de servicios también ejecute Azure Stack Hub para obtener coherencia en la experiencia operativa al restaurar.
Replicación o conmutación por error de máquinas virtuales en una instancia independiente de Azure Stack Hub Recomendado En el caso de conmutación por error, debe tener una segunda nube de Azure Stack Hub totalmente operativa para que pueda evitar un tiempo de inactividad extendido de la aplicación.
Replicación o conmutación por error de máquinas virtuales directamente en Azure o en un proveedor de servicios de confianza Recomendado Siempre que pueda cumplir los requisitos normativos y privacidad de los datos, puede replicar los datos en Azure global o en un proveedor de servicios de confianza. Lo ideal es que el proveedor de servicios también ejecute Azure Stack Hub para obtener coherencia en la experiencia operativa después de la conmutación por error.
Implemente un destino de copia de seguridad en la misma instancia de Azure Stack Hub que también hospede todas las aplicaciones protegidas por el mismo destino de copia de seguridad. Destino independiente: no recomendado
: destino que replica datos de copia de seguridad externamente: recomendado		 Si decide implementar un dispositivo de copia de seguridad en Azure Stack Hub (con el fin de optimizar la restauración operativa), debe asegurarse de que todos los datos se copian continuamente en una ubicación de copia de seguridad externa.
Implementación del dispositivo de copia de seguridad físico en el mismo bastidor donde está instalada la solución de Azure Stack Hub No está soportado Actualmente, no puede conectar ningún otro dispositivo a la parte superior de los conmutadores de bastidor que no forman parte de la solución original.

Consideraciones para una máquina virtual IaaS restaurada

Deberá realizar algunos cambios en la máquina virtual después de restaurar la máquina a partir de la copia de seguridad. Estos incluyen:

  • Dirección MAC
    El adaptador de red virtual obtendrá una nueva dirección MAC. No hay un método para conservar la dirección MAC original.
  • Dirección IP
    Si la máquina virtual tiene una dirección IP estática establecida internamente, la dirección IP interna del adaptador de red virtual se puede establecer para que coincida con el original. Es posible que tenga que tener en cuenta si la red virtual tiene una VPN de S2S en un entorno externo en el que la dirección IP podría estar en uso.
  • Artefactos innecesarios
    Si se realizó una copia de seguridad de la máquina virtual en otra plataforma, como VMware vSphere, deberá seguir algunos pasos adicionales para limpiar los artefactos innecesarios del origen.

Pasos siguientes

En este artículo se proporcionan instrucciones generales para proteger las máquinas virtuales de usuario implementadas en Azure Stack Hub. Para obtener información sobre el uso de servicios de Azure para proteger las máquinas virtuales de usuario, consulte:

  • Last updated on