Ce document explique la virtualisation des zones, la méthode utilisée par Google pour mapper les zones publiques à des clusters de matériel physique interne au sein de nos centres de données. La virtualisation des zones nous permet de développer facilement nos zones, de mettre à niveau le matériel et de mettre hors service une infrastructure physique sans impact sur les clients. Consultez cette rubrique si vos applications sont réparties sur plusieurs projets et si vous souhaitez savoir comment Google répartit ses zones sur une infrastructure physique.
Les ressources Google Cloud sont hébergées dans plusieurs régions à travers le monde. 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. Une région comprend au moins trois zones hébergées dans au moins trois centres de données physiques. Les régions Mexico, Montréal et Osaka comportent trois zones hébergées dans un ou deux centres de données physiques. Ces régions sont en cours d'extension à au moins trois centres de données physiques. Lorsque vous concevez vos solutions dans Google Cloud, tenez compte des conseils fournis dans les sections Zones Cloud, Contrats de niveau de service Google Cloud Platform et Documentation produit Google Cloud appropriées.
En plaçant vos ressources dans plusieurs zones d'une région, vous réduisez le risque de défaillances corrélées de l'infrastructure physique et logicielle qui affectent vos applications. Le positionnement des ressources dans différentes régions offre un degré encore plus élevé d'indépendance en cas de panne.
Pour obtenir la liste des emplacements géographiques Google Cloud, consultez la page Régions et zones. Pour en savoir plus sur la création d'applications résilientes, consultez la série de solutions Google Cloud sur la planification de reprise après sinistre.
Clusters
L'ensemble du matériel Google Cloud est organisé en clusters. Un cluster représente un ensemble de ressources de calcul, de réseau et de stockage compatibles avec la création, l'alimentation et le refroidissement de l'infrastructure. Les composants d'infrastructure acceptent généralement un seul cluster, ce qui garantit que les clusters partagent peu de dépendances.
Figure 1 : La région asia-east1 comporte trois zones. Chaque zone possède son propre cluster avec des ressources individuelles.
Toutefois, les composants présentant une fiabilité hautement démontrée et une redondance en aval peuvent être partagés entre les clusters. Par exemple, plusieurs clusters partagent généralement une sous-station électrique. En effet, les sous-stations sont extrêmement fiables et les clusters utilisent des systèmes d'alimentation redondants. Google Cloud conçoit son infrastructure physique de manière à assurer la compatibilité avec les contrats de niveau de service et les objectifs de niveau de service (SLO) des services Google Cloud.
Mappage de zone à cluster
Lorsqu'un projet utilise une région pour la première fois, Google Cloud sélectionne un cluster unique pour chaque zone de la région qui est le cluster par défaut pour les ressources zonales de ce projet. Toutefois, des contraintes matérielles peuvent entraîner l'utilisation de clusters supplémentaires pour cette zone. Cette sélection est appelée mappage de zone à cluster. Les mappages de zone à cluster sont sélectionnés par projet pour que chaque client bénéficie des mêmes fonctionnalités et performances. Dans un projet, le mappage entre une zone logique et un cluster physique est cohérent, mais un autre projet peut avoir un mappage zone à cluster complètement différent en fonction des ressources zonales du projet. Un projet n'a jamais deux zones mappées sur le même cluster physique.
Vous pouvez aligner les mappages zone à cluster entre les projets à l'aide des réseaux VPC (Virtual Private Cloud). Google Cloud tente d'attribuer le même mappage de zone à cluster à tous les projets partageant un réseau VPC. L'utilisation de mappages de zone à cluster cohérents entre vos projets peut être souhaitable pour les défaillances de composants d'application atomiques et prévisibles.
Zones virtualisées
À mesure que les régions se développent, chaque zone est prise en charge par plusieurs clusters. Notre objectif est de regrouper les clusters avec une infrastructure partagée, telle qu'une infrastructure de bâtiment ou de refroidissement, dans des zones logiques afin que les défaillances d'infrastructure partagée n'affectent qu'une seule zone d'une région.
Figure 2 Deux des trois zones de asia-east1 ont été développées et possèdent maintenant deux clusters.
Les charges de travail client sont gérées dans le plus petit nombre possible de clusters. Généralement, votre charge de travail zonale est contenue dans un seul cluster. Toutefois, les mappages zone à cluster peuvent inclure des clusters supplémentaires dans les cas où une capacité supplémentaire ou du matériel spécialisé n'est pas disponible dans le cluster principal pour la carte.
La Figure 3 montre un diagramme du mappage zone à cluster pour deux projets :
- Project Fizz a deux clusters mappés à
asia-east1-a, car seul le cluster z est compatible avec les charges de travail GPU, et seul le cluster y est compatible avec les charges de travail TPU. - Project Fizz et Project Buzz ont des clusters distincts mappés sur
asia-east1-b.
Bien que le mappage entre zones change rarement, les modifications ont lieu à mesure que les besoins en capacité et les offres matérielles sous-jacentes évoluent. Par exemple, les clusters sont ajoutés à une zone pour augmenter la capacité et sont supprimés d'une zone lorsqu'ils sont hors service. Lors d'un événement de maintenance, Google tente de limiter votre temps d'arrêt en utilisant la migration à chaud si possible.
En cas de panne du cluster, la zone logique associée à ce cluster est signalée comme ayant une panne dans le tableau de bord d'état de Google Cloud, mais pas toutes les ressources client sont affectées, car la zone peut être composée de plusieurs clusters. Par conséquent, certains clients peuvent ne pas être affectés par une seule panne de cluster. Nous vous encourageons vivement à adopter des architectures multizones pour minimiser l'impact des pannes.
Réseaux partagés et zones virtualisées
Les réseaux de cloud privé virtuel (VPC) sont des réseaux virtualisés qui fournissent la connectivité entre les ressources d'un projet. Plusieurs projets peuvent partager un réseau VPC pour permettre la connectivité entre projets, et une organisation peut appairer un réseau VPC partagé pour activer la connectivité organisationnelle. Notre algorithme de mappage de virtualisation de zone tente d'attribuer le même mappage de zone à cluster à tous les projets partageant un réseau VPC, ou d'étendre leur réseau VPC via l'appairage de VPC. Cela est valable même lorsque les projets se trouvent dans des organisations Google Cloud différentes. À mesure que la complexité du réseau augmente avec le nombre de projets et de VPC, il devient plus difficile de maintenir un mappage cohérent entre les zones et ne peut donc pas être garanti.
Étape suivante
- Explorez les ressources globales, régionales et zonales.
- Découvrez-en plus sur la situation géographique et les zones.