Migrar entre regiones de Google Cloud: preparar los datos y las cargas de trabajo por lotes para la migración entre regiones

Last reviewed 2024-12-02 UTC

En este documento se describe cómo diseñar una plataforma de datos en Google Cloud para minimizar el impacto de una futura ampliación a otras regiones o de una migración de una región a otra. Este documento forma parte de una serie que te ayuda a comprender el impacto de ampliar tu plataforma de datos a otra región. Te ayuda a aprender a hacer lo siguiente:

  • Prepárate para mover datos y flujos de datos.
  • Configura comprobaciones durante las fases de migración.
  • Crea una estrategia de migración flexible separando el almacenamiento y el cálculo de datos.

Las directrices de esta serie también son útiles si no has planificado una migración entre regiones o una expansión a varias regiones con antelación. En este caso, puede que tengas que dedicar más tiempo a preparar tu infraestructura, cargas de trabajo y datos para la migración entre regiones y para la expansión a varias regiones.

Este documento forma parte de una serie:

En esta serie se da por hecho que has leído y conoces los siguientes documentos:

En el siguiente diagrama se muestra el recorrido de tu migración.

Ruta de migración con cuatro fases.

En cada paso de la migración, debes seguir las fases definidas en el artículo Migración a Google Cloud: primeros pasos:

  1. Evalúa e identifica tus cargas de trabajo.
  2. Planifica y crea una base.
  3. Despliega tus cargas de trabajo.
  4. Optimiza tu entorno.

La plataforma de datos moderna en Google Cloud

En esta sección se describen las diferentes partes de una plataforma de datos moderna y cómo se suelen construir en Google Cloud. Las plataformas de datos, como concepto general, se pueden dividir en dos secciones:

  • La capa de almacenamiento de datos es donde se guardan los datos. Los datos que guardas pueden estar en forma de archivos en los que gestionas bytes reales en un sistema de archivos como el sistema de archivos distribuidos de Hadoop (HDFS) o Cloud Storage, o bien puedes usar un lenguaje específico de dominio (DSL) para gestionar los datos en un sistema de gestión de bases de datos.
  • La capa de computación de datos es cualquier procesamiento de datos que puedas activar sobre el sistema de almacenamiento. Al igual que con la capa de almacenamiento, hay muchas implementaciones posibles y algunas herramientas de almacenamiento de datos también se encargan del cálculo de datos. La función de la capa de cálculo de datos en la plataforma es cargar datos de la capa de almacenamiento, procesarlos y, a continuación, guardar los resultados en un sistema de destino. El sistema de destino puede ser la capa de almacenamiento de origen.

Algunas plataformas de datos usan varios sistemas de almacenamiento para su capa de almacenamiento de datos y varios sistemas de computación de datos para su capa de tratamiento de datos. En la mayoría de los casos, la capa de almacenamiento de datos y la capa de cálculo de datos están separadas. Por ejemplo, puede que hayas implementado tu capa de almacenamiento de datos con estosGoogle Cloud servicios:

Es posible que hayas implementado la capa de cálculo de datos con otros Google Cloud servicios como los siguientes:

Para reducir el tiempo y la latencia de la comunicación, el coste de la transferencia de datos saliente y el número de operaciones de E/S entre la capa de almacenamiento y la capa de cálculo, le recomendamos que almacene los datos en la misma zona en la que los procese.

También te recomendamos que mantengas la capa de almacenamiento de datos separada de la capa de cálculo de datos. Si mantienes estas capas separadas, tendrás más flexibilidad para cambiar las capas de cálculo y migrar datos. Si mantienes las capas separadas, también se reduce el uso de recursos, ya que no tienes que mantener la capa de cálculo en funcionamiento todo el tiempo. Por lo tanto, te recomendamos que implementes el almacenamiento y el cálculo de datos en plataformas independientes de la misma zona y región. Por ejemplo, puedes mover tu almacenamiento de datos de HDFS a Cloud Storage y usar un clúster de Dataproc para los cálculos.

Evalúa tu entorno

En la fase de evaluación, determina los requisitos y las dependencias para migrar los flujos de procesamiento de datos por lotes que has implementado:

  1. Crea un inventario completo de tus flujos de procesamiento de datos.
  2. Cataloga tus pipelines según sus propiedades y dependencias.
  3. Forma y educa a tus equipos sobre Google Cloud.
  4. Crea un experimento y una prueba de concepto en Google Cloud.
  5. Calcula el coste total de propiedad (CTP) del entorno de destino.
  6. Elige las cargas de trabajo que quieras migrar primero.

Para obtener más información sobre la fase de evaluación y estas tareas, consulta el artículo Migración a Google Cloud: evaluar e identificar cargas de trabajo. Las siguientes secciones se basan en la información de ese documento.

Crear inventarios

Para definir el alcance de la migración, debes conocer el entorno de la plataforma de datos en la que se han implementado tus flujos de procesamiento de datos:

  1. Crea un inventario de tu infraestructura de datos: las diferentes capas de almacenamiento y las diferentes capas de computación que utilizas para el almacenamiento de datos y el procesamiento de datos por lotes.
  2. Crea un inventario de las canalizaciones de datos que se van a migrar.
  3. Crea un inventario de los conjuntos de datos que leen las pipelines de datos y que deben migrarse.

Para crear un inventario de su plataforma de datos, tenga en cuenta lo siguiente para cada parte de la infraestructura de datos:

  • Capas de almacenamiento. Además de las plataformas de almacenamiento estándar, como Cloud Storage, considera otras capas de almacenamiento, como bases de datos (Firebase, BigQuery, Bigtable y PostgreSQL) u otros clústeres (Apache Kafka). Cada plataforma de almacenamiento tiene su propia estrategia y método para completar la migración. Por ejemplo, Cloud Storage tiene servicios de migración de datos y una base de datos puede tener una herramienta de migración integrada. Asegúrate de que cada producto que utilices para almacenar datos esté disponible en tu entorno de destino o de que tengas un sustituto compatible. Practica y verifica el proceso de transferencia de datos técnicos para cada una de las plataformas de almacenamiento implicadas.
  • Capas de cálculo. En cada plataforma de computación, comprueba el plan de implementación y los cambios de configuración que hayas hecho en las diferentes plataformas.
  • Latencia de la red: Prueba y verifica la latencia de la red entre el entorno de origen y el de destino. Es importante que sepas cuánto tiempo tardarán en copiarse los datos. También debes probar la latencia de la red desde los clientes y los entornos externos (como un entorno local) hasta el entorno de destino en comparación con el entorno de origen.

  • Configuraciones e implementación. Cada producto de infraestructura de datos tiene sus propios métodos de configuración. Haz un inventario de las configuraciones personalizadas que has realizado para cada componente y de los componentes de los que estás usando las versiones predeterminadas para cada plataforma (por ejemplo, qué versión de Dataproc o de Apache Kafka estás usando). Asegúrate de que esas configuraciones se puedan implementar como parte de tu proceso de implementación automatizado.

    Debes saber cómo se configura cada componente, ya que los motores de cálculo pueden comportarse de forma diferente si se configuran de forma distinta, sobre todo si el framework de la capa de procesamiento cambia durante la migración. Por ejemplo, si el entorno de destino ejecuta una versión diferente de Apache Spark, es posible que algunas configuraciones del framework de Spark hayan cambiado entre versiones. Este tipo de cambio de configuración puede provocar cambios en las salidas, las serializaciones y los cálculos.

    Durante la migración, te recomendamos que utilices implementaciones automatizadas para asegurarte de que las versiones y las configuraciones sigan siendo las mismas. Si no puedes mantener las versiones y las configuraciones iguales, asegúrate de hacer pruebas que validen los resultados de datos que calcula el framework.

  • Tamaños de los clústeres. En el caso de los clústeres autogestionados, como un clúster de Dataproc de larga duración o un clúster de Apache Kafka que se ejecuta en Compute Engine, anota el número de nodos y CPUs, así como la memoria de cada nodo de los clústeres. Si migras a otra región, es posible que cambie el procesador que usa tu implementación. Por lo tanto, te recomendamos que analices y optimices tus cargas de trabajo después de implementar la infraestructura migrada en producción. Si un componente está totalmente gestionado o no tiene servidor (por ejemplo, Dataflow), el tamaño formará parte de cada trabajo individual y no del clúster en sí.

Los siguientes elementos que evalúe en su inventario se centran en las canalizaciones de datos:

  • Fuentes y receptores de datos. Asegúrate de tener en cuenta las fuentes y los receptores que usa cada canalización de datos para leer y escribir datos.
  • Acuerdos de nivel de servicio (SLAs) y objetivos de nivel de servicio (SLOs). Los acuerdos de nivel de servicio y los objetivos de nivel de servicio de las canalizaciones de datos por lotes suelen medirse en tiempo de finalización, pero también se pueden medir de otras formas, como la potencia de cálculo utilizada. Estos metadatos empresariales son importantes para impulsar los procesos del plan de continuidad de la actividad y recuperación tras desastres (BCDR), como la conmutación por error de un subconjunto de tus pipelines más importantes a otra región en caso de que se produzca un fallo zonal o regional.
  • Dependencias de los flujos de procesamiento de datos Algunos flujos de procesamiento de datos dependen de datos que genera otro flujo de procesamiento de datos. Cuando dividas los flujos de procesamiento en sprints de migración, ten en cuenta las dependencias de los datos.
  • Conjuntos de datos generados y utilizados. En cada una de las canalizaciones de datos, identifique los conjuntos de datos que consume y los que genera. De esta forma, podrás identificar las dependencias entre las canalizaciones y entre otros sistemas o componentes de tu arquitectura general.

Los siguientes elementos que evalúa en su inventario se centran en los conjuntos de datos que se van a migrar:

  • Conjuntos de datos. Identifica los conjuntos de datos que deben migrarse al entorno de destino. Puede que consideres que algunos datos históricos no son necesarios para la migración o que se deben migrar en otro momento si los datos están archivados y no se usan de forma activa. Si defines el ámbito del proceso de migración y las fases de la migración, puedes reducir los riesgos que implica el proceso.
  • Tamaños de los datos. Si tienes previsto comprimir los archivos antes de transferirlos, anota el tamaño de los archivos antes y después de la compresión. El tamaño de tus datos afectará al tiempo y al coste necesarios para copiar los datos de la fuente al destino. Tener en cuenta estos factores te ayudará a elegir entre las estrategias de tiempo de inactividad, tal como se describe más adelante en este documento.
  • Estructura de datos. Clasifica cada conjunto de datos que se va a migrar y asegúrate de que sabes si los datos son estructurados, semiestructurados o no estructurados. Conocer la estructura de los datos puede ayudarte a definir una estrategia para verificar que los datos se migran correctamente y por completo.

Completa la evaluación

Una vez que hayas creado los inventarios relacionados con tus clústeres y cargas de trabajo de Kubernetes, completa el resto de las actividades de la fase de evaluación en Migración a Google Cloud: evalúa y descubre tus cargas de trabajo.

Planifica y construye tu base

La fase de planificación y creación de la migración a Google Cloud consta de las siguientes tareas:

  1. Crea una jerarquía de recursos.
  2. Configura la gestión de identidades y accesos (IAM).
  3. Configura la facturación
  4. Configura la conectividad de red.
  5. Refuerza tu seguridad.
  6. Configura el almacenamiento de registros, la monitorización y las alertas.

Para obtener más información sobre cada una de estas tareas, consulta el artículo Migrar a Google Cloud: planificar y crear la base.

Migrar datos y flujos de datos

En las siguientes secciones se describen algunos aspectos del plan de migración de las canalizaciones de datos y de datos por lotes. Define algunos conceptos sobre las características de los flujos de datos que son importantes para entender cómo crear el plan de migración. También se tratan algunos conceptos de pruebas de datos que pueden ayudarte a tener más confianza en la migración de datos.

Plan de migración

En tu plan de migración, debes incluir el tiempo necesario para completar la transferencia de datos. En tu plan debes tener en cuenta la latencia de la red, el tiempo necesario para comprobar que los datos están completos y obtener los datos que no se hayan migrado, así como los costes de red. Como los datos se copiarán de una región a otra, tu plan de costes de red debe incluir los costes de red interregionales.

Te recomendamos que dividas los diferentes flujos de procesamiento y conjuntos de datos en sprints y los migres por separado. Este enfoque ayuda a reducir los riesgos de cada sprint de migración y permite introducir mejoras en cada uno de ellos. Para mejorar tu estrategia de migración y detectar problemas con antelación, te recomendamos que priorices las cargas de trabajo más pequeñas y no críticas antes de migrar las más grandes y críticas.

Otra parte importante de un plan de migración es describir la estrategia, las dependencias y la naturaleza de las diferentes canalizaciones de datos de la capa de computación. Si las capas de almacenamiento y de cálculo de datos se han creado en el mismo sistema, te recomendamos que monitorices el rendimiento del sistema mientras se copian los datos. Normalmente, la copia de grandes cantidades de datos puede provocar una sobrecarga de E/S en el sistema y reducir el rendimiento en la capa de computación. Por ejemplo, si ejecutas una carga de trabajo para extraer datos de un clúster de Kafka por lotes, las operaciones de E/S adicionales para leer grandes cantidades de datos pueden provocar una degradación del rendimiento en cualquier canalización de datos activa que siga ejecutándose en el entorno de origen. En ese caso, deberías monitorizar el rendimiento del sistema mediante métricas integradas o personalizadas. Para evitar que el sistema se vea sobrecargado, te recomendamos que tengas un plan para retirar algunas cargas de trabajo durante el proceso de copia de datos o para reducir la velocidad de la fase de copia.

Como la copia de datos hace que la migración sea un proceso largo, te recomendamos que tengas planes de contingencia para solucionar cualquier problema que pueda surgir durante la migración. Por ejemplo, si el movimiento de datos tarda más de lo previsto o si las pruebas de integridad fallan antes de poner en marcha el nuevo sistema, plantéate si quieres revertir los cambios o intentar corregir y volver a probar las operaciones fallidas. Aunque una reversión puede ser una solución más limpia, copiar grandes conjuntos de datos varias veces puede llevar mucho tiempo y ser caro. Te recomendamos que tengas claros los pasos que debes seguir y que definas pruebas para determinar qué acción debes llevar a cabo en cada situación, cuánto tiempo debes esperar para intentar crear parches y cuándo debes realizar una reversión completa.

Es importante distinguir entre las herramientas y las secuencias de comandos que usas para la migración y los datos que copias. Si revierte el movimiento de datos, tendrá que volver a copiar los datos y sobrescribir o eliminar los datos que ya haya copiado. Revertir los cambios en las herramientas y las secuencias de comandos puede ser más fácil y menos costoso, pero los cambios en las herramientas pueden obligarte a volver a copiar los datos. Por ejemplo, puede que tengas que volver a copiar los datos si creas una ruta de destino en una secuencia de comandos que genere una ubicación de Cloud Storage de forma dinámica. Para evitar que se vuelvan a copiar los datos, crea tus secuencias de comandos de forma que permitan la reanudación y la idempotencia.

Características de los flujos de procesamiento de datos

Para crear un plan de migración óptimo, debes conocer las características de las diferentes canalizaciones de datos. Es importante recordar que las canalizaciones por lotes que escriben datos son diferentes de las que leen datos:

  • Pipelines de datos que escriben datos: como cambia el estado del sistema de origen, puede ser difícil escribir datos en el entorno de origen al mismo tiempo que se copian datos en el entorno de destino. Ten en cuenta los tiempos de ejecución de las canalizaciones que escriben datos e intenta priorizar su migración en una fase anterior del proceso general. De esta forma, tendrás los datos listos en el entorno de destino antes de migrar las canalizaciones que leen los datos.
  • Flujos de procesamiento de datos que leen datos: los flujos de procesamiento de datos que leen datos pueden tener requisitos diferentes en cuanto a la actualización de datos. Si las canalizaciones que generan datos se detienen en el sistema de origen, las canalizaciones que leen datos podrán ejecutarse mientras se copian los datos en el entorno de destino.

Los datos son un estado y copiar datos entre regiones no es una operación atómica. Por lo tanto, debes tener en cuenta los cambios de estado mientras se copian los datos.

También es importante diferenciar los sistemas en el plan de migración. Es posible que tus sistemas tengan requisitos funcionales y no funcionales diferentes (por ejemplo, un sistema para lotes y otro para streaming). Por lo tanto, tu plan debe incluir diferentes estrategias para migrar cada sistema. Asegúrate de especificar las dependencias entre los sistemas y cómo reducirás el tiempo de inactividad de cada sistema durante cada fase de la migración.

Un plan típico para un sprint de migración debe incluir lo siguiente:

  • Estrategia general. Describe la estrategia para gestionar la migración en este sprint. Para ver las estrategias habituales, consulta Implementar cargas de trabajo.
  • Lista de herramientas y métodos para copiar datos e implementar recursos. Especifica cualquier herramienta que tengas previsto usar para copiar datos o desplegar recursos en el entorno de destino. Esta lista debe incluir secuencias de comandos personalizadas que se usen para copiar recursos de Cloud Storage, herramientas estándar como la CLI de Google Cloud y Google Cloud herramientas como Migration Services.
  • Lista de recursos que se van a implementar en el entorno de destino. Enumera todos los recursos que se deben implementar en el entorno de destino. Esta lista debe incluir todos los componentes de la infraestructura de datos, como los contenedores de Cloud Storage, los conjuntos de datos de BigQuery y los clústeres de Dataproc. En algunos casos, los sprints de migración iniciales incluirán la implementación de un clúster de tamaño determinado (como un clúster de Dataproc) con una capacidad menor, mientras que los sprints posteriores incluirán el cambio de tamaño para adaptarse a las nuevas cargas de trabajo. Asegúrate de que tu plan incluya la posibilidad de cambiar el tamaño.
  • Lista de conjuntos de datos que se van a copiar. En cada conjunto de datos, especifica la siguiente información:
    • Orden de copia (si procede): en la mayoría de las estrategias, el orden de las operaciones puede ser importante. Una excepción es la estrategia de mantenimiento programado, que se describe más adelante en este documento.
    • Tamaño
    • Estadísticas clave: representa en un gráfico estadísticas clave, como el número de filas, que pueden ayudarte a verificar que el conjunto de datos se ha copiado correctamente.
    • Tiempo estimado de copia: el tiempo que se tarda en completar la transferencia de datos, según el plan de migración.
    • Método para copiar: consulta la lista de herramientas y métodos que se describe más arriba en este documento.
    • Pruebas de verificación: enumera explícitamente las pruebas que tienes previsto completar para verificar que los datos se han copiado por completo.
    • Plan de contingencia: describe qué hacer si falla alguna de las pruebas de verificación. En tu plan de contingencia, debes especificar cuándo se debe volver a intentar y reanudar la copia o rellenar el hueco, y cuándo se debe hacer una reversión completa y volver a copiar todo el conjunto de datos.

Pruebas

En esta sección se describen algunos tipos de pruebas habituales que puedes planificar. Las pruebas pueden ayudarte a asegurar la integridad y la exhaustividad de los datos. También pueden ayudarte a asegurarte de que la capa computacional funciona correctamente y está lista para ejecutar tus pipelines de datos.

  • Comparación de resúmenes o hashes: para validar que los datos se han copiado por completo, debe comparar el conjunto de datos original con la nueva copia en el entorno de destino. Si los datos están estructurados en tablas de BigQuery, no puedes combinar las dos tablas en una consulta para ver si existen todos los datos, ya que las tablas se encuentran en regiones diferentes. Debido al coste y la latencia, BigQuery no permite que las consultas combinen datos de diferentes regiones. En su lugar, el método de comparación debe resumir cada conjunto de datos y comparar los resultados. En función de la estructura del conjunto de datos, el método para resumir la información puede ser diferente. Por ejemplo, una tabla de BigQuery puede usar una consulta de agregación, pero un conjunto de archivos de Cloud Storage puede usar una canalización de Spark para calcular un hash de cada archivo y, a continuación, agregar los hashes.

  • Flujos canary: activan trabajos diseñados para validar la integridad y la completitud de los datos. Antes de continuar con los casos prácticos empresariales, como las analíticas de datos, puede ser útil ejecutar trabajos de flujo de canary para asegurarse de que los datos de entrada cumplen una serie de requisitos. Puedes implementar flujos de lanzamiento de versiones canary como flujos de procesamiento de datos personalizados o como flujos en un DAG basado en Cloud Composer. Los flujos de canary pueden ayudarte a completar tareas como verificar que no faltan valores en determinados campos o validar que el recuento de filas de conjuntos de datos específicos coincide con el recuento esperado.

    También puedes usar flujos de lanzamiento de versiones de prueba para crear resúmenes u otras agregaciones de una columna o un subconjunto de los datos. Después, puedes usar el flujo de lanzamiento de versiones de prueba para comparar los datos con un resumen o una agregación similares que se hayan obtenido de la copia de los datos.

    Los métodos de flujo de canary son útiles cuando necesitas evaluar la precisión de los datos almacenados y copiados en formatos de archivo, como los archivos Avro, en Cloud Storage. Normalmente, los flujos de lanzamiento no generan datos nuevos, sino que fallan si no se cumple un conjunto de reglas en los datos de entrada.

  • Entorno de pruebas: una vez que hayas completado el plan de migración, debes probarlo en un entorno de pruebas. El entorno de pruebas debe incluir la copia de datos muestreados o datos de staging en otra región para estimar el tiempo que se tarda en copiar datos a través de la red. Esta prueba le ayudará a identificar cualquier problema con el plan de migración y a verificar que los datos se pueden migrar correctamente. Las pruebas deben incluir pruebas funcionales y no funcionales. Las pruebas funcionales verifican que los datos se migren correctamente. Las pruebas no funcionales verifican que la migración cumpla los requisitos de rendimiento, seguridad y otros requisitos no funcionales. Cada paso de la migración de tu plan debe incluir un criterio de validación que detalle cuándo se puede considerar que se ha completado.

Para facilitar la validación de datos, puede usar la herramienta de validación de datos (DVT). La herramienta realiza funciones de validación de datos de varios niveles, desde el nivel de tabla hasta el de fila, y te ayuda a comparar los resultados de tus sistemas de origen y de destino.

Las pruebas deben verificar la implementación de la capa computacional y probar los conjuntos de datos que se han copiado. Una forma de hacerlo es crear una canalización de pruebas que pueda calcular algunas agregaciones de los conjuntos de datos copiados y asegurarse de que los conjuntos de datos de origen y de destino coincidan. Es más habitual que haya una discrepancia entre los conjuntos de datos de origen y de destino cuando los archivos que copias entre regiones no son representaciones exactas de copia de bytes entre los sistemas de origen y de destino (por ejemplo, cuando cambias los formatos o la compresión de los archivos).

Por ejemplo, supongamos que tiene un conjunto de datos compuesto por archivos JSON delimitados por saltos de línea. Los archivos se almacenan en un segmento de Cloud Storage y se montan como una tabla externa en BigQuery. Para reducir la cantidad de datos que se mueven por la red, puedes realizar la compresión Avro como parte de la migración antes de copiar los archivos en el entorno de destino. Esta conversión tiene muchas ventajas, pero también algunos riesgos, ya que los archivos que se escriben en el entorno de destino no son una representación de copia de bytes de los archivos del entorno de origen.

Para mitigar los riesgos del escenario de conversión, puedes crear un trabajo de Dataflow o usar BigQuery para calcular algunas agregaciones y hashes de suma de comprobación del conjunto de datos (por ejemplo, calculando sumas, medias o cuantiles de cada columna numérica). En las columnas de cadena, puedes calcular agregaciones a partir de la longitud de la cadena o del código hash de esa cadena. En cada fila, puedes calcular un hash agregado a partir de una combinación de todas las demás columnas, lo que permite verificar con gran precisión que una fila es la misma que su origen. Estos cálculos se realizan en los entornos de origen y de destino, y luego se comparan. En algunos casos, como si tu conjunto de datos está almacenado en BigQuery, no puedes combinar tablas de los entornos de origen y de destino porque están en regiones diferentes, por lo que debes usar un cliente que pueda conectarse a ambos entornos.

Puedes implementar los métodos de prueba anteriores en BigQuery o como una tarea por lotes (por ejemplo, en Dataflow). Después, puede ejecutar los trabajos de agregación y comparar los resultados calculados para el entorno de origen con los resultados calculados para el entorno de destino. Este enfoque puede ayudarte a asegurarte de que los datos estén completos y sean precisos.

Otro aspecto importante de las pruebas de la capa computacional es ejecutar las canalizaciones que incluyan todas las variedades de los motores de procesamiento y los métodos computacionales. Probar la canalización es menos importante en el caso de los motores computacionales gestionados, como BigQuery o Dataflow. Sin embargo, es importante probar la canalización en motores de cálculo no gestionados, como Dataproc. Por ejemplo, si tienes un clúster de Dataproc que gestiona varios tipos de computación, como Apache Spark, Apache Hive, Apache Flink o Apache MapReduce, debes probar cada tiempo de ejecución para asegurarte de que los diferentes tipos de carga de trabajo estén listos para transferirse.

Estrategias para migrar

Una vez que hayas verificado tu plan de migración con las pruebas adecuadas, podrás migrar los datos. Cuando migras datos, puedes usar diferentes estrategias para distintas cargas de trabajo. A continuación, se muestran algunos ejemplos de estrategias de migración que puedes usar tal cual o personalizar según tus necesidades:

  • Mantenimiento programado: tú decides cuándo se produce la ventana de cambio. Esta estrategia es adecuada cuando los datos cambian con frecuencia, pero los SLOs y los SLAs pueden tolerar cierto tiempo de inactividad. Esta estrategia ofrece una alta confianza en la transferencia de datos, ya que los datos están completamente obsoletos mientras se copian. Para obtener más información, consulta la sección Mantenimiento programado del artículo "Migración a Google Cloud: transferencia de grandes conjuntos de datos".
  • Cambio a solo lectura: una ligera variación de la estrategia de mantenimiento programado, en la que la plataforma de datos del sistema de origen permite que las canalizaciones de datos de solo lectura sigan leyendo datos mientras se copian. Esta estrategia es útil porque algunos flujos de datos pueden seguir funcionando y proporcionar estadísticas a los sistemas finales. La desventaja de esta estrategia es que los datos que se producen no están actualizados durante la migración, ya que los datos de origen no se actualizan. Por lo tanto, es posible que tengas que aplicar una estrategia de puesta al día después de la migración para tener en cuenta los datos obsoletos de los sistemas finales.
  • Totalmente activo: copias los datos en una marca de tiempo específica, mientras que el entorno de origen sigue activo para las canalizaciones de datos de lectura y escritura. Después de copiar los datos y cambiar a la nueva implementación, se lleva a cabo una fase de copia delta para obtener los datos que se generaron después de la marca de tiempo de la migración en el entorno de origen. Este enfoque requiere más coordinación y reflexión que otras estrategias. Por lo tanto, tu plan de migración debe incluir cómo gestionarás las operaciones de actualización y eliminación de los datos de origen.
  • Escrituras dobles: las canalizaciones de datos se pueden ejecutar en los entornos de origen y de destino mientras se copian los datos. Esta estrategia evita la fase de copia delta que se requiere para rellenar los datos si usas las estrategias totalmente activa o de solo lectura. Sin embargo, para asegurarse de que las canalizaciones de datos producen resultados idénticos, una estrategia de escritura dual requiere más pruebas antes de la migración. Si no realizas pruebas avanzadas, tendrás problemas al intentar consolidar una situación de cerebro dividido. La estrategia de doble escritura también conlleva costes potenciales por ejecutar las mismas cargas de trabajo dos veces en regiones diferentes. Esta estrategia puede migrar tu plataforma sin tiempo de inactividad, pero requiere mucha más coordinación para ejecutarse correctamente.

Pruebas posteriores a la migración

Una vez completada la migración, debes comprobar que los datos están completos y que los flujos de datos son válidos. Si completas la migración por fases, debes realizar estas pruebas después de cada fase. Las pruebas que realices en esta fase son similares a las pruebas de integración: compruebas la validez de una canalización de datos que ejecuta casos prácticos empresariales con datos de producción completos como entrada y, a continuación, inspeccionas la validez de la salida. Para comparar los resultados de la prueba de integración con los del entorno de origen, ejecuta la misma canalización de datos en el entorno de origen y en el de destino. Este tipo de prueba solo funciona si el flujo de datos es determinista y si puedes asegurarte de que la entrada de ambos entornos sea idéntica.

Puedes confirmar que los datos están completos cuando cumplen una serie de criterios predefinidos, en los que los datos del entorno de origen son iguales (o lo suficientemente similares) a los datos del entorno de destino. En función de la estrategia que haya usado en la sección anterior, es posible que los datos no coincidan exactamente. Por lo tanto, debe predefinir criterios para describir la integridad de los datos en su caso práctico. Por ejemplo, en el caso de los datos de series temporales, puede considerar que los datos están completos cuando el registro más actualizado no tenga más de cinco minutos de retraso con respecto a la marca de tiempo actual.

Migración

Una vez que haya verificado y probado los datos y las canalizaciones de datos en el entorno de destino, puede iniciar la fase de cambio. El inicio de esta fase implica que es posible que los clientes tengan que cambiar su configuración para hacer referencia a los nuevos sistemas. En algunos casos, la configuración no puede ser la misma que la que apunta al sistema de origen. Por ejemplo, si un servicio necesita leer datos de un segmento de Cloud Storage, los clientes deben cambiar la configuración del segmento que se va a usar. Los nombres de los segmentos de Cloud Storage son únicos a nivel global, por lo que el segmento de Cloud Storage de tu entorno de destino será diferente del entorno de origen.

Durante la fase de cambio, debes retirar y cancelar la programación de las cargas de trabajo del entorno de origen. Te recomendamos que conserves los datos del entorno de origen durante un tiempo por si necesitas restaurarlos.

La fase de pruebas previas a la migración no es tan completa como una ejecución de producción de una canalización de datos. Por lo tanto, una vez que se haya completado el cambio y el sistema de destino esté operativo, debes monitorizar las métricas, los tiempos de ejecución y los resultados semánticos de tus pipelines de datos. Esta monitorización te ayudará a detectar errores que se hayan podido pasar por alto en la fase de pruebas y a asegurar el éxito de la migración.

Optimizar el entorno

La optimización es la última fase de la migración. En esta fase, puedes mejorar la eficiencia de tu entorno ejecutando varias iteraciones de un bucle repetible hasta que el entorno cumpla tus requisitos de optimización:

  1. Evalúa tu entorno, tus equipos y tu bucle de optimización actuales.
  2. Establezca sus requisitos y objetivos de optimización.
  3. Optimiza tu entorno y tus equipos.
  4. Ajusta el bucle de optimización.

Para obtener más información sobre cómo optimizar tu Google Cloud entorno, consulta Migración a Google Cloud: optimizar tu entorno.

Prepara tus Google Cloud datos y recursos informáticos para una migración entre regiones

En esta sección se ofrece una descripción general de los datos y los recursos informáticos deGoogle Cloud , así como de los principios de diseño para preparar una migración entre regiones.

BigQuery

Como BigQuery es un almacén de datos SQL sin servidor, no tienes que implementar la capa de computación. Si algunos de tus clientes de BigQuery especifican regiones para el tratamiento, tendrás que ajustarlos. De lo contrario, BigQuery será el mismo en el entorno de origen y en el de destino. Los datos de BigQuery se almacenan en dos tipos de tablas:

  • Tablas de BigQuery: tablas en formato BigQuery. BigQuery gestiona los archivos de datos por ti. Para obtener más información sobre cómo migrar datos en formato BigQuery, consulta Gestionar conjuntos de datos.
  • Tablas externas de BigQuery: tablas cuyos datos se almacenan fuera de BigQuery. Una vez que se hayan movido los datos, tendrás que volver a crear las tablas externas en el nuevo destino. Para obtener más información sobre la migración de tablas externas, consulta el artículo Introducción a las tablas externas.

Cloud Storage

Cloud Storage ofrece el Servicio de transferencia de Storage, que puede ayudarte a migrar tus datos.

Dataflow (por lotes)

Dataflow es un motor de procesamiento de datos gestionado por Google. Para simplificar la migración de Dataflow y asegurarte de que tus tareas se puedan desplegar en cualquier región, debes insertar todas las entradas y salidas como parámetros en tu tarea. En lugar de escribir las ubicaciones de los datos de entrada y salida en el código fuente, te recomendamos que pases las rutas de Cloud Storage y las cadenas de conexión de la base de datos como argumentos o parámetros.

Dataproc

Dataproc es un entorno Apache Hadoop gestionado que puede ejecutar cualquier carga de trabajo compatible con el framework Apache Hadoop. Es compatible con frameworks como Apache Spark, Apache Flink y Apache Hive.

Puedes usar Dataproc de las siguientes formas, que influyen en cómo debes migrar tu entorno de Dataproc entre regiones:

  • Clústeres efímeros con datos en Cloud Storage: los clústeres se crean para ejecutar tareas específicas y se destruyen una vez que se han completado. Esto significa que también se destruye la capa HDFS o cualquier otro estado del clúster. Si tu configuración cumple los siguientes criterios, será más fácil migrar este tipo de uso que otros:
    • Las entradas y salidas de tus tareas no están predefinidas en el código fuente. En su lugar, tus trabajos reciben entradas y salidas como argumentos.
    • El aprovisionamiento del entorno de Dataproc está automatizado, incluidas las configuraciones de los frameworks individuales que usa tu entorno.
  • Clústeres de larga duración con datos externos: tienes uno o varios clústeres, pero son de larga duración. Aunque no haya trabajos en ejecución en el clúster, este sigue activo. Los datos y los recursos de computación están separados porque los datos se guardan fuera del clúster enGoogle Cloud soluciones como Cloud Storage o BigQuery. Este modelo suele ser eficaz cuando siempre hay trabajos en ejecución en el clúster, por lo que no tiene sentido desglosar y configurar clústeres como en el modelo efímero. Como los datos y el cálculo están separados, la migración es similar a la migración del modelo efímero.
  • Clústeres de larga duración con datos en el clúster: el clúster es de larga duración, pero también mantiene el estado, los datos o ambos en el clúster, normalmente como datos en HDFS. Este tipo de uso complica las migraciones, ya que los datos y los cálculos no están separados. Si migras uno sin el otro, hay un alto riesgo de que se produzcan incoherencias. En este caso, te recomendamos que muevas los datos y el estado fuera del clúster antes de la migración para separar ambos elementos. Si no puedes hacerlo, te recomendamos que utilices la estrategia de mantenimiento programado para reducir el riesgo de que se produzcan incoherencias en tus datos.

Como hay muchos frameworks posibles, así como muchas versiones y configuraciones de esos frameworks, debes hacer pruebas exhaustivas antes de ejecutar tu plan de migración.

Cloud Composer

Cloud Composer es la versión gestionada de Apache Airflow de Google Cloud, que se usa para orquestar y programar flujos. Los DAGs, las configuraciones y los registros se gestionan en un segmento de Cloud Storage que se debe migrar con tu implementación de Cloud Composer. Para migrar el estado de tu implementación de Cloud Composer, puedes guardar y cargar snapshots del entorno.

Si has implementado algún complemento personalizado en tu instancia de Cloud Composer, te recomendamos que apliques una metodología de infraestructura como código para recrear el entorno de forma totalmente automatizada.

Cloud Composer no gestiona datos, pero activa otros frameworks y plataformas de procesamiento de datos. Por lo tanto, la migración de Cloud Composer se puede aislar por completo de los datos. Cloud Composer tampoco procesa datos, por lo que tu implementación no tiene que estar en la misma región que los datos. Por lo tanto, puede crear una implementación de Cloud Composer en el entorno de destino y seguir ejecutando las canalizaciones en el entorno de origen. En algunos casos, esto puede ser útil para operar diferentes pipelines en diferentes regiones mientras se migra toda la plataforma.

Cloud Data Fusion

Cloud Data Fusion es una herramienta de integración visual que te ayuda a crear flujos de procesamiento de datos con un editor visual. Cloud Data Fusion se basa en el proyecto de código abierto CDAP. Al igual que Cloud Composer, Cloud Data Fusion no gestiona los datos en sí, sino que activa otros frameworks y plataformas de procesamiento de datos. Los flujos de procesamiento de Cloud Data Fusion se deben exportar del entorno de origen e importar al de destino de una de las siguientes formas:

En función de la cantidad de flujos que necesites migrar, puede que prefieras un método u otro. Usar la API de CDAP para crear una secuencia de comandos de migración puede ser difícil y requiere más conocimientos de ingeniería de software. Sin embargo, si tienes muchos flujos o si cambian con relativa frecuencia, un proceso automatizado puede ser la mejor opción.

Siguientes pasos

Colaboradores

Autor: Eyal Ben Ivri | Arquitecto de soluciones en la nube

Otro colaborador: Marco Ferrari | Arquitecto de soluciones en la nube