Zones géographiques et régions

Les produits Google Cloud sont diffusés à partir de domaines de défaillance régionaux spécifiques et sont entièrement couverts par les contrats de niveau de service afin de vous assurer que vous concevez votre architecture d'application au sein de la structure de Google Cloud.

Les services Google Cloud sont disponibles à différents emplacements en Amérique du Nord, en Amérique du Sud, en Europe, en Asie et en Australie. Ces emplacements sont organisés en régions et en zones. Vous pouvez choisir l'emplacement souhaité pour vos applications en fonction de vos critères de latence, de disponibilité et de durabilité.

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Essai gratuit

Régions et zones

Les régions correspondent à des espaces géographiques indépendants qui sont constitués de zones. Les zones et les régions sont des abstractions logiques des ressources physiques sous-jacentes fournies dans un ou plusieurs centres de données physiques. Ces centres de données peuvent appartenir à Google et être répertoriés sur la page Emplacement des centres de données Google. Ils peuvent également être loués auprès de fournisseurs tiers de centres de données. Vous pouvez également consulter la liste complète des emplacements des centres de données pour Google Cloud dans notre certificat ISO/IEC 27001. Que le centre de données soit acheté ou loué, Google Cloud sélectionne les centres de données et conçoit son infrastructure pour offrir un niveau uniforme de performances, de sécurité et de fiabilité.

Les zones servent au déploiement des ressources Google Cloud dans une région. Elles doivent être considérées comme un domaine de défaillance unique au sein d'une région. Pour déployer des applications tolérantes aux pannes et à haute disponibilité, et être mieux protégé contre les défaillances inattendues, déployez vos applications sur plusieurs zones d'une région.

Pour empêcher la perte d'une région entière à la suite d'une catastrophe naturelle, vous devez disposer d'un plan de reprise après sinistre et savoir comment remettre en service votre application dans le cas peu probable de la perte de votre région principale. Pour en savoir plus, consultez la section Remarques relatives au déploiement d'applications.

Pour plus d'informations sur les ressources spécifiques qui sont disponibles dans chaque option d'emplacement, consultez la page Emplacements Cloud.

Les services et ressources Google Cloud peuvent être zonaux, régionaux, ou gérés par Google dans plusieurs régions. Pour en savoir plus sur l'incidence que ces options peuvent avoir sur vos données, consultez la section Gestion géographique des données.

Ressources zonales

Les ressources zonales sont disponibles dans une seule zone. Les interruptions zonales peuvent affecter une partie ou l'ensemble des ressources de cette zone. Une instance de machine virtuelle (VM) Compute Engine résidant dans une zone spécifique est un exemple de ressource zonale.

Ressources régionales

Les ressources régionales sont déployées de façon redondante dans plusieurs zones d'une région. Il peut s'agir par exemple d'applications App Engine ou de groupes d'instances gérés régionaux. Elles offrent ainsi une disponibilité plus élevée que les ressources zonales.

Ressources multirégionales

Plusieurs services Google Cloud sont gérés par Google pour être redondants et distribués dans et entre les régions. Ils contribuent à optimiser la disponibilité, les performances et l'efficacité des ressources. Par conséquent, ces services requièrent des compromis entre la latence et le modèle de cohérence. Ces compromis sont documentés en fonction de chaque produit.

Les services suivants sont associés à un ou plusieurs emplacements multirégionaux, en plus des emplacements régionaux :

  • BigQuery
  • Bigtable
  • Cloud DLP
  • API Cloud Healthcare
  • Cloud Key Management Service
  • Spanner
  • Cloud Storage
  • Database Migration Service
  • Datastore
  • Firestore

Ces services multirégionaux sont conçus pour fonctionner à la suite de la perte d'une seule région.

La documentation publique de Google Cloud répertorie les configurations et les options exactes de chaque produit dans les régions et les zones.

Services internationaux

Google Cloud a été entièrement conçu pour fonctionner dans le monde entier. Il effectue constamment des opérations de maintenance et des mises à niveau 24h/24, 7j/7 et 365 jours par an sans vous déranger. Notre réseau backbone mondial offre une flexibilité exceptionnelle en termes d'équilibrage de charge, et réduit la latence des utilisateurs finaux en établissant des interconnexions plus proches de vous. Notre plan global de gestion cloud simplifie la gestion des développements multirégionaux.

Services internes

L'intégration et la compatibilité de nombreux services Google Cloud destinés aux clients constituent un ensemble de services internes éprouvés tels que Spanner, Colossus, Borg et Chubby.

Ces services internes sont soit équilibrés en charge dans plusieurs régions, soit dédiés à chaque région dans laquelle ils sont disponibles. Lorsque les services sont équilibrés en charge dans plusieurs régions, nous déployons les mises à jour progressivement d'une région à l'autre, ce qui nous permet de détecter et de résoudre les problèmes sans affecter l'utilisation de votre service. Aucun de ces services internes n'est limité à un seul centre de données logique ou à une seule région.

Les services internes globaux peuvent s'exécuter ou être répliqués dans les régions cloud suivantes :

Amériques

  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-west1
  • us-west4

Europe

  • europe-north1
  • europe-west1
  • europe-west4

Asie

  • asia-east1
  • asia-southeast1

Dépendances de services

En général, pour les services Google Cloud, si une région tombe en panne, seuls les clients de cette région sont affectés. Les clients disposant de produits multirégionaux ne sont pas affectés. Google Cloud dispose d'une architecture conséquente dans le but d'éviter les pannes corrélées entre les régions.

Tous les services Google Cloud s'appuient sur des outils internes essentiels permettant de fournir des services fondamentaux tels que la mise en réseau (entrée et sortie des centres de données), l'accès aux centres de données et les systèmes d'autorisation d'identité. Ces outils sont résilients aux pannes régionales, l'objectif étant qu'une région ne soit pas touchée si d'autres régions sont indisponibles.

Google Cloud fournit des instructions claires sur la façon dont les clients peuvent concevoir leurs applications pour le niveau de résilience souhaité sur notre site Web public, en particulier pour les produits Google Cloud couramment utilisés tels que Compute Engine, BigQuery, Pub/Sub et d'autres services.

Nos principales dépendances sont répertoriées ci-dessous, en commençant par celles qui sont communes à tous les services. Notez que les détails de mise en œuvre de niveau inférieur sont susceptibles d'être modifiés.

Dépendances communes à tous les services

  • Plan de données d'identité pour l'authentification et l'autorisation
  • Services internes de journalisation, de stockage de métadonnées et de gestion des workflows
  • L'accès aux API Google Cloud dépend du DNS, des équilibreurs de charge distribués à l'échelle mondiale et des points de présence.
  • Configuration des ressources globales : par exemple, les stratégies IAM, les règles de pare-feu globales, les configurations globales d'équilibreur de charge et les sujets Pub/Sub sont stockés dans des bases de données répliquées.
  • Lorsque les services Google Cloud envoient des requêtes à des points de terminaison contrôlés par le client (par exemple, en récupérant les clés client Cloud EKM ou via Pub/Sub en diffusant des messages), ces requêtes dépendent de notre infrastructure réseau mondiale pour accéder à ces points de terminaison contrôlés par le client.

Informations supplémentaires sur les dépendances

  • Services Compute Engine
    • Les plans de données de la VM et du disque persistant Google Cloud dépendent de services Compute Engine et Cloud Storage de niveau inférieur tels que Borg et Colossus.
  • Les services de stockage de Google Cloud et d'infrastructure tels que Spanner, Bigtable et Cloud Storage dépendent des éléments suivants :
    • Chiffrement et infrastructure de gestion des clés pour le client (Cloud KMS / Cloud EKM) et infrastructure interne pour les clés appartenant à Google
    • Services internes de journalisation et d'audit de l'accès aux données
    • Services de réplication de données internes, dans les cas où les données sont censées être disponibles dans plusieurs régions
    • Les sauvegardes configurées explicitement et la réplication des autres régions dépendent du réseau interrégional
  • Services de messagerie
    • Pub/Sub dépend de notre infrastructure réseau mondiale pour accéder aux points de terminaison contrôlés par le client
  • Services de mise en réseau
    • L'équilibrage de charge au niveau mondial, le DNS et le basculement entre les régions dépendent tous d'une infrastructure de mise en réseau physique.
    • La prévention des attaques DDos, et d'autres attaques similaires, dépend d'une infrastructure Compute Engine de niveau inférieur.
  • Services gérés et hébergés tels que GKE et Cloud SQL
    • Dépendent de Compute Engine et de Container Registry ou Artifact Registry pour les images de VM.
  • Infrastructure de niveau inférieur autonome
    • Notre plan de contrôle interne au niveau du cluster, notamment Borg et les structures réseau
    • Stockage au niveau du cluster, tel que Colossus
    • Infrastructure de chiffrement et de gestion des clés

Gérer et améliorer la disponibilité et la résilience

L'ingénierie en fiabilité des sites (SRE) constitue l'organisation interne de Google dédiée à la disponibilité, à la latence, aux performances et à la capacité. Les pannes et l'indisponibilité d'un service sont corrélées au déploiement d'un nouveau code ou aux modifications apportées à l'environnement. En appliquant les bonnes pratiques du secteur, l'ingénierie SRE assure un juste équilibre entre la nécessité de publier de nouveaux logiciels et la sécurité de l'environnement en ayant conscience que ces modifications nécessaires peuvent provoquer un temps d'arrêt.

Collaborer avec les clients pour créer des services résilients

Si vous avez des besoins critiques en ce qui concerne l'architecture pour la résilience et la reprise après sinistre, nos équipes SRE/CRE et PSO peuvent vous aider à concevoir vos applications pour qu'elles relient plusieurs régions et zones, et à concevoir des systèmes à haute disponibilité.

Si vous avez des exigences de disponibilité plus importantes à des dates spécifiques (par exemple, au moment du Black Friday ou du Cyber Monday), Google Cloud dispose d'un programme qui vous aide à examiner et à valider votre application spécifique exécutée dans GCP, et à identifier toutes les dépendances de services entre votre application et nos services.

Gestion géographique des données

Pour les services Google Cloud, la localité des données est régie par les Conditions d'utilisation, y compris les Conditions spécifiques du service. Nous sommes conscients que chaque client est susceptible d'avoir des exigences spécifiques en termes de sécurité et de conformité. L'équipe commerciale de Google Cloud peut vous aider à répondre à vos besoins.

Lorsque vous utilisez des ressources de stockage régionales ou zonales, nous vous recommandons vivement de répliquer les données dans une autre région ou de créer un instantané de ces données dans une ressource de stockage multirégionale en vue d'une reprise après sinistre.

Remarques relatives au déploiement d'applications

Création de services et d'applications à disponibilité élevée pouvant supporter des défaillances de zones

Utilisez les ressources suivantes :

Création d'applications pouvant faire l'objet d'une reprise après sinistre et capables de supporter la perte prolongée de régions entières

Pour les données, adoptez une ou plusieurs des stratégies suivantes :

  • Utilisez des services de stockage multirégionaux gérés, tels que Cloud Storage, Datastore, Firestore ou Spanner.
  • Utilisez des ressources zonales ou régionales, mais créez un instantané des données dans une ressource multirégionale, telle que Cloud Storage, Datastore, Firestore ou Spanner.
  • Utilisez des ressources zonales ou régionales, mais gérez votre propre processus de réplication des données dans une ou plusieurs autres régions.

Pour les ressources de calcul, adoptez la stratégie suivante :

  • Utilisez des ressources zonales ou régionales, telles que Compute Engine ou App Engine, mais remettez en service, de façon manuelle ou automatique, votre application dans une autre région (en cas de défaillance régionale) à partir de copies des données principales si celles-ci ne se trouvent pas déjà dans une ressource multirégionale gérée.

Pour plus d'informations sur les dépendances de service, contactez le service commercial.

Autres solutions et tutoriels

Les solutions et tutoriels ci-dessous vous aident à garantir la haute disponibilité de votre application et à supporter les interruptions de service.

Modèles d'applications évolutives et résilientes

Apprenez à utiliser Google Cloud afin de créer des architectures d'applications évolutives et résilientes à l'aide de modèles et de bonnes pratiques largement applicables à toute application Web.

Créer un équilibreur de charge HTTPS

Configurez des instances Compute Engine dans différentes régions et utilisez l'équilibrage de charge HTTP pour distribuer le trafic entre ces dernières. Vous pouvez ainsi améliorer la disponibilité dans les différentes régions et permettre le basculement en cas d'interruption de service.

Concevoir des systèmes robustes

Concevez votre application sur le service Compute Engine afin qu'elle résiste aux défaillances, aux interruptions de réseau et aux catastrophes inattendues.

Utiliser le script de sauvegarde/restauration Cassandra avec Cloud Storage

Découvrez comment ajouter une fonctionnalité élémentaire de reprise après sinistre à votre installation Cassandra en utilisant Cloud Storage pour sauvegarder et restaurer vos données.

Guide de planification de reprise après sinistre

Cet article présente les principes généraux à suivre pour concevoir et tester un plan de reprise après sinistre avec Google Cloud.