En este documento, se proporciona una arquitectura de referencia para una aplicación de varios niveles que se ejecuta en VMs de Compute Engine en varias zonas dentro de una región 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 regional 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 de una aplicación que se ejecuta en modo activo-activo en pilas aisladas que se implementan en tres zonas de Google Cloud dentro de una región. La arquitectura está alineada con el arquetipo de implementación regional, que garantiza que la topología de Google Cloud sea sólida contra interrupciones zonales.
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 regional. El MIG es el backend del balanceador de cargas externo regional. 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. |
| 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 regional 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 regional, que es el backend del balanceador de cargas interno. 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 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 más adelante en esta guía. |
| 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”. |
| Bucket birregional de Cloud Storage |
Las copias de seguridad de las aplicaciones y las bases de datos se almacenan en un bucket de Cloud Storage birregional. Si se produce una interrupción zonal o regional, 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 regional 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.
Aplicación con alta disponibilidad con usuarios dentro de un área geográfica
Recomendamos una arquitectura de implementación regional para las aplicaciones que necesitan solidez contra interrupciones zonales, pero que puedan tolerar cierto tiempo de inactividad causado por interrupciones regionales. Si alguna parte de la pila de aplicaciones falla, la aplicación seguirá ejecutándose si existe al menos un componente en funcionamiento con capacidad adecuada en cada nivel. Si se produce una interrupción zonal, la pila de aplicaciones continúa ejecutándose en las otras zonas.
Latencia baja para usuarios de aplicaciones
Si todos los usuarios de una aplicación se encuentran dentro de una sola área geográfica, como un solo país, una arquitectura de implementación regional puede ayudar a mejorar el rendimiento de la aplicación percibido por el usuario. Puedes optimizar la latencia de red para las solicitudes de los usuarios si implementas la aplicación en la región de Google Cloud más cercana a tus usuarios.
Herramientas de redes de baja latencia entre los componentes de la aplicación
Una arquitectura de una sola región puede ser adecuada para aplicaciones como la computación por lotes que necesitan conexiones de red de latencia baja y ancho de banda alto entre los nodos de procesamiento. Todos los recursos se encuentran en una sola región de Google Cloud, por lo que el tráfico de red entre recursos permanece dentro de la región. La latencia de red entre recursos es baja y no se generan costos de transferencia de datos entre regiones. Aún se aplican costos de red dentro de la región.
Cumplimiento de los requisitos de residencia de datos
Puedes usar una arquitectura de una sola región para compilar una topología 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 ejecutar la aplicación en una región de Google Cloud en Europa.
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 regional y seleccionar los servicios de Google Cloud adecuados.
Selección de región
Cuando elijas una región 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 regionales para todos los niveles. Los discos persistentes 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 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 HA y la solidez contra las interrupciones zonales. 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 el almacenamiento para tus cargas de trabajo regionales, 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.
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 regional 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 (DSD) 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 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 regionales en Google Cloud.
Interrupciones de la infraestructura
En una arquitectura regional, si falla algún componente individual de la pila de infraestructura, la aplicación puede procesar solicitudes si existe al menos un componente en funcionamiento con capacidad adecuada en cada nivel. 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 ocurre una interrupción zonal, el balanceador de cargas no se ve afectado, ya que es un recurso regional. Una interrupción zonal puede afectar a las VMs individuales de Compute Engine. Sin embargo, la aplicación permanece disponible y responsiva porque las VMs están en un MIG regional. Un MIG regional garantiza que se creen VMs nuevas de forma automática para mantener la cantidad mínima de VMs configurada. Después de que Google resuelva la interrupción zonal, debes verificar que la aplicación se ejecute como se espera en todas las zonas en las que se implementa.
Si todas las zonas de esta arquitectura tienen una interrupción o si se produce una interrupción regional, la aplicación no estará disponible. 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 regionales si mantienes una réplica pasiva (conmutación por error) de la pila de infraestructura en otra región de Google Cloud. Si se produce una interrupción en la región principal, puedes activar la pila en la 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 región de la conmutación por error.
Para las aplicaciones que requieren solidez contra interrupciones regionales, considera usar una arquitectura multirregional. Para obtener más información, consulta Implementación multirregional en Compute Engine.
Ajuste de escala automático de MIG
Cuando ejecutas tu aplicación en VMs en un MIG regional, la aplicación permanece disponible durante las interrupciones de zonas aisladas. 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.
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 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 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.
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 depósitos 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:
- Guía de confiabilidad de la infraestructura de Google Cloud
- Patrones de apps escalables y resilientes
- Diseña sistemas resilientes
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 regional 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 regional 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 regional 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 optimizadas 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, 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
- Obtén más información sobre los productos de Google Cloud que se usan en esta arquitectura de referencia:
- Comienza a migrar tus cargas de trabajo a Google Cloud.
- Explora y evalúa los arquetipos de implementación que puedes optar por compilar arquitecturas para tus cargas de trabajo en la nube.
- Revisa las opciones de arquitectura para diseñar una infraestructura confiable para tus cargas de trabajo en Google Cloud.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.
Colaboradores
Autor: Kumar Dhanagopal | Desarrollador de soluciones entre productos
Otros colaboradores:
- Ben Good | Arquitecto de soluciones
- Carl Franklin | Director, Arquitecto Empresarial de PSO
- Daniel Lees | Arquitecto de Seguridad en la Nube
- Gleb Otochkin | Cloud Advocate, bases de datos
- Mark Schlagenhauf | Escritor técnico, Herramientas de redes
- Pawel Wenda | Gerente de grupo de productos
- Sean Derrington | Gerente de productos salientes del grupo
- Sekou Page | Gerente de Productos Salientes
- Simon Bennett | Gerente de grupo de productos
- Steve McGhee | Defensor de Confiabilidad
- Victor Moreno | Gerente de producto, Herramientas de redes de Cloud