Partager via

Fiabilité dans l’environnement Azure App Service

App Service Environment est une fonctionnalité Azure App Service qui fournit un environnement entièrement isolé et dédié pour exécuter des applications App Service en toute sécurité à grande échelle. En tant que service Azure, App Service Environment fournit une gamme de fonctionnalités pour prendre en charge vos exigences de fiabilité.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article décrit la prise en charge de la fiabilité dans l’environnement App Service, notamment la résilience aux pannes temporaires, aux défaillances de zone de disponibilité et aux pannes à l’échelle de la région. Il décrit également les stratégies de sauvegarde et la résilience à la maintenance du service, et met en évidence certaines informations clés sur le contrat de niveau de service App Service Environment (SLA).

Remarque

Contrairement à l’offre mutualisée publique App Service qui partage l’infrastructure prenant en charge, un environnement App Service fournit des ressources de calcul dédiées et une isolation réseau améliorée pour un seul client.

Un environnement offre les avantages de fiabilité clés suivants :

  • Ressources de calcul dédiées qui ne sont pas partagées avec d’autres clients
  • Isolation réseau améliorée pour améliorer la sécurité et la stabilité
  • Possibilité de déployer dans votre propre réseau virtuel pour un meilleur contrôle sur le routage du trafic et les stratégies de sécurité

Pour plus d’informations sur la prise en charge de la fiabilité dans App Service, consultez Fiabilité dans App Service.

Recommandations concernant le déploiement de production

Nous vous recommandons d’activer la redondance de zone sur votre environnement et les plans App Service, ce qui nécessite que vos plans utilisent au moins deux instances.

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous implémentez un App Service Environment, vous déployez l’environnement en tant que conteneur pour vos plans App Service et applications web. Pendant l’installation, configurez les paramètres réseau principaux et l’isolation matérielle facultative. Choisissez s’il faut prendre en charge la redondance de zone sur l’environnement si la région prend en charge les zones de disponibilité.

Après avoir créé votre environnement, vous pouvez créer un ou plusieurs plans App Service.

Un plan App Service définit un ensemble de ressources de calcul qui exécutent vos applications web. Toutes les applications web doivent s’exécuter à l’intérieur d’un plan. Vous pouvez mettre à l’échelle un plan pour s’exécuter sur plusieurs instances de machine virtuelle, également appelées Workers. Ces instances fournissent les ressources de calcul qui exécutent le code de votre application. Un seul plan App Service peut héberger plusieurs applications. Toutes les applications s’exécutent sur le même ensemble partagé d’instances de machine virtuelle.

Pour utiliser un environnement App Service, vos plans doivent utiliser le niveau tarifaire v2 isolé. Ce niveau prend en charge la redondance de zone et les applications stratégiques à grande échelle.

App Service fournit les fonctionnalités de redondance suivantes :

  • Distribution entre domaines d’erreur : au niveau de la plateforme, Azure distribue automatiquement les instances de machine virtuelle de votre plan App Service entre les domaines d’erreur au sein de la région Azure. Cette distribution réduit le risque de défaillances matérielles localisées en regroupant les machines virtuelles qui partagent une source d’alimentation commune et un commutateur réseau.

  • Distribution entre les zones de disponibilité : si vous activez la redondance de zone sur un plan App Service pris en charge, Azure distribue vos instances entre les zones de disponibilité au sein de la région. Cette configuration offre une résilience plus élevée si une panne de zone se produit. Pour plus d’informations sur la redondance des zones, consultez Prise en charge des zones de disponibilité.

  • Mise à l’échelle des applications : lorsque vous configurez votre plan App Service pour exécuter plusieurs instances de machine virtuelle, toutes les applications du plan s’exécutent sur toutes les instances par défaut. Si vous configurez votre plan pour la mise à l’échelle automatique, toutes les applications sont mises à l’échelle ensemble en fonction des paramètres de mise à l’échelle automatique. Toutefois, vous pouvez personnaliser le nombre d’instances de plan qui exécutent une application spécifique à l’aide de la mise à l’échelle par application.

  • Unités d’échelle : En interne, App Service s’exécute sur une infrastructure de plateforme appelée unités d’échelle, également appelées tampons ou espaces web. Une unité d’échelle inclut tous les composants nécessaires pour héberger et exécuter App Service, notamment le calcul, le stockage, la mise en réseau et l’équilibrage de charge. Azure gère les unités de mise à l’échelle pour garantir la distribution équilibrée des charges de travail, effectuer une maintenance de routine et maintenir la fiabilité globale de la plateforme.

    Certaines fonctionnalités peuvent uniquement être appliquées à des unités d’échelle spécifiques. Par exemple, certaines unités d’échelle App Service peuvent prendre en charge la redondance de zone, tandis que d’autres unités d’échelle dans la même région ne le font pas.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Les Kits de développement logiciel (SDK) fournis par Microsoft gèrent généralement les fautes temporaires. Étant donné que vous hébergez vos propres applications sur App Service, prenez des mesures pour réduire le risque d’erreurs temporaires :

  • Déployez plusieurs instances dans votre plan. App Service effectue des mises à jour automatisées et d’autres formes de maintenance sur les instances de votre plan. Si une instance devient non saine, le service peut remplacer automatiquement cette instance par une nouvelle instance saine. Pendant le processus de remplacement, il peut y avoir une courte période lorsque l’instance précédente n’est pas disponible et qu’une nouvelle instance n’est pas prête à servir le trafic. Pour atténuer ces effets, déployez plusieurs instances de votre plan App Service.

  • Utilisez des emplacements de déploiement. Les emplacements de déploiement App Service permettent de déployer des déploiements sans temps d’arrêt de vos applications. Utilisez des emplacements de déploiement pour réduire l’effet des déploiements et des modifications de configuration pour vos utilisateurs. Les emplacements de déploiement réduisent également la probabilité que votre application redémarre. Le redémarrage de l’application provoque une erreur temporaire.

  • Évitez d'effectuer une mise à l'échelle vers le haut ou vers le bas. Ces opérations modifient l’UC, la mémoire et d’autres ressources affectées à chaque instance, et peuvent déclencher un redémarrage d’une application. Au lieu de cela, sélectionnez un niveau et une taille d’instance qui répondent à vos besoins en matière de performances en fonction de la charge standard. Pour effectuer un scale-out et un scale-in, ajoutez et supprimez dynamiquement des instances pour gérer les modifications apportées au volume de trafic.

Résilience aux échecs de zone de disponibilité

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

Vous pouvez configurer votre environnement App Service comme redondant interzone. Vous pouvez également configurer vos plans App Service pour qu’ils soient redondants interzones, ce qui les distribue dans plusieurs zones de disponibilité.

Toutefois, vous pouvez activer ou désactiver la redondance de zone sur chaque plan. Cela signifie que vous pouvez avoir certains plans dans votre environnement qui sont redondants interzone, et d’autres qui ne le sont pas.

Lorsque vous créez un plan App Service redondant interzone dans votre environnement, les instances de votre plan App Service sont réparties entre les zones de disponibilité de la région. Pour plus d’informations, consultez Distribution d’instances entre les zones.

Spécifications

Pour activer la redondance de zone pour votre environnement App Service, vous devez répondre aux exigences suivantes :

  • Prise en charge de la région : Pour voir quelles régions prennent en charge les zones de disponibilité pour App Service Environment v3, consultez Régions.

  • Type de plan : Utilisez des types de plan v2 isolés.

  • Nombre minimal d’instances : Déployez au moins deux instances dans votre plan.

  • Unité d’échelle : Votre environnement doit être déployé sur une unité d’échelle qui prend en charge les zones de disponibilité. Vous ne contrôlez pas directement l’unité d’échelle utilisée par votre environnement. Au lieu de cela, lorsque vous créez un environnement App Service, l’environnement est affecté à une unité d’échelle basée sur le groupe de ressources de l’environnement. Pour déterminer si l’unité d’échelle de votre environnement App Service prend en charge la redondance de zone, recherchez la prise en charge de la redondance de zone pour un environnement App Service.

    Si votre environnement est sur une unité d'échelle qui ne prend pas en charge les zones de disponibilité, vous ne pouvez pas activer la redondance des zones sur votre environnement ou vos plans. Au lieu de cela, vous devez créer un environnement dans un nouveau groupe de ressources et redéployer vos applications dans de nouveaux plans au sein de cet environnement.

  • Configuration requise : Configurez votre environnement App Service et vos plans pour prendre en charge la redondance de zone. Vous pouvez activer la redondance de zone pendant la création de l’environnement ou en mettant à jour un environnement existant.

Distribution d’instances entre zones

Lorsque vous créez un plan App Service redondant interzone, Azure distribue les instances du plan entre les zones de disponibilité de la région. Cette distribution garantit que vos applications restent disponibles même si une zone subit une panne.

La distribution d’instances dans un déploiement redondant interzone suit des règles spécifiques. Ces règles s’appliquent également au fur et à mesure que l’application est mise à l’échelle :

  • Instances minimales : Votre plan App Service doit avoir au moins deux instances pour la redondance de zone.

  • Zones de disponibilité maximale prises en charge par votre plan : Azure détermine le nombre de zones de disponibilité que votre plan peut utiliser, ce qui est appelé maximumNumberOfZones. Pour afficher le nombre de zones de disponibilité que votre plan spécifique peut utiliser, consultez Vérifier la prise en charge de la redondance de zone pour un plan App Service.

  • Distribution d’instances : lorsque la redondance de zone est activée, Azure distribue automatiquement les instances de plan entre plusieurs zones de disponibilité. La distribution est basée sur les règles suivantes :

    • Si le nombre d’instances dépasse maximumNumberOfZones et divise uniformément, Azure distribue les instances uniformément entre les zones.

    • Si le nombre d’instances ne se divise pas uniformément, Azure distribue les instances restantes entre les zones restantes.

    • Lorsque la plateforme App Service alloue des instances à un plan App Service redondant interzone, elle utilise le meilleur équilibrage de zone possible qu’offre les groupes de machines virtuelles identiques Azure. Un plan est équilibré si chaque zone a le même nombre de machines virtuelles ou diffère d’une instance de toutes les autres zones. Pour découvrir plus d’informations, consultez Équilibrage de zone.

  • Positionnement de zone physique : Vous pouvez afficher la zone de disponibilité physique utilisée pour chacune de vos instances de plan App Service. Pour plus d’informations, consultez Afficher les zones physiques d’un plan App Service.

Considérations

Une panne de zone de disponibilité peut affecter certains aspects d’App Service, même si l’application continue de traiter le trafic. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

Lorsque vous activez la redondance de zone sur votre plan App Service, vous améliorez également la résilience pendant les mises à jour de la plateforme. Pour plus d’informations, consultez Résilience à la maintenance du service.

Pour les plans App Service qui ne sont pas redondants au niveau des zones, les instances VM sous-jacentes ne sont pas résilientes aux pannes des zones de disponibilité. Elles peuvent rencontrer des temps d’arrêt pendant une panne dans n’importe quelle zone de cette région.

Coûts

Vous pouvez activer la redondance de zone sur un environnement App Service ou ses plans sans frais supplémentaires. Toutefois, la redondance de zone pour un plan nécessite la présence d’au moins deux instances. Vous êtes facturé en fonction de la référence SKU de votre plan App Service, de la capacité que vous spécifiez et de toutes les instances auxquelles vous effectuez une mise à l’échelle en fonction de vos critères de mise à l’échelle automatique.

Si vous activez des zones de disponibilité, mais spécifiez une capacité de moins de deux instances, la plateforme applique une instance minimale de deux. La plateforme vous facture pour ces deux instances.

Important

Lorsque vous activez des zones de disponibilité pour un environnement App Service, tous les plans App Service avec moins de 3 instances sont mis à l’échelle à 3 instances. Tout plan avec 3 instances ou plus reste inchangé. Une fois l’opération d’activation des zones de disponibilité terminée, vous pouvez mettre à l’échelle vos plans App Service en fonction des besoins, y compris à moins de 3 instances.

Configurez la prise en charge des zones de disponibilité

Pour savoir comment créer, activer ou désactiver un nouvel environnement App Service redondant interzone et de nouveaux plans App Service redondants interzone, consultez Configurer des environnements App Service et des plans App Service isolés v2 pour la redondance de zone.

Remarque

Une modification de l’état de redondance de zone d’un environnement App Service prend 12 à 24 heures. Pendant le processus de mise à niveau, aucun temps d’arrêt ni aucun problème de performances ne se produit.

Planification de capacité et gestion

Pour vous préparer à une défaillance de zone de disponibilité, envisagez de surprovisionner la capacité de votre plan App Service. Cette approche permet à la solution de tolérer une perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité à l’aide du surapprovisionnement.

Comportement lorsque toutes les zones sont saines

La liste suivante décrit ce qui doit être attendu lorsque les plans App Service sont configurés pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles :

  • Acheminement de trafic entre zones : pendant les opérations normales, le trafic est acheminé entre toutes vos instances de plan App Service disponibles dans toutes les zones de disponibilité.

  • Réplication des données entre les zones : Pendant les opérations normales, tout état stocké dans le système de fichiers de votre application est stocké dans un stockage redondant interzone et répliqué de manière synchrone entre les zones de disponibilité.

Comportement lors d’une défaillance de zone

Une panne de zone de disponibilité peut affecter certains aspects d’App Service, même si l’application continue de traiter le trafic. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

La liste suivante décrit ce qui doit être attendu lorsque les plans App Service sont configurés pour la redondance de zone et qu’une ou plusieurs zones de disponibilité ne sont pas disponibles :

  • Détection et réponse : La plateforme App Service détecte automatiquement les défaillances dans une zone de disponibilité et lance une réponse. Aucune intervention manuelle n’est nécessaire pour lancer un basculement de zone.

  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois:

  • Demandes actives : toutes les demandes en cours qui se connectent à une instance de plan App Service dans la zone de disponibilité défectueuse sont arrêtées. Réessayez ces requêtes.

  • Réacheminement du trafic : App Service détecte les instances perdues de cette zone et tente de trouver de nouvelles instances de remplacement. Une fois qu’App Service a trouvé des remplacements, il distribue le trafic entre les nouvelles instances en fonction des besoins.

    Si la mise à l’échelle automatique est configurée et détermine que d’autres instances sont nécessaires, elle demande des instances à partir d’App Service. Le comportement de mise à l'échelle automatique fonctionne indépendamment du comportement de la plateforme App Service. Ainsi, le nombre d'instances spécifié ne doit pas nécessairement être un multiple de deux. Pour plus d’informations, consultez Mise à l’échelle d’une application dans App Service et vue d’ensemble de la mise à l’échelle automatique.

    Important

    Azure ne garantit pas que les demandes d'instances supplémentaires aboutissent en cas de panne de zone. La plateforme tente de restaurer les instances perdues dans la mesure du possible. Si vous avez besoin d’une capacité garantie lors d’une défaillance de zone de disponibilité, créez et configurez vos plans App Service pour tenir compte de la perte de zone en surprovisionnant la capacité.

  • Comportements non-runtime : les applications d’un plan App Service redondant interzone continuent à s’exécuter et à traiter le trafic même si une zone de disponibilité subit une panne. Toutefois, il est possible que les comportements hors runtime soient toujours affectés pendant une panne de zone de disponibilité. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

Récupération de la zone

Lorsque la zone de disponibilité récupère, App Service crée automatiquement des instances dans la zone de disponibilité récupérée, supprime toutes les instances temporaires créées dans les autres zones de disponibilité et route le trafic entre vos instances comme d’habitude.

Tester les pannes de zone

La plateforme Azure App Service gère le routage du trafic, le basculement et la restauration automatique pour les plans App Service redondants interzone. Cette fonctionnalité est entièrement gérée. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

App Service est un service à région unique. Si la région devient indisponible, votre environnement et ses plans et applications deviennent également indisponibles.

Solutions multirégions personnalisées pour la résilience

Pour réduire le risque d’une défaillance à une seule région affectant votre application, déployez plusieurs environnements App Service dans plusieurs régions. Les étapes suivantes aident à renforcer la résilience :

  • Déployez votre application dans les environnements App Service dans chaque région.
  • Configurez les stratégies d’équilibrage de charge et de basculement.
  • Répliquez vos données entre les régions afin de pouvoir récupérer votre dernier état d’application.

Pour obtenir un exemple d’approche illustrant cette architecture, consultez le déploiement d’entreprise haute disponibilité à l’aide d’App Service Environment.

Sauvegarde et restauration

Pour sauvegarder vos applications App Service dans un fichier, utilisez les fonctionnalités de sauvegarde et de restauration App Service.

Ces fonctionnalités vous aident quand il est difficile de redéployer du code ou lorsque vous stockez l’état sur le disque. La plupart des solutions ne doivent pas s’appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités de ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas.

Important

À compter du 31 mars 2028, les sauvegardes personnalisées Azure App Service ne prennent plus en charge la sauvegarde des bases de données liées. Pour plus d’informations, consultez Dépréciation des sauvegardes de base de données liées .

Utilisez plutôt les outils de sauvegarde et de restauration natifs de votre base de données liée. Pour plus d’informations, consultez Sauvegarder et restaurer votre application dans App Service.

Résilience à la maintenance du service

App Service effectue des mises à niveau de service régulières et d’autres tâches de maintenance. Pour maintenir votre capacité attendue pendant une mise à niveau, la plateforme ajoute automatiquement des instances supplémentaires du plan App Service pendant le processus de mise à niveau.

Activer la redondance de zone. Lorsque vous activez la redondance de zone sur votre plan App Service, vous améliorez également la résilience pendant les mises à jour de la plateforme. Les domaines de mise à jour sont constitués de collections de machines virtuelles qui sont hors connexion pendant une mise à jour et qui sont mappées aux zones de disponibilité. Le déploiement de plusieurs instances dans votre plan App Service et l’activation de la redondance de zone pour votre plan ajoute une couche supplémentaire de résilience si une instance ou une zone devient défectueuse pendant une mise à niveau.

Personnalisez le cycle de mise à niveau. Vous pouvez personnaliser le cycle de mise à niveau d’un environnement App Service. Si vous devez valider l’effet des mises à niveau sur votre charge de travail, activez les mises à niveau manuelles. Cette approche vous permet d’effectuer la validation et le test sur une instance hors production avant de les appliquer à votre instance de production.

Pour plus d’informations sur les préférences de maintenance, consultez Préférences de mise à niveau pour la maintenance planifiée d’App Service Environment.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit remplir pour atteindre cette disponibilité attendue. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Lorsque vous déployez un plan App Service redondant entre zones, le pourcentage de temps d’activité défini dans le SLA augmente.

Contenu connexe

  • Last updated on