Compartir a través de

Confiabilidad en Azure Logic Apps

Azure Logic Apps le ayuda a integrar y organizar datos más fácilmente entre aplicaciones, servicios en la nube y sistemas locales mediante la reducción de la cantidad de código que tiene que escribir.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que los flujos de trabajo de la aplicación lógica sean resistentes a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. También se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Logic Apps.

Recomendaciones de implementación de producción para la confiabilidad

En el caso de las cargas de trabajo de producción, se recomienda que usted:

  • Para flujos de trabajo empresariales y seguros con requisitos de aislamiento o seguridad de red, cree y ejecute 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, habilite la redundancia de zona para distribuir los recursos de la aplicación lógica entre varias zonas de disponibilidad.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

El recurso principal que implementa es una aplicación lógica. Las aplicaciones lógicas de consumo solo tienen un flujo de trabajo, mientras que las aplicaciones lógicas estándar pueden tener más de un flujo de trabajo. La mayoría de los flujos de trabajo usan una o varias conexiones para acceder a otras aplicaciones, servicios y sistemas.

Si accede a datos en sistemas locales, puede implementar una puerta de enlace de datos en las instalaciones. 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.

Cuando usa Azure Logic Apps para escenarios de integración empresarial de negocio a negocio (B2B), puede desplegar cuentas de integración en las que se definen y almacenan los artefactos que utilizan los flujos de trabajo de las aplicaciones lógicas.

Arquitectura física

En el caso de las aplicaciones lógicas de consumo, Azure Logic Apps administra automáticamente la infraestructura de proceso, el almacenamiento de estado y otros recursos. No es necesario configurar ni administrar ninguna máquina virtual (VM). Las aplicaciones lógicas de consumo comparten la infraestructura de proceso entre muchos clientes.

En el caso de las aplicaciones lógicas estándar, Azure Logic Apps usa recursos de cómputo denominados Planes de servicio de flujo de trabajo o planes, que están dedicados a usted. Cada plan puede tener varias instancias, que opcionalmente se pueden distribuir entre varias zonas de disponibilidad. Cada instancia se asigna aproximadamente a una máquina virtual (VM), pero no ve esas máquinas virtuales y no es necesario configurarlas ni administrarlas directamente. Los flujos de trabajo se ejecutan en instancias del plan.

Las aplicaciones lógicas estándar requieren que configure el almacenamiento para mantener el estado de los flujos de trabajo con estado. Para obtener más información, consulte Flujos de trabajo con estado y sin estado.

Las aplicaciones lógicas estándar usan una infraestructura subyacente similar a Azure Functions y Azure App Service. Sin embargo, existen algunas diferencias en la forma de configurar planes para aplicaciones lógicas en comparación con otros servicios.

Para más información, consulte Diferencias entre las aplicaciones lógicas estándar y las aplicaciones lógicas de consumo.

Resistencia a 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 sus aplicaciones puedan administrar errores transitorios, generalmente reintentando las 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 obtener más información, consulte Recomendaciones para controlar errores transitorios.

En Azure Logic Apps, muchos desencadenadores y acciones de flujo de trabajo admiten automáticamente directivas de reintento, que reintentan automáticamente las solicitudes que producen errores transitorios. Para más información sobre cómo cambiar o deshabilitar las directivas de reintento, 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 obtener más información, consulte Control de errores y excepciones en Azure Logic Apps.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Azure Logic Apps admite redundancia de zona, que distribuye los recursos de proceso y el estado 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 nuevos y existentes de la aplicación lógica de consumo en Azure Logic Apps multitenant habilitan automáticamente la redundancia de zona.

Azure Logic Apps admite la redundancia de zona, que distribuye los recursos de proceso entre varias zonas de disponibilidad. Opcionalmente, puede configurar la redundancia de zona para el estado que almacenan los flujos de trabajo de la aplicación lógica. 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.

Para los flujos de trabajo estándar con la opción de alojamiento plan de servicio de flujo de trabajo en Azure Logic Apps de inquilino único, puede activar opcionalmente la redundancia de zonas.

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 Environment v3 admite zonas de disponibilidad, consulte Confiabilidad en App Service Environment.

Requirements

  • Compatibilidad con regiones: Las aplicaciones lógicas de consumo implementadas en cualquier región que admita zonas de disponibilidad son automáticamente redundantes de zona. Japón Occidental es la excepción, que actualmente no admite aplicaciones lógicas con redundancia de zona porque algunos servicios dependientes aún no admiten redundancia de zona.
  • Compatibilidad con regiones: 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 porque algunos servicios dependientes aún no admiten redundancia de zona. Para más información, consulte Confiabilidad en Azure App Service.
  • Compatibilidad con regiones: para ver qué regiones admiten zonas de disponibilidad para App Service Environment v3, consulte Regiones.
  • Recuento de instancias: debe implementar al menos dos instancias del plan de servicio de flujo de trabajo. Cada instancia se corresponde aproximadamente con una máquina virtual, por lo que para distribuir estas instancias (VM) entre varias zonas de disponibilidad, debe tener dos instancias como mínimo.

Considerations

  • 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.

Cost

No se aplica ningún coste adicional por utilizar la redundancia de zona, que se habilita automáticamente para las aplicaciones lógicas de consumo nuevas y existentes en Azure Logic Apps multitenant.

Si tiene aplicaciones lógicas 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 si tiene dos o más instancias de plan. El coste se calcula en función del SKU del plan, la capacidad especificada y las instancias que se amplíen o reduzcan, según los criterios de escalado automático. Si habilita zonas de disponibilidad pero especifica menos de dos instancias, la plataforma aplica las dos instancias mínimas y le cobra por estas dos 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 del soporte para 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 una nueva aplicación lógica con redundancia de zona: para habilitar la redundancia de zona para aplicaciones lógicas estándar, consulte Habilitación de la redundancia de zona para la aplicación lógica.

  • Habilitación de la redundancia de zona en una aplicación lógica existente: 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.

  • Deshabilitar 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 el fallo de zona de disponibilidad, considere sobredimensionar la capacidad del plan. El sobreaprovisionamiento permite a la solución tolerar cierto grado de pérdida de capacidad y seguir funcionando sin degradar el rendimiento. Para más información, consulte Administración de la capacidad con sobreaprovisionamiento.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando los recursos de la aplicación lógica están configurados para la redundancia de zona y todas las zonas de disponibilidad están operativas.

  • Enrutamiento de tráfico entre zonas: durante las operaciones normales, las invocaciones de flujo de trabajo pueden usar recursos de proceso desde cualquier zona de disponibilidad de la región.

  • Replicación de datos entre zonas: para flujos de trabajo con estado, el estado del flujo de trabajo se replica sincrónicamente entre zonas de disponibilidad mediante el almacenamiento con redundancia de zona (ZRS).

  • Enrutamiento de tráfico entre zonas: 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.

  • Replicación de datos entre zonas: para flujos de trabajo con estado, el estado del flujo de trabajo se almacena en función del almacenamiento de estado configurado. Al usar Azure Storage como sistema de almacenamiento externo, debe usar el almacenamiento con redundancia de zona (ZRS), que replica sincrónicamente el estado de flujo de trabajo entre zonas de disponibilidad.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando se produce una interrupción de zona de disponibilidad mientras los recursos de la aplicación lógica están configurados para la redundancia de zona.

  • Detección y respuesta: 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.
  • Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

  • Solicitudes activas: si una zona de disponibilidad deja de estar disponible, Azure Logic Apps finaliza 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 reanuda automáticamente el flujo de trabajo en otra máquina virtual en una zona de disponibilidad diferente. 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.

  • Tiempo de inactividad esperado: no se espera ningún tiempo de inactividad en Azure Logic Apps. Sin embargo, si existen dependencias en otros servicios que experimentan tiempo de inactividad, la aplicación lógica también podría verse afectada.

  • Pérdida de datos esperada: No se espera ninguna pérdida de datos.

  • Reenrutamiento de tráfico: el tráfico entrante se distribuye automáticamente a la infraestructura en zonas correctas.
  • Comportamientos fuera del tiempo de ejecución: los flujos de trabajo de las aplicaciones lógicas en un plan redundante por zonas continúan ejecutándose incluso si una zona de disponibilidad sufre una interrupción. Sin embargo, los comportamientos que no son de ejecución pueden verse afectados durante una interrupción de la zona de disponibilidad. Para más información y una lista de estos comportamientos, consulte Confiabilidad en Azure App Service: comportamiento durante un error de zona.
  • Comportamientos fuera del tiempo de ejecución: los flujos de trabajo de las aplicaciones lógicas en un plan redundante por zonas continúan ejecutándose incluso si una zona de disponibilidad sufre una interrupción. Sin embargo, los comportamientos que no son de ejecución pueden verse afectados durante una interrupción de la zona de disponibilidad. Para más información y una lista de estos comportamientos, consulte Confiabilidad en Azure App Service Environment: comportamiento durante un error de zona.

Recuperación de zona

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.

Prueba de fallos de zona

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 aplicaciones lógicas redundantes por zonas. 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.

Resistencia a errores en toda la región

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.

Soluciones personalizadas de varias regiones para la resistencia

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 la aplicación lógica, consulte:

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Contenido relacionado

  • Last updated on