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 s'exécutant dans Google Cloud). Oracle PeopleSoft est une suite d'applications d'entreprise pour la gestion du capital humain, les solutions pour les campus et la planification des ressources de l'entreprise.

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

Architecture

Le diagramme 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ègle de sécurité Google Cloud Armor La stratégie de sécurité 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).
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 apportez vos propres licences (BYOL) pour Oracle PeopleSoft, et vous gérez les VM et le logiciel de 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.
Niveau intermédiaire Oracle PeopleSoft (BYOL)

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

  • OpenSearch
  • Serveur d'application
  • Planificateur de processus

Chacun de ces composants s'exécute indépendamment sur deux VM Compute Engine. Vous apportez 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 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 comme la console Google Cloud , la 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 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 Exadata Infrastructure.
Instance d'infrastructure Exadata L'instance Exadata Infrastructure 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 schéma, sont interconnectés à l'aide d'un réseau à faible latence. Lorsque vous créez l'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 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 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 instances Oracle Database via la console Oracle Cloud Infrastructure (OCI) et d'autres interfaces OCI. Le logiciel de base de données Oracle 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 apporter 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 sauvegarde 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 à OCI Object Storage.
Cloud Router, Partner Interconnect, et OCI DRG Le trafic entre votre réseau VPC dans Google Cloud et le VCN OCI est acheminé par 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 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 bases 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 possèdent que des 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 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.
  • 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 pour les 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 contiguë d'adresses IP 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 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 également compte des bonnes pratiques et des recommandations du Google Cloud Framework Well-Architected.

Conception du système

Cette section vous aide à choisir des Google Cloud régions pour votre déploiement et à sélectionner les Google Cloud services 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.

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 Oracle Migration Methods Advisor.

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

Pour les VM Compute Engine de l'architecture, vous pouvez utiliser des volumes de démarrage Hyperdisk ou Persistent Disk. Les volumes Hyperdisk offrent de meilleures performances, une plus grande flexibilité et une meilleure efficacité que les 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 à 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 Régional sont répliqués de manière synchrone sur trois zones de la région. Cette réplication permet d'assurer la haute disponibilité et la robustesse en cas de pannes zonales. Pour assurer la robustesse en cas d'indisponibilité d'une région, vous pouvez répliquer une instance Filestore dans une autre région. Pour en savoir plus, consultez Réplication d'instances.

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 minimales concernant la taille des sous-réseaux. Pour en savoir plus, consultez Planifier l'espace d'adresses 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 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 dispose d'un large éventail d'autorisations, dont certaines qui ne sont peut-être pas nécessaires. Vous pouvez personnaliser des 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 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 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 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 de disque 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 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.

Pour les VM du serveur Web, assurez-vous que le champ de source de la stratégie 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 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 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 lui-même. 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 non réactive.

Robustesse en cas de pannes zonales ou régionales

En cas de panne de zone ou de région, l'application est indisponible. Pour réduire les temps d'arrêt causés par ces 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 celle qui contient le réplica passif 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 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 ou zone 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 ou zone de basculement.
  • Si l'instance répliquée passive se trouve dans une autre région, utilisez les 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) 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é Oracle Exadata

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

Vous pouvez utiliser le service 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 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 assurer la durabilité des données dans 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 dans Oracle Exadata Database Service sur une infrastructure dédiée 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 produits Oracle que vous déployez sur Compute Engine. Vous êtes également responsable du respect des conditions d'utilisation des licences Oracle. Pour en savoir plus, consultez Licensing Oracle Software in the Cloud Computing Environment.

Licences de base de données Oracle Exadata

Lorsque vous créez un cluster de VM Exadata, vous pouvez apporter votre propre licence (BYOL) ou utiliser 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 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 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 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 de la 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 à 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.

Observabilité pour les applications Oracle

Pour implémenter 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 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 des opérations 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 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 Oracle correspondante.

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).

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

Étapes suivantes

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :