Fiabilité dans Azure App Service
Cet article décrit la prise en charge de la fiabilité dans Azure App Service et couvre la résilience intra-régionale avec les zones de disponibilité et la reprise d’activité de récupération d'urgence 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.
Azure App Service est un service HTTP pour l’hébergement d’applications web, d’API REST et de back-ends mobiles. Il ajoute la puissance de Microsoft Azure à votre application, par exemple :
- Sécurité
- Équilibrage de la charge
- Mise à l’échelle automatique
- Gestion automatisée
Pour découvrir comment Azure App Service peut renforcer la fiabilité et la résilience de votre charge de travail d’application, consultez Pourquoi utiliser App Service ?
Recommandations en matière de fiabilité
Cette section contient des recommandations pour atteindre la résilience et la disponibilité. Chaque recommandation appartient à l’une des deux catégories suivantes :
Les éléments d’intégrité couvrent des domaines tels que les éléments de configuration et le bon fonctionnement des principaux composants de votre charge de travail Azure, tels que les paramètres de configuration des ressources Azure, les dépendances vis-à-vis d’autres services, etc.
Les éléments de risque couvrent des domaines tels que les exigences de disponibilité et de reprise d’activité, les tests, le monitoring, le déploiement et d’autres éléments qui, s’ils ne sont pas résolus, augmentent les risques de problèmes dans l’environnement.
Matrice de priorité des recommandations de fiabilité
Chaque recommandation est marquée conformément à la matrice de priorité suivante :
| Image | Priority | Description |
|---|---|---|
|
Élevé | Correctif immédiat nécessaire. |
|
Moyenne | Corriger dans les 3 à 6 mois. |
|
Faible | Doit être examiné. |
Résumé des recommandations en matière de fiabilité
Haute disponibilité
ASP-1 - Déployez des plans App Service redondants interzones
Pour améliorer la résilience et la fiabilité de vos charges de travail vitales pour l'entreprise, il est recommandé de déployer vos nouveaux plans App Service avec une redondance interzone. Suivez les étapes de redéploiement vers la prise en charge des zones de disponibilité, configurez vos pipelines pour redéployer votre application web sur le nouveau plan App Services, puis utilisez une approche de déploiement bleu-vert pour basculer vers le nouveau site.
En répartissant vos applications entre plusieurs zones de disponibilité, vous pouvez garantir leur fonctionnement continu, même en cas de défaillance au niveau du centre de données. Si vous souhaitez en savoir plus sur la prise en charge des zones de disponibilité dans Azure App Service, veuillez consulter la rubrique Prise en charge des zones de disponibilité.
// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A
resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"
Résilience
ASP-2 - Utilisez un plan App Service qui prend en charge les zones de disponibilité
La prise en charge des zones de disponibilité n’est disponible que sur certains plans App Service. Pour connaître le plan dont vous avez besoin pour utiliser les zones de disponibilité, veuillez consulter la rubrique Conditions préalables relatives aux zones de disponibilité.
// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.
resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
tolower(sku_tier) !contains "premium" and
tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)
ASP-4 - Créez des plans App Service distincts pour la production et le test
Pour améliorer la résilience et la fiabilité de vos charges de travail vitales pour l’entreprise, vous devez migrer vos plans App Service existants et vos environnements App Service Environment vers la prise en charge des zones de disponibilité. En répartissant vos applications entre plusieurs zones de disponibilité, vous pouvez garantir leur fonctionnement continu, même en cas de défaillance au niveau du centre de données. Si vous souhaitez en savoir plus sur la prise en charge des zones de disponibilité dans Azure App Service, veuillez consulter la rubrique Prise en charge des zones de disponibilité.
Extensibilité
ASP-3 - Évitez les scale-ups ou les scale-downs fréquents
Nous vous recommandons d’éviter les scale-ups ou les scale-downs fréquents sur vos instances Azure App Service. Au lieu de cela, choisissez un niveau et une taille d’instance appropriés qui peuvent gérer votre charge de travail classique, puis effectuez un scale-out des instances pour prendre en charge les modifications du volume de trafic. Le scale-up ou le scale-down peut potentiellement déclencher un redémarrage d’application, ce qui peut entraîner des interruptions de service.
ASP-5 - Activez la mise à l’échelle automatique/le scale-in et le scale-out automatiques pour garantir que les ressources appropriées sont disponibles pour les demandes de service
Nous vous recommandons d’activer la mise à l’échelle automatique/le scale-in et le scale-out automatiques pour votre Azure App Service pour garantir la disponibilité de ressources suffisantes pour gérer les demandes entrantes. La mise à l’échelle automatique est une mise à l’échelle basée sur des règles, tandis que le scale-in et le scale-out automatiques s’effectuent en fonction du trafic HTTP. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Mise à l’échelle automatique dans Azure App Service ou Bien démarrer avec la mise à l’échelle automatique dans Azure.
// under-development
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 App Service peut être déployé à travers des zones de disponibilité pour vous aider à assurer la résilience et la fiabilité de vos charges de travail vitales pour l’entreprise. Cette architecture est également appelée « redondance de zone ».
Lorsque vous configurez App Service comme redondant interzone, la plateforme répartit automatiquement les instances du plan Azure App Service sur 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 minimal d’instances du plan App Service est de trois.
- Si vous spécifiez une capacité supérieure à trois et que le nombre d’instances est divisible par trois, les instances sont réparties de manière égale.
- Toutes les instances au-delà de 3*N sont réparties sur les zones restantes d’une ou deux zones.
La prise en charge des zones de disponibilité est une propriété du plan App Service. Les plans App Service peuvent être créés sur un environnement multilocataire managé ou un environnement dédié à l’aide de App Service Environment v3. Pour en savoir plus sur App Service Environment v3, consultez Vue d’ensemble de App Service Environment v3.
Pour les services App Services qui ne sont pas configurés pour être redondants interzone, les instances de machine virtuelle ne sont pas résilientes aux zones et peuvent subir un temps d’arrêt lors d’une interruption dans n’importe quelle zone de cette région.
Si vous souhaitez en savoir plus sur l’architecture de déploiement d’entreprise, veuillez consulter la rubrique Déploiement d’entreprise haute disponibilité avec App Service Environment.
Prérequis
Les exigences/limitations actuelles de l’activation des zones de disponibilité sont les suivantes :
Windows et Linux sont tous les deux pris en charge.
Les zones de disponibilité ne sont prises en charge que sur l’empreinte App Service la plus récente. Même si vous utilisez l’une des régions prises en charge, vous recevrez une erreur si les zones de disponibilité ne sont pas prises en charge pour votre groupe de ressources. Pour vous assurer que vos charges de travail atterrissent sur un tampon qui prend en charge les zones de disponibilité, vous devrez peut-être créer un groupe de ressources, un plan App Service et App Service.
Votre plan App Services doit être l’un des plans suivants qui prennent en charge les zones de disponibilité :
- Dans un environnement multilocataire utilisant des plans App Service Premium v2 ou Premium v3.
- Dans un environnement dédié utilisant la fonctionnalité App Service Environment v3 qui est utilisée avec les plans App Service Isolés v2.
Pour des environnements dédiés, la version de votre App Service Environment doit être v3.
Important
Les versions v2 et v1 d’App Service Environment seront mises hors service le 31 août 2024. La version v3 d’App Service Environment est plus facile à utiliser et s’exécute sur des infrastructures plus puissantes. Pour en savoir plus sur la version v3 d’App Service Environment, consultez Vue d’ensemble d’App Service Environment. Si vous utilisez actuellement la version v2 ou v1 d’App Service Environment et que vous souhaitez migrer vers la version v3, suivez les étapes indiquées dans cet article pour migrer vers la nouvelle version.
Un nombre minimal d’instances de trois zones est appliqué. La plateforme appliquera ce nombre minimal en coulisses si vous spécifiez un nombre d’instances inférieur à trois.
Les zones de disponibilité ne peuvent être spécifiées que lors de la création d’un nouveau plan App Service. Un plan App Service pré-existant ne peut pas être converti pour utiliser des zones de disponibilité.
Les régions suivantes prennent en charge Azure App Services s’exécutant sur des environnements à plusieurs locataires :
- Australie Est
- Brésil Sud
- Centre du Canada
- Inde centrale
- USA Centre
- Asie Est
- USA Est
- USA Est 2
- France Centre
- Allemagne Centre-Ouest
- Japon Est
- Centre de la Corée
- Europe Nord
- Norvège Est
- Pologne Centre
- Qatar Central
- Afrique du Sud Nord
- États-Unis - partie centrale méridionale
- Asie Sud-Est
- Suède Centre
- Suisse Nord
- Émirats arabes unis Nord
- Sud du Royaume-Uni
- Europe Ouest
- USA Ouest 2
- USA Ouest 3
- Microsoft Azure exploité par 21Vianet – Chine Nord 3
- Azure Government – US Gov Virginie
Pour savoir quelles régions prennent en charge les zones de disponibilité pour App Service Environment v3, consultez Régions.
Créer une ressource avec la zone de disponibilité activée
Pour déployer un service App Service redondant interzone multi-locataire
Pour activer les zones de disponibilité à l’aide d’Azure CLI, incluez le paramètre --zone-redundant lorsque vous créez votre plan App Service. Vous pouvez également inclure le paramètre --number-of-workers pour spécifier la capacité. Si vous ne spécifiez pas de capacité, la capacité par défaut de la plateforme est trois. La capacité doit être basée sur l’exigence de charge de travail, mais ne doit pas être inférieure à trois. Une bonne règle de base pour choisir la capacité consiste à veiller à ce que les instances soient en nombre suffisant pour l’application, de telle sorte que la perte d’une zone d’instances laisse une capacité suffisante pour gérer la charge attendue.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Conseil
Pour déterminer la capacité d’instance, vous pouvez utiliser le calcul suivant :
Étant donné que la plateforme répartit les machines virtuelles dans trois zones et que vous devez prendre en compte au moins la défaillance d’une zone, multipliez le nombre d’instances nécessaires pour un pic de charge de travail par un facteur de zones/(zones-1), soit 3/2. Par exemple, si votre pic de charge de travail typique nécessite quatre instances, vous devez en approvisionner six : (2/3 * 6 instances) = 4 instances.
Déployer un App Service redondant interzone à l’aide d’un environnement dédié
Pour découvrir comment créer une version v3 de App Service Environment sur le plan v2 isolé, consultez Créer un environnement App Service Environment.
Résolution des problèmes
| Message d’erreur | Description | Recommandation |
|---|---|---|
| La redondance de zone n’est pas disponible pour le groupe de ressources « RG-NAME ». Déployez le plan App Service « ASP-NAME » dans un nouveau groupe de ressources. | Les zones de disponibilité ne sont prises en charge que sur l’empreinte App Service la plus récente. Même si vous utilisez l’une des régions prises en charge, vous recevrez une erreur si les zones de disponibilité ne sont pas prises en charge pour votre groupe de ressources. | Pour vous assurer que vos charges de travail atterrissent sur un tampon qui prend en charge les zones de disponibilité, créez un groupe de ressources, un plan App Service et App Service. |
Tolérance de panne
Pour vous préparer à une défaillance de la zone de disponibilité, vous devez surdimensionner la capacité de service pour veiller à ce que la solution puisse tolérer une perte de capacité d’un tiers et continue à fonctionner sans dégradation des performances pendant les pannes à l’échelle de la zone. Étant donné que la plateforme répartit les machines virtuelles dans trois zones et que vous devez prendre en compte au moins la défaillance d’une zone, multipliez le nombre d’instances nécessaires pour un pic de charge de travail par un facteur de zones/(zones-1), soit 3/2. Par exemple, si votre pic de charge de travail typique nécessite quatre instances, vous devez en approvisionner six : (2/3 * 6 instances) = 4 instances.
Expérience en cas de panne de zone
Le trafic est acheminé vers toutes les instances App Service disponibles. En cas de défaillance d’une zone, la plateforme App Service détecte les instances perdues et tente automatiquement de trouver de nouvelles instances de remplacement et de répartir le trafic en fonction des besoins. Si vous avez configuré la mise à l’échelle automatique et qu’elle décide que davantage d’instances sont nécessaires, la mise à l’échelle automatique envoie également une demande à App Service pour ajouter des instances supplémentaires. Notez que le comportement de la mise à l’échelle automatique est indépendant du comportement de la plateforme App Service et que la spécification du nombre d’instances de mise à l’échelle automatique n’a pas besoin d’être un multiple de trois.
Notes
Il n’est pas garanti que les requêtes d’instances supplémentaires dans un scénario de zone descendante réussissent. Le remplissage arrière des instances perdues survient sur une base du meilleur effort. La solution recommandée consiste à créer et configurer vos plans App Service pour tenir compte de la perte d’une zone, comme décrit dans la section suivante.
Les applications déployées dans un plan App Service pour lequel les zones de disponibilité sont activées continueront à s’exécuter et à traiter le trafic même si d’autres zones dans la même région subissent une interruption. Cependant, il se peut que des comportements hors runtime, dont la mise à l’échelle de plan App Service, la création d’application, la configuration d’application et la publication d’application soient affectés par une interruption dans d’autres zones de disponibilité. La redondance de zone pour les plans App Service garantit uniquement un temps d’activité continu des applications déployées.
Lorsque la plateforme App Service alloue des instances à un plan App Service redondant dans une zone, elle utilise le meilleur équilibrage de zone possible qu’offre les groupes de machines virtuelles identiques Azure. Un plan App Service est « équilibré » si chaque zone compte le même nombre de machines virtuelles, ou +/- une machine virtuelle dans toutes les autres zones que le plan App Service utilise.
Migration de zones de disponibilité
Vous ne pouvez pas migrer des instances App Service existantes ou des ressources d’environnement de la non-prise en charge des zones de disponibilité vers la prise en charge des zones de disponibilité. Pour bénéficier de la prise en charge des zones de disponibilité, vous devez créer vos ressources avec les zones de disponibilité activées.
Tarifs
Aucun coût supplémentaire n’est associé à l’activation des zones de disponibilité. La tarification d’un plan App Service redondant interzone est identique à celle d’un seul plan App Service. Vous serez facturé en fonction de la référence SKU de votre plan App Service, 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, la plateforme appliquera un nombre d’instances minimal de trois et vous facturera l’utilisation de ces trois instances. Pour obtenir des informations de tarification pour App Service Environment v3, consultez Tarification.
Reprise d’activité de récupération d'urgence inter-régions et continuité d’activité
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 décrit certaines stratégies courantes pour les applications web déployées sur App Service.
Par exemple, quand vous créez une application web dans App Service et que vous choisissez une région Azure lors de la création des ressources, il s’agit d’une application à région unique. Quand la région devient indisponible lors d’un sinistre, votre application le devient également. Si vous créez un déploiement identique dans une région Azure secondaire à l’aide d’une architecture géographique multi-région, votre application devient moins vulnérable à une urgence d’une seule région, ce qui garantit la continuité de l’activité. Toute réplication de données entre les régions vous permet de récupérer votre dernier état d’application.
Pour le service informatique, les plans de continuité d’activité sont largement pilotés par l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO). Pour plus d’informations sur le RTO et le RPO, consultez les objectifs de récupération.
Normalement, le maintien d’un contrat de niveau de service (SLA) portant sur l’objectif RTO n’est pas pratique pour les sinistres au niveau régional. Vous concevez généralement votre stratégie de récupération d’urgence uniquement autour de l’objectif RPO (c’est-à-dire, vous vous concentrez sur la récupération des données au lieu de la réduction des interruptions). Avec Azure, toutefois, il n’est pas seulement pratique, mais peut même être simple de déployer App Service pour les géo-basculements automatiques. En effet, il permet de renforcer la protection contre les sinistres de vos applications en prenant en charge les objectifs RTO et RPO.
Selon vos métriques RTO et RPO souhaitées, trois architectures de récupération d’urgence sont couramment utilisées pour les environnements App Service mutualisés et App Service. Chaque architecture est décrite dans le tableau suivant :
| Métrique | Active-Active | Actif-passif | Passif/Froid |
|---|---|---|---|
| RTO | Temps réel ou secondes | Minutes | Heures |
| RPO | Temps réel ou secondes | Minutes | Heures |
| Coût | $$$ | $$ | $ |
| Scénarios | Applications stratégiques | Applications de haute priorité | Applications de faible priorité |
| Capacité à traiter le trafic utilisateur multirégion | Oui | Oui/peut-être | Non |
| Déploiement de code | Pipelines CI/CD préférés | Pipelines CI/CD préférés | Sauvegarde et restauration |
| Création de ressources App Service pendant les temps d’arrêt | Non requis | Non requis | Requis |
Remarque
Votre application dépend probablement d’autres services de données dans Azure, tels que Azure SQL Database et les comptes de stockage Azure. Nous vous recommandons également de développer des stratégies de récupération d’urgence pour chacun de ces services Azure dépendants. Pour SQL Database, consultez l’article Géoréplication active pour Azure SQL Database. Pour Stockage Azure, consultez l’article Redondance de Stockage Azure.
Récupération d’urgence dans la zone géographique multi-région
Il existe plusieurs façons de répliquer le contenu et les configurations de vos applications web dans les régions Azure dans une architecture de type actif/actif ou actif/passif, par exemple en utilisant la sauvegarde et la restauration App Service. Toutefois, la sauvegarde et la restauration créent des instantanés à un point dans le temps et entraînent finalement des problèmes de contrôle de version d’application web dans différentes régions. Consultez le tableau suivant ci-dessous pour obtenir une comparaison entre les instructions de restauration et de retour et les instructions de récupération d’urgence :
Sauvegarder et restaurer par rapport à la récupération d’urgence
| Plate-forme | Conseils de sauvegarde et de restauration | Guide de récupération d’urgence |
|---|---|---|
| App Service Web Apps (Niveau tarifaire gratuit et partagé) |
Si vous avez déployé des applications web dans le niveau Gratuit ou Partagé et que vous avez besoin d’accéder aux fonctionnalités de sauvegarde et de restauration pour ces applications web, effectuez un scale-up vers le niveau De base ou supérieur. | Remettez en ligne les ressources App Service dans une autre région Azure lors d’un sinistre régional. À compter du 31 mars 2025, les applications App Service ne passeront plus en mode de récupération d'urgence lors d’un sinistre dans une région Azure, comme l’explique l’article Reprendre l’activité après une défaillance à l’échelle d’une région. Il est recommandé de mettre en œuvre des techniques de récupération d'urgence courantes pour éviter les temps d’arrêt et les pertes de données à lors d’un sinistre régional. |
| App Service Web Apps (Niveau tarifaire De base\Standard\Premium) |
Dans Azure App Service, vous pouvez effectuer des sauvegardes personnalisées à la demande ou utiliser des sauvegardes automatiques. Vous pouvez restaurer une sauvegarde en remplaçant une application existante en restaurant dans une nouvelle application ou un nouvel emplacement. Pour plus d’informations, consultez Sauvegarder et restaurer votre application dans Azure App Service. |
Les recommandations actuelles concernant la remise en ligne des ressources App Service dans une autre région Azure lors d’un sinistre régional sont disponibles dans Reprendre l’activité après une défaillance à l’échelle d’une région – Azure App Service. À compter du 31 mars 2025, les applications web Azure App Service ne passeront plus en mode de reprise d’activité lors d’un sinistre dans une région Azure, comme l’explique l’article Reprendre l’activité après une défaillance à l’échelle d’une région. Nous vous encourageons à mettre en œuvre des techniques de récupération d'urgence courantes pour éviter une perte de fonctionnalités ou de données pour vos applications web en cas de sinistre régional. |
| App Service Environment (V2 &V3) | Dans Azure App Service Environment, vous pouvez effectuer des sauvegardes personnalisées à la demande ou utiliser des sauvegardes automatiques. Les sauvegardes automatiques peuvent être restaurées dans une application cible au sein du même ASE, et non dans un autre ASE. Les sauvegardes personnalisées peuvent être restaurées dans une application cible au sein d’un autre ASE (par exemple, d’un ASE V2 vers un ASE V3). Les sauvegardes peuvent être restaurées dans une application cible de la même plateforme de système d’exploitation que l’application source. Pour plus d’informations, consultez Sauvegarder et restaurer votre application dans Azure App Service. |
Nous vous encourageons à mettre en œuvre les recommandations de récupération d'urgence qui s’appliquent aux applications web déployées dans App Service Environment en utilisant les techniques de récupération d'urgence courantes. |
| Azure Functions (dédié) | Dans Azure Functions, vous pouvez effectuer des sauvegardes personnalisées à la demande ou utiliser des sauvegardes automatiques. Vous pouvez restaurer une sauvegarde en remplaçant une application existante en restaurant dans une nouvelle application ou un nouvel emplacement. Pour plus d’informations, consultez Sauvegarder et restaurer votre application dans Azure App Service. |
Les recommandations actuelles concernant la remise en ligne des ressources (dédiées) d’application Azure Functions dans une autre région Azure lors d’un sinistre régional sont disponibles dans Récupérer après une défaillance à l’échelle de la région – Azure App Service. À compter du 31 mars 2025, les applications App Service ne passeront plus en mode de récupération d'urgence lors d’un sinistre dans une région Azure, comme l’explique l’article Reprendre l’activité après une défaillance à l’échelle d’une région. Implémentez plutôt la géo-reprise d’activité après sinistre Azure Functions. Par ailleurs, vous pouvez aussi vous reporter aux techniques de récupération d'urgence courantes pour Azure Functions (dédié). |
| Consommation d’Azure Functions & Premium | Les fonctions Azure déployées dans les plans Consommation et Premium ne donnent pas accès aux sauvegardes personnalisées et automatiques. Le contenu d’une application de fonction se trouve dans un compte de stockage Azure. Utilisez les options de redondance de Stockage Azure pour vous assurer que votre compte de stockage répond à ses objectifs en termes de disponibilité et de durabilité à l’occasion d’une panne. Si vous avez créé vos fonctions à l’aide de l’éditeur du portail Azure, vous pouvez également télécharger votre projet d’application de fonction sous la forme d’un fichier .zip. |
Nous vous encourageons vivement à implémenter la géo-reprise d’activité après sinistre et la fiabilité Azure Functions. |
Pour éviter les limitations des méthodes de sauvegarde et de restauration, configurez vos pipelines CI/CD pour déployer du code dans les deux régions Azure. Envisagez d’utiliser Azure Pipelines ou GitHub Actions. Pour plus d’informations, consultez Déploiement continu sur Azure App Service.
Détection, notification et gestion des pannes
Il est recommandé de configurer la surveillance et les alertes pour vos applications web afin de recevoir des notifications en temps voulu lors d’une urgence. Pour plus d’informations, consultez l’article Tests de disponibilité d’Application Insights.
Pour gérer vos ressources d’application dans Azure, utilisez un mécanisme IaC (Infrastructure-as-Code). Dans un déploiement complexe sur plusieurs régions, gérer les régions de manière indépendante et maintenir la configuration synchronisée d’une région à l’autre de manière fiable nécessite un processus prévisible pouvant être testé et reproduit. Envisagez d’utiliser un outil IaC tel que des modèles Azure Resource Manager ou Terraform.
Configurer la reprise d’activité et la détection des pannes
Pour vous préparer à la récupération d’urgence dans une zone géographique multi-région, vous pouvez utiliser une architecture active-active ou active-passive.
Architecture actif/actif
Dans l’architecture de récupération d’urgence active-active, les applications web identiques sont déployées dans deux régions distinctes et Azure Front door est utilisée pour acheminer le trafic vers les deux régions actives.
Dans cet exemple d’architecture :
- Les applications App Service identiques sont déployées dans deux régions distinctes, y compris le niveau tarifaire et le nombre d’instances.
- Le trafic public direct vers les applications App Service est bloqué.
- Azure Front Door est utilisé pour acheminer le trafic vers les deux régions actives.
- En cas de sinistre, l’une des régions devient hors connexion et Azure Front Door achemine le trafic exclusivement vers la région qui reste en ligne. Pendant un tel géobasculement, l’objectif RTO est proche de zéro.
- Les fichiers d’application doivent être déployés sur les deux applications web avec une solution CI/CD. Cela garantit que l’objectif RPO est pratiquement égal à zéro.
- Si votre application modifie activement le système de fichiers, la meilleure façon de réduire le RPO consiste à écrire uniquement dans un partage Stockage Azure monté au lieu d’écrire directement dans le partage de contenu /home de l’application web. Ensuite, utilisez les fonctionnalités de redondance du service Stockage Azure (GZRS ou GRS) pour votre partage monté, qui a un objectif RPO d’environ 15 minutes.
Voici un résumé des étapes à suivre pour créer une architecture de type actif/actif pour votre application web dans App Service :
Créez deux plans App Service dans deux régions Azure différentes. Configurez les deux plans App Service de manière identique.
Créez deux instances de votre application web, une dans chaque plan App Service.
Créez un profil Azure Front Door avec :
- Point de terminaison.
- Deux groupes d’origines, chacun avec une priorité de 1. La priorité égale indique à Azure Front Door d’acheminer le trafic vers les deux régions de manière égale (donc actif/actif).
- Un itinéraire.
Limitez le trafic réseau aux applications web uniquement à partir de l’instance Azure Front Door.
Installez et configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.
Déployez du code sur les applications web à l’aide d’un déploiement continu.
L’article Tutoriel : Créer une application multirégion hautement disponible dans Azure App Service vous explique comment configurer une architecture de type actif/passif. Avec quelques modifications (en définissant la priorité sur « 1 » pour les deux origines dans le groupe d’origines dans Azure Front Door), les mêmes étapes permettent d’obtenir une architecture de type actif/actif.
Architecture actif/passif
Dans cette approche de récupération d’urgence, des applications web identiques sont déployées dans deux régions distinctes et Azure Front Door est utilisé pour acheminer le trafic vers une seule région (la région active).
Dans cet exemple d’architecture :
Les applications App Service identiques sont déployées dans deux régions distinctes.
Le trafic public direct vers les applications App Service est bloqué.
Azure Front Door est utilisé pour acheminer le trafic vers la région primaire.
Pour réduire les coûts, le plan App Service secondaire est configuré pour diminuer le nombre d’instances et/ou s’appliquer à un niveau tarifaire inférieur. Il existe trois approches possibles :
Approche privilégiée Le plan App Service secondaire a le même niveau tarifaire que le plan principal, avec le même nombre d’instances, voire moins. Cette approche garantit la parité dans le dimensionnement des fonctionnalités et des machines virtuelles pour les deux plans App Service. L’objectif RTO pendant un géobasculement dépend uniquement du temps nécessaire pour effectuer un scale-out des instances.
Approche moins privilégiée Le plan App Service secondaire a le même type de niveau tarifaire (par exemple, PremiumV3), mais un dimensionnement de machines virtuelles plus petit, avec un nombre réduit d’instances. Par exemple, la région primaire peut se trouver au niveau P3V3 et la région secondaire au niveau P1V3. Cette approche garantit toujours la parité des fonctionnalités pour les deux plans App Service, mais l’absence de parité de taille peut nécessiter un scale-up manuel quand la région secondaire devient la région active. L’objectif RTO pendant un géobasculement dépend du temps nécessaire pour effectuer un scale-up et un scale-out des instances.
Approche la moins privilégiée Le plan App Service secondaire a un autre niveau tarifaire que celui du plan principal et un nombre réduit d’instances. Par exemple, la région primaire peut se trouver au niveau P3V3 et la région secondaire au niveau S1. Assurez-vous que le plan App Service secondaire dispose de toutes les fonctionnalités dont votre application a besoin pour s’exécuter. Les différences de disponibilité des fonctionnalités entre les deux plans peuvent entraîner des retards dans la récupération de votre application web. L’objectif RTO pendant un géobasculement dépend du temps nécessaire pour effectuer un scale-up et un scale-out des instances.
La mise à l’échelle automatique est configurée sur la région secondaire dans le cas où la région active devient inactive. Il est conseillé d’avoir des règles de mise à l’échelle automatique similaires dans les régions actives et passives.
Lors d’un sinistre, la région primaire devient inactive et la région secondaire commence à recevoir du trafic et devient la région active.
Dès que la région secondaire est active, la charge réseau déclenche des règles de mise à l’échelle automatique préconfigurées pour effectuer un scale-out de l’application web secondaire.
Vous devrez peut-être effectuer manuellement un scale-up du niveau tarifaire de la région secondaire, si elle ne dispose pas déjà des fonctionnalités nécessaires pour s’exécuter en tant que région active. Par exemple, la mise à l’échelle automatique nécessite le niveau Standard ou supérieur.
Quand la région primaire est à nouveau active, Azure Front Door dirige automatiquement le trafic vers celle-ci, et l’architecture est à nouveau de type actif/passif, comme auparavant.
Les fichiers d’application doivent être déployés sur les deux applications web avec une solution CI/CD. Cela garantit que l’objectif RPO est pratiquement égal à zéro.
Si votre application modifie activement le système de fichiers, la meilleure façon de réduire le RPO consiste à écrire uniquement dans un partage Stockage Azure monté au lieu d’écrire directement dans le partage de contenu /home de l’application web. Ensuite, utilisez les fonctionnalités de redondance du service Stockage Azure (GZRS ou GRS) pour votre partage monté, qui a un objectif RPO d’environ 15 minutes.
Voici un résumé des étapes à suivre pour créer une architecture de type actif/passif pour votre application web dans App Service :
- Créez deux plans App Service dans deux régions Azure différentes. Le plan App Service secondaire peut être provisionné à l’aide de l’une des approches mentionnées ci-dessus.
- Configurez des règles de mise à l’échelle automatique pour le plan App Service secondaire afin qu’il soit mis à l’échelle au même nombre d’instances que le plan principal quand la région primaire devient inactive.
- Créez deux instances de votre application web, une dans chaque plan App Service.
- Créez un profil Azure Front Door avec :
- Point de terminaison.
- Un groupe d’origines ayant une priorité de 1 pour la région primaire.
- Un second groupe d’origines ayant une priorité de 2 pour la région secondaire. La différence de priorité indique à Azure Front Door de privilégier la région primaire lorsqu’elle est en ligne (donc actif/passif).
- Un itinéraire.
- Limitez le trafic réseau aux applications web uniquement à partir de l’instance Azure Front Door.
- Installez et configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.
- Déployez du code sur les applications web à l’aide d’un déploiement continu.
L’article Tutoriel : Créer une application multirégion hautement disponible dans Azure App Service vous explique comment configurer une architecture de type actif/passif.
Architecture passif/froid
Utilisez une architecture passif/froid pour créer et gérer des sauvegardes régulières de vos applications web dans un compte de stockage Azure situé dans une autre région.
Dans cet exemple d’architecture :
Une application web unique est déployée dans une seule région.
L’application web est régulièrement sauvegardée sur un compte de stockage Azure dans la même région.
La réplication inter-région de vos sauvegardes dépend de la configuration de la redondance des données dans le compte de stockage Azure. Si possible, définissez votre compte de stockage Azure sur GZRS. GZRS propose une redondance de zone synchrone dans une région et asynchrone dans une région secondaire. Si GZRS n’est pas disponible, configurez le compte en tant que GRS. GZRS et GRS ont un objectif RPO d’environ 15 minutes.
Pour vous assurer de pouvoir récupérer des sauvegardes lorsque la région primaire du compte de stockage devient indisponible, activez l’accès en lecture seule à la région secondaire (ce qui génère le compte de stockage RA-GZRS ou RA-GRS, respectivement). Pour plus d’informations sur la conception de vos applications de manière à tirer parti de la géoredondance, consultez l’article Utiliser la géoredondance pour concevoir des applications hautement disponibles.
Lors d’un sinistre dans la région de l’application web, vous devez déployer manuellement toutes les ressources App Service dépendantes requises à l’aide des sauvegardes du compte de stockage Azure, probablement de la région secondaire avec accès en lecture. L’objectif RTO peut s’exprimer en heures ou en jours.
Pour réduire l’objectif RTO, il est vivement recommandé de disposer d’un playbook complet décrivant toutes les étapes requises pour restaurer la sauvegarde de votre application web dans une autre région Azure.
Voici un résumé des étapes à suivre pour créer une région passive/froide pour votre application web dans App Service :
Créez un compte de stockage Azure dans la même région que votre application web. Choisissez le niveau de performance Standard et sélectionnez la redondance Stockage géoredondant (GRS) ou Stockage géoredondant interzone (GZRS).
Activez RA-GRS ou RA-GZRS (accès en lecture pour la région secondaire).
Configurez la sauvegarde personnalisée pour votre application web. Vous pouvez définir une planification pour les sauvegardes de votre application web (par exemple, toutes les heures).
Vérifiez que les fichiers de sauvegarde de l’application web peuvent être récupérés dans la région secondaire de votre compte de stockage.
Conseil
Outre Azure Front Door, Azure fournit d’autres options d’équilibrage de charge, telles qu’Azure Traffic Manager. Pour obtenir une comparaison des différentes options, consultez l’article Options d’équilibrage de charge - Centre des architectures Azure.
Récupération d’urgence dans une zone géographique à région unique
Si la région de votre application web n’a pas de stockage GZRS ou GRS ou si vous êtes dans une région Azure qui n’est pas l’une des paires régionales, vous devez utiliser le stockage redondant interzone (ZRS) ou le stockage localement redondant (LRS) pour créer une architecture similaire. Par exemple, vous pouvez créer manuellement une région secondaire pour le compte de stockage comme suit :
Voici un résumé des étapes à suivre pour créer une région passive/froide sans GRS et GZRS :
Créez un compte de stockage Azure dans la même région que votre application web. Choisissez le niveau de performance Standard et sélectionnez la redondance Stockage redondant interzone (ZRS).
Configurez la sauvegarde personnalisée pour votre application web. Vous pouvez définir une planification pour les sauvegardes de votre application web (par exemple, toutes les heures).
Vérifiez que les fichiers de sauvegarde de l’application web peuvent être récupérés dans la région secondaire de votre compte de stockage.
Créez un second compte de stockage Azure dans une autre région. Choisissez le niveau de performance Standard et sélectionnez la redondance Stockage localement redondant (LRS).
À l’aide d’un outil tel que AzCopy, répliquez votre sauvegarde personnalisée (fichiers zip, XML et journaux) de la région primaire vers le stockage secondaire. Par exemple :
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'Vous pouvez utiliser Azure Automation avec un runbook PowerShell Workflow pour exécuter votre script de réplication selon une planification. Assurez-vous que la planification de la réplication suit une planification similaire aux sauvegardes de l’application web.