Confiabilidad en Azure Data Factory

En este artículo se describe la compatibilidad con la confiabilidad en Azure Data Factory. La resistencia intrarregional se aborda a través de zonas de disponibilidad y implementaciones multi-regionales.

La confiabilidad es una responsabilidad compartida entre usted y Microsoft. Puede usar esta guía para determinar qué opciones de confiabilidad cumplen sus objetivos empresariales específicos y objetivos de tiempo de actividad.

Puede usar Data Factory para crear canalizaciones de datos flexibles y eficaces para la integración de datos sin servidor y la transformación de datos. Como resultado, al definir el plan de continuidad empresarial para la confiabilidad, debe tener en cuenta los requisitos de confiabilidad y las instrucciones para:

• Pipelines de Data Factory.

• Entornos de ejecución de integración (IR), que se conectan a almacenes de datos y realizan actividades definidas en la canalización.

• Almacenes de datos que se conectan a la factoría de datos. Para ayudar a garantizar que los almacenes de datos cumplan los requisitos de continuidad empresarial, consulte la documentación y las instrucciones de confiabilidad del producto.

Introducción a la arquitectura de confiabilidad

Data Factory consta de varios componentes de infraestructura. Cada componente admite la confiabilidad de la infraestructura de maneras diferentes.

Los componentes de Data Factory incluyen:

• El servicio principal de Data Factory, que administra los desencadenadores de canalización y supervisa la coordinación de las actividades de canalización. El servicio principal también administra los metadatos de cada componente de la factoría de datos. Microsoft administra el servicio principal.

• Entornos de ejecución de integración (IR), que realizan actividades específicas dentro de una canalización. Hay diferentes tipos de infrarrojos.

  • IR administrados por Microsoft, que incluyen Azure IR y Azure-SQL Server Integration Services (Azure-SSIS) IR. Microsoft administra los componentes que componen estos entornos de ejecución. En algunos escenarios, se configuran las opciones que afectan a la resiliencia del IR.

  • Entornos de ejecución de integración autohospedados (SHIR). Microsoft proporciona software que puede ejecutar en su propia infraestructura informática para realizar algunas partes de sus propias canalizaciones de Data Factory. Es responsable de la implementación y administración de los recursos de computación y de la resiliencia de esos recursos de computación.

Errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones controlen errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para más información, vea Recomendaciones para gestionar errores temporales.

Cuando se usa Data Factory, es importante prepararse para errores transitorios, especialmente al diseñar canalizaciones y actividades.

Idempotencia

Las actividades de canalización deben ser idempotentes, lo cual significa que se puedan volver a ejecutar varias veces sin causar efectos adversos. Si se produce un error transitorio como un error de red o una interrupción de zona de disponibilidad, Data Factory podría volver a ejecutar actividades de canalización. Esta repetición puede crear registros duplicados.

Para evitar la inserción de registros duplicados debido a un error transitorio, implemente los procedimientos recomendados siguientes:

• Use identificadores únicos para cada registro antes de escribir en la base de datos. Este enfoque puede ayudarle a encontrar y eliminar registros duplicados.

• Use una estrategia upsert para los conectores que admiten upsert. Antes de que se produzca la inserción de registros duplicados, use este enfoque para comprobar si ya existe un registro. Si existe, actualícela. Si no existe, insértelo. Por ejemplo, comandos SQL como MERGE o ON DUPLICATE KEY UPDATE usan este enfoque de upsert.

• Use estrategias de acción de copia. Para obtener más información, consulte Comprobación de coherencia de datos en la actividad de copia.

Directivas de reintentos

Puede usar directivas de reintento para configurar partes de la canalización para reintentar si hay un problema, como errores transitorios en los recursos conectados. En Data Factory, puede configurar directivas de reintento en los siguientes tipos de objetos de canalización:

• Desencadenadores periódicos
• Actividades de ejecución

Para obtener más información sobre cómo cambiar o deshabilitar las directivas de reintento para los desencadenadores y actividades de Data Factory, consulte Ejecuciones y desencadenadores de canalización.

Compatibilidad con zonas de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de cada región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.

Data Factory admite redundancia de zona, lo que proporciona resistencia a errores en las zonas de disponibilidad. En esta sección se describe cómo cada parte del servicio Data Factory admite redundancia de zona.

Regiones soportadas

Los recursos de Data Factory con redundancia de zona se pueden implementar en cualquier región que admita zonas de disponibilidad.

Consideraciones

Servicio principal: Microsoft administra los componentes en el servicio principal de Data Factory y los distribuye entre zonas de disponibilidad.

IRs: La compatibilidad con la redundancia de zona depende del tipo de IR que se utilice.

• Azure IR admite redundancia de zona y Microsoft administra esta funcionalidad.

• Un Azure-SSIS IR requiere la implementación de al menos dos nodos. Estos nodos se asignan automáticamente a diferentes zonas de disponibilidad.

• Un SHIR le ofrece la responsabilidad de implementar la infraestructura de proceso para hospedar el entorno de ejecución. Puede implementar varios nodos, como máquinas virtuales individuales y configurarlos para alta disponibilidad. Después, puede distribuir esos nodos en varias zonas de disponibilidad. Para más información, consulte Alta disponibilidad y escalabilidad.

Costos

Servicio principal: No se aplica ningún costo adicional para la redundancia de zona.

IR: El costo de la redundancia de zona varía en función del tipo de IR que use.

• Azure IR incluye redundancia de zona sin costo adicional.

• Un Azure-SSIS IR requiere que despliegue al menos dos nodos para lograr redundancia de zona. Para obtener más información sobre cómo se factura cada nodo, vea Ejemplo de precios: Ejecutar paquetes SSIS en un IR de Azure-SSIS.

• Un SHIR requiere que se implemente y administre la infraestructura de proceso. Para lograr la resiliencia de la zona, debe distribuir los recursos informáticos entre varias zonas. Dependiendo del número de nodos que implemente y cómo los configure, puede incurrir en costos adicionales de los servicios de proceso subyacentes y otros servicios auxiliares. No hay ningún cargo adicional para ejecutar el SHIR en varios nodos.

Configuración de la compatibilidad con zonas de disponibilidad

Servicio principal: No se requiere ninguna configuración. El servicio principal de Data Factory admite automáticamente la redundancia de zona.

IR:

• Una instancia de Azure IR: No se requiere ninguna configuración. Azure IR habilita automáticamente la redundancia de zona.

• Un Azure-SSIS IR: no se requiere configuración. Un IR de nivel Azure-SSIS habilita automáticamente la redundancia de zona cuando se implementa con dos o más nodos.

• Una SHIR requiere que configure su propia resistencia, lo que incluye la propagación de los nodos entre varias zonas de disponibilidad.

Planeamiento y administración de capacidad

Servicio principal: El servicio principal de Data Factory se escala automáticamente en función de la demanda y no es necesario planear ni administrar la capacidad.

IR:

• Una instancia de Azure IR se escala automáticamente en función de la demanda y no es necesario planear ni administrar la capacidad.

• Un Azure-SSIS IR requiere que configure específicamente el número de nodos que use. Para prepararse para errores de zona de disponibilidad, considere la posibilidad de sobreaprovisionar la capacidad del IR. El sobreaprovisionamiento permite a la solución tolerar cierto grado de pérdida de capacidad y seguir funcionando sin degradar el rendimiento. Para obtener más información, consulte Administración de la capacidad mediante el aprovisionamiento excesivo.

• Un SHIR requiere que configure su propia capacidad y escalamiento. Considere la posibilidad de sobreaprovisionar al implementar una SHIR.

Operaciones normales

Enrutamiento de tráfico entre zonas: Durante las operaciones normales, Data Factory distribuye automáticamente las actividades de canalización, los desencadenadores y otros trabajos entre instancias correctas en cada zona de disponibilidad.

Experiencia de nivel de zona

Detección y respuesta: La plataforma data Factory es responsable de detectar un error en una zona de disponibilidad y responder. No es necesario hacer nada para iniciar una conmutación por error de zona en las canalizaciones u otros componentes.

Solicitudes activas: cualquier canalización y desencadenador en proceso sigue ejecutándose, y no experimentará ninguna interrupción inmediata debido a un error en la zona. Sin embargo, las actividades en curso durante un error de zona pueden producir un error y reiniciarse. Es importante diseñar actividades para que sean idempotentes, lo que les ayuda a recuperarse de errores de zona y de otros errores. Para obtener más información, consulte Errores transitorios.

Conmutación por recuperación

Cuando se recupera la zona de disponibilidad, Data Factory vuelve automáticamente a la zona original. No es necesario hacer nada para iniciar una conmutación por recuperación de zona en las canalizaciones u otros componentes.

Sin embargo, si usa una SHIR, es posible que tenga que reiniciar los recursos de cómputo si se han detenido.

Pruebas de errores de zona

Para el servicio principal, así como para los Azure y los Azure-SSIS IR, Data Factory administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para los recursos con redundancia de zona. Dado que esta característica está totalmente administrada, no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

En el caso de los SHIR, puede usar Azure Chaos Studio para simular un error de zona de disponibilidad en una máquina virtual de Azure.

Compatibilidad con varias regiones

Los recursos de Data Factory se implementan en una sola región de Azure. Si la región deja de estar disponible, la factoría de datos tampoco está disponible. Sin embargo, hay enfoques que puede usar para ayudar a garantizar la resistencia a las interrupciones de la región. Estos enfoques dependen de si la factoría de datos está en una región emparejada o no emparejada y en sus requisitos y configuración específicos.

Conmutación por error administrada por Microsoft en una región emparejada

Data Factory admite la conmutación por error administrada por Microsoft para factorías de datos en regiones emparejadas, excepto Sur de Brasil y Sudeste de Asia. En el improbable caso de un error prolongado en la región, Microsoft podría iniciar una conmutación por error regional de la instancia de Data Factory.

Debido a los requisitos de residencia de datos en el Sur de Brasil y sudeste de Asia, los datos de Data Factory solo se almacenan en la región local mediante el almacenamiento con redundancia de zona de Azure Storage. Para sudeste asiático, todos los datos se almacenan en Singapur. Para el Sur de Brasil, todos los datos se almacenan en Brasil.

En el caso de las factorías de datos en regiones no emparejadas o en el Sur de Brasil o Sudeste de Asia, Microsoft no realiza la conmutación por error regional en su nombre.

Importante

Microsoft inicia la conmutación por error administrada por Microsoft. Es probable que se produzca después de un retraso significativo y se realice con el mejor esfuerzo. También hay algunas excepciones a este proceso. Es posible que experimente alguna pérdida de los metadatos de la factoría de datos. La conmutación por error de los recursos de Data Factory puede producirse en un momento diferente del tiempo de conmutación por error de otros servicios de Azure.

Si necesita ser resistente a interrupciones de regiones, considere la posibilidad de usar uno de los enfoques alternativos de varias regiones.

Conmutación por error de los IR

Para prepararse para una conmutación por error, puede haber algunas consideraciones adicionales, en función del entorno de ejecución de integración utilizado.

• Puede configurar Azure IR para resolver automáticamente la región que usa. Si la región está establecida para resolverse automáticamente y hay una interrupción en la región principal, el Azure IR cambia automáticamente a la región emparejada. Esta conmutación por error está sujeta a limitaciones. Para configurar la región de Azure IR para la implementación de la actividad o el envío en la configuración de IR, establezca la región para resolverse automáticamente.

• La conmutación por error de Azure-SSIS IR se administra por separado en la conmutación por error administrada por Microsoft de Data Factory. Para obtener más información, consulte Enfoques alternativos de varias regiones.

• Una SHIR se ejecuta en la infraestructura por la que es responsable, por lo que una conmutación por error administrada por Microsoft no se aplica a las SHIR. Para obtener más información, consulte Enfoques alternativos de varias regiones.

Reconfiguración posterior a la conmutación por error

Una vez completada una conmutación por error administrada por Microsoft, puede acceder a la canalización de Data Factory en la región emparejada. Sin embargo, una vez completada la conmutación por error, es posible que tenga que realizar alguna reconfiguración para los IR u otros componentes. Este proceso incluye volver a establecer la configuración de red.

Enfoques alternativos de varias regiones

Si necesita que las canalizaciones sean resistentes a las interrupciones regionales y necesita controlar el proceso de conmutación por error, considere la posibilidad de usar una canalización controlada por metadatos.

• Configure el control de código fuente para que Data Factory realice un seguimiento y audite los cambios realizados en los metadatos. Puede usar este enfoque para acceder a los archivos JSON de metadatos para canalizaciones, conjuntos de datos, servicios vinculados y desencadenadores. Data Factory admite diferentes tipos de repositorio de Git, como Azure DevOps y GitHub. Para más información, consulte Control de código fuente en Data Factory.

• Utilice un sistema de integración continua y entrega continua (CI/CD), como Azure DevOps, para gestionar los metadatos de la canalización y las implementaciones. Puede usar CI/CD para restaurar rápidamente las operaciones en una instancia de otra región. Si una región no está disponible, puede aprovisionar una nueva factoría de datos manualmente o a través de la automatización. Una vez creada la nueva factoría de datos, puede restaurar las canalizaciones, los conjuntos de datos y los servicios vinculados JSON desde el repositorio de Git existente. Para más información, consulte Continuidad empresarial y recuperación ante desastres (BCDR) para canalizaciones de Data Factory y Azure Synapse Analytics.

Dependiendo del IR que utilice, puede haber otras consideraciones.

• Un Azure-SSIS IR usa una base de datos almacenada en Azure SQL Database o Azure SQL Managed Instance. Puede configurar la replicación geográfica o un grupo de conmutación por error para esta base de datos. La base de datos Azure-SSIS se encuentra en una región primaria de Azure que tiene acceso de lectura y escritura. La base de datos se replica continuamente en una región secundaria que tiene acceso de solo lectura. Si la región primaria no está disponible, se desencadena una conmutación por error, lo que hace que las bases de datos principales y secundarias intercambien roles.

  También puede configurar un par de Azure-SSIS IR en espera dual que funcione en sincronización con el grupo de conmutación por error de Azure SQL Database o SQL Managed Instance.

  Para obtener más información, consulte Configurar un IR de Azure-SSIS para BCDR.

• Una SHIR se ejecuta en la infraestructura que administra. Si el SHIR se implementa en una máquina virtual de Azure, puede usar Azure Site Recovery para desencadenar la conmutación por error de la máquina virtual en otra región.

Copias de seguridad y restauración

Data Factory admite CI/CD a través de la integración del control de código fuente, de modo que pueda realizar una copia de seguridad de los metadatos de una instancia de Data Factory. Las canalizaciones de CI/CD implementan estos metadatos sin problemas en un nuevo entorno. Para más información, consulte CI/CD en Data Factory.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure Data Factory describe la disponibilidad esperada del servicio. Este acuerdo también describe las condiciones que se deben cumplir para lograr esta expectativa. Para entender esas condiciones, asegúrese de revisar los Acuerdos de Nivel de Servicio (SLA) para Servicios en Línea.

Contenido relacionado

• Confiabilidad en Azure