Recommandations relatives à l’utilisation des zones de disponibilité et des régions

S’applique à cette recommandation de liste de vérification de fiabilité Azure Well-Architected Framework :

RE :05	Ajoutez une redondance à différents niveaux, en particulier pour les flux critiques. Appliquez la redondance aux niveaux de calcul, de données, de réseau et d’autres niveaux d’infrastructure conformément aux objectifs de fiabilité identifiés.

Guides connexes :Redondance de conception | multirégionale hautement disponible

Ce guide décrit les recommandations pour déterminer quand déployer des charges de travail dans des zones de disponibilité ou des régions.

Lorsque vous concevez une solution pour Azure, vous devez décider si vous allez déployer sur plusieurs zones de disponibilité d’une région ou dans plusieurs régions. Cette décision affecte la fiabilité, le coût et les performances de votre solution, ainsi que la capacité de votre équipe à exploiter la solution. Ce guide fournit des informations sur les exigences métier clés qui influencent votre décision, les approches que vous pouvez envisager, les compromis impliqués dans chaque approche et l’effet de chaque approche sur les principaux piliers d’Azure Well-Architected Framework.

La décision concernant les meilleures régions Azure à utiliser pour votre solution est un choix essentiel. Le guide Sélectionner des régions Azure explique comment sélectionner et utiliser dans plusieurs régions géographiques. Votre choix de la façon dont vous utilisez les régions et les zones de disponibilité au sein de votre solution affecte également plusieurs des piliers de l’infrastructure Well-Architected :

• Fiabilité : votre choix d’approche de déploiement peut vous aider à atténuer différents types de risques. En général, en répartissant votre charge de travail sur une zone géographiquement plus distribuée, vous pouvez obtenir une plus grande résilience.
• Optimisation des coûts : certaines approches architecturales nécessitent le déploiement de plus de ressources que d’autres, ce qui peut augmenter les coûts de vos ressources. D’autres approches impliquent l’envoi de données entre des zones de disponibilité ou des régions géographiquement séparées, ce qui peut entraîner des frais de trafic réseau. Il est également important de prendre en compte le coût continu de la gestion de vos ressources, qui est généralement plus élevé lorsque vous avez des besoins métier complets.
• Efficacité des performances : les zones de disponibilité sont connectées ensemble via une liaison réseau à bande passante élevée et à faible latence, ce qui est suffisant pour la plupart des charges de travail pour permettre la réplication et la communication synchrones entre les zones. Toutefois, si votre charge de travail a été testée et qu’elle est sensible à la latence réseau entre les zones, vous devrez peut-être envisager de localiser physiquement les composants de votre charge de travail à proximité pour réduire la latence lorsqu’ils communiquent.
• Excellence opérationnelle : une architecture complexe demande plus d’efforts pour déployer, configurer et gérer. En outre, pour une solution hautement disponible, vous devrez peut-être planifier le basculement vers un ensemble secondaire de ressources. Le basculement, la restauration automatique et la redirection transparente de votre trafic peuvent être complexes, en particulier lorsque des étapes manuelles sont nécessaires. Il est recommandé d’automatiser vos processus de déploiement et de gestion. Pour plus d’informations, consultez les guides du pilier Excellence opérationnelle, notamment l’infrastructure en tant que code OE :05, l’automatisation des tâches OE :09, la conception d’automatisation OE :10 et les pratiques de déploiement OE :11.

Quelle que soit la conception de votre solution, le pilier Sécurité s’applique. En règle générale, les décisions relatives à l’utilisation ou non des zones de disponibilité et des régions ne modifient pas votre posture de sécurité. Azure applique la même rigueur de sécurité à chaque région et zone de disponibilité.

Conseil

Pour de nombreuses charges de travail de production, un déploiement redondant interzone offre le meilleur équilibre entre les compromis. Vous pouvez étendre cette approche avec une sauvegarde de données asynchrone vers une autre région. Si vous ne savez pas quelle approche sélectionner, commencez par ce type de déploiement.

Envisagez d’autres approches de charge de travail lorsque vous avez besoin des avantages spécifiques que ces approches offrent, mais n’oubliez pas les compromis impliqués.

Définitions

Terme	Définition
Actif/actif	Architecture dans laquelle plusieurs instances d’une solution traitent activement les demandes en même temps.
Actif/Passif	Architecture dans laquelle une instance d’une solution est désignée comme principal et traite le trafic, et une ou plusieurs instances secondaires sont déployées pour servir le trafic si le principal n’est pas disponible.
Réplication asynchrone	Une approche de réplication des données dans laquelle les données sont écrites et validées dans un emplacement unique. Ultérieurement, les modifications sont répliquées vers un autre emplacement.
Zone de disponibilité	Groupe séparé de centres de données au sein d’une région. Chaque zone de disponibilité est indépendante des autres, avec sa propre infrastructure d’alimentation, de refroidissement et de mise en réseau. De nombreuses régions prennent en charge les zones de disponibilité.
Centre de données	Une installation qui contient des serveurs, de l’équipement réseau et d’autres matériels pour prendre en charge les ressources et charges de travail Azure.
Déploiement localement redondant	Modèle de déploiement dans lequel une ressource est déployée dans une seule région sans référence à une zone de disponibilité. Dans une région qui prend en charge les zones de disponibilité, la ressource peut être déployée dans l’une des zones de disponibilité de la région.
Déploiement multi-régions	Modèle de déploiement dans lequel les ressources sont déployées dans plusieurs régions Azure.
Régions jumelées	Relation entre deux régions Azure. Certaines régions Azure sont connectées à une autre région définie pour activer des types spécifiques de solutions multirégions. Les régions Azure plus récentes ne sont pas jumelées.
Région	Périmètre géographique qui contient un ensemble de centres de données.
Architecture de région	Configuration spécifique de la région Azure, y compris le nombre de zones de disponibilité et si la région est associée à une autre région.
Réplication synchrone	Une approche de réplication des données dans laquelle les données sont écrites et validées dans plusieurs emplacements. Chaque emplacement doit confirmer l’achèvement de l’opération d’écriture avant que l’opération d’écriture globale soit considérée comme terminée.
Déploiement zonal (épinglé)	Modèle de déploiement dans lequel une ressource est déployée dans une zone de disponibilité spécifique.
Déploiement redondant interzone	Modèle de déploiement dans lequel une ressource est déployée sur plusieurs zones de disponibilité. Microsoft gère la synchronisation des données, la distribution du trafic et le basculement en cas de panne d’une zone.

Stratégies de conception

Azure a une grande empreinte mondiale. Une région Azure est un périmètre géographique qui contient un ensemble de centres de données. Vous devez avoir une compréhension complète des régions Azure et des zones de disponibilité.

Les régions Azure ont une variété de configurations, qui sont également appelées architectures de région.

De nombreuses régions Azure fournissent des zones de disponibilité, qui sont des groupes séparés de centres de données. Au sein d’une région, les zones de disponibilité sont suffisamment proches pour avoir des connexions à faible latence vers d’autres zones de disponibilité, mais elles sont suffisamment éloignées pour réduire la probabilité que plusieurs d’entre elles soient affectées par des pannes locales ou des conditions météorologiques. Les zones de disponibilité disposent d’une infrastructure indépendante d’alimentation, de refroidissement et de mise en réseau. Ils sont conçus de sorte que si une zone subit une panne, les services régionaux, la capacité et la haute disponibilité sont pris en charge par les autres zones.

Le diagramme suivant montre plusieurs exemples de régions Azure. Les régions 1 et 2 prennent en charge les zones de disponibilité.

Si vous effectuez un déploiement dans une région Azure qui contient des zones de disponibilité, vous pouvez utiliser plusieurs zones de disponibilité ensemble. En utilisant plusieurs zones de disponibilité, vous pouvez conserver des copies distinctes de votre application et de vos données dans des centres de données physiques distincts dans une grande zone métropolitaine.

Il existe deux façons d’utiliser des zones de disponibilité dans une solution :

• Les ressources zonales sont épinglées à une zone de disponibilité spécifique. Vous pouvez combiner plusieurs déploiements zonaux dans différentes zones pour répondre à des exigences de fiabilité élevées. Vous êtes responsable de la gestion de la réplication des données et de la distribution des demandes entre les zones. Si une panne se produit dans une seule zone de disponibilité, vous êtes responsable du basculement vers une autre zone de disponibilité.
• Les ressources redondantes interzones sont réparties sur plusieurs zones de disponibilité. Microsoft gère la répartition des demandes entre les zones et la réplication des données entre les zones. Si une panne se produit dans une seule zone de disponibilité, Microsoft gère le basculement automatiquement.

Les services Azure prennent en charge l’une de ces approches ou les deux. Les services PaaS (Platform as a Service) prennent généralement en charge les déploiements redondants interzone. Les services IaaS (Infrastructure as a Service) prennent généralement en charge les déploiements zonaux. Pour plus d’informations sur le fonctionnement des services Azure avec les zones de disponibilité, consultez Services Azure avec prise en charge des zones de disponibilité.

Lorsque Microsoft déploie des mises à jour sur des services, nous essayons d’utiliser des approches qui vous perturbent le moins. Par exemple, nous visons à déployer des mises à jour dans une seule zone de disponibilité à la fois. Cette approche peut réduire l’impact que les mises à jour peuvent avoir sur une charge de travail active, car la charge de travail peut continuer à s’exécuter dans d’autres zones pendant que la mise à jour est en cours. Toutefois, il incombe en fin de compte à l’équipe de charge de travail de s’assurer que sa charge de travail continue de fonctionner pendant les mises à niveau de la plateforme. Par exemple, lorsque vous utilisez des groupes de machines virtuelles identiques avec le mode d’orchestration flexible ou la plupart des services PaaS Azure, Azure place intelligemment vos ressources pour réduire l’impact des mises à jour de la plateforme. En outre, vous pouvez envisager un surapprovisionnement ( déploiement d’instances supplémentaires d’une ressource) afin que certaines instances restent disponibles pendant que d’autres instances sont mises à niveau. Pour plus d’informations sur la façon dont Azure déploie les mises à jour, consultez Avancement des pratiques de déploiement sécurisé.

De nombreuses régions ont également une région jumelée. Les régions jumelées prennent en charge certains types d’approches de déploiement multirégion. Certaines régions plus récentes ont plusieurs zones de disponibilité et n’ont pas de région jumelée. Vous pouvez toujours déployer des solutions multirégions dans ces régions, mais les approches que vous utilisez peuvent être différentes.

Pour plus d’informations sur la façon dont Azure utilise les régions et les zones de disponibilité, consultez Que sont les régions et les zones de disponibilité Azure ?

Comprendre les responsabilités partagées

Le principe de responsabilité partagée décrit la façon dont les responsabilités sont réparties entre le fournisseur de cloud (Microsoft) et vous. Selon le type de services que vous utilisez, vous pouvez assumer plus ou moins de responsabilités pour l’exploitation du service.

Microsoft fournit des zones de disponibilité et des régions pour vous donner une certaine flexibilité dans la façon dont vous concevez votre solution pour répondre à vos besoins. Lorsque vous utilisez des services managés, Microsoft assume davantage de responsabilités de gestion pour vos ressources, ce qui peut même inclure la réplication des données, le basculement, la restauration automatique et d’autres tâches liées à l’exploitation d’un système distribué.

Votre propre code doit suivre des pratiques recommandées et des modèles de conception pour gérer correctement les défaillances. Ces pratiques sont encore plus importantes lors des opérations de basculement, telles que celles qui se produisent lorsqu’un basculement de zone de disponibilité ou de région se produit, car le basculement entre des zones ou des régions nécessite généralement que votre application réessaye de se connecter aux services.

Identifier les principales exigences métier et de charge de travail

Pour prendre une décision éclairée sur l’utilisation des zones de disponibilité et des régions dans votre solution, vous devez comprendre vos besoins. Ces exigences doivent être pilotées par des discussions entre les concepteurs de solutions et les parties prenantes de l’entreprise.

Tolérance au risque

Différentes organisations ont des degrés de tolérance au risque différents. Même au sein d’un organization, la tolérance au risque est souvent différente pour chaque charge de travail. La plupart des charges de travail n’ont pas besoin d’une disponibilité extrêmement élevée. Toutefois, certaines charges de travail sont si importantes qu’il est même utile d’atténuer les risques qui sont peu susceptibles de se produire, comme les catastrophes naturelles majeures qui affectent une vaste zone géographique.

Ce tableau répertorie quelques-uns des risques courants que vous devez prendre en compte dans un environnement cloud :

Risque	Exemples	Vraisemblance
Panne matérielle	Problème avec le disque dur ou l’équipement réseau. Redémarrages de l’hôte.	Élevée. Toute stratégie de résilience doit tenir compte de ces risques.
Panne du centre de données	Panne d’alimentation, de refroidissement ou de réseau sur l’ensemble d’un centre de données. Catastrophe naturelle dans une partie d’une zone métropolitaine.	Moyenne
Panne de région	Catastrophe naturelle majeure qui touche une vaste zone géographique. Problème de réseau ou de service qui rend un ou plusieurs services Azure indisponibles dans une région entière.	Faible

Il serait idéal d’atténuer tous les risques possibles pour chaque charge de travail, mais il n’est pas pratique ou rentable de le faire. Il est important d’avoir une discussion ouverte avec les parties prenantes de l’entreprise afin de pouvoir prendre des décisions éclairées sur les risques que vous devez atténuer.

Conseil

Quelles que soient les cibles de fiabilité, toutes les charges de travail doivent avoir une certaine atténuation pour la récupération d’urgence. Si votre charge de travail exige des objectifs de fiabilité élevés, vos stratégies d’atténuation doivent être complètes et vous devez réduire le risque d’événements même à faible probabilité. Pour les autres charges de travail, prenez une décision éclairée sur les risques que vous êtes prêt à accepter et ceux que vous devez atténuer.

Exigences en matière de résilience

Il est important de comprendre les exigences de résilience pour votre charge de travail, notamment l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO). Ces objectifs vous aident à choisir les approches à exclure. Si vous n’avez pas d’exigences claires, vous ne pouvez pas prendre de décision éclairée quant à l’approche à suivre. Pour plus d’informations, consultez Exigences fonctionnelles et non fonctionnelles cibles.

Objectifs de niveau de service

Vous devez comprendre l’objectif de niveau de service (SLO) de temps de fonctionnement attendu de votre solution. Par exemple, vous pouvez avoir une exigence métier dont votre solution a besoin pour répondre à une durée de fonctionnement de 99,9 %.

Azure fournit des contrats de niveau de service (SLA) pour chaque service. Un contrat SLA indique le niveau de disponibilité que vous devez attendre du service et les conditions que vous devez remplir pour atteindre ce contrat SLA attendu. Toutefois, n’oubliez pas que la façon dont un contrat SLA Azure indique la disponibilité du service ne correspond pas toujours à la façon dont vous considérez l’intégrité de votre charge de travail.

Vos décisions architecturales affectent le SLO composite de votre solution. En général, plus vous créez de redondance dans votre solution, plus votre SLO est susceptible d’être élevé. De nombreux services Azure fournissent des contrats SLA plus élevés lorsque vous déployez des services dans une configuration redondante interzone ou multirégion. Passez en revue les contrats SLA pour chacun des services Azure que vous utilisez pour vous assurer que vous comprenez comment optimiser la résilience et le contrat SLA du service.

Résidence des données

Certaines organisations imposent des restrictions sur les emplacements physiques dans lesquels leurs données peuvent être stockées et traitées. Parfois, ces exigences sont basées sur des normes légales ou réglementaires. Dans d’autres situations, un organization peut décider d’adopter une stratégie de résidence des données pour éviter les préoccupations des clients. Si vous avez des exigences strictes en matière de résidence des données, vous devrez peut-être utiliser un déploiement dans une seule région ou utiliser un sous-ensemble de régions et de services Azure.

Notes

Évitez de faire des hypothèses non fondées sur vos exigences de résidence des données. Si vous devez vous conformer à des normes réglementaires spécifiques, vérifiez ce que ces normes spécifient réellement.

Emplacement de l’utilisateur

En comprenant où se trouvent vos utilisateurs, vous pouvez prendre une décision éclairée sur la façon d’optimiser la latence et la fiabilité en fonction de vos besoins. Azure fournit de nombreuses options pour prendre en charge une base d’utilisateurs géographiquement dispersée.

Si vos utilisateurs sont concentrés dans une seule zone, un déploiement dans une seule région peut simplifier vos besoins opérationnels et réduire vos coûts. Toutefois, vous devez déterminer si un déploiement dans une seule région répond à vos exigences de fiabilité. Pour les applications stratégiques, vous devez toujours utiliser un déploiement multirégion même si vos utilisateurs sont colocalisés.

Si vos utilisateurs sont géographiquement dispersés, il peut être judicieux de déployer votre charge de travail dans plusieurs régions. Les services Azure offrent différentes fonctionnalités pour prendre en charge un déploiement multirégion, et vous pouvez utiliser l’empreinte globale d’Azure pour améliorer votre expérience utilisateur et rapprocher vos applications de votre base d’utilisateurs. Vous pouvez utiliser le modèle Empreintes de déploiement ou le modèle Géodes, ou répliquer vos ressources dans plusieurs régions.

Même si vos utilisateurs se trouvent dans des zones géographiques différentes, déterminez si vous avez besoin d’un déploiement multirégion. Déterminez si vous pouvez répondre à vos besoins au sein d’une seule région en utilisant l’accélération du trafic global, comme l’accélération fournie par Azure Front Door.

Budget

Si vous travaillez dans un budget limité, il est important de prendre en compte les coûts impliqués dans le déploiement de composants de charge de travail redondants. Ces coûts peuvent inclure des frais de ressources supplémentaires, des coûts de mise en réseau et les coûts opérationnels liés à la gestion d’un plus grand nombre de ressources et d’un environnement plus complexe.

Complexité

Il est recommandé d’éviter une complexité inutile dans l’architecture de votre solution. Plus vous introduisez de complexité, plus il devient difficile de prendre des décisions concernant votre architecture. Les architectures complexes sont plus difficiles à utiliser, plus difficiles à sécuriser et souvent moins performantes. Suivez le principe de simplicité.

Animation Azure

En fournissant des régions et des zones de disponibilité, Azure vous permet de sélectionner une approche de déploiement adaptée à vos besoins. Il existe de nombreuses approches parmi lesquelles vous pouvez choisir, chacune offrant des avantages et des coûts.

Pour illustrer les approches de déploiement que vous pouvez utiliser, envisagez un exemple de scénario. Supposons que vous envisagez de déployer une nouvelle solution qui inclut une application qui écrit des données dans un type de stockage :

Cet exemple n’est pas spécifique à des services Azure particuliers. Il est destiné à fournir un exemple simple pour illustrer des concepts fondamentaux.

Il existe plusieurs façons de déployer cette solution. Chaque approche offre un ensemble différent d’avantages et entraîne des coûts différents. À un niveau élevé, vous pouvez envisager un déploiement localement redondant, zonal (épinglé),redondant interzone ou multirégion . Ce tableau récapitule certaines des préoccupations relatives aux piliers :

Pilier	Localement redondant	Zonal (épinglé)	Redondant interzone	Multirégion
Fiabilité	Faible fiabilité	Dépend de l’approche	Fiabilité élevée ou très élevée	Fiabilité élevée ou très élevée
Optimisation des coûts	Faible coût	Dépend de l’approche	Coût modéré	Coût élevé
Efficacité des performances	Performances acceptables (pour la plupart des charges de travail)	Hautes performances	Performances acceptables (pour la plupart des charges de travail)	Dépend de l’approche
Excellence opérationnelle	Exigences opérationnelles faibles	Exigences opérationnelles élevées	Exigences opérationnelles faibles	Exigences opérationnelles élevées

Ce tableau récapitule certaines des approches que vous pouvez utiliser et leur impact sur votre architecture :

Problème d’architecture	Localement redondant	Zonal (épinglé)	Redondant interzone	Multirégion
Conformité à la résidence des données	Élevé	Élevé	Élevé	Dépend de la région
Disponibilité régionale	Toutes les régions	Régions avec des zones de disponibilité	Régions avec des zones de disponibilité	Dépend de la région

Le reste de cet article décrit chacune des approches répertoriées dans le tableau précédent. La liste des approches n’est pas exhaustive. Vous pouvez décider de combiner plusieurs approches ou d’utiliser différentes approches dans différentes parties de votre solution.

Approche de déploiement 1 : déploiements localement redondants

Si vous ne spécifiez pas plusieurs zones de disponibilité ou régions lors du déploiement de vos ressources, Azure ne garantit pas si les ressources sont déployées dans un seul centre de données ou s’elles sont réparties entre plusieurs centres de données de la région. Dans certains cas, Azure peut également déplacer votre ressource entre des zones de disponibilité.

La plupart des ressources Azure sont hautement disponibles par défaut, avec des SLA élevés et une redondance intégrée au sein d’un centre de données géré par la plateforme. Toutefois, du point de vue de la fiabilité, si une partie de la région rencontre une panne, il est possible que votre charge de travail soit affectée. Si c’est le cas, votre solution n’est peut-être pas disponible ou vos données peuvent être perdues.

Pour les charges de travail hautement sensibles à la latence, cette approche peut également entraîner une baisse des performances. Vos composants de charge de travail peuvent ne pas être colocalisés dans le même centre de données. Vous pouvez donc observer une latence pour le trafic intrarégion. Azure peut également déplacer de manière transparente vos instances de service entre des zones de disponibilité, ce qui peut affecter légèrement les performances. Toutefois, ce n’est pas un problème pour la plupart des charges de travail.

Ce tableau récapitule certaines des préoccupations relatives aux piliers :

Pilier	Impact
Fiabilité	Faible fiabilité. Les services sont sujets à des pannes en cas de défaillance d’un centre de données. Toutefois, vous pouvez créer une application pour qu’elle soit résiliente à d’autres types de défaillances.
Optimisation des coûts	Coût le plus bas. Vous n’avez besoin que d’un seul instance de chaque ressource, et vous n’encourez pas de coûts de bande passante interzones ou interrégions.
Efficacité des performances	Pour la plupart des charges de travail :performances acceptables. Cette approche est susceptible d’offrir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence :performances faibles. Il n’est pas garanti que les composants se trouvent dans la même zone de disponibilité. Vous pouvez donc voir des performances inférieures pour les composants hautement sensibles à la latence.
Excellence opérationnelle	Efficacité opérationnelle élevée. Il vous suffit de déployer et de gérer une seule instance de chaque ressource.

Ce tableau récapitule certaines des préoccupations d’un point de vue architectural :

Problème d’architecture	Impact
Conformité à la résidence des données	Élevée. Lorsque vous déployez une solution qui utilise cette approche, les données sont stockées dans la région Azure que vous sélectionnez.
Disponibilité régionale	Élevée. Cette approche peut être utilisée dans n’importe quelle région Azure.

Déploiements localement redondants avec sauvegarde entre les régions

Vous pouvez étendre un déploiement localement redondant en effectuant des sauvegardes régulières de votre infrastructure et de vos données dans une région secondaire. Cette approche ajoute une couche de protection supplémentaire pour atténuer les pannes dans votre région primaire. Voici à quoi il ressemble :

Lorsque vous implémentez cette approche, vous devez examiner attentivement votre RTO et votre RPO :

• Temps de récupération : si une panne régionale se produit, vous devrez peut-être reconstruire votre solution dans une autre région Azure, ce qui affecte votre temps de récupération. Envisagez de créer votre solution à l’aide d’une approche d’infrastructure en tant que code (IaC) afin de pouvoir rapidement effectuer un redéploiement dans une autre région en cas de sinistre majeur. Assurez-vous que vos outils et processus de déploiement sont tout aussi résilients que vos applications afin de pouvoir les utiliser pour redéployer votre solution même en cas de panne. Planifiez et répétez les étapes nécessaires pour restaurer votre solution à un état opérationnel.
• Point de récupération : votre fréquence de sauvegarde détermine la quantité de perte de données que vous pouvez subir (votre point de récupération). Vous pouvez généralement contrôler la fréquence des sauvegardes afin de répondre à votre RPO.

Ce tableau récapitule certaines des préoccupations relatives aux piliers :

Pilier	Impact
Fiabilité	Fiabilité modérée. Les services sont sujets à des pannes en cas de défaillance d’un centre de données. Les données sont sauvegardées de manière asynchrone dans une région géographiquement séparée, ce qui réduit l’effet d’une panne de région complète en réduisant la perte de données. En cas de panne de région complète, vous pouvez restaurer manuellement les opérations dans une autre région. Toutefois, les processus de récupération peuvent être complexes et la restauration manuelle dans l’autre région peut prendre du temps.
Optimisation des coûts	Faible coût. En règle générale, l’ajout d’une sauvegarde dans une autre région ne coûte que légèrement plus cher que le déploiement d’une ressource localement redondante.
Efficacité des performances	Pour la plupart des charges de travail :performances acceptables. Cette approche est susceptible d’offrir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence :performances faibles. Il n’est pas garanti que les composants se trouvent dans la même zone de disponibilité. Vous pouvez donc voir des performances inférieures pour les composants hautement sensibles à la latence.
Excellence opérationnelle	Pendant toute panne au sein d’une région :faible efficacité opérationnelle. Le basculement est votre responsabilité et peut nécessiter des opérations manuelles et des redéploiements.

Ce tableau récapitule certaines des préoccupations d’un point de vue architectural :

Problème d’architecture	Impact
Conformité à la résidence des données	Dépend de la sélection de la région. Les données sont principalement stockées dans la région Azure que vous spécifiez. Toutefois, vous devez sélectionner une autre région pour stocker vos sauvegardes. Il est donc important de sélectionner une région compatible avec vos exigences de résidence des données.
Disponibilité régionale	Élevée. Vous pouvez utiliser cette approche dans n’importe quelle région Azure.

Approche de déploiement 2 : déploiements zonaux (épinglés)

Dans un déploiement zonnal , vous spécifiez que vos ressources doivent être déployées dans une zone de disponibilité spécifique. Cette approche est parfois appelée déploiement épinglé dans une zone .

Une approche zonale réduit la latence entre vos composants. Toutefois, en soi, cela n’augmente pas la résilience de votre solution. Pour augmenter votre résilience, vous devez déployer plusieurs instances de vos composants dans plusieurs zones de disponibilité et décider comment acheminer le trafic entre chaque instance. Cet exemple montre une approche de routage du trafic actif/passif :

Dans l’exemple précédent, un équilibreur de charge est déployé sur plusieurs zones de disponibilité. Il est important de réfléchir à la façon dont vous acheminez le trafic entre les instances dans différentes zones de disponibilité, car une panne de zone peut également affecter les ressources réseau déployées dans cette zone. Vous pouvez également envisager d’utiliser un équilibreur de charge global, comme Azure Front Door ou Azure Traffic Manager, qui n’est pas déployé dans une région.

Lorsque vous utilisez un modèle de déploiement zonnal, vous prenez de nombreuses responsabilités :

• Vous devez déployer des ressources dans chaque zone de disponibilité, puis configurer et gérer ces ressources individuellement.
• Vous devez décider comment et quand répliquer des données entre les zones de disponibilité, puis configurer et gérer la réplication.
• Vous êtes responsable de la distribution des requêtes aux ressources appropriées, à l’aide, par exemple, d’un équilibreur de charge. Vous devez vous assurer que l’équilibreur de charge répond à vos exigences de résilience. Vous devez également décider d’utiliser un modèle de distribution de requêtes actif-passif ou actif-actif.
• Si une zone de disponibilité rencontre une panne, vous devez gérer le basculement pour envoyer le trafic aux ressources d’une autre zone de disponibilité.

Un déploiement actif/passif dans plusieurs zones de disponibilité est parfois appelé récupération d’urgence dans la région ou récupération d’urgence métropolitaine.

Ce tableau récapitule certaines des préoccupations relatives aux piliers :

Pilier	Impact
Fiabilité	En cas de déploiement dans une zone de disponibilité unique :faible fiabilité. Un déploiement zonnal n’offre aucune résilience à une panne dans un centre de données ou une zone de disponibilité. Vous devez déployer des ressources redondantes sur plusieurs zones de disponibilité pour obtenir une résilience élevée. En cas de déploiement dans plusieurs zones de disponibilité :fiabilité élevée. Les services peuvent être résilients à une panne de centre de données ou de zone de disponibilité.
Optimisation des coûts	En cas de déploiement dans une zone de disponibilité unique :faible coût. Un déploiement à zone unique ne nécessite qu’une seule instance de chaque ressource. En cas de déploiement dans plusieurs zones de disponibilité :coût élevé. Vous déployez plusieurs instances des ressources, chacune d’elles étant facturée séparément. Vous devez également payer le trafic interzone pour la réplication des données.
Efficacité des performances	Performances élevées. La latence peut être très faible lorsque les composants qui traitent une requête se trouvent dans la même zone de disponibilité.
Excellence opérationnelle	Faible efficacité opérationnelle. Vous devez configurer et gérer plusieurs instances de votre service. Vous devez répliquer les données entre les zones de disponibilité. Lors d’une panne de zone de disponibilité, le basculement est votre responsabilité.

Ce tableau récapitule certaines des préoccupations d’un point de vue architectural :

Problème d’architecture	Impact
Conformité à la résidence des données	Élevée. Lorsque vous déployez une solution qui utilise cette approche, les données sont stockées dans la région Azure que vous sélectionnez.
Disponibilité régionale	Régions avec des zones de disponibilité. Cette approche est disponible dans n’importe quelle région qui prend en charge les zones de disponibilité.

Cette approche est généralement utilisée pour les charges de travail basées sur des machines virtuelles. Pour obtenir la liste complète des services qui prennent en charge les déploiements zonaux, consultez Service de zone de disponibilité et prise en charge régionale.

Lorsque vous planifiez un déploiement zonnal, vérifiez que les services Azure que vous utilisez sont pris en charge dans les zones de disponibilité que vous envisagez d’utiliser. Par exemple, pour répertorier les références SKU de machine virtuelle disponibles dans chaque zone de disponibilité, consultez Vérifier la disponibilité de la référence SKU de machine virtuelle.

Conseil

Lorsque vous déployez une ressource dans une zone de disponibilité spécifique, vous sélectionnez le numéro de zone. La séquence de numéros de zone est différente pour chaque abonnement Azure. Si vous déployez des ressources sur plusieurs abonnements Azure, vérifiez les numéros de zone que vous devez utiliser dans chaque abonnement. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

Approche de déploiement 3 : déploiements redondants interzones

Lorsque vous utilisez cette approche, votre couche Application est répartie sur plusieurs zones de disponibilité. Lorsque les requêtes arrivent, un équilibreur de charge intégré au service (qui couvre lui-même les zones de disponibilité) disperse les requêtes entre les instances de chaque zone de disponibilité. Si une zone de disponibilité rencontre une panne, l’équilibreur de charge dirige le trafic vers les instances dans les zones de disponibilité saines.

Votre niveau de stockage est également réparti sur plusieurs zones de disponibilité. Les copies des données de votre application sont distribuées entre plusieurs zones de disponibilité via la réplication synchrone. Lorsque l’application apporte une modification aux données, le service de stockage écrit la modification dans plusieurs zones de disponibilité, et la transaction n’est considérée comme terminée qu’une fois toutes ces modifications terminées. Ce processus garantit que chaque zone de disponibilité dispose toujours d’une copie à jour des données. Si une zone de disponibilité rencontre une panne, une autre zone de disponibilité peut être utilisée pour accéder aux mêmes données.

Une approche redondante interzone augmente la résilience de votre solution aux problèmes tels que les pannes de centre de données. Étant donné que les données sont répliquées de manière synchrone, votre application doit toutefois attendre que les données soient écrites dans plusieurs emplacements distincts qui peuvent se trouver dans différentes parties d’une région métropolitaine. Pour la plupart des applications, la latence impliquée dans la communication interzone est négligeable. Toutefois, pour certaines charges de travail hautement sensibles à la latence, la réplication synchrone entre les zones de disponibilité peut affecter les performances de l’application.

Ce tableau récapitule certaines des préoccupations relatives aux piliers :

Pilier	Impact
Fiabilité	Haute fiabilité. Les services sont résilients à une panne d’un centre de données ou d’une zone de disponibilité. Les données sont répliquées de manière synchrone entre les zones de disponibilité et sans délai.
Optimisation des coûts	Coût modéré. Selon les services que vous utilisez, vous pouvez entraîner des coûts pour des niveaux de service plus élevés afin d’activer la redondance de zone, ou certains coûts de mise en réseau interzone.
Efficacité des performances	Pour la plupart des charges de travail :performances acceptables. Cette approche est susceptible d’offrir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence :performances faibles. Certains composants peuvent être sensibles à la latence en raison du trafic interzone ou du temps de réplication des données.
Excellence opérationnelle	Efficacité opérationnelle élevée. Vous devez généralement gérer une seule instance logique de chaque ressource. Pour la plupart des services, lors d’une panne de zone de disponibilité, le basculement est de la responsabilité de Microsoft et se produit automatiquement.

Ce tableau récapitule certaines des préoccupations d’un point de vue architectural :

Problème d’architecture	Impact
Conformité à la résidence des données	Élevée. Lorsque vous déployez une solution qui utilise cette approche, les données sont stockées dans la région Azure que vous sélectionnez.
Disponibilité régionale	Régions avec des zones de disponibilité. Cette approche est disponible dans n’importe quelle région qui prend en charge les zones de disponibilité.

Cette approche est possible avec de nombreux services Azure, notamment Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Stockage Azure, Azure SQL, Azure Service Bus, et bien d’autres. Pour obtenir la liste complète des services qui prennent en charge la redondance de zone, consultez Service de zone de disponibilité et prise en charge régionale.

Déploiements redondants interzones avec sauvegarde entre les régions

Vous pouvez étendre un déploiement redondant interzone en effectuant des sauvegardes régulières de votre infrastructure et de vos données dans une région secondaire. Cette approche vous offre les avantages d’une approche redondante interzone et ajoute une couche de protection pour atténuer l’événement extrêmement peu probable d’une panne complète de la région.

Lorsque vous implémentez cette approche, vous devez examiner attentivement votre RTO et votre RPO :

• Temps de récupération : si une panne régionale se produit, vous devrez peut-être reconstruire votre solution dans une autre région Azure, ce qui affecte votre temps de récupération. Envisagez de créer votre solution à l’aide d’une approche IaC afin de pouvoir rapidement vous redéployer dans une autre région en cas de sinistre majeur. Assurez-vous que vos outils et processus de déploiement sont tout aussi résilients que vos applications afin de pouvoir les utiliser pour redéployer votre solution même en cas de panne. Planifiez et répétez les étapes nécessaires pour restaurer votre solution à un état opérationnel.

• Point de récupération : votre fréquence de sauvegarde détermine la quantité de perte de données que vous pouvez subir (votre point de récupération). Vous pouvez généralement contrôler la fréquence des sauvegardes pour répondre à votre RPO.

Conseil

Cette approche offre souvent un bon équilibre pour toutes les préoccupations architecturales. Si vous ne savez pas quelle approche utiliser, commencez par ce type de déploiement.

Ce tableau récapitule certaines des préoccupations relatives aux piliers :

Pilier	Impact
Fiabilité	Très haute fiabilité. Les services sont résilients à une panne d’un centre de données ou d’une zone de disponibilité. Pour la plupart des services, les données sont répliquées entre les zones automatiquement et sans délai. Les données sont sauvegardées de manière asynchrone dans une région géographiquement séparée. Cette sauvegarde réduit l’effet d’une panne de région complète en réduisant la perte de données. Après une panne de région complète, vous pouvez restaurer manuellement les opérations dans une autre région. Toutefois, les processus de récupération peuvent être complexes et la restauration manuelle dans l’autre région peut prendre du temps.
Optimisation des coûts	Coût modéré. En règle générale, l’ajout d’une sauvegarde à une autre région ne coûte que légèrement plus cher que l’implémentation de la redondance de zone.
Efficacité des performances	Pour la plupart des charges de travail :performances acceptables. Cette approche est susceptible d’offrir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence :performances faibles. Certains composants peuvent être sensibles à la latence en raison du trafic interzone ou du temps de réplication des données.
Excellence opérationnelle	Pendant une panne de zone de disponibilité :efficacité opérationnelle élevée. Le basculement est de la responsabilité de Microsoft et se produit automatiquement. Pendant une panne régionale :faible efficacité opérationnelle. Le basculement est votre responsabilité et peut nécessiter des opérations manuelles et des redéploiements.

Ce tableau récapitule certaines des préoccupations d’un point de vue architectural :

Problème d’architecture	Impact
Conformité à la résidence des données	Dépend de la sélection de la région. Les données sont stockées principalement dans la région Azure que vous spécifiez, mais vous devez sélectionner une autre région pour stocker vos sauvegardes. Sélectionnez une région compatible avec vos exigences de résidence des données.
Disponibilité régionale	Régions avec des zones de disponibilité. Cette approche est disponible dans n’importe quelle région qui prend en charge les zones de disponibilité.

Approche de déploiement 4 : déploiements multirégions

Vous pouvez utiliser plusieurs régions Azure ensemble pour distribuer votre solution sur une large zone géographique. Vous pouvez utiliser cette approche multirégion pour améliorer la fiabilité de votre solution ou pour prendre en charge les utilisateurs géographiquement distribués. En déployant dans plusieurs régions, vous réduisez également le risque de rencontrer une contrainte de capacité de ressources temporaire dans une seule région. Si la résidence des données est une préoccupation importante pour votre solution, examinez attentivement les régions que vous utilisez pour vous assurer que vos données sont stockées uniquement dans des emplacements qui répondent à vos besoins.

Régions actives et passives

Les architectures multirégions sont complexes et il existe de nombreuses façons de concevoir une solution multirégion. Pour certaines charges de travail, il est logique que plusieurs régions traitent activement les demandes simultanément (déploiements actifs-actifs). Pour les autres charges de travail, il est préférable de désigner une région primaire et d’utiliser une ou plusieurs régions secondaires pour le basculement (déploiements actifs/passifs). Cette section se concentre sur le deuxième scénario, dans lequel une région est active et une autre est passive. Pour plus d’informations sur les solutions multirégions actives/actives, consultez Modèle d’empreintes de déploiement et Modèle géodé.

Réplication des données

La communication entre les régions est beaucoup plus lente que la communication au sein d’une région. En général, une plus grande distance géographique entre deux régions entraîne une latence réseau plus importante en raison de la distance physique plus longue que les données doivent parcourir. Consultez Statistiques de latence aller-retour du réseau Azure pour connaître la latence réseau attendue lorsque vous vous connectez entre deux régions.

La latence réseau interrégion peut affecter considérablement la conception de votre solution, car vous devez soigneusement réfléchir à la façon dont la latence supplémentaire affecte la réplication des données et d’autres transactions. Pour de nombreuses solutions, une architecture interrégion nécessite une réplication asynchrone pour réduire l’effet du trafic interrégion sur les performances.

Réplication asynchrone des données

Lorsque vous implémentez la réplication asynchrone entre les régions, votre application n’attend pas que toutes les régions reconnaissent une modification. Une fois la modification validée dans la région primaire, la transaction est considérée comme terminée. La modification est répliquée dans les régions secondaires ultérieurement. Cette approche garantit que la latence de connexion interrégion n’affecte pas directement les performances de l’application. Toutefois, en raison du retard de réplication, une panne à l’échelle de la région peut entraîner une perte de données. Cette perte de données peut se produire parce qu’une région peut rencontrer une panne une fois qu’une écriture est terminée dans la région primaire, mais avant que la modification ne puisse être répliquée dans une autre région.

Ce tableau récapitule certaines des préoccupations relatives aux piliers :

Pilier	Impact
Fiabilité	Haute fiabilité. La solution est résiliente à une panne d’un centre de données, d’une zone de disponibilité ou d’une région entière. Les données sont répliquées, mais peuvent ne pas être synchrones, de sorte qu’une perte de données est possible dans un scénario de basculement.
Optimisation des coûts	Coût élevé. Vous devez déployer des ressources distinctes dans chaque région, et chaque ressource entraîne des coûts de déploiement et de maintenance. La réplication des données entre les régions peut également entraîner des coûts importants.
Efficacité des performances	Performances élevées. Les demandes d’application ne nécessitent pas de trafic inter-régions, de sorte que le trafic est généralement à faible latence.
Excellence opérationnelle	Faible efficacité opérationnelle. Vous devez déployer et gérer des ressources dans plusieurs régions. Vous êtes également responsable du basculement entre les régions lors d’une panne régionale.

Ce tableau résume certaines des préoccupations d’un point de vue architectural :

Problème architectural	Impact
Conformité avec la résidence des données	Dépend de la sélection de la région. Cette approche vous oblige à sélectionner plusieurs régions dans lesquelles s’exécuter votre charge de travail. Choisissez des régions compatibles avec vos exigences de résidence des données.
Disponibilité régionale	De nombreuses régions Azure sont jumelées. Certains services Azure utilisent des régions jumelées pour répliquer automatiquement les données. Si vous exécutez votre charge de travail dans une région qui n’a pas de paire, vous devrez peut-être utiliser une approche différente pour répliquer vos données.

Réplication synchrone des données

Si vous implémentez une solution multirégion synchrone, votre application doit attendre que les opérations d’écriture se terminent dans chaque région Azure avant que la transaction soit considérée comme terminée. La latence engendrée par l’attente d’opérations d’écriture dépend de la distance entre les régions. Pour de nombreuses charges de travail, la latence entre régions peut rendre la réplication synchrone trop lente pour être utile.

Ce tableau récapitule certaines des préoccupations des piliers :

Pilier	Impact
Fiabilité	Très grande fiabilité. La solution est résiliente à une panne d’un centre de données, d’une zone de disponibilité ou d’une région entière. Les données étant toujours synchronisées entre les régions, même si une perte de région complète se produit, vos données sont disponibles et complètes dans une autre région.
Optimisation des coûts	Coût élevé. Vous devez déployer des ressources distinctes dans chaque région, et chaque ressource entraîne des coûts de déploiement et de maintenance. La réplication des données entre les régions peut également entraîner des coûts importants.
Efficacité des performances	Faibles performances. Les demandes d’application nécessitent un trafic inter-régions. Selon la distance entre les régions, la réplication synchrone peut ajouter une latence significative aux requêtes.
Excellence opérationnelle	Faible efficacité opérationnelle. Vous devez déployer et gérer des ressources dans plusieurs régions. Vous êtes également responsable du basculement entre les régions lors d’une panne régionale.

Ce tableau résume certaines des préoccupations d’un point de vue architectural :

Problème architectural	Impact
Conformité avec la résidence des données	Dépend de la sélection de la région. Cette approche vous oblige à sélectionner plusieurs régions dans lesquelles s’exécuter votre charge de travail. Sélectionnez les régions compatibles avec vos exigences de résidence des données.
Disponibilité régionale	De nombreuses régions Azure sont jumelées. Certains services Azure utilisent des régions jumelées pour répliquer automatiquement les données. Si vous exécutez votre charge de travail dans une région qui n’a pas de paire, vous devrez peut-être utiliser une approche différente pour répliquer vos données.

Architectures de région

Lorsque vous concevez une solution multirégion, déterminez si les régions Azure que vous envisagez d’utiliser sont jumelées.

Vous pouvez créer une solution multirégion même si les régions ne sont pas jumelées. Toutefois, les approches que vous utilisez pour implémenter une architecture multirégion peuvent être différentes. Par exemple, dans Stockage Azure, vous pouvez utiliser le stockage géoredondant (GRS) avec des régions jumelées. Si GRS n’est pas disponible, envisagez d’utiliser des fonctionnalités telles que la réplication d’objets stockage Azure ou de concevoir votre application pour écrire dans plusieurs régions.

Combiner des approches multizones et multirégions

Vous devez combiner des instructions multizones et multirégions si vos besoins métier exigent une telle solution. Par exemple, vous pouvez déployer des composants redondants interzone dans chaque région et configurer la réplication entre les régions. Pour certaines solutions, cette approche offre un très haut degré de fiabilité. Toutefois, la configuration de ce type d’approche peut être compliquée et cette approche peut être coûteuse.

Important

Les charges de travail critiques doivent utiliser plusieurs zones de disponibilité et plusieurs régions. Pour plus d’informations sur les considérations que vous devez prendre en compte lors de la conception de charges de travail stratégiques, consultez la documentation relative aux charges de travail stratégiques.

Comment les services Azure prennent en charge les approches de déploiement

Il est important de comprendre les détails spécifiques des services Azure que vous utilisez. Par exemple, certains services Azure nécessitent que vous configuriez leur configuration de zone de disponibilité lorsque vous déployez la ressource pour la première fois, tandis que d’autres prennent en charge la modification de l’approche de déploiement ultérieurement. De même, certaines fonctionnalités de service peuvent ne pas être disponibles avec chaque approche de déploiement.

Pour en savoir plus sur les options et approches de déploiement spécifiques à prendre en compte pour chaque service Azure, visitez le hub de fiabilité.

Exemples

Cette section décrit certains cas d’usage courants et les exigences clés que vous devez généralement prendre en compte pour chaque charge de travail. Pour chaque charge de travail, une ou plusieurs approches de déploiement suggérées sont fournies, en fonction des exigences et des approches décrites dans cet article.

Application métier pour une entreprise

Contoso, Ltd., est une grande entreprise de fabrication. L’entreprise implémente une application métier pour gérer certains composants de ses processus financiers.

Exigences métier : les informations que le système gère sont difficiles à remplacer, de sorte que les données doivent être conservées de manière fiable. Les architectes disent que le système doit entraîner le moins de temps d’arrêt et aussi peu de perte de données que possible. Les employés de Contoso utilisent le système tout au long de la journée de travail, de sorte que des performances élevées sont importantes pour éviter que les membres de l’équipe n’attendent. Le coût est également un problème, car l’équipe financière doit payer pour la solution.

Approche suggérée : Le déploiement redondant interzone avec sauvegarde dans plusieurs régions offre plusieurs couches de résilience avec des performances élevées.

Application interne

Fourth Coffee est une petite entreprise. L’entreprise développe une nouvelle application interne que les employés peuvent utiliser pour envoyer des feuilles de temps.

Exigences métier : Pour cette charge de travail, l’efficacité des coûts est une préoccupation principale. Fourth Coffee a évalué l’impact sur l’entreprise des temps d’arrêt et a décidé que l’application n’avait pas besoin de hiérarchiser la résilience ou les performances. L’entreprise accepte le risque qu’une panne dans une zone ou une région de disponibilité Azure rende l’application temporairement indisponible.

Approches suggérées :

• Le déploiement localement redondant avec des sauvegardes entre régions a le coût le plus faible, mais présente également des risques importants.
• Le déploiement redondant interzone avec sauvegarde entre les régions offre une meilleure résilience, mais à un coût légèrement plus élevé.

Migration d’applications héritées

Fabrikam, Inc., migre une application héritée d’un centre de données local vers Azure. L’implémentation utilise une approche IaaS basée sur des machines virtuelles. L’application n’a pas été conçue pour un environnement cloud, et la communication entre la couche Application et la base de données est très bavard.

Exigences métier : les performances sont une priorité pour cette application. La résilience est également importante, et l’application doit continuer à fonctionner même si un centre de données Azure rencontre une panne.

Approche suggérée :

• Fabrikan doit d’abord essayer un déploiement redondant interzone. Ils doivent vérifier que les performances répondent à leurs exigences.
• Si les performances de la solution redondante interzone ne sont pas acceptables, envisagez un déploiement zonnal (épinglé), avec des déploiements passifs sur plusieurs zones de disponibilité (récupération d’urgence dans la région).

Application de soins de santé

Lamna Healthcare Company implémente un nouveau système d’enregistrement d’intégrité électronique sur Azure.

Exigences métier : En raison de la nature des données que cette solution stocke, la résidence des données est d’une importance cruciale. Lamna fonctionne dans un cadre réglementaire strict qui exige que les données restent dans un emplacement spécifique.

Approches suggérées :

• Déploiement multizone multirégion, s’il existe plusieurs régions qui répondent aux exigences de résidence des données de Lamna.
• S’il n’existe qu’une seule région qui répond à ses besoins, envisagez un déploiement redondant interzone ou un déploiement redondant interzone avec sauvegarde entre les régions fournit une solution à région unique

Système bancaire

Woodgrove Bank exécute ses opérations bancaires de base à partir d’une solution de grande taille déployée sur Azure.

Exigences métier : il s’agit d’un système stratégique. Toutes les pannes peuvent avoir un impact financier majeur pour les clients. Par conséquent, woodgrove Bank a une très faible tolérance au risque. Le système a besoin du niveau de fiabilité le plus élevé possible, et l’architecture doit atténuer le risque de défaillances pouvant être atténuées.

Approche suggérée : Pour un système stratégique, utilisez un déploiement multizone multirégion. Assurez-vous que les régions correspondent aux exigences de résidence des données de l’entreprise.

SaaS (software as a service)

Proseware, Inc., crée des logiciels utilisés par les entreprises du monde entier. La base d’utilisateurs de l’entreprise est largement distribuée géographiquement.

Exigences métier : Proseware doit permettre à chacun de ses clients de choisir une région de déploiement proche du client. L’activation de ce choix est importante pour la latence et pour les exigences de résidence des données des clients.

Approches suggérées :

• Un déploiement multizone multirégion est généralement un bon choix pour un fournisseur SaaS, en particulier lorsqu’il est utilisé dans le modèle Empreintes de déploiement.
• Un déploiement redondant interrégion unique conjointement avec une solution d’accélération du trafic global, comme Azure Front Door.

Liens connexes

Voici quelques architectures de référence et des exemples de scénarios pour les solutions multizones et multirégions :

• Application web redondante interzone de base hautement disponible
• Application web multirégion hautement disponible
• Application multiniveau multirégion
• Application web multiniveau conçue pour la haute disponibilité/reprise d’activité

De nombreux services Azure fournissent des conseils sur l’utilisation de plusieurs zones de disponibilité, notamment les exemples suivants :

• Azure Site Recovery : Activer la récupération d’urgence des machines virtuelles Azure entre les zones de disponibilité
• Azure NetApp Files : Comprendre la réplication interzone de Azure NetApp Files
• Redondance de Stockage Azure

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de fiabilité