Migrer vers Google Cloud : transférer vos ensembles de données volumineux

Last reviewed 2023-11-13 UTC

Pour de nombreux clients, la première étape de l'adoption d'un produit Google Cloud consiste à importer leurs données dans Google Cloud. Ce processus est présenté dans ce document, depuis la planification d'un transfert de données jusqu'à l'application des bonnes pratiques dans la mise en œuvre d'un plan.

Le transfert de grands ensembles de données implique la constitution de la bonne équipe, la planification précoce et le test de votre plan de transfert avant sa mise en œuvre dans un environnement de production. Ces étapes préparatoires peuvent prendre autant de temps que le transfert lui-même. Cependant, elles vous aideront à minimiser les perturbations de vos activités commerciales pendant le transfert.

Ce document fait partie d'une série d'articles sur la migration vers Google Cloud :

Qu'est-ce que le transfert de données ?

Pour les besoins de ce document, le transfert de données traité ici consiste à déplacer des données sans les transformer, par exemple en transférant des fichiers en l'état dans des objets.

Le transfert de données n'est pas aussi simple qu'il n'y paraît

Il est tentant de considérer le transfert de données comme une session FTP géante, dans laquelle vous placez vos fichiers d'un côté et attendez qu'ils arrivent de l'autre côté. Toutefois, dans la plupart des environnements d'entreprise, le processus de transfert implique de nombreux facteurs, dont les suivants :

  • Concevoir un plan de transfert qui tient compte du temps d'administration, y compris le délai nécessaire au choix d'une option de transfert, à l'obtention des approbations et au traitement des problèmes imprévus.
  • Coordonner les membres de votre organisation, tels que l'équipe qui exécute le transfert, le personnel qui valide les outils et l'architecture, et les intervenants commerciaux concernés par la valeur ajoutée et les perturbations qu'implique un transfert de données.
  • Choisir le bon outil de transfert en fonction de vos ressources, des contraintes de coût et de temps, ainsi que des autres facteurs inhérents au projet.
  • Surmonter les défis liés au transfert de données, y compris les problèmes liés à la "vitesse de la lumière" (bande passante insuffisante), au déplacement des ensembles de données en cours d'utilisation, à la protection et à la surveillance des données en cours de transfert et au contrôle du bon déroulement du transfert.

Ce document vise à vous aider à préparer une démarche de transfert efficace.

La liste suivante inclut des ressources pour d'autres types de projets de transfert de données non traités dans ce document :

Étape 1 : Constituer votre équipe

Planifier un transfert nécessite généralement des collaborateurs correspondant aux rôles et responsabilités suivants :

  • Activation des ressources nécessaires pour un transfert : administrateurs de l'espace de stockage, administrateurs informatique et réseau, responsable exécutif et autres conseillers (par exemple, une équipe Comptes Google ou des partenaires d'intégration)
  • Approbation de la décision de transfert : propriétaires ou administrateurs de données (pour les règles internes d'autorisation des personnes et des données à transférer), conseillers juridiques (pour les réglementations relatives aux données) et un administrateur de la sécurité (pour les règles internes sur la protection de l'accès aux données)
  • Exécution du transfert : un chef d'équipe, un chef de projet (pour l'exécution et le suivi du projet), une équipe d'ingénieurs et une équipe de réception et d'expédition sur site (pour le matériel système)

Il est essentiel d'identifier les responsabilités ci-dessus pour votre projet de transfert, et de convier ces collaborateurs aux réunions de planification et de décision, le cas échéant. Une mauvaise planification organisationnelle est souvent la cause d'échecs des projets de transfert.

Rassembler les exigences du projet et les contributions des diverses parties prenantes est un exercice difficile mais payant. Vous y verrez plus clair après avoir établi les rôles et les responsabilités de chacun, car vous n'êtes pas censé connaître tous les détails de vos données. En constituant vos équipes, vous comprendrez mieux les besoins de l'entreprise. Avant d'investir du temps, de l'argent et des ressources dans une opération de transfert, il est recommandé d'identifier les problèmes potentiels.

Étape 2 : Recenser les exigences et les ressources disponibles

Lorsque vous concevez un plan de transfert, nous vous recommandons de commencer par recenser les exigences liées à votre transfert de données, puis de choisir une option de transfert. Pour ce faire, vous pouvez appliquer cette procédure :

  1. Identifiez les ensembles de données à déplacer.
    • Sélectionnez des outils tels que Data Catalog pour organiser vos données en groupes logiques déplacés et utilisés ensemble.
    • Collaborez avec les équipes de votre organisation pour valider ou mettre à jour ces regroupements.
  2. Identifiez les ensembles de données que vous pouvez déplacer.
    • Déterminez si des facteurs réglementaires, de sécurité ou autres empêchent le transfert de certains ensembles de données.
    • Si vous devez transformer certaines de vos données avant de les déplacer (par exemple, pour supprimer des données sensibles ou réorganiser certaines données), envisagez d'utiliser un produit d'intégration de données tel que Cloud Dataflow ou Cloud Data Fusion, ou un produit d'orchestration de workflow comme Cloud Composer.
  3. Pour les ensembles de données pouvant être déplacés, déterminez la destination pour chaque ensemble de données à transférer.
    • Choisissez une option pour le stockage de vos données. En règle générale, le système de stockage cible sur Google Cloud est Cloud Storage. Même si vous avez besoin de solutions plus complexes après le lancement de vos applications, Cloud Storage est une option de stockage évolutive et durable.
    • Identifiez les règles d'accès aux données devant être gérées après la migration.
    • Déterminez si vous devez stocker ces données dans des régions spécifiques.
    • Planifiez comment structurer ces données à leur emplacement de destination. Par exemple, la structure doit-elle être identique à la source ou différente ?
    • Déterminez si vous devez transférer les données en continu.
  4. Pour les ensembles de données pouvant être déplacés, déterminez les ressources disponibles pour le transfert.
    • Planning : quand le transfert doit-il être effectué ?
    • Coût : quel est le budget disponible pour l'équipe et les coûts de transfert ?
    • Personnes : qui est disponible pour effectuer le transfert ?
    • Bande passante (pour les transferts en ligne) : quelle est la quantité de bande passante disponible pour Google Cloud pouvant être allouée à un transfert, et pour combien de temps ?

Avant d'évaluer et de sélectionner des options de transfert lors de la prochaine phase de planification, nous vous recommandons d'évaluer si une partie de votre modèle informatique peut être améliorée, par exemple la gouvernance des données, l'organisation ou la sécurité.

Votre modèle de sécurité

Dans le cadre de votre projet de transfert de données, de nombreux membres de l'équipe de transfert peuvent se voir attribuer de nouveaux rôles dans votre organisation Google Cloud. La planification du transfert de données est le moment idéal pour examiner vos autorisations IAM et les bonnes pratiques d'utilisation d'IAM en toute sécurité. Ces problèmes peuvent affecter la manière dont vous accordez l'accès à votre espace de stockage. Par exemple, vous pouvez limiter l'accès en écriture aux données archivées pour des raisons réglementaires, tout en accordant l'accès en écriture à de nombreux utilisateurs et applications dans votre environnement de test.

Votre organisation Google Cloud

La façon dont vous structurez vos données sur Google Cloud dépend de la manière dont vous envisagez d'utiliser Google Cloud. Le stockage de vos données dans le projet Google Cloud sur lequel vous exécutez votre application peut fonctionner, mais ce n'est pas optimal du point de vue de la gestion. Certains de vos développeurs peuvent ne pas être autorisés à afficher les données de production. Dans ce cas, un développeur peut être limité à l'écriture de code sur des exemples de données, tandis qu'un compte de service avec accès privilégié peut accéder aux données de production. Ainsi, vous pouvez conserver l'intégralité de votre ensemble de données de production dans un projet Google Cloud distinct, puis utiliser un compte de service pour autoriser l'accès aux données de chaque projet d'application.

Google Cloud s'organise autour de projets. Les projets peuvent être regroupés dans des dossiers, et les dossiers peuvent être regroupés sous votre organisation. Les rôles sont établis au niveau du projet et les autorisations d'accès sont ajoutées à ces rôles au niveau du bucket Cloud Storage. Cette structure s'aligne sur la structure des autorisations d'autres fournisseurs de stockage d'objets.

Pour connaître les bonnes pratiques en matière de structure d'une organisation Google Cloud, consultez la page Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud.

Étape 3 : Évaluer vos options de transfert

Pour évaluer vos options de transfert de données, l'équipe de transfert doit prendre en compte plusieurs facteurs, dont les suivants :

  • Coût
  • Durée de transfert
  • Options de transfert hors connexion et en ligne
  • Outils et technologies de transfert
  • Sécurité

Coût

La plupart des coûts associés au transfert de données sont les suivants :

  • Coûts de mise en réseau.
    • L'entrée réseau vers Cloud Storage est gratuite. Cependant, si vous hébergez vos données chez un fournisseur de cloud public, vous devrez payer des frais de sortie et éventuellement des frais de stockage (opérations de lecture, par exemple) pour le transfert de vos données. Ces frais s'appliquent aux données provenant de Google ou d'un autre fournisseur cloud.
    • Si vos données sont hébergées dans un centre de données privé que vous exploitez, des frais supplémentaires peuvent également vous être facturés pour configurer une capacité de bande passante supplémentaire dans Google Cloud.
  • Coûts de stockage et coûts des opérations Cloud Storage pendant et après le transfert de données.
  • Coûts du produit (par exemple ceux associés à Transfer Appliance).
  • Frais de personnel liés à la constitution de votre équipe et à la mise en place d'un soutien logistique.

Durée de transfert

En informatique, peu d'éléments mettent autant en évidence les limitations matérielles des réseaux que le transfert de grandes quantités de données. Dans l'idéal, vous pouvez transférer 1 Go en huit secondes sur un réseau à 1 Gbit/s. Si vous montez en puissance et constituez un vaste ensemble de données (par exemple, 100 To), le temps de transfert est alors de 12 jours. Le transfert d'ensembles de données volumineux peut éprouver les limites de votre infrastructure et poser des problèmes à votre entreprise.

Vous pouvez utiliser le simulateur suivant pour comprendre le temps nécessaire à un transfert, en fonction de la taille de l'ensemble de données que vous déplacez et de la bande passante disponible pour le transfert. Un certain pourcentage du temps de gestion est pris en compte dans les calculs. De plus, l'efficacité de la bande passante est incluse, de sorte que les chiffres obtenus sont plus réalistes.

Vous ne souhaitez peut-être pas transférer de grands ensembles de données en dehors du réseau de votre entreprise pendant les heures de pointe. Si le transfert surcharge le réseau, personne ne pourra effectuer les tâches nécessaires ou critiques. C'est pourquoi l'équipe chargée du transfert doit prendre en compte le facteur temps.

Une fois les données transférées vers Cloud Storage, vous devez traiter les nouveaux fichiers à leur arrivée, en utilisant pour ce faire un certain nombre de technologies, telles que Dataflow.

Augmenter la bande passante réseau

La méthode employée pour augmenter la bande passante réseau dépend de la manière dont vous vous connectez à Google Cloud.

Dans le cadre d'un transfert de cloud à cloud entre Google Cloud et d'autres fournisseurs cloud, Google provisionne la connexion entre les centres de données des fournisseurs cloud, sans aucune configuration de votre part.

Si vous transférez des données entre votre centre de données privé et Google Cloud, plusieurs approches sont possibles :

  • Une connexion Internet publique à l'aide d'une API publique
  • L'appairage direct à l'aide d'une API publique
  • Cloud Interconnect à l'aide d'une API privée

Lorsque vous évaluez ces approches, il convient de prendre en compte vos besoins de connectivité à long terme. Vous pourriez en conclure qu'il est financièrement inenvisageable d'acquérir de la bande passante à des seules fins de transfert. Toutefois, si vous prenez en compte l'utilisation à long terme de Google Cloud et les besoins du réseau au sein de votre organisation, cet investissement en vaut la peine. Pour en savoir plus sur la connexion de vos réseaux à Google Cloud, consultez la page Choisir un produit de connectivité réseau.

Si vous adoptez une approche impliquant le transfert de données via l'Internet public, nous vous recommandons de vérifier auprès de votre administrateur de sécurité si les règles de votre entreprise interdisent ce type de transfert. Vérifiez également si la connexion Internet publique est utilisée pour votre trafic de production. Enfin, gardez à l'esprit que les transferts de données à grande échelle peuvent avoir un impact négatif sur les performances de votre réseau de production.

Transfert en ligne ou hors connexion

Une décision importante consiste à choisir entre un processus hors connexion ou en ligne pour votre transfert de données. Autrement dit, vous devez choisir entre le transfert sur un réseau, qu'il s'agisse de Cloud Interconnect ou de l'Internet public, et le transfert à l'aide de matériel de stockage.

Pour vous aider à prendre cette décision, nous mettons à votre disposition un simulateur de transfert qui vous aidera à estimer les différences de temps et de coût entre ces deux options. Le graphique suivant montre également certaines vitesses de transfert pour différentes tailles et bandes passantes d'ensembles de données. Un certain temps de gestion est intégré à ces calculs.

Graphique illustrant la relation entre la taille et la vitesse de transfert.

Comme indiqué précédemment, vous devrez peut-être déterminer si le coût pour obtenir des latences plus faibles pour votre transfert de données (par exemple, l'acquisition de bande passante réseau) est compensé par la valeur de cet investissement pour votre organisation.

Options disponibles auprès de Google

Google propose plusieurs outils et technologies pour vous aider à effectuer un transfert de données.

Choix des options de transfert Google

Le choix d'une option de transfert dépend de votre cas d'utilisation, comme indiqué dans le tableau suivant.

Points de départ et d'arrivée du transfert de données Scénario Produits suggérés
Autre fournisseur cloud (par exemple, Amazon Web Services ou Microsoft Azure) vers Google Cloud  : Service de transfert de stockage
Cloud Storage vers Cloud Storage (deux buckets différents)  : Service de transfert de stockage
Votre centre de données privé vers Google Cloud Bande passante suffisante pour respecter la date limite de votre projet Commande gcloud storage
Votre centre de données privé vers Google Cloud Bande passante suffisante pour respecter la date limite de votre projet Service de transfert de stockage pour les données sur site
Votre centre de données privé vers Google Cloud Bande passante insuffisante pour respecter la date limite de votre projet Transfer Appliance

Commande gcloud storage pour les transferts de données peu volumineux sur site

La commande gcloud storage est l'outil standard pour les transferts de petite à moyenne taille sur un réseau d'entreprise classique, d'un centre de données privé ou d'un autre fournisseur cloud vers Google Cloud. Bien que gcloud storage accepte l'importation d'objets jusqu'à la taille maximale d'objets Cloud Storage, les transferts d'objets volumineux sont plus susceptibles de rencontrer des échecs que les transferts de courte durée. Pour en savoir plus sur le transfert d'objets volumineux vers Cloud Storage, consultez la page Service de transfert de stockage pour les transferts volumineux de données sur site.

La commande gcloud storage est particulièrement utile dans les scénarios suivants :

  • Vos transferts doivent être exécutés par vos utilisateurs, à la demande ou pendant les sessions de ligne de commande.
  • Vous ne transférez que quelques fichiers ou des fichiers très volumineux, ou les deux.
  • Vous consommez la sortie d'un programme (sortie en streaming vers Cloud Storage).
  • Vous devez surveiller un répertoire contenant un nombre modéré de fichiers et synchroniser les mises à jour avec des latences très faibles.

Service de transfert de stockage pour les transferts volumineux de données sur site

Comme la commande gcloud storage, le service de transfert de stockage pour les données sur site permet d'effectuer des transferts depuis un stockage sur système de fichiers réseau (NFS) vers Cloud Storage. Le service de transfert de stockage pour les données sur site est conçu pour les transferts à grande échelle (jusqu'à plusieurs pétaoctets de données et des milliards de fichiers). Il est compatible avec les copies complètes ou incrémentielles, et fonctionne avec toutes les options de transfert répertoriées précédemment dans la section Choix des options de transfert Google. Il dispose également d'une interface utilisateur graphique gérée. Une fois la configuration effectuée, même les utilisateurs peu expérimentés peuvent l'utiliser pour déplacer des données.

Le service de transfert de stockage pour les données sur site est particulièrement utile dans les scénarios suivants :

  • Vous disposez de suffisamment de bande passante pour déplacer les volumes de données (consultez le simulateur de transfert de données Google Cloud).
  • Vous assurez une assistance auprès d'un grand nombre d'utilisateurs internes, pour lesquels un outil de ligne de commande peut être rebutant.
  • Vous avez besoin d'un système de rapports d'erreurs fiable et consignant tous les fichiers et objets déplacés.
  • Vous devez limiter l'impact des transferts sur les autres charges de travail de votre centre de données (ce produit peut respecter une limite de bande passante spécifiée par l'utilisateur).
  • Vous souhaitez exécuter des transferts récurrents selon un calendrier défini.

Vous configurez le service de transfert de stockage pour les données sur site en installant des logiciels sur site (appelés agents) sur les ordinateurs de votre centre de données.

Après avoir configuré le service de transfert de stockage, vous pouvez lancer des transferts dans la console Google Cloud en fournissant un répertoire source, un bucket de destination et une heure ou une planification. Le service de transfert de stockage explore de manière récursive les sous-répertoires et les fichiers du répertoire source et crée des objets avec un nom correspondant dans Cloud Storage (l'objet /dir/foo/file.txt devient un objet dans le bucket de destination nommé /dir/foo/file.txt). Le service de transfert de stockage tente à nouveau d'effectuer un transfert lorsqu'il rencontre des erreurs temporaires. Pendant l'exécution des transferts, vous pouvez surveiller le nombre de fichiers déplacés et leur vitesse globale, et afficher des exemples d'erreurs.

Lorsque le service de transfert de stockage termine un transfert, il génère un fichier délimité par des tabulations avec un enregistrement complet de tous les fichiers manipulés et des messages d'erreur reçus. Les agents sont tolérants aux pannes. Par conséquent, si un agent tombe en panne, le transfert se poursuit avec les autres agents. Les agents se mettent également à jour et se réparent spontanément. Vous n'avez donc pas à corriger les dernières versions ni à redémarrer le processus en cas de problème inattendu.

Éléments à prendre en compte lors de l'utilisation du service de transfert de stockage :

  • Utilisez une configuration d'agent identique sur chaque machine. Tous les agents doivent voir les mêmes installations NFS selon la même structure (avec les mêmes chemins d'accès relatifs). Cette configuration est obligatoire pour que le produit fonctionne.
  • Plus d'agents = plus de rapidité. Comme les transferts sont automatiquement mis en parallèle sur tous les agents, nous vous recommandons de déployer de nombreux agents afin d'utiliser votre bande passante disponible.
  • Les limites de bande passante peuvent protéger vos charges de travail. Vos autres charges de travail utilisent peut-être la bande passante de votre centre de données. Par conséquent, définissez une limite de bande passante pour empêcher que les transferts n'aient un impact sur vos contrats de niveau de service.
  • Prévoyez un délai pour examiner les erreurs. Les transferts volumineux peuvent souvent entraîner des erreurs nécessitant un examen. Le service de transfert de stockage vous permet d'afficher un échantillon des erreurs rencontrées, directement dans la console Google Cloud. Si nécessaire, vous pouvez charger l'enregistrement complet de toutes les erreurs de transfert dans BigQuery pour vérifier les fichiers ou évaluer les erreurs qui se sont produites après les nouvelles tentatives. Ces erreurs peuvent être dues à l'exécution d'applications qui écrivaient sur la source lors du transfert, ou révéler un problème nécessitant un dépannage (par exemple, une erreur d'autorisation).
  • Configurez Cloud Monitoring pour les transferts de longue durée. Le service de transfert de stockage Cloud Storage permet à Cloud Monitoring de surveiller l'état et le débit de l'agent. Vous pouvez donc définir des alertes qui vous avertissent en cas de panne ou de problème potentiel. Agir sur les échecs d'agent est important pour les transferts qui prennent plusieurs jours ou semaines, afin d'éviter des ralentissements importants ou des interruptions pouvant retarder la chronologie de votre projet.

Transfer Appliance pour les transferts volumineux

Transfer Appliance est une excellente solution pour les transferts à grande échelle (en particulier les transferts avec une bande passante réseau limitée), et notamment en l'absence de connexion réseau rapide, et si l'acquisition de bande passante supplémentaire s'avère trop coûteuse.

Transfer Appliance est particulièrement utile dans les scénarios suivants :

  • Votre centre de données est situé à distance, avec un accès limité ou inexistant à la bande passante.
  • La bande passante est disponible, mais ne peut pas être mobilisée dans des délais permettant de respecter votre date limite.
  • Vous avez accès à des ressources logistiques pour recevoir et connecter des appareils à votre réseau.

Avec cette option, tenez compte des éléments suivants :

  • Transfer Appliance exige que vous puissiez recevoir et renvoyer le matériel appartenant à Google.
  • En fonction de votre connexion Internet, la latence de transfert des données vers Google Cloud est généralement plus élevée avec Transfer Appliance qu'en ligne.
  • Transfer Appliance n'est disponible que dans certains pays.

Les deux principaux critères à prendre en compte avec Transfer Appliance sont le coût et la vitesse. Avec une connectivité réseau raisonnable (par exemple, 1 Gbit/s), le transfert de 100 To de données en ligne prend plus de 10 jours. Si ce délai est acceptable, le transfert en ligne constitue probablement une solution adaptée à vos besoins. Si votre connexion n'est que de 100 Mbit/s (ou moins pour un emplacement à distance), le même transfert va prendre plus de 100 jours. À ce stade, il convient d'envisager une option de transfert hors connexion, telle que Transfer Appliance.

L'acquisition d'un système Transfer Appliance est très simple. Dans la console Google Cloud, vous demandez un système Transfer Appliance, indiquez la quantité de données dont vous disposez, puis Google envoie un ou plusieurs systèmes à l'emplacement demandé. Vous disposez d'un délai, spécifié en jours, pour transférer vos données vers le système ("capture de données") avant de le renvoyer à Google.

Service de transfert de stockage pour les transferts cloud à cloud

Le service de transfert de stockage est un service entièrement géré et hautement évolutif permettant d'automatiser les transferts depuis d'autres clouds publics vers Cloud Storage. Par exemple, vous pouvez transférer des données d'Amazon S3 vers Cloud Storage à l'aide du service de transfert de stockage.

Pour HTTP, vous pouvez fournir au service de transfert de stockage une liste d'URL publiques dans un format spécifié. Cette approche nécessite de rédiger un script indiquant la taille de chaque fichier en octets, ainsi qu'un hachage MD5 encodé en base64 du contenu du fichier. La taille et le hachage du fichier sont parfois disponibles sur le site Web source. Si ce n'est pas le cas, vous devez disposer d'un accès local aux fichiers ; il vous sera alors plus facile d'utiliser la commande gcloud storage, comme décrit précédemment.

Si un transfert est en place, le service de transfert de stockage est un excellent moyen d'obtenir des données et de les conserver, en particulier lors d'un transfert depuis un autre cloud public.

Si vous souhaitez déplacer des données depuis un autre cloud non compatible avec le service de transfert de stockage, vous pouvez exécuter la commande gcloud storage à partir d'une instance de machine virtuelle hébergée dans le cloud.

Sécurité

La sécurité est la priorité de nombreux utilisateurs de Google Cloud. C'est pourquoi différents niveaux de sécurité sont proposés. La sécurité des données au repos (autorisation et accès aux systèmes de stockage source et de destination), la protection des données en transit et la protection de l'accès au produit de transfert sont quelques-uns des aspects de sécurité à prendre en compte. Le tableau suivant décrit ces aspects de sécurité par produit.

Produit Données au repos Données en transit Accès au produit de transfert
Transfer Appliance Toutes les données sont chiffrées au repos. Les données sont protégées par des clés gérées par le client. Tout le monde peut commander un système, mais pour l'utiliser, la personne doit avoir accès à la source de données.
Commande gcloud storage Clés d'accès requises pour l'accès à Cloud Storage, qui applique un chiffrement au repos. Les données sont envoyées via HTTPS et chiffrées en transit. Tout le monde peut télécharger et exécuter la Google Cloud CLI. Les utilisateurs doivent disposer d'autorisations sur les buckets et les fichiers locaux afin de déplacer des données.
Service de transfert de stockage pour les données sur site Clés d'accès requises pour l'accès à Cloud Storage, qui applique un chiffrement au repos. Les processus de l'agent peuvent accéder aux fichiers locaux en fonction des autorisations accordées par le système d'exploitation. Les données sont envoyées via HTTPS et chiffrées en transit. Vous devez disposer des droits de modification d'objets pour accéder aux buckets Cloud Storage.
Service de transfert de stockage Clés d'accès requises pour les ressources autres que Google Cloud (par exemple, Amazon S3). Les clés d'accès sont requises pour l'accès à Cloud Storage, qui applique un chiffrement au repos. Les données sont envoyées via HTTPS et chiffrées en transit. Vous devez disposer d'autorisations IAM pour que le compte de service puisse accéder aux autorisations de l'éditeur source et d'objets pour tous les buckets Cloud Storage.

Pour améliorer la sécurité de base, les transferts en ligne vers Google Cloud à l'aide de la commande gcloud storage sont réalisés via HTTPS, les données sont chiffrées en transit et, par défaut, toutes les données de Cloud Storage sont chiffrées au repos. Si vous utilisez Transfer Appliance, les clés de sécurité que vous contrôlez peuvent vous aider à protéger vos données. En règle générale, nous vous recommandons de faire appel à votre équipe de sécurité pour vous assurer que votre plan de transfert répond aux exigences réglementaires et à celles de votre entreprise.

Produits de transfert tiers

Pour une optimisation avancée au niveau du réseau ou pour des workflows de transfert en continu, vous devrez peut-être utiliser des outils plus avancés. Pour obtenir des informations complémentaires sur ces outils, consultez la page Partenaires Google Cloud.

Étape 4 : Évaluer les approches de migration des données

Lors de la migration des données, vous pouvez suivre ces étapes générales :

  1. Transférez les données de l'ancien site vers le nouveau site.
  2. Résolvez les éventuels problèmes d'intégration de données, par exemple la synchronisation des mêmes données à partir de plusieurs sources.
  3. Validez la migration des données.
  4. Faites la promotion du nouveau site en tant que copie principale.
  5. Lorsque vous n'avez plus besoin de l'ancien site comme option de secours, supprimez-le.

Vous devez baser votre approche de migration de données sur les questions suivantes :

  • Quel volume de données devez-vous migrer ?
  • À quelle fréquence ces données changent-elles ?
  • Pouvez-vous vous permettre le temps d'arrêt représenté par un intervalle de basculement lors de la migration de données ?
  • Quel est votre modèle actuel de cohérence des données ?

Aucune approche n'est réellement la meilleure. Ce choix dépend de l'environnement et de vos exigences.

Les sections suivantes présentent quatre approches de migration de données :

  • Maintenance planifiée
  • Réplication continue
  • Y (écriture et lecture)
  • Microservice d'accès aux données

Chaque approche aborde des problèmes différents, en fonction de l'ampleur et des exigences de la migration des données.

L'approche de microservice d'accès aux données est l'option recommandée pour une architecture de microservices. Cependant, les autres approches sont utiles pour la migration de données. Elles sont également utiles pendant la période de transition nécessaire à la modernisation de votre infrastructure afin de pouvoir utiliser la méthode de microservice d’accès aux données.

Le graphique suivant décrit les tailles respectives des intervalles de basculement, les efforts de refactorisation et les propriétés de flexibilité de chacune de ces approches.

Graphique à barres dont chaque barre indique les valeurs relatives de flexibilité, d'effort de refactorisation et de tailles d'intervalle de basculement pour chacune des 4 approches

Avant de suivre l'une de ces approches, assurez-vous que vous avez configuré l'infrastructure requise dans le nouvel environnement.

Maintenance planifiée

L'approche de maintenance planifiée est idéale si vos charges de travail peuvent se permettre un intervalle de basculement Elle est planifiée dans le sens où vous pouvez planifier le moment où votre intervalle de basculement se produit.

Dans cette approche, votre migration comprend les étapes suivantes :

  1. Copiez vers le nouveau site les données qui se trouvent dans l'ancien site. Cette copie initiale minimise l'intervalle de basculement. Après celle-ci, vous ne devez copier que les données modifiées au cours de cet intervalle.
  2. Effectuez des vérifications de cohérence et de validation des données afin de comparer les données de l'ancien site et les données copiées du nouveau site.
  3. Arrêtez les charges de travail et les services disposant d'un accès en écriture aux données copiées afin qu'aucune autre modification ne survienne.
  4. Synchronisez les modifications survenues après la copie initiale.
  5. Refactorisez les charges de travail et les services pour utiliser le nouveau site.
  6. Lancez vos charges de travail et vos services.
  7. Lorsque vous n'avez plus besoin de l'ancien site comme option de secours, supprimez-le.

L'approche de maintenance programmée fait peser l'essentiel de la charge sur les opérations, car une refactorisation minimale de la charge de travail et des services est nécessaire.

Réplication continue

Comme toutes les charges de travail ne peuvent pas se permettre un long intervalle de basculement, vous pouvez vous appuyer sur l'approche de maintenance planifiée en fournissant un mécanisme de réplication continue après les étapes de copie et de validation initiales. Lorsque vous concevez un tel mécanisme, vous devez également prendre en compte la fréquence de modification de vos données ; il peut être difficile de garder deux systèmes synchronisés.

L'approche de réplication continue est plus complexe que l'approche de maintenance planifiée. Cependant, elle minimise le temps nécessaire à l'intervalle de basculement requis, car elle minimise la quantité de données à synchroniser. La séquence d'une migration de réplication continue est la suivante :

  1. Copiez vers le nouveau site les données qui se trouvent dans l'ancien site. Cette copie initiale minimise l'intervalle de basculement. Après celle-ci, vous ne devez copier que les données modifiées pendant cet intervalle.
  2. Effectuez des vérifications de cohérence et de validation des données afin de comparer les données de l'ancien site et les données copiées du nouveau site.
  3. Configurez un mécanisme de réplication continue de l'ancien site vers le nouveau site.
  4. Arrêtez les charges de travail et les services ayant accès aux données à migrer (c'est-à-dire aux données impliquées dans l'étape précédente).
  5. Refactorisez les charges de travail et les services pour utiliser le nouveau site.
  6. Attendez que la réplication synchronise entièrement le nouveau site avec l'ancien site.
  7. Lancez vos charges de travail et vos services.
  8. Lorsque vous n'avez plus besoin de l'ancien site comme option de secours, supprimez-le.

Comme pour l'approche de maintenance programmée, l'approche de réplication continue place la majeure partie de la charge sur les opérations.

Y (écriture et lecture)

Si vos charges de travail comportent des exigences strictes de haute disponibilité et que vous ne pouvez pas vous permettre le temps d'arrêt représenté par un intervalle de basculement, vous devez adopter une approche différente. Pour ce scénario, vous pouvez utiliser une approche désignée dans le présent document par Y (écriture et lecture), qui est une forme de migration parallèle. Cette approche permet à la charge de travail d'écrire et de lire des données à la fois dans l'ancien site et dans le nouveau site au cours de la migration (la lettre Y est utilisée ici comme représentation graphique du flux de données pendant la période de migration).

Cette approche est résumée comme suit :

  1. Refactorisez les charges de travail et les services pour écrire des données à la fois sur l'ancien site et sur le nouveau site et pour lire à partir de l'ancien site.
  2. Identifiez les données écrites avant l'activation de l'écriture sur le nouveau site et copiez-les de l'ancien site vers le nouveau site. Avec la refactorisation précédente, cela garantit que les datastores sont alignés.
  3. Effectuez des vérifications de cohérence et de validation des données pour comparer les données de l'ancien site et celles du nouveau site.
  4. Basculez les opérations de lecture de l'ancien site vers le nouveau site.
  5. Effectuez un autre cycle de validation des données et de vérification de la cohérence pour comparer les données de l'ancien site et le nouveau site.
  6. Désactivez l'écriture dans l'ancien site.
  7. Lorsque vous n'avez plus besoin de l'ancien site comme option de secours, supprimez-le.

Contrairement aux approches de maintenance programmée et de réplication continue, l'approche Y (écriture et lecture) déplace la plupart des efforts des opérations vers le développement, en raison des multiples refactorisations.

Microservice d'accès aux données

Si vous souhaitez réduire les efforts de refactorisation nécessaires pour suivre l'approche Y (écriture et lecture), vous pouvez centraliser les opérations de lecture et d'écriture des données en refactorisant les charges de travail et les services pour utiliser un microservice d'accès aux données. Ce microservice évolutif devient le seul point d'entrée de votre couche de stockage de données et agit en tant que proxy pour cette couche. Parmi les approches abordées ici, cela vous apporte une flexibilité maximale, car vous pouvez refactoriser ce composant sans affecter les autres composants de l’architecture et sans nécessiter d'intervalle de basculement.

L'utilisation d'un microservice d'accès aux données ressemble beaucoup à l'approche Y (écriture et lecture). La différence est la suivante : les efforts de refactorisation ne se concentrent que sur le microservice d'accès aux données, au lieu de devoir refactoriser toutes les charges de travail et services qui accèdent à la couche de stockage de données. Cette approche est résumée comme suit :

  1. Refactorisez le microservice d'accès aux données pour écrire des données à la fois dans l'ancien site et le nouveau site. Les lectures sont effectuées sur l'ancien site.
  2. Identifiez les données écrites avant l'activation de l'écriture sur le nouveau site et copiez-les de l'ancien site vers le nouveau site. Avec la refactorisation précédente, cela garantit que les datastores sont alignés.
  3. Effectuez des vérifications de cohérence et de validation des données pour comparer les données de l'ancien site et celles du nouveau site.
  4. Refactorisez le microservice d'accès aux données à lire à partir du nouveau site.
  5. Effectuez un autre cycle de vérifications de cohérence et de validation des données pour comparer les données de l'ancien site et celles du nouveau site.
  6. Refactorisez le microservice d'accès aux données pour écrire uniquement dans le nouveau site.
  7. Lorsque vous n'avez plus besoin de l'ancien site comme option de secours, supprimez-le.

À l'instar de l'approche Y (écriture et lecture), l'approche utilisant un microservice d'accès aux données place la majeure partie de la charge sur le développement. Cependant, elle est nettement moins lourde que l’approche Y (écriture et lecture), car les efforts de refactorisation sont axés sur le microservice d’accès aux données.

Étape 5 : Préparer votre transfert

Pour un transfert volumineux ou comportant un grand nombre de dépendances, il est important de savoir comment vous allez utiliser votre produit de transfert. Les clients passent généralement par les étapes suivantes :

  1. Estimation des coûts et du ROI. Cette étape offre de nombreuses options pour faciliter la prise de décision.

  2. Tests fonctionnels. Lors de cette étape, vous confirmez que le produit peut être configuré correctement et que la connectivité réseau (le cas échéant) fonctionne. Vous testez également la possibilité de déplacer un échantillon représentatif de vos données (y compris les étapes associées et ne consistant pas directement en un transfert, telles que le déplacement d'une instance de VM) vers la destination.

    Vous pouvez généralement effectuer cette étape avant d'allouer toutes les ressources telles que les machines de transfert ou la bande passante. Les objectifs de cette étape sont les suivants :

    • Vérifier que vous pouvez installer et effectuer le transfert.
    • Révéler les problèmes potentiels entraînant une interruption du projet et qui bloquent le déplacement des données (par exemple, les routes réseau) ou vos opérations (par exemple, la formation nécessaire sur une étape ne consistant pas directement en un transfert).

  3. Tests de performances Au cours de cette étape, vous exécutez un transfert sur un grand échantillon (généralement 3 à 5 % de vos données) après avoir alloué les ressources de production, afin de :

    • confirmer que vous pouvez consommer toutes les ressources allouées et obtenir les débits attendus ;
    • identifier et corriger les goulots d'étranglement (par exemple, lenteur du système de stockage source).

Étape 6 : Assurer l'intégrité de votre transfert

Pour garantir l'intégrité de vos données lors d'un transfert, nous vous recommandons de prendre les précautions suivantes :

  • Activez la gestion des versions et la sauvegarde sur votre destination pour limiter les dommages liés aux suppressions accidentelles.
  • Validez vos données avant de supprimer les données sources.

Pour les transferts de données à grande échelle (se chiffrant en pétaoctets de données et en milliards de fichiers), même un taux d'erreur latent de référence du système de stockage source sous-jacent de 0,0001 % entraîne toujours une perte de données qui se compte en milliers de fichiers et en gigaoctets. En règle générale, les applications exécutées à la source sont déjà tolérantes à ces erreurs, auquel cas une validation supplémentaire n'est pas nécessaire. Dans certains cas exceptionnels (par exemple, l'archivage à long terme), une validation supplémentaire est nécessaire avant de pouvoir supprimer des données de la source en toute sécurité.

Selon les exigences de votre application, nous vous recommandons d'exécuter des tests d'intégrité des données une fois le transfert terminé, pour vous assurer que l'application continue de fonctionner comme prévu. De nombreux produits de transfert intègrent des contrôles d'intégrité des données. Cependant, en fonction de votre profil de risque, vous pouvez effectuer un contrôle supplémentaire des données et des applications qui les lisent avant de supprimer les données de la source. Par exemple, vous pouvez vérifier si une somme de contrôle que vous avez enregistrée et calculée indépendamment correspond aux données écrites sur la destination, ou confirmer qu'un ensemble de données utilisé par l'application a bien été transféré.

Étapes suivantes