Déploiement multirégional sur Compute Engine

Last reviewed 2025-05-27 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 plusieurs régions de Google Cloud. 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 multirégionale 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 en mode actif-actif dans des piles isolées déployées dans deux régions Google Cloud . Dans chaque région, l'application s'exécute indépendamment dans trois zones. L'architecture est conforme à l'Google Cloud archétype de déploiement multirégional, ce qui garantit que votre topologie Google Cloud résiste aux pannes zonales et régionales, et qu'elle offre une latence faible aux utilisateurs de l'application.

Architecture multirégionale utilisant un équilibreur de charge global

L'architecture est basée sur le modèle cloud IaaS (Infrastructure as a Service). Vous provisionnez les ressources d'infrastructure requises (calcul, mise en réseau et stockage) dans Google Cloud, et vous conservez un contrôle total sur le système d'exploitation, le middleware et les couches supérieures de la pile d'applications. Pour en savoir plus sur le modèle IaaS et d'autres modèles cloud, consultez 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 Purpose
Équilibreur de charge externe global

L'équilibreur de charge externe global reçoit et distribue les requêtes des utilisateurs à l'application. L'équilibreur de charge externe global annonce une seule adresse IP Anycast, mais il est mis en œuvre sous la forme d'un grand nombre de proxys sur Google Front End (GFE). Les requêtes des clients sont dirigées vers le GFE le plus proche du client.
Groupes d'instances gérés (MIG) régionaux pour le niveau Web

Le niveau Web de l'application est déployé sur des VM Compute Engine faisant partie de MIG régionaux. Ces MIG sont les backends de l'équilibreur de charge global.

Chaque MIG contient des VM Compute Engine réparties dans trois zones différentes. Chacune de ces VM héberge une instance indépendante du niveau Web de l'application.
Équilibreurs de charge internes régionaux

L'équilibreur de charge interne de chaque région répartit le trafic des VM de niveau Web vers les VM de niveau Application de cette région.
MIG régionaux pour le niveau application

Le niveau Application est déployé sur des VM Compute Engine faisant partie de MIG régionaux. Le MIG de chaque région est le backend de l'équilibreur de charge interne de cette région.

Chaque MIG contient des VM Compute Engine réparties dans trois zones différentes. Chaque VM héberge une instance indépendante du niveau Application.
Base de données tierce déployée sur des VM Compute Engine

L'architecture décrite dans ce document montre une base de données tierce (telle que PostgreSQL) déployée sur des VM Compute Engine dans les deux régions. Vous pouvez configurer la réplication interrégionale des bases de données et configurer la base de données dans chaque région pour qu'elle bascule vers la base de données de l'autre région. Les fonctionnalités de réplication et de basculement 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 la réplication, 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 une base de données entièrement gérée, comme une instance Spanner multirégionale.
Réseau cloud privé virtuel et sous-réseaux

Toutes les ressources Google Cloud de l'architecture utilisent un unique réseau VPC comportant des sous-réseaux dans deux régions différentes.

Selon vos besoins, vous pouvez choisir de créer une architecture utilisant plusieurs réseaux et sous-réseaux VPC. Pour en savoir plus, consultez Choisir de créer ou non plusieurs réseaux VPC.
Buckets Cloud Storage birégionaux

Les sauvegardes de bases de données sont stockées dans des buckets Cloud Storage birégionaux. 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 : store 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é.

Cas d'utilisation

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

Migration efficace des applications sur site

Vous pouvez utiliser cette architecture de référence pour créer une topologie Google Cloud afin de réhéberger (migration Lift and Shift) dans le cloud des applications sur site, avec un minimum de modifications. Dans cette architecture de référence, tous les niveaux de l'application sont hébergés sur des VM Compute Engine. Cette approche vous permet de migrer efficacement des applications sur site vers le cloud et de bénéficier des avantages en termes de coûts, de fiabilité, de performances et de simplicité opérationnelle offerts par Google Cloud.

Haute disponibilité pour les utilisateurs dispersés géographiquement

Nous recommandons le déploiement multirégional pour les applications critiques et pour lesquelles la haute disponibilité et la robustesse face aux pannes régionales sont essentielles. Si une région devient indisponible pour une raison quelconque (y compris une perturbation à grande échelle provoquée par une catastrophe naturelle), les utilisateurs de l'application ne remarquent aucun temps d'arrêt. Le trafic est acheminé vers l'application dans les autres régions disponibles. Si les données sont répliquées de manière synchrone, l'objectif de temps de récupération (RTO) est proche de zéro.

Faible latence pour les utilisateurs de l'application

Si vos utilisateurs se trouvent dans une zone géographique spécifique, par exemple un continent, vous pouvez utiliser un déploiement multirégional pour obtenir un équilibre optimal entre la disponibilité et les performances. Si l'une des régions subit une panne, l'équilibreur de charge global envoie les requêtes provenant de cette région à une autre région. Les utilisateurs ne perçoivent pas d'impact significatif sur les performances, car les régions se trouvent dans la même zone géographique.

Alternative de conception

L'architecture précédente utilise un équilibreur de charge global, qui est compatible avec certaines fonctionnalités permettant d'améliorer la fiabilité de vos déploiements, comme la mise en cache périphérique à l'aide de Cloud CDN. Cette section présente une architecture alternative qui utilise des équilibreurs de charge régionaux et Cloud DNS. Cette architecture alternative prend en charge les fonctionnalités supplémentaires suivantes :

  • Terminaison TLS (Transport Layer Security) dans les régions spécifiées.
  • Possibilité de diffuser du contenu depuis la région spécifiée Cependant, cette région peut ne pas être la région la plus performante à un moment donné.
  • Une gamme plus large de protocoles de connexion si vous utilisez un équilibreur de charge réseau passthrough.

Pour en savoir plus sur les différences entre les équilibreurs de charge régionaux et mondiaux, consultez Équilibrage de charge global ou régional et Modes de fonctionnement.

Architecture multirégionale avec équilibreurs de charge régionaux et DNS

L'architecture alternative du diagramme précédent est robuste contre les pannes de zone et de région. Une zone publique Cloud DNS achemine les requêtes des utilisateurs vers la région appropriée. Les équilibreurs de charge externes régionaux reçoivent les requêtes des utilisateurs et les répartissent sur les instances du niveau Web de l'application dans chaque région. Les autres composants de cette architecture sont identiques à ceux de l'architecture basée sur l'équilibreur de charge global.

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é, de fiabilité, d'efficacité opérationnelle, de coût et de performances.

Lorsque vous créez une architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations du Google Cloud Well-Architected Framework.

Conception du système

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

Sélection de la région

Lorsque vous choisissez les régions Google Cloud dans lesquelles vos applications doivent être déployées, tenez compte des facteurs et exigences suivants :

  • Disponibilité des services Google Cloud dans chaque région. Pour en savoir plus, consultez la page Produits disponibles par emplacement.
  • Disponibilité des types de machines Compute Engine dans chaque région. Pour en savoir plus, consultez la page Régions et zones.
  • Exigences relatives à la latence de l'utilisateur final.
  • Coût des ressources Google Cloud .
  • Coûts des transferts de données interrégionaux.
  • Exigences réglementaires.

Certains de ces facteurs et exigences peuvent impliquer des compromis. Par exemple, la région la plus rentable en termes de coûts peut ne pas avoir l'empreinte carbone la plus basse. Pour en savoir plus, consultez Bonnes pratiques pour la sélection des régions Compute Engine.

Infrastructure de calcul

L'architecture de référence décrite dans ce document utilise des VM Compute Engine pour certains niveaux de l'application. Selon les exigences de votre application, vous pouvez choisir parmi d'autres services de calcul Google Cloud  :

  • Conteneurs : vous pouvez exécuter des applications conteneurisées dans des clusters Google Kubernetes Engine (GKE). GKE est un moteur d'orchestration de conteneurs qui automatise le déploiement, le scaling et la gestion des applications conteneurisées.
  • Sans serveur : si vous préférez concentrer vos efforts informatiques sur vos données et vos applications plutôt que sur la configuration et l'exploitation des ressources d'infrastructure, vous pouvez utiliser des services sans serveur tels que Cloud Run.

La décision d'utiliser des VM, des conteneurs ou des services sans serveur implique un compromis entre la flexibilité de la configuration et les efforts de gestion. Les VM et les conteneurs offrent davantage de flexibilité de configuration, mais vous êtes responsable de la gestion des ressources. Dans une architecture sans serveur, vous déployez des charges de travail sur une plate-forme préconfigurée qui nécessite un effort de gestion minimal. Pour en savoir plus sur le choix des services de calcul appropriés pour vos charges de travail dansGoogle Cloud, consultez Héberger des applications sur Google Cloud.

Services de stockage

Les architectures présentées dans ce document utilisent des volumes de disques persistants régionaux pour tous les niveaux. Les disques persistants fournissent une réplication synchrone des données sur deux zones d'une même région.

Les autres options de stockage pour les déploiements multirégionaux incluent des buckets Cloud Storage birégionaux ou multirégionaux. Les objets stockés dans un bucket birégional ou un multirégional sont stockés de manière redondante dans au moins deux zones géographiques distinctes. Les métadonnées sont écrites de manière synchrone entre les régions, et les données sont répliquées de manière asynchrone. Pour les buckets birégionaux, vous pouvez utiliser la réplication turbo, qui garantit que les objets sont répliqués entre des paires de régions, avec un objectif de point de récupération (RPO) de 15 minutes. Pour en savoir plus, consultez la section Disponibilité et durabilité des données.

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 une instance régionale 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 multirégionales, tenez compte des caractéristiques fonctionnelles des charges de travail, des exigences 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.

Des services de base de données

L'architecture de référence de ce document utilise une base de données tierce 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 Google Cloud services de base de données 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 votre charge de travail nécessite une base de données Oracle, vous pouvez la déployer sur une VM Compute Engine ou utiliser Oracle Database@Google Cloud. Pour en savoir plus, consultez Charges de travail Oracle dans Google Cloud.

Lorsque vous choisissez et configurez la base de données pour un déploiement multirégional, tenez compte des exigences de votre application en matière de cohérence des données entre régions et soyez attentif aux compromis en termes de performances et de coûts.

  • Si l'application nécessite une cohérence forte (tous les utilisateurs doivent lire les mêmes données à tout moment), celles-ci doivent être répliquées de manière synchrone sur toutes les régions de l'architecture. Cependant, la réplication synchrone peut entraîner une augmentation des coûts et une baisse des performances, car toutes les données écrites doivent être répliquées en temps réel dans les régions avant que les données ne soient disponibles pour les opérations de lecture.
  • Si votre application peut tolérer une cohérence à terme, vous pouvez répliquer les données de manière asynchrone. Cela peut améliorer les performances, car les données n'ont pas besoin d'être répliquées de manière synchrone entre les régions. Toutefois, cela peut amener des utilisateurs de différentes régions à lire des données différentes, car celles-ci n'ont peut-être pas été entièrement répliquées au moment de la requête.

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 et créer une topologie multirégionale dansGoogle Cloud qui répond aux exigences de sécurité, de confidentialité et de conformité de vos charges de travail.

Protection contre les menaces externes

Pour protéger votre application contre les menaces telles que les attaques par déni de service distribué (DDoS) et les scripts intersites (XSS), vous pouvez utiliser les stratégies de sécurité Google Cloud Armor. Chaque stratégie est un ensemble de règles qui spécifient certaines conditions devant être évaluées et les mesures à prendre lorsque ces conditions sont remplies. Par exemple, une règle peut spécifier que si l'adresse IP source du trafic entrant correspond à une adresse IP ou à une plage CIDR spécifique, le trafic doit être refusé. Vous pouvez également appliquer des règles de pare-feu d'application Web (WAF) préconfigurées. Pour en savoir plus, consultez la section Présentation des stratégies de sécurité.

Accès externe pour les VM

Dans l'architecture de référence décrite dans ce document, les VM Compute Engine n'ont pas besoin d'un accès entrant depuis Internet. N'attribuez pas d'adresses IP externes aux VM. Google Cloud Les ressources ne disposant que d'une adresse IP interne privée peuvent toujours accéder à certains services et API Google à l'aide de Private Service Connect ou de l'accès privé à Google. Pour en savoir plus, consultez la section Options d'accès privé pour les services.

Pour activer les connexions sortantes sécurisées à partir des ressources Google Cloud ne disposant que d'adresses IP privées, comme les VM Compute Engine de cette architecture de référence, vous pouvez utiliser le proxy Web sécurisé ou Cloud NAT.

Droits des comptes de service

Pour les VM Compute Engine de l'architecture, au lieu d'utiliser les comptes de service par défaut, nous vous recommandons de créer des comptes de service dédiés et de spécifier les ressources auxquelles le compte de service peut accéder. Le compte de service par défaut inclut un large éventail d'autorisations qui ne sont pas nécessaires dans ce cas, alors que vous pouvez adapter les comptes de service dédiés pour qu'ils ne disposent que des autorisations requises. Pour en savoir plus, consultez Limiter les droits des comptes de service.

Sécurité SSH

Pour renforcer la sécurité des connexions SSH aux VM Compute Engine de cette architecture, implémentez le transfert Identity-Aware Proxy (IAP) avec l'API Cloud OS Login. IAP vous permet de contrôler l'accès au réseau en fonction de l'identité des utilisateurs et des stratégies IAM (Identity and Access Management). L'API Cloud OS Login vous permet de contrôler l'accès SSH Linux en fonction de l'identité de l'utilisateur et des règles IAM. Pour en savoir plus sur la gestion de l'accès au réseau, consultez Bonnes pratiques pour contrôler l'accès à la connexion SSH.

Chiffrement de disque

Par défaut, les données stockées dans les volumes Persistent Disk sont chiffrées à l'aide deGoogle-owned and Google-managed encryption keys. Pour renforcer la protection, vous pouvez choisir de chiffrer Google-owned and managed key à l'aide de clés dont vous êtes propriétaire et que vous gérez dans Cloud Key Management Service (Cloud KMS). Pour en savoir plus, consultez À propos du chiffrement des disques pour les volumes Hyperdisk et Chiffrer des données avec des clés de chiffrement gérées par le client.

Sécurité du réseau

Pour contrôler le trafic réseau entre les ressources de l'architecture, vous devez configurer des règles de pare-feu Cloud nouvelle génération (NGFW) appropriées.

Points à prendre en compte concernant la résidence des données

Vous pouvez utiliser des équilibreurs de charge régionaux pour créer une architecture multirégionale qui répond à vos exigences de résidence des données. Par exemple, un pays situé en Europe peut exiger que toutes les données utilisateur soient stockées et consultées dans des centres de données situés physiquement en Europe. Pour répondre à cette exigence, vous pouvez utiliser l'architecture basée sur l'équilibreur de charge régional. Dans cette architecture, l'application s'exécute dans les régionsGoogle Cloud en Europe et vous utilisez Cloud DNS avec une règle de routage avec géorepérage pour acheminer le trafic via des équilibreurs de charge régionaux. Afin de répondre aux exigences de résidence des données pour le niveau Base de données, utilisez une architecture segmentée plutôt que la réplication entre les régions. Avec cette approche, les données de chaque région sont isolées, mais vous ne pouvez pas mettre en œuvre la haute disponibilité et le basculement interrégionaux pour la base de données.

Autres considérations sur la sécurité

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations de sécurité au niveau de la plate-forme fournies dans le plan de base Enterprise et le Google Cloud Well-Architected Framework : sécurité, confidentialité et conformité.

Fiabilité

Cette section décrit les facteurs de conception à prendre en compte lorsque vous utilisez cette architecture de référence afin de créer et d'exploiter une infrastructure fiable pour vos déploiements multirégionaux dans Google Cloud.

Robustesse en cas de pannes d'infrastructure

Dans une architecture de déploiement multirégional, en cas de défaillance d'un composant individuel dans la pile d'infrastructure, l'application peut traiter les requêtes si au moins un composant fonctionnel disposant d'une capacité suffisante existe à chaque niveau. 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 une panne zonale se produit, l'équilibreur de charge n'est pas affecté, car il s'agit d'une ressource régionale. Une panne zonale peut affecter les VM Compute Engine individuelles. Toutefois, l'application reste disponible et réactive, car les VM se trouvent dans un MIG régional. Un MIG régional garantit que de nouvelles VM sont créées automatiquement pour conserver le nombre minimal de VM configuré. Une fois la panne de zone résolue par Google, vous devez vérifier que l'application s'exécute comme prévu dans toutes les zones où elle est déployée.

Si toutes les zones d'une région sont indisponibles ou si une panne régionale se produit, l'application de l'autre région reste disponible et réactive. L'équilibreur de charge externe global dirige le trafic vers la région qui n'est pas affectée par la panne. Une fois que Google a résolu la panne régionale, vous devez vérifier que l'application s'exécute comme prévu dans la région où la panne a eu lieu.

Si les deux régions de cette architecture présentent des pannes, l'application est indisponible. Vous devez attendre que Google résolve la panne, puis vérifier que l'application fonctionne comme prévu.

Autoscaling des MIG

Lorsque vous exécutez votre application sur plusieurs MIG régionaux, celle-ci reste disponible en cas de panne d'une zone isolée ou de panne régionale. La fonctionnalité d'autoscaling des MIG sans état vous permet de maintenir à des niveaux prévisibles la disponibilité et les performances de l'application.

Pour contrôler le comportement d'autoscaling de vos MIG sans état, 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 la planification pour les MIG sans état. Les MIG avec état ne peuvent pas faire l'objet d'un autoscaling. Pour en savoir plus, consultez la page Effectuer l'autoscaling des groupes d'instances.

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

Lorsque vous décidez de la taille de vos MIG, tenez compte des limites par défaut et maximales du nombre de VM pouvant être créées dans un MIG. Pour en savoir plus, consultez Ajouter et supprimer des VM dans un MIG.

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. L'application 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 À propos de la réparation des VM pour la haute disponibilité.

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

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 alors dans chaque zone sur des serveurs physiques distincts (appelés hôtes) afin qu'elles résistent aux défaillances des hôtes individuels. Pour en savoir plus, consultez Créer et appliquer des stratégies d'emplacement par répartition aux VM.

Planification de la capacité des VM

Pour vous assurer que la capacité des VM Compute Engine est disponible lorsque des VM doivent être provisionnées, vous pouvez créer des réservations. Une réservation garantit la capacité dans une zone spécifique pour un nombre spécifié de VM d'un type de machine que vous choisissez. Une réservation peut être spécifique à un projet ou partagée entre plusieurs projets. Pour en savoir plus sur les réservations, consultez Choisir un type de réservation.

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 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 le service Backup and DR pour créer, stocker et gérer des sauvegardes des VM Compute Engine. L'outil de sauvegarde et reprise après sinistre stocke les données de la sauvegarde dans leur format d'origine lisible par l'application. Si nécessaire, vous pouvez restaurer vos charges de travail en production en utilisant directement les données d'un stockage de sauvegarde à long terme, sans avoir à préparer ni à déplacer les données.

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

Disponibilité des bases de données

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

Types de machine des VM

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

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

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, les recommandations suivantes peuvent vous aider à réduire les coûts :

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

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 le Google Cloud Well-Architected Framework : optimisation des coûts.

Efficacité opérationnelle

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir et créer une topologie multirégionale Google Cloudque 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 VM, au lieu d'utiliser des images publiques fournies par Google, nous vous recommandons de créer et d'utiliser des images d'OS 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. Vous devez régulièrement mettre à jour 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 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 Google Cloud Framework Well-Architected : excellence opérationnelle.

Optimisation des performances

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir et créer dansGoogle Cloud une topologie multirégionale qui répond aux exigences de performances de vos charges de travail.

Performances de calcul

Compute Engine propose un large éventail de types de machines prédéfinis et personnalisables pour les charges de travail que vous exécutez sur les VM. Choisissez un type de machine adapté en fonction de vos exigences en termes de performances. Pour en savoir plus, consultez le Guide des ressources de familles de machines et guide comparatif.

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 applications qui impliquent des opérations 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 fournit le trafic sur le réseau backbone mondial de Google pour réduire au minimum la perte de paquets et la latence. Le niveau Standard distribue le trafic à l'aide de réseaux d'appairage, de fournisseurs d'accès à Internet (FAI) ou de réseaux de transit au niveau d'un point de présence (PoP) périphérique le plus proche de la région dans laquelle votre charge de travail Google Cloud s'exécute. Pour optimiser les performances, nous vous recommandons d'utiliser le niveau Premium. Pour optimiser les coûts, nous vous recommandons d'utiliser le niveau Standard.

Performances du réseau

Pour les charges de travail nécessitant une faible latence réseau entre les VM dans les niveaux d'application et Web, vous pouvez créer une règle de concentration et l'appliquer au modèle de MIG utilisé pour ces niveaux. Lorsque le MIG crée des VM, il les place alors 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 trouver l'équilibre optimal entre les performances réseau et la disponibilité, vous pouvez spécifier la distance à laquelle les VM doivent être placées lorsque vous créez une stratégie d'emplacement compact. Pour en savoir plus, consultez 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é ou non via le même réseau VPC que la VM source. Pour les VM avec certains types de machines, vous pouvez obtenir une bande passante de sortie maximale plus élevée en activant la mise en réseau Tier_1 afin d'améliorer les performances réseau.

Mise en cache

Si votre application diffuse des éléments statiques de site Web et que votre architecture inclut un équilibreur de charge d'application externe global, vous pouvez utiliser Cloud CDN pour mettre en cache à proximité de vos utilisateurs les éléments statiques consultés régulièrement. Cloud CDN peut vous aider à améliorer les performances pour vos utilisateurs, à réduire l'utilisation des ressources d'infrastructure dans le backend et à réduire vos coûts de diffusion réseau. Pour en savoir plus, consultez Performances Web plus rapides et protection Web améliorée pour l'équilibrage de charge.

Autres considérations sur les performances

Lorsque vous créez l'architecture pour votre charge de travail, tenez compte des bonnes pratiques et des recommandations générales fournies dans le Google Cloud Framework Well-Architected : optimisation des performances.

Étapes suivantes

Contributeurs

Auteurs :

Autres contributeurs :