Recuperación ante desastres para una plataforma de datos de Azure: recomendaciones

Lecciones aprendidas

1. Asegúrese de que todas las partes implicadas comprendan la diferencia entre alta disponibilidad (HA) y recuperación ante desastres (DR): un problema común consiste en confundir los dos conceptos y no ajustar correctamente las soluciones asociadas a ellos
2. Hable con las partes interesadas de la empresa sobre sus expectativas con respecto a los siguientes aspectos para definir los objetivos de punto de recuperación (RPO) y los objetivos de tiempo de recuperación (RTO):
   1. Cuánto tiempo de inactividad pueden tolerar, teniendo en cuenta que, normalmente, cuanto más rápida sea la recuperación, mayor será el costo.
   2. Tipo de incidentes frente a los que quieren protegerse, mencionando la probabilidad relacionada de dicho evento. Por ejemplo, la probabilidad de que un servidor deje de funcionar es mayor que la de un desastre natural que afecte a todos los centros de datos de una región.
   3. ¿Qué impacto tiene la no disponibilidad del sistema en su negocio?
   4. Presupuesto de OPEX para la solución en el futuro
3. Tenga en cuenta las opciones de servicio degradadas que pueden aceptar los usuarios finales. Entre ellas, se pueden incluir las siguientes:
   1. Seguir teniendo acceso a los paneles de visualización incluso sin los datos más actualizados, por ejemplo, si las canalizaciones de ingesta no funcionan, los usuarios finales seguirán teniendo acceso a sus datos.
   2. Tener acceso de lectura pero sin acceso de escritura
4. Las métricas objetivo de RTO y RPO pueden definir qué estrategia de recuperación ante desastres se decide implementar:
   1. activa/activa
   2. activa/pasiva
   3. Activo/Volver a implementar en caso de desastre
   4. Confiar en el SLA de Microsoft
5. Asegúrese de comprender todos los componentes que podrían afectar a la disponibilidad de los sistemas, como los siguientes:
   1. Administración de identidades
   2. Topología de red
   3. Administración de secretos y claves
   4. Orígenes de datos
   5. Automatización/programador de trabajos
   6. Repositorio de código fuente y canalizaciones de implementación (GitHub, Azure DevOps)
6. La detección temprana de interrupciones también es una manera de reducir significativamente los valores de RTO y RPO. Estos son algunos aspectos que se deben tratar:
   1. Defina qué es una interrupción y cómo se alinea con la definición de Microsoft de una interrupción. La definición de Microsoft está disponible en la página Contratos de nivel de servicio de Azure en el nivel de producto o servicio.
   2. Un sistema eficaz de supervisión y alertas con equipos responsables de revisar esas métricas y alertas de forma oportuna ayudará a cumplir el objetivo
7. Los Acuerdo de Nivel de Servicio compuestos significan que cuantos más componentes tenga en la arquitectura, mayor será la probabilidad de un error. Puede usar el Acuerdo de Nivel de Servicio compuesto para definir las posibilidades de una interrupción de componentes.
8. Con respecto al diseño de la suscripción, la infraestructura adicional para la recuperación ante desastres se puede almacenar en la suscripción original. Los servicios PaaS como ADLS Gen2 o Azure Data Factory suelen tener características nativas que permiten la conmutación por error a instancias secundarias de otras regiones mientras permanecen contenidos en la suscripción original. Es posible que algunos clientes quieran considerar la posibilidad de tener un grupo de recursos dedicados para los recursos usados solo en escenarios de recuperación ante desastres con fines de costos.
   1. Se debe tener en cuenta que los límites de suscripción pueden actuar como una restricción para este enfoque
   2. Otras restricciones pueden incluir la complejidad del diseño y los controles de administración para asegurarse de que los grupos de recursos de recuperación ante desastres no se usen para los flujos de trabajo de BAU.
9. Diseñe el flujo de trabajo de recuperación ante desastres en función de la importancia crítica y las dependencias de una solución. Por ejemplo, no intente volver a crear una instancia de Azure Analysis Services antes de que el almacenamiento de datos esté en funcionamiento, ya que se desencadenará un error. Deje los laboratorios de desarrollo más adelante en el proceso, recupere primero las soluciones empresariales principales.
10. Intente identificar las tareas de recuperación que se pueden realizar en paralelo en las distintas soluciones, lo que reduce el RTO total.
11. Si se usa Azure Data Factory en una solución, no olvide incluir los entornos de ejecución de integración autohospedados en el ámbito. Azure Site Recovery es ideal para esas máquinas.
12. Las operaciones manuales se deben automatizar tanto como sea posible para evitar errores humanos, especialmente cuando están bajo presión. Se recomienda lo siguiente:
    1. Adoptar el aprovisionamiento de recursos mediante Bicep, plantillas de ARM o scripts de PowerShell
    2. Adoptar el control de versiones del código fuente y la configuración de recursos
    3. Utilizar canalizaciones de versión de CI/CD en lugar de operaciones basadas en clics
13. Puesto que tiene un plan para la conmutación por error, debe tener en cuenta los procedimientos para la conmutación por recuperación a las instancias principales
14. Defina indicadores y métricas claros para validar que la conmutación por error se haya realizado correctamente y que las soluciones están en funcionamiento, o que la situación ha vuelto a la normalidad (también conocido como funcional principal)
15. Decida si los Acuerdos de Nivel de Servicio deben permanecer iguales después de una migración tras error o si va a permitir un servicio degradado.
    1. Esta decisión dependerá en gran medida del proceso de servicio empresarial que se admita. Por ejemplo, la conmutación por error de un sistema de reserva de habitaciones tendrá un aspecto muy diferente al de un sistema de operaciones principal
16. Una definición de RTO/RPO se debe basar en escenarios o soluciones de usuario específicos en lugar de en el nivel de infraestructura. Le proporcionará más granularidad sobre qué procesos y componentes se deben recuperar primero si hay una interrupción o un desastre.
17. Asegúrese de incluir comprobaciones de capacidad en la región de destino antes de continuar con una migración tras error: si hay un desastre importante, tenga en cuenta que muchos clientes intentarán migrar tras error a la misma región emparejada al mismo tiempo, lo que puede provocar retrasos o contención en el aprovisionamiento de los recursos.
    1. Si estos riesgos son inaceptables, se debe considerar una estrategia de recuperación ante desastres activo/activo o activo/pasivo.
18. Se debe crear y mantener un plan de recuperación ante desastres para documentar el proceso de recuperación y los propietarios de las acciones. Además, tenga en cuenta que las personas pueden estar de baja, por lo que debe asegurarse de incluir contactos secundarios
19. Se deben realizar simulacros de recuperación ante desastres regulares para validar el flujo de trabajo del plan de recuperación ante desastres, que cumpla con el RTO o RPO obligatorio y para entrenar a los equipos responsables.
    1. Las copias de seguridad de los datos y de la configuración también deben probarse regularmente para garantizar que son "aptas" para apoyar cualquier actividad de recuperación.
20. La colaboración temprana con los equipos responsables de redes, identidades y aprovisionamiento de recursos habilitará el acuerdo sobre la solución óptima con respecto a:
    1. Cómo redirigir usuarios y tráfico desde el sitio principal al sitio secundario. Se pueden evaluar conceptos como el redireccionamiento DNS o el uso de herramientas específicas, como Azure Traffic Manager
    2. Cómo proporcionar acceso y derechos al sitio secundario de forma oportuna y segura
21. Durante un desastre, la comunicación eficaz entre las muchas partes implicadas es clave para la ejecución eficaz y rápida del plan:
    1. Responsables de la toma de decisiones
    2. Equipo de respuesta a incidentes
    3. Audiencia interna afectada
    4. Equipos externos
22. La orquestación de los distintos recursos en el momento adecuado garantizará la eficacia en la ejecución del plan de recuperación ante desastres.

Consideraciones

Antipatrones

• Copiar y pegar esta serie de artículos Esta serie de artículos está pensada para proporcionar instrucciones a los clientes que buscan el siguiente nivel de detalle para un proceso de recuperación ante desastres específico de Azure. Por lo tanto, se basa en la propiedad intelectual genérica de Microsoft y las arquitecturas de referencia en lugar de en una implementación individual de Azure específica del cliente.
  Aunque los detalles proporcionados ayudarán a tener una comprensión sólida, los clientes deben aplicar su propio contexto, implementación y requisitos específicos antes de obtener una estrategia y un proceso de recuperación ante desastres "aptas".

• Tratar la recuperación ante desastres como un proceso únicamente tecnológico Las partes interesadas de la empresa desempeñan un papel fundamental a la hora de definir los requisitos de recuperación ante desastres y completar los pasos de validación empresarial necesarios para confirmar una recuperación del servicio. Asegurarse de que las partes interesadas de la empresa estén implicadas en todas las actividades de recuperación ante desastres proporcionará un proceso de recuperación ante desastres que sea "apto", represente valor empresarial y sea ejecutable.

• "Establecer y olvidar" los planes de recuperación ante desastres Azure está evolucionando constantemente, al igual que el uso de varios componentes y servicios por parte del cliente individual. Un proceso de recuperación ante desastres "apto" debe evolucionar con ellos. Mediante el proceso SDLC o las revisiones periódicas, los clientes deben revisar periódicamente su plan de recuperación ante desastres. El objetivo es garantizar la validez del plan de recuperación del servicio y de que se hayan tenido en cuenta las diferencias entre componentes, servicios o soluciones.

• Evaluaciones basadas en papel Aunque la simulación completa de un evento de recuperación ante desastres será difícil en un ecosistema de datos moderno, se deben realizar esfuerzos para llegar lo más cerca posible de una simulación completa en todos los componentes afectados. Los simulacros programados periódicamente crearán la "memoria muscular" requerida por la organización para poder ejecutar el plan de recuperación ante desastres con confianza.

• Confiar en Microsoft para hacerlo todo Dentro de los servicios de Microsoft Azure, hay una división de responsabilidades clara, delimitada por el nivel de servicio en la nube que se utilice: Incluso si se usa una pila de SaaS completa, el cliente seguirá conservando la responsabilidad de asegurarse de que las cuentas, las identidades y los datos sean correctos y actualizados, junto con los dispositivos usados para interactuar con los servicios de Azure.

Estrategia y ámbito del evento

Ámbito del evento de desastre

Los distintos eventos tendrán un ámbito diferente de impacto y, por lo tanto, una respuesta diferente. En el diagrama siguiente, se muestra esto para un evento de desastre:

Opciones de estrategia ante desastres

Hay cuatro opciones generales para una estrategia de recuperación ante desastres:

• Esperar a Microsoft: como sugiere el nombre, la solución está sin conexión hasta la recuperación completa de los servicios en la región afectada por parte de Microsoft. Una vez recuperado, el cliente valida la solución y, a continuación, se actualiza para la recuperación del servicio.
• Reimplementación en caso de desastre: la solución se vuelve a implementar manualmente en una región disponible desde cero y después del evento de desastre.
• Reserva semiactiva (activo/pasivo): se crea una solución secundaria hospedada en una región alternativa y se implementan los componentes para garantizar una capacidad mínima; sin embargo, los componentes no reciben tráfico de producción. Los servicios secundarios de la región alternativa pueden estar "desactivados" o ejecutarse en un nivel de rendimiento inferior hasta que se produzca un evento de recuperación ante desastres.
• Reserva activa (activo/activo): la solución se hospeda en una configuración activo/activo en varias regiones. La solución hospedada secundaria recibe, procesa y sirve datos como parte de un sistema mayor.

Impactos en la estrategia de recuperación ante desastres

Aunque el costo operativo que se atribuye a los niveles más altos de resistencia del servicio domina con frecuencia la decisión de diseño clave (KDD) de una estrategia de recuperación ante desastres, hay otras consideraciones importantes.

El escenario de recuperación ante desastres de este ejemplo de trabajo es una interrupción regional completa de Azure que afecta directamente a la región primaria que hospeda la plataforma de datos de Contoso. En este escenario de interrupción, el impacto relativo en las cuatro estrategias generales de recuperación ante desastres es:

Clave de clasificación

• Objetivo de tiempo de recuperación (RTO): tiempo esperado transcurrido desde el evento de desastre hasta la recuperación del servicio de plataforma
• Complejidad de ejecución: complejidad para la organización de la ejecución de las actividades de recuperación
• Complejidad de implementación: complejidad para la organización de la implementación de la estrategia de recuperación ante desastres
• Impacto en los clientes: impacto directo en los clientes del servicio de plataforma de datos de la estrategia de recuperación ante desastres
• Costo de OPEX de la línea anterior: costo adicional esperado de implementar esta estrategia, como el aumento de la facturación mensual de Azure para los componentes adicionales y los recursos adicionales necesarios para posibilitarla

Pasos siguientes

Ahora que ha aprendido sobre las recomendaciones relacionadas con el escenario, puede obtener información sobre cómo implementar este escenario.

Recursos relacionados

• Recuperación ante desastres para la plataforma de datos de Azure: información general
• Recuperación ante desastres para una plataforma de datos de Azure: arquitectura
• Recuperación ante desastres en la plataforma de datos de Azure: detalles del escenario
• Recuperación ante desastres para la plataforma de datos de Azure: resumen