Reubicación de buckets

En esta página, se proporciona una descripción general de la reubicación de buckets, sus beneficios, casos de uso, cómo funciona y limitaciones.

Descripción general

La reubicación de buckets de Cloud Storage permite la migración sin servidores de buckets entre ubicaciones geográficas. Con la reubicación de buckets, puedes hacer lo siguiente:

  • Mover un bucket existente de una ubicación a otra sin cambiar su nombre ni requerir la transferencia manual de los datos dentro del bucket

  • Alinea la configuración de Cloud Storage de tu carga de trabajo con Compute Engine para mejorar el rendimiento y la rentabilidad.

Beneficios

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

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

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

  • Rendimiento mejorado: La colocalización de recursos de Compute Engine y Cloud Storage en la misma región puede reducir la latencia y mejorar el rendimiento.

  • Preservación de metadatos: El proceso de reubicación de buckets conserva los metadatos del objeto. La retención de los metadatos de los objetos garantiza la compatibilidad con las aplicaciones y los flujos de trabajo existentes después de mover el bucket.

  • Parámetros de configuración de la clase de almacenamiento: Puedes mantener la configuración existente de la clase de Cloud Storage, incluida Clase automática. Si conservas la clase de almacenamiento, te aseguras de que tu estructura de costos permanezca consistente después de la reubicación.

¿Por qué deberías usar la reubicación de bucket?

Estos son algunos de los casos de uso para reubicar tus buckets:

  • Reducir el costo de transferencia de datos: Si se accede a tus datos con frecuencia desde una ubicación lejos de donde se almacenan, puedes reubicar tu bucket a una ubicación cercana a la que se accede, lo que reducirá el costo de transferencia de datos. Por ejemplo, si se accede a tus datos principalmente desde Europa, pero se almacenan en Estados Unidos, puedes mover tu bucket a una ubicación de Europa para reducir los costos.

  • Mejora el rendimiento: Puedes mejorar la velocidad y la respuesta de tu aplicación si acercas los datos a 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: Puedes proteger tus datos críticos de las interrupciones regionales. Por ejemplo, si tus datos se almacenan en una sola región, puedes reubicarlos en ubicaciones dobles o multirregionales para aumentar la disponibilidad y la recuperación ante desastres.

Tipos de traslado

Si la reubicación de un bucket implica un tiempo de inactividad de escritura depende de las ubicaciones de origen y destino del bucket. Para obtener información sobre cómo la ubicación afecta el tipo de reubicación, consulta Determina el tipo de reubicación de tu bucket. Los dos tipos de reubicación de buckets son los siguientes:

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

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

En la siguiente tabla, se describen las diferencias importantes entre los tipos de reubicación con y sin tiempo de inactividad de escritura:

Especificación Reubicación de buckets con tiempo de inactividad de escritura Reubicación de buckets sin tiempo de inactividad de escritura
Disponibilidad de escritura No se pueden realizar operaciones de escritura durante el paso de sincronización final. No hay interrupciones en las operaciones de escritura.
Participación del usuario Requiere que el usuario inicie el paso de finalización del tiempo de inactividad de las operaciones de escritura. No se requiere un paso de finalización explícito.
Impacto en el rendimiento No se pueden escribir ni actualizar objetos dentro del bucket durante el paso de sincronización final. Posibilidad de aumentar la latencia de lectura y escritura de objetos durante la reubicación
Cancelación de la reubicación de buckets Más rápido que los traslados sin tiempo de inactividad de escritura. La cancelación no es instantánea. Puede tardar más debido a la necesidad de reabastecer los objetos.
Compatibilidad de características Hay menos compatibilidad con funciones disponibles que los traslados sin tiempo de inactividad de escritura. Limitaciones en 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.

Determina el tipo de reubicación de tu bucket

Las ubicaciones de los buckets de origen y destino determinan el tipo de reubicación.

Cuando trasladas un bucket entre regiones, regiones dobles o multirregiones, experimentas un tiempo de inactividad en el que no puedes escribir en el bucket. Sin embargo, puedes reubicar un bucket sin tiempo de inactividad en los siguientes casos:

  • Reubica una multirregión a una región doble configurable si ambas ubicaciones comparten el mismo código multirregional.

  • Vuelve a ubicar entre regiones dobles configurables si ambas ubicaciones comparten el mismo código multirregional.

  • Reubicar de una región doble configurable a una multirregión si ambas ubicaciones comparten el mismo código multirregional

Comprende el proceso de reubicación de buckets

La reubicación de buckets te ayuda a mover tus datos de un bucket de origen a un bucket de destino. El bucket de origen contiene los datos que quieres mover, y el bucket de destino es el lugar al que quieres mover tus datos.

En el siguiente diagrama, se muestra el flujo del proceso de reubicación de buckets.

Flujo del proceso de reubicación de buckets.
Figura 1. Flujo del proceso de reubicación de bucket (haz clic para ampliar).

Los pasos numerados se refieren a los números en el diagrama. En el diagrama, se muestran los siguientes pasos:

  1. Copia de datos incremental: El paso de copia de datos incremental copia los datos del bucket de origen al bucket de destino. Los metadatos del bucket están bloqueados para escritura para evitar cambios en el bucket que puedan 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, las eliminaciones o las adiciones de objetos dentro del bucket afecta directamente la duración de la copia. Una tasa de cambio más alta requiere más tiempo. Hay una velocidad máxima de movimiento de objetos Rm, objects/second. Con N objetos en total y una tasa de actualización de R objects/second, la duración del paso de copia se puede estimar en 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 de menos de 10 GB debido a las restricciones de ancho de banda. Por ejemplo, un objeto de 1 TB tarda un día en copiarse. Te recomendamos que dividas los objetos grandes en objetos más pequeños de 0.1 a 1 GB.

    Para obtener más información sobre cómo iniciar la copia de datos incremental, consulta Cómo iniciar el paso de copia de datos incremental.

  2. Supervisa la copia de datos incremental: Para ver el estado del paso de copia de datos incremental, puedes revisar con frecuencia la lista de operaciones de larga duración. Para obtener información sobre cómo verificar el estado del paso de copia de datos incremental, consulta Supervisa el paso de copia de datos incremental.

  3. Sincronización final: En el caso de las reubicaciones con tiempo de inactividad de escritura, una vez que se complete la copia de datos incremental, deberás activar el paso de sincronización final. El último paso de sincronización incluye un período en el que no puedes escribir en el bucket para garantizar la coherencia de los datos. El paso de sincronización final incluye las siguientes acciones:

    1. El bucket tiene un bloqueo de escritura temporal. Como resultado, no puedes escribir ni actualizar ningún objeto dentro del bucket durante este tiempo, lo que evita inconsistencias en los datos.

    2. Cualquier cambio que se realice en los datos del objeto dentro de un bucket desde el paso de copia incremental se copia en el bucket de destino, lo que garantiza que el bucket reubicado tenga los datos más actualizados. Una vez que finaliza la copia de objetos, se realiza una comparación para garantizar la paridad de los datos entre los buckets de origen y de destino. Después de la comparación de datos, se actualiza la ubicación del bucket y todas las solicitudes se redireccionan a la ubicación nueva.

    3. Una vez que se hayan transferido y verificado todos los datos, y el bucket esté en funcionamiento en la ubicación nueva, se quitará el bloqueo de escritura. Luego, puedes reanudar la escritura y actualización de objetos en el bucket.

    Para obtener información sobre cómo iniciar el paso de sincronización final, consulta Cómo iniciar el paso de sincronización final.

Limitaciones

El servicio de reubicación de buckets 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 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 de manejo de datos

Las siguientes son las limitaciones para el manejo de datos durante la reubicación:

  • Fractura de tablas: Las tablas externas de BigLake y las tablas de BigQuery que usan Apache Iceberg se romperá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 transfieren a clases de almacenamiento más en frío. Una vez que se completa la sincronización final, se reanuda Autoclass.

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

      • Los objetos de la clase de almacenamiento estándar tienen un período de 30 días sin acceso antes de que se pueda realizar la transición a una clase más fría, como Nearline Storage. Cuando se mueve un objeto de la clase de almacenamiento estándar durante la reubicación, se trata 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 a punto de realizar la transición a Nearline Storage antes del traslado, deberá esperar otros 30 días después de que se complete la reubicación.

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

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

      • Si lees o escribes un objeto en un bucket de clase de almacenamiento no estándar durante la reubicación, no se actualizará automáticamente a una clase más reciente, como Standard Storage, lo que ayuda a evitar transiciones de clase de almacenamiento innecesarias durante el proceso de reubicación.

      • Si se programó que un objeto se cambie a una clase de almacenamiento más fría, por ejemplo, de Nearline Storage a Coldline Storage, el proceso de reubicación no interferirá en la programación. La baja de categoría se realizará según lo planificado después de que se complete la reubicación.

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

Características no compatibles

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

Restricciones operativas

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

  • Restricción del proyecto: No puedes reubicar 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 tasa de solicitudes: Los buckets reubicados están sujetos a los mismos lineamientos de aumento gradual de la tasa 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:

  • Cargas multiparte: No se admiten cargas multiparte sin terminar y se deben completar o abortar antes de la reubicación. Las cargas multiparte nuevas se bloquean durante el traslado.
  • 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: La reubicación no es compatible con los buckets asociados con Firebase o Appspot.
  • Actualizaciones de progreso: Es posible que las actualizaciones del progreso de la reubicación no sean lineales.

Región no compatible

La reubicación de buckets no está disponible en la región me-central1 para los buckets de origen o destino.

¿Qué sigue?