Fiabilité dans Azure Functions
Cet article décrit la prise en charge de la fiabilité dans Azure Functions et couvre la résilience intra-régionale avec les zones de disponibilité et la reprise d’activité de récupération inter-région et la continuité d’activité. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez fiabilité d’Azure.
La prise en charge des zones de disponibilité pour Azure Functions est disponible dans les plans Premium (Premium élastique) et les plans dédiés (App Service). Cet article porte sur la prise en charge de la redondance de zone pour les plans Premium. Pour plus d’informations sur la redondance de zone avec les plans dédiés, consultez Migrer App Service vers la prise en charge des zones de disponibilité.
Prise en charge des zones de disponibilité
Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.
Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.
Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.
Azure Functions prend en charge un déploiement redondant interzone.
Quand vous configurez Functions en tant que redondance de zone, la plateforme répartit automatiquement les instances d’application de fonction sur les trois zones de la région sélectionnée.
La répartition d’instances avec un déploiement redondant interzone est déterminée à l’intérieur des règles suivantes, même lorsque l’application est mise à l’échelle et sortante :
- Le nombre minimum d’instances d’application de fonction est de trois.
- Lorsque vous spécifiez une capacité supérieure à trois, les instances sont réparties uniformément uniquement lorsque la capacité est un multiple de 3.
- Pour une valeur de capacité supérieure à 3*N, les instances supplémentaires sont réparties sur une ou deux zones restantes.
Important
Azure Functions peut s’exécuter sur la plateforme Azure App Service. Dans la plateforme App Service, les plans qui hébergent des applications de fonction du plan Premium sont appelés plans Élastique Premium, avec des noms de référence SKU tels que EP1. Si vous choisissez d’exécuter votre application de fonction sur un plan Premium, veillez à créer un plan avec un nom de référence SKU qui commence par « E », par exemple EP1. Les noms des références SKU du plan App Service qui commencent par « P », par exemple P1V2 (plan Premium P1V2 Small), sont en fait des plans d’hébergement dédiés. Comme ils sont Dédiés et non Élastique Premium, les plans avec des noms de références SKU commençant par « P » ne sont pas mis à l’échelle de façon dynamique et peuvent augmenter vos coûts.
Disponibilité régionale
Les plans Premium redondants interzones sont disponibles dans les régions suivantes :
| Amérique | Europe | Moyen-Orient | Afrique | Asie-Pacifique |
|---|---|---|---|---|
| Brésil Sud | France Centre | Israël Central | Afrique du Sud Nord | Australie Est |
| Centre du Canada | Allemagne Centre-Ouest | Qatar Central | Inde centrale | |
| USA Centre | Italie Nord | Émirats arabes unis Nord | Chine Nord 3 | |
| USA Est | Europe Nord | Asie Est | ||
| USA Est 2 | Norvège Est | Japon Est | ||
| États-Unis - partie centrale méridionale | Suède Centre | Asie Sud-Est | ||
| USA Ouest 2 | Suisse Nord | |||
| USA Ouest 3 | Sud du Royaume-Uni | |||
| Europe Ouest |
Prérequis
La prise en charge des zones de disponibilité est une propriété du plan Premium. Les exigences/limitations actuelles relatives à l’activation des zones de disponibilité sont les suivantes :
- Vous pouvez activer les zones de disponibilité seulement lors de la création d’un plan Premium pour votre application de fonction. Vous ne pouvez pas convertir un plan Premium existant pour utiliser des zones de disponibilité.
- Vous devez utiliser un compte de stockage redondant interzone (ZRS) pour le compte de stockage de votre application de fonction. Si vous utilisez un autre type de compte de stockage, Functions peut présenter un comportement inattendu lors d’une panne zonale.
- Windows et Linux sont tous les deux pris en charge.
- Doit être hébergé sur un plan d’hébergement Premium élastique ou dédié. Pour savoir comment utiliser la redondance de zone avec un plan dédié, consultez Migrer App Service vers la prise en charge des zones de disponibilité.
- La prise en charge des zones de disponibilité n’est actuellement pas disponible pour les applications de fonction sur les plans Consommation.
- Les applications de fonction hébergées sur un plan Premium doivent disposer d’un nombre minimal de trois instances toujours prêtes.
- La plateforme applique ce nombre minimal en coulisse si vous spécifiez un nombre d’instances inférieur à trois.
- Si vous n’utilisez pas un plan Premium ou une unité d’échelle qui prend en charge les zones de disponibilité, si vous êtes dans une région non prise en charge ou si vous n’êtes pas sûr, consultez les recommandations en matière de migration.
Tarifs
Aucun coût supplémentaire n’est associé à l’activation des zones de disponibilité. La tarification d’un plan App Service Premium redondant interzone est identique à celle d’un plan Premium avec une seule zone. Pour chaque plan App Service que vous utilisez, vous êtes facturé en fonction du SKU que vous choisissez, de la capacité que vous spécifiez et des instances que vous mettez à l’échelle en fonction de vos critères de mise à l’échelle automatique. Si vous activez les zones de disponibilité mais que vous spécifiez une capacité inférieure à trois pour un plan App Service, la plateforme applique un nombre d’instances minimal de trois pour ce plan App Service et vous facture l’utilisation de ces trois instances.
Créer une application de fonction et un plan Premium redondants interzones
Il existe actuellement deux façons de déployer un plan Premium et une application de fonction redondants interzones. Vous pouvez utiliser soit le portail Azure soit un modèle ARM.
Sur le Portail Azure, accédez à la page Créer une application de fonction. Pour plus d’informations sur la création d’une application de fonction sur le portail, consultez Créer une application de fonction.
Sélectionnez Functions Premium, puis cliquez sur le bouton Sélectionner. Cet article explique comment créer une application redondante interzone dans un plan Premium. La redondance de zone n’est actuellement pas disponible dans les plans Consommation. Pour plus d’informations sur la redondance de zone sur les plans App Service, consultez Fiabilité dans Azure App Service.
Sur la page Créer une application de fonction (Functions Premium), sous l’onglet Informations de base, entrez les paramètres de votre application de fonction. Faites attention aux paramètres du tableau suivant (également mis en évidence dans la capture d’écran suivante), qui ont des exigences spécifiques pour la redondance de zone.
Setting Valeur suggérée Remarques relatives à la redondance de zone Région Votre région prise en charge préférée La région dans laquelle l’application de fonction est créée. Vous devez choisir une région qui prend en charge les zones de disponibilité. Consultez la liste de disponibilité de la région. Plan tarifaire Un des plans Elastic Premium. Pour plus d’informations, consultez Références SKU d’instance disponibles. Cet article explique comment créer une application redondante interzone dans un plan Premium. La redondance de zone n’est actuellement pas disponible dans les plans Consommation. Pour plus d’informations sur la redondance de zone sur les plans App Service, consultez Fiabilité dans Azure App Service. Redondance de zone Activé(e) Ce paramètre spécifie si votre application est redondante interzone. Vous ne pourrez pas sélectionner Enabled, sauf si vous avez choisi une région qui prend en charge la redondance de zone, comme décrit précédemment.
Sous l’onglet Stockage , entrez les paramètres de votre compte de stockage d’application de fonction. Portez une attention particulière au paramètre du tableau suivant, qui a des exigences spécifiques pour la redondance de zone.
Setting Valeur suggérée Remarques relatives à la redondance de zone Compte de stockage Un compte de stockage redondant interzone Comme décrit dans la section sur les prérequis, nous vous recommandons vivement d’utiliser un compte de stockage redondant interzone pour votre application de fonction redondante interzone. Pour le reste du processus de création de l’application de fonction, créez votre application de fonction comme en temps normal. Il n’existe aucun paramètre dans le reste du processus de création qui affecte la redondance de zone.
Une fois le plan redondant dans une zone créé et déployé, toute application de fonction hébergée sur votre nouveau plan est alors redondante dans une zone.
Migration de zones de disponibilité
Actuellement, Azure Function Apps ne prend pas en charge la migration sur place des instances d’applications de fonction existantes. Pour plus d’informations sur la migration du plan Premium multilocataire public depuis une non-zone de disponibilité vers la prise en charge des zones de disponibilité, consultez Migrer App Service vers la prise en charge des zones de disponibilité.
Expérience en cas de panne de zone
Toutes les instances d’applications de fonction disponibles des applications de fonction redondantes interzones sont activées et traitent les événements. Quand une zone tombe en panne, Functions détecte les instances perdues et tente automatiquement de trouver de nouvelles instances de remplacement si nécessaire. Le comportement de mise à l’échelle élastique s’applique néanmoins toujours. Cependant, dans un scénario de zone défaillante, il n’existe aucune garantie que les demandes d’instances supplémentaires puissent aboutir, car le remplacement des instances perdues se fait dans la mesure du possible. Les applications déployées dans un plan Premium avec zones de disponibilité activées continueront à s’exécuter même si d’autres zones de la même région subissent une panne. Cependant, il est possible que des comportements non liés à l’exécution puissent néanmoins être affectés par une panne dans d’autres zones de disponibilité. Ces comportements impactés peuvent inclure la mise à l’échelle des plans Premium, la création d’applications, la configuration d’applications et la publication d’applications. La redondance interzone pour les plans Premium garantit seulement la continuité du temps de fonctionnement des applications déployées.
Quand Functions alloue des instances à un plan Premium redondant interzone, il utilise le meilleur équilibrage des zones possible qu’offre les groupes de machines virtuelles identiques Azure sous-jacents. Un plan Premium est considéré comme équilibré quand chaque zone a le même nombre de machines virtuelles (± 1 machine virtuelle) dans toutes les autres zones utilisées par le plan Premium.
Récupération d’urgence et continuité d’activité inter-région
La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.
En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.
Cette section explique certaines des stratégies que vous pouvez adopter pour déployer Functions assurant la récupération d’urgence.
Pour la récupération d’urgence pour Durable Functions, consultez la récupération d’urgence et la géo-distribution dans Azure Durable Functions.
Reprise d’activité multi-régionale
Comme il n'y a pas de redondance intégrée, les fonctions s'exécutent dans une application de fonction dans une région Azure spécifique. Pour éviter la perte d’exécution pendant les pannes, vous pouvez déployer les mêmes fonctions de manière redondante pour des applications de fonction dans plusieurs régions. Pour en savoir plus sur les déploiements multirégions, consultez l’aide dans Application web multirégion hautement disponible.
Lorsque vous exécutez le même code de fonction dans plusieurs régions, il y a deux modèles à prendre en compte, actif-actif et actif-passif.
Modèle actif-actif pour les fonctions de déclencheur HTTP
Avec un modèle actif-actif, les fonctions des deux régions s’exécutent activement et traitent les événements, soit de manière dupliquée, soit en rotation. Il est recommandé d’utiliser un modèle actif-actif en combinaison avec Azure Front Door pour vos fonctions déclenchées HTTP critiques, qui peuvent acheminer et arrondir des requêtes HTTP entre les fonctions exécutées dans plusieurs régions. L’instance Front Door peut contrôler aussi régulièrement l’intégrité de chaque point de terminaison. Lorsqu’une fonction d’une région cesse de répondre aux contrôles d’intégrité, Azure Front Door la retire de la rotation et achemine le trafic vers les fonctions saines restantes uniquement.
Important
Toutefois, il est fortement recommandé d’utiliser le modèle actif-passif pour les fonctions de déclencheur non HTTPS. Vous pouvez créer des déploiements actifs-actifs pour les fonctions non déclenchées par le protocole HTTP. Toutefois, vous devez réfléchir à la façon dont les deux régions actives vont interagir ou se coordonner entre elles. Lorsque vous déployez la même application de fonction dans deux régions, chacune d’entre elles se déclenchant sur la même file d’attente Service Bus, celles-ci agissent en tant que consommateurs concurrents pour retirer les messages de cette file d’attente. Chaque message n’est alors traité que par l’une des deux instances. Cependant, cela signifie aussi qu’il existe toujours un point de défaillance unique sur l’instance de Service Bus.
Au lieu de cela, vous pouvez déployer deux files d’attente Service Bus, l’une dans une région primaire et l’autre dans une région secondaire. Dans ce cas, vous pouvez avoir deux applications de fonction, chacune pointant vers la file d’attente Service Bus active dans sa région. La difficulté de cette topologie réside dans la manière dont les messages de la file d’attente sont distribués entre les deux régions. Cela signifie souvent que chaque serveur de publication tente de publier un message dans les deux régions et que chaque message est traité par les deux applications de fonction actives. Bien que cela crée le modèle actif/actif souhaité, d’autres difficultés apparaissent concernant la duplication du calcul ainsi que la façon dont les données sont regroupées (et à quel moment).
Modèle actif-passif pour les fonctions de déclencheur non HTTPS
Il est recommandé que vous utilisiez ce modèle actif-passif pour les fonctions pilotées par des événements et non déclenchées par HTTP, notamment les fonctions déclenchées par Service Bus ou Event Hubs.
Pour créer une redondance pour les fonctions de déclencheur non HTTP, utilisez un modèle actif-passif. Avec un modèle actif-passif, les fonctions s’exécutent activement dans la région qui reçoit les événements ; tandis que les mêmes fonctions dans une deuxième région restent inactives. Le modèle actif/passif permet à une fonction unique de traiter chaque message, tout en offrant un mécanisme de basculement vers la région secondaire en cas de sinistre. Les applications de fonction fonctionnent avec les comportements de basculement des services partenaires, tels que la géorécupération d’Azure Service Bus et la géorécupération d’Azure Event Hubs.
Prenons un exemple de topologie utilisant un déclencheur Azure Event Hubs. Dans ce cas, le modèle actif/passif nécessite l’implication des composants suivants :
- Azure Event Hubs est déployé dans une région primaire et une région secondaire.
- La géorécupération d’urgence est activée pour jumeler les hubs d’événements primaire et secondaire. Ceci crée également un alias que vous pouvez utiliser pour vous connecter aux Event Hubs et passer du hub primaire au hub secondaire sans changer les informations de connexion.
- Les applications de fonction sont déployées dans les régions primaire et secondaire (basculement), l’application de la région secondaire étant essentiellement inactive, car les messages n’y sont pas envoyés.
- Les applications de fonction se déclenchent sur la chaîne de connexion directe (et non l’alias) pour l’Event Hub correspondant.
- Les serveurs de publication pointant vers le hub d’événements doivent publier sur la chaîne de connexion d’alias.
Avant le basculement, les serveurs de publication effectuant des envois vers l’alias partagé sont routés vers l’Event Hub primaire. L’application de fonction primaire écoute exclusivement le hub d’événements primaire. L’application de fonction secondaire est passive et inactive. Dès que le basculement est déclenché, les serveurs de publication qui effectuent des envois vers l’alias partagé sont routés vers l’Event Hub secondaire. L’application de fonction secondaire devient alors active et se déclenche automatiquement. Il est possible de réaliser en intégralité un basculement efficace vers une région secondaire à partir du hub d’événements, les fonctions devenant actives uniquement quand le hub d’événements correspondant est actif.
Découvrez d’autres informations et éléments à prendre en compte pour le basculement avec Service Bus et Event Hubs.