Diseña tus cargas de trabajo

Last reviewed 2024-07-24 UTC

Este documento te ayuda a diseñar cargas de trabajo de una manera que minimice el impacto de una expansión y migración futuras de cargas de trabajo a otras regiones de Google Cloud, o el impacto de una migración de cargas de trabajo entre regiones. Este documento es útil si planeas realizar alguna de estas actividades o si estás evaluando la oportunidad de hacerlo en el futuro y deseas explorar cómo podría ser el trabajo.

Este documento forma parte de una serie:

La guía de esta serie también es útil si no planificaste una migración entre regiones o una expansión a varias regiones con anticipación. En este caso, es posible que debas invertir un esfuerzo adicional para preparar la infraestructura, las cargas de trabajo y los datos de la migración entre regiones y la expansión a varias regiones.

Este documento te ayuda a hacer lo siguiente:

  1. Prepara tu zona de destino
  2. Prepara tus cargas de trabajo para una migración entre regiones
  3. Prepara tus recursos de procesamiento
  4. Prepara tus recursos de almacenamiento de datos
  5. Prepárate para retirar de servicio el entorno de origen

Prepara tu zona de destino

En esta sección, se enfocan las consideraciones que debes tener en cuenta para extender una zona de destino (también llamada base de la nube) cuando realices la migración entre regiones.

El primer paso es volver a evaluar los diferentes aspectos de cualquier zona de destino existente. Antes de migrar cualquier carga de trabajo, ya debes tener una zona de destino establecida. Aunque es posible que ya tengas una zona de destino para la región que aloja las cargas de trabajo, es posible que la zona de destino no admita la implementación de cargas de trabajo en una región diferente, por lo que debe extenderse a la región de destino. Es posible que algunas zonas de destino que ya están implementadas tengan un diseño que pueda admitir otra región sin necesidad de realizar cambios significativos en la zona de destino (por ejemplo, administración de identidad y acceso o administración de recursos). Sin embargo, es posible que otros factores, como la red o los datos, requieran que planifiques la extensión. Tu proceso de reevaluación debe tener en cuenta los requisitos principales de tus cargas de trabajo para que puedas configurar una base genérica que se pueda especializar más adelante durante la migración.

Consideraciones empresariales

Cuando se trata de aspectos como los estándares, las reglamentaciones y las certificaciones de la industria y el Gobierno, el traslado de las cargas de trabajo a otra región puede tener requisitos diferentes. Las cargas de trabajo que se ejecutan en regiones de Google que se encuentran físicamente en países diferentes deben seguir las leyes y reglamentaciones de ese país. Además, los diferentes estándares de la industria pueden tener requisitos particulares para las cargas de trabajo que se ejecutan en el extranjero (en especial, en términos de seguridad). Debido a que las regiones de Google Cloud se compilan 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 con reglamentaciones específicas. Cuando realizas estas migraciones "en el país", es importante volver a evaluar los datos que se ejecutan de forma local para verificar si la nueva región permite la migración de tus datos a Google Cloud.

Administración de identidades y accesos

Cuando planificas una migración, es probable que no tengas que planificar muchos cambios de identidad y acceso para las regiones que ya están en Google Cloud. Las decisiones de identidad en Google Cloud y el acceso a los recursos suelen basarse en la naturaleza de los recursos, más que en la región en la que se ejecutan. Estas son algunas consideraciones que tal vez debas tener en cuenta:

  • Diseño de equipos: Algunas empresas están estructuradas para tener diferentes equipos que manejen diferentes recursos. Cuando una carga de trabajo se migra a otra región, debido al cambio en la estructura de los recursos, es posible que un equipo diferente sea el mejor candidato para ser responsable de ciertos recursos, en cuyo caso, los accesos se deben ajustar según corresponda.
  • Convenciones de nombres: Aunque las convenciones de nombres no tengan ningún impacto técnico en las funcionalidades, es posible que se deba tener en cuenta si hay recursos definidos con convenciones de nombres que se refieren 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 se nombran con la región como prefijo, por ejemplo, europe-west1-backend-1. Durante el proceso de migración, para evitar confusiones o, lo que es peor, romper las canalizaciones que dependen de una convención de nombres específica, es importante cambiar los nombres para que reflejen la región nueva.

Conectividad y Herramientas de redes

El diseño de tu red afecta a varios aspectos de cómo se ejecuta la migración, por lo que es importante abordar 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 la región. Un ejemplo de este factor es Cloud Interconnect, que está conectado a Google Cloud a través de un adjunto de VLAN hacia regiones específicas. Debes cambiar la región en la que está conectado el adjunto de VLAN antes de descartar esa región para evitar el tráfico de una región a otra. Otro factor que debes tener en cuenta es que, si usas la interconexión de socio, migrar la región puede ayudarte a seleccionar una ubicación física diferente en la que conectar tus adjuntos de VLAN a Google Cloud. Esta consideración también es relevante si usas una Cloud VPN y decides cambiar las direcciones de las subredes en la migración: debes volver a configurar tus routers para reflejar las redes nuevas.

Si bien las nubes privadas virtuales (VPC) en Google Cloud son recursos globales, las subredes individuales 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. Dado que las subredes no pueden tener IPs superpuestas, para mantener las mismas direcciones, debes crear una VPC nueva. Este proceso se simplifica si usas Cloud DNS, que puede aprovechar funciones como el intercambio de tráfico 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 compilar una base en Google Cloud, consulta Migra a Google Cloud: Planifica y compila tu base.

Prepara tus cargas de trabajo para una migración entre regiones

Ya sea que configures tu infraestructura en Google Cloud y planees migrar más adelante a otra región, o que ya estés en Google Cloud y necesites migrar a otra región, debes asegurarte de que tus cargas de trabajo se puedan migrar de la manera más sencilla para reducir el esfuerzo y minimizar los riesgos. Para garantizar que todas las cargas de trabajo estén en un estado que permita una ruta de acceso a la migración, te recomendamos que adoptes el siguiente enfoque:

  • Prefiere diseños de red que se puedan replicar fácilmente y con acoplamiento bajo de la topología de red específica. Google Cloud ofrece diferentes productos que pueden ayudarte a desacoplar tu configuración de red actual de los recursos que usan esa red. Un ejemplo de este producto es Cloud DNS, que te permite desvincular las IPs de subredes internas de las VMs.
  • Configura productos que admitan parámetros de configuración multirregionales o globales. Los productos que admiten una configuración que involucra más de una región, por lo general, simplifican el proceso de migración a otra región.
  • Considera los servicios administrados con réplicas entre regiones administradas para los datos. Como se describe en las siguientes secciones de este documento, algunos servicios administrados te permiten crear una réplica en una región diferente, por lo general, para realizar copias de seguridad o con fines de alta disponibilidad. Esta función puede ser importante para migrar datos de una región a otra.

Algunos servicios de Google Cloud están diseñados para admitir implementaciones multirregionales o implementaciones globales. No es necesario que migres estos servicios, aunque es posible que debas ajustar algunos parámetros de configuración.

Prepara tus recursos de procesamiento

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

Este documento se enfoca en los siguientes productos de procesamiento de 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, debes evaluar diferentes factores, además de las consideraciones de redes.

Te recomendamos que hagas lo siguiente:

  • Verifica los recursos de procesamiento: Una de las primeras limitaciones que puedes encontrar cuando cambias la región de hosting 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, verifica que el sistema operativo de tu VM actual sea compatible con la serie. En términos generales, este problema se puede extender a todos los servicios de procesamiento de Google Cloud (es posible que algunas regiones nuevas no tengan servicios como Cloud Run o GPU de Cloud), por lo que, antes de planificar la migración, asegúrate de que todos los servicios de procesamiento que necesitas estén disponibles en la región de destino.
  • Configura el balanceo de cargas y el escalamiento: Compute Engine admite el tráfico de balanceo de cargas entre instancias de Compute Engine y el ajuste de escala automático para agregar o quitar máquinas virtuales de forma automática de MIG, según la demanda. Te recomendamos que configures el balanceo de cargas y el ajuste de escala automático para aumentar la confiabilidad y la flexibilidad de tus entornos, y evitar la carga de la administración de las soluciones autoadministradas. Consulta Balanceo de cargas y escalamiento para obtener más información sobre la configuración del balanceo de cargas y el escalamiento de Compute Engine.
  • Usa nombres de DNS zonales: Para mitigar el riesgo de interrupciones interregionales, te recomendamos que uses nombres de DNS zonales para identificar de manera inequívoca las máquinas virtuales que usan nombres de DNS en tus entornos. Google Cloud usa nombres de DNS zonales para 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 Descripción general del DNS interno. Para facilitar una migración futura entre regiones y hacer que la 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, finalmente, podrás cambiar en el futuro.
  • Usa la misma plantilla de grupos de instancias administrados (MIG): Compute Engine te permite crear MIG regionales que aprovisionan máquinas virtuales en varias zonas de una región de forma automática. Si usas una plantilla en tu región anterior, puedes usar la misma plantilla para implementar los MIG en la región nueva.

GKE

Google Kubernetes Engine (GKE) te ayuda a implementar, administrar y escalar cargas de trabajo alojadas en contenedores en Kubernetes.

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

  • Cloud Service Mesh: Es una implementación administrada de la malla de Istio. Adoptar Cloud Service Mesh en tu clúster te permite tener un mayor nivel de control sobre el tráfico de red que ingresa al clúster. Una de las características 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 región nueva y agregándolo a la malla de servicios. Con este enfoque, es posible comenzar a implementar cargas de trabajo en el clúster nuevo y enrutar el tráfico a ellas de forma gradual, lo que te permite probar la implementación nueva y, al mismo tiempo, tener la opción de revertir la edición del enrutamiento de la malla.
  • Sincronizador de configuración: Un servicio de GitOps compilado en un núcleo de código abierto que permite a los operadores de clústeres y administradores de plataformas implementar parámetros de configuración desde una sola fuente. El Sincronizador de configuración puede admitir uno o varios clústeres, lo que te permite usar una única fuente de información para configurar los clústeres. Puedes usar esta función del Sincronizador de configuración para replicar la configuración del clúster existente en el clúster de la región nueva y, posiblemente, personalizar un recurso específico para la región.
  • Copia de seguridad para GKE: Esta función te permite crear copias de seguridad de los datos persistentes del clúster de forma periódica y restablecerlos en el mismo clúster o en uno nuevo.

Cloud Run

Cloud Run ofrece un enfoque ligero para implementar 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 implementas un servicio de Cloud Run, puedes elegir una región en la que se implementará la instancia y, luego, usar esta función para implementar la carga de trabajo en una región diferente.

VMware Engine

Google Cloud VMware Engine es un servicio completamente administrado que permite ejecutar la plataforma de VMware en Google Cloud. El entorno de VMware se ejecuta de forma nativa en la infraestructura de equipos físicos deGoogle Cloud en ubicaciones de Google Cloud , incluidos vSphere, vCenter, vSAN, NSX-T, HCX y las herramientas correspondientes.

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

También debes considerar el DNS y el balanceo de cargas en los entornos de Compute Engine cuando planifiques la migración. VMware Engine usa Google Cloud DNS, que es un servicio de alojamiento de DNS administrado que proporciona alojamiento de DNS autorizado publicado en el Internet público, zonas privadas visibles para las redes de VPC, y reenvío e intercambio de tráfico de DNS para administrar la resolución de nombres en redes de VPC. Tu plan de migración puede admitir pruebas de balanceo de cargas multirregión y parámetros de configuración de DNS.

Prepara tus recursos de almacenamiento de datos

En esta sección, se proporciona una descripción general de los recursos de almacenamiento de datos en Google Cloud y los conceptos básicos para 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 capacidad de copiar datos de la base de datos en una región diferente y restablecerlos en otro lugar es un patrón común en la recuperación ante desastres (DR). Por este motivo, algunos de los patrones que se describen en este documento se basan en mecanismos de DR, como la copia de seguridad y la recuperación de bases de datos.

En este documento, se describen los siguientes servicios administrados:

En este documento, se supone que las soluciones de almacenamiento que usas son instancias regionales que se encuentran en la misma ubicación que los recursos de procesamiento.

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 una región diferente para la copia de seguridad y también para la migración de una región a otra.

Cloud SQL

Cloud SQL ofrece un servicio de base de datos relacional para alojar diferentes tipos de bases de datos. Cloud SQL ofrece una funcionalidad de replicación entre regiones que permite replicar los datos de la instancia en una región diferente. Esta característica es un patrón común para la copia de seguridad y el restablecimiento de instancias de Cloud SQL, pero también te permite ascender la segunda réplica en la otra región a la réplica principal. Puedes usar esta función para crear una réplica de lectura en la segunda región y, luego, ascenderla a la réplica principal una vez que migres las cargas de trabajo. En general, para las bases de datos, los servicios administrados simplifican el proceso de replicación de datos para facilitar la creación de una réplica en la región nueva durante la migración.

Otra forma de controlar la migración es con Database Migration Service, que te permite migrar bases de datos de SQL de diferentes fuentes a Google Cloud. Entre las fuentes compatibles, también hay otra instancia de Cloud SQL, con la única limitación de que puedes migrar a una región diferente, pero no a un proyecto diferente.

Filestore

Como se explicó antes en este documento, la función de copia de seguridad y restablecimiento de Filestore te permite crear una copia de seguridad de un recurso compartido de archivos que se puede restablecer en otra región. Esta función se puede usar para realizar la migración 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. Verifica en la lista de ubicaciones de Bigtable si el servicio está disponible en la región de destino.

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

La última opción es exportar tablas, por ejemplo, en Cloud Storage. Estas exportaciones alojarán datos en otro servicio, y los datos estarán disponibles para importarlos a la instancia en 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 la instancia de Firestore a ser multirregional. En estas situaciones 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 app de App Engine ubicada en us-central o europe-west, la base de datos de Firestore se considera multirregional.

Si tienes una ubicación regional y quieres migrar a una ubicación diferente, el servicio administrado de importación y exportación te permite importar y exportar entidades de Firestore con un bucket 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 restablecimiento de Firestore. Esta opción es menos costosa y más directa que la importación y exportación.

Prepárate para retirar de servicio el entorno de origen

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

En un nivel alto, debes considerar lo siguiente antes de retirar el entorno de origen:

  • Pruebas del entorno nuevo: Antes de cambiar el tráfico del entorno anterior al nuevo, puedes realizar pruebas para validar la corrección de las aplicaciones. Además de las pruebas clásicas de unidades y de integración que se pueden realizar en las aplicaciones migradas recientemente, existen diferentes estrategias de prueba. El entorno nuevo se puede tratar como una versión nueva 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. Otro enfoque es replicar el tráfico entrante en el entorno de origen y en el nuevo para verificar que se conserven las funciones.
  • Planificación del tiempo de inactividad: Si seleccionas una estrategia de migración, como azul-verde, en la que cambias el tráfico de un entorno a otro, considera la adopción del tiempo de inactividad planificado. El tiempo de inactividad permite supervisar mejor la transición y evitar errores impredecibles del lado del cliente.
  • Reversión: Según las estrategias adoptadas para migrar el tráfico, puede ser necesario implementar una reversión en caso de errores o una configuración incorrecta del entorno nuevo. Para poder revertir el entorno, debes tener una infraestructura de supervisión para detectar el estado del entorno nuevo.

Solo es posible cerrar los servicios en la primera región después de realizar pruebas extendidas en la nueva región y de que se ponga en marcha en la nueva región sin errores. Te recomendamos que conserves las copias de seguridad de la primera región durante un período limitado, hasta que te asegures de que no haya problemas en la región recién migrada.

También debes considerar si deseas promover la región anterior a un sitio de recuperación ante desastres, suponiendo que aún no haya una solución implementada. Este enfoque requiere un diseño adicional para garantizar que el sitio sea confiable. Para obtener más información sobre cómo diseñar y planificar correctamente la DR, consulta la Guía de planificación para la recuperación ante desastres.

Qué sigue

Colaboradores

Autor: Valerio Ponza | Asesor de soluciones técnicas

Otros colaboradores: