Cet article constitue la sixième partie d'une série qui traite de la reprise après sinistre (DR, Disaster Recovery) dans Google Cloud. Cette partie aborde le processus de conception de charges de travail à l'aide de Google Cloud et la création de composants résilients aux pannes d'infrastructure cloud.
La série comprend les éléments suivants :
- Guide de planification de reprise après sinistre
- Structure de la reprise après sinistre
- Scénarios de reprise après sinistre pour les données
- Scénarios de reprise après sinistre pour les applications
- Concevoir une solution de reprise après sinistre pour des charges de travail limitées à la localité
- Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud (ce document)
Introduction
Pour migrer des charges de travail sur le cloud public, les entreprises doivent transposer leur savoir concernant la création de systèmes sur site résilients vers l'infrastructure hyperscale de fournisseurs cloud tels que Google Cloud. Cet article mappe les concepts de reprise après sinistre standards dans l'industrie, tels que l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO), à l'infrastructure Google Cloud.
Les conseils fournis dans ce document respectent l'un des principes clés de Google garantissant une très haute disponibilité des services : la planification contre les défaillances. Bien que Google Cloud fournisse un service extrêmement fiable, des sinistres peuvent survenir (catastrophes naturelles, ruptures de fibre et défaillances d'infrastructure imprévisibles et complexes), causant ainsi des pannes. La planification contre les pannes permet aux clients Google Cloud de créer des applications qui fonctionnent de manière prévisible lors de ces événements inévitables, via l'utilisation de produits Google Cloud intégrant des mécanismes de reprise après sinistre.
La reprise après sinistre est un sujet vaste qui couvre bien plus que les défaillances d'infrastructure telles que les bugs logiciels ou la corruption de données. C'est pourquoi vous devez disposer d'un plan complet de bout en bout. Toutefois, cet article ne se concentre que sur une partie d'un plan de reprise après sinistre global, à savoir la conception d'applications résilientes aux pannes d'infrastructure cloud. Plus précisément, cet article décrit les éléments suivants :
- L'infrastructure Google Cloud, la façon dont les sinistres se manifestent en cas de panne Google Cloud, ainsi que la manière dont Google Cloud est conçu pour minimiser la fréquence et l'étendue des pannes.
- Un guide de planification de l'architecture qui fournit un framework permettant de catégoriser et de concevoir des applications en fonction des résultats de fiabilité souhaités.
- La liste détaillée d'une sélection de produits Google Cloud proposant des fonctionnalités intégrées de reprise après sinistre que vous souhaiterez peut-être utiliser dans votre application.
Pour en savoir plus sur la planification générale de la reprise après sinistre et sur l'utilisation de Google Cloud en tant que composant de votre stratégie de reprise après sinistre sur site, consultez le guide de planification de reprise après sinistre. Bien que la haute disponibilité soit un concept étroitement lié à la reprise après sinistre, elle n'est pas traitée dans cet article. Pour en savoir plus sur la création d'une architecture haute disponibilité, consultez le framework d'architecture Google Cloud.
Remarque sur la terminologie : dans cet article, le terme disponibilité désigne la capacité d'un produit à être accessible et utilisé de manière significative au fil du temps, tandis que le terme fiabilité désigne un ensemble d'attributs incluant la disponibilité ainsi que des éléments tels que la durabilité et l'exactitude.
Conception de Google Cloud pour la résilience
Centres de données Google
Les centres de données traditionnels visent à maximiser la disponibilité des composants individuels. Dans le cloud, le scaling permet à des opérateurs tels que Google de déployer des services sur de nombreux composants grâce à des technologies de virtualisation, allant ainsi au-delà de la fiabilité traditionnelle des composants. Cela signifie que vous pouvez changer votre approche en matière d'architecture de fiabilité et arrêter de vous focaliser sur les nombreux détails qui vous préoccupaient autrefois dans les environnements sur site. Plutôt que de vous soucier des différents modes de défaillance des composants (tels que le refroidissement et l'alimentation), vous pouvez baser votre planification sur les produits Google Cloud et leurs métriques de fiabilité annoncées. Ces métriques reflètent le risque de panne agrégé dans toute l'infrastructure sous-jacente. Vous pouvez ainsi vous concentrer davantage sur la conception, le déploiement et les opérations des applications plutôt que sur la gestion de l'infrastructure.
Google conçoit son infrastructure pour atteindre des objectifs de disponibilité ambitieux basés sur une vaste expérience dans les domaines de la création et de l'exploitation de centres de données modernes. Google est un leader mondial dans la conception de centres de données. De l'alimentation au refroidissement en passant par les réseaux, chaque technologie de centre de données possède ses propres redondances et mesures d'atténuation, y compris des plans FMEA. Les centres de données de Google sont créés de manière à équilibrer ces risques et à présenter aux clients un niveau de disponibilité attendu et cohérent pour les produits Google Cloud. Nous nous appuyons sur notre expérience pour modéliser la disponibilité de l'architecture globale du système physique et logique, et ainsi nous assurer que la conception des centres de données répond aux attentes. Les ingénieurs de Google déploient de nombreux efforts pour s'assurer que ces attentes sont satisfaites. La disponibilité réelle mesurée surpasse généralement de loin nos objectifs de conception.
En injectant l'ensemble de ces risques et mesures d'atténuation de centre de données dans les produits destinés aux utilisateurs, Google Cloud vous libère des responsabilités liées à la conception et à l'exploitation. À la place, vous pouvez vous concentrer sur la fiabilité intégrée aux régions et aux zones Google Cloud.
Régions et zones
Les produits Google Cloud sont fournis dans un grand nombre de régions et zones. Les régions sont des espaces géographiques indépendants qui contiennent trois zones ou plus. Les zones représentent des groupes de ressources de calcul physiques au sein d'une région, présentant un degré élevé d'indépendance en termes d'infrastructure physique et logique. Elles fournissent des connexions réseau à haut débit et à faible latence vers d'autres zones de la même région. Par exemple, la région asia-northeast1 au Japon contient trois zones : asia-northeast1-a, asia-northeast1-b et asia-northeast1-c.
Les produits Google Cloud sont divisés en ressources zonales, régionales ou multirégionales.
Les ressources zonales sont hébergées dans une seule zone. Une interruption de service dans la zone peut affecter toutes les ressources de cette zone. Prenons l'exemple d'une instance Compute Engine qui s'exécute dans une seule zone spécifiée. Si une défaillance matérielle cause l'arrêt du service dans cette zone, l'instance Compute Engine est indisponible pendant toute la durée de l'interruption.
Les ressources régionales sont déployées de façon redondante dans plusieurs zones d'une même région. Elles offrent ainsi une fiabilité plus élevée que les ressources zonales.
Les ressources multirégionales sont distribuées au sein des régions et entre elles. En général, les ressources multirégionales présentent une fiabilité plus élevée que les ressources régionales. À ce niveau, toutefois, les produits doivent optimiser la disponibilité, les performances et l'efficacité des ressources. Par conséquent, il est important de comprendre les compromis réalisés par chaque produit multirégional que vous décidez d'utiliser. Ces compromis sont décrits plus en détail dans la suite de ce document.
Exploiter les zones et les régions pour améliorer la fiabilité
Les ingénieurs SRE de Google gèrent et font évoluer des produits utilisateur hautement fiables et mondiaux, tels que Gmail et la recherche Google, à l'aide de diverses techniques et technologies qui exploitent de manière fluide l'infrastructure informatique du monde entier. Cela inclut la redirection du trafic depuis des emplacements indisponibles via l'équilibrage de charge global, l'exécution de plusieurs instances dupliquées dans de nombreux emplacements à travers le monde et la réplication des données entre les emplacements. Ces fonctionnalités sont disponibles pour les clients Google Cloud par l'intermédiaire de produits tels que Cloud Load Balancing, Google Kubernetes Engine et Cloud Spanner.
Google Cloud conçoit généralement les produits pour qu'ils offrent les niveaux de disponibilité suivants pour les zones et les régions :
| Ressource | Exemples | Objectif de conception de disponibilité | Temps d'arrêt implicite |
|---|---|---|---|
| Zonal | Compute Engine, Persistent Disk | 99,9 % | 8,75 heures/an |
| Disques | Cloud Storage régional, Persistent Disk (répliqué), Google Kubernetes Engine régional | 99,99 % | 52 minutes/an |
Comparez les objectifs de conception de disponibilité Google Cloud avec le temps d'arrêt que vous jugez acceptable pour identifier les ressources Google Cloud appropriées. Bien que les conceptions traditionnelles visent à améliorer la disponibilité au niveau des composants pour augmenter la disponibilité des applications résultantes, les modèles cloud se focalisent à la place sur la composition des composants pour atteindre cet objectif. De nombreux produits au sein de Google Cloud emploient cette technique. Par exemple, Cloud Spanner propose une base de données multirégionale qui compose plusieurs régions afin de fournir une disponibilité de 99,999 %.
La composition est importante, car sans elle, la disponibilité de votre application ne peut pas surpasser celle des produits Google Cloud que vous utilisez. En fait, à moins que votre application ne rencontre jamais de défaillance, sa disponibilité est inférieure à celle des produits Google Cloud sous-jacents. Le reste de cette section explique de façon générale comment utiliser une composition de produits zonaux et régionaux pour obtenir une disponibilité d'application plus élevée qu'avec une seule zone ou région. La section suivante présente un guide pratique pour la mise en œuvre de ces principes dans vos applications.
Planification pour les pannes zonales
Les défaillances d'infrastructure entraînent généralement des interruptions de service dans une seule zone. Dans une région, les zones sont conçues pour minimiser le risque de pannes corrélées avec d'autres zones. Une interruption de service dans une zone n'affecte généralement pas le service d'une autre zone de la même région. Une panne limitée à une zone ne signifie pas nécessairement que la zone entière est indisponible ; cela définit simplement la limite de l'incident. Il est possible qu'une panne zonale n'ait aucun effet concret sur vos ressources spécifiques de cette zone.
Bien qu'il s'agisse d'un scénario plus rare, il est également essentiel de noter que plusieurs zones subiront à un moment donné une panne corrélée au sein d'une même région. Lorsque deux zones ou plus subissent une panne, la stratégie ci-dessous s'applique pour l'étendue de panne régionale.
Les ressources régionales sont conçues pour résister aux pannes zonales en distribuant le service à partir d'une composition de plusieurs zones. Si l'une des zones qui supportent la ressource régionale est interrompue, la ressource devient automatiquement disponible depuis une autre zone. Consultez attentivement la description des fonctionnalités produit dans l'annexe pour obtenir plus de détails.
Google Cloud ne propose que quelques ressources zonales, à savoir les machines virtuelles (VM) Compute Engine et les disques persistants. Si vous envisagez d'utiliser des ressources zonales, vous devez effectuer votre propre composition de ressources en concevant, en créant et en testant le basculement et la reprise entre des ressources zonales situées dans plusieurs zones. Voici quelques exemples de stratégies :
- Acheminez rapidement votre trafic vers des machines virtuelles d'une autre zone à l'aide de Cloud Load Balancing lorsqu'une vérification d'état détermine qu'une zone rencontre des problèmes.
- Utilisez des modèles d'instances Compute Engine et/ou des groupes d'instances gérés pour exécuter et faire évoluer des instances de VM identiques dans plusieurs zones.
- Utilisez un disque persistant régional pour répliquer les données de manière synchrone vers une autre zone d'une région. Consultez la page Options de haute disponibilité avec des disques persistants régionaux pour en savoir plus.
Planification pour les pannes régionales
Une panne régionale est une interruption de service qui affecte plusieurs zones d'une même région. Ces pannes sont plus importantes et moins fréquentes, et peuvent être causées par des catastrophes naturelles ou des défaillances d'infrastructure à grande échelle.
Pour un produit régional conçu pour offrir une disponibilité de 99,99 %, une panne peut tout de même provoquer presque une heure de temps d'arrêt chaque année pour un produit donné. Par conséquent, vos applications critiques peuvent nécessiter la mise en œuvre d'un plan de reprise après sinistre multirégional si cette durée d'interruption est inacceptable.
Les ressources multirégionales sont conçues pour résister aux pannes régionales en distribuant le service à partir de plusieurs régions. Comme décrit ci-dessus, les produits multirégionaux offrent un compromis entre la latence, la cohérence et les coûts. Le compromis le plus courant se situe au niveau des réplications synchrone et asynchrone des données. La réplication asynchrone fournit une latence inférieure, mais inclut un risque de perte de données en cas de panne. Il est donc important de consulter la description des fonctionnalités produit dans l'annexe pour plus de détails.
Si vous souhaitez utiliser des ressources régionales tout en conservant une résilience aux pannes régionales, vous devez effectuer votre propre composition de ressources en concevant, en créant et en testant leur basculement et leur reprise entre des ressources régionales situées dans plusieurs régions. Outre les stratégies zonales décrites ci-dessus, que vous pouvez également appliquer aux régions, tenez compte des points suivants :
- Les ressources régionales doivent répliquer les données dans une région secondaire, dans une option de stockage multirégional telle que Cloud Storage, ou dans une option de cloud hybride telle qu'Anthos.
- Une fois que vous avez mis en place un système d'atténuation des pannes régionales, testez-le régulièrement. En effet, il n'y a rien de pire que de se croire résilient à une panne régionale, pour ensuite constater que ce n'est pas le cas en situation réelle.
Approche de résilience et de disponibilité de Google Cloud
Bien que Google Cloud surpasse régulièrement ses objectifs de conception de disponibilité, ne partez pas du principe que ces solides performances passées représentent la disponibilité minimale que vous pouvez concevoir. Sélectionnez plutôt les dépendances Google Cloud dont les objectifs de conception surpassent la fiabilité souhaitée pour votre application, de sorte que le temps d'arrêt de votre application et le temps d'arrêt de Google Cloud fournissent le résultat escompté.
Un système bien conçu peut répondre à la question suivante : "Que se passe-t-il lorsqu'une zone ou une région subit une panne de 1, 5, 10 ou 30 minutes ?" Cette question, ainsi que les questions suivantes, doivent être prises en compte au niveau de nombreuses couches :
- Quel est l'impact d'une panne pour mes clients ?
- Comment détecter une panne ?
- Qu'advient-il de mon application en cas de panne ?
- Qu'advient-il de mes données en cas de panne ?
- Qu'advient-il de mes autres applications lors d'une panne (en raison des dépendances croisées) ?
- Comment effectuer une reprise une fois la panne résolue ? Qui se charge de ce processus ?
- Qui informer d'une panne et dans quel délai ?
Guide par étapes sur la conception de la reprise après sinistre pour les applications dans Google Cloud
Dans les sections précédentes, vous avez découvert la façon dont Google conçoit une infrastructure cloud ainsi que quelques approches employées pour gérer les pannes zonales et régionales.
Cette section vous aide à développer un framework permettant d'appliquer le principe de composition à vos applications en fonction des résultats de fiabilité souhaités.
Étape 1 : Rassembler les exigences existantes
La première étape consiste à définir les exigences de disponibilité de vos applications. La plupart des entreprises reçoivent déjà dans une certaine mesure des conseils de conception dans cet espace, qui peuvent être développés ou dérivés en interne à partir de réglementations ou d'autres obligations légales. Ces conseils de conception sont généralement codifiés par deux métriques clés : l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO). Dans le langage d'affaires, la métrique RTO se traduit par "Combien de temps me faut-il pour redevenir opérationnel après un sinistre ?". La métrique RPO, quant à elle, se traduit par "Quelle quantité de données puis-je me permettre de perdre en cas de sinistre ?".
Par le passé, les entreprises ont défini des exigences en matière de RTO et de RPO pour un grand nombre de sinistres allant des défaillances de composants jusqu'aux séismes. Cette démarche était logique dans un monde sur site où les planificateurs devaient mapper les exigences en matière de RTO/RPO via l'ensemble de la pile logicielle et matérielle. Dans le cloud, vous n'avez plus besoin de définir vos exigences de manière aussi détaillée, car le fournisseur s'en charge. À la place, vous pouvez définir vos exigences en matière de RTO et de RPO en fonction de l'étendue de la perte (zones ou régions entières), sans spécifier de raisons sous-jacentes. Pour Google Cloud, cela réduit votre rassemblement des exigences à trois scénarios : panne zonale, panne régionale, ou panne extrêmement improbable de plusieurs régions.
Sachant que toutes les applications n'ont pas la même importance, la plupart des clients catégorisent leurs applications en niveaux de criticité auxquels appliquer une exigence RTO/RPO spécifique. Lorsqu'elles sont combinées, les métriques RTO/RPO et la criticité d'application simplifient le processus de conception d'une application donnée en répondant aux questions suivantes :
- L'application doit-elle s'exécuter dans plusieurs zones de la même région ou dans plusieurs zones de plusieurs régions ?
- Sur quels produits Google Cloud l'application peut-elle s'appuyer ?
Voici un exemple de résultat de l'exercice de rassemblement des exigences :
RTO et RPO par criticité d'application pour l'exemple d'organisation Co :
| Criticité d'application | Pourcentage d'applications | Exemples d'applications | Panne zonale | Panne régionale |
|---|---|---|---|---|
| Niveau 1
(le plus important) |
5 % | Applications externes ou mondiales destinées aux clients, telles que les applications de paiement en temps réel et les vitrines d'e-commerce. | RTO : zéro RPO : zéro |
RTO : 4 heures RPO : 1 heure |
| Niveau 2 | 35 % | Applications régionales ou applications internes importantes, telles que les solutions CRM ou ERP. | RTO : 4 heures RPO : zéro |
RTO : 24 heures RPO : 4 heures |
| Niveau 3 (le moins important) |
60 % | Applications destinées aux équipes ou aux services, telles que les applications pour le back-office, la gestion des congés, les déplacements internes, la comptabilité et les RH. | RTO : 12 heures RPO : 24 heures |
RTO : 28 jours RPO : 24 heures |
Étape 2 : Mapper les fonctionnalités aux produits disponibles
La deuxième étape consiste à comprendre les fonctionnalités de résilience des produits Google Cloud que vos applications utiliseront. La plupart des entreprises examinent les informations pertinentes sur les produits, puis ajoutent des instructions décrivant comment modifier leurs architectures pour combler les écarts entre les fonctionnalités produit et leurs exigences de résilience. Cette section présente plusieurs recommandations et domaines courants concernant les limites des données et des applications dans cet espace.
Comme indiqué précédemment, les produits Google compatibles avec la reprise après sinistre répondent largement aux besoins de deux types d'étendue de panne : régionale et zonale. Les pannes partielles doivent être planifiées de la même manière que les pannes complètes en ce qui concerne la reprise après sinistre. Voici une matrice initiale d'ensemble décrivant les produits adaptés à chaque scénario par défaut :
Fonctionnalités générales des produits Google Cloud
(consultez l'annexe pour obtenir la liste des fonctionnalités de produits spécifiques)
| Tous les produits Google Cloud | Produits Google Cloud régionaux avec réplication automatique entre les zones | Produits Google Cloud multirégionaux ou mondiaux avec réplication automatique entre les régions | |
|---|---|---|---|
| Défaillance d'un composant d'une zone | Couvert* | Couvert | Couvert |
| Panne zonale | Non couvert | Couvert | Couvert |
| Panne régionale | Non couvert | Non couvert | Couvert |
*Tous les produits Google Cloud sont résilients aux défaillances des composants, sauf dans les cas spécifiques mentionnés dans la documentation du produit. Il s'agit habituellement de scénarios dans lesquels le produit fournit un accès direct ou un mappage statique à un élément matériel spécialisé, tel que la mémoire ou un disque SSD.
Comment le RPO limite le choix de produits
Dans la plupart des déploiements cloud, l'intégrité des données constitue l'aspect le plus important de l'architecture à prendre en compte pour un service. Au moins une partie des applications ont une exigence RPO de zéro, ce qui signifie qu'il n'y a aucune perte de données en cas de panne. Cette mise en œuvre nécessite généralement une réplication synchrone des données dans une autre zone ou région. La réplication synchrone présente des compromis en termes de coûts et de latence, si bien que même si de nombreux produits Google Cloud fournissent une réplication synchrone entre les zones, peu d'entre eux fournissent une réplication entre les régions. Ce compromis au niveau des coûts et de la complexité signifie qu'il n'est pas rare que différents types de données au sein d'une application aient des valeurs RPO différentes.
Pour les données avec un RPO supérieur à zéro, les applications peuvent tirer parti de la réplication asynchrone. La réplication asynchrone est acceptable lorsque les données perdues peuvent être facilement recréées, ou récupérées à partir d'une source de données fiable, si nécessaire. Il peut également s'agir d'un choix raisonnable lorsque la perte d'une faible quantité de données constitue un compromis acceptable pour les pannes zonales et régionales dont la durée est prévisible. Il est également important de noter qu'en cas de panne temporaire, les données écrites dans l'emplacement affecté qui n'ont pas encore été répliquées dans un autre emplacement deviennent généralement disponibles une fois la panne résolue. Cela signifie que le risque de perte de données permanente est inférieur au risque de perte d'accès aux données lors d'une panne.
Actions clés : déterminez si vous avez absolument besoin d'un RPO de zéro et, le cas échéant, si vous pouvez mettre en œuvre cette solution pour un sous-ensemble de vos données. Cela vous permet d'augmenter considérablement le nombre de services compatibles avec la reprise après sinistre dont vous pouvez disposer. Dans Google Cloud, l'obtention d'un RPO de zéro implique l'utilisation de produits principalement régionaux pour votre application, qui sont par défaut résilients aux pannes zonales, mais pas aux pannes régionales.
Comment le RTO limite le choix de produits
L'un des principaux avantages du cloud computing est la possibilité de déployer une infrastructure à la demande. Ce déploiement est toutefois différent d'un déploiement instantané. La valeur RTO de votre application doit inclure le RTO combiné des produits Google Cloud utilisés par votre application, ainsi que toutes les actions que vos ingénieurs ou ingénieurs SRE doivent entreprendre pour redémarrer vos VM ou les composants d'application. Un RTO mesuré en minutes implique de concevoir une application qui reprend automatiquement à la suite d'un sinistre sans intervention humaine, ou avec des étapes minimales (comme appuyer sur un bouton pour effectuer un basculement). Les coûts et la complexité de ce type de système ont toujours été très élevés, mais les produits Google Cloud tels que les équilibreurs de charge et les groupes d'instances rendent cette conception bien plus simple et abordable. Par conséquent, nous vous recommandons de mettre en place un basculement et une reprise automatiques pour la plupart des applications. Sachez que la conception d'un système pour ce type de basculement à chaud entre les régions est à la fois complexe et coûteuse. Seule une infime partie des services critiques justifient cette mise en œuvre.
La plupart des applications possèdent un RTO compris entre une heure et une journée. Cela permet un basculement tiède dans une situation de sinistre, où certains composants de l'application s'exécutent en permanence en mode de secours (tels que les bases de données), tandis que d'autres composants font l'objet d'un scaling horizontal en cas de sinistre (tels que les serveurs Web). Pour ces applications, nous vous conseillons vivement d'automatiser les événements à évolutivité horizontale. Les services avec un RTO de plus d'une journée sont les moins critiques et peuvent souvent être récupérés à partir d'une sauvegarde ou recréés entièrement.
Actions clés : déterminez si vous avez absolument besoin d'un RTO (proche) de zéro pour le basculement régional et, le cas échéant, si vous pouvez mettre en œuvre cette solution pour un sous-ensemble de vos services. Cela modifie le coût d'exécution et de maintenance de votre service.
Étape 3 : Développer vos propres architectures et guides de référence
La dernière étape recommandée consiste à créer vos propres modèles d'architecture spécifiques à l'entreprise pour aider vos équipes à standardiser leur approche de la reprise après sinistre. La plupart des clients Google Cloud fournissent à leurs équipes de développement un guide faisant correspondre leurs attentes métier individuelles en termes de résilience aux deux principales catégories de scénarios de panne sur Google Cloud. Ainsi, les équipes peuvent facilement catégoriser les produits compatibles avec la reprise après sinistre adaptés à chaque niveau de criticité.
Créer des directives produit
Reprenons l'exemple de tableau RTO/RPO ci-dessus. Vous disposez ici d'un guide hypothétique répertoriant les produits qui seront autorisés par défaut pour chaque niveau de criticité. Notez que même si certains produits ont été identifiés comme non adaptés par défaut, vous pouvez toujours ajouter vos propres mécanismes de réplication et de basculement pour obtenir une synchronisation interzone ou interrégionale, mais cet exercice dépasse le cadre de cet article. Les tableaux renvoient également vers des informations supplémentaires sur chaque produit pour vous aider à comprendre leurs fonctionnalités en ce qui concerne la gestion des pannes zonales ou régionales.
Exemples de modèles d'architecture pour l'exemple d'organisation Co - résilience aux pannes zonales :
| Produit Google Cloud | Le produit répond-il aux exigences de panne zonale pour l'exemple d'organisation (avec une configuration de produit appropriée) ? | ||
|---|---|---|---|
| Niveau 1 | Niveau 2 | Niveau 3 | |
| Compute Engine | Oui | Oui | Oui |
| Dataflow | Non | Non | Non |
| BigQuery | Non | Non | Oui |
| Google Kubernetes Engine | Oui | Oui | Oui |
| Cloud Storage | Oui | Oui | Oui |
| Cloud SQL | Non | Oui | Oui |
| Cloud Spanner | Oui | Oui | Oui |
| Cloud Load Balancing | Oui | Oui | Oui |
Le tableau ci-dessous n'est fourni qu'à titre d'exemple et est basé sur les niveaux hypothétiques présentés ci-dessus.
Exemples de modèles d'architecture pour l'exemple d'organisation Co - résilience aux pannes régionales :
| Produit Google Cloud | Le produit répond-il aux exigences de panne régionale pour l'exemple d'organisation (avec une configuration de produit appropriée) ? | ||
|---|---|---|---|
| Niveau 1 | Niveau 2 | Niveau 3 | |
| Compute Engine | Oui | Oui | Oui |
| Dataflow | Non | Non | Non |
| BigQuery | Non | Non | Oui |
| Google Kubernetes Engine | Oui | Oui | Oui |
| Cloud Storage | Non | Non | Non |
| Cloud SQL | Oui | Oui | Oui |
| Cloud Spanner | Oui | Oui | Oui |
| Cloud Load Balancing | Oui | Oui | Oui |
Le tableau ci-dessous n'est fourni qu'à titre d'exemple et est basé sur les niveaux hypothétiques présentés ci-dessus.
Pour vous montrer comment ces produits sont utilisés, les sections suivantes présentent quelques architectures de référence pour chaque niveau de criticité d'application. Il s'agit de descriptions volontairement générales qui illustrent les principales décisions en termes d'architecture. Elles ne représentent pas une conception de solution complète.
Exemple d'architecture de niveau 3
| Criticité d'application | Panne zonale | Panne régionale |
|---|---|---|
| Niveau 3 (le moins important) |
RTO : 12 heures RPO : 24 heures |
RTO : 28 jours RPO : 24 heures |
(Les icônes grisées indiquent l'infrastructure à activer pour la reprise.)
Cette architecture décrit une application cliente/serveur classique : les utilisateurs internes se connectent à une application qui s'exécute sur une instance de calcul soutenue par une base de données pour le stockage persistant.
Il est important de noter que cette architecture accepte des valeurs RTO et RPO supérieures à celles requises. Toutefois, vous devez également envisager de supprimer les étapes manuelles supplémentaires lorsqu'elles peuvent s'avérer coûteuses ou peu fiables. Par exemple, la récupération d'une base de données à partir d'une sauvegarde nocturne peut convenir au RPO de 24 heures, mais nécessite généralement la présence d'une personne qualifiée (telle qu'un administrateur de base de données) qui peut être indisponible, en particulier si plusieurs services ont été affectés en parallèle. Grâce à l'infrastructure à la demande de Google Cloud, vous pouvez bénéficier de cette fonctionnalité sans avoir à faire de compromis majeur en matière de coûts. Cette architecture exploite la haute disponibilité de Cloud SQL plutôt qu'une sauvegarde/restauration manuelle pour les pannes zonales.
Principales décisions en termes d'architecture pour les pannes zonales - RTO de 12 heures et RPO de 24 heures :
- Un équilibreur de charge interne est utilisé pour fournir un point d'accès évolutif aux utilisateurs, ce qui permet le basculement automatique vers une autre zone. Même si le RTO est de 12 heures, les modifications manuelles des adresses IP ou même les mises à jour DNS peuvent prendre plus de temps que prévu.
- Un groupe d'instances géré régional est configuré avec plusieurs zones, mais avec des ressources minimales. Ainsi, les coûts sont optimisés et les machines virtuelles peuvent toujours faire l'objet d'un scaling horizontal rapide dans la zone de sauvegarde.
- Une configuration Cloud SQL haute disponibilité fournit un basculement automatique vers une autre zone. Les bases de données sont considérablement plus difficiles à recréer et à restaurer que les machines virtuelles Compute Engine.
Principales décisions en termes d'architecture pour les pannes régionales - RTO de 28 jours et RPO de 24 heures :
- Un équilibreur de charge n'est créé dans la région 2 qu'en cas de panne régionale. Cloud DNS est employé pour fournir un basculement régional orchestré, mais manuel, dans la mesure où l'infrastructure de la région 2 n'est rendue disponible qu'en cas de panne régionale.
- Un nouveau groupe d'instances géré n'est créé qu'en cas de panne régionale. Cela permet d'optimiser les coûts, et ce scénario est peu susceptible de se produire en raison de la courte durée de la plupart des pannes régionales. Pour des raisons de simplicité, le schéma ne montre pas les outils associés nécessaires au redéploiement ni la copie des images Compute Engine requises.
- Une instance Cloud SQL est recréée et les données sont restaurées à partir d'une sauvegarde. Ici aussi, le risque d'une panne régionale prolongée est extrêmement faible. Il s'agit donc d'un autre compromis en matière d'optimisation des coûts.
- Le service Cloud Storage multirégional est utilisé pour stocker ces sauvegardes. Cela permet de fournir une zone automatique et une résilience régionale au sein du RTO et du RPO.
Exemple d'architecture de niveau 2
| Criticité d'application | Panne zonale | Panne régionale |
|---|---|---|
| Niveau 2 | RTO : 4 heures RPO : zéro |
RTO : 24 heures RPO : 4 heures |
Cette architecture décrit un entrepôt de données avec des utilisateurs internes qui se connectent à une couche de visualisation d'instances de calcul, ainsi qu'une couche d'ingestion et de transformation de données qui remplit l'entrepôt de données backend.
Certains composants individuels de cette architecture n'acceptent pas directement le RPO requis pour leur niveau. Toutefois, grâce à la façon dont ces composants sont associés, le service global répond aux exigences en matière de RPO. Ici, comme Dataflow est un produit zonal, vous devez suivre les recommandations de la conception à haute disponibilité pour éviter toute perte de données lors d'une panne zonale. Cependant, la couche Cloud Storage est la source fiable de ces données et accepte un RPO de zéro. Cela signifie que toutes les données perdues peuvent être réingérées dans BigQuery via la zone b en cas de panne dans la zone a.
Principales décisions en termes d'architecture pour les pannes zonales - RTO de 4 heures et RPO de zéro :
- Un équilibreur de charge est utilisé pour fournir un point d'accès évolutif aux utilisateurs, ce qui permet le basculement automatique vers une autre zone. Même si le RTO est de 4 heures, les modifications manuelles des adresses IP ou même les mises à jour DNS peuvent prendre plus de temps que prévu.
- Un groupe d'instances géré régional pour la couche de calcul de visualisation des données est configuré avec plusieurs zones, mais avec des ressources minimales. Ainsi, les coûts sont optimisés et les machines virtuelles peuvent toujours faire l'objet d'un scaling horizontal rapide.
- Le service Cloud Storage régional est utilisé en tant que couche de préproduction pour l'ingestion initiale des données, ce qui permet de fournir une résilience de zone automatique.
- Dataflow est employé pour extraire des données de Cloud Storage et les transformer avant de les charger dans BigQuery. En cas de panne zonale, il s'agit d'un processus sans état qui peut être redémarré dans une autre zone.
- BigQuery fournit le backend de l'entrepôt de données pour l'interface de visualisation des données. En cas de panne zonale, toutes les données perdues sont réingérées à partir de Cloud Storage.
Principales décisions en termes d'architecture pour les pannes régionales - RTO de 24 heures et RPO de 4 heures :
- Un équilibreur de charge dans chaque région est utilisé pour fournir un point d'accès évolutif aux utilisateurs. Cloud DNS est employé pour fournir un basculement régional orchestré, mais manuel, dans la mesure où l'infrastructure de la région 2 n'est rendue disponible qu'en cas de panne régionale.
- Un groupe d'instances géré régional pour la couche de calcul de visualisation des données est configuré avec plusieurs zones, mais avec des ressources minimales. Cette opération n'est pas possible avant la reconfiguration de l'équilibreur de charge, mais elle ne nécessite aucune intervention manuelle.
- Le service Cloud Storage régional est utilisé en tant que couche de préproduction pour l'ingestion initiale des données. Le chargement est effectué simultanément dans les deux régions afin de répondre aux exigences en matière de RPO.
- Dataflow est employé pour extraire des données de Cloud Storage et les transformer avant de les charger dans BigQuery. En cas de panne régionale, les données les plus récentes de Cloud Storage sont ainsi insérées dans BigQuery.
- BigQuery fournit le backend de l'entrepôt de données. En situation normale, les données de l'entrepôt sont actualisées de façon intermittente. En cas de panne régionale, les données les plus récentes sont réingérées à partir de Cloud Storage via Dataflow.
Exemple d'architecture de niveau 1
| Criticité d'application | Panne zonale | Panne régionale |
|---|---|---|
| Niveau 1 (le plus important) |
RTO : zéro RPO : zéro |
RTO : 4 heures RPO : 1 heure |
Cette architecture décrit une infrastructure backend d'application mobile avec des utilisateurs externes qui se connectent à un ensemble de microservices exécutés dans Google Kubernetes Engine. Cloud Spanner fournit la couche de stockage de données backend pour les données en temps réel, et les données de l'historique sont transmises à un lac de données BigQuery dans chaque région.
Ici aussi, certains composants individuels de cette architecture n'acceptent pas directement le RPO requis pour leur niveau. Mais grâce à la façon dont les composants sont associés, le service global accepte ce RPO. Dans ce cas, BigQuery est utilisé pour les requêtes analytiques. Chaque région reçoit simultanément des données de Cloud Spanner.
Principales décisions en termes d'architecture pour les pannes zonales - RTO de zéro et RPO de zéro :
- Un équilibreur de charge est utilisé pour fournir un point d'accès évolutif aux utilisateurs, ce qui permet le basculement automatique vers une autre zone.
- Un cluster Google Kubernetes Engine régional est utilisé pour la couche d'application qui est configurée avec plusieurs zones. Cela permet d'atteindre le RTO de zéro dans chaque région.
- Le service Cloud Spanner multirégional est utilisé en tant que couche de persistance des données, fournissant ainsi une résilience automatique des données de zone et une cohérence des transactions.
- BigQuery fournit la fonctionnalité d'analyse de l'application. Chaque région reçoit indépendamment des données de Cloud Spanner et est accessible indépendamment par l'application.
Principales décisions en termes d'architecture pour les pannes régionales - RTO de 4 heures et RPO de 1 heure :
- Un équilibreur de charge est utilisé pour fournir un point d'accès évolutif aux utilisateurs, ce qui permet le basculement automatique vers une autre région.
- Un cluster Google Kubernetes Engine régional est utilisé pour la couche d'application qui est configurée avec plusieurs zones. En cas de panne régionale, le cluster situé dans la région alternative fait l'objet d'un scaling automatique pour supporter la charge de traitement supplémentaire.
- Le service Cloud Spanner multirégional est utilisé en tant que couche de persistance des données, fournissant ainsi une résilience automatique des données régionales et une cohérence des transactions. Il s'agit du composant clé qui permet d'atteindre le RPO interrégional de 1 heure.
- BigQuery fournit la fonctionnalité d'analyse de l'application. Chaque région reçoit indépendamment des données de Cloud Spanner et est accessible indépendamment par l'application. Cette architecture compense le composant BigQuery en lui permettant de satisfaire aux exigences globales de l'application.
Annexe : documentation de référence produit
Cette section décrit l'architecture et les fonctionnalités de reprise après sinistre des produits Google Cloud les plus couramment utilisés dans les applications clientes et pouvant facilement répondre à vos exigences en matière de reprise après sinistre.
Thèmes communs
De nombreux produits Google Cloud proposent des configurations régionales ou multirégionales. Les produits régionaux sont résilients aux pannes zonales, tandis que les produits multirégionaux et mondiaux sont résilients aux pannes régionales. En général, cela signifie que lors d'une panne, votre application subit une perturbation minimale. Afin de parvenir à ce résultat, Google suit plusieurs approches architecturales courantes qui reflètent les conseils d'architecture ci-dessus.
- Déploiement redondant : les backends d'applications et la solution de stockage des données sont déployés dans plusieurs zones d'une même région et dans plusieurs régions d'un même emplacement multirégional.
Réplication des données : les produits utilisent la réplication synchrone ou asynchrone sur les emplacements redondants.
La réplication synchrone signifie que lorsque votre application effectue un appel d'API pour créer ou modifier des données stockées par le produit, une réponse positive n'est obtenue qu'une fois que le produit a écrit les données dans plusieurs emplacements. La réplication synchrone garantit que vous ne perdrez pas l'accès à vos données lors d'une panne d'infrastructure Google Cloud, car toutes vos données sont disponibles dans l'un des emplacements de backend disponibles.
Bien que cette technique fournisse une protection maximale des données, elle peut présenter des compromis en termes de latence et de performances. Les produits multirégionaux qui utilisent la réplication synchrone font face à ce compromis de manière significative, et subissent généralement une latence supplémentaire de plusieurs dizaines ou centaines de millisecondes.
La réplication asynchrone signifie que lorsque votre application effectue un appel d'API pour créer ou modifier des données stockées par le produit, une réponse positive n'est obtenue qu'une fois que le produit a écrit les données dans un emplacement. Après votre requête d'écriture, le produit réplique vos données dans des emplacements supplémentaires.
Cette technique fournit une latence plus faible et un débit supérieur au niveau de l'API par rapport à la réplication synchrone, mais au détriment de la protection des données. Si l'emplacement dans lequel vous avez écrit des données subit une panne avant la fin de la réplication, vous perdez l'accès à ces données jusqu'à ce que la panne d'emplacement soit résolue.
Gestion des pannes grâce à l'équilibrage de charge : Google Cloud utilise l'équilibrage de charge logicielle pour acheminer les requêtes vers les backends d'applications appropriés. Comparée à d'autres approches telles que l'équilibrage de charge DNS, celle-ci réduit le temps mis par le système pour répondre à une panne. Lorsqu'une panne d'emplacement Google Cloud se produit, l'équilibreur de charge détecte rapidement que le backend déployé à cet emplacement n'est plus opérationnel et dirige toutes les requêtes vers un backend situé dans un autre emplacement. Ainsi, le produit peut continuer de diffuser les requêtes de votre application pendant une panne d'emplacement. Une fois la panne d'emplacement résolue, l'équilibreur de charge détecte que les backends de produit sont disponibles à cet emplacement et reprend la transmission du trafic.
Compute Engine
Compute Engine est l'offre Infrastructure as a Service de Google Cloud. Cette solution s'appuie sur l'infrastructure mondiale de Google pour fournir des machines virtuelles (et des services associés) aux clients.
Les instances Compute Engine sont des ressources zonales. Par conséquent, elles sont indisponibles par défaut en cas de panne zonale. Compute Engine propose des groupes d'instances gérés (MIG) qui peuvent ajouter automatiquement des VM supplémentaires à partir de modèles d'instances préconfigurés, dans une seule ou dans plusieurs zones d'une région. Les MIG conviennent parfaitement aux applications sans état qui nécessitent une résilience aux pertes de zone, mais ils exigent également une configuration et une planification des ressources. Vous pouvez exploiter plusieurs MIG régionaux afin de bénéficier d'une résilience aux pannes régionales pour les applications sans état.
Les applications comportant des charges de travail avec état peuvent également utiliser des MIG avec état (bêta), mais des précautions supplémentaires doivent être prises lors de la planification de la capacité, car ils ne donnent pas lieu à un scaling horizontal. Quel que soit le scénario, il est important de configurer correctement et de tester les modèles d'instances Compute Engine et les MIG à l'avance, afin de garantir le bon fonctionnement du basculement vers d'autres zones. Pour en savoir plus, consultez la section Modèles d'architecture ci-dessus.
Dataproc
Dataproc propose des fonctionnalités de traitement des données par flux et par lot. Le service est conçu en tant que plan de contrôle régional permettant aux utilisateurs de gérer les clusters Dataproc. Le plan de contrôle ne dépend pas d'une zone individuelle d'une région donnée. Par conséquent, vous conservez l'accès aux API Dataproc lors d'une panne zonale, y compris la possibilité de créer des clusters.
Les clusters sont exécutés dans Compute Engine. Étant donné que les clusters sont des ressources zonales, ils deviennent indisponibles ou sont détruits en cas de panne zonale. Dataproc ne prend pas automatiquement d'instantanés de l'état des clusters. Une panne zonale peut donc causer la perte des données en cours de traitement. Dataproc ne conserve pas les données utilisateur au sein du service. Les utilisateurs peuvent configurer leurs pipelines de façon à écrire les résultats dans plusieurs datastores. Vous devez songer à l'architecture du datastore et choisir un produit proposant la résilience aux sinistres requise.
Si une zone subit une panne, vous pouvez recréer une instance du cluster dans une autre zone de deux manières : en spécifiant une zone différente ou en utilisant la fonctionnalité de sélection de zone automatique dans Dataproc, qui choisira automatiquement une zone disponible. Une fois le cluster disponible, le traitement des données peut reprendre. Vous pouvez également exécuter un cluster sur lequel le mode haute disponibilité est activé, ce qui réduit la probabilité qu'une panne zonale partielle survienne sur un nœud maître et, par conséquent, sur le cluster tout entier.
Dataflow
Dataflow est le service de traitement de données sans serveur entièrement géré de Google Cloud pour les pipelines de traitement par flux et par lot. Les tâches Dataflow sont zonales par nature, et la configuration par défaut ne conserve pas les résultats des calculs intermédiaires lors d'une panne zonale. Une approche type pour récupérer ces pipelines Dataflow par défaut consiste à redémarrer une tâche dans une autre zone ou région, puis à retraiter les données d'entrée.
Concevoir l'architecture de pipelines Dataflow pour la haute disponibilité
En cas de panne zonale ou régionale, vous pouvez réutiliser le même abonnement au sujet Pub/Sub pour éviter de perdre des données. Dans le cadre de la garantie "exactement une fois" de Dataflow, le service ne confirme les messages dans Pub/Sub que s'ils ont été conservés dans la destination, ou s'ils ont fait l'objet d'une opération de regroupement/fenêtrage et ont été enregistrés dans l'état du pipeline durable de Dataflow. S'il n'y a aucune opération de regroupement/fenêtrage, un basculement qui réutilise l'abonnement et qui est effectué vers une autre tâche Dataflow d'une autre zone ou région n'entraîne aucune perte des données de sortie du pipeline.
Si le pipeline utilise le regroupement ou le fenêtrage, vous pouvez recourir à la fonctionnalité de recherche de Pub/Sub ou à la fonctionnalité de réouverture de Kafka après une panne zonale ou régionale pour retraiter les éléments de données et obtenir les mêmes résultats de calcul. La perte de données des résultats du pipeline peut être réduite à zéro élément si la logique métier utilisée par le pipeline ne s'appuie pas sur les données avant la panne. Si la logique métier du pipeline s'appuie sur les données traitées avant la panne (par exemple, si des fenêtres glissantes de longue durée sont utilisées ou si une fenêtre globale stocke des compteurs toujours croissants), Dataflow propose une fonctionnalité de création d'instantanés (actuellement en version bêta) qui fournit une sauvegarde d'instantané de l'état d'un pipeline.
BigQuery
BigQuery est un entrepôt de données cloud sans serveur, hautement évolutif et économique, conçu pour optimiser l'agilité des entreprises. Ce service propose deux options de configuration liées à la disponibilité pour les ensembles de données utilisateur.
Configuration dans une seule région
Avec une configuration dans une seule région, les données sont stockées de manière redondante dans deux zones d'une même région. Les données écrites dans BigQuery sont d'abord écrites dans la zone principale, puis répliquées de manière asynchrone dans une zone secondaire. Cette mise en œuvre vous fournit une protection contre l'indisponibilité d'une zone de la région. Les données qui ont été écrites dans la zone principale, mais qui n'ont pas été répliquées dans la zone secondaire au moment d'une panne zonale, sont indisponibles jusqu'à ce que la panne soit résolue. Dans le cas peu probable où une zone est détruite, ces données peuvent être définitivement perdues.
Configuration multirégionale (États-Unis/UE)
À l'instar de la configuration dans une seule région, la configuration multirégionale États-Unis/EU permet de stocker les données de manière redondante dans deux zones d'une même région. En outre, BigQuery conserve une copie de sauvegarde supplémentaire des données dans une deuxième région. En cas de panne dans la région principale, les données sont diffusées à partir de la région secondaire. Les données qui n'ont pas été répliquées sont indisponibles jusqu'à la restauration de la région principale.
Google Kubernetes Engine
Google Kubernetes Engine (GKE) propose un service Kubernetes géré en simplifiant le déploiement d'applications conteneurisées sur Google Cloud. Vous pouvez choisir entre les topologies de cluster régionale et zonale.
- Lors de la création d'un cluster zonal, GKE provisionne une machine de plan de contrôle dans la zone choisie, ainsi que des machines de calcul (nœuds) au sein de cette même zone.
- Pour les clusters régionaux, GKE provisionne trois machines de plan de contrôle dans trois zones différentes de la région choisie. Par défaut, les nœuds sont également répartis sur trois zones, bien que vous puissiez choisir de créer un cluster régional avec des nœuds provisionnés dans une seule zone.
- Les clusters multizones sont semblables aux clusters zonaux, car ils incluent une machine maître, mais ils permettent aussi de répartir les nœuds sur plusieurs zones.
Panne zonale : pour éviter les pannes zonales, utilisez des clusters régionaux. Le plan de contrôle et les nœuds sont répartis sur trois zones différentes d'une même région. Les pannes zonales n'affectent pas le plan de contrôle ni les nœuds de calcul déployés dans les deux autres zones.
Panne régionale : l'atténuation d'une panne régionale nécessite un déploiement dans plusieurs régions. Bien que la topologie multirégionale ne soit actuellement pas fournie de manière intégrée avec les produits, cette approche a été adoptée par plusieurs clients GKE et peut être mise en œuvre manuellement. Vous pouvez créer plusieurs clusters régionaux pour répliquer vos charges de travail sur plusieurs régions, et contrôler le trafic vers ces clusters à l'aide d'une entrée multicluster.
Cloud Key Management Service
Cloud Key Management Service (Cloud KMS) fournit une gestion des ressources de clé cryptographique à la fois évolutive et hautement durable. Le service stocke toutes ses données et métadonnées dans des bases de données Cloud Spanner, qui offrent une durabilité et une disponibilité des données élevées avec une réplication synchrone.
Les ressources Cloud KMS peuvent être créées dans une seule région, dans plusieurs régions ou à l'échelle mondiale.
En cas de panne zonale, Cloud KMS continue de diffuser de façon ininterrompue les requêtes qui proviennent d'une autre zone de la même région ou d'une région différente. Les données étant répliquées de manière synchrone, il n'y a aucune perte ni corruption de données. Une fois la panne zonale résolue, la redondance complète est restaurée.
En cas de panne régionale, les ressources régionales de la région affectée sont hors ligne jusqu'à ce que la région redevienne disponible. Notez que même au sein d'une région, au moins trois instances dupliquées sont gérées dans des zones distinctes. Si une disponibilité plus élevée est requise, nous vous conseillons de stocker les ressources dans une configuration multirégionale ou mondiale. Les configurations multirégionales et mondiales sont conçues pour rester disponibles durant une panne régionale, grâce à un stockage géoredondant et à une diffusion des données dans plusieurs régions.
Cloud Identity
Les services Cloud Identity sont répartis sur plusieurs régions et utilisent l'équilibrage de charge dynamique. Cloud Identity ne permet pas aux utilisateurs de sélectionner un champ d'application pour les ressources. Si une zone ou une région spécifique subit une panne, le trafic est automatiquement distribué vers d'autres zones ou régions.
Dans la plupart des cas, les données persistantes sont mises en miroir dans plusieurs régions grâce à la réplication synchrone. Pour des raisons de performances, certains systèmes (tels que les caches ou les modifications affectant un grand nombre d'entités) sont répliqués de manière asynchrone entre les régions. Si la région principale qui contient les données les plus récentes subit une panne, Cloud Identity diffuse des données obsolètes depuis un autre emplacement jusqu'à ce que la région principale redevienne disponible.
Persistent Disk
Les disques persistants sont disponibles dans les configurations zonales et régionales.
Les disques persistants zonaux sont hébergés dans une seule zone. Si la zone du disque est indisponible, le disque persistant l'est aussi jusqu'à ce que la panne zonale soit résolue.
Les disques persistants régionaux permettent une réplication synchrone des données entre deux zones d'une même région. En cas de panne dans la zone de votre machine virtuelle, vous pouvez forcer l'association d'un disque persistant régional à une instance de VM dans la zone secondaire du disque. Pour cela, vous devez soit démarrer une autre instance de VM dans cette zone, soit y conserver une instance de VM de secours à chaud (hot standby).
Cloud Storage
Cloud Storage fournit une solution de stockage d'objets unifiée, évolutive et hautement durable à l'échelle mondiale. Les buckets Cloud Storage peuvent être créés dans une seule région, dans deux régions ou dans plusieurs régions d'un même continent.
Si une zone subit une panne, les données de la zone indisponible sont diffusées automatiquement et de manière transparente depuis un autre emplacement de la région. Les données et les métadonnées sont stockées de manière redondante entre les zones, et ce, dès l'écriture initiale. Aucune écriture n'est perdue lorsqu'une zone devient indisponible.
En cas de panne régionale, les buckets régionaux de la région affectée sont hors ligne jusqu'à ce que la région redevienne disponible. Si une disponibilité plus élevée est requise, nous vous conseillons de stocker les données dans une configuration birégionale ou multirégionale. Les emplacements birégionaux et multirégionaux sont conçus pour rester disponibles durant une panne régionale, grâce à un stockage géoredondant dans plusieurs régions utilisant la réplication asynchrone.
Cloud Storage exploite Cloud Load Balancing pour diffuser les buckets birégionaux et multirégionaux à partir de plusieurs régions. En cas de panne régionale, la diffusion n'est pas interrompue. Comme la géoredondance est réalisée de manière asynchrone, certaines données récemment écrites peuvent ne pas être accessibles lors de la panne et peuvent être perdues en cas de destruction physique des données dans la région affectée.
Container Registry
Container Registry propose une mise en œuvre hébergée et évolutive de Docker Registry qui stocke de manière sécurisée et privée les images de conteneur Docker. La solution met en œuvre l'API HTTP Docker Registry.
Container Registry est un service mondial qui stocke les métadonnées d'images de manière synchrone dans plusieurs zones et régions par défaut. Les images de conteneurs sont stockées dans des buckets multirégionaux Cloud Storage. Cette stratégie de stockage permet à Container Registry de fournir une résilience aux pannes zonales quel que soit le scénario, ainsi qu'une résilience aux pannes régionales pour toutes les données qui ont été répliquées de manière asynchrone dans plusieurs régions par Cloud Storage.
Pub/Sub
Pub/Sub est un service de messagerie pour l'intégration d'applications et l'analyse de flux. Les sujets Pub/Sub sont mondiaux, ce qui veut dire qu'ils sont visibles et accessibles depuis n'importe quel emplacement Google Cloud. Chaque message n'est toutefois stocké que dans une seule région Google Cloud : la plus proche de l'éditeur et celle autorisée par la règle d'emplacement des ressources. Ainsi, un sujet peut contenir des messages stockés dans différentes régions Google Cloud. La règle de stockage des messages Pub/Sub peut restreindre les régions où les messages sont stockés.
Panne zonale : lorsqu'un message Pub/Sub est publié, il est écrit de manière synchrone dans l'espace de stockage d'au moins deux zones de la région. Par conséquent, si une zone devient indisponible, il n'y a aucun impact pour le client.
Panne régionale : lors d'une panne régionale, les messages stockés dans la région concernée sont inaccessibles. Les opérations d'administration (telles que la création et la suppression de sujets et d'abonnements) sont multirégionales et résilientes aux pannes d'une seule région Google Cloud. Les opérations de publication sont également résilientes aux pannes régionales, à condition qu'au moins une région autorisée par la règle de stockage des messages soit disponible et que votre application utilise le point de terminaison global (pubsub.googleapis.com) ou plusieurs points de terminaison régionaux.
Par défaut, Pub/Sub ne restreint pas l'emplacement de stockage des messages.
Si votre application repose sur le tri des messages, prenez connaissance des recommandations détaillées de l'équipe Pub/Sub. Les garanties de tri des messages sont fournies par région, et peuvent subir des interruptions si vous utilisez un point de terminaison global.
Cloud Composer
Cloud Composer est la mise en œuvre Apache Airflow gérée de Google Cloud. Le service est conçu en tant que plan de contrôle régional permettant aux utilisateurs de gérer les clusters Cloud Composer. Le plan de contrôle ne dépend pas d'une zone individuelle d'une région donnée. Par conséquent, vous conservez l'accès aux API Cloud Composer lors d'une panne zonale, y compris la possibilité de créer des clusters.
Les clusters sont exécutés dans Google Kubernetes Engine. Étant donné que les clusters sont des ressources zonales, ils deviennent indisponibles ou sont détruits en cas de panne zonale. Les workflows en cours d'exécution au moment de la panne peuvent être arrêtés avant leur terme. Cela signifie que la panne entraîne la perte de l'état des workflows partiellement exécutés, y compris des actions externes configurées par l'utilisateur dans le cadre du workflow. Selon le workflow, cette perte peut entraîner des incohérences en externe, par exemple, si le workflow s'arrête au milieu d'une exécution en plusieurs étapes visant à modifier des datastores externes. Par conséquent, vous devez tenir compte du processus de reprise lorsque vous concevez votre workflow Airflow, et envisager comment détecter l'état des workflows partiellement non exécutés, réparer les modifications de données partielles, etc.
Lors d'une panne zonale, vous pouvez choisir d'utiliser Cloud Composer pour démarrer une nouvelle instance du cluster dans une autre zone. Une fois le cluster disponible, le workflow peut reprendre. Selon vos préférences, vous souhaiterez peut-être exécuter un cluster d'instance dupliquée inactif dans une autre zone et basculer vers cette instance dupliquée en cas de panne zonale.
Cloud SQL
Cloud SQL est un service de base de données relationnelle entièrement géré pour MySQL, PostgreSQL et SQL Server. Le service exploite des machines virtuelles Compute Engine gérées pour exécuter le logiciel de base de données. Il offre aussi une configuration haute disponibilité pour la redondance régionale, protégeant ainsi la base de données contre les pannes zonales. Les instances dupliquées interrégionales peuvent être provisionnées pour protéger la base de données contre les pannes régionales. Étant donné que le produit propose également une option zonale, qui n'est pas résiliente aux pannes zonales ni régionales, veillez à bien sélectionner la configuration haute disponibilité, la configuration avec instances dupliquées interrégionales ou les deux.
Panne zonale : l'option Haute disponibilité crée une instance de VM principale et une instance de secours dans deux zones distinctes d'une même région. En situation normale, l'instance de VM principale diffuse toutes les requêtes en écrivant les fichiers de base de données sur un disque persistant régional, qui est répliqué de manière synchrone sur les zones principale et de secours. Si une panne zonale affecte l'instance principale, Cloud SQL lance un basculement pendant lequel le disque persistant est associé à la VM de secours et le trafic est réacheminé.
Au cours de ce processus, la base de données doit être initialisée, ce qui inclut le traitement de toutes les transactions qui ont été écrites dans le journal des transactions, mais qui n'ont pas été appliquées à la base de données. Le nombre et le type de transactions non traitées peuvent augmenter le temps RTO. Un grand nombre d'écritures récentes peut causer une accumulation de transactions non traitées en attente. Le temps RTO est fortement affecté par (a) l'activité liée à un grand nombre d'écritures récentes et (b) les modifications récentes apportées aux schémas de base de données.
Enfin, une fois la panne zonale résolue, vous pouvez déclencher manuellement une opération de basculement afin de reprendre la diffusion dans la zone principale.
Pour en savoir plus sur l'option de haute disponibilité, consultez la documentation sur la haute disponibilité de Cloud SQL.
Panne régionale : l'option Instance dupliquée interrégionale protège votre base de données contre les pannes régionales en créant des instances dupliquées avec accès en lecture de votre instance principale dans d'autres régions. La réplication interrégionale utilise la réplication asynchrone, qui permet à l'instance principale d'effectuer un commit des transactions avant qu'elles ne soient validées sur les instances dupliquées. Le délai entre le commit d'une transaction sur l'instance principale et le commit d'une transaction sur l'instance dupliquée est appelé "délai de réplication" (et peut être surveillé). Cette métrique reflète à la fois les transactions qui n'ont pas été envoyées de l'instance principale aux instances dupliquées et les transactions qui ont été reçues, mais qui n'ont pas été traitées par l'instance dupliquée. Les transactions qui n'ont pas été envoyées à l'instance dupliquée deviennent indisponibles en cas de panne régionale. Les transactions qui ont été reçues, mais qui n'ont pas été traitées par l'instance dupliquée, affectent le temps de récupération comme décrit ci-dessous.
Cloud SQL vous recommande de tester votre charge de travail avec une configuration comprenant une instance dupliquée pour établir une limite sûre de transactions par seconde (TPS), qui correspond au nombre de TPS le plus élevé n'augmentant pas le délai de réplication. Si votre charge de travail dépasse la limite sûre de TPS, le délai de réplication augmente, affectant ainsi négativement les valeurs RPO et RTO. En règle générale, nous vous conseillons d'éviter d'utiliser des configurations incluant de petites instances (moins de deux cœurs de processeur virtuel, disques de moins de 100 Go ou disques persistants HDD), qui sont sensibles au délai de réplication.
En cas de panne régionale, vous devez décider de promouvoir manuellement ou non une instance dupliquée avec accès en lecture. Cette opération est manuelle, car la promotion peut causer une situation de split-brain, où l'instance dupliquée promue accepte de nouvelles transactions malgré le retard pris sur l'instance principale au moment de la promotion. Cette situation peut poser problème une fois la panne régionale résolue, et vous devrez rapprocher les transactions qui n'ont pas été propagées de l'instance principale à l'instance dupliquée. Si ce scénario nuit à vos besoins, vous pouvez envisager d'utiliser un produit de base de données à réplication synchrone interrégionale, tel que Cloud Spanner.
Une fois déclenché par l'utilisateur, le processus de promotion suit des étapes semblables à celles de l'activation d'une instance de secours dans la configuration haute disponibilité : l'instance dupliquée avec accès en lecture doit traiter le journal des transactions et l'équilibreur de charge doit rediriger le trafic. Le traitement du journal des transactions augmente le temps de récupération total.
Pour en savoir plus sur l'option "Instance dupliquée interrégionale", consultez la documentation sur les instances dupliquées interrégionales Cloud SQL.
Cloud Logging
Cloud Logging se compose de deux éléments principaux : le routeur de journaux et l'espace de stockage Cloud Logging.
Le routeur de journaux gère les événements de journaux de streaming et dirige les journaux vers Cloud Storage, Pub/Sub, BigQuery ou l'espace de stockage Cloud Logging.
Le stockage Cloud Logging est un service permettant de stocker et d'interroger des journaux, ainsi que d'en gérer la conformité. Ce service est compatible avec de nombreux utilisateurs et workflows, y compris pour le développement, la conformité, le dépannage et les alertes proactives.
Routeur de journaux et journaux entrants : lors d'une panne zonale, l'API Cloud Logging achemine les journaux vers d'autres zones de la région. Normalement, les journaux acheminés par le routeur de journaux vers Cloud Logging, BigQuery ou Pub/Sub sont écrits le plus rapidement possible dans leur destination finale, tandis que les journaux envoyés à Cloud Storage sont mis en mémoire tampon et écrits chaque heure sous forme de lots.
Entrées de journal : en cas de panne zonale ou régionale, les entrées de journal qui ont été mises en mémoire tampon dans la zone ou dans la région affectée et qui n'ont pas été écrites dans la destination d'exportation deviennent inaccessibles. Les métriques basées sur les journaux sont également calculées dans le routeur de journaux et soumises aux mêmes contraintes. Une fois envoyés à l'emplacement d'exportation des journaux sélectionné, les journaux sont répliqués conformément au service de destination. Les journaux exportés vers l'espace de stockage Cloud Logging sont répliqués de manière synchrone sur deux zones d'une région. Pour en savoir plus sur le comportement de réplication d'autres types de destination, veuillez consulter la section correspondante de cet article. Notez que les journaux exportés vers Cloud Storage sont regroupés et écrits toutes les heures. Par conséquent, nous vous recommandons d'utiliser le stockage Cloud Logging, BigQuery ou Pub/Sub afin de minimiser la quantité de données affectées par une panne.
Métadonnées de journal : les métadonnées telles que la configuration du récepteur et la configuration des exclusions sont stockées mondialement, mais mises en cache localement. Par conséquent, en cas de panne, les instances régionales du routeur de journaux continuent de fonctionner. Les pannes limitées à une seule région n'ont aucun impact en dehors de la région.
Cloud Spanner
Cloud Spanner est une base de données évolutive, à disponibilité élevée, multiversion, répliquée de manière synchrone et hautement cohérente avec une sémantique relationnelle.
Les instances Cloud Spanner régionales répliquent les données de manière synchrone sur trois zones d'une même région. Une écriture sur une instance Cloud Spanner régionale est envoyée de manière synchrone aux trois instances dupliquées et confirmée auprès du client après qu'au moins deux instances dupliquées (le quorum majoritaire de 2 sur 3) ont validé l'écriture. Ainsi, Cloud Spanner est résilient aux pannes de zone en fournissant un accès à toutes les données, car les dernières écritures ont été conservées et un quorum global pour les écritures peut toujours être obtenu avec deux instances dupliquées.
Les instances multirégionales Cloud Spanner incluent un service d'écriture répliquée qui réplique les données de manière synchrone dans cinq zones situées dans trois régions (deux instances dupliquées en lecture/écriture dans la région principale par défaut et une autre région, et une instance dupliquée dans la région témoin). Une écriture sur une instance Cloud Spanner multirégionale est confirmée après qu'au moins trois instances dupliquées (quorum majoritaire de trois sur cinq) ont validé l'écriture. En cas de défaillance d'une zone ou d'une région, Cloud Spanner a accès à toutes les données (y compris les dernières écritures) et diffuse des requêtes de lecture/écriture, car les données sont conservées dans au moins trois zones dans deux régions au moment où l'écriture est confirmée pour le client.
Pour en savoir plus sur ces configurations, consultez la documentation sur les instances de Cloud Spanner. Vous pouvez aussi consulter la documentation sur la réplication pour en savoir plus sur le fonctionnement de la réplication Cloud Spanner.