Copia de seguridad y recuperación ante desastres para aplicaciones de Azure

  • Artículo
  • Tiempo de lectura: 7 minutos

La recuperación ante desastres es el proceso de restaurar la funcionalidad de una aplicación a consecuencia de una pérdida catastrófica.

en la nube somos conscientes de antemano de que se producirán errores. En lugar de intentar evitar todos los errores, el objetivo es minimizar los efectos que pueden provocar los errores de un único componente. La prueba es una manera de minimizar estos efectos. Debe automatizar las pruebas de las aplicaciones siempre que sea posible, pero debe estar preparado para cuando se produzca un error. Cuando esto sucede, es importante disponer de estrategias de copia de seguridad y recuperación.

La tolerancia a una funcionalidad reducida durante un desastre es una decisión empresarial que varía de una aplicación a otra. En el caso de algunas aplicaciones, puede ser aceptable que no estén disponibles o que lo estén de forma parcial con funcionalidad reducida o retrasos en el procesamiento durante un tiempo. Sin embargo, en el caso de otras, cualquier funcionalidad reducida es inaceptable.

Puntos clave

  • Cree y pruebe un plan de recuperación ante desastres de forma periódica mediante escenarios de errores clave.
  • Diseñe estrategias de recuperación ante desastres para ejecutar la mayoría de las aplicaciones con funcionalidad reducida.
  • Diseñe una estrategia de copia de seguridad que se adapte a los requisitos empresariales y a las circunstancias de la aplicación.
  • Automatice los pasos y procesos de conmutación por error y conmutación por recuperación.
  • Pruebe y valide el enfoque de conmutación por error y conmutación por recuperación correctamente al menos una vez.

Plan de recuperación ante desastres

Comience por crear un plan de recuperación. El plan se considera completo una vez que se ha probado totalmente. Incluya las personas, las aplicaciones y los procesos necesarios para restaurar la funcionalidad dentro del Acuerdo de Nivel de Servicio (SLA) que haya definido para los clientes.

Al crear y probar el plan de recuperación ante desastres, tenga en cuenta las siguientes sugerencias:

  • Incluya el proceso para ponerse en contacto con el soporte técnico y escalar los problemas. Esta información le ayudará a evitar un tiempo de inactividad prolongado cuando trabaje en el proceso de recuperación por primera vez.
  • Evalúe el impacto de negocio de los errores de las aplicaciones.
  • Elija una arquitectura de recuperación entre regiones para las aplicaciones críticas.
  • Designe un propietario específico del plan de recuperación ante desastres, incluida la automatización y las pruebas.
  • Documente el proceso, en especial los pasos manuales.
  • Automatice el proceso lo más posible.
  • Establezca una estrategia de copia de seguridad para todos los datos transaccionales y de referencia, y pruebe la restauración de copias de seguridad con regularidad.
  • Configure alertas para la pila de los servicios de Azure que usa la aplicación.
  • Entrene al personal de operaciones para que ejecute el plan.
  • Realice simulaciones de desastres periódicas para validar y mejorar el plan.

Si usa Azure Site Recovery para replicar máquinas virtuales, cree un plan de recuperación completamente automatizado para conmutar por error toda la aplicación.

Pruebas de preparación operativa

Realice una prueba de preparación operativa de la conmutación por error a la región secundaria y de la conmutación por recuperación a la región primaria. Muchos servicios de Azure admiten la conmutación por error manual o la conmutación por error de prueba para maniobras de recuperación ante desastres. Como alternativa, puede simular una interrupción mediante el apagado o la eliminación de servicios de Azure.

Las respuestas operativas automatizadas se deben probar con frecuencia como parte del ciclo de vida normal de la aplicación para garantizar la eficacia operativa.

Pruebas de conmutación por error y conmutación por recuperación

Pruebe la conmutación por error y la conmutación por recuperación para comprobar que los servicios dependientes de la aplicación se recuperen de manera sincronizada durante la recuperación ante desastres. Los cambios realizados en los sistemas y las operaciones pueden afectar a las funciones de conmutación por error y conmutación por recuperación, pero puede que no se detecte el efecto hasta que el sistema principal genere un error o se sobrecargue. Pruebe las funcionalidades de conmutación por error antes de que sean necesarias para solucionar un problema real. Asegúrese también de que los servicios dependientes realicen la conmutación por error y la conmutación por recuperación en el orden correcto.

Si usa Azure Site Recovery para replicar máquinas virtuales, ejecute simulacros de recuperación ante desastres periódicamente mediante la realización de pruebas de conmutación por error a fin de validar la estrategia de replicación. La conmutación por error de prueba no afecta a la replicación de la máquina virtual en curso ni al entorno de producción. Para más información, consulte Ejecución de un simulacro de recuperación ante desastres en Azure.

Interrupción de los servicios dependientes

Es necesario comprender las implicaciones de la interrupción de los servicios dependientes y la manera en que responderá la aplicación. Muchos servicios incluyen características que sustentan la resistencia y la disponibilidad, por lo que es probable que la evaluación de cada servicio de forma independiente mejore el plan de recuperación ante desastres. Por ejemplo, Azure Event Hubs admite conmutación por error al espacio de nombres secundario.

Interrupción de la red

Cuando no se puede acceder a algunas partes de la red de Azure, es posible que le esté vetado el acceso a la aplicación o a los datos. En esta situación, se recomienda diseñar la estrategia de recuperación ante desastres de forma que la mayoría de las aplicaciones se ejecuten con funcionalidad reducida.

Si esto no es viable, las otras opciones posibles son el tiempo de inactividad de la aplicación o la conmutación por error a otra región.

En un escenario de funcionalidad reducida:

  • Si la aplicación no puede acceder a sus datos debido a una interrupción de la red de Azure, podría trabajar localmente con funcionalidad reducida de la aplicación mediante los datos almacenados en caché.
  • También podría almacenar los datos en una ubicación alternativa hasta que se restaure la conectividad.

Automatización de la recuperación

Los pasos necesarios para recuperar o conmutar por error la aplicación en una región secundaria de Azure en situaciones de error se deben codificar, preferiblemente de manera automatizada. De este modo, se asegura de que existen funcionalidades para responder de manera eficaz a una interrupción de una manera que limite el impacto. También deben existir pasos codificados similares para capturar el proceso necesario para realizar una conmutación por recuperación de la aplicación en la región primaria una vez que se haya solucionado el problema que activó la conmutación por error.

Al automatizar los procedimientos de conmutación por error, asegúrese de que las herramientas que se usan para organizar la conmutación por error también se consideran en la estrategia de conmutación por error. Por ejemplo, si ejecuta la conmutación por error de Jenkins que se ejecuta en una máquina virtual, tendrá problemas si la máquina virtual forma parte de la interrupción. Azure DevOps Projects también tiene como ámbito una región.

Estrategia de copia de seguridad

Existen muchas estrategias alternativas para implementar el proceso distribuido entre regiones. Estas se deben adaptar a los requisitos empresariales específicos y a las circunstancias de la aplicación. En un nivel alto, los enfoques pueden dividirse en las siguientes categorías:

  • Volver a implementar en caso de desastre: En este enfoque, la aplicación se vuelve a implementar desde cero en el momento del desastre. Esto es adecuado para aplicaciones que no son esenciales y que no requieren un tiempo de recuperación garantizado.

  • Reserva semiactiva (activa/pasiva): se crea un servicio hospedado secundario en una región alternativa y se implementan los roles para garantizar una capacidad mínima; sin embargo, los roles no reciben el tráfico de producción. Este enfoque es útil para las aplicaciones que no se han diseñado para distribuir el tráfico entre las regiones.

  • Reserva activa (activa/activa): la aplicación está diseñada para recibir la carga de producción en varias regiones. Los servicios en la nube de cada región pueden configurarse para una capacidad mayor de la necesaria para fines de recuperación ante desastres. Como alternativa, se podrían escalar horizontalmente los servicios en la nube según sea necesario en el momento de un desastre y una conmutación por error. Este enfoque requiere una inversión sustancial en el diseño de la aplicación, pero tiene ventajas significativas. Estas incluyen un tiempo de recuperación bajo y garantizado, la comprobación continua de todas las ubicaciones de recuperación y un uso eficiente de la capacidad.

Plan de cara a los errores regionales

Azure se divide física y lógicamente en unidades denominadas regiones. Una región consta de uno o varios centros de datos muy cercanos. Muchas regiones y servicios también admiten zonas de disponibilidad, que se pueden usar para proporcionar más resistencia frente a interrupciones en un único centro de datos. Considere la posibilidad de usar regiones con zonas de disponibilidad para mejorar la disponibilidad de la solución.

En raras ocasiones es posible que no se pueda acceder a las instalaciones de toda una zona de disponibilidad o región debido, por ejemplo, a errores en la red. O bien, las instalaciones pueden perderse por completo debido, por ejemplo, a un desastre natural. Azure tiene funcionalidades para crear aplicaciones que se distribuyen entre zonas y regiones. Esta distribución ayuda a minimizar la posibilidad de que un error en una zona o una región pueda afectar a otras.

Paso siguiente

Control de errores

Volver al artículo principal: Prueba