Base de référence de migration de zone de disponibilité Azure
Cet article vous montre comment évaluer la préparation en zone de disponibilité de votre application aux fins de la migration de la zone de non-disponibilité vers la prise en charge des zones de disponibilité. Nous vous guiderons tout au long des étapes dont vous aurez besoin pour déterminer comment tirer parti de la prise en charge des zones de disponibilité conformément aux exigences de votre application et régionales. Pour plus d’informations sur les zones de disponibilité et les régions qui les prennent en charge, consultez Que sont les régions azure et les zones de disponibilité.
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, 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.
En plus des deux options de zone de disponibilité, zonale et redondante interzone, Azure propose des services globaux, ce qui signifie qu’ils sont disponibles globalement, 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.
Notes
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 à la zone et peuvent tomber en panne 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 possibles de créer une application Azure fiable avec des zones de disponibilité qui répondent à la fois aux contrats SLA et aux objectifs de fiabilité. Suivez les étapes ci-dessous pour choisir l’approche 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é
Dans cette première étape, vous devez vérifier que la 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 d’Azure Resource Mover pour migrer vers une région qui offre une prise en charge des zones de disponibilité.
Notes
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 redéployer. Reportez-vous à la documentation spécifique au service dans Vue d’ensemble des instructions de migration des 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
Dans cette étape, vous allez vérifier que les services Et références SKU Azure requis sont disponibles dans les zones de disponibilité de la région Azure sélectionnée.
Pour case activée 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 région et zone Azure, consultez Vérifier la disponibilité de la référence SKU de machine virtuelle.
Si votre région ne prend pas en charge les services et références SKU dont votre application a besoin, vous devez revenir à l’étape 1 : Vérifier la disponibilité du produit dans la région Azure pour trouver une nouvelle région prenant en charge les services et références SKU dont votre application a besoin. Nous vous recommandons vivement de configurer votre charge de travail avec la redondance de zone.
Pour une haute disponibilité zonale des Machines Virtuelles Azure IaaS, utilisez Virtual Machine Scale Sets (VMSS) Flex pour répartir des machines virtuelles entre plusieurs zones de disponibilité.
Étape 3 : Prendre en compte les exigences de votre application
Dans cette dernière étape, vous allez déterminer, en fonction des exigences de l’application, le type de prise en charge de zone de disponibilité le plus adapté à votre application.
Voici trois questions importantes qui vous aideront à choisir le bon déploiement de zone de disponibilité :
Votre application inclut-elle des composants sensibles à la latence ?
Les zones de disponibilité Azure dans la même région Azure sont connectées par un réseau hautes performances avec une latence aller-retour inférieure à 2 ms.
L’approche recommandée pour atteindre la haute disponibilité, si une 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 les jeux, la simulation d’ingénierie et le trading à haute fréquence (HFT), nous vous recommandons de configurer un déploiement zonnal. Virtual Machine Scale Sets Flex fournit un calcul aligné sur la 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’un échange de données continu entre les microservices entre les zones. Cet échange de données continu via des API peut affecter les performances. Pour améliorer les performances et maintenir une architecture fiable, vous pouvez choisir un déploiement zonnal.
Avec un déploiement zonnal, 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 zonnal.
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 des zones.
Équilibrez la charge entre les déploiements zonaux multiples 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 afin d’obtenir un contrat SLA de durée de fonctionnement plus élevé et une protection 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 l’architecture en alignement avec les meilleures pratiques et les conseils en fonction du type de charge de travail.
Pour les charges de travail spécialisées sur Azure, comme exemple ci-dessous, reportez-vous aux conseils et bonnes pratiques en matière d’architecture de zone d’atterrissage respectifs.
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 assurer la continuité d’activité et la reprise d’activité dans la même région Azure en raison des exigences de conformité, de résidence des données ou de gouvernance ?
Pour assurer la continuité d’activité et la reprise d’activité au sein de la même région et en l’absence de paire régionale, nous vous recommandons vivement de configurer votre charge de travail avec la redondance de zone. Une approche à région unique s’applique également à certains secteurs 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é à une autre au sein de la même région Azure, consultez Activer la récupération d’urgence de machine virtuelle 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 éloignée d’environ 100 milles, et vous offrent une protection de rayon d’explosion contre les défaillances au niveau régional 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é.
Notes
Il peut y avoir des scénarios où une combinaison de services zonaux, redondants interzones et globaux 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 la disponibilité et de la résilience de vos applications, consultez Test des applications pour la disponibilité et la résilience.
Chaque centre de données d’une région est affecté à une zone physique. Les zones physiques sont mappées aux zones logiques de 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 à la 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 comme des services stratégiques qui peuvent ne pas être disponibles dans toutes les zones physiques.
Des frais de bande passante interzone s’appliquent lorsque le trafic se déplace d’une zone à l’autre. Pour en savoir plus sur la tarification de la bande passante, consultez Tarification de la bande passante.