Traslado de segmentos (original) (raw)

En este documento se describe cómo te ayuda la reubicación de segmentos de Cloud Storage a reubicar segmentos sin servidor entre ubicaciones geográficas. Con el cambio de ubicación de segmentos, puede mover un segmento de una ubicación a otra sin cambiar su nombre ni tener que transferir manualmente los datos que contiene.

Antes de iniciar el proceso de cambio de ubicación, planifica el cambio de ubicación de los contenedores para minimizar las interrupciones. Para obtener instrucciones sobre cómo realizar la reubicación, consulta Reubicar cubos.

Ventajas

Estas son las ventajas de cambiar la ubicación de un contenedor:

Migración simplificada: puede cambiar la ubicación de los contenedores con una sobrecarga operativa mínima. No se necesitan secuencias de comandos complejas ni procesos de varios pasos.
Funcionamiento continuo: tus aplicaciones siguen accesibles durante todo el proceso de cambio de ubicación, sin tiempo de inactividad para las operaciones de lectura y con un tiempo de inactividad mínimo para las operaciones de escritura.
Mejora del rendimiento: si colocas los recursos de Compute Engine y Cloud Storage en la misma región, puedes reducir la latencia y mejorar el rendimiento.
Conservación de metadatos: el proceso de cambio de ubicación del segmento conserva los metadatos del objeto. Al conservar los metadatos del objeto, se mantiene la compatibilidad con las aplicaciones y los flujos de trabajo existentes después de mover el contenedor.
Configuraciones de clases de almacenamiento: puedes mantener los ajustes de clase de Cloud Storage, incluido Autoclass. Si conserva la clase de almacenamiento, la estructura de costes se mantendrá constante después de la migración.

Casos prácticos

Estos son algunos casos prácticos que puedes conseguir si cambias la ubicación de tus contenedores:

Reduce los costes de transferencia de datos: evita los costes de transferencia de datos trasladando tu cubo a una ubicación más cercana a las cargas de trabajo que acceden a los datos del cubo. Por ejemplo, si tus datos se almacenan en Estados Unidos y se accede a ellos principalmente desde Europa, puedes mover tu segmento a una ubicación europea para reducir los costes de transferencia de datos.
Mejorar el rendimiento: aumenta la velocidad y la capacidad de respuesta de tu aplicación moviendo los datos a una ubicación más cercana a tus cargas de trabajo de Compute Engine. Por ejemplo, si tu aplicación se ejecuta en us-central1, pero tus datos se encuentran en asia-east1, puedes trasladar tu contenedor a us-central1 para reducir la latencia.
Mejora la resiliencia: protege tus datos críticos frente a las interrupciones regionales. Por ejemplo, si tus datos se almacenan en una sola región, puedes trasladarlos a una región dual o multirregional para aumentar la disponibilidad y la recuperación tras desastres.

Tipos de reubicación

Hay dos tipos de reubicaciones de contenedores:

Reubicación de segmentos con tiempo de inactividad de escritura: en la reubicación de segmentos con tiempo de inactividad de escritura, hay un periodo durante el cual no puedes realizar operaciones de escritura de objetos durante el proceso de reubicación de segmentos.
Cambio de ubicación de un cubo sin tiempo de inactividad de escritura: en el cambio de ubicación de un cubo sin tiempo de inactividad de escritura, puedes seguir realizando operaciones de escritura de objetos sin interrupciones mientras el cambio de ubicación del cubo se produce en segundo plano.

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

Especificaciones	Cambio de ubicación de un bucket con tiempo de inactividad de escritura	Cambio de ubicación de un contenedor sin tiempo de inactividad de escritura
Ubicación del segmento	Si trasladas un contenedor entre las siguientes ubicaciones, se producirá un tiempo de inactividad: RegionesDos regionesMultirregionesMultirregiones y regiones duales predefinidasMultirregiones y birregiones configurables si las dos ubicaciones tienen códigos de multirregión diferentes	Si trasladas un contenedor entre las siguientes ubicaciones, no se producirá ningún tiempo de inactividad si las dos ubicaciones comparten el mismo código multirregional: Regiones duales configurablesMultirregiones y birregiones configurables
Escribir disponibilidad	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 implican tiempo de inactividad de escritura tardan al menos siete días en completarse, ya que deben esperar a que finalicen las subidas reanudables en curso.
Participación de los usuarios	Debes iniciar el paso de finalización del tiempo de inactividad de escritura.	No es necesario realizar ningún paso de finalización explícito.
Impacto en el rendimiento	No puedes escribir ni actualizar objetos en el cubo durante el paso de sincronización final.	La latencia de lectura y escritura de los objetos puede aumentar durante la reubicación.
Cancelación de la reubicación de un segmento	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 tiempo debido a la necesidad de rellenar los objetos.
Funciones admitidas	Ofrece menos funciones que las reubicaciones sin tiempo de inactividad de escritura. Para obtener más información sobre las funciones no admitidas, consulta Funciones no admitidas.	Hay limitaciones en funciones como subidas multiparte, políticas de conservació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

Información sobre el proceso de cambio de ubicación de un contenedor

La reubicación de segmentos te ayuda a mover tus datos de un segmento de origen a un segmento de destino. El segmento de origen contiene los datos que quieres mover y el segmento de destino es donde quieres mover los datos.

En el siguiente diagrama se muestra el flujo del proceso de reubicación de un contenedor:

Imagen 1. Flujo del proceso de cambio de ubicación de un contenedor (haz clic para ampliar).

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

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

Paso	Descripción
Realizar una prueba de funcionamiento(opcional)	Simula el proceso de cambio de ubicación del contenedor para identificar posibles problemas antes de que empiece la transferencia de datos.
Inicia el paso de la reubicación	Copia los datos del segmento de origen en el segmento de destino. Los metadatos del segmento están protegidos contra escritura para evitar que se hagan cambios en el segmento que puedan afectar al proceso de reubicación. Sin embargo, puedes escribir, modificar y eliminar objetos en el segmento. Los factores que influyen en la duración son los siguientes: La frecuencia de las actualizaciones, eliminaciones o adiciones de objetos en el segmento influye directamente en 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, objetos/segundo`. Con `N` objetos en total y una velocidad 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 al 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 es necesario para las reubicaciones con tiempo de inactividad de escritura)	Una vez que inicies la sincronización final, el contenedor se bloqueará para escritura. Por lo tanto, no podrás escribir ni actualizar ningún objeto del segmento durante ese tiempo, lo que evitará incoherencias en los datos. Sin embargo, puedes seguir leyendo del contenedor.Una vez que se hayan transferido y verificado todos los datos, y el segmento esté operativo en la nueva ubicación, el bloqueo de escritura se eliminará automáticamente. Después, puedes reanudar la escritura y la actualización de objetos en el segmento.

Limitaciones

El servicio de cambio de ubicación de segmentos admite hasta cinco cambios de ubicación simultáneos desde la misma ubicación en 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 la gestión de datos

Estas son las limitaciones que se aplican al tratar los datos durante la reubicación:

Ruptura de tablas: las tablas externas de BigLake y las tablas de BigQuery que usen Apache Iceberg se romperán y requerirán una recreación manual. La detección automática de las tablas afectadas no está disponible.
Gestión de objetos de Autoclass: Autoclass usa patrones de acceso para determinar cuándo transferir objetos a clases de almacenamiento más frías. Durante la sincronización final del proceso de cambio de ubicación del segmento, Autoclass se pausa y los objetos no se migran a clases de almacenamiento más frías. Una vez que se haya completado la sincronización final, Autoclass se reanudará.
- Los objetos de la clase de almacenamiento Standard se gestionan de la siguiente manera:
  * Los objetos de la clase de almacenamiento Estándar tienen un periodo de 30 días sin acceso antes de poder migrarse 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. Por lo tanto, el proceso de traslado restablece el periodo sin acceso y, aunque un objeto estuviera a punto de pasar a Nearline Storage antes del traslado, tendrá que esperar otros 30 días después de que se complete el traslado.
- Los objetos de una clase de almacenamiento que no sea Standard se gestionan de la siguiente manera:
  * Reubicar objetos en las clases de almacenamiento Nearline, Coldline o Archive no se considera acceso. Por lo tanto, el periodo sin acceso de estos objetos no se ve afectado.
  * Cuando se cambia la ubicación de un segmento, si accedes con frecuencia a objetos de segmentos con una clase de almacenamiento que no sea Estándar, como Nearline, Coldline o Archive, el segmento no cambia automáticamente a una clase de almacenamiento más activa. Por ejemplo, el segmento no pasa automáticamente de Archive Storage a Coldline Storage ni de Coldline Storage a Standard Storage, aunque se acceda a los objetos con frecuencia. Este comportamiento evita las migraciones automáticas a clases de almacenamiento durante la reubicación.
  * Si se ha programado 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á con la programación. La transición se lleva a cabo según lo previsto una vez finalizado el traslado.
Límite de tamaño de los objetos: se aplica un límite de 2 TB al tamaño de los objetos que se van a reubicar.

Subidas multiparte

Las subidas multiparte no se admiten en la reubicación de cubos con tiempo de inactividad de escritura, independientemente de su estado (finalizadas, en curso o iniciadas durante la reubicación). Si has completado subidas multiparte en el cubo que quieres cambiar de ubicación, debes volver a subir los objetos sin usar métodos multiparte y eliminar las subidas multiparte. De lo contrario, el cambio de ubicación fallará. Si subes objetos mediante subidas multiparte durante la reubicación de un contenedor con tiempo de inactividad de escritura, se produce un error FAILED_PRECONDITION.

Funciones no compatibles

Los contenedores que usan las siguientes funciones no se pueden cambiar de ubicación:

Claves de encriptado gestionadas por el cliente (CMEK) o claves de encriptado proporcionadas por el cliente (CSEK).
Políticas de retención bloqueadas.
Objetos con retenciones temporales.
Segmentos con el espacio de nombres jerárquico habilitado.
Etiquetas No se recomienda añadir etiquetas durante la reubicación, ya que esto provoca que el proceso falle.
Almacenamiento en caché en cualquier lugar. Aunque se puede habilitar Anywhere Cache durante el proceso de cambio de ubicación del contenedor, impide que se complete el paso de sincronización final.
Segmentos de Appspot. Puedes migrar Container Registry a Artifact Registry como solución alternativa para los segmentos predeterminados creados por App Engine.
Contenedores de Firebase. No puedes cambiar la ubicación de los contenedores asociados a Firebase.

Restricciones operativas

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

Restricción de proyectos: no puedes cambiar la ubicación de los contenedores entre proyectos.
Subidas reanudables: las subidas 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 segmento durante la reubicación.
Aumento gradual de la frecuencia de solicitudes: los contenedores reubicados están sujetos a las mismas directrices de aumento gradual de la frecuencia de solicitudes que los contenedores recién creados.

Reubicación sin limitaciones de tiempo de inactividad de escritura

El cambio de ubicación de un bucket sin tiempo de inactividad de escritura tiene las siguientes limitaciones:

Políticas de retención: todas las políticas de retención deben desbloquearse antes de la reubicación.
Contenedores de Firebase y Appspot: no se admite la reubicación de contenedores asociados a Firebase o Appspot.
Actualizaciones del progreso: es posible que las actualizaciones del progreso de la reubicación no sean lineales.
Subidas multiparte: solo se admiten las subidas multiparte completadas durante la reubicación de un contenedor. No se admiten subidas multiparte en curso para objetos durante la reubicación de un contenedor. Estas subidas deben completarse o cancelarse antes de la reubicación del contenedor. Debe volver a subir los objetos sin usar métodos multiparte. Si subes objetos mediante subidas multiparte durante la reubicación de un segmento, se produce un error FAILED_PRECONDITION.

Ubicaciones no admitidas

No se puede cambiar la ubicación de los siguientes tipos de cubos de origen y de destino:

Tipo de ubicación	Ubicaciones no admitidas
Regiones y territorios	ME-CENTRAL1ME-WEST1

Precios

Para obtener información sobre los precios asociados a la reubicación de segmentos, consulta la página Precios de Cloud Storage.

Siguientes pasos

Consulta cómo planificar el cambio de ubicación de un contenedor.
Consulta cómo cambiar la ubicación de los contenedores.