Approches d’application App Service multirégion pour la récupération d’urgence

Azure App Service

Azure Front Door

Lorsque vous déployez une application web Azure App Service dans une seule région qui, en raison d’une panne ou d’une panne, devient indisponible, vous risquez de devenir indisponible pour votre application. Pour vous assurer que votre application reste disponible lorsque la région n’est pas disponible, vous pouvez implémenter une architecture multirégion. Avec une architecture multirégion, vous créez un déploiement identique dans une région Azure secondaire. Avec un déploiement de région secondaire, vous pouvez répliquer vos données pour récupérer l’état de la dernière application ; et peut également répliquer d’autres composants de solution.

Cet article décrit trois approches architecturales multirégions couramment utilisées pour les environnements App Service et App Service.

Approches à envisager

Les plans de continuité d’activité sont influencés par deux métriques clés :

• Objectif de temps de récupération (RTO), qui est le temps d’arrêt maximal tolérable pendant un sinistre.
• Objectif de point de récupération (RPO), qui est la perte maximale de données tolérable lors d’un sinistre.

Pour plus d’informations sur les objectifs de récupération tels que RTO et RPO, consultez les objectifs de récupération et recommandations pour définir des cibles de fiabilité.

Avec la plateforme Azure, vous pouvez concevoir des solutions d’application multirégion de différentes façons. Cet article décrit les architectures qui prennent en charge différentes exigences en matière de RTO et de RPO, et qui ont d’autres compromis pour les coûts et la complexité :

Métrique	Actif/actif	Actif/passif	Passif/froid
RTO	Temps réel ou secondes	Procès-verbaux	Heures
Objectif de point de récupération	Temps réel ou secondes	Procès-verbaux	Heures
Coût	$$$	$$	$
Scénarios	Applications stratégiques	Applications de haute priorité	Applications de faible priorité
Capacité à traiter le trafic utilisateur multirégion	Oui	Non	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

Bien que les trois approches décrites ici soient courantes, elles ne sont pas la seule façon d’obtenir une solution multirégion dans Azure. Adaptez les solutions pour répondre à vos propres besoins.

Remarque

Votre application dépend probablement d’autres services dans Azure, tels qu’Azure SQL Database, Stockage Azure comptes et files d’attente de messages. Lorsque vous concevez une stratégie de récupération d’urgence, vous devez également prendre en compte chacun de ces services Azure dépendants.

Pour en savoir plus sur les solutions multirégions pour les services Azure, consultez les guides de fiabilité des services Azure.

Surveillance

Il est important de configurer la surveillance et les alertes pour vos applications web afin que votre équipe reçoive des notifications en temps opportun lors d’une défaillance de la région. Les tests de disponibilité Azure Application Insights permettent de surveiller la disponibilité d’une application. Pour plus d’informations, consultez l’article Tests de disponibilité d’Application Insights.

Déploiement

Les solutions multirégions peuvent être complexes à déployer et à configurer. Il est important que les instances de chaque région soient synchronisées.

Pour gérer le déploiement et la configuration des ressources Azure comme App Service, 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. Considérez un outil IaC tel que Bicep, des modèles Azure Resource Manager ou Terraform.

Vous devez également configurer vos pipelines CI/CD pour déployer votre code, notamment lorsque vous utilisez plusieurs régions. Envisagez d’utiliser Azure Pipelines ou GitHub Actions. Pour plus d’informations, consultez Déploiement continu sur Azure App Service.

Architecture active-active

Dans une architecture active-active, des applications web identiques sont déployées dans deux régions distinctes. Azure Front Door est utilisé pour acheminer le trafic vers les deux régions actives :

Les applications App Service de chaque région utilisent la même configuration, y compris le niveau tarifaire et le nombre d’instances.

Pendant les opérations normales, le trafic public direct vers l’application App Service est bloqué. Le trafic est acheminé au lieu de cela par Azure Front Door vers les deux régions actives. Cette approche vous permet de vous assurer que les demandes sont inspectées par le pare-feu d’applications web Azure Front Door (WAF) ou qu’elles sont sécurisées ou gérées de manière centralisée.

Lors d’une défaillance de région, si l’une des régions est hors connexion, les sondes d’intégrité Azure Front Door détectent l’origine défectueuse et reconfigurent les itinéraires afin que le trafic soit envoyé exclusivement à la région qui reste en ligne.

Pendant une récupération de région défectueuse (restauration automatique), les sondes d’intégrité Azure Front Door détectent l’origine saine et restaurent le routage normal du trafic.

Recommandations

• Pour répondre à un RPO de zéro pour le contenu de l’application, utilisez une solution CI/CD pour déployer des fichiers d’application sur les deux applications web.

• Dans la mesure du possible, stockez l’état de l’application en dehors du système de fichiers App Service, comme dans une base de données ou Stockage Azure. Configurez ces composants pour répondre à vos exigences de géoredondance.

  Conseil

  Si votre application modifie activement le système de fichiers et que votre région d’application App Service a une région jumelée, vous pouvez réduire le RPO de votre système de fichiers en écrivant 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.

À propos de l’installation

• RTO faible : le RTO pendant un tel basculement géographique dépend de la date à laquelle les sondes d’intégrité détectent la région défectueuse. Par défaut, les sondes vérifient toutes les 30 secondes, mais vous pouvez configurer une fréquence de sonde différente.

• Équilibrage de charge et basculement : cette approche utilise Azure Front Door pour l’équilibrage de charge global, la distribution du trafic et le basculement. 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.

Déployer des applications web App Service actives

Procédez comme suit pour créer une approche active-active pour vos applications web à l’aide d’App Service :

1. Créez deux plans App Service dans deux régions Azure différentes. Configurez de façon identique les deux plans App Service.

2. Créez deux instances de votre application web, une dans chaque plan App Service.

3. Créez un profil Azure Front Door avec :

   • Point de terminaison.
   • Un groupe d’origines avec deux origines, chacun avec une priorité de 1. Les valeurs de priorité égales indiquent à Azure Front Door d’acheminer le trafic vers les applications dans les deux régions de manière égale (actif-actif).
   • Un itinéraire.

4. Limitez le trafic réseau aux applications web uniquement à partir de l’instance Azure Front Door.

5. Configurez et configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.

6. Déployez du code sur les applications web à l’aide d’un déploiement continu.

Le didacticiel Créer une application multirégion hautement disponible dans azure App Service vous montre comment configurer une architecture active-passive . Pour déployer une approche active-active, suivez les mêmes étapes, mais à une exception près : Dans Azure Front Door, configurez les deux origines dans le groupe d’origines pour avoir une priorité de 1.

Architecture actif/passif

Dans une architecture active-passive, des applications web identiques sont déployées dans deux régions distinctes. Azure Front Door est utilisé pour router le trafic vers une seule région (région active ).

Pendant les opérations normales, Azure Front Door achemine le trafic vers la région primaire uniquement. Le trafic public direct vers les applications App Service est bloqué.

Lors d’une défaillance de région, si la région primaire devient inactive, les sondes d’intégrité Azure Front Door détectent l’origine défectueuse et commencent le routage du trafic vers l’origine dans la région secondaire. La région secondaire devient ensuite 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.

Lors d’une récupération de région défectueuse (restauration automatique), Azure Front Door dirige automatiquement le trafic vers la région primaire, et l’architecture revient à active-passive comme précédemment.

Remarque

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.

Recommandations

• Pour répondre à un RPO de zéro pour le contenu de l’application, utilisez une solution CI/CD pour déployer des fichiers d’application sur les deux applications web.

• Dans la mesure du possible, stockez l’état de l’application en dehors du système de fichiers App Service, comme dans une base de données ou Stockage Azure. Configurez ces composants pour répondre à vos exigences de géoredondance.

  Conseil

  Si votre application modifie activement le système de fichiers et que votre région d’application App Service a une région jumelée, vous pouvez réduire le RPO de votre système de fichiers en écrivant 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.

À propos de l’installation

• Contrôles de coût : les applications App Service identiques sont déployées dans deux régions distinctes. 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 :

  • Préféré : le plan App Service secondaire a le même niveau tarifaire que le niveau de tarification principal, avec le même nombre d’instances ou 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.

  • Moins recommandé : le plan App Service secondaire a le même type de niveau tarifaire (par exemple PremiumV3), mais un dimensionnement de machine virtuelle plus petit, avec des instances inférieures. 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.

  • Moins recommandé : le plan App Service secondaire a un niveau tarifaire différent de celui des instances primaires et inférieures. 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 doit être configurée dans la région secondaire au cas où le trafic est redirigé et il y a un afflux soudain de requêtes. Il est conseillé d’avoir des règles de mise à l’échelle automatique similaires dans les régions actives et passives.

• Équilibrage de charge et basculement : cette approche utilise Azure Front Door pour l’équilibrage de charge global, la distribution du trafic et le basculement. 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.

Déployer des applications web App Service actives et passives

Procédez comme suit pour créer une approche active-passive pour vos applications web à l’aide d’App Service :

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

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

3. Créez deux instances de votre application web, une dans chaque plan App Service.

4. Créez un profil Azure Front Door avec :

   • Point de terminaison.

   • Un groupe d’origines avec deux origines :

     • Origine avec une priorité de 1 pour l’application dans la région primaire.
     • Deuxième origine avec une priorité de 2 pour l’application dans 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.

5. Limitez le trafic réseau aux applications web uniquement à partir de l’instance Azure Front Door.

6. Configurez et configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.

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

Dans une architecture passive/froide, votre application web est déployée dans une seule région primaire. Les fichiers d’application et certaines bases de données sont sauvegardés dans un compte Stockage Azure. Les sauvegardes sont répliquées vers une autre région. Si la région primaire n’est pas disponible, vous déployez manuellement une autre application dans une deuxième région et restaurez à partir de la sauvegarde.

Remarque

Les approches passives à froid s’appuient sur une intervention manuelle lors d’une défaillance de région et entraînent souvent un temps d’arrêt et une perte de données significatives. Pour la plupart des solutions de niveau production, vous devez envisager une solution active ou active-passive.

Réplication entre régions

Cette approche utilise la sauvegarde App Service pour sauvegarder régulièrement l’application web dans un compte Stockage Azure dans la même région. Vous configurez la réplication interrégion de vos sauvegardes en configurant le compte de stockage.

L’approche que vous utilisez pour configurer la réplication interrégion dépend de la paire de votre région. Pour plus d’informations, consultez régions et régions jumelées Azure avec des zones de disponibilité et aucune paire de régions.

Régions avec une paire

Utilisez la réplication RA-GZRS , si elle est disponible. RA-GZRS offre à la fois une redondance de zone synchrone au sein d’une région et asynchrone dans une région secondaire. Il fournit également un accès en lecture seule dans la région secondaire, ce qui est essentiel pour vous assurer que vous pouvez récupérer des sauvegardes lorsque la région principale du compte de stockage devient indisponible.

Si RA-GZRS n’est pas disponible, configurez le compte en tant que RA-GRS.

Ra-GZRS et RA-GRS ont un RPO d’environ 15 minutes.

Pour plus d’informations sur la conception de vos applications pour tirer parti du stockage géoredondant, consultez Utiliser la géoredondance pour concevoir des applications hautement disponibles.

Régions sans paire

Vous devez répliquer vos sauvegardes d’application vers un compte de stockage dans une autre région. La réplication d’objets de stockage Azure vous permet de configurer la réplication automatique des objets blob entre deux comptes de stockage, même s’ils se trouvent dans différentes régions. Stockage Azure gère automatiquement le processus de réplication.

La réplication d’objets ne garantit pas la rapidité avec laquelle les données sont répliquées. Toutefois, vous pouvez vérifier l’état de réplication d’un objet blob.

Si vous devez contrôler la fréquence de réplication des données entre les comptes de stockage, vous pouvez utiliser un outil tel qu’AzCopy pour copier explicitement les fichiers de sauvegarde entre les comptes de stockage dans différentes régions. AzCopy est un outil, et non un service, donc vous devez le configurer pour l’exécuter à l’aide d’Azure Automation ou d’une autre plateforme de calcul :

Expérience vers le bas de la région

Si la région primaire n’est pas disponible, vous devez détecter la perte de région. Pour plus d’informations, consultez Surveillance.

Pour préparer la région secondaire à recevoir le trafic, déployez toutes les ressources App Service requises et les ressources dépendantes à l’aide des sauvegardes du compte Stockage Azure dans votre région secondaire.

À propos de l’installation

• RTO élevé : étant donné que ce processus nécessite une détection et une réponse manuelles, le RTO pour ce scénario peut être des heures ou même des jours. Pour réduire votre RTO, générez et testez un playbook complet décrivant toutes les étapes requises pour restaurer votre sauvegarde d’application web dans une autre région Azure.

  Même après avoir créé votre application dans la région secondaire, vous devrez peut-être gérer des complexités telles que les enregistrements DNS et les certificats TLS. Vérifiez que vous avez planifié chaque étape nécessaire pour envoyer du trafic à votre région secondaire et tester régulièrement vos plans.

• RPO élevé : les sauvegardes peuvent être planifiées jusqu’à une fois par heure. Si votre application principale est hors connexion, la sauvegarde que vous restaurez dans une région secondaire peut être obsolète. Votre RPO dépend de la fréquence de vos sauvegardes ainsi que de la rapidité avec laquelle ces sauvegardes sont répliquées entre les régions.

Étapes de procédure

Les étapes que vous utilisez pour configurer un déploiement passif à froid varient selon que votre région a une paire. Pour plus d’informations, consultez régions et régions jumelées Azure avec des zones de disponibilité et aucune paire de régions.

Régions avec une paire

Les étapes de création d’une région à froid passif pour votre application web dans App Service sont les suivantes :

1. 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 redondance en tant que stockage géoredondant (GRS) ou stockage géoredondant interzone (GZRS).

2. Activez RA-GRS ou RA-GZRS (accès en lecture pour la région secondaire).

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

4. Vérifiez que les fichiers de sauvegarde d’application web peuvent être récupérés dans la région secondaire de votre compte de stockage.

Régions sans paire

Les étapes de création d’une région à froid passif pour votre application web dans App Service sont les suivantes :

1. 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 redondance en tant que stockage redondant interzone (ZRS) s’il est disponible.

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

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

4. Configurez la réplication d’objets sur le conteneur dans le compte de stockage principal afin qu’elle soit répliquée sur un conteneur dans le compte de stockage secondaire.

5. Vérifiez que les fichiers de sauvegarde d’application web peuvent être récupérés dans la région secondaire de votre compte de stockage.

Étapes suivantes

Passez en revue les architectures de référence Azure App Service :

• Pour une application redondante interrégion unique, consultez l’application web redondante interzone hautement disponible de référence.
• Pour une application multirégion active/passive, consultez l’application web multirégion hautement disponible.

Lorsque vous déployez une application web Azure App Service dans une seule région qui, en raison d’une panne ou d’une panne, devient indisponible, vous risquez de devenir indisponible pour votre application. Pour vous assurer que votre application reste disponible lorsque la région n’est pas disponible, vous pouvez implémenter une architecture multirégion. Avec une architecture multirégion, vous créez un déploiement identique dans une région Azure secondaire. Avec un déploiement de région secondaire, vous pouvez répliquer vos données pour récupérer l’état de la dernière application ; et peut également répliquer d’autres composants de solution.

Cet article décrit trois approches architecturales multirégions couramment utilisées pour les environnements App Service et App Service.

Approches à envisager

Les plans de continuité d’activité sont influencés par deux métriques clés :

• Objectif de temps de récupération (RTO), qui est le temps d’arrêt maximal tolérable pendant un sinistre.
• Objectif de point de récupération (RPO), qui est la perte maximale de données tolérable lors d’un sinistre.

Pour plus d’informations sur les objectifs de récupération tels que RTO et RPO, consultez les objectifs de récupération et recommandations pour définir des cibles de fiabilité.

Avec la plateforme Azure, vous pouvez concevoir des solutions d’application multirégion de différentes façons. Cet article décrit les architectures qui prennent en charge différentes exigences en matière de RTO et de RPO, et qui ont d’autres compromis pour les coûts et la complexité :

Métrique	Actif/actif	Actif/passif	Passif/froid
RTO	Temps réel ou secondes	Procès-verbaux	Heures
Objectif de point de récupération	Temps réel ou secondes	Procès-verbaux	Heures
Coût	$$$	$$	$
Scénarios	Applications stratégiques	Applications de haute priorité	Applications de faible priorité
Capacité à traiter le trafic utilisateur multirégion	Oui	Non	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

Bien que les trois approches décrites ici soient courantes, elles ne sont pas la seule façon d’obtenir une solution multirégion dans Azure. Adaptez les solutions pour répondre à vos propres besoins.

Remarque

Votre application dépend probablement d’autres services dans Azure, tels qu’Azure SQL Database, Stockage Azure comptes et files d’attente de messages. Lorsque vous concevez une stratégie de récupération d’urgence, vous devez également prendre en compte chacun de ces services Azure dépendants.

Pour en savoir plus sur les solutions multirégions pour les services Azure, consultez les guides de fiabilité des services Azure.

Surveillance

Il est important de configurer la surveillance et les alertes pour vos applications web afin que votre équipe reçoive des notifications en temps opportun lors d’une défaillance de la région. Les tests de disponibilité Azure Application Insights permettent de surveiller la disponibilité d’une application. Pour plus d’informations, consultez l’article Tests de disponibilité d’Application Insights.

Déploiement

Les solutions multirégions peuvent être complexes à déployer et à configurer. Il est important que les instances de chaque région soient synchronisées.

Pour gérer le déploiement et la configuration des ressources Azure comme App Service, 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. Considérez un outil IaC tel que Bicep, des modèles Azure Resource Manager ou Terraform.

Vous devez également configurer vos pipelines CI/CD pour déployer votre code, notamment lorsque vous utilisez plusieurs régions. Envisagez d’utiliser Azure Pipelines ou GitHub Actions. Pour plus d’informations, consultez Déploiement continu sur Azure App Service.

Architecture active-active

Dans une architecture active-active, des applications web identiques sont déployées dans deux régions distinctes. Azure Front Door est utilisé pour acheminer le trafic vers les deux régions actives :

Les applications App Service de chaque région utilisent la même configuration, y compris le niveau tarifaire et le nombre d’instances.

Pendant les opérations normales, le trafic public direct vers l’application App Service est bloqué. Le trafic est acheminé au lieu de cela par Azure Front Door vers les deux régions actives. Cette approche vous permet de vous assurer que les demandes sont inspectées par le pare-feu d’applications web Azure Front Door (WAF) ou qu’elles sont sécurisées ou gérées de manière centralisée.

Lors d’une défaillance de région, si l’une des régions est hors connexion, les sondes d’intégrité Azure Front Door détectent l’origine défectueuse et reconfigurent les itinéraires afin que le trafic soit envoyé exclusivement à la région qui reste en ligne.

Pendant une récupération de région défectueuse (restauration automatique), les sondes d’intégrité Azure Front Door détectent l’origine saine et restaurent le routage normal du trafic.

Recommandations

• Pour répondre à un RPO de zéro pour le contenu de l’application, utilisez une solution CI/CD pour déployer des fichiers d’application sur les deux applications web.

• Dans la mesure du possible, stockez l’état de l’application en dehors du système de fichiers App Service, comme dans une base de données ou Stockage Azure. Configurez ces composants pour répondre à vos exigences de géoredondance.

  Conseil

  Si votre application modifie activement le système de fichiers et que votre région d’application App Service a une région jumelée, vous pouvez réduire le RPO de votre système de fichiers en écrivant 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.

À propos de l’installation

• RTO faible : le RTO pendant un tel basculement géographique dépend de la date à laquelle les sondes d’intégrité détectent la région défectueuse. Par défaut, les sondes vérifient toutes les 30 secondes, mais vous pouvez configurer une fréquence de sonde différente.

• Équilibrage de charge et basculement : cette approche utilise Azure Front Door pour l’équilibrage de charge global, la distribution du trafic et le basculement. 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.

Déployer des applications web App Service actives

Procédez comme suit pour créer une approche active-active pour vos applications web à l’aide d’App Service :

1. Créez deux plans App Service dans deux régions Azure différentes. Configurez de façon identique les deux plans App Service.

2. Créez deux instances de votre application web, une dans chaque plan App Service.

3. Créez un profil Azure Front Door avec :

   • Point de terminaison.
   • Un groupe d’origines avec deux origines, chacun avec une priorité de 1. Les valeurs de priorité égales indiquent à Azure Front Door d’acheminer le trafic vers les applications dans les deux régions de manière égale (actif-actif).
   • Un itinéraire.

4. Limitez le trafic réseau aux applications web uniquement à partir de l’instance Azure Front Door.

5. Configurez et configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.

6. Déployez du code sur les applications web à l’aide d’un déploiement continu.

Le didacticiel Créer une application multirégion hautement disponible dans azure App Service vous montre comment configurer une architecture active-passive . Pour déployer une approche active-active, suivez les mêmes étapes, mais à une exception près : Dans Azure Front Door, configurez les deux origines dans le groupe d’origines pour avoir une priorité de 1.

Architecture actif/passif

Dans une architecture active-passive, des applications web identiques sont déployées dans deux régions distinctes. Azure Front Door est utilisé pour router le trafic vers une seule région (région active ).

Pendant les opérations normales, Azure Front Door achemine le trafic vers la région primaire uniquement. Le trafic public direct vers les applications App Service est bloqué.

Lors d’une défaillance de région, si la région primaire devient inactive, les sondes d’intégrité Azure Front Door détectent l’origine défectueuse et commencent le routage du trafic vers l’origine dans la région secondaire. La région secondaire devient ensuite 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.

Lors d’une récupération de région défectueuse (restauration automatique), Azure Front Door dirige automatiquement le trafic vers la région primaire, et l’architecture revient à active-passive comme précédemment.

Remarque

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.

Recommandations

• Pour répondre à un RPO de zéro pour le contenu de l’application, utilisez une solution CI/CD pour déployer des fichiers d’application sur les deux applications web.

• Dans la mesure du possible, stockez l’état de l’application en dehors du système de fichiers App Service, comme dans une base de données ou Stockage Azure. Configurez ces composants pour répondre à vos exigences de géoredondance.

  Conseil

  Si votre application modifie activement le système de fichiers et que votre région d’application App Service a une région jumelée, vous pouvez réduire le RPO de votre système de fichiers en écrivant 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.

À propos de l’installation

• Contrôles de coût : les applications App Service identiques sont déployées dans deux régions distinctes. 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 :

  • Préféré : le plan App Service secondaire a le même niveau tarifaire que le niveau de tarification principal, avec le même nombre d’instances ou 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.

  • Moins recommandé : le plan App Service secondaire a le même type de niveau tarifaire (par exemple PremiumV3), mais un dimensionnement de machine virtuelle plus petit, avec des instances inférieures. 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.

  • Moins recommandé : le plan App Service secondaire a un niveau tarifaire différent de celui des instances primaires et inférieures. 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 doit être configurée dans la région secondaire au cas où le trafic est redirigé et il y a un afflux soudain de requêtes. Il est conseillé d’avoir des règles de mise à l’échelle automatique similaires dans les régions actives et passives.

• Équilibrage de charge et basculement : cette approche utilise Azure Front Door pour l’équilibrage de charge global, la distribution du trafic et le basculement. 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.

Déployer des applications web App Service actives et passives

Procédez comme suit pour créer une approche active-passive pour vos applications web à l’aide d’App Service :

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

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

3. Créez deux instances de votre application web, une dans chaque plan App Service.

4. Créez un profil Azure Front Door avec :

   • Point de terminaison.

   • Un groupe d’origines avec deux origines :

     • Origine avec une priorité de 1 pour l’application dans la région primaire.
     • Deuxième origine avec une priorité de 2 pour l’application dans 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.

5. Limitez le trafic réseau aux applications web uniquement à partir de l’instance Azure Front Door.

6. Configurez et configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.

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

Dans une architecture passive/froide, votre application web est déployée dans une seule région primaire. Les fichiers d’application et certaines bases de données sont sauvegardés dans un compte Stockage Azure. Les sauvegardes sont répliquées vers une autre région. Si la région primaire n’est pas disponible, vous déployez manuellement une autre application dans une deuxième région et restaurez à partir de la sauvegarde.

Remarque

Les approches passives à froid s’appuient sur une intervention manuelle lors d’une défaillance de région et entraînent souvent un temps d’arrêt et une perte de données significatives. Pour la plupart des solutions de niveau production, vous devez envisager une solution active ou active-passive.

Réplication entre régions

Cette approche utilise la sauvegarde App Service pour sauvegarder régulièrement l’application web dans un compte Stockage Azure dans la même région. Vous configurez la réplication interrégion de vos sauvegardes en configurant le compte de stockage.

L’approche que vous utilisez pour configurer la réplication interrégion dépend de la paire de votre région. Pour plus d’informations, consultez régions et régions jumelées Azure avec des zones de disponibilité et aucune paire de régions.

Régions avec une paire

Utilisez la réplication RA-GZRS , si elle est disponible. RA-GZRS offre à la fois une redondance de zone synchrone au sein d’une région et asynchrone dans une région secondaire. Il fournit également un accès en lecture seule dans la région secondaire, ce qui est essentiel pour vous assurer que vous pouvez récupérer des sauvegardes lorsque la région principale du compte de stockage devient indisponible.

Si RA-GZRS n’est pas disponible, configurez le compte en tant que RA-GRS.

Ra-GZRS et RA-GRS ont un RPO d’environ 15 minutes.

Pour plus d’informations sur la conception de vos applications pour tirer parti du stockage géoredondant, consultez Utiliser la géoredondance pour concevoir des applications hautement disponibles.

Régions sans paire

Vous devez répliquer vos sauvegardes d’application vers un compte de stockage dans une autre région. La réplication d’objets de stockage Azure vous permet de configurer la réplication automatique des objets blob entre deux comptes de stockage, même s’ils se trouvent dans différentes régions. Stockage Azure gère automatiquement le processus de réplication.

La réplication d’objets ne garantit pas la rapidité avec laquelle les données sont répliquées. Toutefois, vous pouvez vérifier l’état de réplication d’un objet blob.

Si vous devez contrôler la fréquence de réplication des données entre les comptes de stockage, vous pouvez utiliser un outil tel qu’AzCopy pour copier explicitement les fichiers de sauvegarde entre les comptes de stockage dans différentes régions. AzCopy est un outil, et non un service, donc vous devez le configurer pour l’exécuter à l’aide d’Azure Automation ou d’une autre plateforme de calcul :

Expérience vers le bas de la région

Si la région primaire n’est pas disponible, vous devez détecter la perte de région. Pour plus d’informations, consultez Surveillance.

Pour préparer la région secondaire à recevoir le trafic, déployez toutes les ressources App Service requises et les ressources dépendantes à l’aide des sauvegardes du compte Stockage Azure dans votre région secondaire.

À propos de l’installation

• RTO élevé : étant donné que ce processus nécessite une détection et une réponse manuelles, le RTO pour ce scénario peut être des heures ou même des jours. Pour réduire votre RTO, générez et testez un playbook complet décrivant toutes les étapes requises pour restaurer votre sauvegarde d’application web dans une autre région Azure.

  Même après avoir créé votre application dans la région secondaire, vous devrez peut-être gérer des complexités telles que les enregistrements DNS et les certificats TLS. Vérifiez que vous avez planifié chaque étape nécessaire pour envoyer du trafic à votre région secondaire et tester régulièrement vos plans.

• RPO élevé : les sauvegardes peuvent être planifiées jusqu’à une fois par heure. Si votre application principale est hors connexion, la sauvegarde que vous restaurez dans une région secondaire peut être obsolète. Votre RPO dépend de la fréquence de vos sauvegardes ainsi que de la rapidité avec laquelle ces sauvegardes sont répliquées entre les régions.

Étapes de procédure

Les étapes que vous utilisez pour configurer un déploiement passif à froid varient selon que votre région a une paire. Pour plus d’informations, consultez régions et régions jumelées Azure avec des zones de disponibilité et aucune paire de régions.

Régions avec une paire

Les étapes de création d’une région à froid passif pour votre application web dans App Service sont les suivantes :

1. 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 redondance en tant que stockage géoredondant (GRS) ou stockage géoredondant interzone (GZRS).

2. Activez RA-GRS ou RA-GZRS (accès en lecture pour la région secondaire).

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

4. Vérifiez que les fichiers de sauvegarde d’application web peuvent être récupérés dans la région secondaire de votre compte de stockage.

Régions sans paire

Les étapes de création d’une région à froid passif pour votre application web dans App Service sont les suivantes :

1. 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 redondance en tant que stockage redondant interzone (ZRS) s’il est disponible.

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

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

4. Configurez la réplication d’objets sur le conteneur dans le compte de stockage principal afin qu’elle soit répliquée sur un conteneur dans le compte de stockage secondaire.

5. Vérifiez que les fichiers de sauvegarde d’application web peuvent être récupérés dans la région secondaire de votre compte de stockage.

Étapes suivantes

Passez en revue les architectures de référence Azure App Service :

• Pour une application redondante interrégion unique, consultez l’application web redondante interzone hautement disponible de référence.
• Pour une application multirégion active/passive, consultez l’application web multirégion hautement disponible.