Migrer dans des régions Google Cloud : concevoir des environnements régionaux résilients sur Google Cloud

Last reviewed 2024-12-08 UTC

Ce document vous aide à concevoir des environnements régionaux résilients sur Google Cloud. Il est utile si vous envisagez de migrer un environnement régional, ou si vous évaluez l'opportunité de le faire à l'avenir et souhaitez découvrir à quoi la migration pourrait ressembler.

Ce document fait partie d'une série :

Ce document vise à fournir des conseils sur la conception d'environnements régionaux résilients sur Google Cloud, et se concentre sur les composants d'architecture suivants :

Dans les instructions du présent document, nous supposons que vous concevez et implémentez des environnements dans une seule région. Si vous utilisez actuellement un environnement régional, vous pourrez migrer vers un environnement multirégional ultérieurement. Si vous envisagez une migration et une évolution futures de vos environnements zonaux et régionaux vers des environnements multirégionaux, consultez la page Migrer dans des régions Google Cloud : premiers pas.

Propriétés des différents archétypes de déploiement

Les produits Google Cloud sont fournis dans de nombreuses régions et zones. Les régions correspondent à des espaces géographiques indépendants qui sont constitués de zones. Les zones et les régions sont des abstractions logiques des ressources physiques sous-jacentes. Une région comprend au moins trois zones hébergées dans au moins trois centres de données physiques. Les régions Mexico, Montréal et Osaka comportent trois zones hébergées dans un ou deux centres de données physiques. Ces régions sont en cours d'extension à au moins trois centres de données physiques. Lorsque vous concevez vos solutions dans Google Cloud, tenez compte des conseils fournis dans les sections Zones Cloud, Contrats de niveau de service Google Cloud Platform et Documentation produit Google Cloud appropriées.

Lorsque vous concevez votre environnement Google Cloud, vous pouvez choisir entre les archétypes de déploiement suivants, présentés par ordre de fiabilité accrue et de coûts opérationnels :

  • Zonal: vous provisionnez des ressources Google Cloud dans une seule zone au sein d'une région, et vous utilisez des services zonaux où ils sont disponibles. Si les services zonaux ne sont pas disponibles, utilisez des services régionaux.
  • Régional: vous provisionnez des ressources Google Cloud dans plusieurs zones d'une même région et vous utilisez des services régionaux lorsque cela est possible.
  • Multirégional: vous provisionnez des ressources Google Cloud dans plusieurs zones de différentes régions. Les ressources zonales sont provisionnées dans une ou plusieurs zones de chaque région.
  • Mondial: vous provisionnez des ressources Google Cloud dans plusieurs zones de différentes régions du monde. Les ressources zonales sont provisionnées dans une ou plusieurs zones de chaque région.

Les archétypes de déploiement ci-dessus ont des propriétés de fiabilité différentes. Vous pouvez les utiliser pour fournir les garanties de fiabilité nécessaires à votre environnement. Par exemple, un environnement multirégional est plus susceptible de subsister en cas de panne régionale qu'un environnement régional ou zonal. Pour en savoir plus sur les propriétés de fiabilité de chaque archétype de déploiement, consultez la section Exploiter les zones et les régions pour améliorer la fiabilité et le guide de fiabilité de l'infrastructure Google Cloud.

La conception, l'implémentation et l'exploitation d'un environnement basé sur ces archétypes de déploiement nécessitent différents niveaux d'effort en raison des propriétés de coût et de complexité de chaque archétype de déploiement. Par exemple, un environnement zonal peut être moins cher et plus facile à concevoir, à implémenter et à utiliser qu'un environnement régional ou multirégional. Les efforts et les coûts potentiellement réduits de l'environnement zonal sont dus aux frais supplémentaires que vous devez gérer pour coordonner les charges de travail, les données et les processus qui se trouvent dans différentes régions.

Le tableau suivant récapitule la distribution des ressources, les propriétés de fiabilité et la complexité de chaque archétype de déploiement. Il décrit également les efforts nécessaires à la conception et à l'implémentation d'un environnement basé sur chacun d'eux.

Nom de l'archétype de déploiement Distribution des ressources Capacité de résistance Complexité de la conception
Environnement zonal Dans une seule zone Échecs des ressources Nécessite une coordination dans une seule zone
Environnement régional Dans plusieurs zones d'une même région Échecs des ressources, pannes zonales Nécessite une coordination dans plusieurs zones d'une même région
Environnement multirégional Dans plusieurs zones de différentes régions Échecs des ressources, pannes zonales, pannes régionales, pannes multirégionales Nécessite une coordination dans plusieurs zones de différentes régions
Environnement global Dans plusieurs zones de différentes régions à travers le monde Échecs des ressources, pannes zonales, pannes régionales, pannes multirégionales Nécessite une coordination dans plusieurs zones de différentes régions

Pour en savoir plus sur ces archétypes de déploiement et d'autres, consultez la section Archétypes de déploiement Google Cloud.

Choisir des archétypes de déploiement pour vos environnements

Pour choisir l'archétype de déploiement qui répond le mieux à vos besoins, procédez comme suit:

  1. Définissez les modèles de défaillance contre lesquels vous souhaitez vous protéger.
  2. Évaluez les archétypes de déploiement pour déterminer celui qui correspond le mieux à vos besoins.

Définir des modèles de défaillance

Pour définir des modèles de défaillance, posez-vous les questions suivantes :

  • Quels composants de votre environnement nécessitent des modèles de défaillance ? Les modèles de défaillance peuvent s'appliquer à toutes les ressources que vous provisionnez ou déployez sur Google Cloud. Un modèle de défaillance peut s'appliquer à des ressources individuelles, ou à toutes les ressources d'une zone ou d'une région. Nous vous recommandons d'appliquer un modèle de défaillance à tout ce qui vous procure de la valeur, comme les charges de travail, les données, les processus et toute ressource Google Cloud.
  • Quelles sont vos exigences en termes de haute disponibilité, de continuité des opérations et de reprise après sinistre pour ces composants ? Chaque composant de votre environnement peut avoir ses propres objectifs de niveau de service (SLO) qui définissent les niveaux de service acceptables pour ce composant, ainsi que ses propres exigences en termes de reprise après sinistre. Par exemple, le contrat de niveau de service de Compute Engine indique que si vous devez atteindre une disponibilité mensuelle supérieure à 99,5 %, vous devez provisionner des instances dans plusieurs zones d'une même région. Pour en savoir plus, consultez le guide de planification de la reprise après sinistre.
  • Combien de modèles de défaillance devez-vous définir ? Dans un environnement type, les composants ne doivent pas tous fournir les mêmes garanties de fiabilité. Si vous proposez des garanties de disponibilité et de résilience plus élevées, vous devez généralement consacrer davantage d'efforts et de ressources. Lorsque vous définissez vos modèles de défaillance, nous vous recommandons d'envisager une approche dans laquelle vous définissez plusieurs modèles de défaillance pour chaque composant, et non pas un seul pour tous vos composants. Par exemple, les charges de travail stratégiques doivent généralement offrir une fiabilité plus élevée, bien qu'il soit acceptable de proposer des garanties inférieures pour d'autres charges de travail moins critiques.
  • De combien de ressources les modèles de défaillance ont-ils besoin pour se protéger contre les défaillances ? Pour vous protéger contre les modèles de défaillance que vous avez définis, vous consommez des ressources telles que le temps et les coûts nécessaires pour concevoir, provisionner et configurer les mécanismes de protection et les processus automatisés. Nous vous recommandons d'évaluer le nombre de ressources que vous devez protéger contre chaque modèle de défaillance que vous définissez.
  • Comment allez-vous détecter les défaillances ? Il est essentiel de pouvoir détecter qu'une défaillance se produit ou est sur le point de se produire afin que vous puissiez entamer des processus d'atténuation, de récupération et de rapprochement. Par exemple, vous pouvez configurer Google Cloud Observability pour être averti en cas de dégradation des performances.
  • Comment tester les modèles de défaillance que vous définissez ? Lorsque vous définissez des modèles de défaillance, nous vous recommandons de réfléchir à la manière de tester chacun d'eux en continu afin de vérifier s'ils assurent une protection optimale contre les défaillances auxquelles ils sont destinés. Par exemple, vous pouvez injecter des pannes dans vos environnements ou évaluer leur capacité à tolérer les défaillances en pratiquant l'ingénierie du chaos.
  • Quel est l'impact attendu d'un modèle de défaillance particulier ? Pour mieux comprendre l'impact qu'une défaillance est susceptible d'avoir sur votre activité, nous vous recommandons d'estimer, pour chaque modèle de défaillance, les conséquences de chaque défaillance pour laquelle le modèle est conçu. Cette compréhension est utile pour établir des priorités et les ordres de récupération, de sorte que vous et vos processus puissent traiter les composants les plus critiques en premier.
  • Quelle est la durée de vie attendue des défaillances dans les modèles que vous définissez ? La durée d'une défaillance peut grandement affecter les plans d'atténuation et de récupération. Par conséquent, lorsque vous définissez des modèles de défaillance, nous vous recommandons de tenir compte de la durée d'une défaillance. Lorsque vous évaluez la durée d'une défaillance, tenez également compte du temps nécessaire à son identification, à son rapprochement et à la restauration des ressources ayant échoué.

Pour en savoir plus sur les modèles de défaillance et la conception d'un plan de reprise après sinistre fiable, consultez la page Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud.

Évaluer les archétypes de déploiement

Une fois que vous avez défini les modèles de défaillance contre lesquels vous souhaitez vous prémunir, vous devez évaluer les archétypes de déploiement afin de déterminer celui qui répond le mieux à vos besoins. Lors de l'évaluation des archétypes de déploiement, posez-vous les questions suivantes :

  • De combien d'archétypes de déploiement avez-vous besoin ? Il n'est pas nécessaire de choisir un seul archétype de déploiement adapté à tous vos environnements. Vous pouvez implémenter une approche hybride dans laquelle vous choisissez plusieurs archétypes de déploiement en fonction des garanties de fiabilité dont vous avez besoin pour vous protéger contre les modèles de défaillance que vous avez définis. Par exemple, si vous avez défini deux modèles de défaillance (l'un nécessitant un environnement zonal et l'autre nécessitant un environnement régional), vous pouvez choisir différents archétypes de déploiement pour vous protéger contre chaque modèle de défaillance. Si vous optez pour plusieurs archétypes de déploiement, nous vous recommandons d'évaluer l'augmentation potentielle de la complexité de la conception, de l'implémentation et de l'exploitation de plusieurs environnements.
  • De combien de ressources avez-vous besoin pour concevoir et implémenter des environnements en fonction des archétypes de déploiement ? La conception et l'implémentation de tout type d'environnement nécessitent des ressources et des efforts. Nous vous recommandons d'évaluer le nombre de ressources dont vous pensez avoir besoin pour concevoir et implémenter chaque environnement en fonction de l'archétype que vous choisissez. Une fois que vous avez déterminé de manière exhaustive le nombre de ressources nécessaires, vous pouvez trouver un compromis entre les garanties de fiabilité offertes par chaque archétype de déploiement, et le coût et la complexité de la conception, de l'implémentation et de la gestion des environnements basés sur ces archétypes.
  • Envisagez-vous de migrer un environnement basé sur un archétype de déploiement vers un environnement basé sur un archétype différent ? À l'avenir, vous pourrez migrer des charges de travail, des données et des processus d'un environnement Google Cloud vers un autre environnement Google Cloud. Par exemple, vous pouvez migrer d'un environnement zonal vers un environnement régional.
  • Dans quelle mesure les environnements que vous concevez et implémentez sont-ils critiques pour les opérations ? Les environnements stratégiques nécessitent probablement plus de garanties de fiabilité. Par exemple, vous pouvez choisir de concevoir et d'implémenter un environnement multirégional pour les charges de travail, les données et les processus stratégiques, et un environnement zonal ou régional pour les charges de travail, les données et les processus moins importants.
  • Avez-vous besoin des fonctionnalités proposées par des archétypes de déploiement particuliers pour certains environnements ? Outre les garanties de fiabilité proposées par chaque archétype de déploiement, les archétypes offrent également différentes garanties en matière d'évolutivité, de proximité géographique, de latence et de localité des données. Nous vous recommandons de prendre en compte ces garanties lorsque vous choisissez les archétypes de déploiement pour vos environnements.

Outre les aspects techniques des modes de défaillance que vous avez définis en suivant les instructions précédentes, nous vous recommandons de prendre en compte toutes les exigences non fonctionnelles, telles que les exigences réglementaires, de localité et de souveraineté. Ces exigences peuvent limiter les options disponibles. Par exemple, si vous devez répondre à des exigences réglementaires qui nécessitent l'utilisation d'une région spécifique, vous devez concevoir et implémenter un environnement régional ou un environnement zonal dans cette région.

Choisir une région Google Cloud pour votre environnement

Lorsque vous commencez à concevoir vos environnements régionaux, vous devez déterminer la région qui répond le mieux aux exigences de chaque environnement. Les sections suivantes décrivent ces deux catégories de critères de sélection :

  • Critères fonctionnels. Ces critères s'appliquent aux produits Google Cloud proposés dans une région spécifique. Ils déterminent si une région donnée répond à vos exigences en termes de latence et de proximité géographique avec les utilisateurs et d'autres environnements externes à Google Cloud. Par exemple, si vos charges de travail et vos données ont des exigences de latence pour vos utilisateurs ou d'autres environnements externes à Google Cloud, vous devrez peut-être choisir la région la plus proche de vos utilisateurs ou des autres environnements pour minimiser cette latence.
  • Critères non fonctionnels. Ces critères concernent les prix des produits associés à des régions spécifiques, les exigences d'empreinte carbone, ainsi que les exigences et réglementations obligatoires en vigueur pour votre entreprise. Par exemple, les marchés hautement réglementés tels que la banque et le secteur public ont des exigences très strictes et spécifiques concernant la localité des données et des charges de travail, ainsi que sur la manière de partager l'infrastructure du fournisseur cloud avec d'autres clients.

Si vous choisissez une région Google Cloud particulière, vous pourrez migrer vers des régions différentes ou vers un environnement multirégional ultérieurement. Si vous envisagez une migration vers d'autres régions, consultez la page Migrer dans des régions Google Cloud : premiers pas.

Évaluer les critères fonctionnels

Pour évaluer les critères fonctionnels, posez-vous les questions suivantes :

  • Quelles sont vos exigences en termes de proximité géographique ? Lors de la sélection d'une région Google Cloud, vous devrez peut-être placer vos charges de travail, vos données et vos processus à proximité de vos utilisateurs ou de vos environnements s'exécutant en dehors de Google Cloud (environnements sur site, par exemple). Si vous ciblez une base d'utilisateurs concentrée dans une zone géographique particulière, nous vous recommandons de choisir la région Google Cloud la plus proche de cette zone. Choisir la région Google Cloud qui correspond le mieux à vos exigences de proximité géographique permet à vos environnements de garantir une latence et des temps de réponse plus faibles pour les requêtes de vos utilisateurs et de vos environnements s'exécutant en dehors de Google Cloud. Des outils tels que le tableau de bord de latence de Google Cloud et des outils non officiels, comme GCPing et l'outil de sélection de région Google Cloud, peuvent vous donner une idée générale des caractéristiques de latence des régions Google Cloud. Toutefois, nous vous recommandons d'effectuer une évaluation complète pour déterminer si les propriétés de latence répondent à vos exigences, à vos charges de travail, à vos données et à vos processus.
  • Laquelle des régions que vous souhaitez utiliser propose les produits dont vous avez besoin ? Nous vous recommandons d'évaluer les produits disponibles dans chaque région Google Cloud et d'identifier les régions qui fournissent les services dont vous avez besoin pour concevoir et implémenter vos environnements. Pour en savoir plus sur les produits disponibles dans chaque région et leur calendrier de disponibilité, consultez la page Emplacements Cloud. En outre, certains produits peuvent ne pas proposer toutes leurs fonctionnalités dans l'ensemble des régions dans lesquelles ils sont disponibles. Par exemple, les régions et zones disponibles pour Compute Engine offrent des types de machines spécifiques dans des régions Google Cloud données. Pour en savoir plus sur les fonctionnalités offertes par chaque produit dans les différentes régions, consultez la documentation des produits.
  • Les ressources dont vous avez besoin dans chaque région Google Cloud sont-elles comprises dans les limites de quota par région ? Google Cloud applique des quotas pour limiter la part d'une ressource Google Cloud partagée que vous pouvez utiliser. Certains quotas sont mondiaux et s'appliquent à votre utilisation de la ressource n'importe où dans Google Cloud, tandis que d'autres sont régionaux ou zonaux et s'appliquent à votre utilisation de la ressource dans une région Google Cloud spécifique. Par exemple, la plupart des quotas d'utilisation des ressources Compute Engine, tels que le nombre de machines virtuelles que vous pouvez créer, sont régionaux. Pour en savoir plus sur les quotas et leur augmentation, consultez la page Utiliser des quotas.

Évaluer les critères non fonctionnels

Pour évaluer les critères non fonctionnels, posez-vous les questions suivantes :

  • Privilégiez-vous une empreinte carbone faible ? Google Cloud investit en permanence dans les projets de développement durable et d'énergie décarbonée dans les régions Google Cloud, et s'est engagé à n'avoir recours qu'à une énergie décarbonée dans toutes les régions cloud. Les régions Google Cloud ont des empreintes carbone différentes. Pour en savoir plus sur l'empreinte carbone de chaque région Google Cloud et sur l'intégration de l'énergie décarbonée dans votre stratégie de localisation, consultez la page Énergie décarbonée dans les régions Google Cloud.
  • Vos environnements doivent-ils respecter des réglementations particulières ? Les gouvernements ainsi que les entités nationales et supranationales régulent souvent certains marchés et secteurs d'activité, tels que la banque et le secteur public. Ces réglementations peuvent imposer que les charges de travail, les données et les processus ne résident que dans des régions géographiques données. Par exemple, vos environnements peuvent avoir besoin de respecter des exigences en termes de souveraineté des données, opérationnelle et logicielle pour garantir certains niveaux de contrôle et de transparence pour les données et charges de travail sensibles s'exécutant dans le cloud. Nous vous recommandons d'évaluer vos exigences réglementaires actuelles et à venir lorsque vous choisissez les régions Google Cloud pour vos environnements, et de choisir les régions Google Cloud les mieux adaptées à vos exigences réglementaires.

Concevoir et créer des environnements régionaux

Pour concevoir un environnement régional, procédez comme suit :

  1. Établissez vos fondations sur Google Cloud.
  2. Provisionnez et configurez les ressources de calcul.
  3. Provisionnez et configurez les ressources de stockage de données.
  4. Provisionnez et configurez les ressources d'analyse de données.

Lorsque vous concevez votre environnement, tenez compte des principes de conception généraux suivants :

  • Provisionnez des ressources régionales. De nombreux produits Google Cloud vous permettent de provisionner des ressources dans plusieurs zones d'une région. Dans la mesure du possible, nous vous recommandons de provisionner des ressources régionales plutôt que des ressources zonales. En théorie, vous pouvez provisionner des ressources zonales dans plusieurs zones d'une région et les gérer vous-même pour bénéficier d'une fiabilité accrue. Toutefois, cette configuration ne vous permettrait pas de profiter pleinement de l'ensemble des fonctionnalités de fiabilité de l'infrastructure Google qui englobe les services Google Cloud.
  • Vérifiez que les environnements fonctionnent comme prévu avec les hypothèses des modèles de défaillance. Lorsque vous concevez et implémentez vos environnements régionaux, nous vous recommandons de vérifier s'ils répondent aux exigences de protection contre les modèles de défaillance que vous envisagez avant de les promouvoir en production. Par exemple, vous pouvez simuler des pannes zonales pour vérifier que vos environnements régionaux peuvent persister avec une interruption minimale.

Pour obtenir des principes de conception plus généraux permettant de concevoir des environnements régionaux et multirégionaux fiables, et pour découvrir comment Google améliore la fiabilité à l'aide des services régionaux et multirégionaux, consultez Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud : Thèmes communs.

Établir vos fondations sur Google Cloud

Pour créer l'infrastructure de base de vos environnements régionaux, consultez la page Migrer vers Google Cloud: planifier et créer vos fondations. Les instructions de ce document visent à créer une infrastructure de base pour la migration des charges de travail, des données et des processus vers Google Cloud, mais aussi pour vos environnements régionaux. Après l'avoir lu, continuez à lire ce document.

Une fois les fondations établies sur Google Cloud, vous devez concevoir et implémenter des contrôles et des limites de sécurité. Ces mesures de sécurité contribuent à garantir que vos charges de travail, données et processus restent dans leurs régions respectives. Les mesures de sécurité permettent également de garantir que vos ressources ne font rien fuiter dans d'autres régions en raison de bugs, d'erreurs de configuration ou d'attaques malveillantes.

Provisionner et configurer les ressources de calcul

Une fois les bases de vos environnements régionaux établies, vous devez provisionner et configurer des ressources de calcul. Les sections suivantes décrivent les produits de calcul de Google Cloud compatibles avec les déploiements régionaux.

Compute Engine

Compute Engine est l'offre "Infrastructure as a Service" (IaaS) 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 ressources Compute Engine sont zonales (machines virtuelles ou disques persistants zonaux), régionales (adresses IP externes statiques) ou globales (instantanés de disque persistant). Pour en savoir plus sur les ressources zonales, régionales et globales compatibles avec Compute Engine, consultez la page Ressources globales, régionales et zonales.

Pour optimiser la flexibilité et la gestion des ressources physiques, Compute Engine dissocie les zones de leurs ressources physiques. Pour en savoir plus sur cette abstraction et ses conséquences, consultez la section Zones et clusters.

Pour améliorer la fiabilité de vos environnements utilisant Compute Engine, tenez compte des points suivants :

  • Groupes d'instances gérés (MIG) régionaux. Les machines virtuelles Compute Engine sont des ressources zonales. Elles sont donc indisponibles en cas de panne zonale. Pour résoudre ce problème, Compute Engine vous permet de créer des MIG régionaux qui provisionnent automatiquement des machines virtuelles dans plusieurs zones d'une région, en fonction de la demande et de la disponibilité régionale. Si vous disposez de charges de travail avec état, vous pouvez également créer des MIG régionaux avec état pour conserver les données et les configurations avec état. Les MIG régionaux permettent de simuler les défaillances de zone. Pour en savoir plus sur la simulation d'une défaillance de zone lors de l'utilisation d'un MIG régional, consultez la page Simuler une défaillance de zone pour un MIG régional. Pour en savoir plus sur les différences entre les MIG régionaux et les autres options de déploiement, consultez la page Choisir une stratégie de déploiement Compute Engine pour votre charge de travail.
  • Forme de distribution cible. Les MIG régionaux répartissent les machines virtuelles en fonction de la forme de distribution cible. Pour vous assurer que la distribution des machines virtuelles ne diffère pas plus d'une unité entre deux zones d'une région, nous vous recommandons de choisir la forme de distribution EVEN lorsque vous créez des MIG régionaux. Pour en savoir plus sur les différences entre les formes de distribution cibles, consultez la section Comparaison des formes.
  • Modèles d'instances. Pour définir les machines virtuelles à provisionner, les MIG utilisent un type de ressource global appelé modèle d'instance. Bien que les modèles d'instances soient des ressources globales, ils peuvent faire référence à des ressources zonales ou régionales. Lorsque vous créez des modèles d'instances, nous vous recommandons de référencer des ressources régionales à la place de ressources zonales dès que possible. Si vous utilisez des ressources zonales, nous vous recommandons d'évaluer leur impact. Par exemple, si vous créez un modèle d'instance faisant référence à un volume de disque persistant disponible uniquement dans une zone donnée, vous ne pouvez pas utiliser ce modèle dans d'autres zones où le volume de disque persistant n'est pas disponible.
  • Configurez l'équilibrage de charge et le scaling. Compute Engine est compatible avec le trafic d'équilibrage de charge entre les instances Compute Engine, ainsi qu'avec l'autoscaling qui permet d'ajouter ou de supprimer automatiquement des machines virtuelles dans les MIG en fonction de la demande. Pour améliorer la fiabilité et la flexibilité de vos environnements et éviter les contraintes de gestion des solutions autogérées, nous vous recommandons de configurer l'équilibrage de charge et l'autoscaling. Pour en savoir plus sur la configuration de l'équilibrage de charge et du scaling pour Compute Engine, consultez la page Équilibrage de charge et scaling.
  • Configurez des réservations de ressources. Pour vous assurer que vos environnements disposent des ressources nécessaires lorsque vous en avez besoin, nous vous recommandons de configurer des réservations de ressources afin de garantir l'obtention de la capacité nécessaire pour les ressources Compute Engine zonales. Par exemple, en cas de panne zonale, vous devrez peut-être provisionner des machines virtuelles dans une autre zone afin de fournir la capacité nécessaire pour compenser celle de la zone indisponible. Les réservations de ressources garantissent que vous disposez des ressources nécessaires pour provisionner les machines virtuelles supplémentaires.
  • Utilisez des noms DNS zonaux. Pour réduire le risque d'indisponibilité dans plusieurs régions, nous vous recommandons d'utiliser des noms DNS zonaux pour identifier de manière unique les machines virtuelles utilisant des noms DNS dans vos environnements. Par défaut, Google Cloud utilise des noms DNS zonaux pour les machines virtuelles Compute Engine. Pour en savoir plus sur le fonctionnement du DNS interne de Compute Engine, consultez la présentation du DNS interne. Pour faciliter une future migration entre régions et rendre votre configuration plus facile à gérer, nous vous recommandons de considérer les noms DNS zonaux comme des paramètres de configuration que vous pourrez modifier à l'avenir.
  • Choisissez des options de stockage appropriées. Compute Engine est compatible avec plusieurs options de stockage pour vos machines virtuelles, telles que les volumes Persistent Disk et les disques durs SSD locaux :
    • Les volumes Persistent Disk sont répartis sur plusieurs disques physiques et sont hébergés indépendamment de vos machines virtuelles. Les disques persistants peuvent être zonaux ou régionaux. Les disques persistants zonaux stockent les données dans une seule zone, tandis que les disques persistants régionaux répliquent les données dans deux zones différentes. Lorsque vous choisissez des options de stockage pour vos environnements régionaux, nous vous recommandons de choisir des disques persistants régionaux, car ils vous fournissent des options de basculement en cas de défaillance d'une zone. Pour savoir comment réagir en cas de défaillances de zone lorsque vous utilisez des disques persistants régionaux, consultez Options de haute disponibilité avec des disques persistants régionaux et Basculement des disques persistants régionaux.
    • Les disques SSD locaux ont un débit élevé, mais ils stockent uniquement les données jusqu'à ce qu'une instance soit arrêtée ou supprimée. Par conséquent, les disques SSD locaux conviennent parfaitement pour stocker des données temporaires, des caches et des données que vous pouvez reconstituer par d'autres moyens. Les disques persistants sont des périphériques de stockage durables auxquels les machines virtuelles peuvent accéder, comme les disques physiques.
  • Concevez et implémentez des mécanismes de protection des données. Lorsque vous concevez vos environnements régionaux, nous vous recommandons de mettre en place des mécanismes automatisés pour protéger vos données en cas d'événements indésirables, tels que des défaillances zonales, régionales ou multirégionales, ou d'attaques délibérées commises par des tiers malveillants. Compute Engine fournit plusieurs options de protection des données. Vous pouvez utiliser ces fonctionnalités d'options de données comme composants de base pour concevoir et implémenter vos processus de protection des données.

GKE

GKE vous aide à déployer, à gérer et à faire évoluer des charges de travail conteneurisées sur Kubernetes. Comme GKE s'appuie sur Compute Engine, les recommandations de la section précédente concernant Compute Engine s'appliquent partiellement à GKE.

Pour améliorer la fiabilité de vos environnements utilisant GKE, tenez compte des fonctionnalités GKE et des principes de conception suivants :

  • Utilisez des clusters GKE régionaux pour améliorer la disponibilité. GKE accepte différents types de disponibilités pour vos clusters, en fonction du type de cluster dont vous avez besoin. Les clusters GKE peuvent comporter un plan de contrôle zonal ou régional, et des nœuds pouvant s'exécuter dans une ou plusieurs zones d'une région. Chaque type de cluster offre également un contrat de niveau de service (SLA) différent. Pour améliorer la fiabilité de vos environnements, nous vous recommandons de choisir des clusters régionaux. Si vous utilisez la fonctionnalité GKE Autopilot, vous ne pouvez provisionner que des clusters régionaux.
  • Envisagez d'utiliser un environnement multicluster. Le déploiement de plusieurs clusters GKE peut améliorer la flexibilité et la disponibilité de votre environnement, au prix d'une complexité accrue. Par exemple, si vous devez utiliser une nouvelle fonctionnalité GKE que vous ne pouvez activer que lorsque vous créez un cluster GKE, vous pouvez éviter les temps d'arrêt et réduire la complexité de la migration en ajoutant un cluster GKE dans votre environnement multicluster, en déployant des charges de travail dans le nouveau cluster et en détruisant l'ancien cluster. Pour en savoir plus sur les avantages d'un environnement GKE multicluster, consultez la section Cas d'utilisation multicluster. Pour vous aider à gérer la complexité de la migration, Google Cloud propose la gestion de parc, un ensemble de fonctionnalités permettant de gérer un groupe de clusters GKE, leur infrastructure. et les charges de travail qui y sont déployées.
  • Configurez Sauvegarde pour GKE. Sauvegarde pour GKE est un service régional permettant de sauvegarder la configuration et les volumes de charges de travail dans un cluster GKE source, et de les restaurer dans un cluster GKE cible. Pour protéger la configuration et les données des charges de travail contre d'éventuelles pertes, nous vous recommandons d'activer et de configurer Sauvegarde pour GKE. Pour en savoir plus, consultez la page Présentation de Sauvegarde pour GKE.

Cloud Run

Cloud Run est une plate-forme de calcul gérée permettant d'exécuter des charges de travail conteneurisées. Cloud Run utilise des services pour vous fournir l'infrastructure nécessaire à l'exécution de vos charges de travail. Les services Cloud Run sont des ressources régionales, et les services sont répliqués dans plusieurs zones de la région dans laquelle ils se trouvent. Lorsque vous déployez un service Cloud Run, vous pouvez choisir une région. Ensuite, Cloud Run choisit automatiquement les zones de cette région dans lesquelles déployer des instances du service. Cloud Run équilibre automatiquement le trafic entre les instances de service et est conçu pour réduire considérablement les effets d'une panne zonale.

VMware Engine

VMware Engine est un service entièrement géré qui vous permet d'exécuter la plate-forme VMware dans Google Cloud. Pour améliorer la fiabilité de vos environnements utilisant VMware Engine, nous vous recommandons de procéder comme suit :

  • Provisionnez des clouds privés VMware Engine multinœuds. VMware Engine permet de provisionner des piles VMware isolées appelées clouds privés. Tous les nœuds qui composent un cloud privé se trouvent dans la même région. Les nœuds des clouds privés s'exécutent sur des nœuds matériels Bare Metal dédiés et isolés, et sont configurés pour éliminer les points de défaillance uniques. VMware Engine est compatible avec les clouds privés à nœud unique, mais nous vous conseillons de les utiliser uniquement pour les démonstrations de faisabilité et les tests. Pour les environnements de production, nous vous recommandons d'utiliser les clouds privés multinœuds par défaut.
  • Provisionnez des clouds privés étendus VMware Engine. Un cloud privé étendu est un cloud privé multinœud dont les nœuds sont répartis entre les zones d'une région. Un cloud privé étendu permet de protéger votre environnement contre les pannes zonales.

Pour en savoir plus sur les fonctionnalités de haute disponibilité et de redondance de VMware Engine, consultez la page Disponibilité et redondance.

Provisionner et configurer les ressources de stockage de données

Après avoir provisionné et configuré les ressources de calcul pour vos environnements régionaux, vous devez provisionner et configurer les ressources permettant de stocker et de gérer les données. Les sections suivantes décrivent les produits de stockage et de gestion de données Google Cloud compatibles avec les configurations régionales et multirégionales.

Cloud Storage

Cloud Storage est un service qui permet de stocker des objets (données immuables) dans des buckets (conteneurs de base permettant d'héberger vos données). Lorsque vous créez un bucket, vous sélectionnez le type d'emplacement du bucket le mieux adapté à vos exigences en termes de disponibilité, de réglementation et autres. Les types d'emplacements offrent des garanties de disponibilité différentes. Pour protéger vos données contre les pannes et les indisponibilités, Cloud Storage rend les données redondantes dans au moins deux zones pour les buckets ayant un type d'emplacement régional, dans deux régions pour les buckets ayant un type d'emplacement birégional et dans au moins deux régions pour les buckets ayant un type d'emplacement multirégional. Par exemple, si vous devez rendre un bucket Cloud Storage disponible en cas de panne zonale, vous pouvez lui provisionner un type d'emplacement régional.

Pour en savoir plus sur la conception de mécanismes de reprise après sinistre pour les données stockées dans Cloud Storage et sur la manière dont Cloud Storage réagit aux pannes zonales et régionales, consultez Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud : Cloud Storage.

Filestore

Filestore fournit des serveurs de fichiers entièrement gérés sur Google Cloud qui peuvent être connectés à des instances Compute Engine, à des clusters GKE et à vos machines sur site. Filestore propose plusieurs niveaux de service. Chaque niveau offre des fonctionnalités uniques de disponibilité, d'évolutivité, de performances, de capacité et de récupération des données. Lorsque vous provisionnez des instances Filestore, nous vous recommandons de choisir le niveau Entreprise, car il est compatible avec la haute disponibilité et la redondance des données dans plusieurs zones d'une région. Les instances disponibles dans d'autres niveaux sont des ressources zonales.

Bigtable

Bigtable est un service de base de données entièrement géré, hautes performances et à grande évolutivité pour les charges de travail analytiques et opérationnelles volumineuses. Les instances Bigtable sont des ressources zonales. Pour améliorer la fiabilité de vos instances, vous pouvez configurer Bigtable pour qu'il réplique les données dans plusieurs zones d'une même région ou de plusieurs régions. Lorsque la réplication est activée, Bigtable bascule automatiquement les requêtes vers d'autres instances disponibles vers lesquelles vous avez répliqué les données en cas de panne.

Pour en savoir plus sur le fonctionnement de la réplication dans Bigtable, consultez les pages À propos de la réplication et Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud: Bigtable.

Firestore

Créé par Firebase et Google Cloud, Firestore est une base de données flexible et évolutive conçue pour le développement mobile, Web et serveur. Lorsque vous provisionnez une base de données Firestore, vous sélectionnez son emplacement. Les emplacements peuvent être multirégionaux ou régionaux, et offrent différentes garanties de fiabilité. Si une base de données possède un emplacement régional, elle réplique les données dans différentes zones d'une région. Une base de données multirégionale réplique les données dans plusieurs régions.

Pour en savoir plus sur le fonctionnement de la réplication dans Firestore et sur la manière dont Firestore réagit aux pannes zonales et régionales, consultez les pages Emplacements Firestore et Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud: Firestore.

Memorystore

Memorystore vous permet de configurer des services de stockage de données en mémoire évolutifs, sécurisés et à disponibilité élevée. Il est compatible avec les backends de données pour Redis, Memcached et Valkey.

Lorsque vous provisionnez une instance Memorystore pour Redis, vous sélectionnez un niveau de service pour cette instance. Memorystore pour Redis est compatible avec plusieurs niveaux de service d'instance, chacun d'eux offrant des fonctionnalités uniques en termes de disponibilité, de taille de nœud et de bande passante. Lorsque vous provisionnez une instance Memorystore pour Redis, nous vous recommandons de choisir un niveau Standard ou un niveau Standard avec des instances répliquées avec accès en lecture. Les instances Memorystore de ces deux niveaux répliquent automatiquement les données dans plusieurs zones d'une région. Pour savoir comment Memorystore pour Redis atteint la haute disponibilité, consultez la page Haute disponibilité pour Memorystore pour Redis.

Lorsque vous provisionnez des instances Memorystore pour Memcached, tenez compte des points suivants :

  • Sélection des zones. Lorsque vous provisionnez une instance Memorystore pour Memcached, vous sélectionnez la région dans laquelle vous souhaitez la déployer. Vous pouvez ensuite sélectionner les zones de cette région dans lesquelles vous souhaitez déployer les nœuds de cette instance, ou laisser Memorystore pour Memcached distribuer automatiquement les nœuds entre les zones. Pour placer les instances de manière optimale et éviter les problèmes de provisionnement, par exemple pour placer tous les nœuds dans la même zone, nous vous recommandons de laisser Memorystore pour Memcached distribuer automatiquement les nœuds dans toutes les zones d'une région.
  • Réplication des données entre les zones. Les instances Memorystore pour Memcached ne répliquent pas les données entre les zones ou les régions. Pour en savoir plus sur le fonctionnement des instances Memorystore pour Memcached en cas de pannes zonales ou régionales, consultez Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud : Memorystore pour Memcached.

Lorsque vous provisionnez des instances Memorystore pour Valkey, vous choisissez des options de disponibilité et de fiabilité. Memorystore pour Valkey est compatible avec plusieurs configurations, telles que les instances zonales et multizonales. Pour en savoir plus sur la disponibilité et la fiabilité de Memorystore pour Valkey, consultez la page Memorystore pour Valkey: haute disponibilité et réplication.

Spanner

Spanner est une base de données relationnelle entièrement gérée offrant une évolutivité illimitée, une cohérence forte et une disponibilité jusqu'à 99,999 %. Pour utiliser Spanner, vous provisionnez des instances Spanner. Lorsque vous provisionnez des instances Spanner, tenez compte des points suivants :

  • Configuration de l'instance. Une configuration d'instance définit l'emplacement géographique et la réplication des bases de données dans une instance Spanner. Lorsque vous créez une instance Spanner, vous la configurez comme régionale ou multirégionale.
  • Réplication. Spanner accepte la réplication automatique au niveau octet et la création d'instances répliquées en fonction de vos besoins en termes de disponibilité, de fiabilité et d'évolutivité. Vous pouvez répartir les instances répliquées entre les régions et les environnements. Les instances Spanner disposant d'une configuration régionale gèrent une instance dupliquée en lecture/écriture pour chaque zone d'une région. Les instances disposant d'une configuration multirégionale répliquent les données dans plusieurs zones de plusieurs régions.
  • Déplacement des instances. Spanner vous permet de déplacer une instance d'une configuration d'instance vers une autre, sans provoquer de temps d'arrêt ni d'interruption des garanties de transaction pendant le déplacement.

Pour en savoir plus sur la réplication Spanner et sur la manière dont Spanner réagit aux pannes zonales et régionales, consultez les pages Réplication Spanner et Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud: Spanner.

Provisionner et configurer les ressources d'analyse de données

Après avoir provisionné et configuré les ressources de stockage de données pour vos environnements régionaux, vous devez provisionner et configurer les ressources d'analyse de données. Les sections suivantes décrivent les produits d'analyse de données Google Cloud compatibles avec les configurations régionales.

BigQuery

BigQuery est un entrepôt de données d'entreprise entièrement géré, qui vous aide à gérer et à analyser vos données grâce à des fonctionnalités intégrées telles que le machine learning, l'analyse géospatiale et l'informatique décisionnelle.

Pour organiser et contrôler l'accès aux données dans BigQuery, vous provisionnez des conteneurs de niveau supérieur appelés ensembles de données. Lorsque vous provisionnez des ensembles de données BigQuery, tenez compte des points suivants :

  • Emplacement de l'ensemble de données. Pour sélectionner l'emplacement BigQuery dans lequel stocker vos données, configurez l'emplacement de l'ensemble de données. Un emplacement peut être régional ou multirégional. Pour chaque type d'emplacement, BigQuery stocke les copies de vos données dans deux zones différentes de l'emplacement sélectionné. Une fois l'ensemble de données créé, vous ne pouvez plus en modifier l'emplacement.
  • Planification de reprise après sinistre. BigQuery est un service régional qui gère automatiquement les défaillances de zones, pour le calcul et les données. Cependant, vous devez planifier vous-même certains scénarios (par exemple, des pannes régionales). Nous vous recommandons de prendre en compte ces scénarios lorsque vous concevez vos environnements.

Pour en savoir plus sur la planification et les fonctionnalités de reprise après sinistre pour BigQuery, consultez les pages Comprendre la fiabilité: Planification de reprise après sinistre de la documentation BigQuery et Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud: BigQuery.

Dataproc

Dataproc est un service géré qui vous permet de bénéficier d'outils de données Open Source pour le traitement par lot, l'émission de requêtes, le streaming et le machine learning. Comme Dataproc s'appuie sur Compute Engine, les recommandations de la section précédente concernant Compute Engine s'appliquent partiellement à Dataproc.

Pour utiliser Dataproc, vous devez créer des clusters Dataproc. Les clusters Dataproc sont des ressources zonales. Lorsque vous créez des clusters Dataproc, tenez compte des points suivants :

  • Sélection de zone automatique. Lorsque vous créez un cluster, vous pouvez spécifier la zone d'une région dans laquelle vous souhaitez provisionner les nœuds du cluster ou laisser Dataproc sélectionner la zone automatiquement. Nous vous recommandons d'utiliser la sélection de zone automatique, sauf si vous devez ajuster la sélection de la zone des nœuds du cluster dans la région.
  • Mode haute disponibilité. Lorsque vous créez un cluster, vous pouvez activer le mode haute disponibilité. Vous ne pouvez pas activer le mode haute disponibilité après avoir créé un cluster. Nous vous recommandons d'activer le mode haute disponibilité si vous souhaitez que le cluster soit résilient aux pannes d'un seul nœud coordinateur ou aux pannes zonales partielles. Les clusters Dataproc à haute disponibilité sont des ressources zonales.

Pour en savoir plus sur la manière dont Dataproc réagit aux pannes zonales et régionales, et sur l'augmentation de la fiabilité de vos clusters Dataproc en cas de défaillance, consultez Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud : Dataproc.

Dataflow

Dataflow est un service entièrement géré pour les pipelines de traitement de données en flux continu et par lot. Pour utiliser Dataflow, vous devez créer des pipelines Dataflow, puis Dataflow exécute des jobs, qui sont des instances de ces pipelines, sur des nœuds de calcul. Étant donné que les jobs sont des ressources zonales, vous devez tenir compte des points suivants lorsque vous utilisez des ressources Dataflow :

  • Points de terminaison régionaux. Lorsque vous créez un job, Dataflow nécessite la configuration d'un point de terminaison régional. En configurant un point de terminaison régional pour votre job, vous limitez la sélection des ressources de calcul et de données à une région particulière.
  • Emplacement zonal. Dataflow répartit automatiquement les nœuds de calcul dans toutes les zones d'une région ou dans la zone la plus adaptée d'une région, en fonction du type de job. Dataflow vous permet de remplacer l'emplacement zonal des nœuds de calcul en les plaçant tous dans la même zone au sein d'une région. Pour résoudre les problèmes causés par les pannes zonales, nous vous recommandons de laisser Dataflow sélectionner automatiquement le meilleur emplacement de zone, sauf si vous devez placer les nœuds de calcul dans une zone spécifique.

Pour en savoir plus sur la manière dont Dataproc réagit aux pannes zonales et régionales, et sur l'augmentation de la fiabilité de vos clusters Dataproc en cas de défaillance, consultez Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud : Dataflow.

Pub/Sub

Pub/Sub est un service de messagerie instantanée asynchrone et évolutif qui dissocie les services qui produisent des messages des services qui traitent ces messages. Pub/Sub organise les messages en sujets. Les diffuseurs (services qui produisent des messages) envoient des messages aux sujets, et les abonnés reçoivent les messages issus des sujets. Pub/Sub stocke chaque message dans une seule région et le réplique dans au moins deux zones de cette région. Pour en savoir plus, consultez la page Présentation de l'architecture de Pub/Sub.

Lorsque vous configurez votre environnement Pub/Sub, tenez compte des points suivants :

  • Points de terminaison mondiaux et régionaux. Pub/Sub est compatible avec les points de terminaison mondiaux et régionaux pour la publication des messages. Lorsqu'un diffuseur envoie un message au point de terminaison mondial, Pub/Sub sélectionne automatiquement la région la plus proche pour traiter ce message. Lorsqu'un producteur envoie un message à un point de terminaison régional, Pub/Sub traite le message dans cette région.
  • Règles de stockage des messages. Pub/Sub vous permet de configurer des règles de stockage des messages pour restreindre l'emplacement où Pub/Sub traite et stocke les messages, quels que soient l'origine de la requête et le point de terminaison utilisé par le diffuseur pour publier le message. Nous vous recommandons de configurer des règles de stockage des messages pour vous assurer que les messages ne quittent pas votre environnement régional.

Pour en savoir plus sur la manière dont Pub/Sub gère les pannes zonales et régionales, consultez Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud : Pub/Sub.

Adapter vos charges de travail à des environnements régionaux

Une fois le provisionnement et la configuration de vos environnements terminés, vous devez déterminer comment rendre vos charges de travail plus résilientes aux défaillances de zone et de région. Chaque charge de travail peut avoir ses propres exigences et propriétés en termes de disponibilité et de fiabilité, mais vous pouvez appliquer quelques principes de conception et des stratégies pour améliorer votre stratégie de résilience globale dans l'éventualité peu probable de défaillances de zone et de région. Lorsque vous concevez et implémentez vos charges de travail, tenez compte des points suivants :

  • Implémentez les pratiques et les principes de l'ingénierie de la fiabilité des sites (ingénierie SRE). L'automatisation et la surveillance étendue font partie des principes de base de l'ingénierie SRE. Google Cloud fournit les outils et les services professionnels nécessaires à l'implémentation de l'ingénierie SRE afin d'accroître la résilience et la fiabilité de vos environnements, et de réduire les tâches répétitives.
  • Développez des solutions évolutives et résilientes. Lorsque vous concevez des charges de travail pour des environnements cloud, nous vous recommandons de considérer l'évolutivité et la résilience comme des exigences inhérentes à vos charges de travail. Pour en savoir plus sur ce type de conception, consultez la page Modèles d'applications évolutives et résilientes.
  • Développez des solutions pour récupérer après une panne d'infrastructure cloud. Les garanties de disponibilité de Google Cloud sont définies par les contrats de niveau de service de Google Cloud. Dans le cas peu probable d'une défaillance de zone ou de région, nous vous recommandons de concevoir vos charges de travail de sorte qu'elles soient résilientes aux défaillances de zone et de région.
  • Implémentez le délestage et la dégradation élégante. En cas de défaillance de l'infrastructure cloud ou d'autres dépendances de vos charges de travail, nous vous recommandons de concevoir vos charges de travail de manière à ce qu'elles soient résilientes. Vos charges de travail doivent conserver certains niveaux de fonctionnalités bien définis même en cas de défaillance (dégradation élégante) et pouvoir supprimer une partie de leur charge lorsqu'elles s'approchent des conditions de surcharge (délestage).
  • Planifiez une maintenance régulière. Lorsque vous concevez vos processus de déploiement et vos processus opérationnels, nous vous recommandons également de prendre en compte toutes les activités que vous devez effectuer lors de la maintenance régulière de vos environnements. La maintenance régulière doit inclure des activités telles que l'application de mises à jour et de modifications de la configuration à vos charges de travail et à leurs dépendances, ainsi que l'impact de ces activités sur la disponibilité de vos environnements. Par exemple, vous pouvez configurer une stratégie de maintenance de l'hôte pour vos instances Compute Engine.
  • Adoptez une approche de développement piloté par les tests. Lorsque vous concevez vos charges de travail, nous vous recommandons d'adopter une approche de développement piloté par les tests pour vous assurer que vos charges de travail se comportent comme prévu sous tous les angles. Par exemple, vous pouvez vérifier si vos charges de travail et votre infrastructure cloud répondent aux exigences fonctionnelles, non fonctionnelles et de sécurité dont vous avez besoin.

Étapes suivantes

Contributeurs

Auteur: Marco Ferrari | Architecte de solutions cloud

Autres contributeurs :