Confiabilidad en Azure Logic Apps
En este artículo, se describe el soporte brindado para lograr la confiabilidad en Azure Logic Apps, que abarca la resistencia intrarregional a través de zonas de disponibilidad e implementaciones en varias regiones.
La resistencia es una responsabilidad compartida entre usted y Microsoft, por lo que este artículo también abarca las formas en que usted puede crear una solución resistente que satisfaga sus necesidades.
Los flujos de trabajo de aplicaciones lógicas le ayudan a integrar datos y organizarlos más fácilmente entre aplicaciones, servicios en la nube y sistemas locales mediante la reducción de la cantidad de código que se debe escribir. Al planificar la resistencia, asegúrese de tener en cuenta no solo las aplicaciones lógicas, sino también estos recursos de Azure que se usan con ellas:
Las Conexiones que se crean a partir de flujos de trabajo de aplicaciones lógicas a otras aplicaciones, servicios y sistemas. Para obtener más información, vea Conexiones a recursos más adelante en este tema.
Las puertas de enlace de datos locales, que son recursos de Azure que se crean y se usan en las aplicaciones lógicas para acceder a los datos de sistemas locales. Cada recurso de puerta de enlace representa una instalación de puerta de enlace independiente en un equipo local. Puede configurar una puerta de enlace de datos local para alta disponibilidad con el uso de varios equipos. Para más información, consulte Compatibilidad con alta disponibilidad.
Las cuentas de integración en las que se definen y almacenan los artefactos que los flujos de aplicaciones lógicas usan para escenarios de integración empresarial de negocio a negocio (B2B). Por ejemplo, puede configurar la recuperación ante desastres entre regiones para cuentas de integración.
Azure Logic Apps multiinquilino administra, de manera automática, la infraestructura de proceso y los recursos de los flujos de trabajo de consumo. No es necesario configurar ni administrar ninguna máquina virtual (VM). Los flujos de trabajo de consumo comparten la infraestructura de proceso entre muchos clientes.
Azure Logic Apps de un solo inquilino ejecuta flujos de trabajo Estándar en recursos de proceso dedicados, que están dedicados a usted y se denominan planes. Cada plan puede tener varias instancias y esas instancias se pueden distribuir, de manera opcional, entre varias zonas de disponibilidad. Los flujos de trabajo se ejecutan en instancias del plan.
Recomendaciones de implementación de producción
Para flujos de trabajo empresariales y seguros con requisitos de aislamiento o seguridad de red, se recomienda crear y ejecutar flujos de trabajo Estándar en Azure Logic Apps de inquilino único, en lugar de flujos de trabajo de Consumo en Azure Logic Apps multiinquilino. Para más información, consulte Creación e implementación en distintos entornos.
En el caso de las implementaciones de producción con Azure Logic Apps de inquilino único, debe habilitar la redundancia de zona para distribuir los recursos de la aplicación lógica en varias zonas de disponibilidad.
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. 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 al comunicarse con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información sobre el control de errores transitorios, consulte Recomendaciones para el control de errores transitorios.
En Azure Logic Apps, muchos desencadenadores y acciones admiten automáticamente directivas de reintento, que reintentan automáticamente las solicitudes que producen errores debido a errores transitorios. Para obtener información sobre cómo cambiar o deshabilitar las directivas de reintento para la aplicación lógica, consulte Control de errores y excepciones en Azure Logic Apps.
Si se produce un error en una acción, puede personalizar el comportamiento de las acciones posteriores. También puede crear ámbitos para agrupar acciones relacionadas que podrían producir errores o realizarse correctamente de manera conjunta.
Para más información sobre el control de errores en Azure Logic Apps, consulte Control de errores y excepciones en Azure Logic Apps.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad son grupos físicamente separados 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.
Para más información sobre las zonas de disponibilidad en Azure, consulte ¿Qué son las zonas de disponibilidad?.
Azure Logic Apps admite la redundancia de zona, que distribuye los recursos de proceso entre varias zonas de disponibilidad. Al distribuir recursos de carga de trabajo de aplicaciones lógicas entre zonas de disponibilidad, se mejora la resistencia y la confiabilidad de las cargas de trabajo de la aplicación lógica de producción.
Los flujos de trabajo de aplicaciones lógicas de consumo nuevos y existentes en Azure Logic Apps multiinquilino tienen habilitada la redundancia de zona de manera automática.
Para flujos de trabajo Estándar con la opción de hospedaje Plan de servicio de flujo de trabajo en Azure Logic Apps de un solo inquilino, puede habilitar, de manera opcional, la redundancia de zona.
En el caso de los flujos de trabajo Estándar con la opción de hospedaje App Service Environment v3, puede habilitar, de manera opcional, la redundancia de zona. Para más información sobre cómo App Service Environments v3 admite zonas de disponibilidad, consulte Confiabilidad en App Service.
Regiones admitidas
Las aplicaciones lógicas de Consumo que se implementan en cualquier región que admita zonas de disponibilidad tienen automáticamente redundancia de zona. Japón Occidental es la excepción, que actualmente no admite aplicaciones lógicas con redundancia de zona porque algunos servicios de dependencia aún no admiten redundancia de zona.
Puede implementar aplicaciones lógicas Estándar con redundancia de zona con planes de servicio de flujo de trabajo en cualquier región que admita zonas de disponibilidad para Azure App Service. Japón Occidental es la excepción, que actualmente no admite aplicaciones lógicas con redundancia de zona. Para más información, consulte Confiabilidad en Azure App Service.
Para ver qué regiones son compatibles con las zonas de disponibilidad de App Service Environment v3, consulta Regiones.
Requisitos
Debe implementar al menos tres instancias del plan de servicio de flujo de trabajo. Cada instancia se corresponde aproximadamente con una máquina virtual. Para distribuir estas instancias (VM) entre zonas de disponibilidad, debe tener un mínimo de tres instancias.
Consideraciones
- Almacenamiento: al configurar el almacenamiento externo para flujos de trabajo Estándar con estado, debe configurar la cuenta de almacenamiento para la redundancia de zona. Para obtener más información, vea Consideraciones de almacenamiento de Azure Functions.
Conectores: los conectores integrados tienen, de manera automática, redundancia de zona cuando la aplicación lógica también la tiene.
Cuentas de integración: las cuentas de integración de SKU Premium tienen redundancia de zona de forma predeterminada.
Costos
No se aplica ningún costo adicional al uso de redundancia de zona, que se habilita de manera automática para flujos de trabajo de consumo nuevos y existentes en Azure Logic Apps multiinquilino.
Cuando tiene flujos de trabajo Estándar con el plan de servicio de flujo de trabajo en Azure Logic Apps de un solo inquilino, no se aplica ningún costo adicional a la habilitación de zonas de disponibilidad siempre que tenga tres o más instancias del plan. Se le cobrará en función del SKU del plan, la capacidad especificada y las instancias que escale o reduzca verticalmente según los criterios de escalado automático. Si habilita zonas de disponibilidad pero especifica una capacidad de menos de tres instancias, la plataforma aplica las tres instancias mínimas y le cobra por estas tres instancias.
App Service Environment v3 tiene un modelo de precios específico para la redundancia de zona. Para obtener información sobre los precios de App Service Environment v3, consulta Precios.
Configuración de la compatibilidad con zonas de disponibilidad
Los flujos de trabajo de la aplicación lógica de consumo admiten la redundancia de zona de manera automática, por lo que no se requiere ninguna configuración.
Creación de un flujo de trabajo con redundancia de zona.
Para habilitar la redundancia de zona para flujos de trabajo de aplicaciones lógicas Estándar, consulte Protección de Logic Apps frente a errores de zona con zonas de disponibilidad y redundancia de zona.
Migración en las series 7000-8000
No se puede habilitar la redundancia de zona después de crear un plan de servicio. En su lugar, debe crear un nuevo plan con redundancia de zona habilitada y eliminar el anterior.
Deshabilitación de la redundancia de zona.
No se puede deshabilitar la redundancia de zona después de crear un plan de servicio de flujo de trabajo. En su lugar, debe crear un nuevo plan con redundancia de zona deshabilitada y eliminar el anterior.
Planeamiento y administración de capacidad
Para prepararse para errores de zona de disponibilidad, considere la posibilidad de sobreaprovisionar la capacidad del servicio. El sobreaprovisionamiento permite a la solución tolerar cierto grado de pérdida de capacidad y seguir funcionando sin degradar el rendimiento.
Para decidir cuántas instancias sobreaprovisionar, es importante saber que la plataforma distribuye instancias entre varias zonas. Debe asumir al menos que una zona experimentará un error.
Siga estos pasos para averiguar el número total de instancias que debe aprovisionar:
- Determine el número de instancias necesarias en una situación de carga de trabajo máxima. En este ejemplo, se usan dos escenarios. Uno es con 3 instancias y el otro, con 4.
- Multiplique el número máximo de instancias de carga de trabajo por un factor de [(zonas/(zonas - 1)] para encontrar el número de instancias que debe sobreaprovisionar.
- Redondee el resultado al número entero más cercano.
Nota:
En la tabla siguiente, se da por supuesto que usa tres zonas de disponibilidad. Si usa otro número, ajuste la fórmula en consecuencia.
| Número de instancias en una situación de carga de trabajo máxima. | Factor de [(zonas / (zonas - 1)] | Fórmula | Instancias por aprovisionar (redondeado) |
|---|---|---|---|
| 3 | 3/2 o 1,5 | (3 x 1,5 = 4,5) | 5 instancias |
| 4 | 3/2 o 1,5 | (4 x 1,5 = 6) | 6 instancias |
Enrutamiento de tráfico entre zonas
Durante las operaciones normales, las invocaciones de flujo de trabajo pueden usar recursos de proceso en cualquiera de las zonas de disponibilidad dentro de la región.
Durante las operaciones normales, las invocaciones de flujo de trabajo se distribuyen entre todas las instancias de plan disponibles en todas las zonas de disponibilidad.
Experiencia de nivel de zona
Detección y respuesta: la plataforma de Azure Logic Apps es responsable de detectar un error en una zona de disponibilidad. No es necesario hacer nada para iniciar una conmutación por error de zona.
Solicitudes activas: si una zona de disponibilidad deja de estar disponible, se finalizan las ejecuciones de flujo de trabajo en curso que se ejecutan en una máquina virtual en la zona de disponibilidad errónea. La plataforma Azure Logic Apps reanuda automáticamente el flujo de trabajo en otra máquina virtual en otra zona de disponibilidad. Debido a este comportamiento, los flujos de trabajo activos pueden experimentar algunos errores transitorios o una mayor latencia a medida que se agregan nuevas máquinas virtuales a las zonas de disponibilidad restantes.
Conmutación por recuperación
Cuando la zona de disponibilidad se recupera, Azure Logic Apps restaura automáticamente las instancias de la zona de disponibilidad, quita las instancias temporales creadas en las otras zonas de disponibilidad y redirecciona el tráfico entre sus instancias, como es habitual.
Pruebas de errores de zona
La plataforma Azure Logic Apps administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para los recursos de aplicación lógica con redundancia de zona. No es necesario iniciar nada. Esta característica está totalmente administrada, por lo que no es necesario validar los procesos de error de zona de disponibilidad.
Compatibilidad con varias regiones
Cada aplicación lógica se implementa en una sola región de Azure. Si la región deja de estar disponible, la aplicación lógica tampoco estará disponible.
Enfoques alternativos de varias regiones
Para lograr una mayor resistencia, puede implementar una aplicación lógica en modo de espera o de copia de seguridad en una región secundaria y conmutar por error a esa otra región si la región primaria no está disponible. Para habilitar esta funcionalidad, complete las siguientes tareas:
- Implemente la aplicación lógica en regiones primarias y secundarias.
- Vuelva a configurar las conexiones a los recursos según sea necesario.
- Configure directivas de equilibrio de carga y conmutación por error.
- Planee supervisar el estado de la instancia principal e iniciar la conmutación por error.
Para más información sobre las implementaciones de varias regiones para los flujos de trabajo de aplicaciones lógicas, consulte la siguiente documentación:
- Implementaciones en varias regiones en Azure Logic Apps
- Configuración de recuperación ante desastres entre regiones para cuentas de integración: Azure Logic Apps
- Creación de tareas de replicación para recursos de Azure mediante Azure Logic Apps
Acuerdo de nivel de servicio
El acuerdo de nivel de servicio (SLA) para Azure Logic Apps 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.