Migration de charges de travail multicloud

Cette page fournit des conseils d'architecture, des mappages de services cross-cloud et des stratégies de migration pour migrer des charges de travail depuis Amazon Web Services (AWS) ou Microsoft Azure vers Google Cloud.

Si vous êtes architecte cloud, ingénieur de plate-forme ou responsable d'infrastructure, utilisez les informations de cette page pour mapper des services cloud tiers à des équivalentsGoogle Cloud , exécuter des transferts de données directs de cloud à cloud et concevoir des architectures de reprise après sinistre (DR) multicloud.

Avant de lire cette page, vous devez disposer d'un inventaire de vos ressources AWS ou Azure sources et comprendre les exigences de votre organisation en matière de continuité d'activité et de basculement.

Mappage des services AWS et Azure

Lorsque vous effectuez une migration depuis AWS ou Azure, utilisez le tableau suivant pour mapper les anciens services cloud à leurs équivalents Google Cloud  :

Domaine fonctionnel Service AWS Service Azure Google Cloud équivalent
Machines virtuelles Amazon EC2 Machines virtuelles Azure Compute Engine
Services Kubernetes gérés Amazon EKS Azure Kubernetes Service (AKS) Google Kubernetes Engine (GKE)
Stockage d'objets Amazon S3 Azure Blob Storage Cloud Storage
Bases de données relationnelles Amazon RDS Azure SQL Database Cloud SQL ou AlloyDB pour PostgreSQL
Entrepôt de données cloud Amazon Redshift Azure Synapse Analytics BigQuery

Transfert de données depuis d'autres clouds

Utilisez le service de transfert de stockage pour transférer des données d'objets à l'échelle du pétaoctet depuis Amazon S3 ou Azure Blob Storage directement vers Cloud Storage.

Principales fonctionnalités du service de transfert de stockage

Le service de transfert de stockage offre les fonctionnalités de transfert de données suivantes :

  • Jobs de transfert automatisés : planifiez des copies d'objets récurrentes ou ponctuelles d'un cloud à un autre sans acheminer les données via des réseaux sur site locaux.
  • Vérification de la somme de contrôle : assurez l'intégrité des données de bout en bout pendant le transfert à l'aide de la vérification automatisée du hachage.
  • Contrôles de la bande passante : limitez les débits de transfert pour éviter d'atteindre les limites de quota d'API sur les fournisseurs de services cloud sources.

Pour en savoir plus, consultez Transférer depuis Amazon S3 et Transférer depuis Microsoft Azure Blob Storage.

Résilience et basculement multicloud

L'établissement de Google Cloud en tant qu'environnement de basculement secondaire permet de reprise après sinistre, d'atténuer les risques liés à un cloud unique et de maintenir la continuité des activités en cas de panne sur d'autres plates-formes cloud.

Configurations de reprise après sinistre

Lorsque vous concevez des architectures de reprise après sinistre multicloud, choisissez l'une des configurations de déploiement suivantes :

  • Cold standby : répliquez les données en continu vers Cloud Storage pour la sauvegarde et la restauration, et conservez des modèles Compute Engine prêts pour un déploiement à la demande.
  • Warm standby : exécutez une capacité de calcul de référence minimale, telle qu'un petit cluster GKE ou une base de données d'instance répliquée avec accès en lecture, sur Google Cloud, prête à évoluer rapidement lors du basculement.
  • Double traitement actif-actif : répartissez le trafic utilisateur actif entre le fournisseur de services cloud principal et Google Cloud à l'aide de Cloud Load Balancing global.

Pour en savoir plus, consultez le guide de planification de la reprise après sinistre et les modèles d'architecture hybride et multicloud.

Étapes suivantes