Fiabilité extrême
Utilisez les principes de haute disponibilité et de récupération après sinistre pour concevoir une architecture en nuage extrêmement fiable.
Les systèmes à haute disponibilité sont conçus pour garantir une disponibilité et une accessibilité maximales. Pour garantir la haute disponibilité, éliminez les points de défaillance uniques de sorte que, même en cas d'échec des composants, l'application continue de s'exécuter et reste disponible.
Un plan de récupération après sinistre bien conçu permet de récupérer rapidement après un sinistre et de continuer à fournir des services à vos utilisateurs. La récupération après sinistre désigne le processus de préparation et de récupération après un sinistre. Un sinistre peut être tout événement qui met vos applications en danger, des pannes de réseau aux défaillances d'équipement et d'application aux catastrophes naturelles. Pour permettre la récupération après sinistre, déployez vos applications critiques dans plusieurs régions et utilisez la réplication asynchrone entre les régions. Planifiez la récupération après sinistre à tous les niveaux de la pile, y compris les services de réseau, de calcul, de stockage d'objets, de base de données et de surveillance.
Recommandations architecturales pour la fiabilité extrême
Nous recommandons une approche progressive pour la fiabilité extrême. Au cours de la première phase, déployez une architecture qui offre la haute disponibilité en tirant parti des domaines d'erreur au sein d'un domaine de disponibilité. Si une résilience supérieure est nécessaire, au cours de la deuxième phase, déployez une architecture couvrant plusieurs régions.
Pour plus d'informations sur les régions, les domaines de disponibilité et les domaines d'erreur, voir Régions et domaines de disponibilité.
Phase 1 : Répartir les instances entre les domaines d'erreur
Les systèmes à haute disponibilité sont conçus pour éviter les points de défaillance uniques. L'un des principes clés pour la conception d'un système à haute disponibilité consiste à répartir les instances entre plusieurs domaines d'erreur. En exploitant correctement les domaines d'erreur, vous pouvez augmenter la disponibilité des applications exécutées sur Oracle Cloud Infrastructure.
L'architecture de votre application détermine si vous devez séparer ou regrouper les instances à l'aide de domaines d'erreur.
Scénario A : Architecture d'application hautement disponible
Dans ce scénario, vous disposez d'une application hautement disponible; par exemple, deux serveurs Web et une base de données en grappe. Dans ce scénario, vous devez regrouper un serveur Web et un noeud de base de données dans un domaine d'erreur et l'autre moitié de chaque paire dans un autre domaine d'erreur. Ce positionnement garantit qu'en cas de défaillance d'un domaine d'erreur, votre application ne sera pas interrompue.
Scénario B : Architecture avec un serveur Web et une instance de base de données
Dans ce scénario, l'architecture de votre application n'est pas hautement disponible. En effet, vous disposez d'un serveur Web et d'une instance de base de données. Dans ce scénario, le serveur Web et l'instance de base de données doivent être placés dans le même domaine d'erreur afin de minimiser les interruptions pour les clients. Ce positionnement garantit que seule une défaillance de ce domaine d'erreur peut affecter l'application, ce qui assure une meilleure disponibilité globale de celle-ci.
CNS composites
Lorsque des services sont utilisés en combinaison, la disponibilité globale du système dépend de la disponibilité de chacun des sous-systèmes. Pour optimiser la disponibilité d'un système comportant plusieurs sous-composants, vous devez minimiser les dépendances entre ces sous-composants. Cela signifie que, selon l'architecture de votre application, vous pouvez obtenir une fiabilité optimale pour un effort d'ingénierie mesuré en tirant parti des domaines d'erreur d'un domaine de disponibilité, plutôt qu'en répartissant vos ressources sur l'ensemble des domaines de disponibilité.
Phase 2 : Déployer des ressources dans plusieurs régions
Pour optimiser la résilience de vos charges de travail, déployez vos charges de travail en nuage dans plusieurs régions, plutôt que dans plusieurs domaines de disponibilité.
Le déploiement vers plusieurs régions permet de réduire les risques associés à une interruption régionale, qui peut avoir une incidence sur tous les domaines de disponibilité de la région. Le déploiement dans plusieurs régions optimise également la valeur de l'effort d'ingénierie investi dans le portage des charges de travail entre plusieurs centres de données.
Scénario C : Architecture à plusieurs régions
Dans ce scénario, votre architecture réplique la même pile dans deux régions.
Pour fournir une source de données cohérente dans les deux régions, utilisez des fonctions de réplication telles que GoldenGate pour la couche de données, Autonomous Data Guard pour la couche de base de données et des politiques de réplication du stockage d'objets sur le seau source qui identifient la région et le seau vers lequel effectuer la réplication.
Pour la couche frontale et la couche d'application, créez un équilibreur de charge et configurez des fonctions de vérification d'état sur les ressources dorsales déployées dans les domaines d'erreur des deux régions. Lorsque vous déployez une nouvelle application en production, déployez-la vers des instances dans les deux régions.
Informations complémentaires
Documentation :