Application d'entreprise avec Oracle Database sur Compute Engine

Last reviewed 2024-09-02 UTC

Ce document fournit une architecture de référence pour vous aider à créer l'infrastructure permettant d'héberger une application d'entreprise disponibilité élevée qui utilise une base de données Oracle, avec l'ensemble de la pile déployée sur des VM Compute Engine. Vous pouvez utiliser cette architecture de référence pour réhéberger (migration Lift and Shift) efficacement des applications sur site qui utilisent des bases de données Oracle vers Google Cloud. Ce document inclut également des conseils pour vous aider à créer une topologie de base de données Oracle dans Google Cloud qui répond aux exigences de l'architecture de disponibilité maximale (MAA, Maximum Availability Architecture) d'Oracle. Ce document s'adresse aux architectes cloud et aux administrateurs de bases de données Oracle. Ce document part du principe que vous connaissez Compute Engine et Oracle Database.

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. Pour en savoir plus, consultez Application d'entreprise sur des VM Compute Engine avec Oracle Exadata dans Google Cloud.

Architecture

Le schéma suivant illustre l'infrastructure d'une application d'entreprise multicouche qui utilise Oracle Database. Le niveau Web, le niveau d'application et les instances de base de données Oracle sont hébergés sur des VM Compute Engine. Le niveau Web et le niveau application s'exécutent en mode actif-actif sur des VM réparties sur deux zones d'une région Google Cloud. Les instances de base de données principale et de secours sont déployées dans des zones distinctes. Cette architecture est conforme à l'archétype de déploiement régional, ce qui garantit que votre topologie Google Cloud résiste aux pannes d'une seule zone.

Une application d'entreprise multicouche utilise Oracle Database sur des VM Compute Engine.

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 et distribue les requêtes des utilisateurs 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.
Instances Oracle Database déployées sur des VM Compute Engine L'application de cette architecture utilise une paire primaire/de secours d'instances Oracle Database déployées sur des VM Compute Engine dans des zones distinctes. Vous apportez vos propres licences (modèle BYOL) pour ces instances de base de données Oracle, et vous gérez les VM et les instances de base de données.
Pools de stockage Hyperdisk Les VM de chaque zone (pour tous les niveaux de la pile d'applications) utilisent des volumes Hyperdisk Balanced à partir d'un pool de stockage Hyperdisk. En créant et en gérant tous les disques dans un seul pool de stockage, vous améliorez l'utilisation de la capacité et réduisez la complexité opérationnelle, tout en conservant la capacité de stockage et les performances dont les VM ont besoin.
Observateur Oracle Data Guard FSFO L'observateur de basculement rapide (FSFO, Fast-Start Failover) d'Oracle Data Guard est un programme léger qui déclenche un basculement automatique vers l'instance de base de données Oracle de secours lorsque l'instance principale est indisponible. L'observateur s'exécute sur une VM Compute Engine dans une zone différente de celles où les instances de base de données principales et de secours sont déployées.
Bucket Cloud Storage Pour stocker les sauvegardes des instances de base de données Oracle, cette architecture utilise un bucket Cloud Storage. Pour faciliter la récupération de la base de données en cas de panne dans une région, vous pouvez stocker les sauvegardes de manière géoredondante dans un bucket birégional ou multirégional.
Réseau cloud privé virtuel (VPC) et sous-réseau Toutes les ressources Google Cloud de l'architecture utilisent un seul réseau VPC et un seul sous-réseau. Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux VPC ou plusieurs sous-réseaux. Pour en savoir plus, consultez la section Choisir de créer ou non plusieurs réseaux VPC.
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 et Cloud Logging Cloud Monitoring vous aide à observer le comportement, l'état et les performances de votre application et de vos ressources Google Cloud. L'agent Ops collecte les métriques et les journaux des VM Compute Engine, y compris les VM qui hébergent les instances de base de données Oracle. L'agent envoie des journaux à Cloud Logging et des métriques à Cloud 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.
  • Google Cloud Hyperdisk: service de stockage réseau que vous pouvez utiliser pour provisionner et faire évoluer de manière dynamique des volumes de stockage de blocs avec des performances configurables et prévisibles.
  • Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
  • Cloud Storage : magasin d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis et en dehors de Google Cloud, et sont répliquées sur plusieurs emplacements à des fins de redondance.
  • 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 Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.
  • 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.

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

  • 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, de surveiller et de maintenir 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 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.
  • 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 tous les niveaux de l'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.

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 Options d'hébergement d'applications.

Options de stockage

L'architecture présentée dans ce document utilise un pool de stockage Hyperdisk dans chaque zone, avec des volumes Hyperdisk Balanced pour les VM de tous les niveaux. Les volumes Hyperdisk offrent de meilleures performances, une plus grande flexibilité et une plus grande efficacité que les disques persistants. Pour en savoir plus sur les types et les fonctionnalités d'Hyperdisk, consultez la page À propos d'Hyperdisk.

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 régionale Filestore. Les données que vous stockez dans une instance Filestore régionale sont répliquées de manière synchrone sur trois zones de la région. Cette réplication garantit la haute disponibilité et la robustesse en cas de pannes zonales. Vous pouvez 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 et un seul sous-réseau VPC. Selon vos besoins, vous pouvez choisir d'utiliser plusieurs réseaux VPC ou plusieurs sous-réseaux. Pour en savoir plus, consultez la documentation suivante:

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 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 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 hébergeant le niveau Web, le niveau Application et les instances Oracle Database 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 le proxy Web sécurisé ou Cloud NAT.

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 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 que vous créez à l'aide de Google Cloud 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.

Chiffrement de disque

Par défaut, les données stockées dans les volumes Hyperdisk sont chiffrées à l'aide de clés appartenant à Google et gérées par Google. Pour renforcer la sécurité, vous pouvez choisir de chiffrer les clés de chiffrement de données appartenant à Google à 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 la page À propos du chiffrement des disques.

Sécurité du réseau

Pour contrôler le trafic réseau entre les ressources de l'architecture, vous devez configurer des règles Cloud Next Generation Firewall (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.

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 de l'un des niveaux échoue, l'application peut continuer à traiter les requêtes.

  • Si une VM 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.
  • Si la VM qui héberge l'instance de base de données Oracle principale échoue, l'observateur FSFO Oracle Data Guard déclenche un basculement automatique vers l'instance de base de données Oracle de secours.

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 zonales

En cas de panne zonale, l'application reste disponible.

  • Le niveau Web et le niveau d'application sont disponibles (et réactifs), car les VM se trouvent dans des MIG régionaux. Les MIG régionaux s'assurent que de nouvelles VM sont créées automatiquement dans l'autre zone pour conserver le nombre minimal de VM configuré. Les équilibreurs de charge transfèrent les requêtes vers les VM de serveur Web et de serveur d'applications disponibles.
  • Si une panne affecte la zone contenant l'instance de base de données Oracle principale, l'observateur FSFO Oracle Data Guard déclenche un basculement automatique vers l'instance de base de données Oracle de secours. L'observateur FSFO s'exécute sur une VM dans une zone différente de celles qui contiennent les instances de base de données principale et de secours.
  • Pour garantir la haute disponibilité des données dans les volumes Hyperdisk en cas de panne d'une seule zone, vous pouvez utiliser la haute disponibilité équilibrée Hyperdisk. Lorsque des données sont écrites sur un volume, elles sont répliquées de manière synchrone entre deux zones d'une même région.

Robustesse face aux pannes régionales

Si les deux zones de l'architecture présentent une panne ou s'il se produit une panne régionale, l'application est indisponible. Pour réduire les temps d'arrêt causés par les pannes multizones ou régionales, vous pouvez implémenter l'approche suivante:

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. Pour le niveau de base de données, vous pouvez utiliser la stratégie de basculement forcé Oracle Active Data Guard pour basculer automatiquement vers une instance de base de données Oracle de secours dans la région de basculement. Cette approche correspond au niveau Or de la certification MAA d'Oracle.

Autoscaling des MIG

Lorsque vous exécutez votre application sur des VM dans un MIG régional, celle-ci reste disponible en cas de panne d'une zone isolée. La fonctionnalité d'autoscaling des MIG sans état vous permet de maintenir à des niveaux prévisibles la disponibilité et les performances de l'application. 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 garantit que votre application résiste 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 en 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.

Disponibilité du stockage de blocs

L'architecture décrite dans ce document utilise un pool de stockage Hyperdisk dans chaque zone pour fournir un stockage en mode bloc aux VM Compute Engine. Vous créez un pool de capacité de stockage en blocs pour une zone. Vous créez ensuite des volumes Hyperdisk dans le pool de stockage et les associez aux VM de la zone. Le pool de stockage tente d'ajouter automatiquement de la capacité pour s'assurer que le taux d'utilisation ne dépasse pas 80% de la capacité provisionnée du pool. Cette approche garantit que l'espace de stockage en blocs est disponible lorsque cela est nécessaire. Pour en savoir plus, consultez la section Fonctionnement des pools de stockage Hyperdisk.

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.

Sauvegarde et récupération

L'architecture décrite dans ce document utilise Cloud Storage pour stocker les sauvegardes de la base de données. Si vous choisissez le type d'emplacement birégional ou multirégional pour le bucket Cloud Storage, les sauvegardes sont répliquées de manière asynchrone dans au moins deux zones géographiques. En cas de panne régionale, vous pouvez utiliser les sauvegardes pour restaurer la base de données dans une autre région. Avec un bucket birégional, vous pouvez obtenir une réplication plus rapide en activant l'option de réplication turbo. Pour en savoir plus, consultez la section Disponibilité et durabilité des données.

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 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 cette architecture de référence.

Types de machine des VM

Pour vous aider à optimiser l'utilisation de vos ressources 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.

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 avec des VM Spot 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. N'utilisez pas de VM Spot pour les VM qui hébergent les instances de base de données Oracle.

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.

Attribution de licences Oracle Database

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 Oracle Database, 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 instances Oracle Database. Pour en savoir plus, consultez la section Licensier des logiciels Oracle dans l'environnement de cloud computing.

Utilisation des ressources de stockage de blocs

L'architecture décrite dans ce document utilise un pool de stockage Hyperdisk dans chaque zone pour fournir un stockage en mode bloc aux VM Compute Engine. Vous pouvez améliorer l'utilisation globale de la capacité de stockage de blocs et réduire les coûts en utilisant des pools de stockage de capacité Advanced, qui utilisent des technologies de provisionnement léger et de réduction des données pour améliorer l'efficacité du stockage.

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 et les correctifs de sécurité 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.

Gestion du stockage de blocs

L'architecture décrite dans ce document utilise un pool de stockage Hyperdisk dans chaque zone pour fournir un stockage en mode bloc aux VM Compute Engine. Les pools de stockage Hyperdisk simplifient la gestion du stockage. Au lieu d'allouer et de gérer la capacité individuellement pour de nombreux disques, vous définissez un pool de capacité pouvant être partagé entre plusieurs charges de travail dans une zone. Vous créez ensuite des volumes Hyperdisk dans le pool de stockage et les associez aux VM de la zone. Le pool de stockage tente d'ajouter automatiquement de la capacité pour s'assurer que le taux d'utilisation ne dépasse pas 80% de la capacité provisionnée du pool.

Connectivité du serveur d'applications à la base de données

Pour les connexions de votre application à 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. L'avantage supplémentaire de cette approche est que vous n'avez pas besoin de réserver et d'attribuer des adresses IP internes statiques aux VM de base de données.

Administration et assistance Oracle Database

Lorsque vous exécutez une instance Oracle Database autogérée sur une VM Compute Engine, les problématiques opérationnelles sont similaires à celles que vous rencontrez lorsque vous exécutez Oracle Database sur site. Toutefois, avec une VM Compute Engine, vous n'avez plus besoin de gérer l'infrastructure de calcul, de mise en réseau et de stockage sous-jacente.

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 de performances pour ces niveaux. Pour obtenir la liste des types de machines disponibles compatibles avec les volumes Hyperdisk et répondant à vos exigences de performances et autres, consultez le tableau Comparaison des séries de machines.
  • Pour les VM qui hébergent 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 cohérentes pour les charges de travail de base de données.

Performances du réseau

Pour les charges de travail nécessitant une faible latence réseau entre VM, vous pouvez créer une stratégie d'emplacement compact et l'appliquer au modèle de MIG utilisé pour le niveau d'application. 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.

Performances du stockage Hyperdisk

L'architecture décrite dans ce document utilise des volumes Hyperdisk pour les VM de tous les niveaux. Hyperdisk vous permet de faire évoluer les performances et la capacité de manière dynamique. Vous pouvez ajuster les IOPS provisionnées, le débit et la taille de chaque volume pour répondre aux besoins de performances et de 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 et l'optimisation des performances 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 la section Framework d'architecture Google Cloud : optimisation des performances.

Étape suivante

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :