Diseñar tus cargas de trabajo

Last reviewed 2024-07-24 UTC

Este documento te ayuda a diseñar cargas de trabajo de forma que se minimice el impacto de una futura ampliación y migración de cargas de trabajo a otras Google Cloud regiones, o el impacto de una migración de cargas de trabajo entre regiones. Este documento es útil si tienes previsto realizar alguna de estas actividades o si estás evaluando la oportunidad de hacerlo en el futuro y quieres saber cómo sería el trabajo.

Este documento forma parte de una serie:

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 le ayudará a hacer lo siguiente:

  1. Preparar la zona de aterrizaje
  2. Preparar las cargas de trabajo para una migración entre regiones
  3. Preparar los recursos informáticos
  4. Preparar los recursos de almacenamiento de datos
  5. Prepararse para retirar el entorno de origen

Preparar la zona de aterrizaje

En esta sección se describen los aspectos que debes tener en cuenta para ampliar una zona de aterrizaje (también denominada base de la nube) al migrar entre regiones.

El primer paso es volver a evaluar los distintos aspectos de cualquier zona de aterrizaje que ya tengas. Antes de migrar cualquier carga de trabajo, debes tener una zona de aterrizaje. Aunque ya tengas una zona de aterrizaje en la región que aloja las cargas de trabajo, es posible que no admita el despliegue de cargas de trabajo en otra región, por lo que debes ampliarla a la región de destino. Algunas zonas de aterrizaje que ya están implementadas pueden tener un diseño que admita otra región sin tener que hacer cambios significativos en la zona de aterrizaje (por ejemplo, la gestión de identidades y accesos o la gestión de recursos). Sin embargo, otros factores, como la red o los datos, pueden requerir que planifiques la extensión. En el proceso de reevaluación, debes tener en cuenta los principales requisitos de tus cargas de trabajo para poder configurar una base genérica que se pueda especializar más adelante durante la migración.

Consideraciones para empresas

En lo que respecta a aspectos como los estándares, las normativas y las certificaciones del sector y de las administraciones públicas, la migración de cargas de trabajo a otra región puede tener requisitos diferentes. Las cargas de trabajo que se ejecutan en regiones de Google ubicadas físicamente en diferentes países deben cumplir las leyes y los reglamentos de esos países. Además, los distintos estándares del sector pueden tener requisitos específicos para las cargas de trabajo que se ejecutan en el extranjero (especialmente en lo que respecta a la seguridad). Como las Google Cloud regiones se crean para ejecutar recursos en un solo país, a veces las cargas de trabajo se migran de otra región de Google a ese país para cumplir normativas específicas. Cuando realices estas migraciones "en el mismo país", es importante que vuelvas a evaluar los datos que se ejecutan de forma local para comprobar si la nueva región permite la migración de tus datos a Google Cloud.

Gestión de identidades y accesos

Cuando planifiques una migración, probablemente no tengas que planificar muchos cambios de identidad y acceso para las regiones que ya estén en Google Cloud. Las decisiones sobre la identidad y el acceso a los recursos suelen basarse en la naturaleza de los recursos, en lugar de en la región en la que se ejecutan. Google Cloud A continuación, se indican algunas consideraciones que debes tener en cuenta:

  • Diseño de los equipos: algunas empresas se estructuran de forma que haya diferentes equipos para gestionar distintos recursos. Cuando se migra una carga de trabajo a otra región, debido al cambio en la estructura de los recursos, puede que otro equipo sea el más adecuado para hacerse cargo de determinados recursos. En ese caso, los accesos deben ajustarse en consecuencia.
  • Convenciones de nomenclatura: aunque las convenciones de nomenclatura no tengan ningún impacto técnico en las funciones, es posible que debas tener en cuenta algunos aspectos si hay recursos definidos con convenciones de nomenclatura que hagan referencia a la región específica. Un ejemplo típico es cuando ya hay varias regiones replicadas, como las máquinas virtuales (VMs) de Compute Engine, que tienen el nombre de la región como prefijo (por ejemplo, europe-west1-backend-1). Durante el proceso de migración, para evitar confusiones o, peor aún, que se interrumpan las canalizaciones que dependen de una convención de nomenclatura específica, es importante cambiar los nombres para que reflejen la nueva región.

Conectividad y redes

El diseño de tu red influye en varios aspectos de la ejecución de la migración, por lo que es importante que abordes este diseño antes de planificar cómo mover las cargas de trabajo.

Ten en cuenta que la conectividad local con Google Cloud es uno de los factores que debes volver a evaluar en la migración, ya que se puede diseñar para que sea específica de una región. Un ejemplo de este factor es Cloud Interconnect, que se conecta a Google Cloud mediante una vinculación de VLAN a regiones específicas. Debes cambiar la región a la que está conectada la vinculación de VLAN antes de descartar esa región para evitar el tráfico entre regiones. Otro factor que debes tener en cuenta es que, si usas Partner Interconnect, migrar la región puede ayudarte a seleccionar otra ubicación física en la que conectar tus vinculaciones de VLAN a Google Cloud. Esta consideración también es importante si usas una VPN de Cloud y decides cambiar las direcciones de subred en la migración: debes volver a configurar los routers para que reflejen la nueva red.

Aunque las nubes privadas virtuales (VPCs) de Google Cloud son recursos globales, las subredes siempre están vinculadas a una región, lo que significa que no puedes usar la misma subred para las cargas de trabajo después de la migración. Como las subredes no pueden solaparse con IPs, para mantener las mismas direcciones, debes crear una VPC. Este proceso se simplifica si usas Cloud DNS, que puede aprovechar funciones como el peering de DNS para enrutar el tráfico de las cargas de trabajo migradas antes de descartar la región antigua.

Para obtener más información sobre cómo crear una base en Google Cloud, consulta el artículo Migrar a Google Cloud: planificar y crear tu base.

Preparar las cargas de trabajo para una migración entre regiones

Tanto si estás configurando tu infraestructura en Google Cloud y tienes previsto migrar a otra región más adelante, como si ya estás en Google Cloud y necesitas migrar a otra región, debes asegurarte de que tus cargas de trabajo se puedan migrar de la forma más sencilla posible para reducir el esfuerzo y minimizar los riesgos. Para asegurarte de que todas las cargas de trabajo estén en un estado que permita la migración, te recomendamos que sigas estos pasos:

  • Prefiere diseños de red que se puedan replicar fácilmente y que no estén estrechamente vinculados a la topología de red específica. Google Cloud ofrece diferentes productos que pueden ayudarte a desacoplar la configuración de tu red actual de los recursos que usan esa red. Un ejemplo de este tipo de producto es Cloud DNS, que te permite desacoplar las IPs de subred internas de las máquinas virtuales.
  • Configure productos que admitan configuraciones multirregionales o globales. Los productos que admiten una configuración que implica más de una región suelen simplificar el proceso de migración a otra región.
  • Plantéate usar servicios gestionados con réplicas entre regiones gestionadas para los datos. Como se describe en las siguientes secciones de este documento, algunos servicios gestionados le permiten crear una réplica en otra región, normalmente con fines de copia de seguridad o de alta disponibilidad. Esta función puede ser importante para migrar datos de una región a otra.

Algunos Google Cloud servicios se han diseñado para admitir despliegues multirregionales o despliegues globales. No es necesario que migres estos servicios, aunque puede que tengas que ajustar algunas configuraciones.

Preparar los recursos informáticos

En esta sección se ofrece una descripción general de los recursos de computación de Google Cloud y los principios de diseño para prepararse para una migración a otra región.

Este documento se centra en los siguientes productos informáticos: Google Cloud

Compute Engine

Compute Engine es el servicio de Google Cloudque proporciona VMs a los clientes.

Para migrar recursos de Compute Engine de una región a otra, debe evaluar diferentes factores, además de las consideraciones sobre la red.

Te recomendamos que hagas lo siguiente:

  • Comprueba los recursos de computación: una de las primeras limitaciones que puedes encontrar al cambiar la región de alojamiento de una VM es la disponibilidad de la plataforma de CPU en la nueva región de destino. Si tienes que cambiar una serie de máquinas durante la migración, comprueba que el sistema operativo de tu máquina virtual actual sea compatible con la serie. En general, este problema se puede extender a todos los servicios de computación (es posible que algunas regiones nuevas no tengan servicios como Cloud Run u Cloud GPU), por lo que, antes de planificar la migración, asegúrate de que todos los servicios de computación que necesites estén disponibles en la región de destino. Google Cloud
  • Configurar el balanceo de carga y el escalado: Compute Engine admite el balanceo de carga del tráfico entre instancias de Compute Engine y el autoescalado para añadir o quitar automáticamente máquinas virtuales de los MIGs en función de la demanda. Te recomendamos que configures el balanceo de carga y el escalado automático para aumentar la fiabilidad y la flexibilidad de tus entornos, así como para evitar la carga de gestión de las soluciones autogestionadas. Para obtener más información sobre cómo configurar el balanceo de carga y el escalado en Compute Engine, consulta Balanceo de carga y escalado.
  • Usar nombres de DNS zonales: para reducir el riesgo de interrupciones entre regiones, te recomendamos que uses nombres de DNS zonales para identificar de forma única las máquinas virtuales mediante nombres de DNS en tus entornos. Google Cloud usa nombres de DNS zonales para las máquinas virtuales de Compute Engine de forma predeterminada. Para obtener más información sobre cómo funciona el DNS interno de Compute Engine, consulta el resumen del DNS interno. Para facilitar una futura migración entre regiones y que tu configuración sea más fácil de mantener, te recomendamos que consideres los nombres de DNS zonales como parámetros de configuración que podrás cambiar en el futuro.
  • Usa la misma plantilla de grupos de instancias gestionadas (MIGs): Compute Engine te permite crear MIGs regionales que aprovisionan automáticamente máquinas virtuales en varias zonas de una región. Si usas una plantilla en tu antigua región, puedes usar la misma plantilla para desplegar los MIGs en la nueva región.

GKE

Google Kubernetes Engine (GKE) te ayuda a desplegar, gestionar y escalar cargas de trabajo en contenedores en Kubernetes.

Para preparar tus cargas de trabajo de GKE para una migración, ten en cuenta los siguientes puntos de diseño y funciones de GKE:

  • Cloud Service Mesh: una implementación gestionada de la malla de Istio. Si adoptas Cloud Service Mesh en tu clúster, tendrás un mayor control sobre el tráfico de red que entra en él. Una de las funciones clave de Cloud Service Mesh es que te permite crear una malla de servicios entre dos clústeres. Puedes usar esta función para planificar la migración de una región a otra creando el clúster de GKE en la nueva región y añadiéndolo a la malla de servicios. Con este enfoque, es posible empezar a desplegar cargas de trabajo en el nuevo clúster y enrutar el tráfico hacia ellas de forma gradual, lo que te permite probar el nuevo despliegue y, al mismo tiempo, tener la opción de revertir los cambios editando el enrutamiento de la malla.
  • Config Sync: un servicio de GitOps basado en un núcleo de código abierto que permite a los operadores de clústeres y a los administradores de plataformas desplegar configuraciones desde una única fuente. Config Sync puede admitir uno o varios clústeres, lo que te permite usar una única fuente de información veraz para configurar los clústeres. Puedes usar esta función de Config Sync para replicar la configuración del clúster en el clúster de la nueva región y, si quieres, personalizar un recurso específico para la región.
  • Copia de seguridad de GKE: esta función te permite crear copias de seguridad periódicas de los datos persistentes de tu clúster y restaurar los datos en el mismo clúster o en uno nuevo.

Cloud Run

Cloud Run ofrece un enfoque ligero para desplegar contenedores en Google Cloud. Los servicios de Cloud Run son recursos regionales y se replican en varias zonas de la región en la que se encuentran. Cuando despliegas un servicio de Cloud Run, puedes elegir una región en la que desplegar la instancia y, a continuación, usar esta función para desplegar la carga de trabajo en otra región.

VMware Engine

VMware Engine de Google Cloud es un servicio totalmente gestionado que te permite ejecutar la plataforma VMware en Google Cloud. El entorno de VMware se ejecuta de forma nativa en laGoogle Cloud infraestructura de hardware desnudo Google Cloud en ubicaciones que incluyen vSphere, vCenter, vSAN, NSX-T, HCX y las herramientas correspondientes.

Para migrar instancias de VMware Engine a otra región, debes crear tu nube privada en la nueva región y, a continuación, usar las herramientas de VMware para mover las instancias.

También debes tener en cuenta el DNS y el balanceo de carga en los entornos de Compute Engine al planificar la migración. VMware Engine usa Google Cloud DNS, que es un servicio de alojamiento de DNS gestionado que proporciona alojamiento de DNS autoritativo publicado en Internet público, zonas privadas visibles para redes de VPC y reenvío y peering de DNS para gestionar la resolución de nombres en redes de VPC. Tu
plan de migración puede admitir pruebas de balanceo de carga multirregional y configuraciones de DNS.

Preparar los recursos de almacenamiento de datos

En esta sección se ofrece una descripción general de los recursos de almacenamiento de datos enGoogle Cloud y los aspectos básicos sobre cómo prepararse para una migración a otra región.

La presencia de los datos en Google Cloud simplifica la migración, ya que implica que existe una solución para alojarlos sin ninguna transformación o que se pueden alojar en Google Cloud.

La posibilidad de copiar datos de una base de datos en otra región y restaurarlos en otro lugar es un patrón habitual en la recuperación tras desastres. Por este motivo, algunos de los patrones descritos en este documento se basan en mecanismos de recuperación ante desastres, como la copia de seguridad y la recuperación de bases de datos.

En este documento se describen los siguientes servicios gestionados:

En este documento se da por hecho que las soluciones de almacenamiento que utilizas son instancias regionales que se encuentran en la misma ubicación que los recursos de computación.

Cloud Storage

Cloud Storage ofrece el servicio de transferencia de almacenamiento, que automatiza la transferencia de archivos de diferentes sistemas a Cloud Storage. Se puede usar para replicar datos en otra región con fines de copia de seguridad y también para migrar de una región a otra.

Cloud SQL

Cloud SQL ofrece un servicio de bases de datos relacionales para alojar diferentes tipos de bases de datos. Cloud SQL ofrece una función de replicación entre regiones que permite replicar los datos de una instancia en otra región. Esta función es un patrón habitual para crear copias de seguridad y restaurar instancias de Cloud SQL, pero también te permite convertir la segunda réplica de la otra región en la réplica principal. Puedes usar esta función para crear una réplica de lectura en la segunda región y, a continuación, convertirla en la réplica principal una vez que hayas migrado las cargas de trabajo. En general, en el caso de las bases de datos, los servicios gestionados simplifican el proceso de replicación de datos, lo que facilita la creación de una réplica en la nueva región durante la migración.

Otra forma de gestionar la migración es usar Database Migration Service, que te permite migrar bases de datos SQL de diferentes fuentes a Google Cloud. Entre las fuentes admitidas, también se encuentra otra instancia de Cloud SQL, con la única limitación de que puedes migrar a otra región, pero no a otro proyecto.

Filestore

Como se ha explicado anteriormente en este documento, la función de copia de seguridad y restauración de Filestore te permite crear una copia de seguridad de un sistema de archivos compartido que se puede restaurar en otra región. Esta función se puede usar para migrar de una región a otra.

Bigtable

Al igual que Cloud SQL, Bigtable admite la replicación. Puedes usar esta función para replicar el mismo patrón descrito. Consulta la lista de ubicaciones de Bigtable para ver si el servicio está disponible en la región de destino.

Además, al igual que Filestore, Bigtable admite copias de seguridad y restauración. Esta función se puede usar, al igual que con Filestore, para implementar la migración creando una copia de seguridad y restaurándola en otra instancia de la nueva región.

La última opción es exportar tablas, por ejemplo, a Cloud Storage. Estas exportaciones alojarán los datos en otro servicio, y los datos estarán disponibles para importarse a la instancia de la región.

Firestore

Las ubicaciones de Firestore pueden estar vinculadas a la presencia de App Engine en tu proyecto, lo que, en algunos casos, obliga a que la instancia de Firestore sea multirregional. En estos casos de migración, también es necesario tener en cuenta App Engine para diseñar la solución adecuada para Firestore. De hecho, si ya tienes una aplicación de App Engine con la ubicación us-central o
europe-west, tu base de datos de Firestore se considera multirregional.

Si tienes una ubicación regional y quieres migrar a otra, el servicio de importación y exportación gestionado te permite importar y exportar entidades de Firestore mediante un segmento de Cloud Storage. Este método se puede usar para mover instancias de una región a otra. La otra opción es usar la función de copia de seguridad y restauración de Firestore. Esta opción es más económica y sencilla que la importación y la exportación.

Prepararse para retirar el entorno de origen

Debes prepararte con antelación antes de retirar el entorno de origen y cambiar al nuevo.

A grandes rasgos, debes tener en cuenta lo siguiente antes de retirar el entorno de origen:

  • Pruebas de entorno nuevo: antes de cambiar el tráfico del entorno antiguo al nuevo, puedes hacer pruebas para validar que las aplicaciones funcionan correctamente. Además de las pruebas unitarias y de integración clásicas que se pueden realizar en las aplicaciones recién migradas, hay diferentes estrategias de prueba. El nuevo entorno se puede tratar como una nueva versión del software y la migración del tráfico se puede implementar con patrones comunes, como las pruebas A/B, que se usan para la validación. Otra opción es replicar el tráfico entrante en el entorno de origen y en el nuevo para comprobar que se conservan las funciones.
  • Planificación del tiempo de inactividad: si seleccionas una estrategia de migración como la azul-verde, en la que cambias el tráfico de un entorno a otro, considera la posibilidad de adoptar un tiempo de inactividad planificado. El tiempo de inactividad permite monitorizar mejor la transición y evitar errores impredecibles en el lado del cliente.
  • Restauración: en función de las estrategias adoptadas para migrar el tráfico, puede que sea necesario implementar una restauración en caso de que se produzcan errores o una configuración incorrecta del nuevo entorno. Para poder restaurar el entorno, debes tener una infraestructura de monitorización para detectar el estado del nuevo entorno.

Solo puedes cerrar los servicios de la primera región después de realizar pruebas ampliadas en la nueva región y poner en marcha los servicios en la nueva región sin errores. Te recomendamos que conserves copias de seguridad de la primera región durante un tiempo limitado, hasta que te asegures de que no hay problemas en la región recién migrada.

También debes plantearte si quieres ascender la región antigua a sitio de recuperación ante desastres, si aún no tienes una solución. Este enfoque requiere un diseño adicional para asegurar que el sitio sea fiable. Para obtener más información sobre cómo diseñar y planificar correctamente la recuperación tras fallos, consulta la guía de planificación para la recuperación tras fallos.

Siguientes pasos

Colaboradores

Autor: Valerio Ponza | Asesor de soluciones técnicas

Otros colaboradores: