Implementación multirregional en Compute Engine

Last reviewed 2024-02-20 UTC

En este documento, se proporciona una arquitectura de referencia para una aplicación de varios niveles que se ejecuta en las VMs de Compute Engine en varias regiones de Google Cloud. En el documento, también se proporciona orientación para ayudarte a compilar una arquitectura que use otros servicios de infraestructura de Google Cloud. Se describen los factores de diseño que debes tener en cuenta cuando compilas una arquitectura multirregional para tus aplicaciones en la nube. El público objetivo para este documento son los arquitectos de la nube.

Arquitectura

En la Figura 1, se muestra una arquitectura para una aplicación que se ejecuta en modo activo-activo en pilas aisladas que se implementan en dos regiones de Google Cloud. En cada región, la aplicación se ejecuta de forma independiente en tres zonas. La arquitectura está alineada con el arquetipo de implementación multirregional, lo que garantiza que la topología de Google Cloud sea sólida contra las interrupciones regionales y zonales, y proporciona baja disponibilidad para los usuarios de aplicaciones.

Arquitectura multirregional con un balanceador de cargas global

Figura 1. Un balanceador de cargas global enruta las solicitudes de usuario a pilas de aplicaciones aisladas de forma regional.

La arquitectura se basa en el modelo de nube como infraestructura como servicio (IaaS). Aprovisionas los recursos de infraestructura necesarios (procesamiento, herramientas de redes y almacenamiento) en Google Cloud, y conservas el control total y la responsabilidad del sistema operativo, el middleware y las capas superiores de la pila de aplicaciones. Para obtener más información sobre IaaS y otros modelos de nube, consulta PaaS en comparación con IaaS o SaaS frente a CaaS: ¿En qué se diferencian?

En el diagrama anterior, se incluyen los siguientes componentes:

Componente Purpose
Balanceador de cargas externo global

El balanceador de cargas externo global recibe y distribuye solicitudes de usuario a la aplicación. El balanceador de cargas externo global anuncia una sola dirección IP anycast, pero se implementa como una gran cantidad de proxies en Google Front End (GFE). Las solicitudes del cliente se dirigen al GFE más cercano al cliente.

Según tus requisitos, puedes usar un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de red de proxy externo global. Para obtener más información, consulta Cómo elegir un balanceador de cargas.
Grupos de instancias administrados (MIG) regionales para el nivel web

El nivel web de la aplicación se implementa en las VMs de Compute Engine que forman parte de los MIG regionales. Estos MIG son los backends para el balanceador de cargas global.

Cada MIG contiene VMs de Compute Engine en tres zonas diferentes. Cada una de estas VMs aloja una instancia independiente del nivel web de la aplicación.
Balanceadores de cargas internos regionales

El balanceador de cargas interno en cada región distribuye el tráfico de las VMs de nivel web a las VMs de nivel de aplicación en esa región.

Según tus requisitos, puedes usar un balanceador de cargas de aplicaciones o un balanceador de cargas de red interno regional. Para obtener más información, consulta Cómo elegir un balanceador de cargas.
MIG regionales para el nivel de aplicación

El nivel de la aplicación se implementa en las VMs de Compute Engine que forman parte de los MIG regionales. El MIG en cada región es el backend para el balanceador de cargas interno en esa región.

Cada MIG contiene VMs de Compute Engine en tres zonas diferentes. Cada VM aloja una instancia independiente del nivel de la aplicación.
Base de datos externa implementada en las VMs de Compute Engine

Una base de datos externa (como PostgreSQL) se implementa en las VMs de Compute Engine en las dos regiones. Puedes configurar la replicación entre regiones para las bases de datos y configurarlas en cada región para que se trasladen a la base de datos de la otra región. Las funciones de replicación y de conmutación por error dependen de la base de datos que uses.

Instalar y administrar una base de datos de terceros implica un esfuerzo adicional y un costo operativo para replicar, aplicar actualizaciones, supervisar y garantizar la disponibilidad. Puedes evitar la sobrecarga de instalar y administrar una base de datos de terceros y aprovechar las funciones integradas de alta disponibilidad (HA) mediante una base de datos completamente administrada, como una multirregión Instancia de Spanner
Red de nube privada virtual y subredes Todos los recursos de Google Cloud en la arquitectura usan una sola red de VPC que tiene subredes en dos regiones diferentes.
Buckets de región doble de Cloud Storage Las copias de seguridad de los datos de la aplicación se almacenan en buckets de Cloud Storage birregionales. De forma alternativa, puedes usar el servicio de copia de seguridad y DR para crear, almacenar y administrar las copias de seguridad de la base de datos.

Casos de uso

En esta sección, se describen casos de uso para los que una implementación multirregional en Compute Engine es una opción adecuada.

Migración eficiente de aplicaciones locales

Puedes usar esta arquitectura de referencia para compilar una topología de Google Cloud para volver a alojar (lift-and-shift) aplicaciones locales en la nube con cambios mínimos en las aplicaciones. Todos los niveles de la aplicación en esta arquitectura de referencia se alojan en las VMs de Compute Engine. Este enfoque te permite migrar las aplicaciones locales de manera eficiente a la nube y aprovechar los beneficios, la confiabilidad, el rendimiento y la simplicidad operativa que proporciona Google Cloud.

Alta disponibilidad para usuarios de distintas ubicaciones geográficas

Recomendamos una implementación multirregional para aplicaciones que son fundamentales para la empresa y en las que la alta disponibilidad y la solidez contra las interrupciones regionales son esenciales. Si una región deja de estar disponible por algún motivo (incluso una interrupción a gran escala causada por un desastre natural), los usuarios de la aplicación no experimentan ningún tiempo de inactividad. El tráfico se enruta a la aplicación en las otras regiones disponibles. Si los datos se replican de forma síncrona, el objetivo de tiempo de recuperación (RTO) es cercano a cero.

Latencia baja para usuarios de aplicaciones

Si tus usuarios están dentro de un área geográfica específica, como un continente, puedes usar una implementación multirregional para lograr un equilibrio óptimo entre la disponibilidad y el rendimiento. Cuando una de las regiones tiene una interrupción, el balanceador de cargas global envía solicitudes que se originan en esa región a otra. Los usuarios no perciben un impacto significativo del rendimiento porque las regiones se encuentran dentro de un área geográfica.

Alternativa de diseño

Una arquitectura que usa un balanceador de cargas global (figura 1) admite ciertas funciones que te ayudan a mejorar la confiabilidad de tus implementaciones, como el almacenamiento en caché perimetral a través del uso de Cloud CDN. En esta sección, se presenta una arquitectura alternativa que usa balanceadores de cargas regionales y Cloud DNS, como se muestra en la figura 2. Esta arquitectura alternativa admite las siguientes funciones adicionales:

  • Finalización de la seguridad de la capa de transporte (TLS) en regiones específicas
  • Capacidad de entregar contenido de la región que especifiques. Sin embargo, es posible que esa región no sea la mejor rendimiento en un momento determinado
  • Una variedad más amplia de protocolos de conexión si usas un balanceador de cargas de red de transferencia

Para obtener más información sobre las diferencias entre los balanceadores de cargas regionales y globales, consulta la siguiente documentación:

Arquitectura multirregional con balanceadores de cargas y DNS regionales.

Figura 2. Cloud DNS enruta las solicitudes de los usuarios a balanceadores de cargas regionales.

Al igual que la arquitectura en la figura 1, la arquitectura en la figura 2 es sólida contra las interrupciones zonales y regionales. Una zona pública de Cloud DNS enruta las solicitudes de los usuarios a la región adecuada. Los balanceadores de cargas externos regionales reciben solicitudes de los usuarios y las distribuyen en las instancias de nivel web de la aplicación dentro de cada región. Los otros componentes de esta arquitectura son idénticos a los componentes de la arquitectura basada en balanceadores de cargas globales.

Consideraciones del diseño

En esta sección, se proporciona orientación para ayudarte a usar esta arquitectura de referencia para desarrollar una arquitectura que cumpla con los requisitos específicos del diseño, la seguridad y el cumplimiento, la confiabilidad, la eficiencia operativa, el costo y el rendimiento del sistema.

Diseño de sistemas

En esta sección, se proporciona orientación para que puedas elegir las regiones de Google Cloud para tu implementación multirregional y seleccionar los servicios de Google Cloud adecuados.

Selección de región

Cuando elijas las regiones de Google Cloud en las que se deben implementar tus aplicaciones, ten en cuenta los siguientes factores y requisitos:

  • Disponibilidad de los servicios de Google Cloud en cada región. Para obtener más información, consulta Productos disponibles por ubicación
  • Disponibilidad de los tipos de máquinas de Compute Engine en cada región. Para obtener más información, consulta Regiones y zonas
  • Requisitos de la latencia del usuario final
  • Costo de los recursos de Google Cloud
  • Costos de transferencia de datos interregionales
  • Requisitos reglamentarios

Algunos de estos factores y requisitos pueden incluir compensaciones. Por ejemplo, es posible que la región más rentable no tenga la huella de carbono más baja.

Servicios de Compute

La arquitectura de referencia de este documento usa VMs de Compute Engine para todos los niveles de la aplicación. Según los requisitos de tu aplicación, puedes elegir entre otros servicios de procesamiento de Google Cloud:

La decisión de usar VMs, contenedores o servicios sin servidores implica un equilibrio entre la flexibilidad de la configuración y el esfuerzo de administración. Las VMs y los contenedores proporcionan más flexibilidad de configuración, pero eres responsable de administrar los recursos. En una arquitectura sin servidores, implementas las cargas de trabajo en una plataforma preconfigurada que requiere un esfuerzo de administración mínimo. Si quieres obtener más información para elegir los servicios de procesamiento adecuados para tus cargas de trabajo en Google Cloud, consulta Hosting de aplicaciones en Google Cloud en el framework de arquitectura de Google Cloud.

Servicios de almacenamiento

Las arquitecturas que se muestran en este documento usan volúmenes de discos persistentes regionales para todos los niveles. Los discos persistentes proporcionan una replicación síncrona de datos en dos zonas dentro de una región.

Otras opciones de almacenamiento para implementaciones multirregionales incluyen los buckets multirregionales o birregionales de Cloud Storage. Los objetos almacenados en un bucket birregional o multirregional se almacenan de manera redundante en al menos dos lugares geográficos separados. Los metadatos se escriben de forma síncrona en todas las regiones, y los datos se replican de forma asíncrona. En el caso de los buckets birregionales, puedes usar la replicación turbo, que garantiza que los objetos se repliquen en pares de regiones, con un objetivo de punto de recuperación (RPO) de 15 minutos. Para obtener más información, consulta Disponibilidad y durabilidad de los datos.

Para almacenar datos que se comparten en varias VMs en una región, como todas las VMs en el nivel web o en el nivel de la aplicación, puedes usar una instancia de Filestore Enterprise. Los datos que almacenas en una instancia de Filestore Enterprise se replican de forma síncrona en tres zonas dentro de la región. Esta replicación garantiza la alta disponibilidad y la solidez contra las interrupciones de zona. Puedes almacenar archivos de configuración compartidos, herramientas y utilidades comunes y registros centralizados en la instancia de Filestore, y activar la instancia en varias VMs.

Si tu base de datos es Microsoft SQL Server, puedes implementar una instancia de clúster de conmutación por error (FCI) y usar los volúmenes de NetApp de Google Cloud completamente administrados para proporcionar almacenamiento SMB de disponibilidad continua (CA) para la base de datos.

Cuando diseñes el almacenamiento para tus cargas de trabajo multirregionales, considera las características funcionales de las cargas de trabajo, los requisitos de la resiliencia, las expectativas de rendimiento y los objetivos de costos. Si quieres obtener más información, consulta Diseña una estrategia de almacenamiento óptima para tu carga de trabajo en la nube.

Servicios de base de datos

En la arquitectura de referencia de este documento, se usa una base de datos de terceros, como PostgreSQL, que se implementa en las VMs de Compute Engine. Instalar y administrar una base de datos de terceros implica esfuerzo y costos para las operaciones, como aplicar actualizaciones, supervisar y garantizar la disponibilidad, realizar copias de seguridad y recuperarse de las fallas.

Puedes evitar el esfuerzo y el costo de instalar y administrar una base de datos de terceros a través de un servicio de base de datos completamente administrado como Cloud SQL, AlloyDB para PostgreSQL, Bigtable, Spanner o Firestore. Estos servicios de base de datos de Google Cloud proporcionan Acuerdos de Nivel de Servicio (ANS) de tiempo de actividad e incluyen capacidades predeterminadas de escalabilidad y observabilidad. Si tus cargas de trabajo requieren una base de datos de Oracle, puedes usar la solución Bare Metal que proporciona Google Cloud. Para obtener una descripción general de los casos de uso para los que es adecuado cada servicio de base de datos de Google Cloud, consulta Bases de datos de Google Cloud.

Cuando elijas y configures la base de datos para una implementación multirregional, ten en cuenta los requisitos de tu aplicación para la coherencia de los datos entre regiones y ten en cuenta las compensaciones de rendimiento y costo.

  • Si la aplicación requiere una coherencia sólida (todos los usuarios deben leer los mismos datos en todo momento), los datos deben replicarse de forma síncrona en todas las regiones de la arquitectura. Sin embargo, la replicación síncrona puede generar un mayor costo y una disminución del rendimiento, ya que cualquier dato que se escribe debe replicarse en tiempo real en todas las regiones antes de que los datos estén disponibles para las operaciones de lectura.
  • Si tu aplicación puede tolerar la coherencia eventual, puedes replicar los datos de forma asíncrona. Esto puede ayudar a mejorar el rendimiento porque los datos no necesitan replicarse de forma síncrona en todas las regiones. Sin embargo, los usuarios en regiones diferentes pueden leer datos diferentes porque es posible que los datos no se hayan replicado por completo en el momento de la solicitud.

Seguridad y cumplimiento

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar y compilar una topología multirregional en Google Cloud que cumpla con los requisitos de seguridad y cumplimiento de las cargas de trabajo.

Protección contra amenazas

Para proteger tu aplicación contra amenazas como los ataques de denegación de servicio distribuido (DSD) y las secuencias de comandos entre sitios (XSS), puedes usar las políticas de seguridad de Google Cloud Armor. Cada política es un conjunto de reglas que especifican ciertas condiciones que se deben evaluar y las acciones que se deben realizar cuando se cumplen las condiciones. Por ejemplo, una regla podría especificar que si la dirección IP de origen del tráfico entrante coincide con una dirección IP o un rango de CIDR en particular, se debe denegar el tráfico. Además, puedes aplicar reglas de firewall de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta Descripción general de las políticas de seguridad.

Acceso externo para las VMs

En la arquitectura de referencia que se describe en este documento, las VMs que alojan el nivel de la aplicación, el nivel web y las bases de datos no necesitan acceso entrante desde Internet. No asignes direcciones IP externas a esas VMs. Los recursos de Google Cloud que solo tienen una dirección IP interna privada pueden acceder a ciertas APIs y servicios de Google a través de Private Service Connect o el Acceso privado a Google. Si quieres obtener más información, consulta Opciones de acceso privado a los servicios.

Para habilitar las conexiones salientes seguras desde recursos de Google Cloud que solo tienen direcciones IP privadas, como las VMs de Compute Engine en esta arquitectura de referencia, puedes usar Cloud NAT.

Seguridad de imágenes de VM

Para garantizar que tus VMs solo usen imágenes aprobadas (es decir, imágenes con software que cumpla con tus requisitos de seguridad o políticas), puedes definir una política de la organización que restrinja el uso de imágenes en proyectos de imagen pública específicos. Para obtener más información, consulta Configura políticas de imágenes confiables.

Privilegios de la cuenta de servicio

En los proyectos de Google Cloud en los que la API de Compute Engine está habilitada, se crea una cuenta de servicio predeterminada de forma automática. A la cuenta de servicio predeterminada se le otorga la función de IAM de editor (roles/editor), a menos que este comportamiento esté inhabilitado. De forma predeterminada, la cuenta de servicio predeterminada se conecta a todas las VMs que creas con Google Cloud CLI o la consola de Google Cloud. La función de editor incluye una amplia gama de permisos, por lo que conectar la cuenta de servicio predeterminada a las VMs crea un riesgo de seguridad. Para evitar este riesgo, puedes crear y usar cuentas de servicio dedicadas para cada aplicación. Para especificar los recursos a los que puede acceder la cuenta de servicio, usa políticas detalladas. Si quieres obtener más información, consulta Limita los privilegios de la cuenta de servicio en “Prácticas recomendadas para usar cuentas de servicio”.

Consideraciones sobre la residencia de los datos

Puedes usar balanceadores de cargas regionales para compilar una arquitectura multirregional que te ayude a cumplir con los requisitos de residencia de datos. Por ejemplo, un país en Europa puede requerir que todos los datos del usuario se almacenen y se acceda a ellos en centros de datos ubicados físicamente en Europa. Para cumplir con este requisito, puedes usar la arquitectura regional basada en el balanceador de cargas en la figura 2. En esa arquitectura, la aplicación se ejecuta en regiones de Google Cloud en Europa y usas Cloud DNS con una política de enrutamiento geovallado para enrutar el tráfico a través de balanceadores de cargas regionales. Para cumplir con los requisitos de residencia de datos del nivel de la base de datos, usa una arquitectura fragmentada en lugar de la replicación entre regiones. Con este enfoque, los datos en cada región están aislados, pero no puedes implementar alta disponibilidad y conmutación por error entre regiones para la base de datos.

Más consideraciones de seguridad

Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de la plataforma que se proporcionan en el plano sobre las bases de seguridad.

Confiabilidad

En esta sección, se describen los factores de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para compilar y operar una infraestructura confiable para tus implementaciones multirregionales en Google Cloud.

Ajuste de escala automático de MIG

Cuando ejecutas tu aplicación en varios MIG regionales, la aplicación permanece disponible durante las interrupciones de zonas aisladas o las interrupciones regionales. La capacidad de ajuste de escala automático de los MIG sin estado te permite mantener la disponibilidad y el rendimiento de la aplicación en niveles predecibles. Para controlar el comportamiento del ajuste de escala automático de tus MIG sin estado, puedes especificar las métricas de uso objetivo, como el uso de CPU promedio. También puedes configurar el ajuste de escala automático basado en programas para MIG sin estado. Los MIG con estado no pueden realizar un ajuste de escala automático. Si quieres obtener más información, consulta Ajuste de escala automático para grupos de instancias.

Reparación automática de VMs

A veces, las VMs que alojan tu aplicación pueden estar en ejecución y disponibles, pero puede haber problemas con la aplicación. Puede congelarse, fallar o no tener suficiente memoria. Para verificar si una aplicación responde como se espera, puedes configurar las verificaciones de estado basadas en aplicaciones como parte de la política de reparación automática de los MIG. Si la aplicación en una VM en particular no responde, el MIG repara automáticamente (remedia) la VM. Para obtener más información sobre la configuración de la reparación automática, consulta Configura una verificación de estado y una reparación automática de la aplicación.

Ubicación de las VMs

En la arquitectura que se describe en este documento, el nivel de aplicación y el nivel web se ejecutan en las VMs de Compute Engine que se distribuyen en varias zonas. Esta distribución garantiza que la aplicación sea sólida contra las interrupciones zonales. Para mejorar aún más esta solidez, puedes crear una política de posición distribuida y aplicarla a la plantilla de MIG. Cuando el MIG crea VMs, las ubica dentro de cada zona en diferentes servidores físicos (llamados hosts), por lo que tus VMs son sólidas frente a fallas de hosts individuales. Para obtener más información, consulta Aplica políticas de posición de distribución a las VMs.

Planificación de la capacidad de las VMs

Para asegurarte de que la capacidad de las VMs de Compute Engine esté disponible cuando sea necesario, puedes crear reservas. Una reserva proporciona capacidad garantizada en una zona específica para una cantidad específica de VMs de un tipo de máquina que elijas. Una reserva puede ser específica de un proyecto o compartirse en varios proyectos. Para obtener más información sobre las reservas, incluidas las consideraciones de facturación, consulta Reservas de recursos zonales de Compute Engine.

Estado de disco persistente

Una práctica recomendada en el diseño de aplicaciones es evitar la necesidad de discos locales con estado. Pero si el requisito existe, puedes configurar tus discos persistentes para que tengan estado para garantizar que los datos se conserven cuando las VMs se reparen o se vuelvan a crear. Sin embargo, te recomendamos que mantengas los discos de arranque sin estado para que puedas actualizarlos fácilmente a las imágenes más recientes con versiones y parches de seguridad nuevos. Para obtener más información, consulta Configura discos persistentes con estado en MIG.

Durabilidad de los datos

Puedes usar Backup and DR para crear, almacenar y administrar copias de seguridad de las VMs de Compute Engine. La copia de seguridad y la DR almacenan datos de copia de seguridad en su formato original legible para la aplicación. Cuando sea necesario, puedes restablecer las cargas de trabajo a producción directamente a través del uso de datos de almacenamiento de copia de seguridad a largo plazo sin mucho tiempo de movimiento de datos o actividades de preparación.

Para almacenar copias de seguridad de bases de datos y registros de transacciones, puedes usar depósitos de Cloud Storage regionales, que proporcionan el almacenamiento de copia de seguridad de menor costo redundante en todas las zonas.

Compute Engine proporciona las siguientes opciones para ayudarte a garantizar la durabilidad de los datos almacenados en los volúmenes de Persistent Disk:

  • Puedes usar instantáneas estándar para capturar el estado de los volúmenes de Persistent Disk en un momento determinado. Las instantáneas se almacenan de forma redundante en varias regiones, con sumas de verificación automáticas para garantizar la integridad de tus datos. Las instantáneas son incrementales de forma predeterminada, por lo que usan menos espacio de almacenamiento y ahorras dinero. Las instantáneas se almacenan en una ubicación de Cloud Storage que puedes configurar. Para obtener más recomendaciones sobre el uso y la administración de instantáneas, consulta Prácticas recomendadas para instantáneas de discos de Compute Engine.
  • Los volúmenes de discos persistentes regionales te permiten ejecutar aplicaciones con alta disponibilidad que no se ven afectadas por fallas en los discos persistentes. Cuando creas un volumen de disco persistente regional, Compute Engine mantiene una réplica del disco en una zona diferente dentro de la misma región. Los datos se replican de forma síncrona en los discos en ambas zonas. Si alguna de las dos zonas tiene una interrupción, los datos permanecen disponibles.

Disponibilidad de la base de datos

Para implementar la conmutación por error entre zonas de la base de datos en cada región, necesitas un mecanismo para identificar las fallas de la base de datos principal y un proceso de conmutación por error a la base de datos en espera. Los detalles del mecanismo de conmutación por error dependen de la base de datos que usas. Puedes configurar una instancia de observador para detectar fallas de la base de datos principal y organizar la conmutación por error. Debes configurar las reglas de conmutación por error de forma adecuada para evitar una situación de cerebro dividido y evitar una conmutación por error innecesaria. Para conocer ejemplos de arquitecturas que puedes usar para implementar la conmutación por error para las bases de datos de PostgreSQL, consulta Arquitecturas para la alta disponibilidad de los clústeres de PostgreSQL en Compute Engine.

Más consideraciones de confiabilidad

Cuando compiles la arquitectura de nube para tu carga de trabajo, revisa las prácticas recomendadas y las recomendaciones relacionadas con la confiabilidad que se proporcionan en la siguiente documentación:

Optimización de costos

En esta sección, se proporciona orientación para optimizar el costo de configurar y operar una topología de Google Cloud multirregional que compilas a través de esta arquitectura de referencia.

Tipos de máquinas de VMs

Para ayudarte a optimizar el uso de los recursos de tus instancias de VM, Compute Engine proporciona recomendaciones sobre los tipos de máquinas. Usa las recomendaciones para elegir los tipos de máquinas que coincidan con los requisitos de procesamiento de tu carga de trabajo. Para cargas de trabajo con requisitos de recursos predecibles, puedes personalizar el tipo de máquina según tus necesidades y ahorrar dinero a través de los tipos personalizados de máquinas.

Modelo de aprovisionamiento de VM

Si tu aplicación es tolerante a errores, las VMs Spot pueden ayudarte a reducir los costos de Compute Engine para las VMs en los niveles de aplicación y la Web. El costo de las VMs Spot es significativamente menor que las VMs normales. Sin embargo, Compute Engine podría detener o borrar las VMs Spot de forma preventiva para recuperar capacidad. Las VMs Spot son adecuadas para trabajos por lotes que pueden tolerar la interrupción y no tienen requisitos de alta disponibilidad. Las VMs Spot ofrecen los mismos tipos de máquinas, opciones y rendimiento que las VMs normales. Sin embargo, cuando la capacidad de recursos en una zona es limitada, es posible que los MIG no puedan escalar horizontalmente (es decir, crear VMs) de forma automática al tamaño objetivo especificado hasta que la capacidad requerida vuelva a estar disponible.

Uso de recursos

La capacidad de ajuste de escala automático de los MIG sin estado permite que tu aplicación maneje los aumentos de tráfico con facilidad y te ayuda a reducir los costos cuando la necesidad de recursos es baja. Los MIG con estado no pueden realizar un ajuste de escala automático.

Licencias de terceros

Cuando migras cargas de trabajo de terceros a Google Cloud, es posible que puedas reducir los costos si usas licencias adquiridas por el usuario (BYOL). Por ejemplo, para implementar VMs de Microsoft Windows Server, en lugar de usar una imagen premium que genere un costo adicional por la licencia de terceros, puedes crear y usar una imagen de BYOL de Windows personalizada. Solo pagas por la infraestructura de VM que usas en Google Cloud. Esta estrategia te ayuda a descubrir el valor de tus inversiones existentes en licencias de terceros. Si decides usar el enfoque BYOL, te recomendamos que hagas lo siguiente:

  • Aprovisiona la cantidad necesaria de núcleos de CPU de procesamiento sin importar la memoria a través de tipos personalizados de máquinas. De esta manera, limitas el costo de las licencias externas a la cantidad de núcleos de CPU que necesitas.
  • Reduce la cantidad de CPU virtuales por núcleo de 2 a 1 a través de la inhabilitación de los multiprocesos simultáneos (SMT) y reduce tus costos de licencia en un 50%.

Más consideraciones de los costos

Cuando compiles la arquitectura de tu carga de trabajo, también considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Framework de la arquitectura de Google Cloud: Optimización de costos.

Eficiencia operativa

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar y compilar una topología de Google Cloud multirregional que puedas operar de manera eficiente.

Actualizaciones de la configuración de VMs

Para actualizar la configuración de las VMs en un MIG (como el tipo de máquina o la imagen de disco de arranque), debes crear una plantilla de instancias nueva con la configuración necesaria y, luego, aplicar la plantilla nueva al MIG. El MIG actualiza las VMs a través del método de actualización que elijas: automático o selectivo. Elige un método adecuado en función de tus requisitos de disponibilidad y eficiencia operativa. Para obtener más información sobre estos métodos de actualización de MIG, consulta Aplica una configuración de VM nueva en un MIG.

Imágenes de VM

Para las plantillas de instancias de MIG, en lugar de usar imágenes públicas que proporciona Google, te recomendamos que crees y uses imágenes personalizadas que contengan la configuración y el software que requieren tus aplicaciones. Puedes agrupar tus imágenes personalizadas en una familia de imágenes personalizada. Una familia de imágenes siempre apunta a la imagen más reciente de esa familia para que tus plantillas de instancias y secuencias de comandos puedan usarla sin que tengas que actualizar las referencias a una versión de imagen específica.

Plantillas de instancias deterministas

Si las plantillas de instancias que usas para tus MIG incluyen secuencias de comandos de inicio para instalar software de terceros, asegúrate de que las secuencias de comandos especifiquen de forma explícita parámetros de instalación de software, como la versión del software. De lo contrario, cuando el MIG crea las VMs, es posible que el software instalado en las VMs no sea coherente. Por ejemplo, si tu plantilla de instancias incluye una secuencia de comandos de inicio para instalar Apache HTTP Server 2.0 (el paquete apache2), asegúrate de que la secuencia de comandos especifique la versión apache2 exacta que se debe instalar, como la versión 2.4.53. Para obtener más información, consulta Plantillas de instancias determinísticas.

Más consideraciones operativas

Cuando compiles la arquitectura de tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales para la eficiencia operativa que se describen en Framework de la arquitectura de Google Cloud: Excelencia operativa.

Optimización del rendimiento

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar y compilar una topología multirregional en Google Cloud que cumpla con los requisitos de rendimiento de las cargas de trabajo.

Ubicación de las VMs

Para las cargas de trabajo que requieren una baja latencia de red entre VMs, puedes crear una política de posición compacta y aplicarla a la plantilla de MIG. Cuando el MIG crea las VMs, las coloca en servidores físicos que están cerca. Para obtener más información, consulta Reduce la latencia con las políticas de colocación compacta.

Tipos de máquinas de VMs

Compute Engine ofrece una amplia variedad de tipos predefinidos y personalizables de máquinas que puedes elegir según tus requisitos de costo y rendimiento. Los tipos de máquinas se agrupan en familias y series de máquinas. En la siguiente tabla, se proporciona un resumen de las series y familias de máquinas recomendadas para diferentes tipos de cargas de trabajo:

Requisito Familia de máquinas recomendada Ejemplo de serie de máquinas
Mejor relación precio-rendimiento en una variedad de cargas de trabajo Familia de máquinas de uso general C3, C3D, E2, N2, N2D, Tau T2D y Tau T2A
Mayor rendimiento por núcleo y optimizado para cargas de trabajo de procesamiento intensivo Familia de máquinas optimizada para procesamiento C2, C2D y H3
Proporción alta de memoria a CPU virtual para cargas de trabajo que requieren mucha memoria Familia de máquinas con optimización de memoria M3, M2 y M1
GPU para cargas de trabajo paralelizadas de forma masiva Familia de máquinas con optimización de acelerador A2 y G2

Para obtener más información, consulta la guía de comparación y recurso de familias de máquinas.

Subprocesos múltiples de VMs

Cada CPU virtual que asignas a una VM de Compute Engine se implementa como un solo subproceso de hardware único. De forma predeterminada, dos CPU virtuales comparten un núcleo de CPU física. Para cargas de trabajo que son muy paralelas o que realizan cálculos de punto flotante (como el análisis de secuencias genéticas y el modelado de riesgo financiero), puedes mejorar el rendimiento si reduces la cantidad de subprocesos que se ejecutan en cada CPU física. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.

Niveles de servicio de red

Los niveles de servicio de red te permiten optimizar el costo de red y el rendimiento de las cargas de trabajo. Puedes elegir entre los siguientes niveles:

  • El nivel Premium usa la red troncal global de alta confiabilidad de Google para ayudarte a lograr una pérdida de paquetes y una latencia mínima. El tráfico entra y sale de la red de Google en un punto de presencia (PoP) perimetral global más cercano al ISP de tu usuario final. Recomendamos usar el nivel Premium como nivel predeterminado para obtener un rendimiento óptimo. El nivel Premium admite direcciones IP externas regionales y también globales para las VMs y los balanceadores de cargas.
  • El nivel Estándar solo está disponible para los recursos que usan direcciones IP externas regionales. El tráfico ingresa y sale de la red de Google en un PoP perimetral más cercano a la región en la que se ejecuta tu carga de trabajo de Google Cloud. Los precios del nivel Estándar son más bajos que el nivel Premium. El nivel Estándar es adecuado para el tráfico que no es sensible a la pérdida de paquetes y que no tiene requisitos de latencia baja.

Almacenamiento en caché

Si tu aplicación entrega elementos de sitios web estáticos y si tu arquitectura incluye un balanceador de cargas de aplicaciones externo global (como se muestra en la figura 1), puedes usar Cloud CDN para almacenar en caché contenido estático al que se accede de forma periódica más cerca de tus usuarios Cloud CDN puede ayudar a mejorar el rendimiento para los usuarios, reducir el uso de los recursos de la infraestructura en el backend y los costos de entrega de la red. Si quieres obtener más información, consulta Rendimiento web más rápido y mayor protección web para el balanceo de cargas.

Más consideraciones sobre el rendimiento

Cuando compiles la arquitectura para tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Framework de la arquitectura de Google Cloud: Optimización del rendimiento.

Próximos pasos

Colaboradores

Autor: Kumar Dhanagopal | Desarrollador de soluciones entre productos

Otros colaboradores: