Editar

Compartir a través de

Recuperación ante desastres para la plataforma de datos de Azure: información general

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs

Información general

Esta serie proporciona un ejemplo ilustrativo de cómo una organización podría diseñar una estrategia de recuperación ante desastres (DR) para una plataforma de datos empresariales de Azure.

Azure ofrece una amplia gama de opciones de resiliencia que pueden proporcionar la continuidad del servicio en caso de desastre. Pero unos niveles de servicio más altos pueden introducir complejidad y un sobrecoste. La compensación del costo frente a la resistencia frente a la complejidad es el factor clave de toma de decisiones para la mayoría de los clientes en relación con la recuperación ante desastres.

Aunque los errores puntuales ocasionales se producen en la plataforma Azure, los centros de datos y los servicios de Azure de Microsoft tienen varias capas de redundancia integradas. Los errores normalmente están limitados en el ámbito y normalmente se corrigen en cuestión de horas. Históricamente, es mucho más probable que un servicio clave, como la administración de identidades, experimente un problema de servicio en lugar de que toda una región de Azure se desconecte.

También debe reconocerse que los ciberataques, especialmente ransomware, ahora suponen una amenaza tangible para cualquier ecosistema de datos moderno y pueden provocar una interrupción de la plataforma de datos. Aunque este tema queda fuera del ámbito de esta serie, se aconseja a los clientes que implementen controles contra este tipo de ataques como parte del diseño de seguridad y resistencia de cualquier plataforma de datos.

Ámbito

El ámbito de esta serie de artículos incluye:

  • Recuperación del servicio de una plataforma de datos de Azure desde un desastre físico para un rol ilustrativo del cliente. Este cliente ilustrativo:
    • Una organización mediana grande con una función de soporte operativo definida, siguiendo una metodología de administración de servicios basada en la Biblioteca de infraestructura de tecnología de la información (ITIL).
    • No nativo de la nube, con su empresa principal, servicios compartidos, como la administración de acceso y autenticación y la administración de incidentes que quedan en el entorno local.
    • En el recorrido de la migración a la nube a Azure, habilitado por la automatización.
  • La plataforma de datos de Azure ha implementado los siguientes diseños dentro del inquilino de Azure del cliente:
    • Zona de aterrizaje empresarial: proporciona la base de la plataforma, incluidas las redes, la supervisión, la seguridad, etc.
    • Plataforma de análisis de Azure: proporciona los componentes de datos que admiten las distintas soluciones y productos de datos proporcionados por el servicio.
  • Los procesos descritos en este artículo se ejecutarán mediante un recurso técnico de Azure en lugar de un experto en la materia (SME) de Azure especialista. Por lo tanto, los recursos deben tener el siguiente nivel de conocimientos y aptitudes:
    • Aspectos básicos de Azure: conocimientos prácticos de Azure, sus servicios principales y componentes de datos.
    • Conocimientos prácticos de Azure DevOps. Capaz de navegar por el control de código fuente y ejecutar implementaciones de canalización.
  • En estos procesos descritos en este artículo se tratan las operaciones de conmutación por error del servicio, desde la región principal a la secundaria.

Fuera de ámbito

Los siguientes elementos se consideran fuera del ámbito de esta serie de artículos:

  • El proceso de reserva, desde la región secundaria hasta la región primaria.
  • Todas las aplicaciones, componentes o sistemas que no son de Azure: esto incluye, pero no se limita a un entorno local, a otros proveedores en la nube, a servicios web de terceros, etc.
  • Recuperación de cualquier servicio ascendente, como redes locales, puertas de enlace, servicios compartidos de empresa y otros, independientemente de las dependencias de estos servicios.
  • Recuperación de cualquier servicio de bajada, como sistemas operativos locales, sistemas de informes de terceros, modelado de datos o aplicaciones de ciencia de datos, y otros, independientemente de las dependencias de estos servicios.
  • Escenarios de pérdida de datos, incluida la recuperación de ransomware o incidentes de seguridad de datos similares
  • Estrategias de copia de seguridad de datos y planes de restauración de datos
  • Establecimiento de la causa principal de un evento de recuperación ante desastres.
    • Para las incidencias de servicios/componentes de Azure, Microsoft publica un "Análisis de la causa principal" en la página web Estado: Historial

Suposiciones clave

Las suposiciones clave para este ejemplo de recuperación ante desastres son:

  • La organización sigue una metodología de administración de servicios basada en ITIL para la compatibilidad operativa de la plataforma de datos de Azure.
  • La organización tiene un proceso de recuperación ante desastres existente como parte de su marco de restauración de servicios para los recursos de TI.
  • La infraestructura como código (IaC) se ha usado para implementar la plataforma de datos de Azure habilitada por un servicio de automatización, como Azure DevOps o similar.
  • Cada solución hospedada por la plataforma de datos de Azure ha completado una evaluación de impacto empresarial o similar, lo que proporciona requisitos de servicio claros para el objetivo de punto de recuperación (RPO), el objetivo de tiempo de recuperación (RTO) y el tiempo medio para recuperar métricas (MTTR).

Pasos siguientes

Ahora que ya conoce el escenario a un alto nivel, puede avanzar hacia la arquitectura diseñada para el caso de uso.