Relocalisation de buckets

Ce document décrit le service de relocalisation de bucket Cloud Storage, qui permet de relocaliser des buckets sans serveur entre des zones géographiques. Le déplacement de buckets vous permet de déplacer un bucket existant d'un emplacement vers un autre sans modifier son nom ni transférer manuellement les données qu'il contient.

En fonction de vos objectifs et de l'utilisation de vos buckets, vous devrez planifier soigneusement la relocalisation de vos buckets pour minimiser les perturbations et les relocaliser correctement. Pour savoir comment déplacer des buckets, consultez Déplacer des buckets.

Avantages

Voici les avantages du déplacement de buckets :

• Migration simplifiée : vous pouvez déplacer des buckets avec un minimum de frais opérationnels. Aucun script complexe ni processus en plusieurs étapes ne sont nécessaires.

• Fonctionnement continu : vos applications restent accessibles tout au long du processus de migration, 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.

• Performances améliorées : la colocation 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 des buckets conserve les métadonnées des objets. La conservation des métadonnées d'objet assure la compatibilité avec les applications et les workflows existants une fois le bucket déplacé.

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

Cas d'utilisation

Voici quelques cas d'utilisation que vous pouvez réaliser en relocalisant vos buckets :

• Réduisez les coûts de transfert de données : évitez les coûts de transfert de données en déplaçant votre bucket plus près des charges de travail qui accèdent aux données du bucket. Par exemple, si vos données sont stockées aux États-Unis et principalement consultées depuis l'Europe, vous pouvez déplacer votre bucket vers un emplacement européen pour réduire les coûts de transfert de données.

• Améliorer les performances : améliorez la vitesse et la réactivité de votre application en rapprochant vos données de vos charges de travail 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 : protégez 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 une région birégionale ou multirégionale pour améliorer la disponibilité et la reprise après sinistre.

Types de déménagement

Il existe deux types de relocalisation de buckets :

• Relocalisation de buckets avec temps d'arrêt en écriture : lors de la relocalisation de buckets avec temps d'arrêt en écriture, vous ne pouvez pas effectuer d'opérations d'écriture d'objets pendant le processus de relocalisation.

• Relocalisation de buckets sans temps d'arrêt pour l'écriture : dans ce type de relocalisation, vous pouvez continuer à effectuer des opérations d'écriture d'objets sans interruption pendant que la relocalisation du bucket s'effectue en arrière-plan.

Les emplacements source et de destination du bucket déterminent si le déplacement d'un bucket implique un temps d'arrêt en écriture. Le tableau suivant montre comment l'emplacement de votre bucket affecte le temps d'arrêt en écriture lors d'un déplacement, y compris les différences entre les déplacements avec et sans temps d'arrêt.

Spécification	Relocalisation de buckets avec temps d'arrêt en écriture	Relocalisation de bucket sans temps d'arrêt pour l'écriture
Emplacement du bucket	Le déplacement d'un bucket entre les emplacements suivants entraîne un temps d'arrêt : Régions Emplacements birégionaux Emplacements multirégionaux Multirégions et birégions prédéfinies Les emplacements multirégionaux et birégionaux configurables si les deux emplacements ont des codes multirégionaux différents	Le déplacement d'un bucket entre les emplacements suivants n'entraîne aucune indisponibilité si les deux emplacements partagent le même code multirégional : Emplacements birégionaux configurables Emplacements multirégionaux et birégionaux configurables
Disponibilité en écriture	Vous ne pouvez pas effectuer d'opérations d'écriture lors de la dernière étape de synchronisation.	Les opérations d'écriture se poursuivent sans interruption pendant le déplacement. Remarque : Les modifications des règles sans temps d'arrêt en écriture prennent au moins sept jours, car elles doivent attendre la fin des importations résumables en cours.
Implication des utilisateurs	Vous devez lancer l'étape de finalisation de l'arrêt des opérations d'écriture.	Aucune étape de finalisation explicite n'est requise.
Impact sur la performance	Vous ne pouvez pas écrire ni mettre à jour d'objets dans le bucket lors de la dernière étape de synchronisation.	La latence de lecture et d'écriture des objets peut augmenter pendant la relocalisation.
Annulation de la relocalisation de buckets	Plus rapide que les relocalisations, sans temps d'arrêt pour l'écriture.	La résiliation n'est pas instantanée et peut prendre plus de temps en raison de la nécessité de remplacer les objets.
Compatibilité avec les fonctionnalités	Offre moins de fonctionnalités que les relocations sans indisponibilité en écriture. Pour en savoir plus sur les fonctionnalités non compatibles, consultez Fonctionnalités non compatibles.	Des limites existent pour des fonctionnalités telles que les importations en plusieurs parties, les règles de conservation, Firebase et appspot. Pour en savoir plus sur ces limites, consultez Limites.
Durée minimale de la relocalisation	Aucun	Sept jours

Comprendre le processus de relocalisation de buckets

Le déplacement de buckets vous permet de transférer 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 l'emplacement où vous souhaitez les transférer.

Le schéma suivant illustre le processus de déplacement des buckets :

^* La synchronisation finale n'est requise que pour les migrations avec temps d'arrêt en écriture.

Le tableau suivant liste les trois étapes principales et leur description :

Étape	Description
Effectuer une simulation (facultatif)	Simule le processus de transfert de bucket pour identifier les problèmes potentiels avant le début du transfert de données.
Lancer 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 susceptible d'affecter le processus de relocalisation. Toutefois, vous pouvez écrire, modifier et supprimer des objets dans le bucket. Les facteurs qui influencent la durée sont les suivants : La fréquence des mises à jour, des suppressions ou des ajouts d'objets dans le bucket a un impact direct sur la durée de la copie. Un taux de variation plus élevé nécessite plus de temps. Il existe un taux de déplacement d'objet maximal `Rm, objets/seconde`. Avec `N` objets au total et un taux de mise à jour de `R objets/seconde`, la durée de l'étape de copie peut être estimée à `N / (Rm - R)` secondes. Les grands buckets nécessitent plus de temps de relocation en raison de la bande passante limitée. La taille des objets individuels a une incidence sur le temps de copie. Les objets de plus de 10 Go mettent plus de temps à être transférés que ceux de moins de 10 Go en raison des contraintes de bande passante. Par exemple, la copie d'un objet de 1 To prend un jour.
Lancer l'étape de synchronisation finale (uniquement requis pour les migrations avec temps d'arrêt en écriture)	Une fois la synchronisation finale lancée, le bucket est 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. Toutefois, vous pouvez continuer à lire les données du bucket. Une fois toutes les données transférées et validées, et le bucket opérationnel dans le nouvel emplacement, le verrouillage en écriture est automatiquement supprimé. Vous pouvez ensuite reprendre l'écriture et la mise à jour des objets dans le bucket.

Limites

Le service de relocalisation de buckets accepte jusqu'à cinq relocalisations simultanées depuis le même emplacement dans un projet.

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

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

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

Limites de traitement des données

Voici les limites à respecter lors de la gestion des données pendant la migration :

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

• Gestion des objets par la classe automatique : la classe automatique utilise les modèles d'accès pour déterminer quand transférer les objets vers des classes de stockage à froid. Lors de la synchronisation finale du processus de relocation du bucket, la classe automatique est suspendue et les objets ne sont pas transférés vers des classes de stockage à froid. Une fois la synchronisation finale terminée, Autoclass reprend.

  • Les objets d'une classe de stockage standard sont traité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é pendant la relocalisation, il est traité comme s'il avait fait l'objet d'un accès. Par conséquent, le processus de transfert réinitialise la période sans accès. Même si un objet était sur le point d'être transféré vers le stockage Nearline avant le déplacement, il doit attendre 30 jours supplémentaires après la fin du transfert.

  • Les objets d'une classe de stockage autre que Standard sont traités comme suit :

    • Le déplacement d'objets dans les classes de stockage Nearline, Coldline ou Archive n'est pas considéré comme un accès. Par conséquent, la période sans accès pour ces objets n'est pas affectée.

    • Lorsque vous déplacez un bucket, si vous accédez fréquemment à des objets dans des buckets avec une classe de stockage autre que Standard, comme Nearline, Coldline ou Archive, le bucket ne passe pas automatiquement à une classe de stockage plus chaude. Par exemple, le bucket ne passe pas automatiquement du stockage Archive au stockage Coldline ni du stockage Coldline au stockage Standard, même si les objets sont fréquemment consultés. Ce comportement empêche les transitions automatiques entre classes de stockage lors du déplacement.

    • Si un objet devait passer à une classe de stockage plus froide (par exemple, du stockage Nearline au stockage Coldline), le processus de déplacement n'interférera pas avec la planification. La transition se déroule comme prévu une fois le transfert terminé.

• Taille maximale des objets : la taille des objets à déplacer est limitée à 2 To.

Importations en plusieurs parties

Les importations en plusieurs parties ne sont pas compatibles avec le déplacement de buckets avec temps d'arrêt en écriture, quel que soit leur état (terminées, en cours ou démarrées pendant le déplacement). Si vous avez terminé les importations en plusieurs parties dans le bucket que vous souhaitez déplacer, vous devez réimporter les objets sans utiliser de méthodes en plusieurs parties et supprimer les importations en plusieurs parties. Sinon, le déplacement échouera. Si vous importez des objets à l'aide d'importations multiparties lors du déplacement d'un bucket avec un temps d'arrêt en écriture, une erreur FAILED_PRECONDITION se produit.

Fonctionnalités non compatibles

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

• Clés de chiffrement gérées par le client (CMEK) ou clés de chiffrement fournies par le client (CSEK).

• Règles de conservation verrouillées.

• Objets soumis à une préservation temporaire.

• Buckets avec l'espace de noms hiérarchique activé.

• Tags. Nous vous déconseillons d'ajouter des tags pendant le transfert, car cela peut le faire échouer.

• Désactivez Anywhere Cache. Bien que le cache Anywhere puisse être activé lors de l'étape de copie incrémentielle des données, il empêche l'étape de synchronisation finale de se terminer.

• Buckets Appspot. En guise de solution de contournement pour les buckets par défaut créés par App Engine, envisagez de migrer Container Registry vers Artifact Registry.

• les buckets Firebase. Vous ne pouvez pas déplacer les buckets associés à Firebase.

Restrictions opérationnelles

La relocalisation de buckets avec temps d'arrêt en écriture est soumise aux restrictions opérationnelles suivantes :

• Restriction liée au projet : vous ne pouvez pas déplacer des buckets d'un projet à un autre.

• 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 pendant le déplacement.

• Augmentation progressive du taux de requêtes : les buckets déplacés sont soumis aux mêmes consignes d'augmentation progressive du taux de requêtes que les buckets nouvellement créés.

Relocalisation sans limites de temps d'arrêt en écriture

La relocalisation de buckets sans temps d'arrêt en écriture présente les limites suivantes :

• Règles de conservation : toutes les règles de conservation doivent être déverrouillées avant le déplacement.

• Buckets Firebase et Appspot : la relocalisation n'est pas possible pour les buckets associés à Firebase ou Appspot.

• Mises à jour sur la progression : la progression de la migration n'est pas forcément linéaire.

• Importations en plusieurs parties : seules les importations en plusieurs parties terminées sont acceptées lors du déplacement de buckets. Les importations en plusieurs parties en cours ne sont pas compatibles avec les objets lors du déplacement de buckets. Elles doivent être finalisées ou annulées avant le déplacement de buckets. Vous devez réimporter les objets sans utiliser de méthodes multiparties. Si vous importez des objets à l'aide d'importations en plusieurs parties lors du déplacement d'un bucket, une erreur FAILED_PRECONDITION se produit.

Zones géographiques non acceptées

Le déplacement de buckets n'est pas possible pour les buckets source et de destination situés dans les emplacements suivants :

Type de lieu	Zones géographiques non acceptées
Régions	ME-CENTRAL1 ME-WEST1
Emplacements birégionaux prédéfinis	EUR5 EUR7 EUR8

Tarifs

Pour en savoir plus sur les tarifs associés au déplacement de buckets, consultez la page Tarifs de Cloud Storage.

Étapes suivantes

• Découvrez comment planifier la relocalisation d'un bucket.
• Découvrez comment déplacer des buckets.