Haute disponibilité

Les systèmes à haute disponibilité sont conçus pour garantir une disponibilité et une accessibilité maximales.

Les applications d'entreprise, essentielles pour les activités quotidiennes de l'entreprise, doivent être disponibles. On attend de ces systèmes qu'ils fonctionnent toujours et qu'il n'y ait jamais de temps d'arrêt. Bien qu'il soit impossible d'éliminer complètement les temps d'arrêt, vous pouvez réduire leurs répercussions négatives en faisant en sorte que vos applications soient hautement disponibles. 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. Oracle Cloud Infrastructure (OCI) fournit des fonctions de haute disponibilité et des meilleures pratiques pour une topologie en nuage fiable et résiliente qui vous permettent de créer des applications d'entreprise hautement disponibles.

Puisque les architectures à plusieurs ou trois niveaux sont courantes dans les applications d'entreprise traditionnelles sur place, utilisons un exemple d'application d'entreprise à trois niveaux pour montrer comment vous pouvez rendre cette application hautement disponible à l'aide des fonctions de récupération après sinistre d'OCI et de meilleures pratiques pour une topologie en nuage fiable et résiliente. Le diagramme suivant présente un exemple d'application d'entreprise dans une configuration de haute disponibilité à une seule région.

Ces informations ne couvrent pas la connectivité entre l'infrastructure sur place et OCI, ni la récupération après sinistre.

Concepts relatifs à la haute disponibilité

Lorsque votre infrastructure est configurée pour fournir une disponibilité presque à temps plein, il s'agit d'un système haute disponibilité.

Pour concevoir une architecture haute disponibilité, tenez compte des éléments clés suivants :

• Redondance : Chaque ressource est-elle associée à au moins une ressource équivalente prête à prendre sa place? Notez que dans chaque niveau illustré dans le diagramme, les ressources ont toujours une ressource principale et une de secours, et qu'elles se trouvent dans des domaines de disponibilité et d'erreur différents pour éviter les points de défaillance uniques.
• Surveillance : Les ressources principales fonctionnent-elles comme prévu? Sinon, à quel moment la ressource de sauvegarde prend-elle le relais de la ressource principale?
• Basculement : Lorsque les critères sont satisfaits pour basculer de la ressource principale à la ressource de secours, celle-ci est-elle prête?

Pour atteindre la haute disponibilité, un système doit tenir compte de tous ces éléments. Bien que la haute disponibilité puisse être obtenue à différents niveaux (y compris au niveau de l'application et de l'infrastructure en nuage), cette section est consacrée à l'infrastructure en nuage. Pour plus d'informations, voir En savoir plus sur l'architecture d'une topologie en nuage à haute disponibilité.

Choix d'une approche pour la haute disponibilité

Certaines applications sont plus critiques que d'autres. Utilisez l'arbre de décision suivant pour identifier les fonctions de haute disponibilité d'OCI à utiliser lors du déploiement d'applications d'entreprise à plusieurs niveaux sur OCI.

Pour notre exemple d'application d'entreprise, la haute disponibilité est nécessaire, ainsi que la capacité à surmonter une panne de domaine de disponibilité. Nous devons également être en mesure de surmonter une panne régionale, mais des temps d'arrêt sont acceptables, au cas où une région serait touchée. C'est pourquoi nous avons choisi un déploiement actif/passif dans plusieurs régions. Les aspects relatifs au déploiement passif sont traités dans la rubrique Récupération après sinistre.

Mesure de la haute disponibilité

La haute disponibilité désigne la capacité d'un système à atteindre un niveau continu de performance opérationnelle, ou de disponibilité, pendant une période donnée.

La disponibilité est généralement exprimée sous la forme d'un pourcentage du temps de disponibilité au cours d'une année, souvent désigné par un nombre de "neuf". Le tableau suivant présente les niveaux de disponibilité et le temps d'arrêt associé à chaque niveau.

Chaque service Oracle Cloud Infrastructure est généralement associé à un contrat de niveau de service qui définit la disponibilité attendue de ce service. La plupart des solutions en nuage nécessitent l'utilisation d'une combinaison de services pour créer l'architecture souhaitée pour votre déploiement en nuage. 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. Le contrat de niveau de service global d'un système comportant plusieurs composants est appelé contrat de niveau de service composite.

Pour calculer le contrat de niveau de service composite d'un système ou d'une application, tenez compte de tous les sous-systèmes et de leur configuration. Prenons l'exemple d'un scénario dans lequel une application dépend de deux systèmes, A et B. Chaque système offre une disponibilité de 99,9 %. Les systèmes sont dépendants en série, comme illustré dans l'image suivante.

Si le système A ou le système B est indisponible, tout le système est indisponible. Pour ce type de configuration de système, vous pouvez calculer le contrat de niveau de service composite en multipliant la disponibilité des deux systèmes : 99,9 % × 99,9 % = 99,8 %. En raison de la dépendance en série entre les deux systèmes, le contrat de niveau de service composite obtenu, 99,8 %, est inférieur au contrat de niveau de service individuel de chaque système.

Points à considérer pour la conception de la haute disponibilité

Oracle Cloud Infrastructure fournit les blocs fonctionnels qui permettent d'activer la haute disponibilité pour votre infrastructure.

L'exemple d'application d'entreprise utilise des services dans les concepts OCI de région, de domaine de disponibilité et de domaine d'erreur. L'utilisation de plusieurs domaines de disponibilité et de plusieurs domaines d'erreur dans chacun de ces domaines, augmente la redondance et élimine les points de défaillance uniques. Pour des informations générales sur les régions et pour connaître les ressources disponibles dans toutes les régions, dans une seule région ou dans un seul domaine de disponibilité, voir Régions et domaines de disponibilité.

Nous vous recommandons de vérifier les informations de résilience des produits OCI pertinents, puis, en fonction des produits de la plate-forme OCI sélectionnés, d'ajuster les architectures pour résoudre les écarts entre les fonctions des produits et leurs besoins en matière de haute disponibilité.

Votre région principale est l'endroit où Oracle crée votre location. C'est là que les ressources du service de gestion des identités et des accès (GIA) de votre organisation sont définies. Selon les besoins de votre entreprise, vous pouvez vous abonner à d'autres régions; le service GIA propage automatiquement les mises à jour dans toutes les régions de votre location. Pour plus d'informations, voir Gestion des régions.

Réseaux

Après avoir créé les bases des réseaux en nuage virtuels et des sous-réseaux, pour assurer la haute disponibilité, vous devez utiliser le service d'équilibrage de charge pour répartir le trafic. Lorsqu'un équilibreur de charge est déployé, il utilise une configuration de haute disponibilité, comme illustré dans l'exemple de diagramme d'architecture. Pour plus d'informations, voir Planifier la haute disponibilité pour les ressources de réseau.

Calcul

Pour éliminer les points de défaillance uniques, créez plusieurs instances de calcul réparties entre les domaines d'erreur dans chacun des domaines de disponibilité. Placez les instances de calcul derrière un équilibreur de charge pour répartir le trafic et obtenir une haute disponibilité, comme illustré dans l'exemple d'architecture. Pour plus d'informations, voir Aperçu du service de calcul, Meilleures pratiques pour vos instances de calcul et Planifier la haute disponibilité pour les instances de calcul.

Stockage

OCI fournit un jeu de services de stockage (Volumes par blocs, Stockage de fichiers et Stockage d'objets), que vous pouvez configurer pour respecter les exigences d'une architecture haute disponibilité.

Le service de stockage d'objets est une plate-forme de stockage haute performance à l'échelle d'Internet qui assure la durabilité des données de manière fiable et rentable. Le service de stockage d'objets est un service régional disponible dans tous les domaines de disponibilité d'une région. Les données sont stockées de façon redondante sur plusieurs serveurs de stockage et dans plusieurs domaines de disponibilité pour assurer une haute disponibilité. Le service de stockage d'objets inclut la réparation automatique et la surveillance de l'intégrité des données pour améliorer encore sa durabilité et sa disponibilité.

Le stockage de fichiers fournit un système de fichiers réseau durable, évolutif et sécurisé pour l'entreprise. Il utilise une architecture résiliente qui réplique les données cinq fois dans différents domaines d'erreur pour assurer une haute disponibilité et durabilité. File Storage peut s'adapter automatiquement pour répondre à la croissance d'un maximum de 8 exaoctets de données. Les instantanés et les clones du système de fichiers peuvent être utilisés pour protéger les données contre les suppressions accidentelles et pour effectuer des copies des données instantanément. Les cycles de vie des instantanés peuvent être gérés automatiquement à l'aide de la fonction Instantané basé sur une politique.

Les volumes par blocs sont durables et hautement disponibles en stockant plusieurs copies des données de manière redondante sur des serveurs de stockage avec des mécanismes de réparation intégrés. Les volumes par blocs peuvent être attachés à une ou plusieurs machines virtuelles et ils persistent au-delà de la durée de vie des machines virtuelles. Les volumes par blocs améliorent encore la haute disponibilité avec des sauvegardes automatisées vers le service de stockage d'objets et des fonctions de clonage de volume.

Pour connaître les étapes de création de ressources de stockage, voir Création d'un volume, Création de systèmes de fichiers et Gestion des seaux. Pour plus d'informations sur les meilleures pratiques, voir Planifier la haute disponibilité pour le stockage.

Base de données

Les bases de données Oracle OCI sont disponibles en plusieurs modèles ou variantes de déploiement. Chaque modèle offre un ensemble croissant de fonctionnalités de haute disponibilité.

Quel que soit le système de base de données utilisé, nous vous recommandons de vous référer à l'architecture de disponibilité maximale, qui est un ensemble de meilleures pratiques développées par les ingénieurs Oracle pendant de nombreuses années pour l'utilisation intégrée des technologies Oracle de haute disponibilité, de protection des données et de récupération après sinistre.

Service de base de données de base OCI

Le service de base de données de base OCI vous permet d'avoir un contrôle total sur vos données tout en tirant parti des capacités d'Oracle Database et d'OCI. Pour obtenir la liste des éditions de base de données prises en charge et les formes de calcul sous-jacentes sur lesquelles elles peuvent être déployées, voir la documentation sur le service de base de données de base OCI. Les fonctions haute disponibilité mentionnées s'appliquent à toutes les versions de base de données ou aux formes de calcul sous-jacentes.

L'édition Enterprise Edition Extreme Performance permet un système de base de données RAC (Real Application Cluster) à deux noeuds avec des noeuds couvrant différents domaines d'erreur dans le même domaine de disponibilité. La haute disponibilité est ainsi assurée dans les scénarios suivants :

• Protection contre les défaillances de noeud
• Maintenance logicielle sans temps d'arrêt
• Modifications élastiques (UC, mémoire et stockage) sans aucun temps d'arrêt
• (presque) Maintenance transparente non planifiée

Si la haute disponibilité est requise dans tous les domaines de disponibilité, vous pouvez envisager une base de données RAC de secours passive mettant en miroir le système de base de données RAC principal, avec des données répliquées au moyen d'Oracle Data Guard. Le basculement vers la base de secours passive peut être manuel avec un faible temps d'arrêt.

Note : La base de données de base OCI prend en charge un maximum de deux noeuds RAC. Pour les versions d'Oracle Database ou pour les noeuds RAC supérieurs à 2, tenez compte du service Exadata Database sur une infrastructure dédiée (ExaDB-D) pour OCI.

Base de données Exadata sur une infrastructure dédiée (ExaDB-D)

Exadata fournit des capacités de haute disponibilité intégrées.

Toutes les meilleures pratiques existantes avec votre environnement Exadata sur place s'appliquent. Les concepts décrits pour la base de données de base OCI, tels que RAC et Data Guard (pour la base de données de secours), s'appliquent à Exadata Database sur une infrastructure dédiée (ExaDB-D), avec les attributs supplémentaires suivants :

• Exadata Database sur une infrastructure dédiée (ExaDB-D) permet plus de deux noeuds RAC, ce qui est une limitation avec le système de base de données de base.
• Évolutivité, performance et disponibilité d'Exadata
• Agilité d'Exadata grâce à l'évolution du nombre de machines virtuelles, du stockage et des ressources de calcul
• Protection des données et Exadata QoS pour les opérations de base de données

Exadata dispose d'une détection instantanée des défaillances qui permet de détecter les défaillances du noeud de base de données, du serveur de stockage et du réseau en moins de 2 secondes, et de reprendre la disponibilité et les performances du service d'application et de base de données.

Il est recommandé d'utiliser les configurations suivantes pour assurer la disponibilité continue de vos applications.

• Utilisez les services de base de données gérés par Oracle Clusterware pour connecter votre application. Pour les environnements Oracle Data Guard, utilisez des services basés sur des rôles.
• Utilisez la chaîne de connexion recommandée avec des temporisations, des tentatives et des retards intégrés, afin que les connexions entrantes ne voient pas d'erreurs lors des pannes.
• Configurez vos connexions avec la fonction d'avis rapide des applications.
• Utilisez la continuité d'application ou la continuité d'application transparente pour réexécuter les transactions non validées en cours de manière transparente après les défaillances.

Autonomous Database

Par défaut, Oracle Autonomous Database (ADB) est hautement disponible et intègre une configuration à plusieurs noeuds afin de se protéger contre les pannes matérielles localisées.

Chaque service d'application de la base de données autonome réside dans au moins une instance Oracle Real Application Clusters (Oracle RAC), avec la possibilité de basculer vers une autre instance Oracle RAC disponible pour des pannes non planifiées ou des activités de maintenance planifiées, ce qui permet d'éviter ou de limiter les temps d'arrêt.

Les principales mises à niveau de base de données sont automatisées. De plus, le temps d'arrêt pour Oracle Autonomous Database Serverless (ADB-S) est minime.

Les contrats de niveau de service (CNS) de temps de disponibilité par mois sont de 99,95 % (22 minutes maximum de temps d'arrêt par mois).

ADB-S permet une base de données locale (entre domaines de disponibilité ou dans des domaines de disponibilité pour des régions à domaine de disponibilité unique) et une base de données de secours distante supplémentaire.

Autonomous Data Guard ajoute une base de données de secours symétrique avec Oracle Data Guard à un bâti Exadata localement (entre des domaines de disponibilité ou dans des domaines de disponibilité pour des régions comportant un seul domaine de disponibilité) avec une base de données supplémentaire dans une autre région. Les systèmes de base de données principaux et de secours sont configurés de manière symétrique pour garantir le maintien des niveaux de performance requis après les changements de rôle Data Guard.

Les meilleures pratiques pour maintenir les temps de disponibilité des applications sont décrites ici.

Surveillance

Le service de surveillance vous permet de surveiller vos ressources en nuage, de manière active et passive, pour assurer une disponibilité supérieure et des niveaux de service cohérents. Pour un exemple, voir Surveillance de bout en bout des applications exécutées sur Oracle Cloud Infrastructure.

Informations complémentaires

Livres de jeu de solution :

• En savoir plus sur l'architecture d'une topologie en nuage à haute disponibilité
• À propos des meilleures pratiques pour une topologie en nuage fiable et résiliente
• Concevoir l'infrastructure pour déployer Oracle Enterprise Performance Management dans le nuage (Architecture haute disponibilité : Une région, un seul domaine de disponibilité)

Architectures de référence :

• Déployer une application Web hautement disponible
• Déployer Oracle REST Data Services avec une haute disponibilité sur Oracle Cloud Infrastructure
• Déployer une grappe MySQL InnoDB hautement disponible
• Déployer des applications ASP.Net hautement disponibles sur Oracle Cloud Infrastructure
• Déployer une grappe CockroachDB hautement disponible
• Déployer une base de données sans système d'exploitation hautement disponible
• Déployer une base de données Microsoft SQL Server hautement disponible
• Déployer une grappe Apache Cassandra hautement disponible
• Déployer un cache distribué hautement disponible à l'aide de Redis
• Provisionner un contrôleur de session en périphérie hautement disponible

Blogues et autres ressources :

• Mise en œuvre d'une architecture haute disponibilité dans et entre les régions
• Modèles Oracle Maximum Availability Architecture pour les déploiements Oracle Cloud Infrastructure (OCI) : Haute disponibilité d'Oracle Database dans le nuage