Application d'entreprise sur des VM Compute Engine avec Oracle Exadata dans Google Cloud

Last reviewed 2024-09-30 UTC

Ce document fournit une architecture de référence pour une application professionnelle disponibilité élevée hébergée sur des machines virtuelles (VM) Compute Engine avec une connectivité à faible latence aux bases de données Exadata d'Oracle Cloud Infrastructure (OCI) qui s'exécutent dans Google Cloud. Ce document s'adresse aux architectes cloud et aux administrateurs de bases de données Oracle. Dans ce document, nous partons du principe que vous connaissez Compute Engine et le service de base de données Oracle Exadata.

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

Si vous n'avez pas besoin de la fonctionnalité Oracle RAC ou si vous avez besoin d'une version de base de données Oracle autre que 19c et 23ai, vous pouvez exécuter des bases de données Oracle autogérées sur des VM Compute Engine. Pour en savoir plus, consultez la page Application d'entreprise avec Oracle Database sur Compute Engine.

Architecture

Le diagramme suivant présente une vue d'ensemble de l'architecture:

Vue d'ensemble d'une architecture qui utilise Oracle Database@Google Cloud.

Dans le diagramme précédent, un équilibreur de charge externe reçoit les requêtes des utilisateurs d'une application publique et les distribue aux serveurs Web de premier plan. Les serveurs Web transfèrent les requêtes des utilisateurs via un équilibreur de charge interne aux serveurs d'applications. Les serveurs d'applications lisent et écrivent des données dans les bases de données d'Oracle Database@Google Cloud. Les administrateurs et les services OCI peuvent se connecter et interagir avec les bases de données Oracle.

Le diagramme suivant présente une vue détaillée de l'architecture :

Vue détaillée d'une architecture qui utilise Oracle Database@Google Cloud

Dans cette architecture, le niveau Web et le niveau application s'exécutent en mode actif-actif sur des VM Compute Engine réparties sur deux zones d'une région Google Cloud. L'application utilise des bases de données Oracle Exadata dans la même région Google Cloud.

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

L'architecture présentée dans le schéma précédent comprend les composants suivants:

Composant Objectif
Équilibreur de charge d'application externe régional L'équilibreur de charge d'application externe régional reçoit les requêtes des utilisateurs et les distribue aux VM du niveau Web.
Règles de sécurité Google Cloud Armor La stratégie de sécurité Google Cloud Armor 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).
Groupe d'instances géré (MIG) régional pour le niveau Web Le niveau Web de l'application est déployé sur des VM Compute Engine qui font partie d'un MIG régional. Ce MIG est le backend de l'équilibreur de charge d'application externe. Le MIG contient des VM Compute Engine dans deux zones. Chacune de ces VM héberge une instance indépendante du niveau Web de l'application.
Équilibreur de charge d'application interne régional L'équilibreur de charge d'application interne régional répartit le trafic des VM du niveau Web vers les VM du niveau application.
MIG régional pour le niveau application Le niveau application, tel qu'un cluster Oracle WebLogic Server, est déployé sur des VM Compute Engine qui font partie d'un MIG régional. Ce MIG est le backend de l'équilibreur de charge d'application interne. Le MIG contient des VM Compute Engine dans deux zones. Chaque VM héberge une instance indépendante du serveur d'applications.
Réseau cloud privé virtuel (VPC) et sous-réseau Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC. Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux. Pour en savoir plus, consultez la section Choisir de créer ou non plusieurs réseaux VPC.
Oracle Database@Google Cloud

Les serveurs d'applications lisent et écrivent des données dans les bases de données Oracle dans 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 telles que 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.

Instances d'infrastructure Exadata Chaque instance d'infrastructure Exadata contient au moins deux serveurs de base de données physiques et trois serveurs de stockage. Ces serveurs, qui ne sont pas représentés dans le diagramme, sont interconnectés à l'aide d'un tissu réseau à faible latence. Lorsque vous créez une 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 une instance d'infrastructure Exadata, vous créez un ou plusieurs clusters de VM Exadata. Par exemple, vous pouvez choisir de créer et d'utiliser un cluster de VM Exadata distinct pour héberger les bases de données requises pour chacune de vos unités commerciales. Chaque cluster de VM Exadata contient une ou plusieurs VM Oracle Linux qui hébergent des instances de base de données Oracle.

Lorsque vous créez un cluster de VM Exadata, vous devez spécifier 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 des sous-réseaux 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 bases de données Oracle via la console 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. Vous choisissez également le type de licence: BYOL (Bring Your Own License) ou 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 secours avec des plages d'adresses IP que vous spécifiez. Le sous-réseau client est utilisé pour la connectivité de votre réseau VPC aux bases de données Oracle. Le sous-réseau de sauvegarde permet d'envoyer des sauvegardes de base de données à Object Storage OCI.
Cloud Router, Partner Interconnect et DRG OCI Le trafic entre votre réseau VPC et le VCN est acheminé par Cloud Router associé au VPC et via une passerelle de routage dynamique (DRG) associée au VCN. Le trafic transite via une connexion à faible latence que Google configure à l'aide de interconnexion partenaire.
Zone privée Cloud DNS Lorsque vous créez un cluster de VM Exadata, une zone DNS privée Cloud est créée automatiquement. Lorsque vos serveurs d'application envoient des requêtes de lecture et d'écriture aux bases de données Oracle, Cloud DNS résout les noms d'hôte des bases de données en adresses IP correspondantes.
Stockage d'objets OCI 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 Object Storage OCI via une passerelle de service.
Passerelle Cloud NAT publique L'architecture comprend une passerelle Cloud NAT publique pour permettre des connexions sortantes sécurisées à partir des VM Compute Engine, qui ne disposent que d'adresses IP internes.
Cloud Interconnect et 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 chacune de ces deux options, consultez la section 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 de surveillance OCI.

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.
  • 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é.
  • Google Cloud Armor: service de sécurité réseau qui propose des règles de pare-feu d'application Web (WAF) et aide à protéger contre les attaques DDoS et d'applications.
  • Cloud NAT: service qui fournit une traduction d'adresses réseau hautes performances gérée par Google Cloud.
  • Cloud Monitoring : service qui offre une visibilité sur les performances, la disponibilité et l'état de vos applications et de votre infrastructure.
  • Cloud Interconnect: service qui étend votre réseau externe au réseau Google via une connexion à haute disponibilité et à faible latence.
  • Partner Interconnect: service qui fournit une connectivité entre votre réseau sur site et vos réseaux cloud privé virtuel (VPC) et 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.

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

  • Exadata Database Service sur une infrastructure dédiée: service qui vous permet d'exécuter des instances Oracle Database sur du matériel Exadata qui vous est dédié.
  • Stockage d'objets: service permettant de stocker de grandes quantités de données structurées et non structurées sous forme d'objets.
  • VCN et sous-réseaux: un VCN est un réseau virtuel et privé pour les ressources d'une région OCI. Un sous-réseau est une plage contiguë d'adresses IP associée à un VCN.
  • Passerelle de routage dynamique: routeur virtuel pour le trafic entre un VCN et des réseaux externes.
  • Service Gateway: passerelle permettant aux ressources d'un VCN d'accéder de manière privée à des services Oracle spécifiques.

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.

Les conseils de cette section ne sont pas exhaustifs. En fonction des exigences spécifiques de votre application et des produits et fonctionnalités Google Cloud et tiers que vous utilisez, il peut y avoir d'autres facteurs de conception et compromis à prendre en compte.

Conception du système

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

Sélection de la région

Lorsque vous choisissez la région Google Cloud pour votre déploiement, 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.
  • Disponibilité d'Oracle Database@Google Cloud dans chaque région. Pour en savoir plus, consultez la section Configurations disponibles.
  • Exigences relatives à la latence tolérée par l'utilisateur final.
  • Coût des ressources Google Cloud.
  • 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 la section 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 héberger le niveau Web et le niveau application. Selon les exigences de votre application, vous pouvez choisir parmi les autres services de calcul Google Cloud suivants:

  • Containers: 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 et Cloud Run Functions.

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é et de contrôle de la 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. Les conseils de conception pour ces services n'entrent pas dans le cadre de ce document. Pour en savoir plus sur les options de service, consultez la page Héberger des applications sur Google Cloud.

Options de stockage

Pour fournir un stockage persistant aux VM Compute Engine dans les niveaux Web et d'application, choisissez un type de disque persistant ou d'Google Cloud Hyperdisk approprié en fonction des exigences de votre application en termes de capacité, d'évolutivité, de disponibilité et de performances. Pour en savoir plus, consultez la page Options de stockage.

Si vous avez besoin d'un stockage à faible coût redondant entre les zones d'une région, utilisez les buckets Cloud Storage régionaux.

Pour stocker des données partagées sur plusieurs VM d'une région, comme les fichiers de configuration de toutes les VM du niveau Web, vous pouvez utiliser une instance Filestore régionale. Les données que vous stockez dans une instance Filestore Regional sont répliquées 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 les données que vous stockez dans Filestore. Vous pouvez 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 multicouche, vous devez choisir une conception de réseau qui répond à vos exigences commerciales et techniques. L'architecture présentée dans ce document utilise une topologie réseau simple avec un seul réseau VPC. Selon vos besoins, vous pouvez choisir d'utiliser plusieurs réseaux. Pour en savoir plus, consultez la documentation suivante :

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

Migration de bases de données

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

Pour migrer des données sur site vers des déploiements de bases de données Oracle dans Google Cloud, vous pouvez utiliser des outils Oracle standards tels que Oracle GoldenGate.

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.

Sécurité

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 externes telles que les attaques DDoS et les scripts XSS, définissez des stratégies de sécurité Google Cloud Armor appropriées en fonction de vos exigences. Chaque stratégie est un ensemble de règles qui spécifie les conditions à évaluer 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 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 hébergeant le niveau Web et le niveau application n'ont pas besoin d'un accès entrant direct depuis Internet. N'attribuez pas d'adresses IP externes à ces VM. Les ressources Google Cloud ne disposant que d'adresses IP internes privées 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 Cloud NAT comme indiqué dans le diagramme d'architecture précédent, ou le proxy Web sécurisé.

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

Sécurité des images de VM

Les images approuvées sont celles qui contiennent un logiciel conforme à vos règles ou exigences de sécurité. Pour vous assurer que vos VM du niveau Web et du niveau application n'utilisent que des images approuvées, vous pouvez définir une règle d'administration limitant l'utilisation d'images dans des projets d'images publiques spécifiques. Pour en savoir plus, consultez la page Configurer des règlements relatifs aux images de confiance.

Droits des comptes de service

Dans les projets Google Cloud pour lesquels l'API Compute Engine est activée, un compte de service par défaut est créé automatiquement. Pour les organisations Google Cloud créées avant le 3 mai 2024, ce compte de service par défaut se voit attribuer le rôle IAM Éditeur (roles/editor), sauf si ce comportement est désactivé.

Par défaut, le compte de service par défaut est associé à toutes les VM Compute Engine que vous créez à l'aide de gcloud CLI ou de la console Google Cloud. Le rôle Éditeur inclut un large éventail d'autorisations. L'association du compte de service par défaut aux VM crée donc un risque de sécurité. Pour éviter ce risque, vous pouvez créer et utiliser des comptes de service dédiés pour chaque niveau de la pile d'applications. Pour spécifier les ressources auxquelles le compte de service peut accéder, utilisez des stratégies précises. Pour en savoir plus, consultez la section Limiter les droits des comptes de service.

Sécurité du réseau

Pour contrôler le trafic réseau entre les ressources de la couche Web et de la couche application de l'architecture, vous devez configurer des règles Cloud Next Generation Firewall (NGFW) appropriées.

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

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

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 dans Google Cloud.

Robustesse face aux défaillances de la VM

Dans l'architecture présentée dans ce document, si une VM Compute Engine du niveau Web ou du niveau application plante, le MIG correspondant recrée automatiquement la VM. Les équilibreurs de charge ne transfèrent les requêtes que vers les instances de serveur Web et de serveur d'applications actuellement disponibles.

Autoréparation de VM

Parfois, les VM qui hébergent votre niveau Web et votre niveau d'application sont en cours d'exécution et disponibles, 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, les VM ne répondent pas aux vérifications de l'état de l'équilibreur de charge, et l'équilibreur de charge n'achemine pas le trafic vers les VM qui ne répondent pas. Pour vous assurer que les applications répondent comme prévu, vous pouvez configurer des vérifications d'état basées sur l'application dans le cadre de la règle d'autoréparation de vos MIG. Si l'application sur une VM particulière ne répond pas, le MIG répare automatiquement la VM. Pour en savoir plus sur la configuration de l'autoréparation, consultez la section À propos de la réparation des VM pour la haute disponibilité.

Robustesse face aux pannes régionales

En cas de panne régionale, l'application est indisponible. Pour réduire le temps d'arrêt causé par les pannes régionales, vous pouvez implémenter l'approche suivante:

  • Gérer une instance répliquée passive (de basculement) de la couche Web et de la couche application dans une autre région Google Cloud
  • Créez une instance d'infrastructure Exadata de secours avec les clusters de VM Exadata requis dans la même région que le réplicat passif de la pile d'applications. Utilisez Oracle Data Guard pour la réplication de 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 du service de récupération autonome Oracle.
  • En cas de panne dans la région principale, utilisez le réplica de la base de données ou la sauvegarde pour restaurer la base de données en production et activer l'application dans la région de basculement.
  • Utilisez des règles de routage DNS pour acheminer le trafic vers un équilibreur de charge externe dans la région de basculement.

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

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

Autoscaling des MIG

L'architecture décrite dans ce document utilise des MIG régionaux pour les niveaux Web et application. La fonctionnalité d'autoscaling des MIG sans état garantit que les VM Compute Engine qui hébergent le niveau Web et le niveau d'application ne sont pas affectés par les pannes d'une seule zone. Les MIG avec état ne peuvent pas faire l'objet d'un autoscaling.

Pour contrôler le comportement d'autoscaling de vos MIG, vous pouvez spécifier des métriques d'utilisation cibles, telles que l'utilisation moyenne du CPU. Vous pouvez également configurer l'autoscaling basé sur des planifications. Pour en savoir plus, consultez la page Effectuer l'autoscaling des groupes d'instances.

Emplacement de la VM

Dans l'architecture décrite dans ce document, le niveau Application et le niveau Web s'exécutent sur des VM Compute Engine réparties sur plusieurs zones. Cette répartition permet de s'assurer que votre niveau Web et votre niveau d'application sont résistants aux pannes d'une seule zone. Pour améliorer davantage sa robustesse, vous pouvez créer une stratégie d'emplacement par répartition et l'appliquer au modèle de MIG. Avec une stratégie d'emplacement par répartition, lorsque le MIG crée des VM, il les place dans chaque zone sur des serveurs physiques distincts (appelés hôtes) afin qu'elles résistent aux défaillances des hôtes individuels. Toutefois, cette approche présente un inconvénient : la latence du trafic réseau inter-VM peut augmenter. Pour en savoir plus, consultez la section Présentation des règles d'emplacement.

Planification de la capacité des VM

Pour vous assurer que la capacité des VM Compute Engine est disponible en cas de besoin pour l'autoscaling des MIG, 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. Des frais vous sont facturés pour les ressources réservées, même si elles ne sont pas provisionnées ou utilisées. Pour en savoir plus sur les réservations, y compris la facturation, consultez la section Réservations de ressources zonales Compute Engine.

Stockage avec état

Une bonne pratique de conception d'application consiste à éviter d'avoir à utiliser des disques locaux avec état. Toutefois, si l'exigence existe, vous pouvez configurer vos disques pour qu'ils soient à état afin de vous assurer que les données sont conservées lors de la réparation ou de la recréation des VM. Cependant, nous vous recommandons de garder les disques de démarrage sans état, afin de pouvoir les mettre à jour facilement vers les dernières images comportant les nouvelles versions et les correctifs de sécurité. Pour en savoir plus, consultez la page Configurer des disques persistants avec état dans les groupes d'instances gérés.

Capacité de la base de données

Vous pouvez faire évoluer l'infrastructure Exadata en ajoutant des serveurs de base de données et des serveurs de stockage selon vos besoins. Une fois que vous avez 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 la page Évoluer les ressources de calcul et de stockage Exadata.

Sauvegarde et récupération

Vous pouvez utiliser le service de sauvegarde et de reprise après sinistre pour créer, stocker et gérer des sauvegardes des VM Compute Engine. Le service Backup and DR stocke les données de 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 perdre du temps à déplacer les données ni à les préparer. Pour en savoir plus, consultez Service Backup and DR pour les sauvegardes d'instances Compute Engine.

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 du service 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 de vos 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 vos VM de niveau Web et de niveau application. 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.

Modèle de provisionnement de VM

Si votre application est tolérante aux pannes, les VM Spot peuvent vous aider à réduire les coûts Compute Engine pour vos VM des niveaux Web et application. Le coût des VM Spot est nettement inférieur à celui des VM standards. Toutefois, Compute Engine peut arrêter ou supprimer les VM Spot de manière préemptive pour récupérer de la capacité.

Les VM Spot conviennent aux tâches par lots pouvant tolérer la préemption et ne nécessitant pas de haute disponibilité. Les VM Spot offrent les mêmes types de machines, options et performances que les VM standards. Toutefois, lorsque la capacité des ressources d'une zone est limitée, les MIG risquent de ne pas pouvoir mener effectuer un scaling horizontal (c'est-à-dire créer des VM) automatique jusqu'à la taille cible spécifiée tant que la capacité requise n'est pas disponible.

Utilisation des ressources de VM

La fonctionnalité d'autoscaling des MIG sans état permet à votre application de gérer de manière fluide les augmentations de trafic vers le niveau Web et le niveau application. L'autoscaling vous permet également de réduire les coûts lorsque les besoins en ressources sont faibles. Les MIG avec état ne peuvent pas faire l'objet d'un autoscaling.

Coûts de la base de données

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

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

Autres considérations sur les coûts

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales fournies dans la section Framework d'architecture Google Cloud : 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.

Mises à jour de la configuration des VM

Pour mettre à jour la configuration des VM d'un MIG (par exemple, le type de machine ou l'image du disque de démarrage), vous devez créer un modèle d'instance avec la configuration requise, puis appliquer le nouveau modèle au MIG. Le MIG met à jour les VM à l'aide de la méthode de mise à jour que vous spécifiez: automatique ou sélective. Choisissez une méthode appropriée en fonction de vos exigences en termes de disponibilité et d'efficacité opérationnelle. Pour en savoir plus sur ces méthodes de mise à jour de MIG, consultez la section Appliquer de nouvelles configurations de VM dans un MIG.

Images de VM

Pour vos modèles d'instances de MIG, au lieu d'utiliser des images publiques fournies par Google, nous vous recommandons de créer et d'utiliser des images de système d'exploitation personnalisées qui incluent les configurations et les 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 de sécurité et les correctifs fournis par le fournisseur de l'OS.

Modèles d'instances déterministes

Si les modèles d'instance que vous utilisez pour vos MIG incluent des scripts de démarrage (par exemple, pour installer des logiciels tiers), assurez-vous qu'ils spécifient explicitement les paramètres d'installation des logiciels, tels que la version. Dans le cas contraire, lorsque le MIG crée les VM, le logiciel installé sur les VM risque de ne pas être cohérent. Par exemple, si votre modèle d'instance inclut un script de démarrage qui installe Apache HTTP Server 2.0 (le package apache2), assurez-vous que le script spécifie exactement la version de apache2 qui doit être installée, par exemple la version 2.4.53. Pour en savoir plus, consultez la page Modèles d'instances déterministes.

Administration des bases de données

Oracle gère les serveurs de base de données physiques, les serveurs de stockage et le matériel de mise en réseau dans Oracle Exadata Database Service sur une infrastructure dédiée. Vous pouvez gérer les instances Exadata Infrastructure 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 pertinentes de la console OCI. Pour éviter de devoir vous reconnecter à OCI, vous pouvez configurer la fédération d'identité entre OCI et Google Cloud.

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 Framework d'architecture Google Cloud : 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, que vous pouvez choisir en fonction des exigences de performances de vos charges de travail. Pour les VM qui hébergent le niveau Web et le niveau d'application, choisissez un type de machine approprié en fonction de vos exigences en termes de performances pour ces niveaux. Pour en savoir plus, consultez la Comparaison des séries de machines.

Performances du réseau

Pour les charges de travail nécessitant une faible latence réseau entre les VM au niveau des niveaux d'application et Web, vous pouvez créer une règle d'emplacement compact et l'appliquer au modèle de MIG utilisé pour ces niveaux. Lorsque le MIG crée des VM, il les place sur des serveurs physiques proches les uns des autres. Alors qu'une stratégie d'emplacement compact permet d'améliorer les performances réseau entre les VM, une stratégie d'emplacement par répartition peut contribuer à améliorer la disponibilité des VM, comme décrit précédemment. Pour obtenir un équilibre optimal entre les performances et la disponibilité du réseau, lorsque vous créez une stratégie d'emplacement compact, vous pouvez spécifier la distance à laquelle les VM doivent être placées. Pour en savoir plus, consultez la section Présentation des règles d'emplacement.

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é 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 la section Configurer les performances réseau Tier_1 par VM.

Le trafic réseau entre les VM de niveau application et le réseau Oracle Exadata est acheminé via une connexion interconnexion partenaire à faible latence que Google configure.

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

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 Framework d'architecture Google Cloud : optimisation des performances.

Étape suivante

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :