Ce document explique comment la relocalisation de bucket Cloud Storage vous aide à relocaliser des buckets sans serveur entre des emplacements géographiques. La relocalisation de bucket vous permet de déplacer un bucket existant d'un emplacement à un autre sans modifier son nom ni transférer manuellement les données qu'il contient.
Avant de commencer le processus de déplacement, planifiez la relocalisation de votre bucket pour minimiser les perturbations. Pour savoir comment effectuer une relocalisation, consultez Relocaliser des buckets.
Avantages
La relocalisation des buckets offre plusieurs avantages :
Migration simplifiée : vous pouvez relocaliser des buckets avec un minimum de frais généraux 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 relocalisation, sans interruption des 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 préserve les métadonnées des objets. La conservation des métadonnées des objets permet de maintenir la compatibilité avec les applications et workflows existants après le déplacement du bucket.
Configurations de classe de stockage : vous pouvez conserver les paramètres de classe Cloud Storage existants, y compris la classe automatique. Conserver la classe de stockage permet de maintenir la cohérence de votre structure de coûts après la relocalisation.
Cas d'utilisation
Voici quelques cas d'utilisation visés par la relocalisation de bucket :
Réduire les coûts de transfert de données : abaissez les coûts de transfert de données en relocalisant votre bucket plus près des charges de travail qui accèdent à ses données. 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 dansasia-east1, vous pouvez relocaliser votre bucket dansus-central1pour réduire la latence.Améliorer 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 relocaliser dans un emplacement birégional ou multirégional pour améliorer la disponibilité et faciliter la reprise après sinistre.
Types de relocalisation
Il existe deux types de relocalisation de bucket :
Relocalisation de bucket avec interruption des opérations d'écriture : lors d'une relocalisation de bucket avec interruption des opérations d'écriture, vous ne pouvez pas effectuer d'opérations d'écriture d'objets pendant le processus de relocalisation.
Relocalisation de bucket sans interruption des opérations d'écriture : dans ce type de relocalisation, vous pouvez continuer à effectuer des opérations d'écriture d'objets sans interruption tandis que la relocalisation du bucket se déroule en arrière-plan.
Les emplacements source et de destination du bucket déterminent si sa relocalisation implique une interruption des opérations d'écriture. Le tableau suivant montre comment l'emplacement de votre bucket affecte les interruptions des opérations d'écriture lors d'une relocalisation, et détaille les différences entre les relocalisations avec et sans interruption des écritures.
| Spécification | Relocalisation de bucket avec interruption des opérations d'écriture | Relocalisation de bucket sans interruption des opérations d'écriture |
|---|---|---|
| Emplacement du bucket | La relocalisation d'un bucket entre les emplacements suivants entraîne un temps d'arrêt :
|
La relocalisation d'un bucket entre les emplacements suivants n'entraîne aucun temps d'arrêt si les deux emplacements partagent le même code multirégional :
|
| Disponibilité en écriture | Vous ne pouvez pas effectuer d'opérations d'écriture lors de l'étape de synchronisation finale. | Les opérations d'écriture se poursuivent sans interruption pendant la relocalisation. Remarque : Les modifications des règles sans interruption des opérations d'écriture prennent au moins sept jours, car elles doivent attendre la fin des importations avec reprise en cours. |
| Implication de l'utilisateur | Vous devez lancer l'étape de finalisation de l'interruption des opérations d'écriture. | Aucune étape de finalisation explicite n'est requise. |
| Impact sur les performances | Vous ne pouvez pas écrire d'objets ni en mettre à jour dans le bucket lors de l'étape de synchronisation finale. | La latence de lecture et d'écriture des objets peut augmenter pendant la relocalisation. |
| Annulation de la relocalisation d'un bucket | Plus rapide que les relocalisations sans interruption des opérations d'écriture. | L'annulation n'est pas instantanée et peut prendre plus de temps en raison de la nécessité de réinsérer les objets. |
| Prise en charge de fonctionnalités | Offre moins de fonctionnalités que les relocations sans interruption des opérations d'écriture. Pour en savoir plus sur les fonctionnalités non disponibles, consultez Fonctionnalités non compatibles. | Des limites existent pour les 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 | Aucune | Sept jours |
Comprendre le processus de relocalisation de bucket
La relocalisation de bucket 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 vers lequel vous souhaitez les transférer.
Le schéma suivant illustre le processus de relocalisation de bucket :
* La synchronisation finale n'est requise que pour les relocalisations avec interruption des opérations d'écriture.
Le tableau suivant présente les trois étapes principales et leur description :
| Étape | Description |
|---|---|
Effectuer un dry run | Simule le processus de relocalisation du bucket pour identifier les problèmes potentiels avant le début du transfert de données effectif. |
Copie les données du bucket source vers le bucket de destination. Les métadonnées du bucket sont verrouillées en écriture afin d'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 :
|
|
Lancer l'étape de synchronisation finale | 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 a pour avantage d'éviter les incohérences dans les données. Toutefois, vous pouvez continuer à lire les données du bucket. Une fois que toutes les données ont été transférées et vérifiées, et que le bucket est opérationnel dans le nouvel emplacement, le verrouillage en écriture est automatiquement supprimé. Vous pouvez alors 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 interruption des opérations d'écriture.
Limites de la relocalisation avec interruption des opérations d'écriture
La relocalisation avec interruption des opérations d'écriture présente les limites listées dans les sections suivantes.
Limites en termes de traitement des données
Voici les limites à respecter pour le traitement des données pendant la relocalisation :
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 en 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 relocalisation de 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, la classe automatique est rétablie.
Les objets en classe de stockage standard sont traités comme suit :
- Les objets en 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 en 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 relocalisation 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, une attente de 30 jours supplémentaires est requise à l'issue de la relocalisation.
Les objets d'une classe de stockage autre que la classe standard sont traités comme suit :
La relocalisation d'objets dans les classes de stockage Nearline, Coldline ou Archive n'est pas considérée comme un accès. Par conséquent, la période sans accès appliquée à ces objets n'est pas affectée.
Lorsque vous relocalisez un bucket, si vous accédez fréquemment à des objets dans un bucket défini sur 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 d'une relocalisation.
Si le passage d'un objet à une classe de stockage plus froide (par exemple, de Nearline à Coldline) était planifié, le processus de relocalisation n'interférera pas avec la planification. La transition se déroule comme prévu une fois la relocalisation terminée.
Taille maximale des objets : la taille des objets à déplacer dans le cadre d'une relocalisation est limitée à 2 To.
Importations en plusieurs parties
Les importations en plusieurs parties ne sont pas compatibles avec les relocalisations de buckets avec interruption des opérations d'écriture, quel que soit leur état (terminée, en cours ou démarrée pendant la relocalisation). Si vous avez terminé les importations en plusieurs parties dans le bucket que vous souhaitez relocaliser, vous devez réimporter les objets sans utiliser de méthode en plusieurs parties et supprimer les importations en plusieurs parties, faute de quoi le déplacement échouera. Si vous tentez d'importer des objets via des importations en plusieurs parties lors d'une relocalisation de bucket avec interruption des opérations d'écriture, une erreur FAILED_PRECONDITION se produit.
Fonctionnalités non compatibles
Les buckets utilisant les fonctionnalités suivantes ne peuvent pas être relocalisé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 avec des préservations temporaires.
Buckets avec l'espace de noms hiérarchique activé.
Tags. Nous vous déconseillons d'ajouter des tags pendant une relocalisation, car cela peut entraîner l'échec du processus de déplacement.
Anywhere Cache. Bien qu'Anywhere Cache puisse être activé pendant le processus de relocalisation de bucket, ce service empêche l'étape de synchronisation finale de s'achever.
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.
Buckets Firebase. Vous ne pouvez pas déplacer les buckets associés à Firebase.
Restrictions opérationnelles
La relocalisation de bucket avec interruption des opérations d'écriture est soumise aux restrictions opérationnelles suivantes :
Restriction liée au projet : vous ne pouvez pas relocaliser 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 une relocalisation.
Augmentation progressive du taux de requêtes : les buckets relocalisés sont soumis aux mêmes consignes d'augmentation progressive du taux de requêtes que les buckets nouvellement créés.
Limites de la relocalisation sans interruption des opérations d'écriture
La relocalisation de bucket sans interruption des opérations d'écriture est soumise aux limites suivantes :
Règles de conservation : toutes les règles de conservation doivent être déverrouillées avant la relocalisation.
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 relocalisation n'est pas forcément linéaire.
Importations en plusieurs parties : seules les importations en plusieurs parties terminées sont prises en charge lors d'une relocalisation de bucket. Les importations en plusieurs parties en cours d'exécution ne sont pas acceptées pour les objets lors d'une relocalisation de bucket. Elles doivent être finalisées ou annulées avant la relocalisation du bucket. Vous devez réimporter les objets sans utiliser de méthode en plusieurs parties. Si vous tentez d'importer des objets via des importations en plusieurs parties lors d'une relocalisation de bucket, une erreur
FAILED_PRECONDITIONse produit.
Emplacements non acceptés
La relocalisation de bucket n'est pas possible pour les buckets source et de destination situés dans les emplacements suivants :
| Type d'emplacement | Emplacements non acceptés |
|---|---|
| Régions |
|
Tarification
Pour en savoir plus sur les tarifs associés à la relocalisation de bucket, consultez les tarifs de Cloud Storage.
Étapes suivantes
- Découvrez comment planifier la relocalisation d'un bucket.
- Découvrez comment relocaliser des buckets.