Base de référence de migration des zones de disponibilité Azure
Cet article explique comment évaluer la préparation de la zone de disponibilité de votre application à des fins de migration de la zone de non-disponibilité vers la prise en charge de la zone de disponibilité. Nous allons vous présenter les étapes à suivre pour déterminer comment vous pouvez tirer parti de la prise en charge des zones de disponibilité en fonction des exigences régionales et de votre application. Pour obtenir des informations détaillées sur les zones de disponibilité et les régions qui les prennent en charge, consultez Que sont les régions et les zones de disponibilité Azure ?.
Lorsque vous créez des charges de travail fiables, vous pouvez choisir au moins l’une des configurations de zone de disponibilité suivantes :
Instances zonales. Une configuration zonale fournit une zone de disponibilité spécifique et auto-sélectionnée.
Instances redondantes interzones. Une configuration redondante interzone fournit des ressources qui sont répliquées ou distribuées automatiquement entre les zones.
Outre les deux options de zone de disponibilité (zonale et redondante interzone), Azure offre des services globaux, ce qui signifie qu’ils sont disponibles dans le monde entier, quelle que soit la région. Étant donné que ces services sont toujours disponibles dans toutes les régions, ils sont résilients aux pannes régionales et zonales.
Pour savoir quels services Azure prennent en charge les zones de disponibilité, consultez Service de zone de disponibilité et prise en charge régionale.
Remarque
Lorsque vous ne sélectionnez pas de configuration de zone pour votre ressource (zonale ou redondante interzone), la ressource et ses sous-composants ne sont pas résilients dans la zone, et ils peuvent subir une défaillance pendant une panne zonale dans cette région.
Considérations relatives à la migration vers la prise en charge des zones de disponibilité
Il existe plusieurs façons de créer une application Azure fiable avec des zones de disponibilité qui répondent à la fois aux objectifs de niveau de service et de fiabilité. Effectuez les étapes suivantes pour choisir l’approche la plus adaptée à vos besoins en fonction des considérations techniques et réglementaires, des fonctionnalités de service, de la résidence des données, des exigences de conformité et de la latence.
Étape 1 : Vérifier si la région Azure prend en charge les zones de disponibilité
Lors de cette première étape, vous devez vérifier que votre région Azure sélectionnée prend en charge les zones de disponibilité ainsi que les services Azure requis pour votre application.
Si votre région prend en charge les zones de disponibilité, nous vous recommandons vivement de configurer votre charge de travail pour les zones de disponibilité. Si votre région ne prend pas en charge les zones de disponibilité, vous devez utiliser les instructions Azure Resource Mover pour migrer vers une région qui offre une prise en charge des zones de disponibilité.
Remarque
Pour certains services, les zones de disponibilité ne peuvent être configurées que pendant le déploiement. Si vous souhaitez inclure des zones de disponibilité pour les services existants, vous devrez peut-être procéder à un redéploiement. Reportez-vous à la documentation spécifique du service dans Vue d’ensemble de l’aide sur la migration de zones de disponibilité pour les produits et services Microsoft Azure.
Étape 2 : Vérifier la disponibilité du produit et de la référence SKU dans la région Azure
Lors de cette étape, vous allez vérifier que les services et références SKU Azure requis sont disponibles dans les zones de disponibilité de votre région Azure sélectionnée.
Pour vérifier la prise en charge régionale des services, consultez Produits disponibles par région.
Pour répertorier les références SKU de machine virtuelle disponibles par zone et région Azure, consultez Vérifier la disponibilité des références SKU de machine virtuelle.
Si votre région ne prend pas en charge les services et références SKU requis par votre application, vous devez revenir à l’Étape 1 : Vérifier la disponibilité du produit dans la région Azure pour trouver une nouvelle région qui prend en charge les services et références SKU requis par votre application. Nous vous recommandons vivement de configurer votre charge de travail avec redondance interzone.
Pour la haute disponibilité zonale des machines virtuelles IaaS Azure, utilisez Virtual Machine Scale Sets (VMSS) Flex pour répartir les machines virtuelles entre plusieurs zones de disponibilité.
Étape 3 : Prendre en compte les exigences de votre application
Lors de cette dernière étape, vous allez déterminer, en fonction des exigences de l’application, quel type de prise en charge de zone de disponibilité convient le mieux à votre application.
Voici trois questions importantes qui vous aideront à choisir le déploiement de zone de disponibilité correct :
Votre application inclut-elle des composants sensibles à la latence ?
Les zones de disponibilité Azure au sein de la même région Azure sont connectées par un réseau hautes performances avec une latence aller-retour de moins de 2 ms.
L’approche recommandée pour atteindre la haute disponibilité, si la faible latence n’est pas une exigence stricte, consiste à configurer votre charge de travail avec un déploiement redondant interzone.
Pour les composants d’application critiques qui nécessitent une proximité physique et une faible latence, tels que le gaming, la simulation d’ingénierie et les transactions à hautes fréquences (HFT), nous vous recommandons de configurer un déploiement zonal. Virtual Machine Scale Sets Flex fournit un calcul aligné sur une zone, ainsi que des disques de stockage attachés.
Votre code d’application est-il prêt à gérer un modèle distribué ?
Pour un modèle de microservices distribués, et en fonction de votre application, il existe la possibilité d’échange de données entre les microservices d’une zone à une autre. Cet échange continu de données par le biais d’API peut affecter les performances. Pour améliorer les performances et maintenir une architecture fiable, vous pouvez choisir un déploiement zonal.
Avec un déploiement zonal, vous devez :
Identifiez les ressources ou services sensibles à la latence dans votre architecture.
Vérifiez que les ressources ou services sensibles à la latence prennent en charge le déploiement zonal.
Colocalisez les ressources ou services sensibles à la latence dans la même zone. D’autres services de votre architecture peuvent continuer à rester redondants interzone.
Répliquez les services zonaux sensibles à la latence sur plusieurs zones de disponibilité pour garantir la résilience de zone.
Équilibrez la charge entre les multiples déploiements zonaux avec des équilibreurs de charge standard ou globaux.
Si le service Azure prend en charge les zones de disponibilité, nous vous recommandons vivement d’utiliser la redondance de zone en répartissant les nœuds entre les zones pour obtenir un contrat SLA et une protection plus élevés contre les pannes zonales.
Pour une application à trois niveaux, il est important de comprendre les niveaux Application, Métier et Données, ainsi que leur état (avec état ou sans état) pour concevoir une architecture alignée avec les meilleures pratiques et conseils en fonction du type de charge de travail.
Pour les charges de travail spécialisées sur Azure comme dans les exemples ci-dessous, reportez-vous aux recommandations respectives relatives à l’architecture de la zone d’atterrissage et aux meilleures pratiques.
SAP
Azure Virtual Desktop
Azure Kubernetes Service
- Créer un cluster Azure Kubernetes Service (AKS) qui utilise des zones de disponibilité
- Considérations relatives à la gestion des opérations pour Azure Kubernetes Service
- Migrer des charges de travail de serveur flexible MySQL et Azure Kubernetes Service (AKS) vers la prise en charge de la zone de disponibilité
Oracle
Voulez-vous atteindre la continuité d’activité et reprise d’activité dans la même région Azure pour des raisons d’exigences de conformité, de résidence des données ou de gouvernance ?
Pour assurer la continuité d’activité et reprise d’activité dans la même région et lorsqu’il n’existe aucune paire régionale, nous vous recommandons vivement de configurer votre charge de travail avec redondance de zone. Une approche à une seule région s’applique également à certaines industries qui ont des exigences strictes en matière de résidence et de gouvernance des données dans la même région Azure. Pour savoir comment répliquer, basculer et restaurer automatiquement des machines virtuelles Azure d’une zone de disponibilité vers une autre dans la même région Azure, consultez Activer la récupération d’urgence des machines virtuelles Azure entre les zones de disponibilité.
Si vous avez besoin de plusieurs régions, ou si votre région Azure ne prend pas en charge les zones de disponibilité, nous vous recommandons d’utiliser des paires régionales. Les paires régionales sont situées à une distance d’environ 160 kilomètres, et vous offrent une protection de rayon d’explosion contre les défaillances régionales telles que les incendies, les inondations, les tremblements de terre et d’autres catastrophes naturelles ou imprévues. Pour plus d’informations, consultez Réplication inter-région dans Azure : continuité d’activité et reprise d’activité.
Remarque
Il peut y avoir des scénarios où une combinaison de services zonaux, redondants interzones et mondiaux fonctionne le mieux pour répondre aux exigences métier et techniques.
Autres éléments à prendre en considération
Pour en savoir plus sur le test de vos applications en matière de disponibilité et de résilience, consultez Test des applications pour la disponibilité et la résilience.
Chaque centre de données dans une région est affecté à une zone physique. Les zones physiques sont mappées à des zones logiques dans votre abonnement Azure. Ce mappage est automatiquement attribué aux abonnements Azure lors de leur création. Vous pouvez utiliser l’API REST ARM dédiée, listLocations, et définir la version de l’API sur 2022-12-01 pour répertorier le mappage de zone logique à zone physique pour votre abonnement. Ces informations sont importantes pour les composants d’application critiques qui nécessitent une colocalisation avec des ressources Azure classées en tant que services stratégiques qui peuvent ne pas être disponibles dans toutes les zones physiques.