Recommandations pour la conception de la redondance

  • Article

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

RE :05 Ajoutez la 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 cibles de fiabilité identifiées.

Guides connexes :Conception multirégion à | haute disponibilitéà l’aide de zones de disponibilité et de régions

Ce guide décrit les recommandations relatives à l’ajout de la redondance dans les flux critiques aux différentes couches de charge de travail, ce qui optimise la résilience. Répondez aux exigences de vos objectifs de fiabilité définis en appliquant les niveaux de redondance appropriés à vos niveaux de calcul, de données, de mise en réseau et d’autres niveaux d’infrastructure. Appliquez cette redondance pour donner à votre charge de travail une base solide et fiable sur laquelle s’appuyer. Lorsque vous créez votre charge de travail sans redondance d’infrastructure, il existe un risque élevé de temps d’arrêt prolongé en raison de défaillances potentielles.

Définitions

Terme Définition
Redondance Implémentation de plusieurs instances identiques d’un composant de charge de travail.
Persistance polyglotte Concept d’utilisation de différentes technologies de stockage par la même application ou solution pour tirer parti des meilleures fonctionnalités de chaque composant.
Cohérence des données La mesure de la synchronisation ou de l’insynchronisation d’un jeu de données donné s’effectue sur plusieurs magasins.
Partitionnement Processus de division physique des données en magasins de données distincts.
Partition Stratégie de partitionnement de base de données horizontale qui prend en charge plusieurs instances de stockage avec un schéma commun. Les données ne sont pas répliquées dans toutes les instances.

Stratégies de conception

Dans le contexte de la fiabilité, utilisez la redondance pour contenir les problèmes qui affectent une seule ressource et vous assurer que ces problèmes n’affectent pas la fiabilité de l’ensemble du système. Utilisez les informations que vous avez identifiées sur vos flux critiques et vos cibles de fiabilité pour prendre des décisions éclairées qui sont nécessaires pour la redondance de chaque flux.

Par exemple, vous pouvez avoir plusieurs nœuds de serveur web en cours d’exécution en même temps. Le caractère critique du flux pris en charge peut nécessiter que tous les utilisateurs disposent de réplicas prêts à accepter le trafic s’il existe un problème qui affecte l’ensemble du pool, par exemple une panne régionale. Sinon, étant donné que les problèmes à grande échelle sont rares et qu’il est coûteux de déployer un ensemble entier de réplicas, vous pouvez déployer un nombre limité de réplicas afin que le flux fonctionne dans un état dégradé jusqu’à ce que vous résolvez le problème.

Lorsque vous concevez la redondance dans le contexte de l’efficacité des performances, répartissez la charge sur plusieurs nœuds redondants pour vous assurer que chaque nœud fonctionne de manière optimale. Dans le contexte de la fiabilité, générez une capacité de réserve pour absorber les défaillances ou dysfonctionnements qui affectent un ou plusieurs nœuds. Assurez-vous que la capacité de réserve peut absorber les défaillances pendant tout le temps nécessaire à la récupération des nœuds affectés. Avec cette distinction à l’esprit, les deux stratégies doivent fonctionner ensemble. Si vous répartissez le trafic sur deux nœuds à des fins de performances et qu’ils s’exécutent à 60 % d’utilisation et qu’un nœud échoue, votre nœud restant risque d’être submergé, car il ne peut pas fonctionner à 120 %. Répartissez le chargement avec un autre nœud pour vous assurer que vos objectifs de performances et de fiabilité sont respectés.

Compromis :

  • Plus de redondance de charge de travail équivaut à plus de coûts. Envisagez soigneusement d’ajouter une redondance et passez régulièrement en revue votre architecture pour vous assurer que vous gérez les coûts, en particulier lorsque vous utilisez le surprovisionnement. Lorsque vous utilisez le surprovisionnement comme stratégie de résilience, équilibrez-la avec une stratégie de mise à l’échelle bien définie pour réduire les inefficacités des coûts.
  • Il peut y avoir des compromis en matière de performances lorsque vous générez dans un degré élevé de redondance. Par exemple, les ressources qui se répartissent entre des zones de disponibilité ou des régions peuvent affecter les performances, car vous devez envoyer du trafic via des connexions à haute latence entre des ressources redondantes, comme des serveurs web ou des instances de base de données.
  • Différents flux au sein d’une même charge de travail peuvent avoir des exigences de fiabilité différentes. Les conceptions de redondance spécifiques aux flux peuvent potentiellement introduire de la complexité dans la conception globale.

Conception d’architecture redondante

Tenez compte de deux approches lorsque vous concevez une architecture redondante : actif-actif ou actif-passif. Choisissez votre approche en fonction de la criticité du flux utilisateur et du flux système pris en charge par les composants d’infrastructure. En termes de fiabilité, une conception active-active multirégion vous permet d’atteindre le niveau de fiabilité le plus élevé possible, mais elle est beaucoup plus coûteuse qu’une conception active-passive. Le choix des régions géographiques appropriées devient le prochain choix critique. Vous pouvez également utiliser ces approches de conception pour une seule région à l’aide de zones de disponibilité. Pour plus d’informations, consultez Recommandations pour la conception multirégion hautement disponible.

Empreintes de déploiement et unités d’échelle

Que vous déployiez dans un modèle actif-actif ou actif-passif, suivez le modèle de conception Empreintes de déploiement pour vous assurer que vous déployez votre charge de travail de manière reproductible et évolutive. Les empreintes de déploiement sont les regroupements de ressources nécessaires pour fournir votre charge de travail à un sous-ensemble donné de vos clients. Par exemple, le sous-ensemble peut être un sous-ensemble régional ou un sous-ensemble avec les mêmes exigences de confidentialité des données que votre charge de travail. Considérez chaque empreinte comme une unité d’échelle que vous pouvez dupliquer pour mettre à l’échelle votre charge de travail horizontalement ou pour effectuer des déploiements bleu-vert. Concevez votre charge de travail avec des empreintes de déploiement pour optimiser votre implémentation active-active ou active-passive pour la résilience et la charge de gestion. La planification d’un scale-out multirégion est également importante pour surmonter les contraintes de capacité de ressources temporaires potentielles dans une région.

Zones de disponibilité dans les régions Azure

Que vous déployiez une conception active-active ou active-passive, tirez parti des zones de disponibilité dans les régions actives pour optimiser pleinement votre résilience. De nombreuses régions Azure fournissent plusieurs zones de disponibilité, qui sont des groupes séparés de centres de données au sein d’une région. Selon le service Azure, vous pouvez tirer parti des zones de disponibilité en déployant des éléments de votre charge de travail de manière redondante entre des zones ou en épinglant des éléments dans des zones spécifiques. Pour plus d’informations, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

Conseils sur la couche d’infrastructure

Ressources de calcul

  • Choisissez le service de calcul approprié pour votre charge de travail. Selon le type de charge de travail que vous concevez, plusieurs options peuvent être disponibles. Recherchez les services disponibles et découvrez quels types de charges de travail fonctionnent le mieux sur un service de calcul donné. Par exemple, les charges de travail SAP sont généralement mieux adaptées aux services de calcul IaaS (Infrastructure as a Service). Pour une application conteneurisée, déterminez les fonctionnalités spécifiques que vous devez contrôler pour déterminer s’il faut utiliser Azure Kubernetes Service (AKS) ou une solution PaaS (Platform as a Service). Votre plateforme cloud gère entièrement un service PaaS.

  • Utilisez les options de calcul PaaS si vos besoins le permettent. Azure gère entièrement les services PaaS, ce qui réduit votre charge de gestion, et un degré de redondance documenté est intégré.

  • Utilisez Azure Virtual Machine Scale Sets si vous avez besoin de déployer des machines virtuelles. Avec Virtual Machine Scale Sets, vous pouvez répartir automatiquement votre calcul uniformément entre les zones de disponibilité.

  • Conservez votre couche de calcul propre de n’importe quel état, car des nœuds individuels qui traitent des requêtes peuvent être supprimés, défectueux ou remplacés à tout moment.

  • Utilisez des services redondants interzones lorsque cela est possible pour fournir une plus grande résilience sans augmenter votre charge opérationnelle.

  • Surprovisionner les ressources critiques pour atténuer les défaillances des instances redondantes, même avant le début des opérations de mise à l’échelle automatique, afin que le système continue de fonctionner après une défaillance de composant. Calculez l’effet acceptable d’une erreur lorsque vous incorporez le surprovisionnement dans votre conception de redondance. Comme pour votre processus de prise de décision en matière de redondance, vos objectifs de fiabilité et vos décisions de compromis financiers déterminent l’étendue dans laquelle vous ajoutez la capacité inutilisée avec le surapprovisionnement. Le surprovisionnement fait spécifiquement référence à un scale-out, ce qui signifie l’ajout d’instances supplémentaires d’un type de ressource de calcul donné, au lieu d’augmenter les capacités de calcul d’une instance unique. Par exemple, si vous remplacez une machine virtuelle d’une référence SKU de niveau inférieur à une référence SKU de niveau supérieur.

  • Déployez les services IaaS manuellement ou via l’automatisation dans chaque zone de disponibilité ou région dans laquelle vous envisagez d’implémenter votre solution. Certains services PaaS ont des fonctionnalités intégrées qui sont répliquées automatiquement entre les zones de disponibilité et les régions.

Ressources de données

  • Déterminez si la réplication de données synchrone ou asynchrone est nécessaire pour les fonctionnalités de votre charge de travail. Pour vous aider à effectuer cette détermination, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

  • Tenez compte du taux de croissance de vos données. Pour la planification de la capacité, planifiez la croissance des données, la rétention des données et l’archivage afin de vous assurer que vos exigences de fiabilité sont remplies à mesure que la quantité de données dans votre solution augmente.  

  • Distribuez les données géographiquement, comme pris en charge par votre service, pour réduire l’effet des défaillances localisées géographiquement.

  • Répliquez les données entre les régions géographiques pour fournir une résilience aux pannes régionales et aux défaillances catastrophiques.

  • Automatisez le basculement après une défaillance de instance de base de données. Vous pouvez configurer le basculement automatisé dans plusieurs services de données PaaS Azure. Le basculement automatisé n’est pas requis pour les magasins de données qui prennent en charge les écritures multirégions, comme Azure Cosmos DB. Pour plus d’informations, consultez Recommandations pour la conception d’une stratégie de récupération d’urgence.

  • Utilisez le meilleur magasin de données pour vos données. Adoptez la persistance polyglotte ou des solutions qui utilisent une combinaison de technologies de magasin de données. Les données incluent plus que les données d’application persistantes. Elles incluent également les journaux des applications, les événements, les messages et les caches.

  • Tenez compte des exigences de cohérence des données et utilisez la cohérence éventuelle lorsque les exigences le permettent. Lorsque les données sont distribuées, utilisez une coordination appropriée pour appliquer des garanties de cohérence fortes. La coordination peut réduire votre débit et rendre vos systèmes étroitement couplés, ce qui peut les rendre plus fragiles. Par exemple, si une opération met à jour deux bases de données, au lieu de les placer dans une seule étendue de transaction, il est préférable que le système puisse prendre en charge une cohérence éventuelle.

  • Partitionnez les données pour la disponibilité. Le partitionnement de base de données améliore la scalabilité et peut également améliorer la disponibilité. Si une partition tombe en panne, les autres partitions sont toujours accessibles. Une défaillance dans une partition n’interrompt qu’un sous-ensemble du total des transactions.

  • Si le partitionnement n’est pas une option, vous pouvez utiliser le modèle CQRS (Command and Query Responsibility Segregation) pour séparer vos modèles de données en lecture-écriture et en lecture seule. Ajoutez des instances de base de données en lecture seule redondantes pour renforcer la résilience.  

  • Comprendre les fonctionnalités intégrées de réplication et de redondance des services de plateforme avec état que vous utilisez. Pour connaître les fonctionnalités de redondance spécifiques des services de données avec état, consultez Liens connexes.

Mise en réseau

  • Choisissez une topologie de réseau fiable et évolutive. Utilisez un modèle hub-and-spoke ou un modèle Azure Virtual WAN pour vous aider à organiser votre infrastructure cloud en modèles logiques qui facilitent la création et la mise à l’échelle de votre conception de redondance.

  • Sélectionnez le service réseau approprié pour équilibrer et rediriger les demandes au sein ou entre les régions. Utilisez des services d’équilibrage de charge globaux ou redondants interzone lorsque cela est possible pour atteindre vos objectifs de fiabilité.

  • Vérifiez que vous avez alloué suffisamment d’espace d’adressage IP dans vos réseaux virtuels et sous-réseaux pour prendre en compte l’utilisation planifiée, y compris les exigences de scale-out.

  • Vérifiez que l’application peut être mise à l’échelle dans les limites de port de la plateforme d’hébergement d’application choisie. Si une application lance plusieurs connexions TCP ou UDP sortantes, elle peut épuiser tous les ports disponibles et entraîner des performances médiocres de l’application.

  • Choisissez des références SKU et configurez des services de mise en réseau qui peuvent répondre à vos besoins en bande passante et en disponibilité. Le débit d’une passerelle VPN varie en fonction de sa référence SKU. La prise en charge de la redondance de zone n’est disponible que pour certaines références SKU d’équilibreur de charge.

  • Assurez-vous que votre conception pour la gestion du DNS est basée sur la résilience et prend en charge l’infrastructure redondante.

Animation Azure

La plateforme Azure vous aide à optimiser la résilience de votre charge de travail et à ajouter une redondance en :

Facilitation Azure spécifique à DNS

  • Pour les scénarios de résolution de noms internes, utilisez des zones privées Azure DNS, qui disposent d’une redondance de zone et d’une géoredondance intégrées. Pour plus d’informations, consultez Résilience des zones privées Azure DNS.

  • Pour les scénarios de résolution de noms externes, utilisez des zones publiques Azure DNS, qui disposent d’une redondance de zone et d’une géoredondance intégrées.

  • Les services DNS Azure publics et privés sont des services globaux qui résistent aux pannes régionales, car les données de zone sont disponibles à l’échelle mondiale.

  • Pour les scénarios de résolution de noms hybrides entre les environnements locaux et cloud, utilisez Azure DNS Private Resolver. Ce service prend en charge la redondance de zone si votre charge de travail se trouve dans une région qui prend en charge les zones de disponibilité. Une panne à l’échelle de la zone ne nécessite aucune action pendant la récupération de zone. Le service se rééquilibre automatiquement pour tirer parti de la zone saine. Pour plus d’informations, consultez Résilience dans Azure DNS Private Resolver.

  • Pour éliminer un point de défaillance unique et obtenir une résolution de noms hybride plus résiliente entre les régions, déployez au moins deux résolveurs privés Azure DNS dans différentes régions. Le basculement DNS, dans un scénario de transfert conditionnel, est obtenu en affectant un programme de résolution en tant que serveur DNS principal. Affectez l’autre programme de résolution dans une autre région en tant que serveur DNS secondaire. Pour plus d’informations, consultez Configurer le basculement DNS à l’aide de résolveurs privés.

Exemple

Pour obtenir un exemple de déploiement redondant multirégion, consultez Application web redondante interzone hautement disponible de base.

Le diagramme suivant illustre un autre exemple :

Diagramme montrant l’architecture de l’implémentation de référence.

Pour en savoir plus sur la redondance, consultez les ressources suivantes :

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de fiabilité