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 coincidir las soluciones asociadas a ellas.
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ápido 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 baje es mayor que un desastre natural que afecta 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 gastos operativos (OPEX) para la solución.
3. Tenga en cuenta las opciones de servicio degradadas que pueden aceptar los usuarios finales. Entre ellas, se pueden incluir las siguientes:
   1. Aún teniendo acceso a los paneles de visualización incluso sin los datos más actualizados, es decir, si las canalizaciones de ingesta no funcionan, los usuarios finales todavía tienen 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. Activo/Activo.
   2. Activo/Pasivo.
   3. Activo o reimplementación en caso de desastre.
   4. Considere su propio objetivo de nivel de servicio compuesto (SLO) para tener en cuenta los tiempos de inactividad tolerables.
5. Asegúrese de conocer todos los componentes que podrían afectar a la disponibilidad de los sistemas, como:
   1. Administración de identidades.
   2. Topología de red.
   3. Administración de secretos y claves.
   4. Orígenes de datos.
   5. Programador de automatización/trabajo.
   6. Repositorio de origen e 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 Acuerdo de nivel de servicio (SLA) de Azure en el nivel de producto o servicio.
   2. Un sistema eficaz de supervisión y alertas con equipos responsables para revisar esas métricas y alertas de forma oportuna ayuda a cumplir el objetivo.
7. 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 de plataforma como servicio (PaaS), como Azure Data Lake Storage Gen2 o Azure Data Factory, suelen tener características nativas que permiten conmutar por error a instancias secundarias en otras regiones mientras permanecen contenidas en la suscripción original. Es posible que algunos clientes quieran considerar la posibilidad de tener un grupo de recursos dedicado para los recursos utilizados solo en escenarios de recuperación ante desastres con fines de costo.
   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 usan para flujos de trabajo de negocio como de costumbre (BAU).
8. 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 recompilar una instancia de Azure Analysis Services antes de que el almacenamiento de datos esté en funcionamiento, ya que desencadena un error. Deje los laboratorios de desarrollo más adelante en el proceso, primero recupere las soluciones empresariales principales.
9. Intente identificar las tareas de recuperación que se pueden paralelizar entre soluciones, lo que reduce el RTO total.
10. 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.
11. 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. Adopte 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. Use canalizaciones de versión de CI/CD en lugar de hacer clic en operaciones.
12. Como tiene un plan para la conmutación por error, debe tener en cuenta los procedimientos para revertir a las instancias principales.
13. Defina indicadores claros y métricas para validar que la conmutación por error se ha realizado correctamente y que las soluciones están en funcionamiento o que la situación vuelve a ser normal (también conocida como funcional principal).
14. Decida si los acuerdos de nivel de servicio (SLA) deben permanecer iguales después de una conmutación por error o si permite 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 operativo principal.
15. Una definición de RTO/RPO debe basarse en escenarios de usuario específicos en lugar de en el nivel de infraestructura. Si lo hace, obtendrá más granularidad sobre qué procesos y componentes se deben recuperar primero si hay una interrupción o un desastre.
16. Asegúrese de incluir comprobaciones de capacidad en la región de destino antes de avanzar con una conmutación por error: si hay un desastre importante, tenga en cuenta que muchos clientes intentarán conmutar por 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 tener en cuenta una estrategia de recuperación ante desastres activa/activa o activa/pasiva.
17. 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.
18. Se deben realizar simulacros de recuperación ante desastres normales para validar el flujo de trabajo del plan de recuperación ante desastres, que cumple con el RTO/RPO necesario y para entrenar a los equipos responsables.
    1. Las copias de seguridad de los datos y de la configuración también deben probarse cada cierto tiempo para garantizar que son "aptas según los objetivos" para favorecer cualquier actividad de recuperación.
19. 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 de 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.
20. Durante un desastre, la comunicación eficaz entre las muchas partes implicadas es clave para la ejecución eficaz y rápida del plan. Teams puede incluir:
    1. Responsables de la toma de decisiones.
    2. Equipo de respuesta a incidentes.
    3. Usuarios y equipos internos afectados.
    4. Equipos externos.
21. 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 tanto, se basa en la IP 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 facilitados ayudarán a tener conocimientos sólidos, 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 "aptos según los objetivos".

• 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. Si se garantiza que las partes interesadas de la empresa se impliquen en todas las actividades de recuperación ante desastres, se facilitará un proceso de recuperación ante desastres que sea "apto según los objetivos", aporte 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 de cada cliente. El proceso de recuperación ante desastres "apto según los objetivos" debe evolucionar con ellos. Ya sea a través del proceso de ciclo de vida de desarrollo de software (SDLC) o 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 hacer todo lo posible 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" necesaria 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, existe una clara división de responsabilidades, determinada por el nivel de servicio en la nube utilizado: Aunque se use una pila completa de software como servicio (SaaS), el cliente seguirá teniendo la responsabilidad de garantizar que las cuentas, las identidades y los datos sean correctos o estén actualizados, así como los dispositivos utilizados 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 no está conectada 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 desastre : la solución se vuelve a implementar manualmente en una región disponible desde cero y después del 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 actúa como parte del sistema más grande.

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 que se va a ejecutar: la complejidad de la organización para ejecutar las actividades de recuperación.
• Complejidad que se va a implementar: la complejidad de la organización para implementar la estrategia de recuperación ante desastres.
• Impacto en los clientes: impacto directo a los clientes del servicio de plataforma de datos de la estrategia de recuperación ante desastres.
• Costo de OPEX de línea anterior: el costo adicional esperado de la implementación de esta estrategia, como el aumento de la facturación mensual de Azure para componentes adicionales y recursos adicionales necesarios para admitir.

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