Déploiement à zone unique sur Compute Engine

Last reviewed 2024-02-08 UTC

Ce document fournit une architecture de référence pour une application à plusieurs niveaux qui s'exécute sur des VM Compute Engine dans une zone Google Cloud unique. Vous pouvez utiliser cette architecture de référence pour réhéberger (migration Lift and Shift) efficacement des applications sur site vers le cloud en apportant un minimum de modifications aux applications. Le document décrit également les facteurs de conception à prendre en compte lorsque vous créez une architecture zonale pour vos applications cloud. Ce document s'adresse aux architectes cloud.

Architecture

Le schéma suivant illustre une architecture pour une application qui s'exécute dans une zone Google Cloud unique. Cette architecture est conforme à l'archétype de déploiement zonal Google Cloud.

Architecture à zone unique utilisant Compute Engine.

L'architecture est basée sur le modèle cloud IaaS (Infrastructure as a Service). Vous provisionnez les ressources d'infrastructure nécessaires (calcul, mise en réseau et stockage) dans Google Cloud. Vous conservez un contrôle total sur l'infrastructure et la responsabilité du système d'exploitation, du middleware et des couches supérieures de la pile d'applications. Pour en savoir plus sur le modèle IaaS et d'autres modèles cloud, consultez l'article En quoi les types de cloud PaaS, IaaS, SaaS et CaaS sont-ils différents ?

Le schéma précédent comprend les composants suivants :

Composant Objectif
Équilibreur de charge externe régional

L'équilibreur de charge externe régional reçoit et distribue les requêtes des utilisateurs aux VM de niveau Web.

Utilisez un type d'équilibreur de charge approprié en fonction du type de trafic et des autres exigences. Par exemple, si le backend se compose de serveurs Web (comme illustré dans l'architecture précédente), utilisez un équilibreur de charge d'application pour transférer le trafic HTTP(S). Pour équilibrer la charge du trafic TCP, utilisez un équilibreur de charge réseau. Pour en savoir plus, consultez la page Choisir un équilibreur de charge.

Groupe d'instances géré (MIG) zonal pour le niveau Web Le niveau Web de l'application est déployé sur des VM Compute Engine qui font partie d'un MIG zonal. Le MIG est le backend de l'équilibreur de charge externe régional. Chaque VM du MIG héberge une instance indépendante du niveau Web de l'application.
Équilibreur de charge interne régional

L'équilibreur de charge interne régional répartit le trafic des VM du niveau Web vers les VM du niveau application.

Selon vos besoins, vous pouvez utiliser un équilibreur de charge d'application interne régional ou un équilibreur de charge réseau interne régional. Pour en savoir plus, consultez la page Choisir un équilibreur de charge.

MIG zonal pour le niveau application Le niveau application est déployé sur des VM Compute Engine faisant partie d'un MIG zonal, qui est le backend de l'équilibreur de charge interne. Chaque VM du MIG héberge une instance indépendante du niveau application.
Base de données tierce déployée sur une VM Compute Engine

L'architecture décrite dans ce document montre une base de données tierce (telle que PostgreSQL) déployée sur une VM Compute Engine. Vous pouvez déployer une base de données de secours dans une autre zone. Les fonctionnalités de réplication et de basculement de base de données dépendent de la base de données que vous utilisez.

L'installation et la gestion d'une base de données tierce impliquent des efforts et des coûts opérationnels supplémentaires pour l'application des mises à jour, la surveillance et la garantie de la disponibilité. Vous pouvez éviter le surcoût lié à l'installation et à la gestion d'une base de données tierce, et profiter des fonctionnalités de haute disponibilité intégrées en utilisant un service de base de données entièrement géré tel que Cloud SQL ou AlloyDB pour PostgreSQL. Pour en savoir plus sur les options de bases de données gérées, consultez la page Services de base de données.

Réseau cloud privé virtuel 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 plus d'informations, consultez la section Décider s'il convient de créer plusieurs réseaux VPC de la page "Bonnes pratiques et architectures de référence pour la conception de VPC".

Bucket régional Cloud Storage

Les sauvegardes d'applications et de bases de données sont stockées dans un bucket Cloud Storage régional. En cas de panne zonale, votre application et vos données ne sont pas perdues.

Vous pouvez également utiliser le service de sauvegarde et de reprise après sinistre pour créer, stocker et gérer les sauvegardes de la base de données.

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 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 : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud.

Cas d'utilisation

Cette section décrit les cas d'utilisation pour lesquels un déploiement à zone unique sur Compute Engine constitue un choix approprié.

  • Développement et tests dans le cloud : vous pouvez utiliser une architecture de déploiement à zone unique pour créer un environnement cloud économique pour le développement et les tests.
  • Applications qui n'ont pas besoin de la haute disponibilité : une architecture à zone unique peut être suffisante pour les applications pouvant tolérer des temps d'arrêt dus à des pannes d'infrastructure.
  • Mise en réseau à faible latence et faible coût entre les composants d'application : une architecture à zone unique peut être adaptée aux applications telles que le calcul par lot qui nécessitent des connexions réseau à faible latence et à bande passante élevée entre les nœuds de calcul. Avec un déploiement à zone unique, il n'y a pas de trafic réseau interzone, et le trafic intrazone n'entraîne aucuns frais.
  • Migration de charges de travail standards : l'architecture de déploiement zonal fournit un chemin de migration cloud simple pour les applications sur site dont vous ne contrôlez pas le code ou qui ne peuvent pas accepter d'architectures autres qu'une topologie active-passive de base.
  • Exécuter des logiciels sous licence : une architecture à zone unique peut être adaptée aux systèmes sous licence avec lesquels l'exécution de plusieurs instances à la fois est trop coûteuse ou non autorisée.

Considérations de conception

Cette section fournit des conseils pour vous aider à utiliser cette architecture de référence afin de développer une architecture répondant à vos exigences spécifiques en termes de conception, de sécurité et de conformité du système, de fiabilité, d'efficacité opérationnelle, de coût et de performances.

Conception du système

Cette section fournit des conseils pour vous aider à choisir les régions et les zones Google Cloud de votre déploiement zonal et à sélectionner les services Google Cloud appropriés.

Sélection de la région

Lorsque vous choisissez une région et une zone Google Cloud pour vos applications, tenez compte des facteurs et exigences suivants :

  • Disponibilité des services Google Cloud. Pour en savoir plus, consultez la page Produits disponibles par emplacement.
  • Disponibilité des types de machines Compute Engine. 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.
  • 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 page Choisir des zones géographiques et des régions dans le framework d'architecture Google Cloud.

Services de calcul

L'architecture de référence décrite dans ce document utilise des VM Compute Engine pour tous les niveaux de l'application. Sauf indication contraire, les conseils de conception fournis dans ce document sont spécifiques à Compute Engine.

Selon les exigences de votre application, vous pouvez choisir parmi les autres services de calcul Google Cloud suivants. Les conseils de conception pour ces services n'entrent pas dans le cadre de ce document.

  • 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.
  • 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 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é 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 dans Google Cloud, consultez la page Choisir et gérer les ressources de calcul dans le framework d'architecture Google Cloud.

Services de stockage

L'architecture présentée dans ce document utilise des volumes Persistent Disk zonaux pour tous les niveaux. Pour un stockage persistant plus durable, vous pouvez utiliser des volumes Persistent Disk régionaux, qui permettent une réplication synchrone des données sur deux zones d'une même région.

Pour un stockage à faible coût redondant entre les zones d'une région, vous pouvez utiliser les buckets Cloud Storage régionaux.

Pour stocker des données partagées sur plusieurs VM d'une région, par exemple l'ensemble des VM du niveau Web ou du niveau Application, vous pouvez utiliser Filestore. Les données que vous stockez dans une instance Filestore Enterprise 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.

Si votre base de données est Microsoft SQL Server, nous vous recommandons d'utiliser Cloud SQL pour SQL Server. Dans les cas où Cloud SQL n'est pas compatible avec vos exigences en matière de configuration ou si vous avez besoin d'accéder au système d'exploitation, vous pouvez déployer une instance de cluster de basculement (FCI). Dans ce scénario, vous pouvez utiliser les services entièrement gérés Google Cloud NetApp Volumes pour fournir un espace de stockage SMB à disponibilité continue (CA) pour la base de données.

Lorsque vous concevez le stockage pour vos charges de travail, tenez compte des caractéristiques fonctionnelles, 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.

Services de base de données

L'architecture de référence de ce document utilise une base de données tierce, telle que PostgreSQL, déployée sur des VM Compute Engine. L'installation et la gestion d'une base de données tierce impliquent des efforts et des coûts pour les opérations telles que l'application de mises à jour, la surveillance et la garantie de disponibilité, l'exécution de sauvegardes et la récupération en cas de défaillance.

Vous pouvez vous épargner les efforts et les coûts liés à l'installation et à la gestion d'une base de données tierce en utilisant un service de base de données entièrement géré tel que Cloud SQL, AlloyDB pour PostgreSQL, Bigtable, Spanner ou Firestore. Ces services de base de données Google Cloud offrent des contrats de niveau de service (SLA) de disponibilité, et incluent des fonctionnalités par défaut pour l'évolutivité et l'observabilité. Si vos charges de travail nécessitent une base de données Oracle, vous pouvez utiliser la solution Bare Metal fournie par Google Cloud. Pour obtenir une présentation des cas d'utilisation auxquels chaque service de base de données Google Cloud convient, consultez la section Bases de données Google Cloud.

Sécurité et conformité

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir et créer une topologie zonale 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. Les stratégies de sécurité sont appliquées au périmètre, c'est-à-dire avant que le trafic n'atteigne le niveau Web. 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é. En outre, vous pouvez 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 Application, le niveau Web et les bases de données n'ont pas besoin d'un accès entrant depuis Internet. N'attribuez pas d'adresses IP externes à ces VM. Les ressources Google Cloud 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 en provenance des ressources Google Cloud qui ne possèdent que des adresses IP internes, comme les VM Compute Engine de cette architecture de référence, vous pouvez utiliser Cloud NAT.

Sécurité des images de VM

Pour vous assurer que vos VM n'utilisent que des images approuvées (c'est-à-dire, des images comportant des logiciels conformes à vos règles ou à vos exigences de sécurité), 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. 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 application. 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 page Limiter les droits des comptes de service dans la section "Bonnes pratiques d'utilisation des comptes de service".

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 appropriées. Chaque règle de pare-feu vous permet de contrôler le trafic en fonction de paramètres tels que le protocole, l'adresse IP et le port. Par exemple, vous pouvez configurer une règle de pare-feu pour autoriser le trafic TCP provenant des VM de serveur Web vers un port spécifique des VM de base de données, et bloquer tout le reste du trafic.

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 afin de créer et d'exploiter une infrastructure fiable pour vos déploiements zonaux dans Google Cloud.

Pannes d'infrastructure

Dans une architecture de déploiement à zone unique, en cas de défaillance d'un composant dans la pile d'infrastructure, l'application peut traiter les requêtes si chaque niveau contient au moins un composant fonctionnel disposant d'une capacité suffisante. Par exemple, en cas d'échec d'une instance de serveur Web, l'équilibreur de charge transfère les requêtes des utilisateurs aux autres instances disponibles du serveur Web. Si une VM qui héberge un serveur Web ou une instance de serveur d'applications plante, le MIG recrée automatiquement la VM. Si la base de données plante, vous devez activer manuellement la deuxième base de données et mettre à jour les instances du serveur d'applications pour qu'elles se connectent à la base de données.

Une panne zonale ou régionale affecte toutes les VM Compute Engine lors d'un déploiement à zone unique. Les pannes zonales n'affectent pas l'équilibreur de charge de cette architecture, car il s'agit d'une ressource régionale. Cependant, l'équilibreur de charge ne peut pas distribuer le trafic, car aucun backend n'est disponible. Si une panne zonale ou régionale se produit, vous devez attendre que Google la résolve, puis vérifier que l'application fonctionne comme prévu.

Vous pouvez réduire les temps d'arrêt causés par les pannes zonales ou régionales en conservant une instance répliquée passive (de basculement) de la pile d'infrastructure dans une autre zone ou région Google Cloud. Si une panne se produit dans la zone principale, vous pouvez activer la pile dans la région ou zone de basculement et utiliser des règles de routage DNS pour acheminer le trafic vers l'équilibreur de charge dans la région ou zone de basculement.

Pour les applications nécessitant une robustesse face aux pannes zonales ou régionales, envisagez d'utiliser une architecture régionale ou multirégionale. Consultez les architectures de référence suivantes :

Autoscaling des MIG

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.

Limite de taille des groupes d'instances gérés

Par défaut, un MIG zonal peut comporter jusqu'à 1000 VM. Vous pouvez augmenter la taille maximale d'un groupe d'instances géré à 2000 VM.

Autoréparation de VM

Parfois, les VM qui hébergent votre application sont en cours d'exécution et disponibles, mais vous pouvez rencontrer des problèmes avec l'application proprement dite. Elle peut se figer, planter ou manquer de mémoire. Pour vérifier si une application répond 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 page Configurer une vérification de l'état et une autoréparation des applications.

Emplacement de la VM

Dans l'architecture décrite dans ce document, le niveau application et le niveau Web sont exécutés sur des VM Compute Engine dans une seule zone. Pour améliorer la robustesse de l'architecture, vous pouvez créer une stratégie d'emplacement de répartition et l'appliquer au modèle de MIG. Lorsque le MIG crée des VM, il les place sur différents serveurs physiques (appelés hôtes) afin qu'elles résistent aux défaillances d'hôtes individuels. Pour en savoir plus, consultez la page Appliquer des stratégies d'emplacement de répartition aux VM.

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.

État du disque persistant

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

Durabilité des données

Vous pouvez utiliser l'outil de sauvegarde et reprise après sinistre pour créer, stocker et gérer des sauvegardes des VM Compute Engine. L'outil de sauvegarde et reprise après sinistre stocke les données de la sauvegarde dans leur format d'origine lisible par l'application. Si nécessaire, vous pouvez restaurer vos charges de travail en production en utilisant directement les données d'un stockage de sauvegarde à long terme sans perdre du temps à déplacer les données ni à les préparer.

Si vous utilisez un service de base de données géré tel que Cloud SQL, les sauvegardes sont effectuées automatiquement en fonction de la règle de conservation que vous définissez. Vous pouvez compléter la stratégie de sauvegarde par des sauvegardes logiques supplémentaires pour répondre aux exigences réglementaires, de workflow ou métier.

Si vous utilisez une base de données tierce et que vous devez stocker des sauvegardes de base de données et des journaux de transactions, vous pouvez utiliser des buckets Cloud Storage régionaux. Les buckets Cloud Storage régionaux offrent un stockage de sauvegarde redondant à faible coût entre les zones.

Compute Engine offre les options suivantes pour vous aider à garantir la durabilité des données stockées dans les volumes de disques persistants :

  • Vous pouvez utiliser des instantanés pour capturer l'état des volumes de disques persistants à un moment précis. Les instantanés standards sont stockés de manière redondante dans plusieurs régions, avec des sommes de contrôle automatiques permettant de garantir l'intégrité des données. Les instantanés sont incrémentiels par défaut. Ils utilisent donc moins d'espace de stockage et vous réalisez des économies. Les instantanés sont stockés dans un emplacement Cloud Storage que vous pouvez configurer. Pour obtenir d'autres recommandations sur l'utilisation et la gestion des instantanés, consultez la page bonnes pratiques relatives aux instantanés de disques Compute Engine.
  • Les volumes de disques persistants régionaux vous permettent d'exécuter des applications à disponibilité élevée, qui ne sont pas affectées en cas de défaillances des disques persistants. Lorsque vous créez un volume de disque persistant régional, Compute Engine gère une instance répliquée du disque dans une autre zone de la même région. Les données sont répliquées de manière synchrone sur les disques des deux zones. En cas de panne dans l'une des deux zones, les données restent disponibles.

Disponibilité des bases de données

Si vous utilisez un service de base de données géré tel que Cloud SQL dans la configuration à haute disponibilité, Cloud SQL bascule automatiquement en cas de défaillance de la base de données principale vers la base de données de secours. Vous n'avez pas besoin de modifier l'adresse IP du point de terminaison de la base de données. Si vous utilisez une base de données tierce autogérée déployée sur une VM Compute Engine, vous devez utiliser un équilibreur de charge interne ou un autre mécanisme pour vous assurer que l'application peut se connecter à une autre base de données si la base de données principale n'est pas disponible.

Pour mettre en œuvre le basculement interzone pour une base de données déployée sur une VM Compute Engine, vous avez besoin d'un mécanisme permettant d'identifier les défaillances de la base de données principale et d'un processus de basculement vers la base de données de secours. Les détails spécifiques du mécanisme de basculement dépendent de la base de données que vous utilisez. Vous pouvez configurer une instance observatrice pour détecter les défaillances de la base de données principale et orchestrer le basculement. Vous devez configurer les règles de basculement de manière appropriée pour éviter une situation de split-brain et éviter tout basculement inutile. Pour obtenir des exemples d'architectures que vous pouvez utiliser afin d'implémenter le basculement pour des bases de données PostgreSQL, consultez la page Architectures haute disponibilité pour les clusters PostgreSQL sur Compute Engine.

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 zonale que vous créez à l'aide de cette architecture de référence.

Types de machine des VM

Pour vous aider à optimiser l'utilisation des ressources de vos instances de VM, Compute Engine propose des recommandations de types de machines. Utilisez les recommandations pour choisir les types de machines qui correspondent aux exigences de calcul de votre charge de travail. Pour les charges de travail ayant des besoins en ressources prévisibles, vous pouvez personnaliser le type de machine en fonction de vos besoins et réaliser des économies en utilisant des types de machines personnalisés.

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 les 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 sont adaptées aux tâches par lots pouvant tolérer la préemption et ne présentent pas d'exigences 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 un scaling horizontal (c'est-à-dire créer des VM) jusqu'à la taille cible spécifiée tant que la capacité requise n'est pas disponible.

Utilisation des ressources

La fonctionnalité d'autoscaling des MIG sans état permet à votre application de gérer sans heurt les hausses de trafic et 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.

Licences tierces

Lorsque vous migrez des charges de travail tierces vers Google Cloud, vous pouvez peut-être réduire les coûts en utilisant vos propres licences (BYOL). Par exemple, pour déployer des VM Microsoft Windows Server, vous pouvez créer et utiliser une image BYOL Windows personnalisée plutôt que d'utiliser une image payante qui entraîne des coûts supplémentaires pour la licence tierce. Vous ne payez alors que pour l'infrastructure de VM que vous utilisez sur Google Cloud. Cette stratégie vous permet de continuer à tirer profit de vos investissements existants en licences tierces. Si vous décidez d'utiliser l'approche BYOL, nous vous recommandons d'effectuer les opérations suivantes :

  • Provisionnez le nombre de cœurs de CPU requis indépendamment de la mémoire, en utilisant les types de machines personnalisés. Cela permet de limiter le coût des licences tierces au nombre de cœurs de CPU dont vous avez besoin.
  • Réduisez le nombre de vCPU par cœur de 2 à 1 en désactivant le multithreading simultané (SMT) pour réduire vos coûts de licence de 50 %.

Si vous déployez une base de données tierce telle que Microsoft SQL Server sur des VM Compute Engine, vous devez prendre en compte les coûts de licence du logiciel tiers. Lorsque vous utilisez un service de base de données géré tel que Cloud SQL, les coûts de licence de la base de données sont inclus dans les frais du service.

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 et créer dans Google Cloud une topologie zonale 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 choisissez : 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 personnalisées contenant 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.

Modèles d'instances déterministes

Si les modèles d'instance que vous utilisez pour vos MIG incluent des scripts de démarrage permettant d'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 peut 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.

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 et créer dans Google Cloud une topologie zonale qui répond aux exigences de performances de vos charges de travail.

Emplacement de la VM

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. Lorsque le MIG crée des VM, il les place alors sur des serveurs physiques proches les uns des autres. Pour en savoir plus, consultez la section Réduire la latence à l'aide de stratégies de concentration.

Types de machine des VM

Compute Engine propose un large éventail de types de machines prédéfinis et personnalisables, que vous pouvez choisir sur la base de vos exigences en matière de coûts et de performances. Les types de machines sont regroupés en séries et familles de machines. Le tableau suivant récapitule les familles et séries de machines recommandées pour différents types de charges de travail :

Exigence Famille de machines recommandée Exemples de séries de machines
Le meilleur rapport prix/performances pour des charges de travail diverses Famille de machines à usage général C3, C3D, E2, N2, N2D, Tau T2D, Tau T2A
Performances les plus élevées par cœur, optimisées pour les charges de travail intensives en calcul Famille de machines optimisées pour le calcul C2, C2D, H3
Ratio mémoire/vCPU élevé pour les charges de travail exigeantes en mémoire Famille de machines à mémoire optimisée M3, M2, M1
GPU pour des charges de travail massivement parallélisées Famille de machines optimisées pour les accélérateurs A2, G2

Pour en savoir plus, consultez le Guide des ressources de familles de machines et guide comparatif.

Multithreading de VM

Chaque processeur virtuel que vous allouez à une VM Compute Engine est mis en œuvre sous la forme d'un multithread matériel unique. Par défaut, deux processeurs virtuels partagent un cœur physique de processeur. Pour les charges de travail hautement parallèles ou qui effectuent des calculs à virgule flottante (tels que l'analyse de séquences génétiques et la modélisation des risques financiers), vous pouvez améliorer les performances en réduisant le nombre de threads s'exécutant sur chaque cœur de processeur physique. Pour en savoir plus, consultez la section Définir le nombre de threads par cœur.

Le multithreading de VM peut avoir des implications en termes de licence pour certains logiciels tiers, tels que des logiciels de bases de données. Pour plus d'informations, consultez la documentation de licence du logiciel tiers.

Niveaux de service réseau

Les niveaux de service réseau vous permettent d'optimiser le coût et les performances réseau de vos charges de travail. Vous pouvez choisir entre les niveaux Premium ou Standard.

  • Le niveau Premium utilise le réseau backbone mondial extrêmement fiable de Google pour vous aider à réduire au minimum la perte de paquets et la latence. Le trafic entre et sort du réseau Google au niveau d'un point of presence (POP) périphérique global, qui est celui le plus proche de votre utilisateur final. Nous vous recommandons d'utiliser le niveau Premium comme niveau par défaut pour des performances optimales.
  • Avec le niveau Standard, le trafic entre et sort du réseau Google au niveau d'un POP périphérique le plus proche de l'emplacement Google Cloud dans lequel votre charge de travail est exécutée. Le prix du niveau Standard est inférieur à celui du niveau Premium. Le niveau Standard convient au trafic non sensible à la perte de paquets et qui ne présente pas d'exigences de faible latence.

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.

Étapes suivantes

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :