Recommandations relatives à l’utilisation des zones de disponibilité et des régions
S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :
| RE :05 | Ajoutez la redondance à différents niveaux, notamment 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 cibles de fiabilité identifiées. |
|---|
Guides connexes : Redondance de conception | multirégion 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 plusieurs zones de disponibilité dans une région ou déployer 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 principales exigences métier 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 piliers principaux du Framework Azure Well-Architected.
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 opérer dans plusieurs régions géographiques. Votre choix de la façon dont vous utilisez des régions et des 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 dans une zone plus distribuée géographiquement, vous pouvez obtenir une résilience plus élevée.
- 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, ce qui est généralement plus élevé lorsque vous avez des exigences métier complètes.
- Efficacité des performances : les zones de disponibilité sont connectées par le biais d’une liaison réseau à bande passante élevée et à faible latence, qui est suffisante pour la plupart des charges de travail afin d’activer la réplication et la communication synchrones entre les zones. Toutefois, si votre charge de travail a été testée et est sensible à la latence réseau entre les zones, vous devrez peut-être envisager de localiser physiquement les composants de votre charge de travail de façon à réduire la latence lorsqu’elles communiquent.
- Excellence opérationnelle : une architecture complexe prend 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 requises. 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 OE :05 en tant que code, l’automatisation des tâches OE :09, la conception d’OE :10 Automation et les pratiques de déploiement OE :11.
Toutefois, vous concevez votre solution, le pilier sécurité s’applique. En règle générale, les décisions relatives à l’utilisation et à la façon dont vous utilisez 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 des compromis. Vous pouvez étendre cette approche avec la 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 tenez compte des 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 trafic principal et traite le trafic, et une ou plusieurs instances secondaires sont déployées pour servir le trafic si le serveur principal n’est pas disponible. |
| Réplication asynchrone | Approche de réplication des données dans laquelle les données sont écrites et validées à un seul emplacement. 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 son propre alimentation, son refroidissement et son infrastructure réseau. De nombreuses régions prennent en charge les zones de disponibilité. |
| Centre de données | Installation qui contient des serveurs, des équipements 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 permettre 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 | Approche de réplication des données dans laquelle les données sont écrites et validées à plusieurs emplacements. Chaque emplacement doit accuser réception de 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 si une zone subit une panne. |
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, également appelées architectures de région.
De nombreuses régions Azure fournissent des zones de disponibilité, qui sont séparées par des groupes de centres de données. Dans une région, les zones de disponibilité sont suffisamment proches pour avoir des connexions à faible latence à d’autres zones de disponibilité, mais elles sont assez éloignées pour réduire la probabilité que plusieurs personnes soient affectées par des pannes locales ou des conditions météorologiques. Les zones de disponibilité disposent d’une alimentation, d’un système de refroidissement et d’une infrastructure réseau indépendants. Ils sont conçus de sorte que, si une zone subit une panne, les services régionaux, la capacité et la haute disponibilité soient pris en charge par les zones restantes.
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 déployez 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 des données dans des centres de données physiques distincts dans une grande région 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 requêtes entre les zones. Si une panne survient dans une zone de disponibilité donnée, vous êtes responsable du basculement vers une autre zone de disponibilité.
- Les ressources redondantes interzones sont réparties entre plusieurs zones de disponibilité. Microsoft gère la répartition des requêtes et la réplication des données entre les zones. Si une panne survient dans une zone de disponibilité donnée, Microsoft gère automatiquement le basculement.
Les services Azure prennent en charge l’une ou l’autre de ces approches. 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 des zones de disponibilité, consultez les 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 sont les moins perturbatrices pour vous. Par exemple, nous souhaitons déployer des mises à jour sur un seul fuseau 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 finalement à 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 de surprovisionner - déployer davantage d’instances d’une ressource , afin que certaines instances restent disponibles alors que d’autres instances sont mises à niveau. Pour plus d’informations sur la façon dont Azure déploie des mises à jour, consultez Amélioration 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 des régions et des zones de disponibilité, consultez Quelles sont les régions Azure et les zones de disponibilité ?
Comprendre les responsabilités partagées
Le principe de responsabilité partagée décrit comment les responsabilités sont divisées entre le fournisseur de cloud (Microsoft) et vous. Selon le type de services que vous utilisez, vous pouvez assumer plus ou moins la responsabilité de 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 recommander des pratiques 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’une zone de disponibilité ou un basculement de région se produit, car le basculement entre les zones ou régions nécessite généralement que votre application recommencez les connexions aux services.
Identifier les exigences d’entreprise et de charge de travail clés
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 de risque différents. Même au sein d’une organisation, la tolérance aux risques est souvent différente pour chaque charge de travail. La plupart des charges de travail n’ont pas besoin d’une haute disponibilité. Toutefois, certaines charges de travail sont si importantes qu’il vaut même la peine d’atténuer les risques qui ne sont pas 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é. Toute stratégie de résilience doit tenir compte de ces risques. |
| Panne du centre de données | Panne de l’alimentation, du refroidissement ou du réseau sur l’ensemble d’un centre de données. Catastrophe naturelle dans une partie d’une région métropolitaine. |
Moyenne |
| Panne de région | Catastrophe naturelle majeure qui affecte 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. |
Bas |
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 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 cibles de fiabilité élevées, 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 à atténuer.
Exigences en matière de résilience
Il est important de comprendre les exigences de résilience de votre charge de travail, notamment l’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO). Ces objectifs vous aident à déterminer les approches à exclure. Si vous n’avez pas d’exigences claires, vous ne pouvez pas prendre de décision éclairée sur l’approche à suivre. Pour plus d’informations, consultez Les exigences fonctionnelles et non fonctionnelles cibles.
Objectifs de niveau de service
Vous devez comprendre l’objectif de niveau de service (SLO) attendu de votre solution. Par exemple, vous pouvez avoir une exigence métier que votre solution doit respecter 99,9 % de temps d’activité.
Azure fournit des contrats de niveau de service (SLA) pour chaque service. Un contrat SLA indique le niveau de temps d’activité attendu du service et les conditions que vous devez respecter pour atteindre ce contrat SLA attendu. Toutefois, n’oubliez pas que la façon dont un contrat SLA Azure indique que 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 règle générale, plus vous générez de redondance dans votre solution, plus votre SLO est susceptible d’être. De nombreux services Azure fournissent des contrats SLA plus élevés lorsque vous déployez des services dans une configuration interzone redondante 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 placent 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, une organisation peut décider d’adopter une stratégie de résidence des données pour éviter les problèmes 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 à une seule région ou utiliser un sous-ensemble de régions et de services Azure.
Remarque
Évitez d’effectuer des hypothèses non fondées sur vos exigences de résidence des données. Si vous devez respecter des normes réglementaires spécifiques, vérifiez ce que ces normes spécifient réellement.
Emplacement utilisateur
En comprenant l’emplacement de vos utilisateurs, vous pouvez prendre une décision éclairée sur la façon d’optimiser la latence et la fiabilité de vos besoins. Azure propose de nombreuses options pour prendre en charge une base d’utilisateurs géographiquement dispersée.
Si vos utilisateurs sont concentrés dans un domaine, un déploiement à 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 à 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 Tampons de déploiement ou le modèle Geodes, 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 atteindre vos besoins au sein d’une seule région à l’aide de l’accélération globale du trafic, comme l’accélération fournie par Azure Front Door.
Budget
Si vous utilisez un budget limité, il est important de prendre en compte les coûts liés au 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 des coûts opérationnels de gestion de ressources supplémentaires et d’un environnement plus complexe.
Complexité
Il est recommandé d’éviter toute complexité inutile dans votre architecture de solution. Plus vous introduisez de complexité, plus il devient difficile de prendre des décisions sur votre architecture. Les architectures complexes sont plus difficiles à utiliser, plus difficiles à sécuriser et souvent moins performantes. Suivez le principe de simplicité.
Facilitation 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 d’elles 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 certain 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 quelques-unes des préoccupations des 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 comment elles affectent votre architecture :
| Préoccupation architecturale | 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 zones de disponibilité | Régions avec 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 lorsque vous déployez vos ressources, Azure ne garantit pas si les ressources sont déployées dans un centre de données unique ou réparties entre plusieurs centres de données de la région. Dans certains cas, Azure peut également déplacer votre ressource entre les zones de disponibilité.
La plupart des ressources Azure sont hautement disponibles par défaut, avec des contrats 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 subit une panne, il est possible que votre charge de travail soit affectée. Si c’est le cas, votre solution peut être indisponible ou vos données peuvent être perdues.
Pour les charges de travail hautement sensibles à la latence, cette approche peut également entraîner des performances inférieures. 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 certaine latence pour le trafic intrarégion. Azure peut également déplacer de manière transparente vos instances de service entre les zones de disponibilité, ce qui peut affecter légèrement les performances. Toutefois, ce n’est pas une préoccupation pour la plupart des charges de travail.
Ce tableau récapitule quelques-unes des préoccupations des piliers :
| Pilier | Impact |
|---|---|
| Fiabilité | Faible fiabilité. Les services sont soumis à des pannes si un centre de données échoue. Toutefois, vous pouvez créer une application pour qu’elle soit résiliente à d’autres types d’échecs. |
| Optimisation des coûts | Coût le plus bas. Vous n’avez besoin que d’une seule instance de chaque ressource et vous n’avez aucun coût de bande passante interrégion. |
| Efficacité des performances | Pour la plupart des charges de travail : performances acceptables. Cette approche est susceptible de fournir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence : faible performance. Les composants ne sont pas assurés d’être situés 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. Vous devez uniquement déployer et gérer une seule instance de chaque ressource. |
Ce tableau récapitule certaines des préoccupations du point de vue architectural :
| Préoccupation architecturale | Impact |
|---|---|
| Conformité à la résidence des données | Élevé. 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é. Cette approche peut être utilisée dans n’importe quelle région Azure. |
Déploiements localement redondants avec sauvegarde entre 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 supplémentaire de protection 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 IaC (Infrastructure-as-Code) afin de pouvoir rapidement 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 requises pour restaurer votre solution à un état de travail.
- Point de récupération : votre fréquence de sauvegarde détermine la quantité de perte de données que vous pouvez rencontrer (votre point de récupération). En règle générale, vous pouvez contrôler la fréquence des sauvegardes afin de pouvoir répondre à votre RPO.
Ce tableau récapitule quelques-unes des préoccupations des piliers :
| Pilier | Impact |
|---|---|
| Fiabilité | Fiabilité modérée. Les services sont soumis à des pannes si un centre de données échoue. 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. Dans une panne complète de région, vous pouvez restaurer manuellement des opérations dans une autre région. Toutefois, les processus de récupération peuvent être complexes et il peut prendre du temps pour restaurer manuellement dans l’autre région. |
| Optimisation des coûts | Coût faible. En règle générale, l’ajout d’une sauvegarde à une autre région coûte un peu plus 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 de fournir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence : faible performance. Les composants ne sont pas assurés d’être situés 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 du point de vue architectural :
| Préoccupation architecturale | 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é. 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 zonal , 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é par zone.
Une approche zonale réduit la latence entre vos composants. Toutefois, en soi, elle 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 router 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 prendre en compte la façon dont vous routez le trafic entre les instances de 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 du tout.
Lorsque vous utilisez un modèle de déploiement zonal, vous prenez de nombreuses responsabilités :
- Vous devez déployer des ressources dans chaque zone de disponibilité et 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, par exemple 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 s’il faut 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 sur plusieurs zones de disponibilité est parfois appelé dr dans la région ou la récupération d’urgence metro.
Ce tableau récapitule quelques-unes des préoccupations des piliers :
| Pilier | Impact |
|---|---|
| Fiabilité | Lors du déploiement dans une seule zone de disponibilité : faible fiabilité. Un déploiement zonal ne fournit 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. Lorsqu’il est déployé 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 | Lors du déploiement dans une seule zone de disponibilité : coût faible. Un déploiement à zone unique ne nécessite qu’une seule instance de chaque ressource. Lors du déploiement dans plusieurs zones de disponibilité : coût élevé. Vous déployez plusieurs instances des ressources, chacune d’elles étant facturées séparément. |
| Efficacité des performances | Performances élevées. La latence peut être très faible lorsque les composants qui servent 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 des données entre des zones de disponibilité. Lors d’une panne de zone de disponibilité, le basculement est votre responsabilité. |
Ce tableau récapitule certaines des préoccupations du point de vue architectural :
| Préoccupation architecturale | Impact |
|---|---|
| Conformité à la résidence des données | Élevé. 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 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 le service de zone de disponibilité et la prise en charge régionale.
Lorsque vous planifiez un déploiement zonal, 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, la couche Application est répartie sur plusieurs zones de disponibilité. Lorsque les requêtes arrivent, un équilibreur de charge intégré au service (qui s’étend sur les zones de disponibilité) répartit 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 des instances dans les zones de disponibilité saines.
Votre niveau de stockage est également réparti entre 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 est considérée comme terminée uniquement lorsque toutes ces modifications sont 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 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 sensibles à la latence, la réplication synchrone entre les zones de disponibilité peut affecter les performances de l’application.
Ce tableau récapitule quelques-unes des préoccupations des piliers :
| Pilier | Impact |
|---|---|
| Fiabilité | Fiabilité élevée. 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 risquez d’entraîner des coûts pour des niveaux de service plus élevés afin d’activer la redondance de zone. |
| Efficacité des performances | Pour la plupart des charges de travail : performances acceptables. Cette approche est susceptible de fournir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence : faible performance. 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. En règle générale, vous devez 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 la responsabilité de Microsoft et se produit automatiquement. |
Ce tableau récapitule certaines des préoccupations du point de vue architectural :
| Préoccupation architecturale | Impact |
|---|---|
| Conformité à la résidence des données | Élevé. 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 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 le service de zone de disponibilité et la 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 vers 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 de région complète.
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 que vous puissiez rapidement redéployer dans une autre région lors d’un 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 si une panne se produit. Planifiez et répétez les étapes requises pour restaurer votre solution dans un état de travail.
Point de récupération : votre fréquence de sauvegarde détermine la quantité de perte de données que vous pouvez rencontrer (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 quelques-unes des préoccupations des 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 automatiquement entre les zones 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 complète de région, vous pouvez restaurer manuellement des opérations dans une autre région. Toutefois, les processus de récupération peuvent être complexes et il peut prendre du temps pour restaurer manuellement dans l’autre région. |
| 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 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 de fournir des performances satisfaisantes. Pour les charges de travail hautement sensibles à la latence : faible performance. Certains composants peuvent être sensibles à la latence en raison du trafic interzone ou du temps de réplication des données. |
| Excellence opérationnelle | Lors d’une panne de zone de disponibilité : efficacité opérationnelle élevée. Le basculement est la responsabilité de Microsoft et se produit automatiquement. Lors d’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 du point de vue architectural :
| Préoccupation architecturale | 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 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 dans une vaste 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 que vous rencontrerez une contrainte de capacité de ressource 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 judicieux que plusieurs régions traitent activement les demandes simultanément (déploiements 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 et 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 le modèle Tampons de déploiement et le modèle Geode.
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 élevée en raison de la plus longue distance physique nécessaire aux données. Consultez les statistiques de latence des allers-retours réseau Azure pour 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 examiner attentivement 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 délai 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, car 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 quelques-unes des préoccupations des piliers :
| Pilier | Impact |
|---|---|
| Fiabilité | Fiabilité élevée. 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 que certaines pertes de données sont possibles 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égion. Le trafic est donc généralement faible. |
| 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écapitule certaines des préoccupations du point de vue architectural :
| Préoccupation architecturale | Impact |
|---|---|
| Conformité à 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 pour que votre charge de travail s’exécute. Choisissez 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. |
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 interrégion peut rendre la réplication synchrone trop lente pour être utile.
Ce tableau récapitule quelques-unes des préoccupations des piliers :
| Pilier | Impact |
|---|---|
| Fiabilité | Très 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 toujours synchronisées entre les régions. Par conséquent, même si une perte complète de région se produit, vos données sont disponibles et terminées 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 | Performances faibles. Les demandes d’application nécessitent un trafic interrégion. 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écapitule certaines des préoccupations du point de vue architectural :
| Préoccupation architecturale | Impact |
|---|---|
| Conformité à 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 pour que votre charge de travail s’exécute. 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 Stockage Azure réplication d’objets ou concevoir votre application pour écrire dans plusieurs régions.
Combiner des approches multizones et multirégions
Vous devez combiner des instructions multizone et multirégion si vos besoins métier demandent 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 degré de fiabilité très élevé. 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 sur les charges de travail critiques.
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 configurez 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 subir autant de temps d’arrêt et que la perte de données est aussi faible que possible. Les employés de Contoso utilisent le système tout au long du travail, de sorte que les performances élevées sont importantes pour éviter d’attendre les membres de l’équipe. Le coût est également une préoccupation, car l’équipe financière doit payer pour la solution.
Approche suggérée : le déploiement redondant interzone avec sauvegarde entre les régions fournit plusieurs couches de résilience avec des performances élevées.
Application interne
Le quatrième café est une petite entreprise. L’entreprise développe une nouvelle application interne que les employés peuvent utiliser pour soumettre des feuilles de temps.
Exigences métier : pour cette charge de travail, l’efficacité des coûts est une préoccupation principale. Le quatrième café a évalué l’impact commercial du temps d’arrêt et a décidé que l’application n’a pas besoin de hiérarchiser la résilience ou les performances. La société accepte le risque qu’une panne dans une zone de disponibilité Ou une région Azure puisse rendre l’application temporairement indisponible.
Approches suggérées :
- Le déploiement localement redondant avec des sauvegardes entre régions présente le coût le plus bas, mais présente également des risques importants.
- Le déploiement redondant interzone avec sauvegarde entre régions offre une meilleure résilience, mais à un coût légèrement plus élevé.
Migration d’application héritée
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 zonal (épinglé), avec des déploiements passifs sur plusieurs zones de disponibilité (récupération d’urgence dans la région).
Application de santé
Lamna Healthcare Company implémente un nouveau système de dossiers d’intégrité électronique sur Azure.
Exigences métier : en raison de la nature des données stockées par cette solution, la résidence des données est extrêmement importante. Lamna opère dans un cadre réglementaire strict qui impose que les données restent dans un emplacement spécifique.
Approches suggérées :
- Déploiement multirégion multizone, s’il existe plusieurs régions qui correspondent aux exigences de résidence des données de Lamna.
- S’il n’existe qu’une seule région qui répond à leurs besoins, envisagez un déploiement redondant interzone ou un déploiement redondant interzone avec une sauvegarde entre les régions fournit une solution à une seule région.
Système bancaire
Woodgrove Bank exécute ses opérations bancaires de base à partir d’une grande solution 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 tolérance à risque très faible. 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 multirégion multizone. 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 des 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 multirégion multizone est généralement un bon choix pour un fournisseur SaaS, en particulier lorsqu’il est utilisé dans le modèle Tampons 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 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 d’Azure NetApp Files
- Redondance de Stockage Azure
Liste de contrôle de fiabilité
Reportez-vous à l’ensemble complet de recommandations.