FAQ sur la résilience et la disponibilité permanente des services et de la plateforme Oracle Cloud Infrastructure

Clause de non-responsabilité : les informations suivantes sont destinées à présenter notre orientation générale concernant les produits. Ces données ne sont fournies qu’à titre informatif et ne peuvent être intégrées dans un contrat. Elles ne sauraient constituer un engagement d’Oracle à offrir l’un ou l’autre de ces produits, programmes ou fonctionnalités, ni servir de base pour la prise de décisions d’achat. Le développement, la publication, le calendrier et les tarifs des caractéristiques ou fonctionnalités exposés pour les produits Oracle sont susceptibles d’être modifiés et relèvent de la seule discrétion d’Oracle Corporation.

Cette FAQ répond à des questions courantes sur la façon dont Oracle assure la résilience et une disponibilité continue de ses services d'infrastructure de base et de sa plate-forme d'hébergement. Les réponses peuvent intéresser les clients d'Oracle Cloud à plusieurs titres :

  • Elles aident les clients à réaliser la diligence raisonnable requise lorsqu'ils évaluent la plateforme d'hébergement et les services d'Oracle.
  • Nombre des réponses traitent des défis et des solutions qui sous-tendent l'ensemble des systèmes à l'échelle du cloud. Elles fournissent donc des informations sur l'architecture et la conception des systèmes que les clients souhaitent créer dans le cloud.

FAQ sur la résilience et la disponibilité continue des services et de la plate-forme Oracle Cloud Infrastructure

Tout ouvrir Tout fermer
  • Oracle a-t-il plusieurs classes de service, par exemple les services stratégiques, disponibles en permanence ou à emplacement unique ?

    Nous ne faisons pas de telles distinctions. Nous catégorisons plutôt les services en fonction du niveau de dépendance, de la portée de disponibilité et du plan de données par rapport au plan de contrôle. Ces catégories permettent de fournir divers compromis utiles entre disponibilité, durabilité, performances et confort.

    Niveaux de dépendance

    Ces niveaux peuvent être considérés comme les couches d'un schéma fonctionnel architectural. Chaque couche ne dépend que des couches inférieures.

    De bas en haut :

    • Services principaux : ils constituent le fondement d'Oracle Cloud Infrastructure. Il s'agit notamment d'Identity and Access Management (IAM), de Key Management, de Networking, de Compute, de Block Volumes, d'Object Storage, de Telemetry et de plusieurs services internes partagés. Ils sont conçus pour limiter les dépendances, y compris les unes avec les autres. (Pour plus d'informations sur les dépendances, reportez-vous plus loin dans ce document.)
    • IaaS : cette couche offre davantage de fonctionnalités de niveau infrastructure, reposant sur le coeur. Les services de cette couche incluent File Storage, Database et Container Engine for Kubernetes.
    • SaaS : cette couche est composée de logiciels avancés en tant que services qui reposent sur des couches inférieures.

    Portée de la disponibilité

    Pour répondre aux objectifs de disponibilité et de durabilité pour un service, l'une des portées de disponibilité suivantes est choisie pour chaque service :

    • Local avec des domaines de disponibilité : chaque domaine de disponibilité contient une instance indépendante du service. Ces services assurent une durabilité élevée des données stockées à l'aide de la réplication synchrone entre répliques au sein du même domaine de disponibilité (pour plus de détails, reportez-vous à la section sur les domaines de pannes plus tard dans ce document). Ils peuvent tolérer une panne d'un tiers de l'infrastructure du domaine de disponibilité, ou plus selon la nature du service. Les services locaux de domaine de disponibilité atteignent ce niveau de tolérance de panne en utilisant au sein du domaine de disponibilité deux types de centre de données logique (groupes logiques d'isolation des pannes et d'isolation des performances). Pour plus de détails, reportez-vous aux sections sur les domaines de pannes et sur les cellules de service plus loin dans ce document. Enfin, ces services peuvent continuer à fonctionner comme d'habitude même si le domaine de disponibilité ne peut communiquer avec un quelconque autre domaine de disponibilité. Par conséquent, ils tolèrent la perte d'autres domaines de disponibilité ou une défaillance complète du réseau WAN dans la région.
    • Régional à plusieurs domaines de disponibilité : chaque région (à plusieurs domaines de disponibilité) contient une instance indépendante du service, des composants se trouvant dans chaque domaine de disponibilité. Ces services offrent une très haute durabilité des données stockées à l'aide de la réplication synchrone dans plusieurs domaines de disponibilité de la même région. Ils peuvent tolérer la panne de n'importe quel domaine de disponibilité dans une région ou l'incapacité à communiquer avec celui-ci.
    • Service régional à domaine de disponibilité unique : si une région ne contient qu'un domaine de disponibilité, les caractéristiques visibles du service régional correspondent à celles du service local de domaine de disponibilité, décrites précédemment. La différence entre le service local de domaine de disponibilité et le service régional de domaine de disponibilité unique ne s'exprime que si une région à domaine de disponibilité unique est étendue via l'ajout de domaines de disponibilité. Dans ce cas, chaque service régional est automatiquement étendu de manière à permettre l'utilisation appropriée des nouveaux domaines de disponibilité, tout en ne conservant qu'une seule instance du service. Par exemple, le plan de données Object Storage serait étendu pour utiliser les domaines de disponibilité supplémentaires afin d'améliorer la durabilité des données existantes. En revanche, avec les services locaux de domaine de disponibilité, chacun des nouveaux domaines de disponibilité reçoit sa propre instance de chaque service local de domaine de disponibilité.
    • Répartition dans les régions : l'un des principes de base d'Oracle Cloud Infrastructure est que chaque région est aussi indépendante que possible des autres sur le plan opérationnel. La mention "possible" reflète le fait que les régions partagent nécessairement au moins une partie de l'infrastructure, par exemple le réseau de base inter-régional. Sinon, nous ne créons pas de mécanismes de couplage étroit entre les régions, tels que la haute disponibilité transparente ou le basculement en cas d'incident, qui pourraient causer des problèmes qui affectent simultanément plusieurs régions. Nous préférons fournir deux mécanismes de distribution des services dans les diverses régions, présentant un couplage léger :
      • Reprise après sinistre : permettre à nos clients de créer des systèmes offrant des fonctionnalités de récupération après sinistre est l'une des clés de notre approche et de notre investissement dans le cloud. Plusieurs services principaux proposent déjà des mécanismes de récupération après sinistre, par exemple la sauvegarde inter-région de Block Volumes et la copie inter-région d'Object Storage. Les fonctionnalités de récupération après sinistre sont considérées comme des éléments prioritaires dans leurs feuilles de route.
      • Abonnements entre régions : actuellement, les abonnements entre régions ne sont disponibles que pour les données IAM. Conceptuellement, les données IAM ont une portée globale. Les clients peuvent s'abonner à (choisir) un ensemble de régions. Nous y répliquons automatiquement les données IAM appropriées et les mises à jour apportées par la suite. Pour éviter tout couplage étroit, la réplication est asynchrone et cohérente à terme. Les clients apportent des modifications à leurs données IAM dans une région d'origine désignée. Si, pour certaines raisons, la région d'origine en cours n'est plus disponible ou ne convient plus, une autre région peut être désignée.

    Plan de contrôle et plan de données

    Le plan de données d'un service est l'ensemble des interfaces et des composants de traitement des données qui implémentent les fonctionnalités devant être utilisées par les applications. Par exemple, le plan de données du réseau cloud virtuel (VCN) inclut le système de traitement de paquets réseau, les routeurs virtualisés et les passerelles, tandis que le plan de données Block Volumes inclut l'implémentation du protocole iSCSI et du système de stockage répliqué tolérant les pannes pour les données de volume.

    Le plan de contrôle d'un service est l'ensemble des API et des composants qui souscrit aux tâches suivantes :

    • Gestion des demandes client pour le provisionnement, la reconfiguration, le redimensionnement ou l'arrêt des ressources
    • Application automatique de correctifs aux grandes flottes, rapidement et en toute sécurité
    • Détection des ressources en échec, endommagées ou configurées de façon incorrecte
    • Réparation automatique ou demande d'assistance aux opérateurs
    • Collaboration avec d'autres plans de contrôle ( Compute, VCN et Block Storage sont par exemple couplés pendant LaunchInstance)
    • Gestion de la capacité non utilisée
    • Coordination avec le personnel humain, par exemple à l'arrivée d'un nouvel équipement, lors de réparations physiques ou de maintenance
    • Visibilité et contrôle opérationnels
  • Comment Oracle garantit-il que les services sont résilients et disponibles en permanence ?

  • Dans les régions Oracle comportant plusieurs domaines de disponibilité, les services critiques sont-ils tous distribués dans les domaines de disponibilité ?

  • Comment Oracle et ses clients peuvent-ils éviter un service critique qui dépend d'un seul centre de données logique ?

  • Comment Oracle parvient-il à effectuer les activités de maintenance sans qu'un service essentiel soit temporairement indisponible pour les clients ?

  • Des services de plate-forme sans serveur sont-ils déployés dans plusieurs centres de données logiques pour une meilleure disponibilité ?

  • Si la résilience n'est pas la configuration par défaut, les clients peuvent-ils opter pour le déploiement de centres de données logiques multiples (par exemple, une configuration à domaines de disponibilité multiples ou inter-région) ?

  • Comment Oracle permet-il aux clients d'éviter une défaillance corrélée des applications liée aux dépendances internes existant entre les différents services d'infrastructure et de plate-forme ?

  • Les services Oracle Cloud Infrastructure d'une région, y compris les adresses d'API régionales, continuent-ils de fonctionner s'ils sont isolés des fonctions de plan de contrôle global ?

  • Les services Oracle Cloud Infrastructure dans un centre de données logique continuent-ils de fonctionner s'ils sont isolés des fonctions de plan de contrôle régional ?

  • Les régions Oracle Cloud Infrastructure disposent-elles de connexions Internet redondantes à des fins de haute disponibilité ?