Diseña tus cargas de trabajo

Este documento te ayuda a diseñar cargas de trabajo de manera que se minimice el impacto de una expansión y migración futuras 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 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 aterrizaje existente. Antes de migrar cualquier carga de trabajo, debes tener una zona de destino. Si bien 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, otros factores, como la red o los datos, pueden requerir que planifiques la extensión. Tu proceso de reevaluación debe tener en cuenta los principales requisitos de tus cargas de trabajo para permitirte establecer una base genérica que se pueda especializar más adelante durante la migración.

Consideraciones empresariales

En lo que respecta a aspectos como los estándares, las reglamentaciones y las certificaciones de la industria y el Gobierno, la migración de cargas de trabajo a otra región puede tener diferentes 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 Google Cloud regiones 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 realices estas migraciones "en el país", es importante que vuelvas 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, probablemente 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 tal vez debas tener en cuenta:

  • Diseño de equipos: Algunas empresas se estructuran de manera que diferentes equipos se encarguen de diferentes recursos. Cuando una carga de trabajo se migra a otra región, debido al cambio en la estructura de los recursos, un equipo diferente puede ser el mejor candidato para ser responsable de ciertos recursos, en cuyo caso, los accesos deben ajustarse según corresponda.
  • Convenciones de nomenclatura: Si bien las convenciones de nomenclatura no tienen ningún impacto técnico en las funcionalidades, es posible que se requiera alguna consideración si hay recursos definidos con convenciones de nomenclatura que hacen 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 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 a la que está conectado el adjunto de VLAN antes de descartar esa región para evitar el tráfico de región a región. Otro factor que debes tener en cuenta es que, si usas 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 pertinente si usas una Cloud VPN y decides cambiar las direcciones de subred durante 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 las 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.

Si quieres obtener más información para 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 estés configurando tu infraestructura en Google Cloud y planees migrar a otra región más adelante, o que ya estés en Google Cloudy necesites migrar a otra región, debes asegurarte de que tus cargas de trabajo se puedan migrar de la manera más sencilla posible para reducir el esfuerzo y minimizar los riesgos. Para asegurarte de que todas las cargas de trabajo se encuentren en un estado que permita una ruta de migración, te recomendamos que sigas este 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 tipo de producto es Cloud DNS, que te permite desacoplar las IPs 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 usar servicios administrados con réplicas administradas entre regiones 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, generalmente con fines de copia de seguridad o alta disponibilidad. Esta función puede ser importante para migrar datos de una región a otra.

Algunos Google Cloud servicios están diseñados para admitir implementaciones multirregionales o implementaciones globales. No es necesario que migres 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 Cloudy los principios de diseño para preparar una migración a otra región.

En este documento, se abordan los siguientes productos de Google Cloud computación:

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 debes 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 ajuste de escala: 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 (MIG): Compute Engine te permite crear MIG regionales que aprovisionan automáticamente máquinas virtuales en varias zonas de una región. 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 para tu clúster te permite tener un mayor nivel de control sobre el tráfico de red hacia 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 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 nuevo clúster y enrutar el tráfico hacia ellas de forma gradual, lo que te permite probar la nueva implementación y, al mismo tiempo, tener la opción de revertir los cambios editando el 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 sola fuente de información para configurar los clústeres. Puedes usar esta función de 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 periódicas de los datos persistentes de tu clúster y restablecer los datos en el mismo clúster o en uno nuevo.

Cloud Run

Cloud Run ofrece un enfoque liviano 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 otra región.

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 laGoogle Cloud infraestructura de equipos físicos en Google Cloud ubicaciones, lo que incluye 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, 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 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 configuraciones de DNS y balanceo de cargas multirregión.

Prepara tus recursos de almacenamiento de datos

En esta sección, se proporciona una descripción general de los recursos de almacenamiento de datos enGoogle 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 otra región 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 otra región para realizar copias 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 función de replicación entre regiones que permite replicar los datos de la instancia en otra región. 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 promover 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, promoverla 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 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 una región diferente, pero no a un proyecto diferente.

Filestore

Como se explicó anteriormente 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 en otra región. Esta función se puede usar para realizar migraciones de una región a otra.

Bigtable

Al igual que con Cloud SQL, Bigtable admite la replicación. Puedes usar esta función para replicar el mismo patrón descrito. Comprueba 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 copias de seguridad y restablecimientos. Al igual que con Filestore, esta función se puede usar para implementar la migración creando una copia de seguridad y restableciéndola en otra instancia de la nueva región.

La última opción es exportar tablas, por ejemplo, a Cloud Storage. En estas exportaciones, se alojarán los datos en otro servicio, y luego 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 trasladar 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 sencilla 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 tener en cuenta lo siguiente antes de retirar el entorno de origen:

  • Pruebas de 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 de integración y de unidad clásicas que se pueden realizar en las aplicaciones recién migradas, existen 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. Otro enfoque es replicar el tráfico entrante en el entorno de origen y en el nuevo entorno para verificar que se conserven 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 adopción de un tiempo de inactividad planificado. El tiempo de inactividad permite supervisar mejor la transición y evitar errores imprevistos del lado del cliente.
  • Reversión: Según las estrategias adoptadas para migrar el tráfico, es posible que sea necesario implementar una reversión en caso de errores o mala configuración 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 región nueva y comenzar a operar en la región nueva 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 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 de recuperación ante desastres.

Qué sigue

Colaboradores

Autor: Valerio Ponza | Asesor de soluciones técnicas

Otros colaboradores: