Régions et zones

Les ressources Compute Engine sont hébergées à plusieurs emplacements dans le monde. Ces emplacements sont organisés en régions et en zones. Une région est une aire géographique spécifique au sein de laquelle vous pouvez héberger vos ressources. Chaque région possède une ou plusieurs zones et la plupart des régions en comptent au moins trois. Par exemple, la région us-west1 représente une région de la côte ouest des États-Unis comportant trois zones : us-west1-a, us-west1-b et us-west1-c.

Les ressources contenues dans une zone, telles que les instances de machines virtuelles ou les disques persistants zonaux, sont des ressources dites "zonales". D'autres ressources, telles que les adresses IP statiques externes, sont régionales. Les ressources régionales peuvent être utilisées par toutes les ressources de cette région, quelle que soit la zone, tandis que les ressources zonales ne peuvent être utilisées que par d'autres ressources de la même zone.

Par exemple, pour associer un disque persistant zonal à une instance, les deux ressources doivent se trouver dans la même zone. De même, si vous souhaitez attribuer une adresse IP statique à une instance, celle-ci doit se trouver dans la même région que l'adresse IP statique.

Le positionnement des ressources dans différentes zones d'une région les protège de nombreux types de pannes : pannes d'infrastructure, pannes matérielles et pannes logicielles. Le positionnement des ressources dans différentes régions offre un degré encore plus élevé d'indépendance en cas de panne. Vous pouvez ainsi concevoir des systèmes robustes dont les ressources sont réparties sur différents domaines de défaillance.

Seules certaines ressources sont propres à une région ou à une zone. Les autres ressources, telles que les images, sont des ressources globales pouvant être utilisées par toutes les autres ressources sur tous les sites. Pour plus d'informations sur les ressources Compute Engine globales, régionales et zonales, consultez la page relative aux ressources globales, régionales et zonales.

Zones et clusters

Compute Engine met en œuvre une couche d'abstraction entre les zones et les clusters physiques où sont hébergées les zones. Un cluster représente une infrastructure physique distincte, hébergée dans un centre de données. Chaque cluster possède une infrastructure logicielle et une infrastructure d'alimentation, de refroidissement, de réseau et de sécurité indépendantes, et comprend un vaste ensemble de ressources de calcul et de stockage.

Chaque zone est hébergée au sein d'un ou plusieurs clusters et Compute Engine mappe indépendamment les zones avec des clusters pour chaque organisation. Par exemple, la zone us-central1-a de votre organisation peut ne pas correspondre au même cluster que la zone us-central1-a d'une autre organisation.

Le découplage des zones et clusters présente de nombreux avantages aussi bien pour vous que pour Compute Engine :

  • Cela permet à Compute Engine de s'assurer que les ressources sont équilibrées entre les clusters d'une région.
  • La liste des zones disponibles reste gérable, car Compute Engine continue de développer ses régions au fil du temps en ajoutant de nouveaux clusters.

Pour la plupart des organisations, Compute Engine veille à maintenir la cohérence au niveau de la correspondance entre zone et cluster pour tous les projets d'une même organisation. Pour les organisations utilisant l'appairage de réseaux VPC ou l'accès aux services privés afin de partager des réseaux ou des services avec d'autres organisations, Compute Engine s'efforce de vérifier la cohérence du mappage entre zone et cluster pour les organisations appairées. Dans le cas de fournisseurs SaaS à grande échelle, par exemple, il n'est pas toujours possible à Compute Engine de fournir un mappage cohérent pour l'ensemble des organisations appairées. Dans de tels cas, Compute Engine s'assure que le mappage entre zone et cluster reste cohérent pour les projets appairés.

Zones

Le tableau suivant décrit les emplacements de toutes les régions Compute Engine et les zones qui leur sont associées. Reportez-vous à la section Régions et zones disponibles pour obtenir une description complète des types de machines et des fonctionnalités disponibles dans chaque zone.

Région Zones Localisation
asia-east1 a, b, c Comté de Changhua, Taïwan
asia-east2 a, b, c Hong Kong
asia-northeast1 a, b, c Tokyo, Japon
asia-northeast2 a, b, c Osaka, Japon
asia-south1 a, b, c Mumbai, Inde
asia-southeast1 a, b, c Jurong West, Singapour
australia-southeast1 a, b, c Sydney, Australie
europe-north1 a, b, c Hamina, Finlande
europe-west1 b, c, d Saint-Ghislain, Belgique
europe-west2 a, b, c Londres, Angleterre, Royaume-Uni
europe-west3 a, b, c Francfort, Allemagne
europe-west4 a, b, c Eemshaven, Pays-Bas
europe-west6 a, b, c Zurich, Suisse
northamerica-northeast1 a, b, c Montréal, Québec, Canada
southamerica-east1 a, b, c Osasco (São Paulo), Brésil
us-central1 a, b, c, f Council Bluffs, Iowa, États-Unis
us-east1 b, c, d Moncks Corner, Caroline du Sud, États-Unis
us-east4 a, b, c Ashburn, Virginie du Nord, États-Unis
us-west1 a, b, c The Dalles, Oregon, États-Unis
us-west2 a, b, c Los Angeles, Californie, États-Unis

Choisir une région et une zone

Vous choisissez la région ou la zone qui héberge vos ressources, ce qui vous permet de contrôler l'endroit où vos données sont stockées et utilisées. Le choix d'une région et d'une zone est important pour plusieurs raisons :

Gestion des pannes
Répartissez vos ressources sur plusieurs zones et régions pour permettre la tolérance aux interruptions. Google conçoit les zones afin qu'elles soient indépendantes les unes des autres : les plans d'alimentation, de refroidissement, de mise en réseau et de contrôle d'une zone sont isolés des autres zones, et la plupart des événements de défaillance uniques n'affectent qu'une seule zone. Ainsi, si une zone devient indisponible, vous pouvez transférer le trafic vers une autre zone de la même région pour que vos services continuent de fonctionner. De même, si une région subit des perturbations, vous devez disposer de services de secours exécutés dans une autre région. Pour plus d'informations sur la répartition de vos ressources et la conception d'un système robuste, consultez la page Concevoir des systèmes robustes.
Diminution de la latence du réseau
Pour réduire la latence du réseau, vous pouvez choisir une région ou une zone proche de votre point de service. Par exemple, si vos clients se trouvent principalement sur la côte est des États-Unis, vous pouvez choisir une région et une zone principales à proximité, ainsi qu'une région et une zone de secours également proches.

Identifier une région ou une zone

Chaque région de Compute Engine contient un certain nombre de zones. Chaque nom de zone se compose de deux parties décrivant la zone en détail. La première partie du nom de la zone est la région et la seconde partie du nom décrit la zone de la région :

  • Région

    Les régions sont des ensembles de zones. Les zones d'une même région bénéficient entre elles de connexions réseau à haut débit et à faible latence. Afin de déployer des applications tolérantes aux pannes et à haute disponibilité, Google recommande un déploiement sur plusieurs zones et plusieurs régions. Vous vous protégez ainsi contre les défaillances imprévues des composants, y compris dans une zone ou une région donnée.

    Choisissez les régions qui conviennent à votre situation. Par exemple, si l'intégralité de vos clients se trouve aux États-Unis ou si vous avez des besoins spécifiques qui nécessitent que vos données soient hébergées aux États-Unis, il est judicieux de stocker vos ressources dans des zones de la région us-central1 ou us-east1.

  • Zone

    Une zone est un emplacement isolé dans une région. Le nom complet d'une zone est au format <region>-<zone>. Par exemple, le nom complet de la zone a dans la région us-central1 est us-central1-a.

    Selon l'étendue que vous souhaitez donner à la répartition de vos ressources, créez des instances sur plusieurs zones dans plusieurs régions à des fins de redondance.

Régions et zones disponibles

Le tableau suivant répertorie les régions et leur emplacement, ainsi que les zones et fonctionnalités disponibles dans chaque région.

Chaque zone est compatible avec une combinaison de plates-formes Ivy Bridge, Sandy Bridge, Haswell, Broadwell et Skylake. Lorsque vous créez une instance dans la zone, l'instance utilise le processeur par défaut disponible dans cette zone. Par exemple, si vous créez une instance dans la zone us-central1-a, l'instance utilise un processeur Sandy Bridge.

Vous pouvez également choisir la plate-forme de processeur si vous le souhaitez. Pour plus d'informations, consultez la page Spécifier une configuration minimum de la plate-forme du processeur pour les instances de VM.

Nom de la région Description de la région Localisation Zones Fonctionnalités
asia-east1 Taïwan Comté de Changhua, Taïwan asia-east1-a
asia-east1-b
asia-east1-c
asia-east2 Hong Kong Hong Kong
  • asia-east2-a
  • asia-east2-b
  • asia-east2-c
asia-northeast1 Tokyo Tokyo, Japon asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-northeast2 Osaka Osaka, Japon
  • asia-northeast2-a
  • asia-northeast2-b
  • asia-northeast2-c
asia-south1 Mumbai Mumbai, Inde
  • asia-south1-a
  • asia-south1-c
asia-south1-b
asia-southeast1 Singapour Jurong West, Singapour
  • asia-southeast1-a
  • asia-southeast1-b
  • asia-southeast1-c
australia-southeast1 Sydney Sydney, Australie
  • australia-southeast1-a
  • australia-southeast1-b
  • australia-southeast1-c
europe-north1 Finlande Hamina, Finlande
  • europe-north1-a
  • europe-north1-b
  • europe-north1-c
europe-west1 Belgique Saint-Ghislain, Belgique europe-west1-b
europe-west1-c
europe-west1-d
europe-west2 Londres Londres, Angleterre, Royaume-Uni
  • europe-west2-a
  • europe-west2-c
europe-west2-b
europe-west3 Francfort Francfort, Allemagne
  • europe-west3-a
  • europe-west3-b
    europe-west3-c
europe-west4 Pays-Bas Eemshaven, Pays-Bas
  • europe-west4-a
  • europe-west4-b
  • europe-west4-c
europe-west6 Zurich Zurich, Suisse
  • europe-west6-a
  • europe-west6-b
  • europe-west6-c
northamerica-northeast1 Montréal Montréal, Québec, Canada
  • northamerica-northeast1-a
  • northamerica-northeast1-b
  • northamerica-northeast1-c
southamerica-east1 Osasco Osasco, São Paulo, Brésil
  • southamerica-east1-a
southamerica-east1-b
southamerica-east1-c
us-central1 Iowa Council Bluffs, Iowa, États-Unis us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-east1 Caroline du Sud Moncks Corner, Caroline du Sud, États-Unis us-east1-b
    us-east1-c
    us-east1-d
us-east4 Virginie du Nord Ashburn, Virginie, États-Unis
  • us-east4-a
  • us-east4-b
  • us-east4-c
us-west1 Oregon The Dalles, Oregon, États-Unis us-west1-a
us-west1-b
us-west1-c
us-west2 Los Angeles Los Angeles, Californie, États-Unis us-west2-a
us-west2-b
us-west2-c

Régions annoncées

En 2019 et 2020, Google continuera à se développer dans les nouvelles régions suivantes :

Maintenance transparente

Google assure une maintenance régulière de son infrastructure en appliquant les logiciels correctifs les plus récents sur ses systèmes, en effectuant des tests de routine et de la maintenance préventive, et en s’assurant de façon générale que la rapidité et l'efficacité de l’infrastructure Google correspond au savoir-faire unique de Google.

Par défaut, toutes les instances sont configurées pour que ces événements de maintenance soient transparents pour vos applications et vos charges de travail. Google utilise une combinaison d’innovations sur le centre de données, de bonnes pratiques opérationnelles et de technologies de migration à chaud pour déplacer les instances de machines virtuelles en cours d’exécution sans interférer avec la maintenance. Votre instance poursuit son exécution dans la même zone sans aucune action de votre part.

Par défaut, toutes les machines virtuelles sont configurées pour une migration à chaud, mais vous pouvez également configurer vos machines virtuelles pour qu'elles s'arrêtent et redémarrent. Voici les différences entre les deux méthodes :

  • Migrer à chaud

    Compute Engine migre automatiquement votre instance en cours d'exécution. Le processus de migration a un certain impact sur les performances des clients, mais votre instance reste en ligne tout au long du processus. L'impact sur les performances et la durée dépendent de nombreux facteurs, mais la plupart des applications et des charges de travail ne subissent aucun effet. Pour en savoir plus, consultez la section Migrer à chaud.

  • Arrêter et redémarrer

    Compute Engine signale automatiquement à votre instance de s'arrêter, attend un instant pour veiller à un arrêt correct, puis redémarre l'instance en dehors de l'événement de maintenance.

Pour plus d'informations sur la définition des options ci-dessus pour vos instances, consultez la page Définir les options de programmation de l'instance.

Obsolescence de zones

Il n'est jamais nécessaire de mettre hors service une zone existante en cas d'actualisation complète de l'infrastructure (alimentation, refroidissement, matrice réseau, serveurs, etc.). Les actualisations d'infrastructure sont rares, et les zones sont généralement actives pendant trois à cinq ans entre les actualisations. Ces actualisations doivent être transparentes pour les clients.

S'il devient nécessaire de rendre une zone obsolète, Compute Engine en informera les utilisateurs bien avant la déconnexion de la zone. Vous aurez ainsi un délai suffisant pour déplacer vos charges de travail et instances de machines virtuelles.

Quota

Certaines ressources, telles que les adresses IP statiques, les images, les règles de pare-feu et les réseaux VPC, disposent de limites de quota à l'échelle du projet et par région. Lorsque vous créez ces ressources, elles sont prises en compte dans le quota total du projet ou dans votre quota par région, le cas échéant. Si l'une des limites de quota concernées est dépassée, vous ne pourrez pas ajouter d'autres ressources du même type dans ce projet ou cette région.

Pour afficher la liste complète des quotas appliqués à votre projet, consultez la page Quotas dans la console Google Cloud Platform.

Par exemple, si votre quota global de pools cibles est de 50 et que vous créez 25 pools cibles dans la région example-region-1 et 25 dans la région example-region-2, vous atteignez le quota global à l'échelle du projet et ne pouvez plus créer de pools cibles dans une région de votre projet tant que vous ne libérez pas d'espace. De même, si un quota par région de sept adresses IP réservées s'applique, vous ne pouvez réserver que sept adresses IP maximum dans une région donnée. Une fois cette limite atteinte, vous devez soit réserver des adresses IP dans une nouvelle région, soit libérer des adresses IP.

Astuces

Lors de la sélection des zones, gardez à l'esprit les points suivants :

  • La communication dans et entre les régions entraîne des coûts différents.

    En règle générale, la communication au sein d'une région est toujours moins chère et plus rapide que la communication entre régions.

  • Concevez des systèmes importants avec redondance dans plusieurs zones.

    À un moment donné, il est possible que vos instances subissent une défaillance inattendue. Pour atténuer les effets de ces événements potentiels, vous devez dupliquer les systèmes importants dans plusieurs zones et régions.

    Par exemple, si vous hébergez des instances dans les zones europe-west1-b et europe-west1-c, en cas de panne inattendue de la zone europe-west1-b, vos instances dans la zone europe-west1-c restent disponibles. Cependant, si vous hébergez toutes vos instances dans la zone europe-west1-b, vous ne pourrez accéder à aucune instance si la zone europe-west1-b est déconnectée. Vous devriez également envisager d’héberger vos ressources dans plusieurs régions. Par exemple, dans l'hypothèse peu probable d'une défaillance de la région europe-west1, envisagez d'héberger des instances de sauvegarde dans une zone de la région europe-west3. Pour plus de conseils sur la conception de systèmes à des fins de disponibilité, consultez la page Concevoir des systèmes robustes.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine