Oracle E-Business Suite avec Oracle Database sur des VM Compute Engine

Last reviewed 2025-05-27 UTC

Ce document fournit des architectures de référence pour vous aider à créer l'infrastructure permettant d'exécuter les applications Oracle E-Business Suite avec Oracle Database sur des VM Compute Engine 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 Oracle Database et la pile technologique et l'architecture Oracle E-Business Suite.

Si vous devez utiliser Oracle Exadata ou Oracle Real Application Clusters (Oracle RAC), vous pouvez migrer vos applications vers Google Cloud et exécuter vos bases de données sur Oracle Database@Google Cloud. Pour en savoir plus, consultez Oracle E-Business Suite avec Oracle Exadata dans Google Cloud.

Architecture

En fonction de votre cas d'utilisation et de vos exigences en termes de disponibilité et de reprise après sinistre (DR), vous pouvez choisir l'un des archétypes de déploiement suivants Google Cloudpour exécuter les applications Oracle E-Business Suite sur Google Cloud :

  • Zonale : vos applications s'exécutent dans une seule zone Google Cloud. Cet archétype de déploiement est bien adapté aux environnements de développement et de test, ainsi qu'aux applications non critiques qui n'ont pas besoin d'une haute disponibilité.
  • Régional : vos applications s'exécutent indépendamment dans au moins deux zones d'une même région Google Cloud. Nous recommandons cet archétype de déploiement pour les applications non critiques, mais qui doivent être robustes face aux pannes zonales.
  • Multirégional : vos applications s'exécutent indépendamment dans plusieurs zones dans au moins deux régions Google Cloud , en mode actif-actif ou actif-passif. Cet archétype de déploiement est idéal pour prendre en charge les scénarios de reprise après sinistre. Nous recommandons cet archétype pour les applications critiques qui doivent être résilientes face aux pannes et aux catastrophes régionales.

Le choix d'un archétype de déploiement permet de simplifier les décisions suivantes concernant les produits et fonctionnalités Google Cloud dont vous avez besoin pour votre architecture.

Les sections suivantes présentent quatre options d'architecture. Chaque option est basée sur l'un des archétypes de déploiement :

Architecture zonale

Le schéma suivant illustre une architecture pour les applications Oracle E-Business Suite avec Oracle Database s'exécutant dans une seule zone d'une régionGoogle Cloud . Cette architecture est conforme à l'archétype de déploiement zonal.

Une architecture pour les applications Oracle E-Business Suite s'exécute dans une seule zone d'une région Google Cloud .

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

Composant Description
É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 permet de protéger vos applications contre les menaces telles que les attaques DDoS et les 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. Chaque VM héberge une instance indépendante du niveau application. Le disque de démarrage de chaque VM est un volume Google Cloud Hyperdisk.

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 zonale Filestore contient les binaires et les données de l'application. L'instance Filestore est installée sur les VM Compute Engine qui hébergent les composants de la couche Application.
Base de données Oracle (BYOL)

Les applications Oracle E-Business Suite utilisent une instance Oracle Database déployée sur une VM Compute Engine. Les disques de démarrage et de données de la VM sont des volumes Hyperdisk.

Vous utilisez votre propre licence (BYOL) pour l'instance Oracle Database, et vous gérez la VM et la base de données.
Sauvegardes d'applications et de bases de données Les sauvegardes des données d'application et de la base de données sont créées, stockées et gérées à l'aide du service Backup and DR.
Réseau de cloud privé virtuel (VPC) et sous-réseaux

Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC. Les VM qui hébergent la couche d'application et la base de données utilisent des sous-réseaux distincts.

Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux VPC. Pour en savoir plus, consultez Décider s'il convient de créer plusieurs réseaux VPC.
Passerelle NAT publique L'architecture inclut une passerelle Cloud NAT publique pour les connexions sortantes sécurisées depuis les VM Compute Engine, qui ne possèdent que des adresses IP internes. Par exemple, les VM peuvent accéder au serveur Oracle Linux Yum pour télécharger des packages d'OS.
Cloud Interconnect et 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.

Architecture zonale avec une DMZ

Le schéma suivant illustre une architecture avec deux couches d'application Oracle E-Business Suite indépendantes s'exécutant sur des VM Compute Engine. L'une des couches d'application est une zone démilitarisée (DMZ), qui sert les utilisateurs externes des applications Oracle E-Business Suite. L'autre couche est destinée aux utilisateurs internes. Les deux couches d'application s'exécutent dans une seule zone d'une région Google Cloud et utilisent une seule instance Oracle Database. Comme l'architecture de la section précédente, celle-ci est conforme à l'archétype de déploiement zonal.

Une architecture pour les applications Oracle E-Business Suite s'exécute dans une seule zone avec une DMZ dans une région Google Cloud .

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

Composant Description
Équilibreur de charge d'application externe régional L'équilibreur de charge externe reçoit et distribue les requêtes des utilisateurs externes au niveau de l'application externe.
Équilibreur de charge d'application interne régional L'équilibreur de charge interne reçoit et distribue les requêtes des utilisateurs internes à un niveau d'application interne.
Règle de sécurité Google Cloud Armor La stratégie de sécurité Google Cloud Armor permet de protéger vos applications contre les menaces externes telles que les attaques DDoS et les scripts 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. Chaque VM héberge une instance indépendante du niveau application. Les applications internes et externes sont diffusées à partir de différents ensembles de VM. Le disque de démarrage de chaque VM est un volume Hyperdisk.

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 zonale Filestore contient les binaires et les données de l'application. L'instance Filestore est installée sur les VM Compute Engine qui hébergent les composants de la couche Application.
Base de données Oracle (BYOL)

Les applications Oracle E-Business Suite utilisent une instance Oracle Database déployée sur une VM Compute Engine. Les disques de démarrage et de données de la VM sont des volumes Hyperdisk.

Vous utilisez votre propre licence (BYOL) pour l'instance Oracle Database, et vous gérez la VM et la base de données.
Sauvegardes d'applications et de bases de données Les sauvegardes des données et de la base de données 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) et sous-réseaux

Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC. Les VM qui hébergent la couche d'application et la base de données utilisent des sous-réseaux distincts.

Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux VPC. Pour en savoir plus, consultez Décider s'il convient de créer plusieurs réseaux VPC.
Passerelle NAT publique L'architecture inclut une passerelle Cloud NAT publique pour les connexions sortantes sécurisées à partir des VM Compute Engine, qui ne possèdent que des adresses IP internes. Par exemple, les VM peuvent accéder au serveur Oracle Linux Yum pour télécharger des packages d'OS.
Cloud Interconnect et Cloud VPN Pour connecter votre réseau sur site au réseau VPC dansGoogle Cloud, vous pouvez utiliser Cloud Interconnect ou Cloud VPN. Les administrateurs et les utilisateurs d'applications internes utilisent ces connexions pour accéder respectivement aux ressources et aux applications. Pour en savoir plus sur les avantages relatifs de chaque approche, consultez Choisir un produit de connectivité réseau.

Architecture régionale

Le schéma suivant présente 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 région Google Cloud . Les deux déploiements d'applications utilisent une instance Oracle Database principale qui s'exécute sur une VM dans l'une des zones. Oracle Data Guard gère la réplication et le basculement de la base de données vers une instance Oracle Database de secours dans la deuxième zone. Cette architecture est basée sur l'archétype de déploiement régional.

Une architecture pour les applications Oracle E-Business Suite s'exécute dans deux zones d'une région Google Cloud .

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

Composant Description
É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 permet de protéger vos applications contre les menaces telles que les attaques DDoS distribuées et les scripts 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. Chaque VM héberge une instance indépendante du niveau Application. Le disque de démarrage de chaque VM est un volume Hyperdisk.

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.
Base de données Oracle (BYOL)

Les applications Oracle E-Business Suite utilisent une paire primaire-standby d'instances Oracle Database déployées sur des VM Compute Engine dans des zones distinctes. Les disques de démarrage et de données de la VM sont des volumes Hyperdisk.

Oracle Data Guard gère la réplication et le basculement de la base de données de l'instance principale vers l'instance de secours.

Vous utilisez vos propres licences (BYOL) pour les instances Oracle Database, et vous gérez les VM et les bases de données.
Sauvegardes d'applications et de bases de données Les sauvegardes des données et de la base de données 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) et sous-réseaux

Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC. Les VM qui hébergent la couche d'application et la base de données utilisent des sous-réseaux distincts.

Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux VPC. Pour en savoir plus, consultez Décider s'il convient de créer plusieurs réseaux VPC.
Passerelle NAT publique L'architecture inclut une passerelle Cloud NAT publique pour les connexions sortantes sécurisées à partir des VM Compute Engine, qui ne possèdent que des adresses IP internes. Par exemple, les VM peuvent accéder au serveur Oracle Linux Yum pour télécharger des packages d'OS.
Cloud Interconnect et 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.

Architecture multirégionale actif-passif (reprise après sinistre)

Le schéma suivant présente 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 région Google Cloud . Les deux déploiements d'applications utilisent une instance Oracle Database principale qui s'exécute sur une VM dans l'une des zones. Oracle Data Guard gère la réplication et le basculement de la base de données vers une instance Oracle Database de secours dans la deuxième zone. L'architecture inclut une réplique à plus petite échelle de la pile d'applications dans une région distante (de basculement) pour la reprise après sinistre. Comme l'architecture de la section précédente, celle-ci est basée sur l'archétype de déploiement régional.

Une architecture pour les applications Oracle E-Business Suite s'exécute dans deux zones d'une région Google Cloud , avec un réplica dans une région distante pour la reprise après sinistre.

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

Composant Description
Règle de routage avec basculement DNS Une zone publique Cloud DNS configurée avec une règle de routage de basculement achemine les requêtes des utilisateurs vers l'équilibreur de charge de la région qui traite actuellement les requêtes.
É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 permet de protéger vos applications contre les menaces telles que les attaques DDoS distribuées et les scripts 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.

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 dans la région principale 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 de la région principale. L'instance Filestore est répliquée dans la région de basculement.
Base de données Oracle (BYOL)

Les applications Oracle E-Business Suite utilisent une paire primaire-standby d'instances Oracle Database déployées sur des VM Compute Engine dans des zones distinctes de la région primaire. Les disques de démarrage et de données de la VM sont des volumes Hyperdisk.

Oracle Data Guard gère la réplication et le basculement de la base de données de l'instance principale vers l'instance de secours.

Vous utilisez vos propres licences (BYOL) pour les instances Oracle Database, et vous gérez les VM et les bases de données.
Sauvegardes d'applications et de bases de données Les sauvegardes des données d'application et de la base de données sont créées, stockées et gérées à l'aide de Backup and DR.
Réseau de cloud privé virtuel (VPC) et sous-réseaux

Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC. Les VM qui hébergent la couche d'application et la base de données utilisent des sous-réseaux régionaux distincts.

Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux VPC. Pour en savoir plus, consultez Décider s'il convient de créer plusieurs réseaux VPC.
Passerelle NAT publique L'architecture inclut une passerelle Cloud NAT publique dans chaque région pour les connexions sortantes sécurisées à partir des VM Compute Engine, qui ne possèdent que des adresses IP internes. Par exemple, les VM peuvent accéder au serveur Oracle Linux Yum pour télécharger des packages d'OS.
Cloud Interconnect et 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.

Produits utilisés

Ces architectures de référence utilisent 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.
  • 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.
  • 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 Interconnect : service qui étend votre réseau externe au réseau Google via une connexion à haute disponibilité et à faible latence.
  • 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.

Ces architectures de référence utilisent 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.
  • Oracle Database : système de gestion de base de données relationnelle (SGBDR) qui étend le modèle relationnel à un modèle relationnel-objet.
  • Oracle Data Guard : ensemble de services permettant de créer, de gérer et de surveiller une ou plusieurs bases de données de secours.

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 ces architectures de référence pour développer une topologie qui répond à vos exigences spécifiques en termes de sécurité, de fiabilité, d'efficacité opérationnelle, de coût et de performances.

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 déploiements Oracle Database sur site versGoogle 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 vers des déploiements de bases de données Oracle dansGoogle Cloud, vous pouvez utiliser des outils Oracle standards tels qu'Oracle GoldenGate.

Options de stockage

Les architectures présentées dans ce document utilisent des volumes Hyperdisk pour les disques de démarrage de toutes les VM Compute Engine et pour les disques de données des VM qui hébergent des instances Oracle Database. Les volumes Hyperdisk offrent de meilleures performances, une plus grande flexibilité et une efficacité accrue par rapport aux disques persistants. Pour en savoir plus sur les types et les fonctionnalités d'Hyperdisk, consultez À propos d'Hyperdisk.

Pour les données et les binaires d'application, toutes les architectures de ce document utilisent Filestore. Les données que vous stockez dans une instance régionale Filestore 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. Les architectures présentées dans ce document utilisent une topologie de réseau simple 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 effectuer des analyses avancées, vous pouvez utiliser Google Cloud Cortex Framework afin d'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 ces architectures 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.

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 de disque

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.

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.

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 ces architectures de référence pour créer et exploiter une infrastructure fiable pour votre déploiement dans Google Cloud.

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

Avec toutes les options d'architecture de ce document, si certaines (mais pas toutes) des VM d'application é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 de la base de données face aux défaillances de VM

Dans une architecture zonale, si la VM de base de données échoue, vous pouvez restaurer la base de données en production sur une nouvelle VM à l'aide des sauvegardes stockées dans Backup and DR. Une fois la base de données restaurée, vous devez connecter les applications à la nouvelle instance de base de données.

Si la cohérence des données est une priorité, configurez une instance de base de données principale et une instance de base de données de secours, de préférence sur des VM situées dans des zones différentes, comme indiqué dans l'architecture régionale. Pour la réplication et le basculement vers l'instance de base de données de secours, utilisez Data Guard. Data Guard contribue à assurer la cohérence en répliquant les transactions sur l'instance de secours avant de les confirmer sur l'instance principale. L'architecture de base de données principale-de secours entraîne des coûts supplémentaires pour l'infrastructure et les licences.

Dans une architecture régionale ou multirégionale, si la VM qui héberge la base de données principale échoue, Oracle Data Guard lance un basculement vers l'instance de base de données Oracle de secours. Pendant le processus de basculement, les applications ne peuvent pas accéder à la base de données.

Robustesse en cas de pannes zonales

Dans une architecture zonale, si la zone qui héberge votre déploiement est en panne, les applications et la base de données sont hors service. Vous pouvez restaurer les applications et la base de données en production dans une autre zone ou région à l'aide des sauvegardes stockées dans Backup and DR.

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 Régional.

Pour assurer 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 équilibré à 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 et la base de données ne sont pas disponibles. Vous pouvez restaurer les applications et la base de données en production dans une autre région à l'aide des sauvegardes stockées dans Backup and DR. Pour réduire le temps d'arrêt, utilisez l'architecture multirégionale active-passive (DR). Une fois les applications et la base de données opérationnelles, vous devez mettre à jour la règle de routage DNS pour acheminer le trafic vers l'équilibreur de charge dans la région de basculement.

Pour les applications critiques qui ne peuvent pas tolérer de temps d'arrêt, même en cas de panne régionale, utilisez l'archétype de déploiement multirégional actif/actif.

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.

Durabilité des données

Les architectures décrites dans ce document utilisent 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 :

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 ces architectures 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. 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.

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 ces architectures 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.

Connectivité entre le serveur d'application et la base de données

Pour les connexions de vos applications à Oracle Database, nous vous recommandons d'utiliser le nom DNS interne zonal de la VM de base de données plutôt que son adresse IP. Google Cloud résout automatiquement le nom DNS en adresse IP interne principale de la VM. Un autre avantage de cette approche est que vous n'avez pas besoin de réserver ni d'attribuer d'adresses IP internes statiques pour les VM de base de données.

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 ces architectures 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, que vous pouvez choisir en fonction des exigences de performances de vos charges de travail.

  • Pour les VM qui hébergent les applications et la base de données, choisissez un type de machine approprié en fonction de vos exigences en termes de performances. Pour obtenir la liste des types de machines disponibles compatibles avec les volumes Hyperdisk et qui répondent à vos exigences de performances et autres, consultez le tableau Comparaison des séries de machines.
  • Pour la VM qui héberge les instances Oracle Database, nous vous recommandons d'utiliser un type de machine de la série de machines C4 de la famille de machines à usage général. Les types de machines C4 offrent des performances élevées et constantes pour les charges de travail de base de données.

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.

Performances de stockage Hyperdisk

Les architectures décrites dans ce document utilisent des volumes Hyperdisk pour tous les disques de démarrage des VM et pour les disques de données de la VM de base de données. 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 l'optimisation 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 :