Reubicación de buckets

En este documento, se describe el servicio de reubicación de bucket de Cloud Storage que reubica buckets sin servidores entre ubicaciones geográficas. Con la reubicación de buckets, puedes mover un bucket existente de una ubicación a otra sin cambiar su nombre ni requerir la transferencia manual de datos dentro del bucket.

Según tus objetivos y el uso del bucket, deberás planificar cuidadosamente la reubicación del bucket para minimizar las interrupciones y reubicarlo correctamente. Para obtener más información sobre cómo cambiar la ubicación de los buckets, consulta Cómo cambiar la ubicación de los buckets.

Beneficios

Estos son los beneficios de la reubicación de bucket:

• Migración simplificada: Puedes cambiar la ubicación de los buckets con una sobrecarga operativa mínima. No se requieren procesos complejos de varios pasos ni secuencias de comandos.

• Operación continua: Tus aplicaciones siguen siendo accesibles durante todo el proceso de reubicación, sin tiempo de inactividad para las operaciones de lectura y con un tiempo de inactividad mínimo para las operaciones de escritura.

• Mejor rendimiento: Colocar los recursos de Compute Engine y Cloud Storage en la misma región puede reducir la latencia y mejorar el rendimiento.

• Conservación de metadatos: El proceso de reubicación del bucket conserva los metadatos del objeto. La conservación de los metadatos del objeto garantiza la compatibilidad con las aplicaciones y los flujos de trabajo existentes después de que se mueva el bucket.

• Configuraciones de la clase de almacenamiento: Puedes mantener la configuración existente de la clase de Cloud Storage, incluida la clase automática. Conservar la clase de almacenamiento garantiza que la estructura de costos siga siendo coherente después de la reubicación.

Casos de uso

Estos son algunos casos de uso que puedes lograr si reubicas tus buckets:

• Reduce el costo de transferencia de datos: Evita los costos de transferencia de datos reubicando tu bucket más cerca de las cargas de trabajo que acceden a los datos del bucket. Por ejemplo, si tus datos se almacenan en Estados Unidos y se accede a ellos principalmente desde Europa, puedes trasladar tu bucket a una ubicación europea para reducir los costos de transferencia de datos.

• Mejora el rendimiento: Aumenta la velocidad y la capacidad de respuesta de tu aplicación acercando tus datos a tus cargas de trabajo de Compute Engine. Por ejemplo, si tu aplicación se ejecuta en us-central1, pero tus datos residen en asia-east1, puedes reubicar tu bucket en us-central1 para reducir la latencia.

• Mejora la resiliencia: Protege tus datos críticos de las interrupciones regionales. Por ejemplo, si tus datos se almacenan en una sola región, puedes trasladarlos a una región doble o múltiple para aumentar la disponibilidad y la recuperación ante desastres.

Tipos de reubicación

Existen dos tipos de reubicaciones de bucket:

• Reubicación de buckets con tiempo de inactividad de escritura: En la reubicación de buckets con tiempo de inactividad de escritura, hay un período durante el cual no puedes realizar operaciones de escritura de objetos durante el proceso de reubicación del bucket.

• Reubicación de buckets sin tiempo de inactividad de escritura: En la reubicación de buckets sin tiempo de inactividad de escritura, puedes seguir realizando operaciones de escritura de objetos sin interrupciones mientras la reubicación del bucket se realiza en segundo plano.

Las ubicaciones de origen y destino del bucket determinan si la reubicación del bucket implica un tiempo de inactividad de escritura. En la siguiente tabla, se muestra cómo la ubicación de tu bucket afecta el tiempo de inactividad de escritura durante una reubicación, incluidas las diferencias entre las reubicaciones con y sin tiempo de inactividad.

Especificación	Reubicación de buckets con tiempo de inactividad de escritura	Reubicación de buckets sin tiempo de inactividad de escritura
Ubicación del bucket	La reubicación de un bucket entre las siguientes ubicaciones causa tiempo de inactividad: Regiones Regiones dobles Multirregiones Regiones múltiples y regiones dobles predefinidas Regiones múltiples y regiones dobles configurables si las dos ubicaciones tienen diferentes códigos de región múltiple	Si se reubica un bucket entre las siguientes ubicaciones, no se produce tiempo de inactividad si las dos ubicaciones comparten el mismo código de multirregión: Regiones dobles configurables Regiones múltiples y regiones dobles configurables
Disponibilidad de escritura	No puedes realizar operaciones de escritura durante el paso de sincronización final.	Las operaciones de escritura continúan sin interrupciones durante la reubicación. Nota: Los cambios en las políticas que no tienen tiempo de inactividad de escritura tardan al menos siete días en completarse porque deben esperar a que finalicen primero las cargas reanudables en curso.
Participación del usuario	Debes iniciar el paso de finalización del tiempo de inactividad de escritura.	No se requiere ningún paso de finalización explícito.
Impacto en el rendimiento	No puedes escribir ni actualizar objetos en el bucket durante el paso de sincronización final.	La latencia de lectura y escritura de objetos puede aumentar durante la reubicación.
Cancelación de la reubicación de buckets	Más rápido que las reubicaciones sin tiempo de inactividad de escritura.	La cancelación no es instantánea y puede tardar más debido a la necesidad de rellenar objetos.
Compatibilidad de características	Proporciona menos compatibilidad con funciones que las reubicaciones sin tiempo de inactividad por escritura. Para obtener más información sobre las funciones no compatibles, consulta Funciones no compatibles.	Existen limitaciones para funciones como las cargas de varias partes, las políticas de retención, Firebase y appspot. Para obtener más información sobre estas limitaciones, consulta Limitaciones.
Duración mínima de la reubicación	Ninguno	Siete días

Comprende el proceso de reubicación de bucket

La reubicación de buckets te ayuda a transferir tus datos de un bucket de origen a uno de destino. El bucket de origen contiene los datos que deseas mover, y el bucket de destino es donde deseas mover tus datos.

En el siguiente diagrama, se muestra el flujo del proceso de reubicación de bucket:

^* La sincronización final solo es necesaria para las reubicaciones con tiempo de inactividad de escritura.

En la siguiente tabla, se enumeran los tres pasos principales y la descripción de cada uno:

Paso	Descripción
Realiza una ejecución de prueba (opcional)	Simula el proceso de reubicación del bucket para identificar posibles problemas antes de que comience la transferencia de datos real.
Inicia el paso de copia de datos incremental	Copia datos del bucket de origen al bucket de destino. Los metadatos del bucket están bloqueados para escritura para evitar cualquier cambio en el bucket que pueda afectar el proceso de reubicación. Sin embargo, puedes escribir, modificar y borrar objetos en el bucket. Los factores que influyen en la duración son los siguientes: La frecuencia de las actualizaciones, eliminaciones o adiciones de objetos dentro del bucket afecta directamente la duración de la copia. Una mayor tasa de cambio requiere más tiempo. Hay una tasa máxima de movimiento de objetos `Rm, objetos/segundo`. Con `N` objetos totales y una tasa de actualización de `R objetos/segundo`, la duración del paso de copia se puede estimar como `N / (Rm - R)` segundos. Los buckets grandes requieren más tiempo de reubicación debido al ancho de banda finito. El tamaño de los objetos individuales afecta el tiempo de copia. Los objetos de más de 10 GB tardan más en transferirse que los objetos de menos de 10 GB debido a las limitaciones de ancho de banda. Por ejemplo, un objeto de 1 TB tarda un día en copiarse.
Inicia el paso de sincronización final (solo se requiere para las reubicaciones con tiempo de inactividad de escritura)	Una vez que inicies la sincronización final, el bucket se bloqueará para escritura. Como resultado, no puedes escribir ni actualizar ningún objeto dentro del bucket durante este tiempo, lo que evita incoherencias en los datos. Sin embargo, puedes seguir leyendo desde el bucket. Una vez que se hayan transferido y verificado todos los datos, y el bucket esté operativo en la nueva ubicación, se quitará automáticamente el bloqueo de escritura. Luego, puedes reanudar la escritura y actualización de objetos en el bucket.

Limitaciones

El servicio de reubicación de bucket admite hasta cinco reubicaciones simultáneas desde la misma ubicación dentro de un proyecto.

En las siguientes secciones, se describen las limitaciones que se aplican a las reubicaciones con tiempo de inactividad de escritura y sin tiempo de inactividad de escritura.

Reubicación con limitaciones de tiempo de inactividad de escritura

La reubicación con tiempo de inactividad de escritura tiene las limitaciones que se indican en las siguientes secciones.

Limitaciones en el manejo de datos

Estas son las limitaciones que se aplican al manejo de datos durante la reubicación:

• Falla de la tabla: Las tablas externas de BigLake y las tablas de BigQuery que usan Apache Iceberg fallarán y requerirán una recreación manual. La detección automática de las tablas afectadas no está disponible.

• Manejo de objetos de Autoclass: Autoclass usa patrones de acceso para determinar cuándo trasladar objetos a clases de almacenamiento más frías. Durante la sincronización final del proceso de reubicación del bucket, Autoclass se pausa y los objetos no se trasladan a clases de almacenamiento más en frío. Una vez que se completa la sincronización final, se reanuda Autoclass.

  • Los objetos de la clase de almacenamiento Standard se controlan de la siguiente manera:

    • Los objetos de la clase de almacenamiento Standard tienen un período de 30 días sin acceso antes de que puedan hacer la transición a una clase más fría, como Nearline Storage. Cuando se mueve un objeto de la clase de almacenamiento Standard durante la reubicación, se considera como si se hubiera accedido a él. Como resultado, el proceso de reubicación restablece el período sin acceso y, aunque un objeto estuviera cerca de hacer la transición a Nearline Storage antes de la mudanza, debe esperar otros 30 días después de que se complete la reubicación.

  • Los objetos en una clase de almacenamiento que no es estándar se controlan de la siguiente manera:

    • La reubicación de objetos en las clases de almacenamiento Nearline Storage, Coldline Storage o Archive Storage no se considera como acceso a ellos. Por lo tanto, no se ve afectado el período sin acceso para estos objetos.

    • Cuando reubicas un bucket, si accedes con frecuencia a objetos en buckets con una clase de almacenamiento que no sea Standard, como Nearline Storage, Coldline Storage o Archive Storage, el bucket no realiza la transición automáticamente a una clase de almacenamiento más cálida. Por ejemplo, el bucket no realiza la transición automáticamente de Archive Storage a Coldline Storage ni de Coldline Storage a Standard Storage, incluso si se accede a los objetos con frecuencia. Este comportamiento evita las transiciones automáticas de la clase de almacenamiento durante la reubicación.

    • Si se programó la transición de un objeto a una clase de almacenamiento más fría, como de Nearline Storage a Coldline Storage, el proceso de reubicación no interferirá en la programación. La transición se realiza según lo previsto después de que finaliza la reubicación.

• Límite de tamaño del objeto: Se aplica un límite de 2 TB a los tamaños de los objetos para la reubicación.

Cargas multiparte

Las cargas multiparte no se admiten para la reubicación de bucket con tiempo de inactividad de escritura, independientemente de su estado, ya sea que estén finalizadas, en curso o que se hayan iniciado durante la reubicación. Si tienes cargas multiparte completadas en el bucket que deseas reubicar, debes volver a subir los objetos sin usar métodos multiparte y borrar las cargas multiparte. De lo contrario, la reubicación fallará. Si subes objetos con cargas de varias partes durante la reubicación del bucket con tiempo de inactividad de escritura, se produce un error FAILED_PRECONDITION.

Características no compatibles

No se pueden reubicar los buckets que usan las siguientes funciones:

• Claves de encriptación administradas por el cliente (CMEK) o claves de encriptación proporcionadas por el cliente (CSEK)

• Políticas de retención bloqueadas

• Objetos con conservaciones temporales

• Buckets con el espacio de nombres jerárquico habilitado

• Etiquetas. No se recomienda agregar etiquetas durante la reubicación, ya que esto provoca que el proceso falle.

• Inhabilita Anywhere Cache. Si bien se puede habilitar Anywhere Cache durante el paso de copia de datos incremental, impide que se complete el paso de sincronización final.

• Son buckets de Appspot. Considera migrar Container Registry a Artifact Registry como solución alternativa para los buckets predeterminados que crea App Engine.

• Son los buckets de Firebase. No puedes cambiar la ubicación de los buckets asociados con Firebase.

Restricciones operativas

La reubicación de buckets con tiempo de inactividad de escritura tiene las siguientes restricciones operativas:

• Restricción del proyecto: No puedes cambiar la ubicación de los buckets entre proyectos.

• Cargas reanudables: Las cargas reanudables en curso deben finalizarse antes del paso de sincronización final para evitar la pérdida de datos.

• Actualizaciones de metadatos: No puedes actualizar los metadatos de un bucket durante la reubicación.

• Aumento gradual de la frecuencia de solicitudes: Los buckets reubicados están sujetos a los mismos lineamientos de aumento gradual de la frecuencia de solicitudes que los buckets creados recientemente.

Reubicación sin limitaciones de tiempo de inactividad de escritura

La reubicación de buckets sin tiempo de inactividad de escritura tiene las siguientes limitaciones:

• Políticas de retención: Todas las políticas de retención deben estar desbloqueadas antes de la reubicación.

• Buckets de Firebase y Appspot: No se admite la reubicación de buckets asociados con Firebase o Appspot.

• Actualizaciones de progreso: Es posible que las actualizaciones de progreso de la reubicación no sean lineales.

• Cargas multiparte: Solo se admiten las cargas multiparte completadas durante la reubicación del bucket. Las cargas de varias partes en curso no se admiten para los objetos durante la reubicación del bucket y deben completarse o cancelarse antes de la reubicación del bucket. Debes volver a subir los objetos sin usar métodos de carga multiparte. Si subes objetos con cargas multiparte durante la reubicación del bucket, se produce un error FAILED_PRECONDITION.

Ubicaciones no admitidas

No se admite la reubicación de buckets para los buckets de origen y destino en las siguientes ubicaciones:

Tipo de ubicación	Ubicaciones no admitidas
regiones	ME-CENTRAL1 ME-WEST1
Regiones dobles predefinidas	EUR5 EUR7 EUR8

Precios

Para obtener detalles sobre los precios asociados con la reubicación de bucket, consulta Precios de Cloud Storage.

¿Qué sigue?

• Obtén más información para planificar la reubicación de un bucket.
• Obtén más información para cambiar la ubicación de los buckets.