Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 con zonas de disponibilidad para Azure Functions depende del plan de hospedaje de Functions:
Plan de hospedaje | Nivel de soporte | Para obtener más información... |
---|---|---|
Plan de consumo flexible | Versión preliminar | Seleccione Flex Consumption (Consumo flexible ) en la parte superior de este artículo. |
Plan Elastic Premium | Disponibilidad general | Seleccione Premium en la parte superior de este artículo. |
Plan Dedicado (App Service) | Disponibilidad general | Consulte Confiabilidad en Azure App Service. |
Plan de consumo | n/a | No es compatible con el plan de consumo. |
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.
Azure Functions admite una implementación con redundancia de zona.
Compatibilidad con zonas de disponibilidad
Importante
La compatibilidad con zonas de disponibilidad al hospedar la aplicación en un plan de consumo flexible está actualmente en versión preliminar.
Al configurar las aplicaciones del plan de Consumo flexible como redundantes de zona, la plataforma propaga automáticamente las instancias de la aplicación de funciones en las zonas de la región seleccionada, con reglas diferentes para las instancias que siempre están listas frente a las de demanda.
Cuando la redundancia de zona está habilitada en un plan de consumo flexible, la propagación de instancias se determina dentro de las reglas siguientes:
- Las instancias Siempre listas se distribuyen entre al menos dos zonas de forma round-robin.
- Las instancias a petición, que se crean como resultado de los volúmenes de origen de eventos a medida que la aplicación se escala más allá de estar siempre lista, se distribuyen entre zonas de disponibilidad con el mejor esfuerzo. Esto significa que para las instancias a petición, se prefiere una escalabilidad horizontal más rápida, incluso por encima de una distribución uniforme entre zonas de disponibilidad. La plataforma intenta equilibrar la distribución a lo largo del tiempo.
- Para garantizar la resiliencia de la zona con zonas de disponibilidad, la plataforma mantiene automáticamente al menos dos instancias siempre listas para cada función de escalado por función o por grupo, independientemente de la configuración siempre lista para la aplicación. Las instancias creadas por la plataforma son administradas por la plataforma, se facturan como instancias listas para siempre y no cambian las opciones de configuración siempre preparadas.
Al configurar planes de aplicación de funciones de Elastic Premium como con redundancia de zona, la plataforma distribuye automáticamente las instancias de la aplicación de funciones entre las 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 número mínimo de instancias de la aplicación de funciones es dos.
- Cuando se especifica una capacidad mayor que el número de zonas, las instancias solo se distribuyen uniformemente cuando la capacidad es un múltiplo del número de zonas.
- Para un valor de capacidad superior al número de zonas * Número de instancias, las instancias adicionales se distribuyen entre las zonas restantes.
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
. Los nombres de SKU del plan de App Service que comienzan por P
, como P1V2
(plan premium V2 pequeño), son planes de hospedaje dedicados. Dado que son Dedicados y no Elastic Premium, los planes con nombres de SKU que comienzan por P
no se escalan dinámicamente y pueden aumentar los costos.
Disponibilidad regional
Actualmente, no todas las regiones admiten redundancia de zona para los planes de consumo flex. Puede usar la CLI de Azure para ver las regiones que lo admiten:
Si aún no lo ha hecho, instale e inicie sesión en Azure mediante la CLI de Azure:
az login
El comando
az login
inicia sesión en la cuenta de Azure.Use este
az functionapp list-flexconsumption-locations
comando con la--zone-redundant=true
opción para devolver una lista de regiones que admiten actualmente planes de consumo flexible con redundancia de zona:az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table
Al crear una aplicación de consumo flexible en Azure Portal, la Zone redundancy
sección de la página Aspectos básicos se habilita cuando la región elegida la admite.
Los planes Premium con redundancia de zona están disponibles en estas 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 | |||
Oeste de Europa |
Requisitos previos
El soporte para zonas de disponibilidad es una propiedad del plan de consumo flexible. Estas son las consideraciones actuales para usar zonas de disponibilidad:
- Puede habilitar zonas de disponibilidad en el plan durante la creación de la aplicación.
- Puede habilitar o deshabilitar zonas de disponibilidad mediante la actualización de la configuración de recursos del plan.
- Debe usar una cuenta de almacenamiento con redundancia de zona (ZRS) para la cuenta de almacenamiento de host predeterminada de la aplicación de funciones. Si usa un tipo diferente de cuenta de almacenamiento, es posible que la aplicación se comporte inesperadamente durante una interrupción zonal.
- Debe hospedarse en un plan de consumo flexible .
La compatibilidad con zonas de disponibilidad es una característica del plan Premium. Estas son las consideraciones actuales para las zonas de disponibilidad:
- Solo puede habilitar zonas de disponibilidad en el plan al crear la aplicación. 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 host predeterminada de la aplicación de funciones. Si usa un tipo diferente de cuenta de almacenamiento, es posible que la aplicación se comporte inesperadamente durante una interrupción zonal.
- Se admite Windows y Linux.
- Las aplicaciones de funciones hospedadas en un plan Premium deben tener como mínimo dos instancias listas para siempre.
- La plataforma aplica este recuento mínimo en segundo plano si especifica un recuento de instancias inferior a dos.
- 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 hay ningún medidor independiente asociado a la habilitación de zonas de disponibilidad. Los precios de las instancias usadas para una aplicación de consumo flexible con redundancia de zona son los mismos que los precios de una aplicación de consumo flexible de una sola zona. Para más información, consulte Facturación.
Cuando se habilitan zonas de disponibilidad en una aplicación con una configuración de instancia siempre lista para menos de dos instancias para cada función o grupo de escalado por función, la plataforma crea automáticamente dos instancias del tipo siempre listo para cada función o grupo. Estas nuevas instancias también se facturan como instancias siempre listas.
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 en un plan con menos de dos instancias, la plataforma aplica un número mínimo de instancias de dos para ese plan de App Service y se le cobra por ambas instancias.
Creación de una aplicación de funciones en un plan con redundancia de zona
Actualmente hay varias maneras de implementar una aplicación de consumo flexible con redundancia de zona.
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 Flex Consumption y, a continuación, seleccione el botón Seleccionar.
En la página Crear aplicación de funciones (Consumo Flexible), en la pestaña Aspectos 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 el plan de consumo flexible. Debe seleccionar una región que admita zonas de disponibilidad. Consulte la lista de disponibilidad de la región. Redundancia de zona habilitado Esta configuración especifica si la aplicación tiene redundancia de zona. Solo puede seleccionar Enabled
cuando haya elegido una región que admita redundancia de zona.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, la aplicación de funciones de consumo flexible hospedada en el nuevo plan tendrá redundancia de zona.
Actualización de un plan de consumo flexible para que sea con redundancia de zona
Cambiar la redundancia de zona de la aplicación requiere un reinicio, lo que provoca tiempo de inactividad en la aplicación.
Antes de actualizar el plan de consumo flexible para que sea con redundancia de zona, debe actualizar la cuenta de almacenamiento de host predeterminado para que también tenga redundancia de zona. Si usa una cuenta de almacenamiento independiente para el contenedor de implementación de la aplicación, también debe actualizarla para que tenga redundancia de zona.
Siga estos pasos para preparar las cuentas de almacenamiento para el cambio:
- Revisar Consideraciones de almacenamiento.
- Cree o identifique una cuenta de almacenamiento con redundancia de zona para que sea la cuenta de almacenamiento de host predeterminada para la aplicación.
- Actualice la configuración de la aplicación relacionada con el almacenamiento de la aplicación, como
AzureWebJobsStorage
, para hacer referencia a la cuenta de almacenamiento con redundancia de zona. Consulte Trabajar con la configuración de la aplicación. - Actualice la cuenta de almacenamiento de implementación de la aplicación, que puede ser la misma o diferente que la cuenta de almacenamiento asociada a la aplicación. Consulte Configuración de las opciones de implementación.
Una vez actualizadas las cuentas de almacenamiento usadas por la aplicación, puede actualizar el plan de consumo flexible para que tenga redundancia de zona mediante las plantillas de Bicep o ARM. Actualmente, Azure Portal no admite la realización de actualizaciones de redundancia de zona en el plan.
Actualmente no se admite.
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 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 el plan de Elastic Premium. 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 Enabled
a 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 zona de disponibilidad
Actualmente no se puede cambiar la compatibilidad de zona de disponibilidad de un plan Elastic Premium para una aplicación de funciones existente. 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 de bajada de zona
Todas las instancias de aplicaciones de funciones disponibles de las aplicaciones del plan de consumo flexible con redundancia de zona están habilitadas y procesan eventos. Las aplicaciones flex Consumption siguen ejecutándose incluso cuando otras zonas de la misma región sufren una interrupción. Sin embargo, es posible que los comportamientos fuera del tiempo de ejecución se vean afectados debido a una interrupción en otras zonas de disponibilidad. Los comportamientos de la aplicación de funciones estándar que pueden afectar a la disponibilidad incluyen:
- Ampliación
- Creación de aplicación
- Cambios de configuración
- Implementaciones
La redundancia de zona para los planes de consumo flexible solo garantiza un tiempo de actividad continuado para las aplicaciones implementadas en ejecución.
Cuando una zona deja de funcionar, Functions detecta las instancias perdidas e intenta buscar o crear automáticamente instancias de reemplazo, según sea necesario, en las zonas disponibles. Durante la interrupción zonal, la plataforma intenta restaurar el equilibrio en las zonas disponibles restantes.
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 no relacionados con el tiempo de ejecución podrían verse afectados por un fallo 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 en todas las demás zonas usadas por el plan Premium, más o menos una máquina virtual.
Recuperación ante desastres entre regiones y continuidad empresarial
La recuperación ante desastres (DR) hace referencia a las prácticas que las organizaciones usan para recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores que producen 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 aplicación que admita activamente la recuperación ante desastres. Antes de empezar a crear el plan de recuperación ante desastres, consulte Recomendaciones para diseñar una estrategia de recuperación ante desastres.
Para la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En este modelo, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Sin embargo, muchos servicios de Azure no replican automáticamente datos ni se revierten de una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, es 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. Puede usar características específicas del servicio para admitir la recuperación rápida con el fin de contribuir al desarrollo del plan de recuperación ante desastres.
En esta sección se explican algunas de las estrategias que puede usar para implementar una aplicación de funciones para permitir 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. Debería 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.
Para obtener un ejemplo, consulte el ejemplo sobre cómo implementar el patrón de geode mediante la implementación de la API en geodes en regiones distribuidas de Azure.
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.
Patrón activo-activo para funciones de desencadenador que no son HTTPS
Aunque se recomienda usar el patrón activo-pasivo para las funciones de desencadenador que no son HTTPS, todavía puede crear implementaciones activo-activo para funciones de desencadenador que no son HTTP. Antes de implementar este patrón, debe tener en cuenta cómo interactúan las dos regiones activas o se coordinan entre sí.
Por ejemplo, considere la posibilidad de contar con el mismo código de función desencadenado de Service Bus implementado en dos regiones, pero que se desencadene en la misma cola de Service Bus. En este caso, ambas funciones actúan como consumidores competidores al quitar la cola única de la cola. Aunque cada mensaje solo se puede procesar mediante una de las dos instancias de la aplicación, también significa que todavía hay un único punto de error, que es la única instancia de Service Bus.
En su lugar, puede implementar dos colas de Service Bus, con una en una región primaria, 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.