Partager via


Activer la résilience de zone pour les charges de travail Azure

Pour rendre vos applications plus résilientes aux défaillances matérielles liées aux zones, aux interruptions réseau et aux catastrophes naturelles, il est important de concevoir vos charges de travail Azure pour la résilience de zone. Lorsque vous distribuez des ressources entre plusieurs zones de disponibilité au sein d’une région, vous réduisez le risque d’une panne de zone unique affectant les services critiques.

Bien qu’il soit recommandé d’aborder la résilience de zone pendant la planification et le déploiement initiaux des charges de travail, il est courant de convertir les charges de travail non résilientes existantes en configurations résilientes de zone. En général, le traitement de l’activation de la résilience de zone pour les charges de travail existantes est simple et Microsoft continue de simplifier le processus. Toutefois, toute modification apportée à votre charge de travail peut entraîner un risque. Une fois que vous comprenez les risques impliqués, vous pourrez ensuite évaluer et hiérarchiser les charges de travail et services au sein de ces charges de travail sont les plus vitales pour votre entreprise, puis appliquer la résilience de zone aux ressources les plus impactantes en premier.

Cet article décrit les principales considérations relatives à l’activation de la résilience de zone dans vos charges de travail Azure. Il vous aide également à planifier et à implémenter une transition réussie vers une architecture plus résiliente.

Conseil / Astuce

Si vous êtes actuellement en train de concevoir vos charges de travail ou de planifier une révision de conception de vos charges de travail actuelles, il est important de suivre les recommandations de conception pour la conception de la redondance dans Azure Well-Architected Framework (WAF). Le guide des recommandations waf vous aide à concevoir la redondance des charges de travail à plusieurs niveaux, avec un focus sur les flux de travail critiques. Pour prendre en charge l’adoption de la zone de disponibilité, elle présente également des stratégies telles que les déploiements multirégions et les tampons de déploiement.

Qu’est-ce que la résilience de zone ?

Les services Azure peuvent être résilients aux pannes de zone de disponibilité de deux manières principales :

  • Services redondants interzone : De nombreux services Azure prennent en charge la redondance de zone. Ces services répliquent automatiquement les données entre les zones de disponibilité, distribuent les requêtes entrantes et basculent vers différentes zones lors d’une défaillance de zone. Chaque service prend en charge ces fonctionnalités de manière logique pour ce service spécifique. Certains services sont redondants interzone par défaut, tandis que d’autres services peuvent avoir besoin de configurer la redondance de zone.

  • Services zonaux : Certains services Azure sont zonaux, ce qui signifie qu’ils peuvent être épinglés à une zone de disponibilité spécifique. Pour obtenir une résilience de zone à l’aide d’un service zonal, déployez des instances distinctes du service dans plusieurs zones de disponibilité. Vous devrez peut-être également gérer la distribution du trafic, la réplication des données et le basculement entre les instances.

Certains services peuvent être déployés dans une configuration redondante interzone ou zonale. Dans la plupart des cas, il est préférable de déployer des services redondants interzone lorsque vous le pouvez.

Pour plus d’informations, consultez Types de prise en charge des zones de disponibilité.

Procédure d’activation de zone

Utilisez les étapes suivantes pour examiner systématiquement vos charges de travail Azure, les hiérarchiser pour la résilience de zone et activer la résilience de zone sur chaque composant.

Prerequisites

Avant de commencer, effectuez les étapes suivantes :

  • Identifiez chaque charge de travail. Une charge de travail fait référence à une collection de ressources d’application, de données et d’infrastructure de prise en charge qui fonctionnent ensemble pour obtenir des résultats métier définis. Pour en savoir plus sur les charges de travail et leur définition, consultez Charges de travail Azure Well-Architected Framework.

  • Hiérarchiser les flux utilisateur et système de chaque charge de travail. Comprenez les chemins critiques et les dépendances de vos charges de travail pour déterminer quels composants rendre résilients dans chaque zone en priorité. Pour plus d’informations sur l’utilisation de l’analyse de flux critique pour hiérarchiser les flux de travail, consultez Hiérarchiser les charges de travail pour la résilience de zone.

  • Attribuez une évaluation de la criticité à chaque charge de travail et flux. Cette évaluation vous aide à comprendre l’impact d’une panne potentielle sur votre entreprise et guide vos décisions sur les charges de travail à hiérarchiser pour la résilience de zone. Considérez également la quantité de temps d’arrêt acceptable pendant que vous reconfigurez les charges de travail.

    Vous pouvez utiliser une taxonomie pour classifier vos charges de travail en fonction de leur criticité. Cette approche vous aide à concentrer vos efforts sur les services les plus importants.

    Considérez l’exemple de taxonomie suivant pour classifier vos charges de travail.

    Type de charge de travail Descriptif Effet de l’interruption
    Intégration stratégique Flux critiques et charges de travail qui doivent être hautement fiables, toujours disponibles, résilients aux défaillances et opérationnels Toute perturbation des fonctions essentielles risque immédiatement des dommages catastrophiques à l’entreprise ou introduit des risques pour la vie humaine.
    Vital pour l’entreprise Flux et charges de travail essentiels qui exploitent des fonctions métier importantes L’interruption risque une perte financière ou des dommages de marque.
    Opérationnel pour l’entreprise Contribue à l’efficacité des opérations commerciales, mais hors ligne de service directe aux clients Peut tolérer un certain niveau de perturbation.
    Administratif Flux de production internes et charges de travail non alignés sur les opérations métier Peut tolérer des perturbations.

    Pour plus d’informations sur la classification de vos charges de travail en fonction de l’évaluation de la criticité, consultez Affecter une évaluation de criticité à chaque flux.

  • Vérifiez que les régions où résident vos ressources Azure prennent en charge les zones de disponibilité. Consultez la liste des régions Azure. Si une région ne prend pas en charge les zones de disponibilité, envisagez de déplacer vos ressources vers une région qui le fait. Pour plus d’informations, consultez Déplacer des ressources Azure entre des groupes de ressources, des abonnements ou des régions.

Étape 1 : Hiérarchiser les services Azure pour la résilience de zone

Maintenant que vous comprenez les flux de charge de travail les plus critiques pour votre entreprise, vous pouvez vous concentrer sur les services Azure dont dépendent ces flux. Certains services Azure sont plus critiques pour vos applications que d’autres. Hiérarchiser ces services pour vous assurer que vos applications restent disponibles et résilientes si une défaillance de zone se produit.

Utilisez les conseils suivants pour hiérarchiser les groupes de services Azure en fonction de leur criticité pour vos charges de travail. Prenez en compte votre architecture d’application et vos exigences métier spécifiques lorsque vous déterminez la priorité des services pour la résilience de zone.

  1. Commencez par les services de mise en réseau. Les charges de travail ont tendance à partager des services réseau, de sorte qu’une augmentation de la résilience de ces services peut améliorer la résilience de plusieurs charges de travail en même temps.

    De nombreux services de mise en réseau de base sont automatiquement redondants interzone, mais vous devez vous concentrer sur les composants tels que les passerelles Azure ExpressRoute, la passerelle VPN Azure, Azure Application Gateway, Azure Load Balancer et le Pare-feu Azure.

  2. Améliorez la résilience du stockage des données opérationnelles. Les magasins de données opérationnels contiennent des données précieuses que plusieurs charges de travail utilisent souvent, ce qui permet d’améliorer la disponibilité de ces magasins de données.

    Pour une résilience de stockage de données opérationnelle, concentrez-vous sur les services tels qu’Azure SQL Database, Azure SQL Managed Instance, Stockage Azure, Azure Data Lake Storage, Azure Cosmos DB, Serveur flexible Azure PostgreSQL, Serveur flexible Azure MySQL et Azure Cache pour Redis.

  3. Hiérarchiser les services de calcul. Ces services sont souvent faciles à répliquer et à distribuer entre les zones, car ils sont sans état.

    Les services de calcul incluent des machines virtuelles Azure, des groupes de machines virtuelles Azure, Azure Kubernetes Service (AKS), Azure App Service, App Service Environment, Azure Functions, Azure Service Fabric et Azure Container Apps.

  4. Passez en revue les ressources restantes critiques que vos flux critiques utilisent. Ces ressources peuvent ne pas être aussi critiques que les ressources répertoriées précédemment, mais elles jouent toujours un rôle dans les fonctionnalités de votre application, et vous devez les prendre en compte pour la résilience de zone.

  5. Passez en revue le reste de vos ressources opérationnelles. Prenez des décisions éclairées concernant la résilience des systèmes en fonction des zones. Cette révision inclut les services qui peuvent ne pas être directement liés à vos charges de travail critiques, mais qui contribuent toujours à la fiabilité et aux performances globales des applications.

Étape 2 : Évaluer les approches de configuration de zone

Après avoir hiérarchisé vos charges de travail et vos services Azure, identifiez l’approche requise pour activer la prise en charge des zones de disponibilité pour chaque service et comprenez ce que vous devez faire pour configurer la résilience de zone.

Chaque guide de service de fiabilité Azure fournit une section qui décrit comment activer la résilience de zone pour ce service. Cette section vous aide à comprendre l’effort nécessaire pour rendre chaque zone de service résiliente afin que vous puissiez planifier votre stratégie en conséquence. Pour plus d’informations sur un service spécifique, consultez les Guides de service de fiabilité Azure.

Utilisez la table de configuration de zone pour comprendre rapidement les approches des services Azure courants.

Important

Si votre charge de travail inclut des composants déployés dans une configuration zonale (ou à zone unique), envisagez de rendre ces composants résilients aux pannes de zone. Une approche courante consiste à déployer des instances distinctes dans une autre zone de disponibilité et à basculer entre elles si nécessaire.

Étape 3 : Tester la latence

Lorsque vous rendez la zone des charges de travail résiliente, envisagez la latence entre les zones de disponibilité. Parfois, certains systèmes hérités ne peuvent pas tolérer la faible latence supplémentaire introduite par le trafic interzone, en particulier lorsque vous activez la réplication synchrone au sein du niveau données. Si vous pensez que la latence interzone peut affecter votre charge de travail, exécutez des tests avant et après avoir activé la résilience de zone. Pour plus d’informations sur la façon dont la latence interzone peut affecter votre application et les approches permettant d’atténuer les problèmes de latence interzone, consultez les ressources zonales et la résilience de zone.

Approches de configuration de zone pour les services Azure

Chaque service Azure prend en charge un type spécifique de prise en charge de zone de disponibilité, qui est basé sur l’utilisation prévue du service et l’architecture interne. Si vous disposez d’une ressource qui n’est pas configurée pour utiliser des zones de disponibilité (ou une ressource nonzonale ), vous souhaiterez peut-être la reconfigurer avec la prise en charge des zones de disponibilité. Le guide de fiabilité de ce service fournit des conseils ou des liens vers des instructions de configuration de zone de disponibilité.

Cette section fournit une vue d’ensemble des différents types d’approches de configuration de zone et de l’approche prise en charge par chaque service.

Important

Lorsque vous activez la redondance de zone sur une ressource, cette ressource devient automatiquement résiliente aux défaillances de zone. Lorsque vous utilisez une configuration zonale pour épingler la ressource à une zone de disponibilité spécifique, la ressource n’est pas automatiquement redondante interzone. Vous devez la rendre résiliente à une défaillance de zone. Pour les services zonaux, cet article reflète la complexité et le coût de l’épinglage à une zone. Pour plus d’informations sur les étapes supplémentaires permettant d’obtenir une résilience de zone, consultez le guide de fiabilité du service.

La table de configuration de zone indique l’approche de configuration de zone prise en charge pour de nombreux services Azure, et contient un lien vers chaque guide de fiabilité pour ce service. Le guide de fiabilité fournit des informations sur la configuration des ressources de service nonzonales pour activer la prise en charge des zones de disponibilité.

Le tableau suivant décrit chaque approche de configuration de zone, y compris le niveau d’effort et le temps d’arrêt requis pour activer les zones de disponibilité.

Approche Descriptif Niveau d’effort typique Peut nécessiter un temps d’arrêt
Toujours résilient aux zones Le service est résilient par défaut dans les régions qui prennent en charge les zones de disponibilité. Aucune action n’est requise. Aucun Non
Activation Modifications de configuration minimales requises, telles que l’activation de la redondance de zone dans les paramètres. Le processus n’affecte pas la disponibilité, mais envisagez des effets sur les coûts ou les performances. Low Non
Modification Nécessite probablement des modifications de configuration, telles que le redéploiement des ressources dépendantes ou la modification des paramètres réseau. Moyen Oui
Redéploiement Des modifications importantes requises, telles que le redéploiement de ressources entières, d’applications ou de services, ou la migration de données vers de nouveaux services. High Oui

Comprendre le coût de l’activation du support des zones de disponibilité pour un service. Pour de nombreux services, l’activation des zones de disponibilité n’ajoute pas de coût. Toutefois, certains services nécessitent un niveau spécifique, un nombre spécifique d’unités de capacité, ou les deux. D’autres services facturent des tarifs différents lorsque vous utilisez des zones de disponibilité. Le tableau de la section suivante répertorie l’impact classique sur les coûts pour chaque service.

Note

Les informations contenues dans cet article résument l’approche classique permettant d’activer la prise en charge des zones de disponibilité et décrivent l’impact typique sur les coûts. Toutefois, certains facteurs peuvent affecter le fonctionnement de votre solution spécifique. Par exemple, certains services sont répertoriés comme toujours résilients à la zone, mais cette désignation s’applique uniquement dans des régions spécifiques ou pour des niveaux spécifiques du service. Utilisez ces tables comme point de départ, mais passez en revue les autres ressources mentionnées pour comprendre les détails spécifiques.

Approche de configuration des services Azure par zone

Le tableau suivant récapitule la prise en charge des zones de disponibilité pour de nombreux services Azure et fournit une approche, y compris l’impact sur les coûts, afin d’activer la prise en charge des zones de disponibilité pour chaque service.

Service Peut être redondant interzone Peut être zonal Approche de configuration de zone classique Impact classique sur les coûts
Recherche d’IA Azure Yes Toujours résilient aux zones N/A
Gestion des API Azure Yes Yes Modification Niveau minimal requis
Configuration d'application Azure Yes Toujours résilient aux zones N/A
Azure App Service Yes Activation Nombre minimal de niveaux et d’instances requis
Azure App Service - App Service Environment Yes Activation Nombre minimal d’instances requis
Application Gateway Azure Yes Yes Toujours résilient aux zones N/A
Sauvegarde Azure Yes Redéploiement Augmentation modérée des coûts
Azure Bastion Yes Yes Redéploiement Aucun impact sur les coûts
Azure Batch Yes Redéploiement Aucun impact sur les coûts pour le même nombre de machines virtuelles
Stockage Blob Azure Yes Activation Augmentation modérée des coûts
Cache Azure pour Redis – Entreprise Yes Redéploiement Aucun impact sur les coûts
Cache Azure pour Redis – Standard et Premium Yes Activation Niveau minimal requis
Azure Container Apps Yes Redéploiement Nombre minimal de réplicas requis
Azure Container Instances Yes Redéploiement Aucun impact sur les coûts
Azure Container Registry Yes Toujours résilient aux zones N/A
Azure Cosmos DB pour NoSQL Yes Modification Aucun si vous utilisez la mise à l’échelle automatique ou les écritures multirégions
Azure Data Factory. Yes Toujours résilient aux zones N/A
Azure Data Lake Storage Yes Activation Augmentation modérée des coûts
Serveurs flexibles Azure Database pour MySQL Yes Redéploiement Nécessite une instance principale et à haute disponibilité.
Azure Database pour PostgreSQL - Serveur flexible Yes Activation Nécessite une instance principale et une instance de haute disponibilité
Azure Databricks Yes Activation Aucun impact sur les coûts pour le même nombre de machines virtuelles ; augmentation modérée des coûts pour le stockage
Stockage sur disque Azure (disques managés) Yes Yes Activation Augmentation modérée des coûts
SAN élastique Azure Yes Redéploiement Augmentation modérée des coûts
Azure Event Hubs : niveau dédié Yes Toujours résilient aux zones Unités de capacité minimales requises
Azure Event Hubs : tous les autres niveaux Yes Toujours résilient aux zones N/A
Passerelle Azure ExpressRoute Yes Yes Modification Dépend du niveau
Azure Files Yes Activation Augmentation modérée des coûts
Pare-feu Azure Yes Yes Modification Aucun impact sur les coûts
Azure Functions Yes Redéploiement Nombre minimal de niveaux et d’instances requis
Azure HDInsight Yes Redéploiement Aucun impact sur les coûts pour le même nombre de nœuds
Azure IoT Hub Yes Toujours résilient aux zones N/A
Azure Key Vault Yes Toujours résilient aux zones N/A
Azure Kubernetes Service (AKS) Yes Redéploiement Aucun impact sur les coûts
Équilibrage de charge Azure Yes Yes Modification Aucun impact sur les coûts
Azure Logic Apps – Niveau Consommation Yes Toujours résilient aux zones N/A
Azure Logic Apps – Niveau Standard Yes Redéploiement Nombre minimal de niveaux et d’instances requis
Grafana géré par Azure Yes Redeploy Augmentation modérée des coûts
Azure Monitor : Log Analytics Yes Toujours résilient aux zones
Azure NetApp Files Yes Redéploiement Dépend de la configuration de la réplication
Stockage de files d'attente Azure Yes Activation Augmentation modérée des coûts
Azure Service Bus Yes Toujours résilient aux zones N/A
Azure Service Fabric Yes Yes Redéploiement Aucun impact sur les coûts pour le même nombre de machines virtuelles
Azure Site Recovery Yes Redéploiement Aucun impact sur les coûts pour Site Recovery, augmentation modérée des coûts pour le stockage de réplique
Azure SQL Database : niveau Critique pour l’entreprise Yes Activation Aucun impact sur les coûts
Azure SQL Database : niveau Usage général Yes Activation Augmentation modérée des coûts
Azure SQL Database – niveau Hyperscale Yes Redéploiement Nombre minimal de réplicas requis
Azure SQL Database : niveau Premium Yes Activation Aucun impact sur les coûts
Azure SQL Managed Instance Yes Activation Augmentation modérée des coûts
Stockage de tables Azure Yes Activation Augmentation modérée des coûts
Groupes de machines virtuelles identiques Azure Yes Yes Redéploiement Aucun impact sur les coûts pour le même nombre de machines virtuelles
Machines virtuelles Azure Yes Redéploiement Aucun impact sur les coûts pour le même nombre de machines virtuelles
Réseau virtuel Azure Yes Toujours résilient aux zones N/A
Adresse IP publique Yes Yes Toujours résilient aux zones N/A