Concevoir l'architecture de vos charges de travail

Last reviewed 2024-07-24 UTC

Ce document vous aide à concevoir des charges de travail de manière à minimiser l'impact d'une expansion et d'une migration futures des charges de travail vers d'autres régions Google Cloud, ou l'impact d'une migration de charges de travail entre les régions. Il est utile si vous envisagez d’effectuer l’une de ces activités ou si vous souhaitez évaluer l’opportunité de le faire à l’avenir et souhaitez découvrir à quoi pourrait ressembler le travail.

Ce document fait partie d'une série :

Les conseils de cette série sont également utiles si vous n'avez pas planifié de migration sur plusieurs régions ou d'expansion vers plusieurs régions. Dans ce cas, vous devrez peut-être déployer des efforts supplémentaires pour préparer votre infrastructure, vos charges de travail et vos données à la migration sur plusieurs régions et à l'expansion vers plusieurs régions.

Ce document vous aide à effectuer les opérations suivantes :

  1. Préparer votre zone de destination
  2. Préparer vos charges de travail pour une migration sur plusieurs régions
  3. Préparer vos ressources de calcul
  4. Préparer vos ressources de stockage de données
  5. Préparer la mise hors service de l'environnement source

Préparer votre zone de destination

Cette section porte sur les considérations à prendre en compte pour étendre une zone de destination (également appelée une fondation cloud) lors de la migration sur plusieurs régions.

La première étape consiste à réévaluer les différents aspects de toute zone de destination existante. Avant de pouvoir migrer une charge de travail, vous devez déjà disposer d'une zone de destination. Bien que vous disposiez déjà d'une zone de destination pour la région qui héberge les charges de travail, celle-ci peut ne pas être compatible avec le déploiement de charges de travail dans une autre région. Elle doit donc être étendue à la région cible. Certaines zones de destination déjà en place peuvent avoir une conception compatible avec une autre région sans nécessiter de modifications importantes de la zone de destination (par exemple, la gestion de l'authentification et des accès ou la gestion des ressources). Toutefois, des facteurs supplémentaires, tels que le réseau ou les données, peuvent nécessiter une planification spécifique pour l'extension. Votre processus de réévaluation doit tenir compte des principales exigences de vos charges de travail pour vous permettre de configurer une fondation générique pouvant être spécialisée ultérieurement lors de la migration.

Points à prendre en compte concernant l'entreprise

En ce qui concerne des aspects tels que les normes, réglementations et certifications industrielles et gouvernementales, le transfert de charges de travail vers une autre région peut avoir des exigences différentes. Les charges de travail exécutées sur des régions Google situées physiquement dans différents pays doivent respecter les lois et réglementations de ces pays. En outre, différentes normes du secteur peuvent avoir des exigences particulières pour les charges de travail exécutées à l'étranger (en particulier en termes de sécurité). Les régions Google Cloud étant conçues pour exécuter des ressources dans un seul pays, les charges de travail sont parfois migrées d'une autre région Google vers ce pays afin de respecter des réglementations spécifiques. Lorsque vous effectuez ces migrations "dans le pays", il est important de réévaluer les données exécutées sur site pour vérifier si la nouvelle région autorise la migration de vos données vers Google Cloud.

Gestion de l'authentification et des accès

Lorsque vous planifiez une migration, vous n'avez probablement pas besoin de planifier de nombreuses modifications d'identité et d'accès pour les régions qui sont déjà sur Google Cloud. Les décisions concernant l'identité sur Google Cloud et l'accès aux ressources sont généralement basées sur la nature des ressources plutôt que sur la région dans laquelle elles sont exécutées. Voici quelques points à prendre en compte :

  • Conception des équipes : certaines entreprises sont structurées de manière à disposer d'équipes différentes pour gérer différentes ressources. Lorsqu'une charge de travail est migrée vers une autre région, en raison de la modification de la structure des ressources, une autre équipe peut être le meilleur choix pour être responsable de certaines ressources. Dans ce cas, les accès doivent être ajustés en conséquence.
  • Conventions d'attribution de noms : bien que les conventions d'attribution de noms n'aient pas d'impact technique sur les fonctionnalités, certaines considérations peuvent être nécessaires si des ressources sont définies avec des conventions d'attribution de noms faisant référence à une région spécifique. Un exemple typique se produit lorsqu'il existe déjà plusieurs régions répliquées, telles que des machines virtuelles (VM) Compute Engine, qui sont nommées avec la région en préfixe, par exemple europe-west1-backend-1. Pendant le processus de migration, pour éviter toute confusion ou, pire, perturber les pipelines qui reposent sur une convention de d'attribution de noms spécifique, il est important de modifier les noms afin qu'ils reflètent la nouvelle région.

Connectivité et mise en réseau

La conception de votre réseau affecte plusieurs aspects de l'exécution de la migration. Il est donc important de prendre en compte cette conception avant de planifier le transfert des charges de travail.

Gardez à l'esprit que la connectivité sur site avec Google Cloud est l'un des facteurs que vous devez réévaluer dans la migration, car elle peut être conçue pour être spécifique à une région. Cloud Interconnect est un exemple de ce facteur, qui est connecté à Google Cloud via un rattachement de VLAN à des régions spécifiques. Vous devez modifier la région dans laquelle le rattachement de VLAN est connecté avant de fermer cette région afin d'éviter le trafic régional. Un autre facteur à prendre en compte est que si vous utilisez Partner Interconnect, la migration de la région peut vous aider à sélectionner un autre emplacement physique pour connecter vos rattachements de VLAN à Google Cloud. Ce point est également important si vous utilisez un réseau Cloud VPN et que vous décidez de modifier les adresses des sous-réseaux dans la migration : vous devez reconfigurer vos routeurs afin qu'ils reflètent le nouveau réseau.

Bien que les clouds privés virtuels (VPC) sur Google Cloud soient des ressources globales, les sous-réseaux individuels sont toujours associés à une région spécifique. Vous ne pouvez donc pas utiliser le même sous-réseau pour les charges de travail après la migration. Étant donné que les sous-réseaux ne peuvent pas chevaucher les adresses IP, vous devez créer un autre VPC pour conserver les mêmes adresses. Ce processus est simplifié si vous utilisez Cloud DNS, qui peut exploiter des fonctionnalités telles que l'appairage DNS pour acheminer le trafic des charges de travail migrées avant de supprimer l'ancienne région.

Pour en savoir plus sur la création d'une fondation sur Google Cloud, consultez la page Migrer vers Google Cloud : établir une fondation.

Préparer vos charges de travail pour une migration sur plusieurs régions

Si vous souhaitez configurer votre infrastructure sur Google Cloud avec l'intention de migrer ultérieurement vers une autre région, ou que vous utilisez déjà Google Cloud et que vous devez migrer vers une autre région, vous devez vous assurer que vos charges de travail peuvent être migrées de la manière la plus simple afin de réduire les efforts et minimiser les risques. Pour vous aider à garantir que toutes les charges de travail sont dans un état qui permet la migration, nous vous recommandons d'adopter l'approche suivante :

  • Privilégiez les conceptions de réseau facilement réplicables et faiblement couplées dans la topologie spécifique du réseau. Google Cloud propose différents produits qui peuvent vous aider à dissocier votre configuration réseau actuelle des ressources utilisant ce réseau. Cloud DNS, un exemple de ce type, permet de dissocier les adresses IP de sous-réseau internes des VM.
  • Configurez des produits compatibles avec les configurations multirégionales ou globales. Les produits compatibles avec une configuration impliquant plusieurs régions simplifient généralement le processus de migration vers une autre région.
  • Envisagez d'utiliser des services gérés avec des instances répliquées interrégionales gérées pour les données. Comme décrit dans les sections suivantes de ce document, certains services gérés vous permettent de créer une instance répliquée dans une autre région, généralement à des fins de sauvegarde ou de haute disponibilité. Cette fonctionnalité peut être importante pour migrer des données d'une région à une autre.

Certains services Google Cloud sont conçus pour être compatibles avec les déploiements multirégionaux ou les déploiements globaux. Vous n'avez pas besoin de migrer ces services, mais vous devrez peut-être ajuster certaines configurations.

Préparer vos ressources de calcul

Cette section présente les ressources de calcul sur Google Cloud, ainsi que les principes de conception permettant de préparer une migration vers une autre région.

Ce document porte sur les produits de calcul Google Cloud suivants :

Compute Engine

Compute Engine est le service Google Cloud qui fournit des VM aux clients.

Pour migrer des ressources Compute Engine d'une région à une autre, vous devez évaluer différents facteurs en plus des considérations sur la mise en réseau.

Nous vous recommandons d'effectuer les opérations suivantes :

  • Vérifier les ressources de calcul : l'une des premières limites que vous pouvez rencontrer lorsque vous modifiez la région d'hébergement d'une VM est la disponibilité de la plate-forme de processeur dans la nouvelle région cible. Si vous devez changer une série de machines pendant la migration, vérifiez que le système d'exploitation de votre VM actuelle est compatible avec la nouvelle série. De manière générale, ce problème peut être étendu à tous les services de calcul Google Cloud (certaines nouvelles régions peuvent ne pas disposer de services comme Cloud Run ou Cloud GPU). Avant de planifier la migration, assurez-vous que tous les services de calcul dont vous avez besoin sont disponibles dans la région de destination.
  • Configurer 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. Nous vous recommandons de configurer l'équilibrage de charge et l'autoscaling pour améliorer la fiabilité et la flexibilité de vos environnements, évitant ainsi les contraintes de gestion des solutions autogérées. 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.
  • Utiliser 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 à l'aide de 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.
  • Utiliser le même modèle de groupes d'instances gérés (MIG) : Compute Engine vous permet de créer des MIG régionaux qui provisionnent automatiquement des machines virtuelles sur plusieurs zones d'une région. Si vous utilisez un modèle dans votre ancienne région, vous pouvez utiliser le même modèle pour déployer les MIG dans la nouvelle région.

GKE

Google Kubernetes Engine (GKE) vous aide à déployer, à gérer et à faire évoluer des charges de travail conteneurisées sur Kubernetes.

Pour préparer vos charges de travail GKE à une migration, tenez compte des fonctionnalités GKE et des principes de conception suivants :

  • Cloud Service Mesh : mise en œuvre gérée du maillage Istio. L'adoption de Cloud Service Mesh pour votre cluster vous permet de disposer d'un plus haut niveau de contrôle sur le trafic réseau dans le cluster. L'une des principales fonctionnalités de Cloud Service Mesh est qu'il vous permet de créer un maillage de services entre deux clusters. Vous pouvez utiliser cette fonctionnalité pour planifier la migration d'une région à une autre en créant le cluster GKE dans la nouvelle région et en l'ajoutant au maillage de services. En utilisant cette approche, il est possible de commencer à déployer des charges de travail dans le nouveau cluster et d'y acheminer progressivement le trafic, ce qui vous permet de tester le nouveau déploiement tout en ayant la possibilité d'effectuer un rollback en modifiant le routage du maillage.
  • Config Sync : service GitOps basé sur un noyau Open Source qui permet aux opérateurs de cluster et aux administrateurs de plate-forme de déployer des configurations à partir d'une source unique. Config Sync peut accepter un ou plusieurs clusters, ce qui vous permet d'utiliser une seule source de vérité pour configurer les clusters. Vous pouvez utiliser cette fonction Config Sync pour répliquer la configuration du cluster existant sur le cluster pour la nouvelle région et éventuellement personnaliser une ressource spécifique pour la région.
  • Sauvegarde pour GKE : cette fonctionnalité vous permet de sauvegarder régulièrement les données persistantes de votre cluster et de les restaurer sur le même cluster ou sur un nouveau.

Cloud Run

Cloud Run propose une approche légère pour déployer des conteneurs sur Google Cloud. Les services Cloud Run sont des ressources régionales et 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 dans laquelle déployer l'instance, puis utiliser cette fonctionnalité pour déployer la charge de travail dans une autre région.

VMware Engine

Google Cloud VMware Engine est un service entièrement géré qui vous permet d'exécuter la plate-forme VMware dans Google Cloud. L'environnement VMware s'exécute de manière native sur une infrastructure bare metal de Google Cloud dans des emplacements Google Cloud, y compris vSphere, vCenter, vSAN, NSX-T, HCX et les outils correspondants.

Pour migrer des instances VMware Engine vers une autre région, vous devez créer votre cloud privé dans la nouvelle région, puis utiliser les outils VMware pour transférer les instances.

Vous devez également prendre en compte le DNS et l'équilibrage de charge dans les environnements Compute Engine lorsque vous planifiez votre migration. VMware Engine utilise Google Cloud DNS, un service d'hébergement DNS géré qui fournit un hébergement DNS fiable publié sur l'Internet public, des zones privées visibles par les réseaux VPC, et un transfert et un appairage DNS pour gérer la résolution de noms sur les réseaux VPC. Votre plan de migration
est compatible avec les tests de l'équilibrage de charge multirégional et les configurations DNS.

Préparer vos ressources de stockage de données

Cette section présente les ressources de stockage de données sur Google Cloud et les principes de base de la préparation d'une migration vers une autre région.

Les données déjà présentes sur Google Cloud simplifient la migration, car cela implique qu'il existe une solution permettant de les héberger sans aucune transformation, ou qu'elles peuvent être hébergées sur Google Cloud.

La capacité de copier des données de base de données dans une autre région et de les restaurer ailleurs est un schéma classique lors d'une reprise après sinistre. C'est pourquoi certains des modèles décrits dans ce document s'appuient sur des mécanismes de reprise après sinistre, tels que la sauvegarde et la récupération de bases de données.

Les services gérés suivants sont décrits dans ce document :

Dans ce document, nous partons du principe que les solutions de stockage que vous utilisez sont des instances régionales, colocalisées avec des ressources de calcul.

Cloud Storage

Cloud Storage propose le service de transfert de stockage, qui automatise le transfert de fichiers vers Cloud Storage depuis différents systèmes. Il peut être utilisé pour répliquer des données dans une autre région pour la sauvegarde, ainsi que pour la migration d'une région à une autre.

Cloud SQL

Cloud SQL propose un service de base de données relationnelle permettant d'héberger différents types de bases de données. Cloud SQL offre une fonctionnalité de réplication interrégionale qui permet de répliquer les données d'une instance dans une région différente. Cette fonctionnalité est un schéma courant pour la sauvegarde et la restauration des instances Cloud SQL, mais elle vous permet aussi de promouvoir la deuxième instance répliquée dans l'autre région en tant qu'instance répliquée principale. Vous pouvez utiliser cette fonctionnalité pour créer une instance répliquée avec accès en lecture dans la deuxième région, puis la promouvoir en tant qu'instance répliquée principale après avoir migré les charges de travail. En général, pour les bases de données, les services gérés simplifient le processus de réplication des données, facilitant ainsi la création d'une instance répliquée dans la nouvelle région lors de la migration.

Une autre façon de gérer la migration consiste à utiliser Database Migration Service, qui vous permet de migrer des bases de données SQL depuis différentes sources vers Google Cloud. Parmi les sources compatibles, il existe également une autre instance Cloud SQL avec une seule limitation : vous pouvez migrer vers une région différente, mais pas vers un autre projet.

Filestore

Comme expliqué précédemment dans ce document, la fonctionnalité de sauvegarde et de restauration de Filestore vous permet de créer une sauvegarde d'un partage de fichiers qui peut être restaurée dans une autre région. Cette fonctionnalité peut être utilisée pour effectuer une migration d'une région à une autre.

Bigtable

Comme pour Cloud SQL, Bigtable est compatible avec la réplication. Vous pouvez utiliser cette fonctionnalité pour répliquer le même modèle que celui décrit. Vérifiez dans la liste des emplacements Bigtable si le service est disponible dans la région de destination.

De plus, comme avec Filestore, Bigtable est compatible avec les opérations de sauvegarde et de restauration. Cette fonctionnalité peut être utilisée, comme avec Filestore, pour mettre en œuvre la migration en créant une sauvegarde et en la restaurant dans une autre instance de la nouvelle région.

La dernière option consiste à exporter des tables, par exemple sur Cloud Storage. Ces exportations hébergent des données dans un autre service, qui peuvent ensuite être importées dans l'instance de la région.

Firestore

Les emplacements Firestore peuvent être liés à la présence d'App Engine dans votre projet, ce qui, dans certains scénarios, oblige l'instance Firestore à être multirégionale. Dans ces scénarios de migration, il est également nécessaire de prendre en compte App Engine pour concevoir une solution adaptée à Firestore. En effet, si vous disposez déjà d'une application App Engine ayant pour emplacement us-central ou
europe-west, votre base de données Firestore est considérée comme multirégionale.

Si vous disposez d'un emplacement régional et que vous souhaitez migrer vers un autre emplacement, le service d'exportation et d'importation géré permet d'importer et d'exporter des entités Firestore à l'aide d'un bucket Cloud Storage. Cette méthode peut être utilisée pour déplacer des instances d'une région à une autre. L'autre option consiste à utiliser la fonctionnalité de sauvegarde et de restauration de Firestore. Cette option est moins coûteuse et plus simple que l'importation et l'exportation.

Préparer la mise hors service de l'environnement source

Vous devez vous préparer à l'avance avant de mettre hors service votre environnement source et de passer au nouveau.

De manière générale, vous devez tenir compte des points suivants avant de mettre hors service l'environnement source :

  • Tests du nouvel environnement : avant de basculer le trafic de l'ancien environnement vers le nouveau, vous pouvez effectuer des tests pour valider l'exactitude des applications. Outre les tests unitaires et d'intégration classiques pouvant être effectués sur les applications nouvellement migrées, il existe différentes stratégies de test. Le nouvel environnement peut être traité comme une nouvelle version du logiciel et la migration du trafic peut être mise en œuvre avec des modèles courants, tels que les tests A/B utilisés pour la validation. Une autre approche consiste à répliquer le trafic entrant dans l'environnement source et dans le nouvel environnement pour vérifier que les fonctions sont conservées.
  • Planification des temps d'arrêt : si vous sélectionnez une stratégie de migration, telle que le déploiement bleu-vert, où vous basculez le trafic d'un environnement à un autre, envisagez d'adopter des temps d'arrêt planifiés. Le temps d'arrêt permet de mieux surveiller la transition et d'éviter les erreurs imprévisibles côté client.
  • Rollback : en fonction des stratégies adoptées pour migrer le trafic, il peut être nécessaire de mettre en œuvre un rollback en cas de failles ou d'erreurs de configuration du nouvel environnement. Pour pouvoir effectuer un rollback de l'environnement, vous devez disposer d'une infrastructure de surveillance en place afin de détecter l'état du nouvel environnement.

Vous ne pouvez arrêter les services dans la première région qu'après avoir réalisé des tests étendus dans la nouvelle région et effectué la mise en service dans la nouvelle région sans erreur. Nous vous recommandons de conserver les sauvegardes de la première région pendant une durée limitée, jusqu'à ce que vous soyez sûr qu'il n'y a aucun problème dans la région qui vient d'être migrée.

Vous pouvez également envisager de promouvoir l'ancienne région sur un site de reprise après sinistre, en supposant qu'aucune solution n'est déjà en place. Cette approche nécessite une conception supplémentaire pour garantir la fiabilité du site. Pour en savoir plus sur la conception et la planification appropriées de la reprise après sinistre, consultez le Guide de planification de reprise après sinistre.

Étape suivante

Contributeurs

Auteur : Valerio Ponza | Consultant en solutions techniques

Autres contributeurs :