Confiabilidad de Azure Functions
En este artículo se describe la compatibilidad con la confiabilidad de Azure App Service, y se trata tanto la resiliencia intrarregional con zonas de disponibilidad como la recuperación ante desastres y la continuidad del negocio entre regiones. Para obtener información general más detallada sobre los principios de confiabilidad de Azure, consulte Confiabilidad de Azure.
La compatibilidad de zonas de disponibilidad para Azure Functions está disponible en los planes Premium (Elastic Premium) y Dedicado (App Service). Este artículo se centra en la compatibilidad con la redundancia de zona para los planes Premium. Para obtener redundancia de zona en planes dedicados, consulte Soporte técnico para migrar App Service a la zona de disponibilidad.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.
Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.
Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.
Azure Functions admite una implementación con redundancia de zona.
Al configurar Functions como redundancia de zona, la plataforma propaga automáticamente las instancias de la aplicación de funciones en tres zonas de la región seleccionada.
La propagación de instancias con una implementación con redundancia de zona se determina dentro de las reglas siguientes, incluso cuando la aplicación se escala y se reduce horizontalmente:
- El recuento mínimo de instancias de la aplicación de funciones es tres.
- Cuando se especifica una capacidad superior a tres, las instancias se distribuyen uniformemente solo cuando la capacidad es un múltiplo de 3.
- Para un valor de capacidad superior a 3*N, las instancias adicionales se distribuyen entre las zonas restantes de una o dos.
Importante
Azure Functions puede ejecutarse en la plataforma Azure App Service. En la plataforma App Service, los planes que hospedan las aplicaciones de funciones de plan Premium se conocen como planes Elastic Premium, con nombres de SKU como EP1. Si decide ejecutar la aplicación de funciones en un plan Premium, asegúrese de crear un plan con un nombre de SKU que comience por "E", como EP1. Nombres de SKU de plan de App Service que comienzan por "P", como P1V2 (plan Premium pequeño P1V2), son en realidad Planes de hospedaje dedicados. Dado que son Premium dedicados y no elásticos, los planes con nombres de SKU que comienzan por "P" no se escalan dinámicamente y pueden aumentar los costos.
Disponibilidad regional
Los planes Premium con redundancia de zona están disponibles en las siguientes regiones:
| América | Europa | Oriente Medio | África | Asia Pacífico |
|---|---|---|---|---|
| Sur de Brasil | Centro de Francia | Centro de Israel | Norte de Sudáfrica | Este de Australia |
| Centro de Canadá | Centro-oeste de Alemania | Centro de Catar | Centro de la India | |
| Centro de EE. UU. | Norte de Italia | Norte de Emiratos Árabes Unidos | Norte de China 3 | |
| Este de EE. UU. | Norte de Europa | Este de Asia | ||
| Este de EE. UU. 2 | Este de Noruega | Japón Oriental | ||
| Centro-sur de EE. UU. | Centro de Suecia | Sudeste de Asia | ||
| Oeste de EE. UU. 2 | Norte de Suiza | |||
| Oeste de EE. UU. 3 | Sur de Reino Unido 2 | |||
| Oeste de Europa |
Requisitos previos
La compatibilidad con zonas de disponibilidad es una característica del plan Premium. Estos son los requisitos o limitaciones actuales para habilitar las zonas de disponibilidad:
- Solo puede habilitar zonas de disponibilidad al crear un plan Premium para la aplicación de funciones. No se puede convertir un plan Premium existente para que use zonas de disponibilidad.
- Debe usar una cuenta de almacenamiento con redundancia de zona (ZRS) para la cuenta de almacenamiento de la aplicación de funciones. Si usa otro tipo de cuenta de almacenamiento, es posible que Functions muestre un comportamiento inesperado durante una interrupción zonal.
- Se admite Windows y Linux.
- Debe hospedarse en un plan de hospedaje elástico Premium o dedicado. Para obtener información sobre cómo usar la redundancia de zona con un plan dedicado, consulte Migración de App Service para obtener compatibilidad con zonas de disponibilidad.
- La compatibilidad con las zonas de disponibilidad no está disponible actualmente en las aplicaciones de funciones de los planes de consumo.
- Las instancias de Function Apps hospedadas en un plan Premium también deben tener un recuento mínimo de tres instancias que estén siempre listas.
- La plataforma aplicará este recuento mínimo en segundo plano si especifica un recuento de instancias inferior a tres.
- Si no tiene un plan Premium o una unidad de escalado que admita zonas de disponibilidad, se encuentra en una región no admitida o tienes dudas, consulte la guía de migración.
Precios
No existen costes adicionales asociados a la habilitación de zonas de disponibilidad. Los precios de un plan de App Service Premium con redundancia de zona son los mismos que los de un plan Premium con una sola zona. Para cada plan de App Service que use, se le cobrará en función de la SKU que elija, la capacidad que especifique y las instancias a las que escale según los criterios de escalado automático. Si habilita zonas de disponibilidad pero especifica una capacidad inferior a tres para un plan de App Service, la plataforma aplica un recuento mínimo de instancias de tres para ese plan de App Service y le cobra por esas tres instancias.
Creación de un plan Premium con redundancia de zona y una aplicación de funciones
Actualmente hay dos maneras de implementar un plan Premium con redundancia de zona y una aplicación de funciones. Puede usar Azure Portal o una plantilla de ARM.
En Azure Portal, vaya a la página Crear aplicación de funciones. Para obtener más información sobre cómo crear una aplicación de funciones en el portal, consulte Creación de una aplicación de funciones.
Seleccione Functions Premium y, a continuación, seleccione el botón Seleccionar . En este artículo se describe cómo crear una aplicación con redundancia de zona en un plan Premium. La redundancia de zona no está disponible actualmente en los planes de consumo. Para obtener información sobre la redundancia de zona en los planes de App Service, consulte Confiabilidad de Azure App Service.
En la página Crear aplicación de funciones (Functions Premium), en la pestaña Datos básicos, escriba la configuración de la aplicación de funciones. Preste especial atención a la configuración de la tabla siguiente (también resaltada en la captura de pantalla siguiente), que tienen requisitos específicos para la redundancia de zona.
Configuración Valor sugerido Notas de la redundancia de zona Región Su región admitida preferida Región en la que se crea la nueva aplicación de funciones. Debe elegir una región que admita zonas de disponibilidad. Consulte la lista de disponibilidad de la región. Plan de precios Uno de los planes Elastic Premium. Para obtener más información, consulte SKU de instancia disponibles. En este artículo se describe cómo crear una aplicación con redundancia de zona en un plan Premium. La redundancia de zona no está disponible actualmente en los planes de consumo. Para obtener información sobre la redundancia de zona en los planes de App Service, consulte Confiabilidad en Azure App Service. Redundancia de zona habilitado Esta configuración especifica si la aplicación tiene redundancia de zona. No podrá seleccionar Enableda menos que haya elegido una región que admita redundancia de zona, como se ha descrito anteriormente.
En la pestaña Almacenamiento, escriba la configuración de la cuenta de almacenamiento de la aplicación de funciones. Preste especial atención a la configuración de la tabla siguiente, que tiene requisitos específicos para la redundancia de zona.
Configuración Valor sugerido Notas de la redundancia de zona Cuenta de almacenamiento Una cuenta de almacenamiento con redundancia de zona Como se describe en la sección requisitos previos, se recomienda encarecidamente usar una cuenta de almacenamiento con redundancia de zona para la aplicación de funciones con redundancia de zona. Para el resto del proceso, cree la aplicación de funciones de la forma habitual. No hay ninguna configuración en el resto del proceso de creación que afecte a la redundancia de zona.
Una vez que se crea e implementa el plan con redundancia de zona, cualquier aplicación de funciones hospedada en el nuevo plan tendrá redundancia de zona.
Migración de zonas de disponibilidad
Azure Function Apps no admite actualmente la migración local de instancias de aplicaciones de funciones existentes. Para obtener información sobre cómo migrar el plan Premium multiinquilino público de la zona de no disponibilidad a la característica de compatibilidad con zonas de disponibilidad, consulte Migración de App Service para obtener compatibilidad con zonas de disponibilidad.
Experiencia a nivel de zona
Todas las instancias de aplicaciones de funciones disponibles de las aplicaciones de funciones con redundancia de zona están habilitadas y procesan eventos. Si una zona está fuera de servicio, Functions detecta las instancias que se han perdido e intenta encontrar automáticamente nuevas instancias de reemplazo, si es necesario. El comportamiento de escala elástica se sigue aplicando. No obstante, en un escenario de zona fuera de servicio no hay ninguna garantía de que las solicitudes de instancias adicionales pueden tener éxito, ya que la reposición de instancias perdidas se produce con según un esfuerzo razonable. Las aplicaciones implementadas en un plan Premium habilitado para zonas de disponibilidad seguirán ejecutándose incluso cuando otras zonas de la misma región sufran una interrupción. Sin embargo, es posible que los comportamientos que no sean de tiempo de ejecución puedan verse afectados por una interrupción en otras zonas de disponibilidad. Estos comportamientos afectados pueden incluir la ampliación del plan Premium, la creación de aplicaciones, la configuración de aplicaciones y la publicación de aplicaciones. La redundancia de zona para los planes Premium solo garantiza un tiempo de actividad continuado para las aplicaciones implementadas.
Cuando Functions asigna instancias a un plan Premium con redundancia de zona, aplica un esfuerzo razonable de equilibrio de zona que ofrece la instancia de Azure Virtual Machine Scale Sets subyacente. Un plan Premium se considera equilibrado cuando cada zona tiene el mismo número de máquinas virtuales (± 1 VM) en las demás zonas usadas por el plan Premium.
Recuperación ante desastres entre regiones y continuidad empresarial
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
En este artículo se explican algunas de las estrategias que puede usar para implementar funciones que permitan la recuperación ante desastres.
Para la recuperación ante desastres para Durable Functions, consulte Recuperación ante desastres y distribución geográfica en Azure Durable Functions.
Recuperación ante desastres entre regiones
Dado que no hay redundancia integrada disponible, las funciones se ejecutan en una aplicación de funciones en una región específica de Azure. Para evitar que se pierdan los datos de la ejecución durante las interrupciones, puede implementar de forma redundante las mismas funciones en aplicaciones de funciones en varias regiones. Para obtener más información sobre las implementaciones en varias regiones, consulte la guía que tiene en Aplicación web de varias regiones de alta disponibilidad.
Al ejecutar el mismo código de función en varias regiones, hay dos patrones que se deben tener en cuenta, activo-activo y activo-pasivo.
Patrón activo-activo para funciones de desencadenador HTTP
Las funciones de ambas regiones están ejecutando y procesando eventos de forma activa, ya sea de manera duplicada o en rotación. Se recomienda usar un patrón activo-activo en combinación con Azure Front Door para las funciones críticas desencadenadas por HTTP, que pueden enrutar y redondear solicitudes HTTP entre funciones que se ejecutan en varias regiones. Front Door también puede comprobar periódicamente el estado de cada punto de conexión. Cuando una función de una región deja de responder a las comprobaciones de estado, Azure Front Door la quita de la rotación y solo reenvía el tráfico a las funciones restantes que estén en buen estado.
Importante
Aunque se recomienda encarecidamente usar el patrón activo-pasivo para las funciones de desencadenador que no son HTTPS. Todavía puede realizar implementaciones de tipo activa/activa para funciones de desencadenador que no son HTTP. Sin embargo, debe tener en cuenta cómo interactuarán o se coordinarán entre sí las dos regiones. Cuando implemente la misma aplicación de funciones en dos regiones y cada una de ellas se desencadene en la misma cola de Service Bus, estas actuarán como consumidores rivales al quitar esa cola. Si bien esto significa que cada mensaje solo se procesará mediante una de las instancias, también significa que todavía hay un único punto de error en la única instancia de Service Bus.
En su lugar, puede implementar dos colas de Service Bus: una en una región primaria y la otra en una región secundaria. En este caso, puede tener dos aplicaciones de funciones, cada una de las cuales apuntará a la cola de Service Bus que esté activa en su región. El desafío de esta topología es saber cómo se distribuyen los mensajes de cola entre las dos regiones. A menudo, esto significa que cada publicador intenta publicar un mensaje en ambas regiones, y ambas aplicaciones de funciones activas procesan cada mensaje. Aunque esta situación crea un patrón activo/activo esperado, también presenta otras dificultades relacionadas con la duplicación del proceso y cuándo o cómo se consolidan los datos.
Patrón activo-pasivo para funciones de desencadenador que no son HTTPS
Se recomienda usar el patrón activo-pasivo para las funciones desencadenadas por eventos, no HTTP, como Service Bus y Event Hubs desencadenadas.
Para crear redundancia para funciones de desencadenador que no son HTTP, use un patrón activo-pasivo. Con un patrón activo-pasivo, las funciones se ejecutan activamente en la región que recibe eventos; mientras que las mismas funciones de una segunda región permanecen inactivas. El patrón activo/pasivo proporciona una manera de que solo una sola función procese cada mensaje pero, al mismo tiempo, ofrece un mecanismo para conmutar por error a una región secundaria en caso de desastre. Las aplicaciones de funciones funcionan con los comportamientos de conmutación por error de los servicios asociados, como la recuperación geográfica de Azure Service Bus y la recuperación geográfica de Azure Event Hubs.
Considere crear una topología de ejemplo mediante un desencadenador de Azure Event Hubs. En este caso, el patrón activo/pasivo requiere la participación de los siguientes componentes:
- Azure Event Hubs implementado en una región primaria y una secundaria.
- Recuperación ante desastres geográfica habilitada para emparejar el centro de eventos principal y el secundario. Esto también crea un alias que puede usar para conectarse a los centros de eventos y cambiar del principal al secundario sin tener que cambiar la información de conexión.
- Las aplicaciones de funciones se implementan en la región principal y secundaria (conmutación por error), donde la aplicación de la región secundaria básicamente está inactiva porque no se envían mensajes allí.
- Las aplicaciones de funciones se desencadenan en la cadena de conexión directa (sin alias) de su centro de eventos correspondiente.
- Los publicadores del centro de eventos deben publicar en la cadena de conexión de alias.
Antes de conmutar por error, los publicadores que envían contenido al alias compartido se enrutarán al centro de eventos principal. La aplicación de función principal escucha exclusivamente al centro de eventos principal. La aplicación de funciones secundaria será pasiva y estará inactiva. En cuanto se inicia la conmutación por error, los publicadores que envíen contenido al alias compartido se enrutarán al centro de eventos secundario. Así pues, la aplicación de funciones secundaria pasará a estar activa y comenzará a desencadenarse automáticamente. La conmutación por error efectiva a una región secundaria se puede controlar íntegramente desde el centro de eventos, donde las funciones solo se activan cuando lo hace el centro de eventos correspondiente.
Puede obtener más información y detalles sobre la conmutación por error con Service Bus y Event Hubs.