Partager via

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 dépend de votre plan d’hébergement Functions :

Plan d’hébergement Niveau du support Pour plus d’informations...
Plan Consommation Flex Disponibilité générale Sélectionnez Flex Consumption en haut de cet article.
Plan Élastique Premium Disponibilité générale Sélectionnez Premium en haut de cet article.
Plan dédié (App Service) Disponibilité générale Consultez fiabilité dans Azure App Service.
Plan Consommation n/a Non pris en charge par le plan Consommation.

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Azure Functions prend en charge un déploiement redondant interzone.

Prise en charge des zones de disponibilité

Lorsque vous configurez des applications du plan Flex Consumption comme redondantes entre les zones, la plateforme répartit automatiquement les instances de votre application fonctionnelle dans les zones de la région sélectionnée, avec des règles différentes pour les instances toujours prêtes et celles à la demande.

Lorsque la redondance de zone est activée dans un plan Flex Consumption, la répartition d’instances est déterminée à l’intérieur des règles suivantes :

  • Les instances de toujours prêtes sont réparties sur au moins deux zones de manière tourniquet.
  • Les instances à la demande, créées à partir de volumes sources d’événements lorsque l’application s’adapte au-delà de son état « toujours prête », sont réparties entre les zones de disponibilité selon un principe du meilleur effort. Cela signifie que pour les instances à la demande, un scale-out plus rapide est préférable à la répartition même entre les zones de disponibilité. La plateforme tente d'équilibrer la distribution au fil du temps.
  • Pour garantir la résilience des zones grâce aux zones de disponibilité, la plateforme maintient automatiquement au moins deux instances toujours prêtes pour chaque fonction ou groupe de mise à l'échelle par fonction, indépendamment de la configuration toujours prête pour l’application. Toutes les instances créées par la plateforme sont gérées par la plateforme, facturées en tant qu’instances toujours prêtes et ne modifient pas les paramètres de configuration toujours prêts.

Quand vous configurez l’application de fonction Elastic Premium en tant que redondance interzone, la plateforme répartit automatiquement les instances d’application de fonction entre les 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 minimal d’instances d’application de fonction est de deux.
  • Lorsque vous spécifiez une capacité supérieure au nombre de zones, les instances sont réparties uniformément lorsque la capacité est un multiple du nombre de zones.
  • Pour une valeur de capacité supérieure au nombre de zones * nombre d’instances, des instances supplémentaires sont réparties entre les 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 de plan Premium sont appelés plans Elastic Premium, avec des noms de référence SKU comme EP1. Si vous choisissez d’exécuter votre application de fonction sur un plan Premium, veillez à créer un plan avec un nom SKU qui commence par E, comme par exemple EP1. Les noms de référence SKU du plan App Service qui commencent par P, tels que P1V2 (plan Premium V2 Petite), sont des plans d’hébergement dédiés. Étant donné qu'ils sont "Dedicated" et non Elastic Premium, les plans avec des noms de référence SKU commençant par P ne sont pas mis à l'échelle dynamiquement et peuvent entraîner une augmentation de vos coûts.

Disponibilité régionale

Actuellement, toutes les régions ne prennent pas en charge la redondance de zone pour les plans Flex Consumption. Vous pouvez utiliser Azure CLI pour afficher les régions qui le prennent en charge :

  1. Si ce n’est déjà fait, installez et connectez-vous à Azure à l’aide d’Azure CLI :

    az login

    La commande az login vous connecte à votre compte Azure.

  2. Utilisez cette az functionapp list-flexconsumption-locations commande avec l’option --zone-redundant=true pour renvoyer une liste de régions qui prennent actuellement en charge les plans Flex Consumption redondants interzone :

    az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table

Lorsque vous créez une application Flex Consumption dans le portail Azure, la Zone redundancy section de la page Informations de base est activée lorsque votre région choisie la prend en charge.

Les plans Premium redondants interzones sont disponibles dans ces régions :

Amérique Europe Moyen-Orient Afrique Asie-Pacifique
Brésil Sud France Centre Israël Central Afrique du Sud Nord Australie Est
Canada Centre Allemagne Centre-Ouest Banque Centrale du Qatar 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 Royaume-Uni Sud
Europe Ouest

Prérequis

La prise en charge des zones de disponibilité est une caractéristique du plan « Flex Consumption ». Voici les considérations actuelles relatives à l’utilisation des zones de disponibilité :

La prise en charge des zones de disponibilité est une propriété du plan Premium. Voici les considérations actuelles relatives aux zones de disponibilité :

  • Vous ne pouvez activer les zones de disponibilité que dans le plan lorsque vous créez votre application. 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 hôte par défaut de votre application de fonction. Si vous utilisez un autre type de compte de stockage, votre application peut se comporter de façon inattendue lors d’une panne zonale.
  • Windows et Linux sont tous les deux pris en charge.
  • Les applications de fonction hébergées sur un plan Premium doivent avoir au moins deux instances toujours prêtes.
  • La plateforme applique ce nombre minimal en arrière-plan si vous spécifiez un nombre d’instances inférieur à deux.
  • 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

Il n’existe aucun compteur distinct associé à l’activation des zones de disponibilité. La tarification des instances utilisées pour une application Flex Consumption redondante interzone est identique à celle d’une application Flex Consumption dans une seule zone. Pour en savoir plus, consultez Facturation.

Lorsque vous activez les zones de disponibilité dans une application avec une configuration d’instance « toujours prête » de moins de deux instances pour chaque fonction ou groupe de mise à l’échelle par fonction, la plateforme crée automatiquement deux instances de type toujours prête pour chaque fonction ou groupe de mise à l’échelle par fonction. Ces nouvelles instances sont également facturées en tant qu’instances toujours prêtes.

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 de zone unique. 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 des zones de disponibilité sur un plan avec moins de deux instances, la plateforme applique un nombre minimal d’instances de deux pour ce plan App Service et vous êtes facturé pour les deux instances.

Créer une application de fonction dans un plan redondant interzone

Il existe actuellement plusieurs façons de déployer une application de consommation flexible à redondance de zone.

  1. Pour créer une application de fonction dans un plan redondant interzone, vous devez disposer d’un compte de stockage redondant interzone existant. Si vous n’avez pas encore de compte de stockage redondant interzone, créez-en un avant de continuer.

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

  3. Sélectionnez Flex Consumption , puis sélectionnez le bouton Sélectionner .

  4. Dans la page Créer une application de fonction (Consommation Flex), 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.

    Réglage Valeur suggérée Remarques relatives à la redondance de zone
    Région Votre région prise en charge préférée Région dans laquelle votre plan Flex Consumption est créé. Vous devez sélectionner une région qui prend en charge les zones de disponibilité. Consultez la liste de disponibilité de la région.
    Redondance de zone Activé Ce paramètre spécifie si votre application est redondante interzone. Vous ne pouvez sélectionner Enabled que lorsque vous avez choisi une région qui prend en charge la redondance de zone.

    Capture d’écran de l’onglet Informations de base de la page de création de l’application de fonction Flex Consumption.

  5. Sous l’onglet Stockage , sélectionnez le compte de stockage redondant interzone pour votre 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.

    Réglage 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.

  6. 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 interzone créé et déployé, l’application de fonction de type consommation flexible hébergée sur votre nouveau plan est alors considérée comme redondante interzone.

Mettre à jour un plan de consommation flexible pour qu’il soit redondant interzone

La modification de la redondance de zone de votre application nécessite un redémarrage, ce qui entraîne un temps d’arrêt dans votre application.

Avant de mettre à jour votre plan Flex Consumption pour qu’il soit redondant interzone, vous devez mettre à jour le compte de stockage hôte par défaut pour qu’il soit également redondant interzone. Si vous utilisez un compte de stockage distinct pour le conteneur de déploiement de l’application, vous devez également le mettre à jour pour qu’il soit redondant interzone.

Procédez comme suit pour préparer vos comptes de stockage pour la modification :

  1. Examinez les considérations relatives au stockage.
  2. Créez ou identifiez un compte de stockage redondant interzone comme compte de stockage hôte par défaut pour l’application.
  3. Mettez à jour les paramètres d’application associés au stockage de l’application, par exemple AzureWebJobsStorage, pour référencer le compte de stockage redondant interzone. Consultez Utiliser les paramètres de l’application.
  4. Mettez à jour le compte de stockage de déploiement de l’application, qui peut être identique ou différent du compte de stockage associé à l’application. Consultez Configurer les paramètres de déploiement.

Une fois les comptes de stockage utilisés par votre application mis à jour, vous pouvez mettre à jour le plan Flex Consumption pour être redondant interzone à l’aide de modèles Bicep ou ARM. Le portail Azure ne prend actuellement pas en charge l’exécution de mises à jour de redondance de zone dans le plan.

  1. Dans le portail Azure, recherchez et sélectionnez l’application de fonction à mettre à jour.

  2. Sous Paramètres, sélectionnez Mise à l’échelle et concurrence.

  3. Sous l’onglet Redondance de zone, cochez Ajouter une redondance de zone pour activer la fonctionnalité. Si cette case est déjà cochée, vous pouvez décocher cette case pour désactiver la fonctionnalité.

  4. Sélectionnez Enregistrer pour valider vos modifications et redémarrer l’application.

Capture d’écran de l’onglet Mise à l’échelle et Concurrence d’une Application de fonction Flex Consumption.

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.

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

  2. Sélectionnez Functions Premium, puis cliquez sur le bouton Sélectionner.

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

    Réglage Valeur suggérée Remarques relatives à la redondance de zone
    Région Votre région prise en charge préférée Région dans laquelle votre plan Elastic Premium est créé. 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é 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.

    Capture d’écran de l’onglet Informations de base de la page de création de l’application de fonction.

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

    Réglage 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.

  5. 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é

Vous ne pouvez pas modifier actuellement la prise en charge de la zone de disponibilité d’un plan Elastic Premium pour une application de fonction existante. Pour plus d’informations sur la migration du plan Premium multilocataire public de la zone d’indisponibilité vers la prise en charge de la zone de disponibilité, consultez Migrer App Service vers la prise en charge de la zone de disponibilité.

Expérience en cas de panne de zone

Toutes les instances d’applications de fonction disponibles des applications de plan de consommation flexible redondantes interzones sont activées et traitent les événements. Les applications Flex Consumption continuent de s’exécuter même lorsque d’autres zones de la même région subissent une panne. Toutefois, il est possible que des comportements non liés à l’exécution puissent être affectés en raison d’une panne dans d’autres zones de disponibilité. Les comportements d’application de fonction standard qui peuvent affecter la disponibilité sont les suivants :

  • Croissance
  • Création d’une application
  • Modifications de configuration
  • Déploiements

La redondance de zone pour les plans Flex Consumption garantit uniquement une durée de fonctionnement continue pour les applications déployées en cours d’exécution.

Lorsqu’une zone tombe en panne, Functions détecte les instances perdues et tente automatiquement de localiser ou de créer des instances de remplacement, selon les besoins, dans les zones disponibles. Pendant la panne zonale, la plateforme tente de restaurer l’équilibre sur les zones disponibles restantes.

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. Toutefois, dans un scénario de zone défaillante, il n’existe aucune garantie que les demandes de plus d’instances aboutissent, 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. Toutefois, il est possible que des comportements non liés à l’exécution puissent quand même ê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é lorsque chaque zone a le même nombre de machines virtuelles dans toutes les autres zones utilisées par le plan Premium, plus ou moins une machine virtuelle.

Reprise d’activité et continuité d’activité entre régions

La reprise après sinistre (DR) fait référence aux pratiques utilisées par les organisations pour se remettre d’événements à fort impact, tels que des catastrophes naturelles ou des déploiements échoués qui entraînent des temps d’arrêt et des pertes de données. Quelle que soit la cause, la meilleure solution pour une catastrophe est un plan de récupération d’urgence bien défini et testé et une conception d’application qui prend activement en charge la récupération d’urgence. Avant de commencer à créer votre plan de reprise après sinistre, consultez Recommandations pour la conception d'une stratégie de reprise après sinistre.

Pour la récupération d’urgence, Microsoft utilise le modèle de responsabilité partagée. Dans ce modèle, Microsoft garantit que l’infrastructure de base et les services de plateforme sont disponibles. Cependant, de nombreux services Azure ne répliquent pas automatiquement les données ou ne reviennent pas 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 instructions pour la prise en charge de la récupération d’urgence. Vous pouvez utiliser des fonctionnalités spécifiques au service pour prendre en charge une récupération rapide afin de vous aider à développer votre plan de reprise après sinistre.

Cette section explique certaines des stratégies que vous pouvez utiliser pour déployer une application de fonction afin de permettre 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

Étant donné qu’aucune redondance intégrée n’est disponible, 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. Vous devriez utiliser un modèle actif-actif en combinaison avec Azure Front Door pour vos fonctions HTTP critiques déclenchées, qui peuvent acheminer et répartir de manière équilibrée les 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.

Architecture autour d’Azure Front Door et de Functions.

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.

Exemple d’architecture actif-passif.

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.

Modèle actif-actif pour les fonctions de déclencheur non HTTPS

Bien que vous soyez encouragé à utiliser le modèle actif-passif pour les fonctions de déclencheur non HTTPS, vous pouvez toujours créer des déploiements actifs-actifs pour les fonctions déclenchées non HTTP. Avant d’implémenter ce modèle, vous devez prendre en compte la façon dont les deux régions actives interagissent ou coordonnent les unes avec les autres et la source du déclencheur.

Par exemple, envisagez d’avoir le même code de fonction, déclenché par Service Bus, déployé dans deux régions, mais se déclenchant sur la même file d’attente de Service Bus. Dans ce cas, les deux fonctions agissent en tant que consommateurs concurrents lors du défilement de la file d’attente unique. Bien que chaque message ne puisse être traité que par l’une des deux instances d’application, cela signifie également qu’il existe toujours un point de défaillance unique, qui est l’instance Service Bus unique. Envisagez d’activer les fonctionnalités de reprise après sinistre géographique et de géoréplication de Service Bus pour vous assurer qu’elle est également résiliente.

Étapes suivantes

  • Last updated on