Oracle E-Business Suite avec Oracle Exadata dans Google Cloud

Last reviewed 2025-05-27 UTC

Ce document fournit une architecture de référence pour vous aider à créer l'infrastructure permettant d'exécuter des applications Oracle E-Business Suite avec une connectivité à faible latence aux bases de données Exadata d'Oracle Cloud Infrastructure (OCI) qui s'exécutent dans Google Cloud. Oracle E-Business Suite est une suite d'applications d'entreprise pour les fonctions opérationnelles telles que la finance, les ressources humaines, la chaîne d'approvisionnement et la relation client.

Ce document s'adresse aux architectes cloud et aux administrateurs de bases de données Oracle et d'applications Oracle E-Business Suite. Ce document suppose que votre équipe connaît la pile technologique et l'architecture Oracle E-Business Suite et Oracle Exadata Database Service.

Si vous utilisez Oracle Exadata ou Oracle Real Application Clusters (Oracle RAC) pour exécuter des bases de données Oracle sur site, vous pouvez migrer efficacement vos applications vers Google Cloud et exécuter vos bases de données sur Oracle Database@Google Cloud. Oracle Database@Google Cloud est une offre Google Cloud Marketplace qui vous permet d'exécuter Oracle Exadata Database Service et Oracle Autonomous Database directement dans Google Cloud.

Architecture

Le schéma suivant montre une architecture dans laquelle les applications Oracle E-Business Suite s'exécutent en mode actif/actif sur des VM Compute Engine distribuées dans deux zones d'une Google Cloud région. L'application utilise des bases de données Oracle Exadata dans la même région Google Cloud.

Tous les composants de l'architecture se trouvent dans une seule région Google Cloud. Cette architecture est conforme à l'archétype de déploiement régional. Vous pouvez adapter cette architecture pour créer une topologie robuste face aux pannes régionales en utilisant l'archétype de déploiement multirégional. Pour en savoir plus, consultez Déploiement multirégional sur Compute Engine et les conseils de la section Fiabilité plus loin dans ce document.

Les applications Oracle E-Business Suite s'exécutent en mode actif-actif sur des VM Compute Engine.

L'architecture du diagramme précédent comprend les composants suivants :

Composant Objectif
Équilibreur de charge d'application externe régional L'équilibreur de charge reçoit et distribue les requêtes des utilisateurs aux applications Oracle E-Business Suite.
Règle de sécurité Google Cloud Armor La stratégie de sécurité Google Cloud Armor vous aide à protéger votre pile d'applications contre les menaces telles que les attaques par déni de service distribué (DDoS) et les scripts intersites (XSS).
Oracle E-Business Suite (BYOL)

Les composants de la couche Application d'Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server et un serveur de traitement simultané) s'exécutent sur des VM Compute Engine réparties sur deux zones de la région principale. Chaque VM héberge une instance indépendante du niveau application. Le disque de démarrage de chaque VM est un volume Hyperdisk Balanced.

Vous utilisez vos propres licences (BYOL) pour Oracle E-Business Suite, et vous gérez les VM et les applications.
Binaires et données d'application Une instance régionale Filestore contient les binaires et les données de l'application. L'instance Filestore est installée sur toutes les VM Compute Engine qui hébergent les composants de la couche Application dans les deux zones.
Sauvegardes d'applications Les sauvegardes de l'application sont créées, stockées et gérées à l'aide de Backup and DR.
Réseau de cloud privé virtuel (VPC) Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC. Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux. Pour en savoir plus, consultez Décider s'il convient de créer plusieurs réseaux VPC.
Oracle Database@Google Cloud

Les applications lisent et écrivent des données dans les bases de données Oracle du service Oracle Exadata Database. Vous provisionnez Oracle Exadata Database Service à l'aide d'Oracle Database@Google Cloud, une offre Cloud Marketplace qui vous permet d'exécuter des bases de données Oracle sur du matériel géré par Oracle dans un centre de données Google Cloud .

Vous utilisez des interfaces Google Cloud telles que la console Google Cloud , Google Cloud CLI et les API pour créer des instances Exadata Infrastructure. Oracle configure et gère l'infrastructure de calcul, de stockage et de réseau requise dans un centre de données d'une région Google Cloud sur du matériel dédié à votre projet.
Instances d'infrastructure Exadata Chaque instance d'infrastructure Exadata contient au moins deux serveurs de base de données physiques et au moins trois serveurs de stockage. Ces serveurs, qui ne sont pas représentés dans le diagramme, sont interconnectés à l'aide d'un réseau à faible latence. Lorsque vous créez une instance Exadata Infrastructure, vous spécifiez le nombre de serveurs de base de données et de serveurs de stockage à provisionner.
Clusters de VM Exadata

Dans une instance d'infrastructure Exadata, vous créez un ou plusieurs clusters de VM Exadata. Par exemple, vous pouvez choisir de créer et d'utiliser un cluster de VM Exadata distinct pour héberger les bases de données requises pour chacune de vos unités commerciales. Chaque cluster de VM Exadata contient une ou plusieurs VM Oracle Linux qui hébergent des instances Oracle Database.

Lorsque vous créez un cluster de VM Exadata, vous spécifiez les éléments suivants :

  • Nombre de serveurs de base de données.
  • Capacité de calcul, de mémoire et de stockage à allouer à chaque VM du cluster.
  • Réseau VPC auquel le cluster doit se connecter.
  • Plages d'adresses IP des sous-réseaux de sauvegarde et client pour le cluster.

Les VM des clusters de VM Exadata ne sont pas des VM Compute Engine.
Instances Oracle Database Vous créez et gérez des bases de données Oracle via la console OCI et d'autres interfaces OCI. Le logiciel Oracle Database s'exécute sur les VM du cluster de VM Exadata. Lorsque vous créez le cluster de VM Exadata, vous spécifiez la version d'Oracle Grid Infrastructure. Vous pouvez également choisir le type de licence : utiliser vos propres licences (BYOL) ou opter pour le modèle avec licence incluse.
VCN OCI et sous-réseaux Lorsque vous créez un cluster de VM Exadata, un réseau cloud virtuel OCI (VCN) est créé automatiquement. Le VCN comporte un sous-réseau client et un sous-réseau de secours avec des plages d'adresses IP que vous spécifiez. Le sous-réseau client est utilisé pour la connectivité entre votre réseau VPC et les bases de données Oracle. Le sous-réseau de sauvegarde est utilisé pour envoyer les sauvegardes de base de données vers OCI Object Storage.
Cloud Router, Partner Interconnect et OCI DRG Le trafic entre votre réseau VPC et le VCN est acheminé par Cloud Router associé au VPC et par une passerelle de routage dynamique (DRG) associée au VCN. Le trafic transite par une connexion à faible latence que Google configure à l'aide de interconnexion partenaire.
Zone Cloud DNS privée Lorsque vous créez un cluster de VM Exadata, une zone privée Cloud DNS est créée automatiquement. Lorsque vos applications envoient des requêtes de lecture et d'écriture aux bases de données Oracle, Cloud DNS résout les noms d'hôte de la base de données en adresses IP correspondantes.
OCI Object Storage et OCI Service Gateway Par défaut, les sauvegardes des bases de données Oracle Exadata sont stockées dans OCI Object Storage. Les sauvegardes de base de données sont acheminées vers OCI Object Storage via une passerelle de service.
Passerelle Cloud NAT publique L'architecture inclut une passerelle Cloud NAT publique pour activer les connexions sortantes sécurisées à partir des VM Compute Engine, qui ne possèdent que des adresses IP internes.
Cloud Interconnect ou Cloud VPN Pour connecter votre réseau sur site au réseau VPC dansGoogle Cloud, vous pouvez utiliser Cloud Interconnect ou Cloud VPN. Pour en savoir plus sur les avantages relatifs de chaque approche, consultez Choisir un produit de connectivité réseau.
Cloud Monitoring Vous pouvez utiliser Cloud Monitoring pour observer le comportement, l'état et les performances de votre application et de vos ressources Google Cloud , y compris les ressources Oracle Exadata. Vous pouvez également surveiller les ressources Oracle Exadata à l'aide du service OCI Monitoring.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants :

  • Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
  • Google Cloud Armor : service de sécurité réseau qui propose des règles de pare-feu d'application Web (WAF) et aide à se protéger contre les attaques DDoS et d'applications.
  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud . Le VPC inclut l'appairage de réseaux VPC, Private Service Connect, l'accès aux services privés et le VPC partagé.
  • Cloud NAT : service qui fournit une traduction d'adresse réseau hautes performances gérée par Google Cloud.
  • Cloud Monitoring : service qui offre une visibilité sur les performances, la disponibilité et l'état de vos applications et de votre infrastructure.
  • Cloud Interconnect : service qui étend votre réseau externe au réseau Google via une connexion à haute disponibilité et à faible latence.
  • Partner Interconnect : service qui fournit une connectivité entre votre réseau sur site et vos réseaux de cloud privé virtuel, ainsi que d'autres réseaux, via un fournisseur de services agréé.
  • Cloud VPN : service qui étend de manière sécurisée votre réseau de pairs au réseau de Google via un tunnel VPN IPsec.
  • Compute Engine : service de calcul sécurisé et personnalisable qui vous permet de créer et d'exécuter des machines virtuelles au sein de l'infrastructure de Google.
  • Google Cloud Hyperdisk : service de stockage réseau que vous pouvez utiliser pour provisionner et mettre à l'échelle de manière dynamique des volumes de stockage de blocs avec des performances configurables et prévisibles.
  • Filestore : service qui fournit un stockage de fichiers hautes performances et entièrement géré sur Google Cloud , auquel vous pouvez vous connecter à différents types de clients.
  • Service Backup and DR : service de sauvegarde et de récupération sécurisé géré de manière centralisée pour les charges de travail Google Cloud , qui protège les données de sauvegarde contre la suppression malveillante ou accidentelle.
  • Cloud DNS : service qui fournit un service DNS résilient et à faible latence à partir du réseau mondial de Google.

Cette architecture de référence utilise les produits Oracle suivants :

  • Oracle E-Business Suite : suite d'applications pour les opérations commerciales telles que la finance, les ressources humaines et la chaîne d'approvisionnement.
  • Exadata Database Service sur une infrastructure dédiée : service qui vous permet d'exécuter des instances Oracle Database sur du matériel Exadata qui vous est dédié.
  • Stockage d'objets : service permettant de stocker de grandes quantités de données structurées et non structurées sous forme d'objets.
  • VCN et sous-réseaux : un VCN est un réseau virtuel et privé pour les ressources d'une région OCI. Un sous-réseau est une plage contiguë d'adresses IP avec un VCN.
  • Passerelle de routage dynamique : routeur virtuel pour le trafic entre un VCN et des réseaux externes.
  • Passerelle de service : passerelle permettant aux ressources d'un VCN d'accéder de manière privée à des services Oracle spécifiques.

Vous êtes responsable de l'obtention de licences pour les produits Oracle que vous déployez dans Google Cloud. Vous êtes également responsable du respect des conditions d'utilisation des licences Oracle.

Considérations de conception

Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, d'efficacité opérationnelle, de coût et de performances. Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations du Google Cloud Well-Architected Framework.

Conception du système

Cette section vous aide à choisir des Google Cloud régions pour votre déploiement et à sélectionner les services Google Cloud appropriés.

Sélection de la région

Lorsque vous choisissez les régions Google Cloud dans lesquelles vos applications doivent être déployées, tenez compte des facteurs et exigences suivants :

  • Disponibilité des services Google Cloud dans chaque région. Pour en savoir plus, consultez la page Produits disponibles par emplacement.
  • Disponibilité des types de machines Compute Engine dans chaque région. Pour en savoir plus, consultez la page Régions et zones.
  • Exigences relatives à la latence de l'utilisateur final.
  • Coût des ressources Google Cloud .
  • Coûts des transferts de données interrégionaux.
  • Exigences réglementaires.

Certains de ces facteurs et exigences peuvent impliquer des compromis. Par exemple, la région la plus rentable en termes de coûts peut ne pas avoir l'empreinte carbone la plus basse. Pour en savoir plus, consultez Bonnes pratiques pour la sélection des régions Compute Engine.

Infrastructure de calcul

L'architecture de référence décrite dans ce document utilise des VM Compute Engine pour certains niveaux de l'application. Selon les exigences de votre application, vous pouvez choisir parmi d'autres services de calcul Google Cloud  :

  • Conteneurs : vous pouvez exécuter des applications conteneurisées dans des clusters Google Kubernetes Engine (GKE). GKE est un moteur d'orchestration de conteneurs qui automatise le déploiement, le scaling et la gestion des applications conteneurisées.
  • Sans serveur : si vous préférez concentrer vos efforts informatiques sur vos données et vos applications plutôt que sur la configuration et l'exploitation des ressources d'infrastructure, vous pouvez utiliser des services sans serveur tels que Cloud Run.

La décision d'utiliser des VM, des conteneurs ou des services sans serveur implique un compromis entre la flexibilité de la configuration et les efforts de gestion. Les VM et les conteneurs offrent davantage de flexibilité de configuration, mais vous êtes responsable de la gestion des ressources. Dans une architecture sans serveur, vous déployez des charges de travail sur une plate-forme préconfigurée qui nécessite un effort de gestion minimal. Pour en savoir plus sur le choix des services de calcul appropriés pour vos charges de travail dansGoogle Cloud, consultez Héberger des applications sur Google Cloud.

Migration de bases de données

Lorsque vous prévoyez de migrer des bases de données sur site vers Oracle Database@Google Cloud, évaluez votre environnement de base de données actuel et obtenez des recommandations de configuration et de dimensionnement à l'aide de l'outil Database Migration Assessment (DMA).

Pour migrer des données sur site ou entre plates-formes, y compris les systèmes Unix, vers des déploiements de bases de données Oracle dans Google Cloud, vous pouvez utiliser des outils Oracle standards tels que Transportable Tablespaces. Pour en savoir plus sur les tablespaces transportables et leurs limites, consultez Migrer des données à l'aide de tablespaces transportables.

Avant d'utiliser les bases de données migrées dans un environnement de production, vérifiez la connectivité entre vos applications et les bases de données.

Options de stockage

L'architecture présentée dans ce document utilise des volumes Hyperdisk équilibrés Google Cloud pour les disques de démarrage des VM Compute Engine qui hébergent les applications Oracle E-Business Suite. Les volumes Hyperdisk offrent de meilleures performances, une plus grande flexibilité et une efficacité accrue par rapport aux disques persistants. Avec Hyperdisk Balanced, vous pouvez provisionner les IOPS et le débit séparément et de manière dynamique, ce qui vous permet d'adapter le volume à un large éventail de charges de travail. Pour en savoir plus sur les types et les fonctionnalités d'Hyperdisk, consultez À propos d'Hyperdisk Balanced.

Pour les données et les binaires d'application, l'architecture de ce document utilise Filestore. Les données que vous stockez dans une instance Filestore régionale sont répliquées de manière synchrone sur trois zones de la région. Cette réplication garantit la haute disponibilité et la robustesse en cas de pannes zonales. Vous pouvez également stocker sur l'instance Filestore des fichiers de configuration partagés, des outils et utilitaires courants, ainsi que des journaux centralisés, et installer l'instance sur plusieurs VM.

Lorsque vous concevez le stockage pour vos charges de travail, tenez compte des caractéristiques fonctionnelles des charges de travail, des exigences en matière de résilience, des attentes en termes de performances et des objectifs de coûts. Pour en savoir plus, consultez la section Concevoir une stratégie de stockage optimale pour votre charge de travail cloud.

Conception d'un réseau

Lorsque vous créez une infrastructure pour une pile d'applications multicouches, vous devez choisir une conception de réseau qui répond à vos exigences commerciales et techniques. L'architecture présentée dans ce document utilise une topologie de réseau avec un seul réseau VPC. Selon vos besoins, vous pouvez choisir d'utiliser plusieurs réseaux VPC. Pour en savoir plus, consultez la documentation suivante :

Analyse de données

Pour une analyse avancée, vous pouvez utiliser le Google Cloud Cortex Framework pour ingérer les données de vos applications Oracle E-Business Suite dans BigQuery. Pour en savoir plus, consultez Cortex Framework : intégration à Oracle E-Business Suite.

Sécurité, confidentialité et conformité

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir une topologie dans Google Cloud qui répond aux exigences de sécurité et de conformité de vos charges de travail.

Protection contre les menaces externes

Pour protéger votre application contre les menaces telles que les attaques par déni de service distribué (DDoS) et les scripts intersites (XSS), vous pouvez utiliser les stratégies de sécurité Google Cloud Armor. Chaque stratégie est un ensemble de règles qui spécifient certaines conditions devant être évaluées et les mesures à prendre lorsque ces conditions sont remplies. Par exemple, une règle peut spécifier que si l'adresse IP source du trafic entrant correspond à une adresse IP ou à une plage CIDR spécifique, le trafic doit être refusé. Vous pouvez également appliquer des règles de pare-feu d'application Web (WAF) préconfigurées. Pour en savoir plus, consultez la section Présentation des stratégies de sécurité.

Accès externe pour les VM

Dans l'architecture de référence décrite dans ce document, les VM Compute Engine n'ont pas besoin d'un accès entrant depuis Internet. N'attribuez pas d'adresses IP externes aux VM. Google Cloud Les ressources ne disposant que d'une adresse IP interne privée peuvent toujours accéder à certains services et API Google à l'aide de Private Service Connect ou de l'accès privé à Google. Pour en savoir plus, consultez la section Options d'accès privé pour les services.

Pour activer les connexions sortantes sécurisées à partir des ressources Google Cloud ne disposant que d'adresses IP privées, comme les VM Compute Engine de cette architecture de référence, vous pouvez utiliser le proxy Web sécurisé ou Cloud NAT.

Pour les sous-réseaux utilisés par les VM Exadata, Oracle recommande d'attribuer des plages d'adresses IP privées.

Droits des comptes de service

Pour les VM Compute Engine de l'architecture, au lieu d'utiliser les comptes de service par défaut, nous vous recommandons de créer des comptes de service dédiés et de spécifier les ressources auxquelles le compte de service peut accéder. Le compte de service par défaut inclut un large éventail d'autorisations qui ne sont pas nécessaires dans ce cas, alors que vous pouvez adapter les comptes de service dédiés pour qu'ils ne disposent que des autorisations requises. Pour en savoir plus, consultez Limiter les droits des comptes de service.

Sécurité SSH

Pour renforcer la sécurité des connexions SSH aux VM Compute Engine de cette architecture, implémentez le transfert Identity-Aware Proxy (IAP) avec l'API Cloud OS Login. IAP vous permet de contrôler l'accès au réseau en fonction de l'identité des utilisateurs et des stratégies IAM (Identity and Access Management). L'API Cloud OS Login vous permet de contrôler l'accès SSH Linux en fonction de l'identité de l'utilisateur et des règles IAM. Pour en savoir plus sur la gestion de l'accès au réseau, consultez Bonnes pratiques pour contrôler l'accès à la connexion SSH.

Chiffrement des données

Par défaut, les données stockées dans les volumes Hyperdisk et dans Filestore sont chiffrées à l'aide deGoogle-owned and Google-managed encryption keys. Pour renforcer la protection, vous pouvez choisir de chiffrer Google-owned and managed key à l'aide de clés dont vous êtes propriétaire et que vous gérez dans Cloud Key Management Service (Cloud KMS). Pour en savoir plus, consultez À propos du chiffrement des disques pour les volumes Hyperdisk et Chiffrer des données avec des clés de chiffrement gérées par le client pour Filestore.

Par défaut, les bases de données Exadata utilisent le chiffrement transparent des données (TDE), qui vous permet de chiffrer les données sensibles stockées dans les tables et les espaces de table.

Sécurité du réseau

Pour contrôler le trafic réseau entre les ressources de l'architecture, vous devez configurer des règles de pare-feu Cloud nouvelle génération (NGFW) appropriées.

Sécurité et conformité des bases de données

Le service Exadata Database inclut Oracle Data Safe, qui vous aide à gérer les exigences de sécurité et de conformité pour les bases de données Oracle. Vous pouvez utiliser Oracle Data Safe pour évaluer les contrôles de sécurité, surveiller l'activité des utilisateurs et masquer les données sensibles. Pour en savoir plus, consultez Gérer la sécurité des bases de données avec Oracle Data Safe.

Autres considérations sur la sécurité

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations de sécurité au niveau de la plate-forme fournies dans le plan de base Enterprise et le Google Cloud Well-Architected Framework : sécurité, confidentialité et conformité.

Fiabilité

Cette section décrit les facteurs de conception à prendre en compte lorsque vous utilisez cette architecture de référence pour créer et exploiter une infrastructure fiable pour votre déploiement dansGoogle Cloud.

Robustesse de la couche application face aux défaillances de VM

Si certaines (mais pas toutes) des VM qui hébergent les applications Oracle E-Business Suite échouent, les applications restent disponibles, car l'équilibreur de charge transfère les requêtes vers d'autres VM d'application.

Parfois, une VM d'application peut être en cours d'exécution et disponible, mais vous pouvez rencontrer des problèmes avec l'application proprement dite. L'application peut se figer, planter ou manquer de mémoire. Dans ce scénario, la VM ne répond pas aux vérifications de l'état de l'équilibreur de charge, et l'équilibreur de charge ne route pas le trafic vers la VM qui ne répond pas.

Robustesse en cas de pannes zonales

Dans une architecture régionale, si l'une des zones subit une panne, l'équilibreur de charge transfère les requêtes vers les instances des applications qui s'exécutent dans l'autre zone. Filestore reste disponible, car l'architecture utilise le niveau de service Filestore Regional.

Pour garantir la haute disponibilité des données dans les volumes Hyperdisk en cas d'indisponibilité d'une seule zone, vous pouvez utiliser Hyperdisk équilibré à haute disponibilité. Lorsque des données sont écrites sur un volume Hyperdisk Balanced à haute disponibilité, elles sont répliquées de manière synchrone entre deux zones de la même région.

Robustesse en cas de pannes régionales

En cas de panne régionale, les applications ne sont pas disponibles. Pour réduire les temps d'arrêt causés par les pannes régionales, vous pouvez mettre en œuvre l'approche suivante :

  • Gérez une instance répliquée passive (de basculement) du niveau Application dans une autre région Google Cloud .
  • Créez une instance d'infrastructure Exadata de secours avec les clusters de VM Exadata requis dans la même région que celle qui contient la réplique passive de la pile d'applications. Utilisez Oracle Data Guard pour la réplication des données et le basculement automatique vers les bases de données Exadata de secours. Si votre application a besoin d'un objectif de point de récupération (RPO) plus faible, vous pouvez sauvegarder et récupérer les bases de données à l'aide d'Oracle Autonomous Recovery Service.
  • En cas de panne dans la région principale, utilisez la réplique ou la sauvegarde de la base de données pour restaurer la base de données en production et activer l'application dans la région de basculement.
  • Utilisez des règles de routage DNS pour acheminer le trafic vers un équilibreur de charge externe dans la région de basculement.

Pour les applications stratégiques qui doivent rester disponibles même en cas de panne régionale, envisagez d'utiliser l'archétype de déploiement multirégional. Vous pouvez utiliser Oracle Active Data Guard pour fournir une base de données de secours en lecture seule dans la région de reprise après sinistre.

Oracle gère l'infrastructure dans Oracle Database@Google Cloud. Pour en savoir plus sur les objectifs de niveau de service (SLO) pour Oracle Exadata Database Service sur l'infrastructure dédiée, consultez Objectifs de niveau de service pour les services de cloud public Oracle PaaS et IaaS.

Planification de la capacité des VM

Pour vous assurer que la capacité des VM Compute Engine est disponible lorsque des VM doivent être provisionnées, vous pouvez créer des réservations. Une réservation garantit la capacité dans une zone spécifique pour un nombre spécifié de VM d'un type de machine que vous choisissez. Une réservation peut être spécifique à un projet ou partagée entre plusieurs projets. Pour en savoir plus sur les réservations, consultez Choisir un type de réservation.

Capacité de la base de données

Vous pouvez mettre à l'échelle l'infrastructure Exadata en ajoutant des serveurs de base de données et des serveurs de stockage selon vos besoins. Après avoir ajouté les serveurs de base de données ou de stockage requis à l'infrastructure Exadata, vous devez ajouter la capacité au cluster de VM Exadata associé pour pouvoir utiliser les ressources de stockage ou de processeur supplémentaires. Pour en savoir plus, consultez Scaling Exadata Compute and Storage.

Durabilité des données

L'architecture décrite dans ce document utilise Backup and DR pour créer, stocker et gérer des sauvegardes des VM Compute Engine. L'outil de sauvegarde et reprise après sinistre stocke les données de la sauvegarde dans leur format d'origine lisible par l'application. Si nécessaire, vous pouvez restaurer des charges de travail en production en utilisant directement les données d'un stockage de sauvegarde à long terme, sans avoir à préparer ni à déplacer les données.

Backup and DR propose deux méthodes pour créer des sauvegardes :

  • Stockage du parc de sauvegarde : les données de sauvegarde sont stockées dans la même région que les données sources. Elles ne peuvent pas être modifiées ni supprimées.
  • Stockage autogéré : les utilisateurs autorisés peuvent modifier ou supprimer les données de sauvegarde, et vous pouvez stocker des données dans plusieurs régions.

Pour en savoir plus, consultez la documentation suivante :

Pour assurer la durabilité des binaires d'application dans votre instance Filestore, vous pouvez créer des sauvegardes et des instantanés de l'instance.

Par défaut, les sauvegardes des bases de données dans Oracle Exadata Database Service on Dedicated Infrastructure sont stockées dans OCI Object Storage. Pour obtenir un RPO plus faible, vous pouvez sauvegarder et récupérer les bases de données à l'aide d'Oracle Autonomous Recovery Service.

Autres considérations sur la fiabilité

Lorsque vous créez l'architecture cloud pour votre charge de travail, passez en revue les bonnes pratiques et les recommandations liées à la fiabilité fournies dans la documentation suivante :

Optimisation des coûts

Cette section fournit des conseils pour optimiser les coûts de configuration et d'exploitation d'une topologie Google Cloud que vous créez à l'aide de cette architecture de référence.

Types de machine des VM

Pour vous aider à optimiser l'utilisation des ressources de vos instances de VM, Compute Engine propose des recommandations de types de machines. Utilisez les recommandations pour choisir les types de machines qui correspondent aux exigences de calcul de votre charge de travail. Pour les charges de travail ayant des besoins en ressources prévisibles, vous pouvez personnaliser le type de machine en fonction de vos besoins et réaliser des économies en utilisant des types de machines personnalisés.

Licences de produits Oracle

Vous êtes responsable de l'obtention de licences pour les applications Oracle E-Business Suite que vous déployez sur Compute Engine. Vous êtes également responsable du respect des conditions d'utilisation des licences Oracle. Lorsque vous calculez le coût des licences, tenez compte du nombre de licences Oracle Processor requises en fonction du type de machine que vous choisissez pour les VM Compute Engine qui hébergent les produits Oracle. Pour en savoir plus, consultez Licensing Oracle Software in the Cloud Computing Environment.

Coûts associés à la base de données

Lorsque vous créez un cluster de VM Exadata, vous pouvez choisir d'utiliser votre propre licence (BYOL) ou de provisionner des bases de données Oracle avec licence incluse.

Les frais de Mise en réseau pour le transfert de données entre vos applications et les bases de données Oracle Exadata situées dans la même région sont inclus dans le prix de l'offre Oracle Database@Google Cloud.

Autres considérations sur les coûts

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales fournies dans le Google Cloud Well-Architected Framework : optimisation des coûts.

Efficacité opérationnelle

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir une topologie Google Cloud que vous pouvez exploiter efficacement.

Images de VM

Pour vos VM, vous pouvez utiliser des images Oracle Linux disponibles dans Compute Engine ou importer des images Oracle Linux que vous créez et gérez. Vous pouvez également créer et utiliser des images d'OS personnalisées qui incluent les configurations et logiciels requis par vos applications. Vous pouvez regrouper vos images personnalisées dans une famille d'images personnalisées. Une famille d'images pointe toujours vers la plus récente des images qu'elle contient, ce qui permet aux modèles d'instance et aux scripts d'utiliser cette image sans qu'il soit nécessaire de mettre à jour les références pour désigner une version spécifique de l'image. Vous devez mettre à jour régulièrement vos images personnalisées pour inclure les mises à jour et les correctifs de sécurité fournis par le fournisseur de l'OS.

Administration des bases de données

Oracle gère les serveurs de base de données physiques, les serveurs de stockage et le matériel réseau dans Oracle Exadata Database Service sur une infrastructure dédiée. Vous pouvez gérer les instances d'infrastructure Exadata et les clusters de VM Exadata via les interfaces OCI ou Google Cloud . Vous créez et gérez des bases de données à l'aide des interfaces OCI. Les pages de la console Google Cloud pour Oracle Database@Google Cloud incluent des liens que vous pouvez utiliser pour accéder directement aux pages correspondantes de la console OCI. Pour éviter d'avoir à vous reconnecter à OCI, vous pouvez configurer la fédération d'identité entre OCI et Google Cloud.

Documentation et assistance Oracle

Les produits Oracle qui s'exécutent sur des VM Compute Engine présentent des préoccupations opérationnelles similaires à celles des produits Oracle qui s'exécutent sur site. Toutefois, vous n'avez pas besoin de gérer l'infrastructure de calcul, de réseau et de stockage sous-jacente.

  • Pour obtenir des conseils sur l'utilisation et la gestion des produits Oracle, consultez la documentation fournie par Oracle pour le produit concerné.
  • Pour en savoir plus sur la politique d'assistance d'Oracle concernant les instances Oracle Database que vous déployez dans Google Cloud, consultez Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).
  • Pour obtenir un récapitulatif des règles d'assistance Oracle pour Oracle E-Business Suite, consultez Certifications EBS.

Observabilité

Pour implémenter l'observabilité pour votre déploiement Oracle E-Business Suite surGoogle Cloud, vous pouvez utiliser les services Google Cloud Observability ou Oracle Enterprise Manager. Choisissez une stratégie de surveillance appropriée en fonction de vos exigences et contraintes. Par exemple, si vous exécutez d'autres charges de travail dans Google Cloud en plus des applications Oracle E-Business Suite, vous pouvez utiliser les services Google Cloud Observability pour créer un tableau de bord des opérations unifié pour toutes les charges de travail.

Autres considérations opérationnelles

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales pour l'efficacité opérationnelle décrites dans la section Google Cloud Framework Well-Architected : excellence opérationnelle.

Optimisation des performances

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir une topologie dans Google Cloud qui répond aux exigences de performances de vos charges de travail.

Performances de calcul

Compute Engine propose un large éventail de types de machines prédéfinis et personnalisables pour les charges de travail que vous exécutez sur les VM. Choisissez un type de machine adapté en fonction de vos exigences en termes de performances. Pour en savoir plus, consultez le Guide des ressources de familles de machines et guide comparatif.

Performances du réseau

Compute Engine applique une limite par VM pour la bande passante réseau de sortie. Cette limite dépend du type de machine de la VM et du fait que le trafic soit acheminé ou non via le même réseau VPC que la VM source. Pour les VM avec certains types de machines, vous pouvez obtenir une bande passante de sortie maximale plus élevée en activant la mise en réseau Tier_1 afin d'améliorer les performances réseau. Pour en savoir plus, consultez Configurer les performances réseau Tier_1 par VM.

Le trafic réseau entre les VM du niveau Application et le réseau Oracle Exadata est acheminé via une connexion interconnexion partenaire à faible latence configurée par Google.

L'infrastructure Exadata utilise RDMA over Converged Ethernet (RoCE) pour une mise en réseau à haut débit et à faible latence entre les serveurs de base de données et les serveurs de stockage. Les serveurs échangent des données directement dans la mémoire principale sans impliquer le processeur, le cache ni le système d'exploitation.

Performances de stockage Hyperdisk

L'architecture décrite dans ce document utilise des volumes Hyperdisk pour tous les disques de démarrage des VM qui hébergent les applications Oracle E-Business Suite. Hyperdisk vous permet de faire évoluer les performances et la capacité de manière dynamique. Vous pouvez ajuster les IOPS et le débit provisionnés, ainsi que la taille de chaque volume pour répondre aux besoins des performances et de la capacité de stockage de votre charge de travail. Les performances des volumes Hyperdisk dépendent du type d'Hyperdisk et du type de machine des VM auxquelles les volumes sont associés. Pour en savoir plus sur les limites de performances et le réglage d'Hyperdisk, consultez la documentation suivante :

Autres considérations sur les performances

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales fournies dans le Google Cloud Framework Well-Architected : optimisation des performances.

Étapes suivantes

Contributeurs

Auteurs :

Autres contributeurs :