Editar

Compartir a través de

BCDR para canalizaciones de Azure Data Factory y Azure Synapse Analytics

Azure Data Factory
Azure Repos
Azure Synapse Analytics
GitHub

Los desastres pueden ser errores de hardware, desastres naturales o errores de software. El proceso de preparación y recuperación de un desastre se denomina recuperación ante desastres (DR). En este artículo se describen los procedimientos recomendados a fin de lograr continuidad empresarial y recuperación ante desastres (BCDR) para las canalizaciones de Azure Data Factory y Azure Synapse Analytics.

Las estrategias de BCDR incluyen redundancia de zona de disponibilidad, recuperación automatizada que proporciona la recuperación ante desastres de Azure y recuperación administrada por el usuario mediante la integración continua y entrega continua (CI/CD).

Arquitectura

Diagrama en el que se muestran las zonas de disponibilidad y las regiones para BCDR de las canalizaciones de Azure Synapse Analytics y Data Factory.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

  1. Las canalizaciones de Data Factory y Azure Synapse logran resistencia mediante regiones y zonas de disponibilidad de Azure.

    • Cada región de Azure tiene un conjunto de centros de datos que se implementan en un perímetro definido por la latencia.
    • Las zonas de disponibilidad de Azure son ubicaciones separadas físicamente dentro de cada región de Azure y toleran los errores locales.
    • Todas las regiones y las zonas de disponibilidad de Azure se conectan mediante una red dedicada de baja latencia regional y una red de alto rendimiento.
    • Para garantizar la resistencia, todas las regiones habilitadas para zonas de disponibilidad cuentan al menos con tres zonas de disponibilidad independientes.

  2. Cuando un centro de datos, parte de un centro de datos o una zona de disponibilidad en una región deja de funcionar, la conmutación por error se produce sin tiempo de inactividad para las canalizaciones de Data Factory y Azure Synapse con resistencia de zona.

Componentes

Detalles del escenario

Las canalizaciones de Data Factory y Azure Synapse almacenan artefactos que incluyen los datos siguientes:

Metadatos

  • Canalización
  • Conjuntos de datos
  • Servicios vinculados
  • Tiempo de ejecución de integración
  • Desencadenadores

Supervisión de datos

  • Canalización
  • Desencadenadores
  • Ejecuciones de actividad

Los desastres pueden producirse de diferentes maneras, como errores de hardware, desastres naturales o errores de software como resultado de errores humanos o ciberataques. En función de los tipos de errores, su impacto geográfico puede ser regional o global. Al planear una estrategia de recuperación ante desastres, tenga en cuenta la naturaleza del desastre y su impacto geográfico.

BCDR en Azure funciona en un modelo de responsabilidad compartida. Muchos servicios de Azure requieren que los clientes configuren explícitamente su estrategia de recuperación ante desastres, mientras que Azure proporciona la infraestructura y los servicios de plataforma de referencia según sea necesario.

Puede usar los procedimientos recomendados siguientes a fin de lograr BCDR para las canalizaciones de Data Factory y Azure Synapse en varios escenarios de error. Para la implementación, vea Implementación de este escenario.

Recuperación automatizada con recuperación ante desastres de Azure

Con la recuperación automatizada proporcionada por la característica de copia de seguridad y recuperación ante desastres de Azure, cuando hay una interrupción regional completa en una región de Azure que tiene una región emparejada, Data Factory o las canalizaciones de Azure Synapse conmutan automáticamente por error a la región emparejada al configurar la recuperación automatizada. Las excepciones son las regiones Sudeste de Asia y Brasil, donde los requisitos de residencia de datos requieren que los datos permanezcan en esas regiones.

En la conmutación por error de recuperación ante desastres, Data Factory recupera las canalizaciones de producción. Si necesita validar las canalizaciones recuperadas, puede realizar una copia de seguridad de las plantillas de Azure Resource Manager para las canalizaciones de producción en el almacenamiento secreto y comparar las canalizaciones recuperadas con las copias de seguridad.

El equipo de Azure Global lleva a cabo simulacros de BCDR normales y Azure Data Factory y Azure Synapse Analytics participan en estos simulacros. El simulacro de BCDR simula un error de región y conmuta por error los servicios de Azure en una región emparejada sin ninguna participación del cliente. Para obtener más información sobre los simulacros de BCDR, vea Pruebas de servicios.

Redundancia administrada por el usuario con CI/CD

Para lograr BCDR en caso de que se produzca un error en toda la región, necesita una factoría de datos o un área de trabajo de Azure Synapse en la región secundaria. En caso de eliminación por error de una canalización de Data Factory o Azure Synapse, interrupciones o eventos de mantenimiento internos, puede usar Git y CI/CD para recuperar manualmente las canalizaciones.

Opcionalmente, puede usar una implementación activa/pasiva. La región primaria controla las operaciones normales y permanece activa, mientras que la región secundaria de recuperación ante desastres requiere pasos planeados previamente, en función de la implementación específica, para convertirse en la principal. En este caso, todas las configuraciones necesarias para la infraestructura están disponibles en la región secundaria, pero no se aprovisionan.

Posibles casos de uso

La redundancia administrada por el usuario es útil en escenarios como los siguientes:

  • Eliminación accidental de artefactos de canalización como resultado de un error humano.
  • Interrupciones prolongadas o eventos de mantenimiento que no desencadenan BCDR porque no hay ningún desastre notificado.

Puede mover rápidamente las cargas de trabajo de producción a otras regiones y que no les afecte.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Las canalizaciones de Data Factory y Azure Synapse son servicios de Azure estándar que admiten zonas de disponibilidad, y están diseñados para proporcionar el nivel adecuado de resistencia y flexibilidad junto con una latencia ultra baja.

El enfoque de recuperación administrada por el usuario le permite seguir trabajando si hay algún evento de mantenimiento, interrupciones o errores humanos en la región primaria. Mediante CI/CD, las canalizaciones de Data Factory y Azure Synapse pueden integrarse en un repositorio de Git e implementarse en una región secundaria para lograr una recuperación inmediata.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

La recuperación administrada por el usuario integra Data Factory con Git mediante CI/CD y, opcionalmente, usa una región de recuperación ante desastres secundaria que tiene todas las configuraciones de infraestructura necesarias como copia de seguridad. Este escenario podría incurrir en costos adicionales. Para estimar los costos, use la calculadora de precios de Azure.

Para obtener ejemplos de precios de Data Factory y Azure Synapse Analytics, vea lo siguiente:

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

Mediante el enfoque de recuperación de CI/CD administrado por el usuario, puede integrarse en Azure Repos o GitHub. Para obtener más información sobre los procedimientos recomendados de CI/CD, vea Procedimientos recomendados para CI/CD.

Implementación de este escenario

Realice las acciones siguientes a fin de configurar la recuperación ante desastres automatizada o administrada por el usuario para las canalizaciones de Data Factory y Azure Synapse.

Configuración de la recuperación automatizada

En Data Factory, puede establecer la región de Azure IR para la ejecución de la actividad o distribuirla en la configuración de IR. Para habilitar la conmutación automática por error en caso de una interrupción regional completa, establezca Región en Resolución automática.

Captura de pantalla en la que se muestra la selección de Resolución automática para habilitar la conmutación automática por error en la configuración de IR.

En el contexto de los entornos de ejecución de integración, IR conmuta por error automáticamente a la región emparejada al seleccionar Auto Resolve (Resolución automática) como región de IR. Para otras regiones de ubicación específica, puede crear una factoría de datos secundaria en otra región y usar CI/CD a fin de aprovisionar la factoría de datos desde el repositorio de Git.

Los servicios vinculados no están totalmente habilitados después de la conmutación por error, debido a puntos de conexión privados pendientes en la red más reciente de la región. Debe configurar puntos de conexión privados en la región recuperada. Puede automatizar la creación de puntos de conexión privados mediante la API de aprobación.

Configuración de la recuperación administrada por el usuario mediante CI/CD

Puede usar Git y CI/CD para recuperar canalizaciones manualmente en caso de eliminación o interrupción de la canalización de Data Factory o Azure Synapse.

Al implementar la redundancia administrada por el usuario mediante CI/CD, realice las acciones siguientes:

Deshabilitar desencadenadores

Deshabilite los desencadenadores en la factoría de datos principal original una vez que vuelva a estar en línea. Puede deshabilitar los desencadenadores manualmente o implementar la automatización para comprobar periódicamente la disponibilidad del servidor principal original. Deshabilite todos los desencadenadores en la factoría de datos principal original inmediatamente después de que esta se recupere.

Para usar Azure PowerShell a fin de activar o desactivar los desencadenadores de Data Factory, vea Ejemplo de script anterior y posterior a la implementación y Mejoras de CI/CD relacionadas con la implementación de desencadenadores de canalización.

Control de escrituras duplicadas

La mayoría de las canalizaciones de extracción, transformación y carga (ETL) están diseñadas para controlar las escrituras duplicadas, ya que la reposición y la redefinición las requieren. Los receptores de datos que admiten la conmutación por error transparente pueden controlar escrituras duplicadas con la combinación de registros o eliminando e insertando todos los registros en el intervalo de tiempo específico.

En el caso de los receptores de datos que cambian los puntos de conexión después de la conmutación por error, el almacenamiento principal y secundario puede tener datos duplicados o parciales. Los datos se deben combinar manualmente.

Comprobación del testigo y controle el flujo de canalización (opcional)

En general, debe diseñar las canalizaciones para incluir actividades, como las de error y búsqueda, a fin de reiniciar las canalizaciones con errores desde el punto de interés.

  1. Agregue un parámetro global en la factoría de datos para indicar la región, por ejemplo region='EastUS' en la factoría de datos principal y region='CentralUS' en la secundaria.

  2. Cree un testigo en una tercera región. El testigo puede ser una llamada de REST o cualquier tipo de almacenamiento. El testigo devuelve la región primaria actual, por ejemplo 'EastUS', de manera predeterminada.

  3. Cuando se produce un desastre, actualice manualmente el testigo para devolver la región primaria nueva, por ejemplo 'CentralUS'.

  4. Agregue una actividad en la canalización para buscar el testigo y comparar el valor principal actual con el parámetro global.

    • Si los parámetros coinciden, esta canalización se ejecuta en la región primaria. Continúe con el trabajo real.
    • Si los parámetros no coinciden, esta canalización se ejecuta en la región secundaria. Solo tiene que devolver el resultado.

Nota

Este enfoque presenta una dependencia de la búsqueda de testigos en la canalización. Si no se lee el testigo, se detienen todas las ejecuciones de canalización.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

  • Mario Zimmermann | Administrador principal de ingeniería de software: equipo de Azure Data Factory

  • Wee Hyong Tok | Director principal de PM: equipo de Azure Data Factory

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes