Les services d'infrastructure Google Cloud sont exécutés dans le monde entier. Les emplacements sont divisés en domaines de défaillance appelés régions et zones, qui constituent les éléments de base permettant de concevoir une infrastructure fiable pour vos charges de travail cloud.
Un domaine de défaillance est une ressource ou un groupe de ressources qui peuvent échouer indépendamment des autres ressources. Une VM Compute Engine autonome est un exemple de ressource qui constitue un domaine de défaillance. Une région ou une zone Google Cloud est un exemple de domaine de défaillance constitué d'un groupe de ressources. Lorsqu'une application est distribuée de manière redondante entre les domaines de défaillance, elle peut atteindre un niveau de disponibilité agrégé plus élevé que celui fourni par chaque domaine de défaillance.
Cette partie du guide de fiabilité de l'infrastructure Google Cloud décrit les composants fondamentaux de la fiabilité dans Google Cloud et leur impact sur la disponibilité de vos ressources cloud.
Régions et zones
Les régions Google Cloud sont des emplacements géographiques indépendants. Chaque région Google Cloud contient plusieurs zones. Une défaillance dans une zone a peu de chances d'affecter l'infrastructure des autres zones. Le réseau backbone mondial fournit une connectivité à haut débit et à faible latence dans toutes les zones et régions Google Cloud.
Disponibilité de la plate-forme
L'infrastructure Google Cloud est conçue pour tolérer et permettre la récupération après une défaillance. Google investit continuellement dans des approches innovantes pour maintenir et améliorer la fiabilité de Google Cloud. Les fonctionnalités d'infrastructure Google Cloud suivantes fournissent une plate-forme fiable pour vos charges de travail dans le cloud :
- Répartition des zones géographiques pour atténuer les effets des catastrophes naturelles et des pannes régionales sur les services mondiaux.
- Redondance matérielle et réplication pour éviter les points de défaillance uniques.
- Migration à chaud des ressources lors des événements de maintenance Par exemple, lors de la maintenance planifiée de l'infrastructure, les VM Compute Engine peuvent être déplacées vers un autre hôte de la même zone à l'aide de la migration à chaud.
- Une base d'infrastructure sécurisée pour l'infrastructure physique et logicielle sur laquelle Google Cloud s'exécute, et des contrôles de sécurité opérationnels pour protéger vos données et vos charges de travail. Pour en savoir plus, consultez la présentation de la sécurité sur l'infrastructure Google.
- Un réseau backbone hautes performances qui utilise une approche avancée de réseau défini par logiciel (SDN) pour la gestion de réseau, avec des services de mise en cache périphérique, pour offrir des performances constantes et évolutives.
- Une surveillance et des rapports continus. Vous pouvez afficher l'état des services Google Cloud à chaque emplacement à l'aide du tableau de bord Service Health de Google Cloud.
- Des événements test de reprise après sinistre (DiRT) annuels à l'échelle de l'entreprise pour garantir le fonctionnement des services Google Cloud et des opérations commerciales internes en cas de sinistre.
L'infrastructure Google Cloud est conçue pour prendre en charge les niveaux de disponibilité cibles suivants pour la plupart des charges de travail des clients :
| Emplacement du déploiement | Pourcentage de disponibilité (temps d'activité) | Temps d'arrêt maximal estimé |
|---|---|---|
| Zone unique | 3 chiffres neuf : 99,9 % | 43,2 minutes au cours d'un mois de 30 jours |
| Plusieurs zones d'une région | 4 chiffres neuf : 99,99 % | 4,3 minutes au cours d'un mois de 30 jours |
| Plusieurs régions | 5 chiffres neuf : 99,999 % | 26 secondes au cours d'un mois de 30 jours |
Les pourcentages de disponibilité du tableau précédent sont des cibles. Les contrats de niveau de service garantissant la disponibilité de services Google Cloud spécifiques peuvent être différents de ces objectifs de disponibilité. Par exemple, le contrat de niveau de service garantissant la disponibilité d'une instance Bigtable dépend du nombre de clusters, de leur distribution entre les emplacements et de la règle de routage que vous configurez.
Le contrat de niveau de service garantissant la disponibilité minimale d'une instance Bigtable comportant des clusters dans trois régions ou plus est de 99,999 % si la règle de routage multicluster est configurée. Toutefois, si la règle de routage à cluster unique est configurée, le contrat de niveau de service garantissant la disponibilité minimale est de 99,9 %, quel que soit le nombre de clusters et leur distribution.
Les schémas dans cette section montrent des instances Bigtable présentant différentes tailles de cluster et les différents pourcentages de disponibilité correspondants dans le cadre du contrat de niveau de service.
Cluster unique
Le schéma suivant montre une instance Bigtable à cluster unique, avec un contrat de niveau de service garantissant une disponibilité minimale de 99,9 % :
Plusieurs clusters
Le schéma suivant montre une instance Bigtable multicluster dans plusieurs zones d'une même région, avec un routage multicluster (disponibilité minimale dans le cadre du contrat de niveau de service : 99,99 %) :
Plusieurs clusters
Le schéma suivant montre une instance Bigtable multicluster dans trois régions, avec un routage multicluster (disponibilité minimale dans le cadre du contrat de niveau de service : 99,999 %) :
Disponibilité globale de l'infrastructure
Pour exécuter vos applications dans Google Cloud, vous devez utiliser des ressources d'infrastructure telles que des VM et des bases de données. Ces ressources d'infrastructure constituent la pile d'infrastructure de votre application.
Le schéma suivant montre un exemple de pile d'infrastructure dans Google Cloud et le contrat de niveau de service assurant la disponibilité pour chaque ressource de la pile :
Cet exemple de pile d'infrastructure comprend les ressources Google Cloud suivantes :
- Un équilibreur de charge d'application externe régional reçoit les requêtes des utilisateurs et y répond.
- Un groupe d'instances géré (MIG) régional est le backend de l'équilibreur de charge d'application externe régional. Le MIG contient deux VM Compute Engine dans différentes zones. Chaque VM héberge une instance de serveur Web.
- Un équilibreur de charge interne gère la communication entre le serveur Web et les instances du serveur d'applications.
- Un deuxième MIG régional est le backend de l'équilibreur de charge interne. Ce MIG comporte deux VM Compute Engine dans différentes zones. Chaque VM héberge une instance d'un serveur d'applications.
- Une instance Cloud SQL configurée pour la haute disponibilité est la base de données de l'application. L'instance de base de données principale est répliquée de manière synchrone sur une instance de base de données de secours.
La disponibilité globale que vous pouvez attendre d'une pile d'infrastructure telle que dans l'exemple précédent dépend des facteurs suivants :
Contrats de niveau de service Google Cloud
La garantie de disponibilité des contrats de niveau de service des services Google Cloud que vous utilisez dans votre pile d'infrastructure influence la disponibilité globale minimale que vous pouvez attendre de la pile.
Les tableaux suivants comparent la garantie de disponibilité des contrats de niveau de service de certains services :
| Services de calcul | Garantie de disponibilité du contrat de niveau de service par mois | Temps d'arrêt maximal estimé sur un mois de 30 jours |
|---|---|---|
| VM Compute Engine | 99,9 % | 43,2 minutes |
| Pods GKE Autopilot dans plusieurs zones | 99,9 % | 43,2 minutes |
| Service Cloud Run | 99,95 % | 21,6 minutes |
| Services de base de données | Garantie de disponibilité du contrat de niveau de service par mois | Temps d'arrêt maximal estimé sur un mois de 30 jours |
|---|---|---|
| Instance Cloud SQL pour PostgreSQL (édition Enterprise) | 99,95 % | 21,6 minutes |
| Instance AlloyDB pour PostgreSQL | 99,99 % | 4,3 minutes |
| Instance Spanner multirégionale | 99,999 % | 26 secondes |
Pour les contrats de niveau de service d'autres services Google Cloud, consultez Contrats de niveau de service Google Cloud.
Comme le montrent les tableaux précédents, les services Google Cloud que vous choisissez pour chaque niveau de votre pile d'infrastructure affectent directement le temps d'activité global de la pile d'infrastructure. Pour augmenter la disponibilité attendue d'une charge de travail déployée sur une ressource Google Cloud, vous pouvez provisionner des instances redondantes de la ressource, comme décrit dans la section suivante.
Redondance des ressources
La redondance des ressources consiste à provisionner au moins deux instances identiques d'une ressource et à déployer la même charge de travail sur toutes les ressources du groupe. Par exemple, pour héberger le niveau Web d'une application, vous pouvez provisionner un MIG contenant plusieurs VM Compute Engine identiques.
Si vous répartissez un groupe de ressources de manière redondante sur plusieurs domaines de défaillance (par exemple, deux zones Google Cloud), la disponibilité des ressources de ce groupe est supérieure à la garantie de disponibilité du contrat de niveau de service de chaque ressource du groupe. Cette disponibilité est plus élevée, car la probabilité que chaque ressource du groupe échoue en même temps est inférieure à la probabilité que les ressources d'un domaine de défaillance unique présentent une défaillance coordonnée.
Par exemple, si la garantie de disponibilité du contrat de niveau de service d'une ressource est de 99,9 %, la probabilité que la ressource échoue est de 0,001 (1 moins le contrat de niveau de service). Si vous répartissez une charge de travail sur deux instances de cette ressource provisionnées dans des domaines de défaillance distincts, la probabilité que les deux ressources échouent simultanément est de 0,000001 (c'est-à-dire 0,001 x 0,001). Cette probabilité de défaillance se traduit par une disponibilité théorique de 99,9999 % pour le groupe des deux ressources. Toutefois, la disponibilité réelle que vous pouvez attendre est limitée à la disponibilité cible de l'emplacement de déploiement : 99,9 % si les ressources se trouvent dans une seule zone Google Cloud, 99,99 % pour un déploiement multizone et 99,999 % si les ressources redondantes sont réparties sur plusieurs régions.
Profondeur de la pile
La profondeur d'une pile d'infrastructure correspond au nombre de niveaux distincts (ou couches) de la pile. Chaque niveau d'une pile d'infrastructure contient des ressources qui fournissent une fonction distincte pour l'application. Par exemple, le niveau intermédiaire d'une pile à trois niveaux peut utiliser des VM Compute Engine ou un cluster GKE pour héberger des serveurs d'applications. Chaque niveau d'une pile d'infrastructure présente généralement une interdépendance étroite avec ses niveaux adjacents. Cela signifie que si un niveau de la pile est indisponible, la pile entière devient indisponible.
Vous pouvez calculer la disponibilité globale attendue d'une pile d'infrastructure à N niveaux à l'aide de la formule suivante :
Par exemple, si chaque niveau d'une pile à trois niveaux est conçu pour offrir une disponibilité de 99,9 %, la disponibilité globale de la pile est d'environ 99,7 % (0,999 x 0,999 x 0,999). Cela signifie que la disponibilité globale d'une pile à plusieurs niveaux est inférieure à celle du niveau qui offre la plus faible disponibilité.
À mesure que le nombre de niveaux interdépendants dans une pile augmente, la disponibilité globale de la pile diminue, comme indiqué dans le tableau suivant. Chaque exemple de pile dans le tableau possède un nombre différent de niveaux. Pour faciliter la comparaison, chaque niveau est supposé offrir une disponibilité de 99,9 %.
| Niveau | Pile A | Pile B | Pile C |
|---|---|---|---|
| Interface | 99,9 % | 99,9 % | 99,9 % |
| Niveau d'application | 99,9 % | 99,9 % | 99,9 % |
| Niveau intermédiaire | – | 99,9 % | 99,9 % |
| Niveau de données | – | – | 99,9 % |
| Disponibilité globale de la pile | 99,8 % | 99,7 % | 99,6 % |
| Temps d'arrêt maximal estimé de la pile sur un mois de 30 jours | 86 minutes | 130 minutes | 173 minutes |
Récapitulatif des considérations de conception
Lorsque vous concevez vos applications, tenez compte de la disponibilité globale de la pile d'infrastructure Google Cloud.
- La disponibilité de chaque ressource Google Cloud dans votre pile d'infrastructure influence la disponibilité globale de la pile. Lorsque vous choisissez des services Google Cloud pour créer votre pile d'infrastructure, tenez compte de la garantie de disponibilité du contrat de niveau de service des services.
- Pour améliorer la disponibilité de la fonction (par exemple, calcul ou base de données) fournie par une ressource, vous pouvez provisionner des instances redondantes de la ressource. Lorsque vous concevez une architecture avec des ressources redondantes, en plus des avantages de disponibilité, vous devez également prendre en compte les effets potentiels sur la complexité opérationnelle, la latence et les coûts.
- Le nombre de niveaux d'une pile d'infrastructure (c'est-à-dire la profondeur de la pile) présente une relation inverse avec la disponibilité globale de la pile. Tenez compte de cette relation lorsque vous concevez ou modifiez votre pile.
Pour obtenir des exemples de calculs de disponibilité globale, consultez les sections suivantes :
- Exemple de calcul : Déploiement à zone unique
- Exemple de calcul : Déploiement multizone
- Exemple de calcul : Déploiement multirégional avec équilibrage de charge régional
- Exemple de calcul : Déploiement multirégional avec équilibrage de charge global
Champs d'application des emplacements
Le champ d'application de l'emplacement d'une ressource Google Cloud détermine dans quelle mesure une défaillance de l'infrastructure peut affecter la ressource. La plupart des ressources que vous provisionnez dans Google Cloud disposent de l'un des champs d'application d'emplacement suivants : zonal, régional, multirégional ou mondial.
Le champ d'application de l'emplacement de certains types de ressources est fixe. Autrement dit, vous ne pouvez pas choisir ni modifier le champ d'application de l'emplacement. Par exemple, les réseaux de cloud privé virtuel (VPC) sont des ressources globales et les machines virtuelles (VM) Compute Engine sont des ressources zonales. Pour certaines ressources, vous pouvez choisir le champ d'application de l'emplacement lors du provisionnement de la ressource. Par exemple, lorsque vous créez un cluster GKE (Google Kubernetes Engine), vous pouvez choisir de créer un cluster GKE zonal ou régional.
Les sections suivantes décrivent plus en détail les champs d'application des emplacements.
Ressources zonales
Les ressources zonales sont déployées dans une seule zone d'une région Google Cloud. Vous trouverez ci-dessous des exemples de ressources zonales. Cette liste n'est pas exhaustive.
- VM Compute Engine
- Groupes d'instances gérés (MIG) zonaux
- Disques persistants zonaux
- Clusters GKE à zone unique
- Instances Filestore basiques et zonales
- Jobs Dataflow
- Instances Cloud SQL
- Clusters Dataproc sur Compute Engine
Une défaillance dans une zone peut affecter les ressources zonales provisionnées dans cette zone. Les zones sont conçues pour minimiser le risque de défaillances corrélées avec d'autres zones de la région. Une défaillance dans une zone n'affecte généralement pas les ressources des autres zones de la région. De plus, une défaillance dans une zone n'entraîne pas nécessairement l'indisponibilité de l'ensemble de l'infrastructure de cette zone. La zone définit simplement la limite attendue pour l'effet d'une défaillance.
Pour protéger les applications qui utilisent des ressources zonales contre les incidents zonaux, vous pouvez répartir ou répliquer les ressources sur plusieurs zones ou régions. Pour en savoir plus, consultez la page Concevoir une infrastructure fiable pour vos charges de travail dans Google Cloud.
Ressources régionales
Les ressources régionales sont déployées defaçon redondante dans plusieurs zones d'une même région. Vous trouverez ci-dessous des exemples de ressources régionales. Cette liste n'est pas exhaustive.
- MIG régionaux
- Buckets Cloud Storage régionaux
- Disques persistants régionaux
- Clusters GKE régionaux avec la configuration par défaut (multizone)
- Sous-réseaux VPC
- Équilibreurs de charge d'application externes régionaux
- Instances Spanner régionales
- Instances Filestore Enterprise
- Services Cloud Run
Les ressources régionales sont résilientes aux incidents dans une zone spécifique. Une panne régionale peut affecter tout ou partie des ressources régionales provisionnées dans cette région. Ces pannes peuvent être causées par des catastrophes naturelles ou des défaillances d'infrastructure à grande échelle.
Ressources multirégionales
Les ressources multirégionales sont réparties sur des régions spécifiques. Vous trouverez ci-dessous des exemples de ressources multirégionales. Cette liste n'est pas exhaustive.
- Buckets Cloud Storage birégionaux et multirégionaux
- Instances Spanner multirégionales
- Instances Bigtable multiclusters (multirégionales)
- Trousseaux de clés multirégionaux dans Cloud Key Management Service
Pour obtenir la liste complète des services Google disponibles dans les configurations multirégionales, consultez la page Produits disponibles par emplacement.
Les ressources multirégionales sont résilientes aux incidents dans des régions et zones spécifiques. Une panne d'infrastructure dans plusieurs régions peut affecter la disponibilité de tout ou partie des ressources multirégionales provisionnées dans les régions concernées.
Ressources globales
Des ressources globales sont disponibles dans tous les emplacements Google Cloud. Vous trouverez ci-dessous des exemples de ressources globales. Cette liste n'est pas exhaustive.
projets et sont utilisés pour le paiement de ceux-ci. Pour obtenir des conseils et des bonnes pratiques sur l'organisation de vos ressources Google Cloud en dossiers et projets, consultez la page Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud.
Réseaux VPC, y compris les routes et règles de pare-feu associées
Zones Cloud DNS
Équilibreurs de charge d'application externes globaux
Trousseaux de clés mondiaux dans Cloud Key Management Service
Sujets Pub/Sub
Secrets dans Secret Manager
Pour obtenir la liste complète des services Google disponibles dans le monde entier, consultez la page Produits disponibles dans le monde entier.
Les ressources globales sont résilientes aux incidents zonaux et régionaux. Ces ressources ne dépendent pas de l'infrastructure dans une région spécifique. Google Cloud dispose de systèmes et de processus qui permettent de réduire le risque de pannes mondiales de l'infrastructure. Google surveille également en permanence l'infrastructure et résout rapidement les pannes mondiales.
Le tableau suivant récapitule la résilience relative des ressources zonales, régionales, multirégionales et globales aux problèmes d'application et d'infrastructure. Il décrit également les efforts requis pour configurer ces ressources, ainsi que les recommandations visant à limiter les effets des pannes.
| Champ d'application de la ressource | Résilience | Recommandations pour limiter les effets des pannes d'infrastructure |
|---|---|---|
| Zonales | Faible | Déployez les ressources de manière redondante dans plusieurs zones ou régions. |
| Régionales | Moyen | Déployez les ressources de manière redondante dans plusieurs régions. |
| Multirégional ou global | Élevés | Gérez les modifications avec soin et utilisez des solutions de remplacement en profondeur dans la mesure du possible. Pour en savoir plus, consultez la page Recommandations pour gérer le risque d'interruption des ressources globales. |
Recommandations pour gérer le risque d'interruption des ressources globales
Pour tirer parti de la résilience des ressources globales aux pannes zonales et régionales, vous pouvez envisager d'utiliser certaines ressources globales dans votre architecture. Google recommande les approches suivantes pour gérer le risque de pannes de ressources globales :
Gestion minutieuse des modifications apportées aux ressources globales
Les ressources globales sont résilientes aux défaillances physiques. La configuration de ces ressources se fait à l'échelle globale. Ainsi, il est plus facile de configurer une seule ressource globale que d'exploiter plusieurs ressources régionales. Cependant, une erreur critique dans la configuration d'une ressource globale peut en faire un point de défaillance unique (SPOF). Par exemple, vous pouvez utiliser un équilibreur de charge global comme interface pour une application répartie géographiquement. Un équilibreur de charge global est souvent un bon choix pour une telle application. Toutefois, une erreur dans la configuration de l'équilibreur de charge peut le rendre indisponible dans toutes les zones géographiques. Pour éviter ce risque, vous devez gérer avec soin les modifications de configuration des ressources globales. Pour en savoir plus, consultez la page Contrôler les modifications apportées aux ressources globales.
Utilisation de ressources régionales en tant que solutions de remplacement en profondeur
Pour les applications présentant des exigences de disponibilité exceptionnellement élevées, les ressources régionales en tant que solutions de remplacement en profondeur peuvent aider à minimiser l'effet des pannes de ressources globales. Prenons l'exemple d'une application distribuée géographiquement ayant un équilibreur de charge global comme interface. Pour vous assurer que l'application reste accessible même si l'équilibreur de charge global est affecté par une panne mondiale, vous pouvez déployer des équilibreurs de charge régionaux. Vous pouvez configurer les clients pour qu'ils utilisent de préférence l'équilibreur de charge global, mais basculer vers l'équilibreur de charge régional le plus proche si l'équilibreur de charge global n'est pas disponible.
Exemple d'architecture avec des ressources zonales, régionales et globales
Votre topologie cloud peut inclure une combinaison de ressources zonales, régionales et globales, comme illustré dans le schéma suivant. Ce schéma montre un exemple d'architecture pour une application à plusieurs niveaux déployée dans Google Cloud.
Comme le montre le schéma ci-dessus, un équilibreur de charge HTTP/S externe global reçoit les requêtes des clients. L'équilibreur de charge distribue les requêtes au backend, qui est un MIG régional comportant deux VM Compute Engine. L'application exécutée sur les VM écrit et lit des données dans une base de données Cloud SQL. La base de données est configurée pour la haute disponibilité. Les instances principale et de secours de la base de données sont provisionnées dans des zones distinctes, et la base de données principale est répliquée de manière synchrone dans la base de données de secours. En outre, la base de données est automatiquement sauvegardée dans un bucket multirégional dans Cloud Storage.
Le tableau suivant récapitule les ressources Google Cloud de l'architecture précédente et la résilience de chaque ressource en cas de pannes zonales et régionales :
| Ressource | Résilience aux pannes |
|---|---|
| Réseau VPC | Les réseaux VPC, y compris leurs routes et règles de pare-feu associées, sont des ressources globales. Elles sont résilientes aux pannes zonales et régionales. |
| Sous-réseaux | Les sous-réseaux VPC sont des ressources régionales. Ils sont résilients aux pannes zonales. |
| Équilibreur de charge HTTP(S) externe global | Les équilibreurs de charge HTTP/S externes globaux sont résilients aux pannes zonales et régionales. |
| MIG régional | Les MIG régionaux sont résilients aux pannes zonales. |
| VM Compute Engine | Les VM Compute Engine sont des ressources zonales. En cas de panne zonale, les VM Compute Engine individuelles peuvent être affectées. Toutefois, l'application peut continuer à diffuser les requêtes, car le backend de l'équilibreur de charge est un MIG régional et non des VM autonomes. |
| Instances Cloud SQL | Le déploiement Cloud SQL de cette architecture est configuré pour la haute disponibilité. Autrement dit, le déploiement inclut une paire principale d'instances de base de données de secours. La base de données principale est dupliquée de manière synchrone sur la base de données de secours à l'aide de disques persistants régionaux.
|
| Bucket Cloud Storage multirégional | Les données stockées dans des buckets Cloud Storage multirégionaux sont résilientes aux pannes régionales. |
| Disques persistants | Les disques persistants peuvent être zonaux ou régionaux. Les disques persistants régionaux sont résilients aux pannes zonales. Pour vous préparer à la reprise après une panne régionale, vous pouvez programmer des instantanés des disques persistants et les stocker dans un bucket Cloud Storage multirégional. |