Oracle PeopleSoft sur Compute Engine avec Oracle Exadata

Last reviewed 2025-08-21 UTC

Ce document fournit une architecture de référence pour vous aider à créer l'infrastructure permettant d'exécuter des applications Oracle PeopleSoft sur des VM Compute Engine avec une connectivité à faible latence à Oracle Database@Google Cloud (bases de données Oracle Cloud Infrastructure Exadata qui s'exécutent dans Google Cloud). Oracle PeopleSoft est une suite d'applications d'entreprise pour la gestion du capital humain, les solutions de campus et la planification des ressources d'entreprise.

Ce document s'adresse aux architectes cloud et aux administrateurs de bases de données Oracle et d'applications Oracle PeopleSoft. Dans ce document, nous partons du principe que vous connaissez bien les applications Oracle PeopleSoft et les bases de données Oracle.

Architecture

Le schéma suivant illustre une architecture dans laquelle les applications Oracle PeopleSoft s'exécutent sur des VM Compute Engine dans une région Google Cloudet utilisent des bases de données Oracle Exadata dans la même région Google Cloud .

Architecture pour Oracle PeopleSoft avec Oracle Exadata.

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 les requêtes des utilisateurs et les distribue aux serveurs Web Oracle PeopleSoft. Pour garantir l'affinité de session, l'équilibreur de charge est configuré pour utiliser des cookies générés.
Règles de sécurité Google Cloud Armor La stratégie de sécurité Cloud Armor permet de 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).
Niveau Web Oracle PeopleSoft (BYOL) Le niveau Web Oracle PeopleSoft se compose de serveurs Web qui s'exécutent indépendamment sur deux VM Compute Engine. Vous utilisez vos propres licences (BYOL) pour Oracle PeopleSoft, et vous gérez les VM et le logiciel serveur Web.
Binaires du serveur Web Une instance Filestore contient les binaires du serveur Web. L'instance Filestore est installée sur toutes les VM Compute Engine qui hébergent les serveurs Web.
Oracle PeopleSoft mid tier (BYOL)

Le niveau intermédiaire d'Oracle PeopleSoft se compose des éléments suivants :

  • OpenSearch
  • Serveur d'application
  • Ordonnancement de processus

Chacun de ces composants s'exécute indépendamment sur deux VM Compute Engine. Vous utilisez vos propres licences (BYOL) pour les composants Oracle PeopleSoft, et vous gérez les VM et le logiciel de niveau intermédiaire.
Binaires de niveau intermédiaire Une instance Filestore contient les binaires de niveau intermédiaire. L'instance Filestore est installée sur toutes les VM Compute Engine qui hébergent les composants de niveau intermédiaire.
Sauvegardes d'applications Les sauvegardes de l'application sont créées, stockées et gérées à l'aide du service Backup and DR.
Réseau de cloud privé virtuel (VPC) Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC. Les serveurs Web, les composants de niveau intermédiaire et les bases de données se trouvent dans des sous-réseaux distincts.
Oracle Database@Google Cloud

Les applications Oracle PeopleSoft lisent et écrivent des données dans les bases de données Oracle d'Oracle Exadata Database Service. 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 comme la console Google Cloud , la Google Cloud CLI et les API pour créer des instances d'infrastructure Exadata. Oracle configure et gère l'infrastructure de calcul, de stockage et de mise en réseau requise dans un centre de données d'une région Google Cloud sur du matériel dédié à votre projet.

Pour optimiser la latence entre l'application et la base de données, déployez l'application dans la même zone que celle où vous créez les instances d'infrastructure Exadata.
Instance d'infrastructure Exadata L'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 sur le schéma, sont interconnectés à l'aide d'une structure réseau à faible latence. Lorsque vous créez l'instance d'infrastructure Exadata, vous spécifiez le nombre de serveurs de base de données et de serveurs de stockage à provisionner.
Clusters de VM Exadata

Dans l'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 du 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 instances Oracle Database via la console Oracle Cloud Infrastructure (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 et choisissez le type de licence. Vous pouvez 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 (VCN) OCI est créé automatiquement. Le VCN comporte un sous-réseau client et un sous-réseau de sauvegarde avec les 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 permet d'envoyer des sauvegardes de base de données vers OCI Object Storage.
Cloud Router, Partner Interconnect et OCI DRG Le trafic entre votre réseau VPC dans Google Cloudet le VCN OCI est acheminé par un routeur Cloud Router via une passerelle de routage dynamique (DRG) associée au VCN OCI. 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 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 (facultatif) L'architecture inclut une passerelle Cloud NAT publique facultative. La passerelle permet d'établir des connexions sortantes sécurisées à partir des VM Compute Engine, qui ne disposent que d'adresses IP internes.
Cloud Interconnect ou Cloud VPN Pour connecter votre réseau sur site au réseau VPC dans Google 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 :

  • 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.
  • 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 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 cloud privé virtuel et d'autres réseaux via un fournisseur de services agréé.
  • Cloud VPN : service qui étend votre réseau de pairs au réseau Google de façon sécurisée, via un tunnel VPN IPsec.
  • Cloud NAT : service qui fournit une traduction d'adresse réseau hautes performances gérée par Google Cloud.
  • 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 PeopleSoft : suite d'applications d'entreprise pour la gestion du capital humain, les solutions de campus et la planification des ressources d'entreprise.
  • 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é.
  • 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 d'adresses IP contiguës avec un VCN.
  • Passerelle de routage dynamique : routeur virtuel pour le trafic entre un VCN et des réseaux externes.
  • Stockage d'objets : service permettant de stocker de grandes quantités de données structurées et non structurées sous forme d'objets.
  • Passerelle de service : passerelle permettant aux ressources d'un VCN d'accéder à des services Oracle spécifiques de manière privée.

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 de ces licences Oracle.

Considérations de conception

Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception que vous devez 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 de votre charge de travail, tenez également compte des bonnes pratiques et des recommandations du Google Cloud Well-Architected Framework.

Conception du système

Cette section fournit des conseils pour vous aider à choisir les régions Google Cloud de 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 tolérée par l'utilisateur final.
  • Coût des ressources Google Cloud .
  • Coûts des transferts de données interrégionaux.
  • Exigences réglementaires.
  • Exigences de durabilité.

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.

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 en savoir plus sur la procédure et les outils que vous pouvez utiliser pour migrer des bases de données Oracle vers Google Cloud, consultez l'outil de conseil sur les méthodes de migration Oracle.

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

Options de stockage

Pour les VM Compute Engine de l'architecture, vous pouvez utiliser des volumes de démarrage Google Cloud Hyperdisk ou Persistent Disk. Les volumes Hyperdisk offrent des performances, une flexibilité et une efficacité supérieures à celles des disques persistants. Avec Google Cloud Hyperdisk Balanced, vous pouvez provisionner les IOPS et le débit séparément et de manière dynamique, ce qui vous permet d'ajuster le volume à une grande variété de charges de travail.

Pour stocker les binaires d'application, utilisez Filestore. Les fichiers que vous stockez dans une instance Filestore Regional sont répliqués de manière synchrone sur trois zones de la région. Cette réplication permet de garantir la haute disponibilité et la robustesse en cas de pannes zonales. Pour assurer la robustesse en cas de panne régionale, vous pouvez répliquer une instance Filestore dans une autre région. Pour en savoir plus, consultez Réplication d'instance.

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 du réseau Oracle Database@Google Cloud

Choisissez une conception de réseau qui répond à vos exigences commerciales et techniques. Par exemple, vous pouvez utiliser un seul réseau VPC ou plusieurs réseaux VPC. Pour en savoir plus, consultez Sélectionner des topologies réseau pour Oracle Database@Google Cloud.

Lorsque vous attribuez des plages d'adresses IP pour les sous-réseaux client et de sauvegarde à utiliser pour les clusters de VM Exadata, tenez compte des exigences de taille minimale des sous-réseaux. Pour en savoir plus, consultez Planifier l'espace d'adressage IP dans Oracle Database@Google Cloud.

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 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 dispose d'un large éventail d'autorisations, dont certaines ne sont peut-être pas nécessaires. Vous pouvez personnaliser les comptes de service dédiés pour qu'ils ne disposent que des autorisations essentielles. 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 votre architecture, implémentez Identity-Aware Proxy (IAP) et l'API Cloud OS Login. IAP vous permet de contrôler l'accès au réseau en fonction de l'identité de l'utilisateur et des stratégies Identity and Access Management (IAM). 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 stratégies IAM. Pour en savoir plus sur la gestion de l'accès 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 Hyperdisk, Persistent Disk et 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 que vous possédez et gérez dans Cloud Key Management Service (Cloud KMS). Pour en savoir plus, consultez À propos du chiffrement des disques pour les volumes Hyperdisk et Persistent Disk, 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 des tables et des espaces de table.

Sécurité réseau

Pour contrôler le trafic réseau entre les ressources de l'architecture, vous devez configurer des stratégies Cloud Next Generation Firewall (NGFW) appropriées.

Pour les VM du serveur Web, assurez-vous que le champ source de la règle d'entrée inclut les éléments suivants :

Sécurité et conformité d'Oracle Exadata

Oracle Exadata Database Service 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 dans 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 d'application contre les défaillances de VM

Si l'une des deux VM qui hébergent chaque composant Oracle PeopleSoft échoue, l'application reste disponible. Les requêtes sont acheminées vers l'autre VM.

Parfois, une VM peut être en cours d'exécution et disponible, mais vous pouvez rencontrer des problèmes avec le composant Oracle PeopleSoft proprement dit. Le composant peut se figer, planter ou manquer de mémoire. Dans ces scénarios, la VM ne répond pas aux vérifications d'état de l'équilibreur de charge, et l'équilibreur de charge n'achemine pas le trafic vers la VM qui ne répond pas.

Robustesse en cas de pannes zonales ou régionales

En cas de panne zonale ou régionale, l'application est indisponible. Pour réduire les temps d'arrêt causés par de telles pannes, vous pouvez mettre en œuvre l'approche suivante :

  • Conservez une instance répliquée passive (de basculement) de la pile d'applications dans une autre région ou zoneGoogle Cloud .
  • Créez une instance d'infrastructure Exadata de secours avec les clusters de VM Exadata requis dans la même zone que l'instance répliquée passive de la pile d'applications. Utilisez Oracle Active 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 nécessite un objectif de point de récupération (RPO) inférieur, 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 ou la zone principale, utilisez l'instance répliquée 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 ou la zone de basculement.
  • Si l'instance répliquée passive se trouve dans une autre région, utilisez des règles de routage Cloud DNS pour acheminer le trafic vers l'équilibreur de charge externe de cette région.

Pour en savoir plus, consultez Oracle Maximum Availability Architecture (MAA) for Oracle Database@Google Cloud.

Oracle gère l'infrastructure dans Oracle Database@Google Cloud. Pour en savoir plus sur les objectifs de niveau de service (SLO) d'Oracle Exadata Database Service sur une infrastructure dédiée, consultez Objectifs de niveau de service pour les services cloud publics 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é Oracle Exadata

Vous pouvez faire évoluer 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 processeur ou de stockage supplémentaires. Pour en savoir plus, consultez Scaling Exadata Compute and Storage (Effectuer un scaling du calcul et du stockage Exadata).

Durabilité des données

Vous pouvez utiliser le service Backup and DR pour créer, stocker et gérer des sauvegardes des VM Compute Engine. Le service Backup and DR stocke les données de la sauvegarde dans leur format d'origine lisible par l'application. Si nécessaire, vous pouvez restaurer vos charges de travail en production en utilisant directement les données d'un stockage de sauvegarde à long terme sans perdre du temps à déplacer les données ni à les préparer. Pour en savoir plus, consultez Backup and DR pour les sauvegardes d'instances Compute Engine.

Pour garantir la durabilité des données de vos instances Filestore, vous pouvez créer des sauvegardes et des instantanés de l'instance ou utiliser Backup and DR pour Filestore et les systèmes de fichiers.

Par défaut, les sauvegardes des bases de données d'Oracle Exadata Database Service sur une infrastructure dédiée sont stockées dans OCI Object Storage. Pour réduire lRPO, 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 produits Oracle que vous déployez sur Compute Engine. Vous êtes également responsable du respect des conditions d'utilisation de ces licences. Pour en savoir plus, consultez Licensing Oracle Software in the Cloud Computing Environment (Licences des logiciels Oracle dans l'environnement de cloud computing).

Licences de base de données Oracle Exadata

Lorsque vous créez un cluster de VM Exadata, vous pouvez utiliser votre propre licence (BYOL) ou une licence que vous avez achetée dans le cadre de votre commande Google Cloud Marketplace pour Oracle Database@Google Cloud.

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 la section 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 Oracle Linux

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 les logiciels requis par vos applications. Regroupez 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. Mettez régulièrement à jour vos images personnalisées pour inclure les mises à jour de sécurité et les correctifs fournis par le fournisseur de l'OS.

Administration de base de données Oracle Exadata

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 via les 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.

Observabilité pour les applications Oracle

Pour mettre en œuvre l'observabilité des charges de travail Oracle déployées dans Google 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 de vos contraintes. Par exemple, si vous exécutez d'autres charges de travail dans Google Cloud en plus des charges de travail Oracle, vous pouvez utiliser les services Google Cloud Observability pour créer un tableau de bord de surveillance unifié pour toutes les charges de travail.

Documentation et assistance Oracle

Les produits Oracle qui s'exécutent sur des VM Compute Engine présentent des problèmes opérationnels similaires à ceux des produits Oracle qui s'exécutent sur site. Toutefois, vous n'avez pas besoin de gérer l'infrastructure de calcul, de mise en réseau et de stockage sous-jacente. Pour obtenir des conseils sur l'utilisation et la gestion des produits Oracle, consultez la documentation Oracle correspondante.

Pour en savoir plus sur la règle d'assistance d'Oracle pour les instances Oracle Database que vous déployez dans Google Cloud, consultez Assistance Oracle Database pour les environnements cloud publics non Oracle (ID de document 2688277.1).

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 Well-Architected Framework: 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 dans Google Cloud une topologie 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 des VM. Choisissez un type de machine approprié en fonction de vos exigences 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 de l'acheminement du trafic via le même réseau VPC que la VM source. Pour les VM de 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. Pour en savoir plus, consultez Configurer les performances réseau Tier_1 par VM.

Le trafic réseau entre les VM d'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 à bande passante élevée et à faible latence entre ses serveurs de base de données et ses 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.

Pour optimiser la latence entre votre application et la base de données, déployez l'application dans la même zone que celle où vous créez l'instance d'infrastructure Exadata.

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 la section Google Cloud Well-Architected Framework : optimisation des performances.

Étapes suivantes

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :