Fiabilité extrême
Utilisez les principes de haute disponibilité et de récupération après sinistre pour concevoir une architecture cloud extrêmement fiable.
Les systèmes haute disponibilité sont conçus pour garantir un maximum de temps d'activité et d'accessibilité. Pour garantir la haute disponibilité, éliminez les points d'échec uniques, de sorte que, même en cas de défaillance des composants, l'application reste en cours d'exécution et disponible.
Un plan de récupération après sinistre bien conçu vous permet d'effectuer une récupération après sinistre rapide et de continuer à fournir des services aux utilisateurs. La récupération après sinistre est le processus consistant à vous préparer aux sinistres et à effectuer la récupération après sinistre. Un sinistre peut être tout événement mettant vos applications en danger, qu'il s'agisse de pannes de réseau, d'équipement ou d'application, ou de catastrophes naturelles. Pour mettre en place la récupération après sinistre, déployez vos applications essentielles vers plusieurs régions et utilisez la réplication asynchrone entre les régions. Planifiez la récupération après sinistre sur toutes les couches de la pile, y compris Networking, Compute, Object Storage, Database et Monitoring.
Recommandations d'architecture pour une fiabilité extrême
Pour obtenir une fiabilité extrême, nous recommandons une approche progressive. Dans la première phase, déployez une architecture qui s'appuie sur les domaines de pannes d'un domaine de disponibilité pour fournir des fonctionnalités haute disponibilité. Si une plus grande résilience est nécessaire, déployez dans la seconde phase une architecture couvrant plusieurs régions.
Pour plus d'informations sur les régions, les domaines de disponibilité et les domaines de pannes, reportez-vous à Régions et domaines de disponibilité.
Phase 1 : distribution des instances dans les domaines de pannes
Les systèmes haute disponibilité sont conçus pour éviter les points d'échec uniques. L'un des principes clés pour la conception d'un système haute disponibilité est de répartir les instances entre plusieurs domaines de pannes. En utilisant correctement les domaines de pannes, 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 des instances à l'aide de domaines de pannes.
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 cluster. Dans ce scénario, vous devez regrouper un serveur Web et un noeud de base de données dans un domaine de pannes et l'autre moitié de chaque paire dans un autre domaine de pannes. Ce placement permet de s'assurer qu'une éventuelle défaillance d'un domaine de pannes n'entraîne pas d'interruption de l'application.
Scénario B : serveur Web unique et architecture d'instance de base de données
Dans ce scénario, l'architecture d'application n'est pas hautement disponible. Par exemple, 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 de pannes pour minimiser les coupures client. Ce placement permet de s'assurer que votre application n'est affectée que par la défaillance du domaine de pannes unique considéré, ce qui offre une meilleure disponibilité globale de l'application.
Contrats de niveau de service 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, réduisez les dépendances entre ceux-ci. Autrement dit, selon l'architecture de votre application, vous pouvez obtenir pour un même effort d'ingénierie une plus grande fiabilité en tirant parti des domaines de pannes d'un domaine de disponibilité plutôt qu'en répartissant les ressources entre des domaines de disponibilité.
Phase 2 : déploiement des ressources dans plusieurs régions
Pour maximiser la résilience de vos charges globales cloud, déployez-les dans plusieurs régions plutôt que dans plusieurs domaines de disponibilité.
Le déploiement dans plusieurs régions permet de réduire les risques associés à une coupure régionale, qui est susceptible d'affecter tous les domaines de disponibilité d'une région. Le déploiement dans plusieurs régions optimise également la valeur de l'effort d'ingénierie réalisé afin de transférer les charges globales dans 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 fonctionnalités de réplication telles que GoldenGate pour la couche de données et Autonomous Data Guard pour la couche de base de données, ainsi que des stratégies de réplication Object Storage sur le bucket source, qui identifient la région et le bucket vers lesquels effectuer la réplication.
Pour la couche frontale et la couche d'application, créez un équilibreur de charge et configurez des fonctionnalités de vérification de l'état sur les ressources back-end déployées dans les domaines de pannes des deux régions. Chaque fois que vous déployez une nouvelle application en production, déployez-la sur des instances des deux régions.
En savoir plus
Documentation :