Relocalisation de buckets

Cette page présente le déplacement de bucket, ses avantages, ses cas d'utilisation, son fonctionnement et ses limites.

Présentation

La relocalisation de buckets Cloud Storage permet de migrer des buckets entre des zones géographiques sans serveur. Grâce à la relocalisation de bucket, vous pouvez effectuer les opérations suivantes:

  • Déplacer un bucket existant d'un emplacement à un autre sans modifier son nom ni nécessiter de transfert manuel des données du bucket

  • Améliorez les performances et la rentabilité en alignant la configuration Cloud Storage de votre charge de travail sur Compute Engine.

Avantages

Les avantages de la relocalisation de buckets sont les suivants:

  • Migration simplifiée: vous pouvez déplacer des buckets avec un coût opérationnel minimal. Vous n'avez pas besoin de scripts complexes ni de processus en plusieurs étapes.

  • Fonctionnement continu: vos applications restent accessibles tout au long du processus de relocalisation, sans temps d'arrêt pour les opérations de lecture et avec un temps d'arrêt minimal pour les opérations d'écriture.

  • Amélioration des performances: la colocalisation des ressources Compute Engine et Cloud Storage dans la même région peut réduire la latence et améliorer les performances.

  • Conservation des métadonnées: le processus de relocalisation de bucket conserve les métadonnées de l'objet. La conservation des métadonnées d'objets garantit la compatibilité avec les applications et les workflows existants après le déplacement du bucket.

  • Configurations de classe de stockage: vous pouvez conserver les paramètres existants de la classe Cloud Storage, y compris la classe automatique. En préservant la classe de stockage, vous vous assurez que votre structure de coûts reste cohérente après le transfert.

Pourquoi utiliser la relocalisation de buckets ?

Voici quelques cas d'utilisation de la relocalisation de vos buckets:

  • Réduire les coûts de transfert de données: si vos données sont fréquemment consultées à partir d'un emplacement éloigné de l'endroit où elles sont stockées, vous pouvez déplacer votre bucket vers un emplacement proche de l'endroit d'où elles sont consultées, ce qui réduit les coûts de transfert de données. Par exemple, si vos données sont principalement consultées depuis l'Europe, mais qu'elles sont stockées aux États-Unis, vous pouvez déplacer votre bucket vers un emplacement en Europe pour réduire les coûts.

  • Améliorer les performances: vous pouvez améliorer la vitesse et la réactivité de votre application en rapprochant vos données de votre Compute Engine. Par exemple, si votre application s'exécute dans us-central1, mais que vos données se trouvent dans asia-east1, vous pouvez déplacer votre bucket vers us-central1 pour réduire la latence.

  • Améliorez la résilience: vous pouvez protéger vos données critiques contre les pannes régionales. Par exemple, si vos données sont stockées dans une seule région, vous pouvez les déplacer vers des emplacements birégionaux ou multirégionaux pour améliorer la disponibilité et la reprise après sinistre.

Types de déménagement

Le fait qu'un déplacement de bucket implique un temps d'arrêt d'écriture dépend des emplacements source et de destination du bucket. Pour en savoir plus sur l'impact de l'emplacement sur le type de transfert, consultez Déterminer le type de transfert de votre bucket. Les deux types de relocalisation de buckets sont les suivants:

  • Déplacement de bucket avec temps d'arrêt d'écriture: lors du déplacement de bucket avec temps d'arrêt d'écriture, il existe une période pendant laquelle vous ne pouvez pas effectuer d'opérations d'écriture d'objets pendant le processus de déplacement de bucket.

  • Déplacement de bucket sans temps d'arrêt d'écriture: dans le cas d'un déplacement de bucket sans temps d'arrêt d'écriture, vous pouvez continuer à effectuer des opérations d'écriture d'objets sans interruption pendant que le déplacement de bucket se produit en arrière-plan.

Le tableau suivant décrit les principales différences entre les types de relocalisation avec et sans temps d'arrêt en écriture:

Spécification Relocalisation de buckets avec temps d'arrêt en écriture Relocalisation de buckets sans temps d'arrêt d'écriture
Disponibilité en écriture Impossible d'effectuer des opérations d'écriture lors de l'étape de synchronisation finale. Aucune interruption des opérations d'écriture.
Implication des utilisateurs L'utilisateur doit lancer l'étape de finalisation de l'arrêt d'écriture. Aucune étape de finalisation explicite n'est requise.
Impact sur la performance Impossible d'écrire ou de mettre à jour des objets dans le bucket lors de la dernière étape de synchronisation. Latence de lecture et d'écriture des objets susceptible d'augmenter lors de la relocalisation.
Annulation de la relocalisation de buckets Plus rapide que les transferts sans temps d'arrêt d'écriture. L'annulation n'est pas instantanée. Peut prendre plus de temps en raison de la nécessité de remplir les objets.
Compatibilité avec les fonctionnalités Moins de fonctionnalités disponibles que pour les migrations sans temps d'arrêt en écriture. Restrictions concernant des fonctionnalités telles que les importations multiparties, les règles de conservation, Firebase et appspot. Pour en savoir plus sur ces limites, consultez la section Limites.

Déterminer le type de relocalisation de votre bucket

Les emplacements des buckets source et de destination déterminent le type de transfert.

Lorsque vous déplacez un bucket entre des régions, des régions duales ou des emplacements multirégionaux, vous subissez des temps d'arrêt pendant lesquels vous ne pouvez pas écrire dans le bucket. Toutefois, vous pouvez déplacer un bucket sans temps d'arrêt dans les cas suivants:

  • Déplacez-vous d'un emplacement multirégional vers un emplacement birégional configurable si les deux emplacements partagent le même code multirégional.

  • Déplacez-vous entre les emplacements birégionaux configurables si les deux emplacements partagent le même code multirégional.

  • Déplacez-vous d'un emplacement birégional configurable vers un emplacement multirégional si les deux emplacements partagent le même code multirégional.

Comprendre le processus de réaffectation de buckets

La relocalisation de bucket vous permet de déplacer vos données d'un bucket source vers un bucket de destination. Le bucket source contient les données que vous souhaitez déplacer, et le bucket de destination est celui vers lequel vous souhaitez déplacer vos données.

Le schéma suivant illustre le flux de processus de réaffectation de buckets.

Flux de processus de relocalisation de buckets.
Figure 1. Flux de processus de réinstallation de bucket (cliquez pour agrandir).

Les étapes numérotées font référence aux numéros du diagramme. Le diagramme montre les étapes suivantes:

  1. Copie incrémentielle des données: l'étape de copie incrémentielle des données copie les données du bucket source vers le bucket de destination. Les métadonnées du bucket sont verrouillées en écriture pour empêcher toute modification du bucket qui pourrait affecter le processus de réinstallation. Toutefois, vous pouvez écrire, modifier et supprimer des objets dans le bucket. Voici les facteurs qui influencent la durée:

    • La fréquence des mises à jour, suppressions ou ajouts d'objets dans le bucket a un impact direct sur la durée de la copie. Un taux de changement plus élevé nécessite plus de temps. Il existe un taux maximal de mouvement d'objets Rm, objects/second. Avec un nombre total d'objets de N et un taux de mise à jour de R objects/second, la durée de l'étape de copie peut être estimée à N / (Rm - R) secondes.

    • Les buckets volumineux nécessitent plus de temps de relocalisation en raison de la bande passante limitée.

    • La taille des objets individuels a une incidence sur le temps de copie. Le transfert d'objets de plus de 10 Go prend plus de temps que celui d'objets de moins de 10 Go en raison de contraintes de bande passante. Par exemple, la copie d'un objet de 1 To prend un jour. Nous vous recommandons de décomposer les objets volumineux en objets plus petits de 0,1 à 1 Go.

    Pour savoir comment lancer la copie incrémentielle des données, consultez la section Lancer l'étape de copie incrémentielle des données.

  2. Surveiller la copie incrémentielle des données: pour afficher l'état de l'étape de copie incrémentielle des données, vous pouvez consulter régulièrement la liste des opérations de longue durée. Pour savoir comment vérifier l'état de l'étape de copie de données incrémentielle, consultez la section Surveiller l'étape de copie de données incrémentielle.

  3. Synchronisation finale: pour les relocalisations avec temps d'arrêt d'écriture, une fois la copie incrémentielle des données terminée, vous devez déclencher l'étape de synchronisation finale. L'étape de synchronisation finale inclut une période pendant laquelle vous ne pouvez pas écrire dans le bucket pour garantir la cohérence des données. La dernière étape de synchronisation comprend les actions suivantes:

    1. Le bucket est temporairement verrouillé en écriture. Par conséquent, vous ne pouvez pas écrire ni mettre à jour d'objets dans le bucket pendant cette période, ce qui évite les incohérences de données.

    2. Toutes les modifications apportées aux données d'objet d'un bucket depuis l'étape de copie incrémentielle sont copiées dans le bucket de destination, ce qui garantit que le bucket déplacé contient les données les plus à jour. Une fois la copie des objets terminée, une comparaison est effectuée pour garantir la parité des données entre les buckets source et de destination. Après la comparaison des données, l'emplacement du bucket est mis à jour et toutes les requêtes sont redirigées vers le nouvel emplacement.

    3. Une fois que toutes les données ont été transférées, validées et que le bucket est opérationnel au nouvel emplacement, le verrouillage en écriture est supprimé. Vous pouvez ensuite reprendre l'écriture et la mise à jour des objets dans le bucket.

    Pour savoir comment lancer la dernière étape de synchronisation, consultez Lancer la dernière étape de synchronisation.

Limites

Le service de relocalisation de bucket accepte jusqu'à cinq relocalisations simultanées à partir du même emplacement dans un projet.

Les sections suivantes décrivent les limites qui s'appliquent aux transferts avec et sans temps d'arrêt en écriture.

Déplacement avec des limites de temps d'arrêt en écriture

La relocalisation avec temps d'arrêt d'écriture présente les limites listées dans les sections suivantes.

Limites de gestion des données

Voici les limites concernant la gestion des données lors de la migration:

  • Défaillance des tables: les tables externes BigLake et les tables BigQuery utilisant Apache Iceberg seront endommagées et devront être recréées manuellement. La détection automatique des tables concernées n'est pas disponible.

  • Gestion des objets Autoclass: Autoclass utilise des modèles d'accès pour déterminer quand transférer des objets vers des classes de stockage à froid. Lors de la synchronisation finale du processus de réinstallation des buckets, Autoclass est mis en pause et les objets ne sont pas transférés vers des classes de stockage plus froides. Une fois la synchronisation finale terminée, Autoclass reprend.

    • Les objets d'une classe de stockage standard sont gérés comme suit:

      • Les objets de la classe de stockage standard doivent être inaccessibles pendant 30 jours avant de pouvoir être transférés vers une classe plus froide, comme le stockage Nearline. Lorsqu'un objet de la classe de stockage standard est déplacé lors de la relocalisation, il est traité comme s'il avait été consulté. Par conséquent, le processus de transfert réinitialise la période d'inaccessibilité. Même si un objet était sur le point d'être transféré vers le stockage Nearline avant le transfert, il doit attendre encore 30 jours après la fin du transfert.

    • Les objets d'une classe de stockage non standard sont gérés comme suit:

      • Le fait de déplacer des objets dans les classes de stockage Nearline, Coldline ou Archive ne compte pas comme un accès à ces objets. Par conséquent, la période d'accès refusé pour ces objets n'est pas affectée.

      • Si vous lisez ou écrivez un objet dans un bucket de classe de stockage non standard lors de la relocalisation, il ne sera pas automatiquement mis à niveau vers une classe plus chaude, comme le stockage standard. Cela permet d'éviter les transitions de classe de stockage inutiles pendant le processus de relocalisation.

      • Si un objet devait être rétrogradé vers une classe de stockage plus froide, par exemple du stockage Nearline au stockage Coldline, le processus de réinstallation n'interférera pas avec le calendrier. La rétrogradation se déroulera comme prévu une fois la migration terminée.

  • Limite de taille des objets: une limite de 2 To s'applique aux tailles d'objets pour le transfert.

Fonctionnalités non compatibles

Les buckets utilisant les fonctionnalités suivantes ne peuvent pas être déplacés:

Restrictions opérationnelles

Le déplacement de bucket avec temps d'arrêt d'écriture présente les restrictions opérationnelles suivantes:

  • Restriction de projet: vous ne pouvez pas déplacer des buckets entre des projets.
  • Importations avec reprise: les importations avec reprise en cours doivent être finalisées avant l'étape de synchronisation finale pour éviter toute perte de données.
  • Mise à jour des métadonnées: vous ne pouvez pas mettre à jour les métadonnées d'un bucket lors de la relocalisation.
  • Augmentation du débit des requêtes: les buckets déplacés sont soumis aux mêmes consignes d'augmentation du débit des requêtes que les buckets nouvellement créés.

Relocalisation sans limite de temps d'arrêt d'écriture

Le déplacement de bucket sans temps d'arrêt d'écriture présente les limites suivantes:

  • Importations en plusieurs parties: les importations en plusieurs parties inachevées ne sont pas acceptées et doivent être terminées ou annulées avant le transfert. Les nouvelles importations en plusieurs parties sont bloquées pendant le transfert.
  • Règles de conservation: toutes les règles de conservation doivent être déverrouillées avant le transfert.
  • Buckets Firebase et Appspot: la relocalisation n'est pas prise en charge pour les buckets associés à Firebase ou Appspot.
  • Informations sur la progression: les informations sur la progression de la migration peuvent ne pas être linéaires.

Région non disponible

Le déplacement de bucket n'est pas disponible dans la région me-central1 pour les buckets source ou de destination.

Étape suivante