Documentation Oracle Cloud Infrastructure

Haute disponibilité

Les systèmes haute disponibilité sont conçus pour garantir un maximum de temps d'activité et d'accessibilité.

Les applications d'entreprise sont essentielles aux opérations quotidiennes et doivent être disponibles. Les utilisateurs considèrent que ces systèmes fonctionnent en permanence, sans temps d'inactivité. Bien qu'il soit impossible d'exclure complètement les temps d'inactivité, vous pouvez garantir la haute disponibilité de vos applications afin d'en réduire l'impact. 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. Oracle Cloud Infrastructure (OCI) fournit des fonctionnalités haute disponibilité et des meilleures pratiques pour la conception de topologies cloud fiables et résilientes qui vous permettent de créer des applications d'entreprise hautement disponibles.

Etant donné que les architectures à plusieurs niveaux sont fréquentes dans les applications d'entreprise sur site traditionnelles, utilisons un exemple d'application d'entreprise à trois niveaux afin de montrer comment rendre une application hautement disponible à l'aide des fonctionnalités de haute disponibilité OCI et des meilleures pratiques pour la conception de topologies cloud fiables et résilientes. Le schéma suivant présente un exemple d'application d'entreprise dans une configuration de haute disponibilité avec région unique.

Exemple d'application d'entreprise dans une configuration de haute disponibilité avec région unique.

Ces informations ne couvrent ni la connectivité de l'environnement sur site à OCI ni les aspects de l'infrastructure liés à la récupération après sinistre.

Concepts relatifs à la haute disponibilité

Lorsqu'une infrastructure est configurée pour fournir une disponibilité quasiment à 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 dispose-t-elle d'au moins une ressource similaire prête à prendre le relais ? Dans chaque niveau du diagramme, les ressources disposent toujours d'une instance principale et d'une instance de secours, et se trouvent dans des domaines de disponibilité et de pannes différents pour éviter les points d'échec uniques.
  • Surveillance : les ressources principales fonctionnent-elles comme prévu ? Dans le cas contraire, à quel moment la ressource de secours prend-elle le relais de la ressource principale ?
  • Basculement : lorsque les critères de déclenchement d'un basculement de l'instance principale vers l'instance de secours sont remplis, cette dernière est-elle prête ?

La haute disponibilité suppose qu'un système prenne en compte tous ces éléments. Bien que la haute disponibilité puisse être mise en place à divers niveaux (notamment ceux de l'application et de l'infrastructure cloud), cette section se concentre sur celui de l'infrastructure cloud. Pour plus d'informations, reportez-vous à En savoir plus sur la conception d'une topologie cloud hautement disponible.

Choix d'une approche haute disponibilité

Certaines applications sont plus essentielles que d'autres. Utilisez l'arbre de décision suivant pour savoir quelles fonctionnalités de haute disponibilité OCI utiliser lors du déploiement d'applications d'entreprise à plusieurs niveaux sur OCI.

Arbre de décision permettant de savoir quelles fonctionnalités de haute disponibilité OCI utiliser lors du déploiement d'applications d'entreprise à plusieurs niveaux.

Dans notre exemple d'application d'entreprise, nous avons besoin de la haute disponibilité et devons pouvoir résister à une panne de domaine de disponibilité. De plus, nous devons pouvoir résister à une panne régionale, mais sommes en mesure de gérer un temps d'inactivité si une région est touchée. Nous avons donc choisi un déploiement actif/passif dans plusieurs régions. Les aspects liés au déploiement passif sont traités dans Récupération après sinistre.

Mesure de la haute disponibilité

La haute disponibilité correspond à la capacité d'un système à atteindre un niveau continu de performances opérationnelles (temps d'activité) pendant une période donnée.

La disponibilité est généralement exprimée sous la forme d'un pourcentage du temps d'activité sur un an, souvent indiqué par un nombre de "neuf". Le tableau suivant présente les niveaux de disponibilité et le temps d'inactivité associé à chacun.

% de disponibilité Disponibilité (en nombre de neuf) Temps d'inactivité par an Temps d'inactivité par mois Temps d'inactivité par semaine Temps d'inactivité par jour
90 % Un neuf 36,53 jours 73,05 heures 16,80 heures 2,40 heures
99 % Deux neuf 3,65 jours 7,31 heures 1,68 heures 14,40 minutes
99,9 % Trois neuf 8,77 heures 43,83 minutes 10,08 minutes 1,44 minute
99,99 % Quatre neuf 52,60 minutes 4,38 minutes 1,01 minute 8,64 secondes
99,999 % Cinq neuf 5,26 minutes 26,30 secondes 6,05 secondes 864,00 millisecondes
99,9999 % Six neuf 31,56 secondes 2,63 secondes 604,80 millisecondes 86,40 millisecondes
99,99999 % Sept neuf 3,16 secondes 262,98 millisecondes 60,48 millisecondes 8,64 millisecondes
99,999999 % Huit neuf 315,58 millisecondes 26,30 millisecondes 6,05 millisecondes 864,00 microsecondes
99,9999999 % Neuf neuf 31,56 millisecondes 2,63 millisecondes 604,80 microsecondes 86,40 microsecondes

Chaque service Oracle Cloud Infrastructure est généralement associé à un contrat de niveau de service qui définit la disponibilité attendue du service. La plupart des solutions cloud exigent que vous utilisiez une combinaison de services afin d'obtenir l'architecture souhaitée pour votre déploiement cloud. 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 la manière dont ils sont configurés. Prenons l'exemple d'un scénario dans lequel une application dépend de deux systèmes, A et B. Chaque système présente une disponibilité de 99,9 %. Les systèmes présentent une dépendance en série, comme illustré dans l'image suivante.

Diagramme d'un exemple de système dont les sous-systèmes présentent une dépendance en série.

Si le système A ou le système B n'est pas disponible, l'ensemble du système est indisponible. Dans ce type de configuration 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 à celui de chaque système.

Remarques concernant la conception de la haute disponibilité

Oracle Cloud Infrastructure fournit les blocs de création permettant d'activer la haute disponibilité dans votre infrastructure.

L'exemple d'application d'entreprise utilise des services dans différents concepts OCI (régions, domaines de disponibilité et domaines de pannes). L'utilisation de plusieurs domaines de disponibilité, et de plusieurs domaines de pannes dans chacun d'entre eux, augmente la redondance et élimine les points d'échec uniques. Pour obtenir des informations générales sur les régions et la liste des ressources disponibles dans les différentes régions, au sein d'une même région ou dans un seul domaine de disponibilité, reportez-vous à Régions et domaines de disponibilité.

Nous vous recommandons de consulter les informations pertinentes sur la résilience des produits OCI, puis, en fonction des produits de plate-forme OCI choisis, d'ajuster les architectures pour tenir compte des écarts éventuels entre les capacités des produits et leurs exigences en matière de haute disponibilité.

La région d'origine est l'emplacement où Oracle crée votre location et où les ressources Identity and Access Management (IAM) de votre organisation sont définies. En fonction de vos exigences commerciales, vous pouvez vous abonner à d'autres régions. IAM propage automatiquement les mises à jour dans toutes les régions de votre location. Pour plus d'informations, reportez-vous à Gestion des régions.

Fonctions de réseau

Après avoir créé le socle réseau des réseaux cloud virtuels et des sous-réseaux, vous devez, pour assurer une haute disponibilité, utiliser le service Load Balancing afin de répartir le trafic. Lorsqu'un équilibreur de charge est déployé, il utilise une configuration haute disponibilité comme indiqué dans l'exemple de diagramme d'architecture. Pour plus d'informations, reportez-vous à Planification de la haute disponibilité pour les ressources réseau.

Calcul

Pour éliminer les points d'échec uniques, créez plusieurs instances de calcul réparties dans les domaines de pannes des différents domaines de disponibilité. Placez les instances de calcul derrière un équilibreur de charge pour répartir le trafic et atteindre une haute disponibilité, comme indiqué dans l'exemple d'architecture. Pour plus d'informations, reportez-vous à Présentation du service Compute, à Meilleures pratiques pour vos instances Compute et à Planification de la haute disponibilité pour les instances Compute.

Stockage

OCI fournit un ensemble de services de stockage (Block Volume, File Storage et Object Storage), que vous pouvez configurer pour répondre aux exigences d'une architecture haute disponibilité.

Object Storage est une plate-forme de stockage hautes performances, à l'échelle d'Internet, qui offre une durabilité fiable et rentable en matière de données. Object Storage est un service régional qui est 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 de multiples domaines de disponibilité pour assurer une haute disponibilité. Object Storage inclut également la surveillance automatique de l'autorétablissement et de l'intégrité des données pour améliorer davantage sa durabilité et sa disponibilité.

File Storage 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 sur différents domaines de pannes, garantissant ainsi une haute disponibilité et une durabilité élevées. File Storage peut évoluer automatiquement pour s'adapter à la croissance de 8 exaoctets de données maximum. Les instantanés et les clones de système de fichiers peuvent être utilisés pour protéger les données contre les suppressions accidentelles et pour faire des copies de données instantanément. Les cycles de vie des instantanés peuvent être gérés automatiquement à l'aide de la fonctionnalité Cliché basé sur une stratégie.

Les volumes de blocs sont durables et hautement disponibles en stockant de multiples copies de données de manière redondante sur les serveurs de stockage avec des mécanismes de réparation intégrés. Les volumes de blocs peuvent être associés à une ou plusieurs machines virtuelles, et ils persistent au-delà de la durée de vie des machines virtuelles. Les volumes de blocs améliorent encore la haute disponibilité grâce aux fonctionnalités de sauvegardes automatisées vers Object Storage et de clonage de volumes.

Pour connaître les étapes de création des ressources de stockage, reportez-vous à Création d'un volume, à Création de systèmes de fichiers et à Gestion des buckets. Pour connaître les meilleures pratiques, reportez-vous àPlanification de la haute disponibilité pour le stockage.

Base de données

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

Quel que soit le système de base de données utilisé, nous vous recommandons de vous reporter à l'Maximum Availability Architecture (MAA), qui est un ensemble de meilleures pratiques développées par des ingénieurs Oracle depuis de nombreuses années pour assurer l'utilisation intégrée de technologies de haute qualité, de protection de données et d'extraction après sinistre de Oracle.

Service OCI Base Database

OCI Base Database Service vous permet d'avoir un contrôle total sur vos données tout en tirant parti des fonctionnalités d'Oracle Database et d'OCI. Pour obtenir la liste des éditions de base de données prises en charge et des formes de calcul sous-jacentes sur lesquelles elles peuvent être déployées, reportez-vous à la documentation OCI Base Database Service. Les fonctionnalités de 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 d'utiliser un système de base de données RAC (Real Application Cluster) à deux noeuds comportant des noeuds couvrant différents domaines de pannes au sein du même domaine de disponibilité. Cela permet une haute disponibilité dans les scénarios suivants :

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

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

Remarque : OCI Base Database prend en charge un maximum de deux noeuds RAC. Pour les versions d'Oracle Database ou pour les noeuds RAC supérieurs à 2, envisagez OCI Exadata Database on Dedicated Infrastructure (ExaDB-D).

Exadata Database on Dedicated Infrastructure (ExaDB-D)

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

Toutes les meilleures pratiques existantes concernant votre instance Exadata on-premise sont applicables. Les concepts décrits pour la base de données OCI Base Database, tels que RAC et Data Guard (pour la base de données de secours), sont applicables à Exadata Database on Dedicated Infrastructure (ExaDB-D), avec les attributs supplémentaires suivants :

  • Exadata Database on Dedicated Infrastructure (ExaDB-D) autorise plus de deux noeuds RAC, ce qui est une limitation avec le système de base de données Base.
  • Evolutivité, performances et disponibilité d'Exadata
  • Flexibilité d'Exadata avec l'évolution du nombre de machines virtuelles, de stockage et de ressources de calcul
  • Protection des données et Exadata QoS pour les opérations de base de données

Exadata dispose d'une fonctionnalité de détection instantanée des pannes qui peut détecter les pannes de noeud de base de données, de serveur de stockage et de réseau en moins de 2 secondes, puis rétablir la disponibilité et les performances du service de la base de données et de l'application.

Nous recommandons les configurations suivantes afin de garantir une disponibilité continue pour vos applications.

  • Utiliser les services de base de données gérés par Oracle Clusterware pour connecter l'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 les délais d'expiration, les tentatives et les retards intégrés, de sorte que les connexions entrantes ne voient pas d'erreurs lors des coupures.
  • Configurez vos connexions à l'aide de Fast Application Notification.
  • Tirez parti de la continuité des applications ou de la continuité transparente des applications pour réexécuter les transactions non validées en cours de traitement de façon transparente après les échecs.

Autonomous Database

Par défaut, Oracle Autonomous Database (ADB) est hautement disponible, avec une configuration multinoeud pour une protection contre les pannes matérielles localisées.

Chaque service d'application ADB réside dans au moins une instance Oracle Real Application Clusters (Oracle RAC). Il est possible de basculer vers une autre instance Oracle RAC disponible en cas de pannes imprévues ou d'activités de maintenance planifiées. Il est ainsi possible d'obtenir des temps d'arrêt nuls ou presque nuls.

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

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

ADB-S prend en charge une base de données locale (sur tous les domaines de disponibilité ou dans les domaines de disponibilité pour les 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 rack Exadata localement (dans les domaines de disponibilité ou dans les domaines de disponibilité pour les régions à domaine de disponibilité unique) avec une base de données supplémentaire dans une autre région. Les systèmes de base de données principal et de secours sont configurés symétriquement afin de garantir que les niveaux des services de performances sont maintenus après le changement de rôle Data Guard.

Les meilleures pratiques de maintenance des temps d'activité des applications sont décrites ici.

Surveillance

Monitoring vous permet de surveiller, de façon active et passive, vos ressources cloud pour une meilleure disponibilité et des niveaux de service uniformes. Pour obtenir un exemple, reportez-vous à Surveillance de bout en bout des applications exécutées sur Oracle Cloud Infrastructure.

En savoir plus

Livres de jeux de solution :

Architectures de référence :

Blogs et autres ressources :