Diseña tus cargas de trabajo

Last reviewed 2024-07-24 UTC

En este documento, encontrarás ayuda para diseñar cargas de trabajo de una manera que minimice el impacto de una expansión futura y la migración 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.

En este documento, encontrarás ayuda para 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 implementada. 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 se debe extender 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 factores adicionales, como la red o los datos, requieran que planifiques la extensión. El proceso de reevaluación debe tener en cuenta los requisitos principales de tus cargas de trabajo para permitirte 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 normativas y las certificaciones industriales y gubernamentales, mover las cargas de trabajo a otra región puede tener distintos requisitos. 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 (especialmente 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 “dentro del país”, es importante volver a evaluar los datos que se ejecutan de manera local para verificar si la región nueva permite la migración de los 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, en lugar de la región en la que se ejecutan. Estas son algunas consideraciones que debes tener en cuenta:

  • Diseño de equipos: Algunas empresas están estructuradas para tener diferentes equipos que administren diferentes recursos. Cuando se migra una carga de trabajo a otra región debido a un cambio en la estructura de los recursos, es posible que un equipo diferente sea el mejor candidato para ser responsable de ciertos recursos. En ese caso, los accesos deben ajustarse según corresponda.
  • Convenciones de nombres: Aunque las convenciones de nombres pueden no tener ningún impacto técnico en las funcionalidades, es posible que se necesite cierta consideración si hay recursos definidos con convenciones de nombres que hagan referencia a la API específica región. 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ífico de una 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 donde está conectado el adjunto de VLAN antes de descartarla para evitar el tráfico de región a región. Otro factor que debes considerar es que si usas la interconexión de socio, migrar la región puede ayudarte a seleccionar una ubicación física diferente para conectar tu VLAN adjuntos a Google Cloud. Esta consideración también es relevante si usas una Cloud VPN y decides cambiar las direcciones de subred en la migración: debes volver a configurar tus routers para que reflejen la nueva red.

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 superponerse con IPs, 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 planeas 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 pueden migrar de la manera más sencilla para reducir el esfuerzo y minimizar los riesgos. Para ayudarte a asegurarte de que todas las cargas de trabajo estén en un estado que permita una ruta de migración, te recomendamos que sigas 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 la configuración de red actual de los recursos que usan esa red. Un ejemplo de este producto es Cloud DNS, que te permite separar las IP de subred internas de las VMs.
  • Configura productos que admitan configuraciones 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 crear copias de seguridad o para lograr 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 migrar estos servicios, aunque es posible que debas ajustar algunas configuraciones.

Prepara tus recursos de procesamiento

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

Este documento se centra en los siguientes productos de computación de Google Cloud:

Compute Engine

Compute Engine es el servicio de Google Cloud que 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 herramientas 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 Cloud GPU), 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 de 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 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 (MIGs): Compute Engine te permite crear MIG regionales que aprovisionan de forma automática máquinas virtuales en varias zonas de una región automáticamente. 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: Una implementación administrada de la malla de Istio. Adoptar Cloud Service Mesh para tu clúster te permite tener un mayor nivel de control sobre el tráfico de red en el 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 si creas el clúster de GKE en la región nueva y lo agregas 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 hacia ellas de forma gradual, lo que te permite probar la implementación nueva mientras tienes la opción de revertir mediante la edición del enrutamiento de 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 sola fuente de información para configurar los clústeres. Puedes usar esta función de Sincronización 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 periódicamente 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 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 de Google 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 tener en cuenta el DNS y el balanceo de cargas en los entornos de Compute Engine cuando planifiques tu 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 multirregional y configuraciones 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 preparar una migración a otra región.

La presencia de los datos que ya están en Google Cloud simplifica la migración, ya que implica que existe una solución para alojarlos sin ninguna transformación o que se puede 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 Recuperación ante desastres (DR). Por esta razón, algunos de los patrones que se describen en este documento se basan en mecanismos de DR, como la copia de seguridad y recuperación de la base 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 desde 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 región a región.

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 que los datos de la instancia se repliquen 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, promocionarla 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 manejar la migración es mediante Database Migration Service, que te permite migrar bases de datos de SQL desde diferentes fuentes a Google Cloud. Entre las fuentes admitidas, 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 archivo compartido que se puede restablecer a otra región. Esta función se puede usar para realizar la migración de región a región.

Bigtable

Al igual que con Cloud SQL, Bigtable admite 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 con Filestore, Bigtable admite copias de seguridad y restablecimientos. 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 de 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, luego, los datos estarán disponibles para importarlos 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 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 mediante 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 tu 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 exactitud de las aplicaciones. Además de las pruebas de integración y unidades clásicas que se pueden realizar en aplicaciones recién migradas, 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 preserven 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 que la transición se supervise mejor y evite errores impredecibles del cliente.
  • Reversión: Según las estrategias adoptadas para migrar el tráfico, podría ser necesario implementar una reversión en caso de errores o configuración incorrecta del nuevo entorno. 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 lanzarla sin errores. Te recomendamos conservar las copias de seguridad de la primera región durante un tiempo limitado hasta que estés seguro de que no hay problemas en la región recién migrada.

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

Qué sigue

Colaboradores

Autor: Valerio Ponza | Asesor de soluciones técnicas

Otros colaboradores: