Implementación de zona única en Compute Engine

Last reviewed 2024-02-08 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 una sola zona de Google Cloud. Puedes usar esta arquitectura de referencia para volver a alojar (lift-and-shift) aplicaciones locales en la nube de forma eficiente con cambios mínimos en las aplicaciones. En el documento, también se describen los factores de diseño que debes tener en cuenta cuando compilas una arquitectura zonal para tus aplicaciones en la nube. El público objetivo para este documento son los arquitectos de la nube.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura para una aplicación que se ejecuta en una sola zona de Google Cloud. Esta arquitectura está alineada con el arquetipo de implementación zonal de Google Cloud.

Arquitectura de zona única con Compute Engine.

La arquitectura se basa en el modelo de nube como infraestructura como servicio (IaaS). Debes aprovisionar los recursos de infraestructura necesarios (procesamiento, herramientas de redes y almacenamiento) en Google Cloud. Conservas el control total sobre la infraestructura 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 Objetivo
Balanceador de cargas regional externo

El balanceador de cargas externo regional recibe y distribuye las solicitudes del usuario a las VMs de nivel web.

Usa un tipo de balanceador de cargas adecuado según el tipo de tráfico y otros requisitos. Por ejemplo, si el backend consta de servidores web (como se muestra en la arquitectura anterior), usa un balanceador de cargas de aplicaciones para reenviar el tráfico HTTP(S). Para balancear las cargas del tráfico de TCP, usa un balanceador de cargas de red. Para obtener más información, consulta Cómo elegir un balanceador de cargas.

Grupo de instancias administrado (MIG) regional para el nivel web El nivel web de la aplicación se implementa en las VMs de Compute Engine que forman parte de un MIG zonal. El MIG es el backend del balanceador de cargas externo regional. Cada VM en el MIG aloja una instancia independiente del nivel web de la aplicación.
Balanceador de cargas interno regional

El balanceador de cargas interno regional distribuye el tráfico desde las VMs de nivel web hasta las VMs del nivel de la aplicació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 zonal para el nivel de la aplicación El nivel de la aplicación se implementa en las VMs de Compute Engine que forman parte de un MIG zonal, que es el backend del balanceador de cargas interno. Cada VM en el MIG aloja una instancia independiente del nivel de la aplicación.
Base de datos de terceros implementada en una VM de Compute Engine

En la arquitectura de este documento, se muestra una base de datos de terceros (como PostgreSQL) que se implementa en una VM de Compute Engine. Puedes implementar una base de datos en espera en otra zona. 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 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) con un servicio de base de datos completamente administrado, como Cloud SQL o AlloyDB para PostgreSQL. Para obtener más información sobre las opciones de bases de datos administradas, consulta Servicios de base de datos.

Red de nube privada virtual y subred

Todos los recursos de Google Cloud en la arquitectura usan una sola red de VPC y subred.

Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes de VPC o varias subredes. Para obtener más información, consulta Decide si crear o no varias redes de VPC en “Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC”.

Cloud Storage (bucket regional)

Las copias de seguridad de las aplicaciones y las bases de datos se almacenan en un bucket regional de Cloud Storage. Si se produce una interrupción zonal, la aplicación y los datos no se pierden.

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.

Productos usados

En esta arquitectura de referencia, se usan los siguientes productos de Google Cloud:

  • Compute Engine: Un servicio de procesamiento seguro y personalizable que te permite crear y ejecutar VMs en la infraestructura de Google.
  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
  • Cloud Storage: Un depósito de objetos de bajo costo y sin límites para varios tipos de datos. Se puede acceder a los datos desde y hacia Google Cloud, y estos se replican en las ubicaciones para aumentar la redundancia.
  • Nube privada virtual: Un sistema virtual que proporciona funcionalidad de red global y escalable para tus cargas de trabajo de Google Cloud.

Casos de uso

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

  • Desarrollo y pruebas en la nube: Puedes usar una arquitectura de implementación de una sola zona que te permita compilar un entorno de nube de bajo costo para el desarrollo y las pruebas.
  • Aplicaciones que no necesitan alta disponibilidad: Una arquitectura de una sola zona puede ser suficiente para las aplicaciones que pueden tolerar tiempo de inactividad debido a interrupciones en la infraestructura.
  • Herramientas de redes de baja latencia y bajo costo entre los componentes de la aplicación: Una arquitectura de una sola zona puede ser adecuada para aplicaciones como el procesamiento por lotes que necesita redes de latencia baja y ancho de banda alto entre los nodos de procesamiento. Con una implementación de una sola zona, no hay tráfico de red entre zonas y no se generan costos por el tráfico dentro de la zona.
  • Migración de cargas de trabajo básicas: la arquitectura de implementación zonal proporciona una ruta de migración a la nube simple para aplicaciones locales básicas en las que no tienes control sobre el código o que no admiten arquitecturas más allá de una topología básica activa-pasiva.
  • Ejecución de software con licencia restringida: Una arquitectura de una sola zona puede ser adecuada para sistemas con licencia restringida en los que ejecutar más de una instancia a la vez es demasiado costosa o no está permitido.

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 y zonas de Google Cloud para tu implementación zonal y seleccionar los servicios de Google Cloud adecuados.

Selección de región

Cuando elijas una región y una zona de Google Cloud para tus aplicaciones, ten en cuenta los siguientes factores y requisitos:

  • Disponibilidad de los servicios de Google Cloud. Para obtener más información, consulta Productos disponibles por ubicación
  • Disponibilidad de los tipos de máquina de Compute Engine. Para obtener más información, consulta Regiones y zonas.
  • Requisitos de la latencia del usuario final
  • Costo de los recursos de Google Cloud
  • 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. Para obtener más información, consulta Selecciona zonas y regiones geográficas en el framework de arquitectura de Google Cloud.

Servicios de Compute

La arquitectura de referencia de este documento usa VMs de Compute Engine para todos los niveles de la aplicación. La guía de diseño de este documento es específica para Compute Engine, a menos que se mencione lo contrario.

Según los requisitos de tu aplicación, puedes elegir entre los siguientes otros servicios de procesamiento de Google Cloud. La guía de diseño de esos servicios está fuera del alcance de este documento.

  • Puedes ejecutar aplicaciones alojada en contenedores en los clústeres de Google Kubernetes Engine (GKE). GKE es un motor de organización de contenedores que automatiza la implementación, el escalamiento y la administración de aplicaciones en contenedores.
  • Si prefieres enfocar tus esfuerzos de TI en los datos y las aplicaciones en lugar de configurar y operar recursos de infraestructura, puedes usar servicios sin servidores como Cloud Run y Cloud Functions.

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 Elige y administra el procesamiento en el framework de arquitectura de Google Cloud.

Servicios de almacenamiento

La arquitectura que se muestra en este documento usa volúmenes de discos persistentes zonales para todos los niveles. Para obtener un almacenamiento persistente más duradero, puedes usar volúmenes de discos persistentes regionales, que proporcionan una replicación síncrona de datos en dos zonas dentro de una región.

Para el almacenamiento de bajo costo que es redundante en todas las zonas dentro de una región, puedes usar buckets regionales de Cloud Storage.

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 Filestore. 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, te recomendamos usar Cloud SQL para SQL Server. En situaciones en las que Cloud SQL no es compatible con tus requisitos de configuración o si necesitas acceso al sistema operativo, puedes implementar una instancia de clúster de conmutación por error (FCI). En esta situación, puedes usar Google Cloud NetApp Volumes completamente administrado para proporcionar almacenamiento SMB de disponibilidad continua (CA) para la base de datos.

Cuando diseñes almacenamiento para tus cargas de trabajo, considera las características funcionales, los requisitos de resiliencia, las expectativas de rendimiento y los objetivos de costo. 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.

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 zonal en Google Cloud que cumpla con los requisitos de seguridad y cumplimiento de las cargas de trabajo.

Protección contra amenazas externas

Para proteger tu aplicación contra amenazas externas como los ataques de denegación de servicio distribuido (DDoS) y las secuencias de comandos entre sitios (XSS), puedes usar las políticas de seguridad de Google Cloud Armor. Las políticas de seguridad se aplican en el perímetro, es decir, antes de que el tráfico alcance el nivel web. 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 internas, 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 el rol 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”.

Seguridad de red

Para controlar el tráfico de red entre los recursos en la arquitectura, debes configurar las reglas de firewall de nueva generación de Cloud adecuadas. Cada regla de firewall te permite controlar el tráfico según parámetros como el protocolo, la dirección IP y el puerto. Por ejemplo, puedes configurar una regla de firewall para permitir el tráfico de TCP desde las VMs del servidor web a un puerto específico de las VMs de la base de datos y bloquear el resto del tráfico.

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 empresa.

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 zonales en Google Cloud.

Interrupciones de la infraestructura

En una arquitectura de implementación de una sola zona, si falla algún componente de la pila de infraestructura, la aplicación puede procesar solicitudes si cada nivel contiene al menos un componente en funcionamiento con la capacidad adecuada. Por ejemplo, si una instancia del servidor web falla, el balanceador de cargas reenvía las solicitudes del usuario a las otras instancias disponibles del servidor web. Si una VM que aloja un servidor web o una instancia del servidor de apps falla, el MIG vuelve a crear la VM de forma automática. Si la base de datos falla, debes activar la segunda base de datos de forma manual y actualizar las instancias del servidor de aplicaciones para que se conecten con la base de datos.

Una interrupción zonal o regional afecta a todas las VMs de Compute Engine en una implementación de zona única. Una interrupción zonal no afecta el balanceador de cargas en esta arquitectura porque es un recurso regional. Sin embargo, el balanceador de cargas no puede distribuir el tráfico porque no hay backends disponibles. Si se produce una interrupción zonal o regional, debes esperar a que Google resuelva la interrupción y, luego, verificar que la aplicación funcione como se espera.

Puedes reducir el tiempo de inactividad causado por las interrupciones zonales o regionales si mantienes una réplica pasiva (de conmutación por error) de la pila de infraestructura en otra zona o región de Google Cloud. Si ocurre una interrupción en la zona principal, puedes activar la pila en la zona o región de conmutación por error y usar políticas de enrutamiento de DNS para enrutar el tráfico al balanceador de cargas en la zona o región de conmutación por error.

Para las aplicaciones que requieren solidez contra interrupciones zonales o regionales, considera usar una arquitectura regional o multirregional. Consulta las siguientes arquitecturas de referencia:

Ajuste de escala automático de MIG

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. Los MIG con estado no pueden realizar un ajuste de escala automático.

Para controlar el comportamiento del ajuste de escala automático de tus MIG, 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. Si quieres obtener más información, consulta Ajuste de escala automático para grupos de instancias.

Límite de tamaño del MIG

De forma predeterminada, un MIG zonal puede tener hasta 1,000 VMs. Puedes aumentar el límite de tamaño de un MIG a 2,000 VMs.

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 dentro de una sola zona. Para mejorar la solidez de la arquitectura, puedes crear una política de posición de distribución y aplicarla a la plantilla de MIG. Cuando el MIG crea las VMs, las coloca en diferentes servidores físicos (llamados hosts), por lo que las VMs son sólidas contra 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 necesaria para el ajuste de escala automático de MIG, 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. Se generarán cargos por los recursos reservados, incluso si no se aprovisionan ni se usan los recursos. 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 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.

Si usas un servicio de base de datos administrado como Cloud SQL, las copias de seguridad se realizan de forma automática según la política de retención que definas. Puedes complementar la estrategia de copia de seguridad con copias de seguridad lógicas adicionales para cumplir con los requisitos regulatorios, de flujo de trabajo o de la empresa.

Si usas una base de datos de terceros y necesitas almacenar copias de seguridad de la base de datos y registros de transacciones, puedes usar buckets regionales de Cloud Storage. Los buckets regionales de Cloud Storage proporcionan almacenamiento de copias de seguridad de bajo costo que es 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 para capturar el estado de los volúmenes de Persistent Disk en un momento determinado. Las instantáneas estándar 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

Si usas un servicio de base de datos administrado como Cloud SQL en la configuración de HA, en caso de que se produzca una falla de la base de datos principal, Cloud SQL realiza una conmutación por error automática a la base de datos en espera No es necesario cambiar la dirección IP para el extremo de la base de datos. Si usas una base de datos de terceros autoadministrada que se implementa en una VM de Compute Engine, debes usar un balanceador de cargas interno o algún otro mecanismo para asegurarte de que la aplicación pueda conectarse a otra base de datos si la base de datos principal no está disponible.

A fin de implementar la conmutación por error entre zonas para una base de datos que se implementa en una VM de Compute Engine, necesitas un mecanismo para identificar fallas de la base de datos principal y un proceso para conmutar 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 zonal 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 HA. 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%.

Si implementas una base de datos de terceros, como Microsoft SQL Server en las VMs de Compute Engine, debes considerar los costos de la licencia del software de terceros. Cuando usas un servicio de base de datos administrado como Cloud SQL, los costos de la licencia de la base de datos se incluyen en los cargos del servicio.

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 zonal 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 zonal 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.

Los subprocesos múltiples de VM pueden tener implicaciones de licencias para algún software de terceros, como las bases de datos. Para obtener más información, lee la documentación sobre licencias del software de terceros.

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 los niveles Premium o Estándar.

  • 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 y global que está cerca de tu usuario final. Recomendamos usar el nivel Premium como nivel predeterminado para obtener un rendimiento óptimo.
  • Con el nivel Estándar, el tráfico ingresa y sale de la red de Google en un PoP perimetral más cercano a la ubicación de Google Cloud en la que se ejecuta tu carga de trabajo. 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.

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: