Ressources zonales et résilience de zone

Dans Azure, une ressource zonale est une ressource épinglée à une seule zone. Étant donné qu’une ressource zonale se trouve dans une seule zone de disponibilité, elle n’est pas résiliente à la zone. Si la zone qui contient la ressource a un problème, la ressource risque d’être en temps d’arrêt.

Certains services Azure nécessitent ou vous permettent de déployer des ressources zonales. Vous pouvez choisir de déployer une ressource de manière zonale en raison de considérations relatives à la latence ou à des exigences spécifiques du service. Vous pouvez épingler des ressources individuelles ou des ensembles de ressources associées à une seule zone.

Cet article décrit les scénarios dans lesquels vous pouvez choisir de déployer des ressources zonales au lieu de ressources redondantes interzones. Il met également en évidence les considérations et responsabilités requises pour vous assurer que votre solution reste résiliente aux pannes de zone.

Types de déploiement de ressources

Dans Azure, seuls certains types de déploiement fournissent une résilience de zone. Le tableau suivant compare trois types de déploiement de ressources et décrit leur résilience de zone, la distribution de zone, les options de configuration et les recommandations.

Pour plus d’informations sur les zones de disponibilité et les déploiements de ressources, consultez Zones de disponibilité.

Charges de travail combinant des ressources redondantes interzones et propres à une zone

De nombreuses charges de travail combinent des ressources redondantes interzones et zonales. Par exemple, votre charge de travail peut inclure un ensemble de machines virtuelles zonales pour votre niveau de base de données, un serveur web redondant interzone hébergé sur Azure App Service et un équilibreur de charge redondant interzone pour envoyer le trafic à vos machines virtuelles de base de données.

Lorsque vous combinez des ressources zonales et redondantes interzone dans une charge de travail, réfléchissez à la façon dont chaque ressource et la solution globale se comportent si une zone de disponibilité a un problème. En règle générale, les services redondants interzone récupèrent automatiquement des pannes de zone avec une perte de données minimale voire nulle, et Microsoft gère l’ensemble du processus. Pour les ressources zonales, vous assumez la configuration du basculement automatisé ou des opérations de récupération manuelle. Pour savoir comment chaque service se comporte pendant les scénarios de panne de zone, comprenez vos responsabilités par rapport à celles de Microsoft et surveillez l’intégrité des services pendant ces événements, consultez le guide de fiabilité de votre service.

Quand utiliser un déploiement zonal

Utilisez des ressources zonales uniquement lorsqu’il existe un besoin clair. Les raisons courantes d’un déploiement à zone unique incluent des cas où une ressource doit être zonale, un service est disponible uniquement dans une zone spécifique ou une charge de travail est très sensible à la latence interzone.

Ressources nécessitant des déploiements zonaux

Quelques services Azure prennent uniquement en charge les déploiements zonaux et ne fournissent pas de déploiements redondants interzone.

Les machines virtuelles sont une ressource zonale. Vous pouvez utiliser Virtual Machine Scale Sets pour créer des groupes de machines virtuelles. Les ensembles d'échelles de machines virtuelles peuvent s'étendre sur plusieurs zones, ce qui signifie que les machines virtuelles du groupe sont réparties sur plusieurs zones. Les ensembles échelonnables sont un excellent moyen d'assurer une résilience zonale pour de nombreuses charges de travail basées sur des VM.

Un autre exemple est Azure NetApp Files, qui prend en charge le déploiement de volumes dans une seule zone. Le service vous permet également de répliquer entre plusieurs volumes zonaux.

Certains services fournissent des options disponibles uniquement dans des zones spécifiques. Par exemple, des types de machines virtuelles spécifiques qui utilisent des unités de traitement graphique avancées (GPU) peuvent être disponibles uniquement dans des zones spécifiques d’une région, ce qui signifie qu’ils ne peuvent pas être déployés sur plusieurs zones. Pour vérifier quelles régions et zones prennent en charge les types de machines virtuelles dont vous avez besoin, utilisez les ressources suivantes :

• Pour vérifier les types de machines virtuelles disponibles dans chaque région, consultez Produits disponibles par région.

• Pour vérifier les types et tailles de machine virtuelle pris en charge dans chaque zone d’une région spécifique, consultez Vérifier la disponibilité de la référence SKU de machine virtuelle.

Si le type de machine virtuelle dont vous avez besoin est disponible uniquement dans une seule zone au sein de la région que vous utilisez, vous pouvez envisager un déploiement zonal pour cette machine virtuelle, puis trouver d’autres façons de rendre la machine virtuelle résiliente aux pannes de zone. Toutefois, vous devez continuer à vous assurer que les autres parties de votre solution sont résilientes en zone.

Pour plus d’informations, consultez les services Azure qui prennent en charge les zones de disponibilité.

Latence interzone

Si vous avez une charge de travail exceptionnellement sensible à la latence, vous pourriez utiliser des ressources zonales au lieu de ressources redondantes entre zones, même si un service prend en charge les déploiements redondants entre zones.

Un réseau à faible latence connecte les zones de disponibilité, avec une latence aller-retour interzone généralement en moins de deux millisecondes. Pour la plupart des charges de travail, la latence interzone n’est pas un problème. Les avantages de la résilience de la répartition des ressources entre les zones de disponibilité sont plus importants que l’impact minimal sur les performances de l’envoi du trafic entre les zones. Mais quelques charges de travail sont très sensibles à la latence interzone. Ces charges de travail peuvent inclure les scénarios suivants :

• Applications locales héritées : Certaines charges de travail héritées peuvent contenir des applications conçues à l’origine pour un environnement local. Ces charges de travail supposent que les composants, tels que les bases de données et d’autres applications et services, sont colocalisés sur le même hôte ou dans une proximité physique étroite.

• Réplication synchrone à très grande échelle : Les applications et bases de données avec état effectuent parfois un très grand nombre d’écritures à l’aide de la réplication synchrone. La réplication synchrone signifie que les données sont écrites dans plusieurs réplicas avant que l’opération d’écriture soit considérée comme terminée. La distribution de réplicas entre les zones de disponibilité améliore la résilience, mais lorsque vous utilisez la réplication synchrone, la latence interzone peut augmenter la latence d’écriture de la charge de travail. Cette latence accrue n’est généralement pas significative, mais en raison de la façon dont certaines applications sont conçues, il peut parfois devenir problématique à grande échelle.

Si vous pensez que la latence interzone affecte votre charge de travail, testez son impact dans un environnement réaliste en suivant ces étapes pour votre charge de travail spécifique :

1. Définissez les exigences de performances acceptables. Le trafic interzone ajoute une faible latence, mais il est négligeable pour la plupart des charges de travail. Définissez les performances acceptables pour votre charge de travail.

2. Exécutez un test de performances dans une seule zone de disponibilité. Établissez un ensemble de métriques de performances de référence.

   Important

   Testez votre charge de travail, y compris vos applications, protocoles, configuration et région Azure. Utilisez une charge réaliste. Les tests de référence et de synthèse ne sont pas suffisants, car ils ne montrent pas comment votre solution se comporte réellement.

3. Activer la réplication interzone. Selon les composants que vous utilisez, vous pouvez activer la redondance de zone ou déplacer des répliques entre zones.

4. Réexécutez les tests de performances. Collectez les mêmes métriques que celles que vous avez collectées précédemment.

5. Comparez l’impact sur les performances par rapport à vos besoins. Utilisez vos exigences et les données de performances pour prendre une décision éclairée sur le compromis entre latence et résilience aux pannes de zone.

   Si le test montre que la latence est anormalement élevée pour votre charge de travail, envisagez d’effectuer les actions suivantes :

   • Essayez d’utiliser un autre ensemble de zones. Il peut y avoir une légère variabilité dans la latence entre différentes zones, car elles peuvent avoir des distances physiques différentes entre elles.

     Conseil / Astuce

     Si vous réalisez des tests sur plusieurs abonnements Azure, vérifiez le mappage logique-physique des zones afin de garantir que vous testez bien les ensembles de zones physiques souhaités.

   • S’il existe une autre région Azure qui répond à vos besoins globaux en matière de résidence des données et d’autres facteurs, essayez d’utiliser plusieurs zones dans cette région.

   • Déterminez si vous pouvez redéfinir votre application pour réduire la communication interzone requise. Par exemple, vous pouvez consolider plusieurs opérations de base de données de petite taille en une seule opération. Cette approche peut réduire l’impact de la latence sur votre charge de travail.

   Si aucune de ces actions n’est utile, envisagez d’exécuter la charge de travail ou les composants spécifiques dans une seule zone de disponibilité à l’aide de machines virtuelles zonales et d’autres services Azure pris en charge. Vous prenez ensuite la responsabilité de rendre les composants zonaux résilients aux pannes de zone. Passez en revue le reste de cet article pour comprendre vos responsabilités et certaines approches à prendre en compte.

Vos responsabilités pour un déploiement zonal

Une ressource zonale risque de temps d’arrêt lorsque sa zone de disponibilité subit une panne. Lorsque vous déployez une ressource zonale, vous êtes responsable de la résilience de votre charge de travail aux défaillances au niveau de la zone.

Pour rendre les ressources zonales résilientes, tenez compte des responsabilités suivantes :

• Déploiement et configuration de plusieurs ressources : Déployez manuellement des ressources zonales distinctes dans différentes zones ou régions. Déterminez comment maintenir la cohérence de la configuration sur chaque ressource. L’utilisation de l’infrastructure en tant que code (IaC) est une bonne pratique, car elle permet un déploiement rapide de plusieurs ressources identiques.

• Routage et distribution du trafic : Vous devez sélectionner un composant d’équilibreur de charge, s’assurer qu’il est résilient aux zones et le configurer pour envoyer le trafic entre les ressources dans différentes zones. Vous configurez généralement la stratégie de routage (telle que active-active ou active-passive), les contrôles d’intégrité automatisés et les processus de basculement. Pour plus d’informations, consultez les options d’équilibrage de charge.

• Répliques ou sauvegardes de données : Pour les ressources avec état, vous êtes responsable de la protection des données qu'elles stockent et d'assurer qu'elles sont conservées en toute sécurité dans plusieurs régions. Une approche courante consiste à configurer la réplication vers une autre instance de service dans une autre zone de disponibilité. Dans certains cas, vous pouvez vous appuyer sur des sauvegardes à la place. Toutefois, les sauvegardes nécessitent un temps de récupération plus long pendant une défaillance de zone, ce qui vous oblige à avoir un objectif de temps de récupération plus élevé (RTO). Ils entraînent également une perte de données plus élevée, ce qui nécessite un objectif de point de récupération (RPO) plus élevé.

• Détection des défaillances de zone et implémentation du processus de réponse : Vous devez déterminer comment surveiller l’intégrité des ressources zonales, définir les conditions qui les marquent comme non saines et déclencher des actions de réponse telles que la restauration d’opérations dans une autre zone ou une autre région.

• Processus de récupération de zone : Une fois la zone récupérée, vous êtes responsable des actions de récupération requises, telles que repasser aux ressources dans la zone primaire.

Approches courantes pour la résilience du déploiement zonal

Pour prendre des décisions éclairées sur la résilience des zones pour vos ressources zonales, tenez compte des facteurs suivants :

• Passez en revue votre charge de travail entière. Découvrez comment chaque composant se comporte pendant les événements d'interruption de zone, y compris les ressources redondantes interzone, zonales et nonrégionales. Utilisez le guide de fiabilité de chaque service pour découvrir le fonctionnement du service dans les scénarios de panne de zone et comment surveiller l’intégrité des services pour les événements de zone hors connexion.

• Comprendre la perte de données autorisée lors d’une défaillance de zone. Votre RPO spécifie la quantité de perte de données que vous pouvez accepter.

  De nombreuses ressources redondantes interzone Azure fournissent un RPO de zéro pour les défaillances de zone, ce qui signifie qu’aucune perte de données ne se produit. Ils obtiennent généralement ce RPO en répliquant de manière synchrone toutes les modifications entre les zones.

  Lorsque vous planifiez un déploiement zonal, vous devez vous assurer que vous pouvez répondre aux exigences de RPO de votre charge de travail en cas d’échec d’une zone.

• Comprendre le temps d’arrêt autorisé pendant une défaillance de zone. Votre RTO spécifie le temps d’arrêt que vous pouvez accepter.

  Les ressources redondantes interzone Azure fournissent généralement un RTO très faible pour les défaillances de zone et nécessitent généralement seulement quelques secondes de temps d’arrêt.

  Lorsque vous planifiez un déploiement zonal, vous devez vous assurer que vous pouvez répondre aux exigences du RTO de votre charge de travail. Si vous avez un RTO faible, vous devrez peut-être vous appuyer sur des processus de détection et de récupération automatisés. Un RTO plus élevé offre une plus grande flexibilité pour vos processus de réponse.

• Comprendre le coût. Les ressources zonales sont généralement facturées individuellement, de sorte que le déploiement de plusieurs ressources zonales peut augmenter le coût de vos ressources.

Concevoir un déploiement zonal pour la résilience

Lorsque vous concevez votre déploiement zonal pour la résilience, déterminez si vous utilisez des zones de disponibilité pour obtenir une haute disponibilité ou une récupération d’urgence. La distinction entre ces concepts est basée sur vos exigences en matière de RTO et de RPO.

Si vous avez besoin d’un RTO faible et d’un RPO faible, vous devez traiter les zones de disponibilité comme une construction à haute disponibilité . Toutefois, si votre RTO et votre RPO sont plus élevés, vous pouvez choisir de traiter les zones de disponibilité comme une construction de récupération d’urgence . Pour plus d’informations, consultez continuité d’activité, haute disponibilité et reprise d’activité. Votre niveau de charge de travail peut vous aider à déterminer vos besoins et les actions nécessaires.

Concevoir pour la haute disponibilité

Envisagez de déployer votre propre architecture hautement disponible sur plusieurs zones. Une architecture hautement disponible nécessite une réplication automatisée et fréquente des données entre les composants déployés sur plusieurs zones et le basculement automatique entre ces composants en cas de défaillance de zone.

Certaines applications que vous déployez sur des machines virtuelles de zone offrent une prise en charge intégrée de la haute disponibilité, notamment en étant sensibles aux répliques. Par exemple, si vous utilisez SQL Server sur des machines virtuelles Azure, les groupes de disponibilité fournissent des fonctionnalités de routage et de basculement du trafic. Vous pouvez choisir d’utiliser la réplication synchrone ou asynchrone. Pour plus d’informations, consultez continuité d’activité, haute disponibilité et récupération d’urgence pour SQL Server sur des machines virtuelles Azure.

Conception de systèmes de récupération d’urgence

La récupération d’urgence diffère de la haute disponibilité, car les temps d’arrêt et la perte de données sont acceptables dans un scénario de sinistre. RTO et RPO sont généralement mesurés en heures ou plus.

Un plan de récupération d’urgence vous aide à vous préparer à différents scénarios et définit comment répondre à l’aide d’une combinaison de processus automatisés et manuels.

Les approches de récupération d’urgence suivantes peuvent vous aider lorsque vous planifiez un déploiement zonal :

• Récupération d’urgence interzone à zone Azure Site Recovery : Cette approche est utile lorsque vous avez besoin d’une réplication asynchrone au niveau du disque entre des machines virtuelles dans différentes zones. Pour plus d’informations, consultez Activer la récupération d’urgence des machines virtuelles Azure entre les zones de disponibilité.

• Récupération d’urgence de région à région Site Recovery : Site Recovery prend en charge la récupération d’urgence de région à région et s’appuie sur la réplication asynchrone. Cette approche vous permet de basculer vers une zone dans une autre région Azure au lieu d’une autre zone de votre région primaire. Pour plus d’informations, consultez Répliquer des machines virtuelles Azure vers une autre région Azure.

• Récupération d’urgence basée sur la sauvegarde : Si votre solution peut tolérer un RTO élevé et un RPO élevé, envisagez d’utiliser des sauvegardes comme stratégie de récupération d’urgence. Si la zone subit une panne, vous pouvez ensuite restaurer des sauvegardes dans une autre zone ou région. Vous devez également déterminer si vous précréez les autres ressources Azure dans votre solution ou si vous les créez pendant le processus de basculement.

  Dans une architecture zonale, vous êtes souvent responsable du stockage et de la réplication de ces sauvegardes.

  Sauvegarde Azure est un service de sauvegarde managée largement utilisé. Il prend en charge les sauvegardes redondantes interzone et les sauvegardes géorépliquées entre les régions Azure jumelées. Certaines applications, telles que SQL Server sur des machines virtuelles Azure, incluent également des fonctionnalités de sauvegarde intégrées spécifiques à l’application.

Étape suivante

• Recommandations relatives à l’utilisation de zones de disponibilité et de régions dans Azure Well-Architected Framework