Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :
| RE :05 | Ajoutez une redondance à différents niveaux, en particulier pour les flux critiques, afin de répondre à vos objectifs de fiabilité. Envisagez les composants d’infrastructure redondants tels que le calcul et le réseau, ainsi que plusieurs instances de votre solution. |
|---|
Ce guide décrit les recommandations relatives à l’ajout de redondance tout au long des flux critiques sur différentes couches de charge de travail, ce qui optimise la résilience. Répondez aux exigences de vos cibles de fiabilité définies en appliquant les niveaux de redondance appropriés à vos niveaux de calcul, de données, de mise en réseau et d’autres niveaux d’infrastructure. Appliquez cette redondance pour donner à votre charge de travail une base solide et fiable pour vous appuyer. Lorsque vous générez votre charge de travail sans redondance d’infrastructure, il existe un risque élevé de temps d’arrêt prolongé en raison de défaillances potentielles.
Définitions
| Terme | Definition |
|---|---|
| Redundancy | Implémentation de plusieurs instances identiques d’un composant de charge de travail. |
| Région | Emplacement d’un centre de données Azure. |
| Persistance polyglotte | Concept d’utilisation de technologies de stockage différentes par la même application ou solution pour tirer parti des meilleures fonctionnalités de chaque composant. |
| Cohérence des données | La mesure de la synchronisation ou de l’expiration de la synchronisation d’un jeu de données donné se trouve dans plusieurs magasins. |
| Partitioning | Processus de division physique des données en magasins de données distincts. |
| Tesson | Stratégie de partitionnement de base de données horizontale qui prend en charge plusieurs instances de stockage avec un schéma commun. Les données ne sont pas répliquées dans toutes les instances. |
Dans le contexte de la fiabilité, utilisez la redondance pour contenir des problèmes qui affectent une seule ressource et assurez-vous que ces problèmes n’affectent pas la fiabilité de l’ensemble du système. Utilisez les informations que vous avez identifiées sur vos flux critiques et cibles de fiabilité pour prendre des décisions éclairées requises pour la redondance de chaque flux.
Par exemple, vous pouvez avoir plusieurs nœuds de serveur web qui s’exécutent simultanément. Si le flux qu’ils prennent en charge est critique, tous les nœuds peuvent avoir besoin de réplicas qui peuvent accepter le trafic immédiatement si un problème affecte l’ensemble du pool, tel qu’une panne complète du centre de données. Sinon, étant donné que les problèmes à grande échelle sont rares et qu’il est coûteux de déployer un ensemble entier de réplicas, vous pouvez déployer un nombre limité de réplicas afin que le flux fonctionne dans un état détérioré jusqu’à ce que vous résolvez le problème.
Lorsque vous concevez une redondance dans le contexte de l’efficacité des performances, distribuez la charge sur plusieurs nœuds redondants pour vous assurer que chaque nœud fonctionne de manière optimale. Dans le contexte de la fiabilité, créez une capacité de rechange pour absorber les défaillances ou les dysfonctionnements qui affectent un ou plusieurs nœuds. Assurez-vous que la capacité de rechange peut absorber les défaillances pendant toute la durée nécessaire à la récupération des nœuds affectés. Avec cette distinction à l’esprit, les deux stratégies doivent travailler ensemble. Si vous répartissez le trafic sur deux nœuds pour les performances et qu’ils s’exécutent à 60% utilisation et qu’un nœud échoue, votre nœud restant risque de devenir submergé, car il ne peut pas fonctionner à 120%. Répartissez la charge avec un autre nœud pour vous assurer que vos cibles de performances et de fiabilité sont respectées.
Compromis :
Une redondance accrue de la charge de travail équivaut à plus de coûts. Envisagez soigneusement d’ajouter la redondance et de passer régulièrement en revue votre architecture pour vous assurer que vous gérez les coûts, en particulier lorsque vous utilisez le surprovisionnement. Lorsque vous utilisez le surprovisionnement comme stratégie de résilience, équilibrez-le avec une stratégie de mise à l’échelle bien définie pour réduire les inefficacités des coûts.
Il peut y avoir des compromis sur les performances lorsque vous créez un degré élevé de redondance. Par exemple, les ressources réparties entre des zones de disponibilité ou des emplacements peuvent affecter les performances, car vous devez envoyer du trafic via des connexions à latence élevée entre des ressources redondantes, telles que des serveurs web ou des instances de base de données.
Différents flux au sein de la même charge de travail peuvent avoir des exigences de fiabilité différentes. Les conceptions de redondance spécifiques aux flux peuvent potentiellement introduire une complexité dans la conception globale.
Une conception de redondance à faible latence signifie que vous acceptez le risque de perdre ces composants en cas d’événement à grande échelle, comme une catastrophe géographique, qui met toutes les instances hors connexion. Un environnement de récupération d’urgence géo-distante permet d’atténuer ce risque, mais augmente les coûts.
Préférer les services serverless et entièrement managés pour réduire la charge opérationnelle
Tirez parti des solutions SaaS ( Serverless, Software as a Service) et PaaS (Platform as a Service) pour ajouter facilement la redondance à votre charge de travail sans avoir à gérer les opérations de réplication ou de basculement des données. Ces services implémentent la redondance de manière transparente, ce qui supprime le fardeau opérationnel de la conception et de la maintenance de vos propres mécanismes de redondance. Lorsque vous évaluez les options de service, hiérarchiser les services managés qui gèrent automatiquement la redondance par rapport aux approches basées sur l’infrastructure qui nécessitent une configuration de redondance manuelle.
Les services managés Azure fournissent une redondance via différents modèles. Chaque modèle fournit différents niveaux d’abstraction et de simplicité opérationnelle.
Services globaux avec redondance intégrée : Les services tels que Microsoft Entra ID, Azure DNS et Azure Key Vault fonctionnent en tant que services globaux avec redondance automatique entre plusieurs régions. Ces services offrent une résilience inhérente sans nécessiter de configuration de redondance à partir de vous. Ils gèrent automatiquement les scénarios de basculement et de récupération de manière transparente.
Modèles de capacité abstraits : Les offres telles qu’Azure Cosmos DB, Azure Databricks et les points de terminaison managés Azure OpenAI résument la complexité de l’infrastructure sous-jacente derrière les unités de capacité, les DTU ou d’autres métriques logiques. Ces services distribuent automatiquement votre charge de travail entre plusieurs instances, zones et régions tout en présentant un modèle de facturation et de gestion simplifié. Vous spécifiez des exigences de capacité au lieu de gérer des instances redondantes individuelles.
Lorsque vous concevez votre solution, évaluez si une option de service managé existe pour chaque composant avant d’implémenter la redondance basée sur l’infrastructure. Les services managés réduisent votre surcharge opérationnelle et fournissent souvent des implémentations de redondance plus robustes que des solutions personnalisées, bien qu’ils peuvent impliquer des compromis dans le contrôle et des coûts potentiellement plus élevés pour chaque unité de capacité.
Générer une redondance dans votre charge de travail avec plusieurs instances de composant
Déployez plusieurs instances de vos composants et services d’infrastructure pour obtenir la résilience dont votre charge de travail a besoin. Cette stratégie de redondance fondamentale garantit qu’en cas d’échec d’une instance, d’autres instances peuvent continuer à gérer la charge de travail. Vous pouvez obtenir plusieurs instances à l’aide de différentes approches. Certains scénarios vous obligent à configurer manuellement la redondance en déployant plusieurs ressources individuellement, telles que plusieurs circuits Azure ExpressRoute ou la configuration d’Azure Traffic Manager dans plusieurs régions. D’autres services sont conçus pour prendre en charge plusieurs instances directement, tels que la définition de groupes de machines virtuelles identiques Azure sur cinq instances ou la configuration d’Azure App Service pour exécuter 10 instances. Si possible, préférez les services qui fournissent une prise en charge intégrée de plusieurs instances et fonctionnalités de mise à l’échelle automatique, car ils simplifient la gestion de la redondance et peuvent répondre aux besoins de fiabilité et de performances.
Lorsque vous déployez des composants d’infrastructure redondants, déterminez le nombre d’instances de chaque composant qui répondent à vos objectifs de fiabilité. Déterminez si vous avez besoin de plusieurs instances de tous les composants ou uniquement de composants critiques spécifiques et déterminez la distribution géographique de ces instances pour répondre à vos besoins de résilience. Lorsque vous déployez une infrastructure redondante, tenez compte des recommandations suivantes.
Ressources de calcul :
Préférez les services qui prennent en charge la redondance intégrée. Ces services vous permettent de spécifier le nombre d’instances dont vous avez besoin et peuvent gérer la distribution et la gestion de ces instances pour vous.
Conservez votre couche de calcul propre à n’importe quel état , car des nœuds individuels qui servent des requêtes peuvent être supprimés, défectueux ou remplacés à tout moment.
Concevez et testez votre stratégie de mise à l’échelle pour qu’elle corresponde à votre approche de redondance.
Ressources de données :
Répliquez des données entre les régions géographiques pour assurer la résilience aux pannes régionales et aux défaillances catastrophiques.
Comprendre les fonctionnalités intégrées de réplication et de redondance des services de plateforme avec état que vous utilisez.
Déterminez si la réplication des données synchrones ou asynchrones est nécessaire pour les fonctionnalités de votre charge de travail. Pour plus d'informations, consultez Recommandations pour l'utilisation des zones de disponibilité et des régions.
Distribuez les données géographiquement, comme pris en charge par votre service, pour réduire l’effet des défaillances localisées géographiquement.
Automatisez le basculement après un échec d’instance de base de données. Vous pouvez configurer le basculement automatisé dans plusieurs services de données PaaS Azure. Le basculement automatisé n’est pas nécessaire pour les magasins de données qui prennent en charge les écritures multirégions, comme Azure Cosmos DB. Pour plus d’informations, consultez Recommandations pour la conception d’une stratégie de récupération d’urgence.
Utilisez le meilleur magasin de données pour vos données. Adoptez la persistance polyglotte ou les solutions qui utilisent une combinaison de technologies de magasin de données. Les données incluent plus que les données d’application persistantes. Il inclut également les journaux d’application, les événements, les messages et les caches.
Prenez en compte les exigences de cohérence des données et utilisez la cohérence éventuelle lorsque les exigences l’autorisent. Lorsque les données sont distribuées, utilisez une coordination appropriée pour appliquer des garanties de cohérence fortes. La coordination peut réduire votre débit et rendre vos systèmes étroitement couplés, ce qui peut les rendre plus faibles. Par exemple, si une opération met à jour deux bases de données, au lieu de la placer dans une seule étendue de transaction, il est préférable si le système peut prendre en charge la cohérence éventuelle.
Partitionner les données pour la disponibilité. Le partitionnement de base de données améliore l’extensibilité et peut également améliorer la disponibilité. Si une partition tombe en panne, les autres partitions sont toujours accessibles. Une défaillance d’une partition n’interrompt qu’un sous-ensemble des transactions totales.
Si le partitionnement n’est pas une option, vous pouvez utiliser le modèle de séparation de responsabilité des requêtes de commande (CQRS) pour séparer vos modèles de données en lecture-écriture et en lecture seule. Ajoutez des instances de base de données en lecture seule redondantes pour renforcer la résilience.
Ressources réseau :
Choisissez une topologie de réseau fiable et évolutive. Utilisez un modèle hub-and-spoke ou un modèle Azure Virtual WAN pour vous aider à organiser votre infrastructure cloud en modèles logiques qui facilitent la création et la mise à l’échelle de votre conception de redondance.
Sélectionnez le service réseau approprié pour équilibrer et rediriger les demandes dans ou entre les régions. Utilisez des services d’équilibrage de charge globaux ou redondants interzone lorsque cela est possible pour répondre à vos objectifs de fiabilité.
Vérifiez que vous avez alloué suffisamment d’espace d’adressage IP dans vos réseaux virtuels et sous-réseaux pour prendre en compte l’utilisation planifiée, y compris les exigences de scale-out.
Vérifiez que l’application peut être mise à l’échelle dans les limites de port de la plateforme d’hébergement d’application choisie. Si une application lance plusieurs connexions TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol), il peut épuiser tous les ports disponibles et entraîner des performances d’application médiocres.
Choisissez des références SKU et configurez des services réseau qui peuvent répondre à vos besoins en bande passante et en disponibilité. Le débit d’une passerelle VPN varie en fonction de leur référence SKU. La prise en charge de la redondance de zone n’est disponible que pour certaines références SKU de l’équilibreur de charge.
Assurez-vous que votre conception pour la gestion du système DNS (Domain Name System) est basée sur la résilience et prend en charge l’infrastructure redondante.
Utilisez le modèle Tampons de déploiement pour simplifier votre approche de redondance
Au-delà de la redondance pour les composants et services d’infrastructure individuels, étendez votre stratégie de redondance au niveau de la charge de travail en déployant plusieurs instances de votre charge de travail entière ou des groupes logiques de ressources. Suivez le modèle de conception Tampons de déploiement pour créer des unités reproductibles autonomes qui incluent toutes les ressources requises pour fournir votre charge de travail à un sous-ensemble spécifique d’utilisateurs ou d’exigences.
Les tampons de déploiement représentent un passage du niveau composant à la redondance au niveau de la charge de travail. Chaque tampon sert d’unité complète de mise à l’échelle contenant toutes les ressources nécessaires ( calcul, stockage, mise en réseau et dépendances) qui peuvent fonctionner indépendamment. Cette approche offre des avantages clés, notamment les domaines d’échec isolés qui contiennent un rayon d’explosion, une mise à l’échelle horizontale via un déploiement d’empreinte supplémentaire au lieu d’une mise à l’échelle de composants individuelle, une segmentation flexible par zone géographique ou requise, et des opérations simplifiées via des unités reproductibles identiques.
Que vous déployiez des tampons dans un modèle actif-actif (où tous les tampons servent activement le trafic simultanément) ou un modèle actif-passif (où un tampon sert le trafic tandis que d’autres restent en veille), concevez chaque empreinte pour être un déploiement complet et autonome qui peut gérer sa charge de travail désignée indépendamment.
Atteindre un temps d’arrêt zéro par le biais d’une redondance active/active
Les déploiements actifs optimisent la disponibilité du service en exécutant plusieurs instances d’une charge de travail simultanément, chacune gérant activement le trafic. Cette configuration garantit un basculement immédiat, élimine les temps d’arrêt et optimise l’utilisation des ressources en gardant toutes les instances productives. En cas d’échec d’une instance, le trafic est automatiquement redirigé vers des instances saines sans interrompre le service.
Par exemple, une plateforme de commerce électronique pendant la saison de pointe peut maintenir des opérations transparentes même si un déploiement rencontre des problèmes. Les configurations actives sont idéales pour les charges de travail critiques qui nécessitent une disponibilité ininterrompue, mais elles ont des coûts d’infrastructure et une complexité plus élevés. Des stratégies opérationnelles avancées sont nécessaires pour gérer plusieurs environnements en direct, garantir la cohérence des données et coordonner les mises à jour sur toutes les instances.
Les sections suivantes décrivent les options de configuration pour les déploiements actifs et actifs.
Actif au niveau de la capacité : Tampons de déploiement mis en miroir dans deux emplacements ou plus, chacun configuré pour gérer les charges de travail de production pour l’emplacement ou les emplacements qu’ils servent et scalables pour gérer les charges à partir d’autres emplacements si une panne régionale se produit.
Réseautage: Utilisez la latence ou le routage global pondéré pour répartir le trafic entre les emplacements.
Réplication et cohérence des données : Utilisez un magasin de données distribué globalement comme Azure Cosmos DB pour les fonctionnalités de lecture et d’écriture multirégion. Pour les bases de données relationnelles, utilisez des réplicas lisibles avec des chaînes de connexion en lecture seule.
Avantage de cette conception : Coûts d’exploitation inférieurs à une conception surprovisionnée.
Inconvénient de cette conception : Dégradation possible de l’expérience utilisateur lors d’un scale-up pour répondre aux demandes d’une charge complète si un autre emplacement subit une panne.
Surprovisionné actif/actif : Tampons de déploiement mis en miroir dans deux emplacements ou plus, chacun surprovisionné pour gérer les charges de travail de production pour l’emplacement ou les emplacements qu’ils servent et pour gérer les charges à partir d’autres emplacements si une panne régionale se produit.
Réseautage: Utilisez la latence ou le routage global pondéré pour répartir le trafic entre les emplacements.
Réplication et cohérence des données : Utilisez un magasin de données distribué globalement comme Azure Cosmos DB pour les fonctionnalités de lecture et d’écriture multirégion. Pour les bases de données relationnelles, utilisez des réplicas lisibles avec des chaînes de connexion en lecture seule.
Avantage de cette conception : Conception la plus résiliente possible.
Inconvénient de cette conception : Coûts d’exploitation plus élevés qu’une conception évolutive.
Avantages courants des deux conceptions : Résilience élevée et faible risque de panne complète de la charge de travail.
Inconvénients courants des deux conceptions : Coûts d’exploitation et charge de gestion plus élevés en raison de divers facteurs, notamment la nécessité de gérer la synchronisation de l’état de l’application et des données.
Utiliser une conception d'architecture active-passive comme approche de reprise après sinistre rentable
Les configurations de déploiement actif/passif offrent un moyen économique de garantir la récupération d’urgence en exécutant une instance principale qui gère tout le trafic tout en conservant les instances secondaires inactives mais prêtes. Ces instances de secours sont activées uniquement lorsque l’instance principale échoue ou subit une maintenance. Cette approche réduit l’utilisation des ressources tout en fournissant des fonctionnalités de basculement fiables.
Par exemple, une plateforme de négociation financière peut utiliser cette configuration pour maintenir la continuité des services. Le système principal gère toutes les transactions, tandis que le système secondaire reste synchronisé en arrière-plan. Si le système principal tombe en panne, le système secondaire prend rapidement en charge et restaure les opérations avec une interruption minimale. Cette approche équilibre la fiabilité et le coût, ce qui le rend idéal pour les charges de travail qui peuvent tolérer de brefs temps de récupération sans la complexité ou les dépenses des déploiements actifs.
Tenez compte des options de configuration suivantes pour les déploiements actifs et passifs.
Espace de rechange chaud : Un emplacement principal et un ou plusieurs emplacements secondaires. L’emplacement secondaire est déployé avec le dimensionnement minimal possible du calcul et des données et s’exécute sans charge. Cet emplacement est appelé emplacement de rechange chaud . Après le basculement, les ressources de calcul et de données sont mises à l’échelle pour gérer la charge à partir de l’emplacement principal.
Réseautage: Utilisez le routage global prioritaire .
Réplication et cohérence des données : Répliquez votre base de données à votre emplacement passif et utilisez les fonctionnalités de basculement automatique des solutions PaaS telles qu’Azure Cosmos DB et Azure SQL Database.
Avantage de cette conception : Durée de récupération la plus courte parmi les conceptions actives-passives.
Inconvénient de cette conception : Coût d’exploitation le plus élevé parmi les conceptions actives et passives.
Rechange à froid : Un emplacement principal et un ou plusieurs emplacements secondaires. L’emplacement secondaire est mis à l’échelle pour gérer la charge complète, mais toutes les ressources de calcul sont arrêtées. Cet emplacement est appelé emplacement de rechange à froid . Vous devez démarrer les ressources avant le basculement.
Réseautage: Utilisez le routage global prioritaire .
Réplication et cohérence des données : Répliquez votre base de données à votre emplacement passif et utilisez les fonctionnalités de basculement automatique des solutions PaaS telles qu’Azure Cosmos DB et SQL Database.
Avantage de cette conception : Coûts d’exploitation inférieurs à la conception de rechange chaude.
Inconvénient de cette conception : Temps de récupération plus long que la conception de rechange chaude.
Distribuer des charges de travail sur une infrastructure indépendante immédiate
Le déploiement de charges de travail dans des centres de données indépendants ou des secteurs de centres de données proches offre une redondance sans compromettre les performances. En utilisant des installations géographiquement proches mais physiquement distinctes, cette configuration garantit l’isolation des pannes avec un impact minimal sur la latence. Il fournit la résilience de l’infrastructure distribuée tout en conservant la réactivité d’un déploiement à site unique. Dans Azure, les zones de disponibilité fournissent cette fonctionnalité. Les zones de disponibilité sont des centres de données ou des secteurs de centres de données physiquement indépendants qui sont conçus pour vous permettre de déployer facilement des charges de travail à faible latence et tolérantes aux pannes.
Pour les applications sensibles à la latence comme les jeux en temps réel, cette approche permet un basculement fluide et une expérience utilisateur ininterrompue. Les serveurs de jeux distribués sur les centres de données locaux peuvent réacheminer instantanément le trafic pendant les pannes, avec un équilibrage de charge transparent et une réplication de données en quasi temps réel préservant la continuité du jeu. Toutefois, cette stratégie présente un certain risque, car les événements régionaux à grande échelle peuvent toujours affecter tous les sites simultanément.
Renforcer la tolérance de panne avec les déploiements géo-distants
Le déploiement sur des centres de données géographiquement distribués offre la protection la plus forte contre les catastrophes à grande échelle en répartissant les charges de travail entre les régions des centaines ou des milliers de kilomètres à part. Cette approche garantit la continuité des activités pendant les événements tels que les catastrophes naturelles, les défaillances d’infrastructure ou les perturbations géopolitiques qui peuvent affecter l’ensemble des régions métropolitaines. Dans Azure, vous pouvez déployer des charges de travail dans des régions réparties dans le monde entier. Lorsque vous utilisez cette approche de conception, choisissez des régions proches de vos utilisateurs, mais qui sont géographiquement distantes, telles que usa Ouest et USA Est.
Par exemple, une plateforme financière mondiale peut maintenir un service ininterrompu en acheminant le trafic vers des régions non affectées si une zone subit une panne majeure. Cette approche optimise la résilience et prend en charge la conformité réglementaire entre les juridictions, mais elle introduit une latence plus élevée, des exigences de cohérence des données complexes et une surcharge opérationnelle accrue. Vous devez peser attentivement ces facteurs sur les avantages de la redondance globale.
Facilitation Azure
La plateforme Azure vous aide à optimiser la résilience de votre charge de travail et à ajouter une redondance en effectuant les actions suivantes :
Vous aide à sélectionner les meilleures régions Azure pour votre architecture multirégion avec le guide Sélectionner des régions Azure.
Fournit une redondance intégrée avec de nombreuses solutions PaaS et SaaS, dont certaines sont configurables.
Fournit des services managés globaux tels que l’ID Microsoft Entra, Azure DNS et Key Vault qui implémentent la redondance de manière transparente sans nécessiter de configuration.
Vous permet de concevoir et d’implémenter la redondance intra-région à l’aide de zones de disponibilité et de redondance interrégion.
Fournit des solutions de calcul redondantes interzone, telles que les groupes de machines virtuelles identiques, qui peuvent répartir automatiquement votre calcul uniformément entre les zones de disponibilité lorsque vous déployez des machines virtuelles.
Fournit des services d’équilibrage de charge prenant en charge les réplicas tels qu’Azure Application Gateway, Azure Front Door et Azure Load Balancer.
Fournit des solutions de géoréplication facilement implémentées comme la géoréplication active pour SQL Database. Implémentez la distribution mondiale et la réplication transparente à l’aide d’Azure Cosmos DB. Azure Cosmos DB fournit deux options pour gérer les écritures en conflit. Choisissez la meilleure option pour votre charge de travail.
Fournit des fonctionnalités de restauration dans le temps (PITR) pour de nombreux services de données PaaS.
Atténue l’épuisement des ports via la passerelle NAT Azure ou le pare-feu Azure.
Facilitation Azure spécifique à DNS
Pour les scénarios de résolution de noms internes, utilisez des zones privées Azure DNS, qui ont une redondance de zone intégrée et une géoredondance. Pour plus d’informations, consultez résilience de zone privée Azure DNS.
Pour les scénarios de résolution de noms externes, utilisez des zones publiques Azure DNS, qui ont une redondance de zone intégrée et une géoredondance.
Les services AZURE DNS publics et privés sont des services globaux résilients aux pannes régionales, car les données de zone sont disponibles globalement.
Pour les scénarios de résolution de noms hybrides entre les environnements locaux et cloud, utilisez Azure DNS Private Resolver. Ce service prend en charge la redondance de zone si votre charge de travail se trouve dans une région qui prend en charge les zones de disponibilité. Une panne à l’échelle de la zone ne nécessite aucune action pendant la récupération de zone. Le service se guérit automatiquement et rééquilibrée pour tirer parti de la zone saine. Pour plus d’informations, consultez Résilience dans azure DNS Private Resolver.
Pour éliminer un point de défaillance unique et obtenir une résolution de noms hybride plus résiliente entre les régions, déployez deux ou plusieurs résolveurs privés Azure DNS dans différentes régions. Le basculement DNS, dans un scénario de transfert conditionnel, est obtenu en affectant un programme de résolution en tant que serveur DNS principal. Attribuez l’autre programme de résolution dans une autre région en tant que serveur DNS secondaire. Pour plus d’informations, consultez Configurer le basculement DNS à l’aide de programmes de résolution privés.
Appliquer la protection de suppression pour préserver la redondance
La redondance ne fonctionne que si les composants qui la fournissent restent en place. La suppression accidentelle d’un magasin de données, d’une zone DNS ou d’une couche de routage du trafic réduit la résilience et force les actions de récupération complètes. Réduisez l'impact des erreurs humaines en appliquant des verrous de ressources Azure 'CanNotDelete'.
Compromis: L’application de verrous ralentit les actions de récupération légitimes et peut créer des frictions opérationnelles. Empêche la suppression des ressources, mais pas les modifications ni les données dans la ressource. Traitez les verrous comme un filet de sécurité mince qui complète, et ne remplace jamais, les sauvegardes, la réplication et la gouvernance des accès.
Example
Pour obtenir un exemple de déploiement redondant multirégion, consultez l’application web redondante interzone hautement disponible de référence.
Le diagramme suivant montre un autre exemple.
Liens connexes
Pour en savoir plus sur la redondance, consultez les ressources suivantes :
- Guide des régions Azure
- Redondance du stockage Azure
- Stockage redondant interzone
- Géoréplication active sql Database
- Configurer la réplication entre deux instances managées
Liste de contrôle de fiabilité
Reportez-vous à l’ensemble complet de recommandations.