Comme décrit dans la section Disponibilité des plates-formes, l'infrastructure Google Cloud est conçue pour offrir une disponibilité cible de 99,9 % pour une charge de travail déployée dans une seule zone. La disponibilité cible est de 99,99 % pour un déploiement multizone et de 99,999 % pour un déploiement multirégional. Cette partie du guide de fiabilité de l'infrastructure Google Cloud fournit des conseils de déploiement, des exemples d'architecture et des techniques de conception permettant de protéger vos charges de travail contre les défaillances au niveau de la ressource, de la zone et de la région.
Évitez les points de défaillance uniques
Les applications sont généralement composées de plusieurs composants interdépendants, chacun conçu pour exécuter une fonction spécifique. Ces composants sont généralement regroupés par niveaux selon la fonction qu'ils exécutent et leur relation avec les autres composants. Par exemple, une application de diffusion de contenu peut comporter trois niveaux : un niveau Web contenant un équilibreur de charge et des serveurs Web, un niveau application avec un cluster de serveurs d'applications et un niveau de données pour la persistance. Si un composant de cette pile d'applications dépend d'une seule ressource d'infrastructure, une défaillance de cette ressource peut affecter la disponibilité de la pile entière. Par exemple, si le niveau d'application s'exécute sur une seule VM et si la VM plante, l'intégralité de la pile est effectivement indisponible. Un tel composant est un point de défaillance unique (SPOF).
Une pile d'applications peut comporter plusieurs SPOF. Examinons la pile d'applications à plusieurs niveaux illustrée dans le schéma suivant :
Comme le montre le schéma précédent, cet exemple d'architecture contient un seul équilibreur de charge, deux serveurs Web, un seul serveur d'applications et une seule base de données. Dans cet exemple, l'équilibreur de charge, le serveur d'applications et la base de données sont des SPOF. L'échec de l'un de ces composants peut entraîner l'échec des requêtes utilisateur adressées à l'application.
Pour supprimer les SPOF de votre pile d'application, répartissez les ressources entre les emplacements et déployez des ressources redondantes.
Répartir les ressources et créer une redondance
En fonction des exigences de fiabilité de votre application, vous pouvez choisir parmi les architectures de déploiement suivantes :
| Architecture | Recommandation de charge de travail |
|---|---|
| Emplacement multirégional | Des charges de travail critiques pour les entreprises et pour lesquelles la haute disponibilité est essentielle, comme les applications de vente au détail et de réseaux sociaux. |
| Multizone | Charges de travail qui nécessitent une résilience aux pannes zonales, mais peuvent tolérer des temps d'arrêt causés par les pannes régionales. |
| Zone unique | Charges de travail pouvant tolérer des temps d'arrêt ou pouvant être déployées à un autre emplacement si nécessaire, avec un minimum d'efforts. |
Remarques concernant les coûts, la latence et les opérations
Lorsque vous concevez une architecture distribuée avec des ressources redondantes, en plus des exigences de disponibilité de l'application, vous devez également prendre en compte les effets sur la complexité opérationnelle, la latence et les coûts.
Dans une architecture distribuée, vous provisionnez et gérez un nombre plus élevé de ressources. Le volume de trafic réseau inter-sites est plus élevé. Vous pouvez également stocker et répliquer d'autres données. Par conséquent, le coût de vos ressources cloud dans une architecture distribuée est plus élevé, et l'exploitation de ces déploiements implique davantage de complexité. Pour les applications critiques, l'avantage en termes de disponibilité d'une architecture distribuée peut compenser l'augmentation des coûts et de la complexité opérationnelle.
Pour les applications qui ne sont pas critiques pour l'entreprise, la haute disponibilité fournie par une architecture distribuée peut ne pas être essentielle. Certaines applications ont d'autres exigences plus importantes que la disponibilité. Par exemple, les applications de calcul par lot nécessitent des connexions réseau à faible latence et à haut débit entre les VM. Une architecture à zone unique peut être parfaitement adaptée à ces applications et peut également vous aider à réduire les coûts de transfert de données.
Architectures de déploiement
Cette section présente les options d'architecture suivantes permettant de créer une infrastructure pour vos charges de travail dans Google Cloud :
- Déploiement à zone unique
- Déploiement multizone
- Déploiement multirégional avec équilibrage de charge régional
- Déploiement multirégional avec équilibrage de charge global
Déploiement à zone unique
Le schéma suivant montre une architecture d'application à zone unique avec redondance à chaque niveau, pour une disponibilité plus élevée des fonctions effectuées par chaque composant :
Comme le montre le schéma précédent, cet exemple d'architecture comprend les composants suivants :
- Un équilibreur de charge HTTP/S externe régional permettant de recevoir les requêtes des utilisateurs et d'y répondre.
- Un groupe d'instances géré (MIG) zonal en tant que backend pour l'équilibreur de charge HTTP/S. Le MIG comporte deux VM Compute Engine. Chaque VM héberge une instance d'un serveur Web.
- Un équilibreur de charge interne pour gérer la communication entre le serveur Web et les instances du serveur d'applications.
- Un deuxième MIG zonal servant de backend à l'équilibreur de charge interne. Ce MIG contient deux VM Compute Engine. Chaque VM héberge une instance d'un serveur d'applications.
- Une instance de base de données Cloud SQL Enterprise à partir de laquelle l'application écrit et lit des données. La base de données est répliquée manuellement sur une deuxième instance de base de données Cloud SQL dans la même zone.
Disponibilité globale: déploiement à zone unique
Le tableau suivant indique la disponibilité de chaque niveau dans le schéma d'architecture à zone unique précédent :
| Ressource | Contrat de niveau de service |
|---|---|
| Équilibreur de charge externe | 99,99 % |
| Niveau Web : VM Compute Engine dans une seule zone | 99,9 % |
| Équilibreur de charge interne | 99,99 % |
| Niveau application : VM Compute Engine dans une seule zone | 99,9 % |
| Instance Cloud SQL Enterprise | 99,95 % |
Les ressources d'infrastructure Google Cloud regroupées dans le tableau précédent fournissent la disponibilité globale suivante et le temps d'arrêt mensuel maximal estimé :
- Disponibilité globale : 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73 %
- Temps d'arrêt mensuel maximal estimé : environ 1 heure et 57 minutes
Ce calcul ne prend en compte que les ressources d'infrastructure présentées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :
- Conception interne de l'application
- Processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud
Pour en savoir plus, consultez la section Facteurs qui affectent la fiabilité des applications.
Effets des pannes et conseils pour la récupération
Dans une architecture de déploiement à zone unique, en cas de défaillance d'un composant, l'application peut traiter les requêtes si chaque niveau contient au moins un composant fonctionnel disposant d'une capacité suffisante. 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 du serveur Web. Si une VM qui héberge un serveur Web ou une instance de serveur d'applications plante, le MIG garantit qu'une nouvelle VM est créée automatiquement. Si la base de données plante, vous devez activer manuellement la deuxième base de données et mettre à jour les instances du serveur d'applications pour qu'elles se connectent à la base de données.
Une panne zonale ou régionale affecte les VM Compute Engine et les instances de base de données Cloud SQL lors d'un déploiement à zone unique. Les pannes zonales n'affectent pas l'équilibreur de charge de cette architecture, car il s'agit d'une ressource régionale. Cependant, l'équilibreur de charge ne peut pas distribuer le trafic, car aucun backend n'est disponible. Si une panne zonale se produit, vous devez attendre que Google la résolve, puis vérifier que l'application fonctionne comme prévu.
La section suivante décrit une approche architecturale que vous pouvez utiliser pour répartir les ressources sur plusieurs zones, ce qui permet d'améliorer la résilience de l'application aux pannes zonales.
Déploiement multizone
Dans le cas d'un déploiement à zone unique, en cas de panne zonale, l'application risque de ne pas pouvoir diffuser les requêtes tant que le problème n'est pas résolu. Pour améliorer la résilience de votre application contre les pannes zonales, vous pouvez provisionner plusieurs instances de ressources zonales (telles que les VM Compute Engine) sur deux zones ou plus. Pour les services compatibles avec les ressources à l'échelle de la région (telles que les buckets Cloud Storage), vous pouvez déployer des ressources régionales.
Le schéma suivant illustre une architecture interzone à disponibilité élevée, avec les composants de chaque niveau de la pile d'applications répartis sur deux zones :
Comme le montre le schéma précédent, cet exemple d'architecture comprend les composants suivants :
- Un équilibreur de charge HTTP/S externe régional reçoit les requêtes des utilisateurs et y répond.
- Un MIG régional est le backend de l'équilibreur de charge HTTP/S. 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 TCP. 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 Enterprise 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.
Disponibilité globale : déploiement multizone
Le tableau suivant indique la disponibilité de chaque niveau dans le schéma d'architecture à deux zones précédent :
| Ressource | Contrat de niveau de service |
|---|---|
| Équilibreur de charge externe | 99,99 % |
| Niveau Web : VM Compute Engine dans des zones distinctes | 99,99 % |
| Équilibreur de charge interne | 99,99 % |
| Niveau d'application : VM Compute Engine dans des zones distinctes | 99,99 % |
| Instance Cloud SQL Enterprise | 99,95 % |
Les ressources d'infrastructure Google Cloud regroupées dans le tableau précédent fournissent la disponibilité globale suivante et le temps d'arrêt mensuel maximal estimé :
- Disponibilité globale : 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91 %
- Temps d'arrêt mensuel maximal estimé : environ 39 minutes
Ce calcul ne prend en compte que les ressources d'infrastructure présentées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :
- Conception interne de l'application
- Processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud
Pour en savoir plus, consultez la section Facteurs qui affectent la fiabilité des applications.
Effets des pannes et conseils pour la récupération
Dans un déploiement à deux zones, en cas de défaillance d'un composant, 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 à l'instance de serveur Web dans l'autre zone. Si une VM qui héberge un serveur Web ou une instance de serveur d'applications plante, le MIG garantit qu'une nouvelle VM est créée automatiquement. Si la base de données Cloud SQL principale plante, Cloud SQL bascule automatiquement vers l'instance de base de données de secours.
Le schéma suivant illustre la même architecture que le schéma précédent et les effets d'une panne zonale sur la disponibilité de l'application :
Comme le montre le schéma précédent, en cas de panne dans l'une des zones, l'équilibreur de charge de cette architecture n'est pas affecté, car il s'agit d'une ressource régionale. Une panne zonale peut affecter des VM Compute Engine individuelles et l'une des instances de base de données Cloud SQL. Toutefois, l'application reste disponible et réactive, car les VM se trouvent dans les MIG régionaux et la base de données Cloud SQL est configurée pour la haute disponibilité. Les groupes d'instances gérés assurent la création automatique de VM pour conserver le nombre minimal de VM configuré. Si l'instance de base de données Cloud SQL principale est affectée par une panne zonale, Cloud SQL bascule automatiquement vers l'instance de secours dans l'autre zone. Une fois la panne 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 les deux zones de cette architecture présentent une panne, l'application est indisponible. L'équilibreur de charge reste disponible, sauf en cas d'interruption à l'échelle de la région. Cependant, l'équilibreur de charge ne peut pas distribuer le trafic, car aucun backend n'est disponible. Si une panne multizone ou une panne régionale se produit, vous devez attendre que Google résolve la panne, puis vérifier que l'application fonctionne comme prévu.
Les sections suivantes présentent des options d'architecture pour protéger votre application contre les pannes multizones et les pannes régionales.
Déploiement multirégional avec équilibrage de charge régional
Dans un déploiement à zone unique ou multizone, en cas de panne régionale, l'application ne peut pas diffuser les requêtes tant que le problème n'est pas résolu. Pour protéger votre application contre les pannes régionales, vous pouvez répartir les ressources Google Cloud sur deux régions ou plus.
Le schéma suivant montre une architecture interrégionale à disponibilité élevée, avec les composants de chaque niveau de la pile d'applications répartis sur plusieurs régions :
Comme le montre le schéma précédent, cet exemple d'architecture comprend les composants suivants :
- Une zone Cloud DNS publique avec une règle de routage qui dirige le trafic vers deux régions Google Cloud.
- Un équilibreur de charge HTTP/S externe régional dans chaque région pour recevoir les requêtes des utilisateurs et y répondre.
- Le backend de chaque équilibreur de charge HTTP/S régional est un MIG régional. Chaque MIG contient deux VM Compute Engine dans différentes zones. Chacune de ces VM héberge une instance d'un serveur Web.
- Un équilibreur de charge interne dans chaque région gère la communication entre les instances du serveur Web et les instances du serveur d'applications.
- Une deuxième paire de MIG régionaux est le backend des équilibreurs de charge internes. Chacun de ces MIG contient deux VM Compute Engine dans différentes zones. Chaque VM héberge une instance d'un serveur d'applications.
- L'application écrit et lit dans une instance multirégionale Spanner. La configuration multirégionale utilisée dans cette architecture (
eur5) comprend quatre instances dupliquées en lecture/écriture. Les instances dupliquées en lecture/écriture sont provisionnées de manière égale entre deux régions et dans des zones distinctes. La configuration multirégionale Spanner inclut également une instance dupliquée témoin dans une troisième région.
Disponibilité globale : déploiement multirégional avec équilibrage de charge régional
Dans le déploiement multirégional illustré dans le schéma précédent, les équilibreurs de charge et les VM sont provisionnés de manière redondante dans deux régions. La zone DNS est une ressource globale et l'instance Spanner est une ressource multirégionale.
Pour calculer la disponibilité globale de l'infrastructure Google Cloud présentée dans cette architecture, nous devons d'abord calculer la disponibilité globale des ressources dans chaque région, puis prendre en compte les ressources qui couvrent plusieurs régions. Procédez comme suit :
- Calculer la disponibilité globale des ressources d'infrastructure par région, autrement dit, en excluant des ressources DNS et de la base de données :
Ressource et contrat de niveau de service Contrat de niveau de service Équilibreur de charge externe 99,99 % Niveau Web : VM Compute Engine dans des zones distinctes 99,99 % Équilibreur de charge interne 99,99 % Niveau d'application : VM Compute Engine dans des zones distinctes 99,99 % Disponibilité globale par région : 0,9999 x 0,9999 x 0,9999 x 0,9999 = 99,96 %
Calculez la disponibilité globale des ressources d'infrastructure en tenant compte de la redondance à deux zones des équilibreurs de charge et des VM Compute Engine.
La disponibilité théorique est de 1-(1-0,9996)(1-0,9996) = 99,999984 %. Toutefois, la disponibilité réelle que vous pouvez attendre est limitée à la disponibilité cible des déploiements multirégionaux, qui est de 99,999 %.
Calculez la disponibilité globale de toutes les ressources d'infrastructure, y compris les ressources Cloud DNS et Spanner :
- Disponibilité globale : 0,99999 x 1 x 0,99999 = 99,998 %
- Temps d'arrêt mensuel maximal estimé : environ 52 secondes
Ce calcul ne prend en compte que les ressources d'infrastructure présentées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :
- Conception interne de l'application
- Processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud
Pour en savoir plus, consultez la section Facteurs qui affectent la fiabilité des applications.
Effets des pannes et conseils pour la récupération
Si l'un des composants de ce déploiement multirégional échoue, mais qu'il existe au moins un composant fonctionnel avec une capacité suffisante à chaque niveau, l'application continue de fonctionner. Par exemple, en cas d'échec d'une instance de serveur Web, l'équilibreur de charge HTTP/S externe régional transfère les requêtes des utilisateurs aux autres instances du serveur Web de la région. De même, si l'une des instances du serveur d'applications plante, les équilibreurs de charge internes envoient des requêtes aux autres instances du serveur d'applications. Si l'une des VM plante, les MIG s'assurent de créer automatiquement des VM pour conserver le nombre minimal de VM configuré.
Les pannes dans une zone n'affectent pas les équilibreurs de charge, car il s'agit de ressources régionales et résilientes aux pannes zonales. Une panne zonale peut affecter les VM Compute Engine individuelles. Toutefois, les instances du serveur Web et du serveur d'applications restent disponibles, car les VM font partie des MIG régionaux. Les groupes d'instances gérés s'assurent de créer automatiquement des VM pour conserver le nombre minimal de VM configuré. L'instance Spanner de cette architecture utilise une configuration multirégionale, résiliente aux pannes zonales.
Pour en savoir plus sur le fonctionnement de la réplication multirégionale dans Spanner, consultez les pages Configurations régionales et multirégionales et Démystifier les configurations multirégionales Spanner.
Le schéma suivant illustre la même architecture multirégionale que le schéma précédent et les effets d'une panne régionale dans la disponibilité de l'application :
Comme le montre le schéma précédent, même en cas de panne dans les deux zones de n'importe quelle région, l'application reste disponible, car une pile d'applications indépendante est déployée dans chaque région. La zone DNS dirige les requêtes des utilisateurs vers la région non touchée par la panne. L'instance Spanner multirégionale est résiliente aux pannes régionales. Une fois la panne résolue par Google, vous devez vérifier que l'application s'exécute comme prévu dans la région où la panne a eu lieu.
Si deux des régions de cette architecture présentent des pannes, l'application est indisponible. Attendez que Google ait résolu les pannes. Ensuite, vérifiez que l'application s'exécute comme prévu dans toutes les régions où elle est déployée.
Pour les déploiements multirégionaux, au lieu d'utiliser des équilibreurs de charge régionaux, vous pouvez envisager d'utiliser un équilibreur de charge global. La section suivante présente une architecture de déploiement multirégionale qui utilise un équilibreur de charge global et décrit les avantages et les risques de cette approche.
Déploiement multirégional avec équilibrage de charge global
Le schéma suivant illustre un autre déploiement multirégional utilisant un équilibreur de charge global plutôt que des équilibreurs de charge régionaux :
Comme le montre le schéma précédent, cette architecture utilise un équilibreur de charge HTTP/S externe global (avec Cloud CDN activé) pour recevoir les requêtes des utilisateurs et y répondre. Chaque règle de transfert de l'équilibreur de charge utilise une seule adresse IP externe. Vous n'avez pas besoin de configurer un enregistrement DNS distinct pour chaque région. Les backends de l'équilibreur de charge HTTP/S externe global sont deux MIG régionaux. L'équilibreur de charge achemine les requêtes vers la région la plus proche des utilisateurs.
Tous les autres composants de cette architecture sont identiques à l'architecture présentée dans le document Déploiement multirégional avec équilibrage de charge régional.
Avantages et risques de l'équilibrage de charge global pour les déploiements multirégionaux
Pour équilibrer le trafic externe vers une application répartie sur plusieurs régions, vous pouvez utiliser un équilibreur de charge global ou plusieurs équilibreurs de charge régionaux.
Voici les avantages d'une architecture utilisant un équilibreur de charge global :
- Vous ne devez gérer qu'un seul équilibreur de charge.
- Les équilibreurs de charge mondiaux utilisent une seule adresse IP Anycast pour fournir un équilibrage de charge entre les régions Google Cloud.
- Les équilibreurs de charge mondiaux sont résilients aux pannes régionales et fournissent un basculement automatique entre les régions.
- Les équilibreurs de charge mondiaux sont compatibles avec les fonctionnalités suivantes, qui peuvent améliorer la fiabilité de vos déploiements :
- Mise en cache périphérique à l'aide de Cloud CDN
- Possibilité d'utiliser des buckets Cloud Storage très durables en tant que backends
- Règles de sécurité Google Cloud Armor
Voici les risques d'une architecture utilisant un équilibreur de charge global :
- Une modification de configuration incorrecte dans l'équilibreur de charge global peut rendre l'application indisponible pour les utilisateurs. Par exemple, lors de la mise à jour de l'interface de l'équilibreur de charge global, si vous supprimez accidentellement une règle de transfert, celui-ci cesse de recevoir des requêtes utilisateur. L'effet de ce risque est plus faible dans le cas d'une architecture multirégionale utilisant des équilibreurs de charge régionaux, car même si l'équilibreur de charge régional dans l'une des régions est affecté par une erreur de configuration, les équilibreurs de charge des autres régions continuent de fonctionner.
- Une panne d'infrastructure qui affecte les ressources globales peut rendre l'équilibreur de charge global indisponible.
Pour limiter ces risques, vous devez gérer avec soin les modifications apportées à l'équilibreur de charge global et envisager d'utiliser des solutions de remplacement en profondeur si possible. Pour en savoir plus, consultez la page Recommandations pour gérer le risque d'interruption des ressources globales.
Disponibilité globale: déploiement multirégional avec équilibrage de charge global
Dans le déploiement multirégional illustré dans le schéma précédent, les VM et les équilibreurs de charge internes sont répartis de manière redondante entre deux régions. L'équilibreur de charge externe est une ressource globale et l'instance Spanner est une ressource multirégionale.
Pour calculer la disponibilité globale de ce déploiement, nous calculons d'abord la disponibilité globale des ressources dans chaque région, puis nous examinons les ressources couvrant plusieurs régions.
- Calculez la disponibilité globale des ressources d'infrastructure par région, en excluant l'équilibreur de charge externe et la base de données :
Ressource Contrat de niveau de service Niveau Web : VM Compute Engine dans des zones distinctes 99,99 % Équilibreur de charge interne 99,99 % Niveau Web : VM Compute Engine dans des zones distinctes 99,99 % Disponibilité globale par région : 0,9999 x 0,9999 x 0,9999 = 99,97 %
Calculez la disponibilité globale des ressources d'infrastructure en tenant compte de la redondance à deux zones de l'équilibreur de charge interne et des VM Compute Engine.
La disponibilité théorique est de 1-(1-0.9997)(1-0.9997) = 99,999991 %. Toutefois, la disponibilité réelle que vous pouvez attendre est limitée à la disponibilité cible des déploiements multirégionaux, qui est de 99,999 %.
Calculez la disponibilité globale de toutes les ressources d'infrastructure, y compris l'équilibreur de charge global et les ressources Spanner :
- Disponibilité globale : 0,99999 x 0,9999 x 0,99999 = 99,988 %
- Temps d'arrêt mensuel maximal estimé : environ 5 minutes et 11 secondes
Ce calcul ne prend en compte que les ressources d'infrastructure présentées dans le schéma d'architecture précédent. Pour évaluer la disponibilité d'une application dans Google Cloud, vous devez également prendre en compte d'autres facteurs, tels que les suivants :
- Conception interne de l'application
- Processus et outils DevOps utilisés pour créer, déployer et gérer l'application, ses dépendances et l'infrastructure Google Cloud
Pour en savoir plus, consultez la section Facteurs qui affectent la fiabilité des applications.
Effets des pannes et conseils pour la récupération
Si un composant de cette architecture échoue, l'application continue de fonctionner si au moins un composant fonctionnel avec une capacité suffisante existe à chaque niveau. Par exemple, en cas d'échec d'une instance de serveur Web, l'équilibreur de charge HTTP/S externe global transfère les requêtes des utilisateurs aux autres instances du serveur Web. Si une instance de serveur d'applications plante, les équilibreurs de charge internes envoient les requêtes aux autres instances de serveur d'applications. Si l'une des VM plante, les MIG s'assurent de créer automatiquement des VM pour conserver le nombre minimal de VM configuré.
Si une panne se produit dans l'une des zones de n'importe quelle région, l'équilibreur de charge n'est pas affecté. L'équilibreur de charge HTTP/S externe global est résilient aux pannes zonales et régionales. Les équilibreurs de charge internes sont des ressources régionales. Elles sont résilientes aux pannes zonales. Les pannes zonales peuvent affecter les VM Compute Engine individuelles. Toutefois, les instances du serveur Web et du serveur d'applications restent disponibles, car les VM font partie des MIG régionaux. Les MIG garantissent que de nouvelles VM sont créées automatiquement pour conserver le nombre minimal de VM configuré. L'instance Spanner de cette architecture utilise une configuration multirégionale, résiliente aux pannes zonales.
Le schéma suivant illustre la même architecture multirégionale que le schéma précédent et les effets d'une panne régionale dans la disponibilité de l'application :
Comme le montre le schéma précédent, même en cas de panne dans les deux zones de n'importe quelle région, l'application reste disponible, car une pile d'applications indépendante est déployée dans chaque région. L'équilibreur de charge HTTP/S externe global achemine les requêtes des utilisateurs vers l'application dans la région qui n'est pas affectée par la panne. L'instance Spanner multirégionale est résiliente aux pannes régionales. Une fois que Google a résolu la panne, vous devez vérifier que l'application s'exécute comme prévu dans la région où la panne a eu lieu.
Pour en savoir plus sur le fonctionnement de la réplication multirégionale dans Spanner, consultez les pages Configurations régionales et multirégionales et Démystifier les configurations multirégionales Spanner.
Si deux des régions de cette architecture présentent des pannes, l'application est indisponible. L'équilibreur de charge HTTP/S externe global est disponible, mais il ne peut pas distribuer de trafic, car aucun backend n'est disponible. Attendez que Google ait résolu les pannes. Ensuite, vérifiez que l'application s'exécute comme prévu dans toutes les régions où elle est déployée.
Les déploiements multirégionaux permettent de garantir une haute disponibilité pour vos applications métier les plus critiques. Pour assurer la continuité des opérations lors des événements de défaillance, outre le déploiement de l'application dans plusieurs régions, vous devez prendre certaines mesures supplémentaires. Par exemple, vous devez effectuer une planification des capacités pour vous assurer qu'une capacité suffisante est réservée dans toutes les régions ou que les risques associés à l'autoscaling d'urgence sont acceptables. Vous devez également mettre en œuvre des pratiques opérationnelles pour les tests de reprise après sinistre, la gestion des incidents, la vérification de l'état des applications après les incidents et la réalisation de rétrospectives.