Despliegue regional en Compute Engine

En este documento se proporciona una arquitectura de referencia para una aplicación de varios niveles que se ejecuta en máquinas virtuales de Compute Engine en varias zonas de una región Google Cloud. Puedes usar esta arquitectura de referencia para volver a alojar (lift and shift) de forma eficiente aplicaciones on-premise en la nube con cambios mínimos en las aplicaciones. En el documento también se describen los factores de diseño que debes tener en cuenta al crear una arquitectura regional para tus aplicaciones en la nube. Este documento está dirigido a arquitectos de nube.

Arquitectura

En el siguiente diagrama se muestra la arquitectura de una aplicación que se ejecuta en modo activo-activo en pilas aisladas que se despliegan en tres zonasGoogle Cloud de una región. La arquitectura se ajusta al arquetipo de despliegue regional.

La arquitectura se basa en el modelo de nube de infraestructura como servicio (IaaS). Tú proporcionas los recursos de infraestructura necesarios (computación, redes y almacenamiento) en Google Cloud. Tú 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 el artículo PaaS, IaaS, SaaS y CaaS: ¿en qué se diferencian?

El diagrama anterior incluye los siguientes componentes:

Componente	Finalidad
Balanceador de carga externo regional	El balanceador de carga externo regional recibe y distribuye las solicitudes de los usuarios a las VMs de la capa web. Usa el tipo de balanceador de carga adecuado en función del tipo de tráfico y otros requisitos. Por ejemplo, si el backend consta de servidores web (como se muestra en la arquitectura anterior), utiliza un balanceador de carga de aplicaciones para reenviar el tráfico HTTP(S). Para balancear la carga del tráfico TCP, usa un balanceador de carga de red. Para obtener más información, consulta Elegir un balanceador de carga.
Grupo de instancias gestionado (MIG) regional para el nivel web	El nivel web de la aplicación se despliega en máquinas virtuales de Compute Engine que forman parte de un MIG regional. El MIG es el backend del balanceador de carga externo regional. El MIG contiene VMs de Compute Engine en tres zonas diferentes. Cada una de estas máquinas virtuales aloja una instancia independiente de la capa web de la aplicación.
Balanceador de carga interno regional	El balanceador de carga interno regional distribuye el tráfico de las VMs de la capa web a las VMs de la capa de aplicación. En función de tus requisitos, puedes usar un balanceador de carga de aplicaciones interno regional o un balanceador de carga de red. Para obtener más información, consulta Elegir un balanceador de carga.
MIG regional para el nivel de aplicación	El nivel de aplicación se despliega en máquinas virtuales de Compute Engine que forman parte de un MIG regional, que es el backend del balanceador de carga interno. El MIG contiene VMs de Compute Engine en tres zonas diferentes. Cada VM aloja una instancia independiente de la capa de aplicación.
Base de datos de terceros desplegada en una VM de Compute Engine	La arquitectura de este documento muestra una base de datos de terceros (como PostgreSQL) que se ha desplegado en una VM de Compute Engine. Puede implementar una base de datos de reserva en otra zona. Las funciones de replicación y conmutación por error de la base de datos dependen de la base de datos que utilices. Instalar y gestionar una base de datos de terceros implica un esfuerzo y un coste operativo adicionales para aplicar actualizaciones, monitorizar y asegurar la disponibilidad. Puedes evitar la sobrecarga de instalar y gestionar una base de datos de terceros, así como aprovechar las funciones de alta disponibilidad (HA) integradas, usando un servicio de base de datos totalmente gestionado, como Cloud SQL o AlloyDB para PostgreSQL. Para obtener más información sobre las opciones de bases de datos gestionadas, consulta la sección Servicios de bases de datos más adelante en esta guía.
Red de nube privada virtual y subred	Todos los Google Cloud recursos de la arquitectura usan una única red VPC y una única subred. En función de tus requisitos, puedes crear una arquitectura que use varias redes de VPC o varias subredes. Para obtener más información, consulta el artículo Decidir si se deben crear varias redes de VPC en "Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC".
Segmento birregional de Cloud Storage	Las copias de seguridad de las aplicaciones y las bases de datos se almacenan en un segmento de Cloud Storage de doble región. Si se produce una interrupción del servicio en una zona o una región, no se perderán tu aplicación ni tus datos. También puede usar el servicio de copia de seguridad y recuperación tras desastres para crear, almacenar y gestionar las copias de seguridad de la base de datos.

Productos usados

Esta arquitectura de referencia usa los siguientes Google Cloud productos:

• Compute Engine: un servicio de computación seguro y personalizable con el que puedes crear y ejecutar máquinas virtuales en la infraestructura de Google.
• Cloud Load Balancing: una cartera de balanceadores de carga de alto rendimiento, escalables, globales y regionales.
• Cloud Storage: un almacén de objetos ilimitado y a un coste bajo para diversos tipos de datos. Se puede acceder a los datos desde dentro y fuera de Google Cloud, y se replican en varias ubicaciones para ofrecer redundancia.
• Nube privada virtual (VPC): un sistema virtual que proporciona funciones de red globales y escalables para tus Google Cloud cargas de trabajo. VPC incluye el intercambio de tráfico entre redes de VPC, Private Service Connect, el acceso a servicios privados y la VPC compartida.

Casos prácticos

En esta sección se describen los casos prácticos en los que es apropiado realizar una implementación regional en Compute Engine.

Migración eficiente de aplicaciones on-premise

Puedes usar esta arquitectura de referencia para crear una Google Cloud topología 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 de esta arquitectura de referencia se alojan en máquinas virtuales de Compute Engine. Esta estrategia te permite migrar aplicaciones on-premise a la nube de forma eficiente y aprovechar las ventajas deGoogle Cloud en cuanto a costes, fiabilidad, rendimiento y sencillez operativa.

Aplicación de alta disponibilidad con usuarios de un área geográfica

Recomendamos una arquitectura de implementación regional para las aplicaciones que necesiten robustez frente a las interrupciones de zonas, pero que puedan tolerar cierto tiempo de inactividad provocado por interrupciones de regiones. Si falla alguna parte de la pila de aplicaciones, la aplicación seguirá ejecutándose si hay al menos un componente que funcione con capacidad suficiente en cada nivel. Si se produce una interrupción en una zona, la pila de aplicaciones sigue ejecutándose en las demás zonas.

Latencia baja para los usuarios de la aplicación

Si todos los usuarios de una aplicación se encuentran en una misma zona geográfica, como un país, una arquitectura de implementación regional puede ayudar a mejorar el rendimiento de la aplicación percibido por los usuarios. Puedes optimizar la latencia de la red para las solicitudes de los usuarios desplegando la aplicación en la Google Cloud región más cercana a ellos.

Redes de baja latencia entre componentes de aplicaciones

Una arquitectura de una sola región puede ser adecuada para aplicaciones como la computación por lotes, que necesitan conexiones de red de baja latencia y alto ancho de banda entre los nodos de computación. Todos los recursos están en una sola Google Cloud región, por lo que el tráfico de red entre recursos permanece en la región. La latencia de la red entre recursos es baja y no se incurre en costes de transferencia de datos entre regiones. Se siguen aplicando los costes de red dentro de la misma región.

Cumplimiento de los requisitos de residencia de datos

Puedes usar una arquitectura de una sola región para crear una topología que te ayude a cumplir los requisitos de residencia de datos. Por ejemplo, un país de Europa puede requerir que todos los datos de usuario se almacenen y se acceda a ellos en centros de datos ubicados físicamente en Europa. Para cumplir este requisito, puedes ejecutar la aplicación en una Google Cloud región de Europa.

Factores del diseño

En esta sección se ofrece información para ayudarte a usar esta arquitectura de referencia y desarrollar una arquitectura que cumpla tus requisitos específicos de diseño del sistema, seguridad y cumplimiento, fiabilidad, eficiencia operativa, coste y rendimiento.

Diseño de sistemas

En esta sección se ofrecen directrices para ayudarte a elegir las Google Cloud regiones para tu implementación regional y a seleccionar los Google Cloud servicios adecuados.

Selección de regiones

Cuando elijas las Google Cloud regiones 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 el artículo Regiones y zonas.
• Requisitos de latencia para los usuarios finales.
• Coste de los Google Cloud recursos.
• Costes de transferencia de datos entre regiones.
• Requisitos normativos.

Algunos de estos factores y requisitos pueden implicar concesiones. Por ejemplo, la región más rentable puede no tener la huella de carbono más baja. Para obtener más información, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine.

Infraestructura informática

La arquitectura de referencia de este documento usa máquinas virtuales de Compute Engine para determinados niveles de la aplicación. En función de los requisitos de tu aplicación, puedes elegir entre otros Google Cloud servicios de computación:

• Contenedores: puedes ejecutar aplicaciones en contenedores en clústeres de Google Kubernetes Engine (GKE). GKE es un motor de orquestación de contenedores que automatiza el despliegue, el escalado y la gestión de aplicaciones en contenedores.
• Sin servidor: si prefieres centrar tus esfuerzos de TI en los datos y las aplicaciones en lugar de configurar y operar recursos de infraestructura, puedes usar servicios sin servidor, como Cloud Run.

Para decidir si usar máquinas virtuales, contenedores o servicios sin servidor, debes encontrar el equilibrio entre la flexibilidad de la configuración y el esfuerzo de gestión. Las máquinas virtuales y los contenedores ofrecen más flexibilidad de configuración, pero tú eres el responsable de gestionar los recursos. En una arquitectura sin servidor, las cargas de trabajo se despliegan en una plataforma preconfigurada que requiere un esfuerzo de gestión mínimo. Para obtener más información sobre cómo elegir los servicios de computación adecuados para tus cargas de trabajo enGoogle Cloud, consulta Alojar aplicaciones en Google Cloud.

Servicios de almacenamiento

La arquitectura que se muestra en este documento usa volúmenes de disco persistente regional para todos los niveles. Los discos persistentes proporcionan replicación síncrona de datos en dos zonas de una región.

Google Cloud Hyperdisk ofrece un mejor rendimiento, flexibilidad y eficiencia que Persistent Disk. Con Hyperdisk Balanced, puedes aprovisionar IOPS y el procesamiento de forma independiente y dinámica, lo que te permite ajustar el volumen a una amplia variedad de cargas de trabajo.

Si quieres un almacenamiento de bajo coste que se replique en varias ubicaciones, puedes usar segmentos regionales, birregionales o multirregionales de Cloud Storage.

• Los datos de los segmentos regionales se replican de forma síncrona en las zonas de la región.
• Los datos de los contenedores birregionales o multirregionales se almacenan de forma redundante en al menos dos ubicaciones geográficas independientes. 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 segmentos de dos regiones, puedes usar la replicación turbo, que asegura que los objetos se repliquen en los pares de regiones, con un objetivo de punto de recuperación (RPO) de 15 minutos. Para obtener más información, consulta el artículo Disponibilidad y durabilidad de los datos.

Para almacenar datos que se compartan entre varias VMs de una región, como todas las VMs de la capa web o de la capa de aplicación, puedes usar una instancia regional de Filestore. Los datos que almacenas en una instancia regional de Filestore se replican de forma síncrona en tres zonas de la región. Esta replicación asegura una alta disponibilidad y una gran solidez frente a las interrupciones de zonas. Puedes almacenar archivos de configuración compartidos, herramientas y utilidades comunes, y registros centralizados en la instancia de Filestore, así como activar la instancia en varias máquinas virtuales. Para aumentar la solidez frente a las interrupciones de la región, puede replicar una instancia de Filestore en otra región. Para obtener más información, consulta Replicación de instancias.

Si tu base de datos es Microsoft SQL Server, te recomendamos que uses Cloud SQL para SQL Server. En los casos en los que Cloud SQL no admita tus requisitos de configuración o si necesitas acceder al sistema operativo, puedes implementar una instancia de clúster de conmutación por error (FCI) de Microsoft SQL Server. En este caso, puedes usar Google Cloud NetApp Volumes, un servicio totalmente gestionado, para proporcionar almacenamiento SMB de disponibilidad continua (CA) a la base de datos.

Cuando diseñes el almacenamiento de tus cargas de trabajo, ten en cuenta las características funcionales, los requisitos de resiliencia, las expectativas de rendimiento y los objetivos de costes. Para obtener más información, consulta Diseñar una estrategia de almacenamiento óptima para tu carga de trabajo en la nube.

Servicios de bases de datos

La arquitectura de referencia de este documento usa una base de datos de terceros que se ha desplegado en máquinas virtuales de Compute Engine. Instalar y gestionar una base de datos de terceros implica esfuerzo y costes para operaciones como aplicar actualizaciones, monitorizar y asegurar la disponibilidad, realizar copias de seguridad y recuperarse de fallos.

Puedes evitar el esfuerzo y el coste de instalar y gestionar una base de datos de terceros usando un servicio de base de datos totalmente gestionado como Cloud SQL, AlloyDB para PostgreSQL, Bigtable, Spanner o Firestore. Estos servicios de bases de datos ofrecen acuerdos de nivel de servicio (SLAs) de tiempo de actividad e incluyen funciones predeterminadas de escalabilidad y observabilidad. Google Cloud

Si tu carga de trabajo necesita una base de datos de Oracle, puedes desplegarla en una VM de Compute Engine o usar Oracle Database@Google Cloud. Para obtener más información, consulta Cargas de trabajo de Oracle en Google Cloud.

Diseño de redes

Elige un diseño de red que cumpla los requisitos técnicos y empresariales. Puedes usar una o varias redes de VPC. Para obtener más información, consulta la siguiente documentación:

• Decidir si se deben crear varias redes de VPC
• Decide el diseño de la red de tu Google Cloud zona de aterrizaje

Seguridad, privacidad y cumplimiento

En esta sección se describen los factores que debes tener en cuenta al usar esta arquitectura de referencia para diseñar y crear una topología regional enGoogle Cloud que cumpla los requisitos de seguridad, privacidad y cumplimiento de tus cargas de trabajo.

Protección frente a amenazas externas

Para proteger tu aplicación frente a amenazas 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. Cada política es un conjunto de reglas que especifica determinadas condiciones que se deben evaluar y las acciones que se deben llevar a cabo cuando se cumplan esas 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 intervalo CIDR específicos, se debe denegar el tráfico. También puede aplicar reglas de cortafuegos de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta el artículo Información general sobre la política de seguridad.

Acceso externo a las VMs

En la arquitectura de referencia que se describe en este documento, las VMs de Compute Engine no necesitan acceso entrante desde Internet. No asignes direcciones IP externas a las VMs. Google Cloud Los recursos que solo tienen una dirección IP interna privada pueden acceder a determinadas APIs y servicios de Google mediante Private Service Connect o Acceso privado de Google. Para obtener más información, consulta el artículo sobre las opciones de acceso privado a servicios.

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

Privilegios de cuenta de servicio

En el caso de las máquinas virtuales de Compute Engine de la arquitectura, en lugar de usar las cuentas de servicio predeterminadas, te recomendamos que crees cuentas de servicio específicas y que indiques los recursos a los que puede acceder la cuenta de servicio. La cuenta de servicio predeterminada tiene una amplia gama de permisos, incluidos algunos que puede que no sean necesarios. Puedes adaptar las cuentas de servicio dedicadas para que solo tengan los permisos esenciales. Para obtener más información, consulta Limitar los privilegios de las cuentas de servicio.

Seguridad de SSH

Para mejorar la seguridad de las conexiones SSH a las VMs de Compute Engine de tu arquitectura, implementa Identity-Aware Proxy (IAP) y la API Cloud OS Login. IAP te permite controlar el acceso a la red en función de la identidad del usuario y las políticas de Gestión de Identidades y Accesos (IAM). La API Cloud OS Login te permite controlar el acceso SSH de Linux en función de la identidad del usuario y las políticas de gestión de identidades y accesos. Para obtener más información sobre cómo gestionar el acceso a la red, consulta las prácticas recomendadas para controlar el acceso de inicio de sesión SSH.

Seguridad de la red

Para controlar el tráfico de red entre los recursos de la arquitectura, debes configurar las políticas de cortafuegos de última generación (NGFW) de Cloud adecuadas.

Más consideraciones sobre seguridad

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de plataforma que se proporcionan en el blueprint de bases empresariales y en el Google Cloud framework Well-Architected: seguridad, privacidad y cumplimiento.

Fiabilidad

En esta sección se describen los factores de diseño que debes tener en cuenta al usar esta arquitectura de referencia para crear y operar una infraestructura fiable para tus implementaciones regionales en Google Cloud.

Interrupciones de la infraestructura

En una arquitectura regional, si falla algún componente de la pila de infraestructura, la aplicación puede procesar solicitudes si hay al menos un componente que funcione con capacidad suficiente en cada nivel. Por ejemplo, si falla una instancia de servidor web, el balanceador de carga reenvía las solicitudes de los usuarios a las otras instancias de servidor web disponibles. Si falla una VM que aloja una instancia de servidor web o de servidor de aplicaciones, el MIG recrea la VM automáticamente.

Si se produce una interrupción en una zona, el balanceador de carga no se verá afectado, ya que es un recurso regional. Una interrupción de una zona puede afectar a máquinas virtuales de Compute Engine concretas. Sin embargo, la aplicación sigue estando disponible y respondiendo porque las VMs están en un MIG regional. Un MIG regional se asegura de que se creen automáticamente máquinas virtuales para mantener el número mínimo configurado de máquinas virtuales. Una vez que Google haya resuelto la interrupción de la zona, debes verificar que la aplicación se ejecuta correctamente en todas las zonas en las que se ha implementado.

Si todas las zonas de esta arquitectura sufren una interrupción o si se produce una interrupción en una región, la aplicación no estará disponible. Debes esperar a que Google resuelva la interrupción y, a continuación, verificar que la aplicación funciona correctamente.

Puedes reducir el tiempo de inactividad provocado por las interrupciones de las regiones manteniendo una réplica pasiva (de conmutación por error) de la pila de infraestructura en otra región. Google Cloud Si se produce una interrupción en la región principal, puedes activar el stack en la región de failover y usar políticas de enrutamiento de DNS para enrutar el tráfico al balanceador de carga de la región de failover.

En el caso de las aplicaciones que requieren solidez frente a las interrupciones de las regiones, considera la posibilidad de usar una arquitectura multirregional. Para obtener más información, consulta el artículo sobre despliegues multirregionales en Compute Engine.

Autoescalado de MIG

Para controlar el comportamiento del autoescalado de tus MIGs sin estado, puedes especificar métricas de utilización objetivo, como la utilización media de la CPU. También puedes configurar el escalado automático basado en la programación para los MIGs sin estado. Las MIGs con estado no se pueden escalar automáticamente. Para obtener más información, consulta Grupos de instancias con autoescalado.

Límite de tamaño de MIG

Cuando decidas el tamaño de tus MIGs, ten en cuenta los límites predeterminados y máximos del número de VMs que se pueden crear en un MIG. Para obtener más información, consulta Añadir y quitar VMs de un MIG.

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 propia aplicación. Es posible que la aplicación se bloquee, falle o no tenga suficiente memoria. Para verificar si una aplicación responde según lo esperado, puedes configurar comprobaciones de estado basadas en aplicaciones como parte de la política de reparación automática de tus MIGs. Si la aplicación de una máquina virtual concreta no responde, el MIG se recupera automáticamente (repara la máquina virtual). Para obtener más información sobre cómo configurar la reparación automática, consulta Información sobre la reparación de VMs para la alta disponibilidad.

Emplazamiento de VM

En la arquitectura que se describe en este documento, los niveles de aplicación y web se ejecutan en máquinas virtuales de Compute Engine distribuidas en varias zonas. Esta distribución asegura que tu aplicación sea robusta frente a interrupciones de zona.

Para mejorar la solidez de la arquitectura, puedes crear una política de colocación de réplicas y aplicarla a la plantilla de MIG. Cuando el MIG crea VMs, las coloca en servidores físicos diferentes (llamados hosts) dentro de cada zona, por lo que tus VMs son resistentes a los fallos de hosts concretos. Para obtener más información, consulta Crear y aplicar políticas de colocación dispersa a VMs.

Planificación de la capacidad de las VMs

Para asegurarte de que haya capacidad disponible para las VMs de Compute Engine cuando sea necesario aprovisionarlas, puedes crear reservas. Las reservas proporcionan capacidad asegurada en una zona específica para un número determinado de máquinas virtuales de un tipo de máquina que elijas. Una reserva puede ser específica de un proyecto o compartirse entre varios proyectos. Para obtener más información sobre las reservas, consulta Elegir un tipo de reserva.

Almacenamiento con estado

Una práctica recomendada en el diseño de aplicaciones es evitar la necesidad de usar discos locales con estado. Sin embargo, si es necesario, puedes configurar tus discos persistentes para que tengan reconocimiento del estado y así asegurarte de que los datos se conserven cuando se reparen o se vuelvan a crear las VMs. Sin embargo, te recomendamos que mantengas los discos de arranque sin reconocimiento del estado para que puedas actualizarlos a las imágenes más recientes con nuevas versiones y parches de seguridad. Para obtener más información, consulta Configurar discos persistentes con reconocimiento del estado en MIGs.

Durabilidad de los datos

Puedes usar Backup y DR para crear, almacenar y gestionar copias de seguridad de las máquinas virtuales de Compute Engine. Backup y recuperación tras fallos almacena los datos de las copias de seguridad en su formato original, legible por las aplicaciones. Cuando sea necesario, puedes restaurar tus cargas de trabajo en producción usando directamente los datos del almacenamiento de copias de seguridad a largo plazo, sin tener que preparar ni mover datos.

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

• Puedes usar capturas para registrar el estado de los volúmenes de discos persistentes en un momento determinado. Las instantáneas se almacenan de forma redundante en varias regiones, con sumas de comprobación automáticas para asegurar la integridad de tus datos. Las copias de seguridad son incrementales de forma predeterminada, por lo que ocupan menos espacio de almacenamiento y ahorras dinero. Las capturas se almacenan en una ubicación de Cloud Storage que puedes configurar. Para obtener más recomendaciones sobre el uso y la gestión de capturas, consulta las prácticas recomendadas para las capturas de disco de Compute Engine.
• Para asegurarte de que los datos de Persistent Disk sigan estando disponibles si se produce una interrupción en una zona, puedes usar Persistent Disk regional o Hiperdisco equilibrado de alta disponibilidad. Los datos de estos tipos de discos se replican de forma síncrona entre dos zonas de la misma región. Para obtener más información, consulta el artículo Acerca de la replicación de discos síncrona.

Si usas un servicio de base de datos gestionado como Cloud SQL, las copias de seguridad se crean automáticamente en función de la política de conservación que definas. Puedes complementar la estrategia de copia de seguridad con copias de seguridad lógicas adicionales para cumplir los requisitos normativos, de flujo de trabajo o empresariales.

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 segmentos de Cloud Storage regionales. Los segmentos de Cloud Storage regionales proporcionan un almacenamiento de copias de seguridad de bajo coste que es redundante en todas las zonas.

Disponibilidad de la base de datos

Si usas un servicio de base de datos gestionado como Cloud SQL con una configuración de alta disponibilidad, en caso de fallo de la base de datos principal, Cloud SQL conmutará automáticamente por error a la base de datos de reserva. No es necesario que cambie la dirección IP del endpoint de la base de datos. Si usas una base de datos de terceros autogestionada que se haya desplegado en una VM de Compute Engine, debes usar un balanceador de carga interno u 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.

Para implementar la conmutación por error entre zonas en una base de datos desplegada en una VM de Compute Engine, necesitas un mecanismo para identificar los fallos de la base de datos principal y un proceso para conmutar por error a la base de datos de reserva. Los detalles del mecanismo de conmutación por error dependen de la base de datos que utilices. Puedes configurar una instancia observadora para detectar fallos en la base de datos principal y coordinar la conmutación por error. Debes configurar las reglas de conmutación por error correctamente para evitar una situación de cerebro dividido y prevenir conmutaciones por error innecesarias. Para ver arquitecturas de ejemplo que puedes usar para implementar la conmutación por error en bases de datos de PostgreSQL, consulta Arquitecturas de alta disponibilidad de clústeres de PostgreSQL en Compute Engine.

Más consideraciones sobre la fiabilidad

Cuando crees la arquitectura en la nube de tu carga de trabajo, consulta las prácticas recomendadas y las recomendaciones relacionadas con la fiabilidad que se proporcionan en la siguiente documentación:

• Google Cloud guía de fiabilidad de la infraestructura
• Patrones para aplicaciones escalables y resilientes
• Diseñar sistemas resilientes
• Google Cloud Well-Architected Framework: fiabilidad

Optimización de costes

En esta sección se ofrecen directrices para optimizar el coste de configurar y operar una topología regional Google Cloud que se cree con esta arquitectura de referencia.

Tipos de máquinas virtuales

Para ayudarte a optimizar el uso de los recursos de tus instancias de VM, Compute Engine ofrece recomendaciones sobre el tipo de máquina. Usa las recomendaciones para elegir los tipos de máquinas que se ajusten a los requisitos de computación de tu carga de trabajo. En el caso de las cargas de trabajo con requisitos de recursos predecibles, puedes personalizar el tipo de máquina según tus necesidades y ahorrar dinero usando tipos de máquinas personalizadas.

Modelo de aprovisionamiento de VMs

Si tu aplicación es tolerante a fallos, las VMs de acceso puntual pueden ayudarte a reducir los costes de Compute Engine de las VMs de los niveles de aplicación y web. El coste de las máquinas virtuales de acceso puntual es significativamente inferior al de las máquinas virtuales normales. Sin embargo, Compute Engine puede detener o eliminar de forma preventiva las Spot VMs para recuperar capacidad.

Las máquinas virtuales Spot son adecuadas para tareas por lotes que pueden tolerar la interrupción y no tienen requisitos de alta disponibilidad. Las VMs de acceso puntual ofrecen los mismos tipos de máquinas, opciones y rendimiento que las VMs normales. Sin embargo, cuando la capacidad de recursos de una zona es limitada, es posible que los MIGs no puedan aumentar la escala (es decir, crear VMs) automáticamente hasta el tamaño de destino especificado hasta que la capacidad necesaria vuelva a estar disponible.

Uso de recursos de las VMs

La función de autoescalado de los MIGs sin estado permite que tu aplicación gestione los aumentos de tráfico de forma adecuada y te ayuda a reducir los costes cuando la demanda de recursos es baja. Las MIGs con estado no se pueden escalar automáticamente.

Licencias de terceros

Cuando migras cargas de trabajo de terceros a Google Cloud, puedes reducir los costes si utilizas tus propias licencias (BYOL). Por ejemplo, para desplegar máquinas virtuales de Microsoft Windows Server, en lugar de usar una imagen premium que suponga un coste adicional por la licencia de terceros, puedes crear y usar una imagen de Windows BYOL personalizada. Después, solo pagas por la infraestructura de las máquinas virtuales que utilizas en Google Cloud. Esta estrategia te ayuda a seguir obteniendo valor de tus inversiones en licencias de terceros. Si decides usar el enfoque BYOL, las siguientes recomendaciones pueden ayudarte a reducir los costes:

• Aprovisiona el número de núcleos de CPU de cálculo que necesites independientemente de la memoria mediante tipos de máquinas personalizadas. De esta forma, el coste de las licencias de terceros se limita al número de núcleos de CPU que necesites.
• Reduce el número de vCPUs por núcleo de 2 a 1 inhabilitando el multihilo simultáneo (SMT).

Si despliegas una base de datos de terceros, como Microsoft SQL Server, en máquinas virtuales de Compute Engine, debes tener en cuenta los costes de licencia del software de terceros. Si usas un servicio de base de datos gestionado como Cloud SQL, los costes de la licencia de la base de datos se incluyen en los cargos del servicio.

Más consideraciones sobre los costes

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias generales que se proporcionan en el Google Cloud framework Well-Architected: optimización de costes.

Eficiencia operativa

En esta sección se describen los factores que debes tener en cuenta al usar esta arquitectura de referencia para diseñar y crear una topología regional Google Cloud que puedas gestionar de forma eficiente.

Actualizaciones de configuración de máquinas virtuales

Para actualizar la configuración de las VMs de un MIG (como el tipo de máquina o la imagen del disco de arranque), crea una plantilla de instancia con la configuración necesaria y, a continuación, aplícala al MIG. El MIG actualiza las VMs mediante el 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 MIGs, consulta Aplicar nuevas configuraciones de VM en un MIG.

Imágenes de máquina virtual

En el caso de tus VMs, en lugar de usar imágenes públicas proporcionadas por Google, te recomendamos que crees y uses imágenes de SO personalizadas que contengan las configuraciones y el software que necesiten tus aplicaciones. Puedes agrupar tus imágenes personalizadas en una familia de imágenes personalizadas. Una familia de imágenes siempre apunta a la imagen más reciente de esa familia, por lo que tus plantillas de instancia y tus secuencias de comandos pueden usar esa imagen sin que tengas que actualizar las referencias a una versión específica de la imagen. Debe actualizar periódicamente sus imágenes personalizadas para incluir las actualizaciones y los parches de seguridad que proporcione el proveedor del SO.

Plantillas de instancia deterministas

Si las plantillas de instancia que usas en tus MIGs incluyen secuencias de comandos de inicio para instalar software de terceros, asegúrate de que las secuencias de comandos especifiquen explícitamente los parámetros de instalación del software, como la versión del software. De lo contrario, cuando el MIG cree las VMs, es posible que el software instalado en ellas no sea coherente. Por ejemplo, si tu plantilla de instancia incluye un script de inicio para instalar el servidor HTTP de Apache 2.0 (el paquete apache2), asegúrate de que el script especifique la versión exacta de apache2 que se debe instalar, como la versión 2.4.53. Para obtener más información, consulta Plantillas de instancia deterministas.

Más consideraciones operativas

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas generales y las recomendaciones para mejorar la eficiencia operativa que se describen en el Google Cloud framework Well-Architected: excelencia operativa.

Optimización del rendimiento

En esta sección se describen los factores que debes tener en cuenta al usar esta arquitectura de referencia para diseñar y crear una topología regional enGoogle Cloud que cumpla los requisitos de rendimiento de tus cargas de trabajo.

Rendimiento de computación

Compute Engine ofrece una amplia gama de tipos de máquinas predefinidos y personalizables para las cargas de trabajo que ejecutas en las VMs. Elige un tipo de máquina adecuado en función de tus requisitos de rendimiento. Para obtener más información, consulta la guía de comparación y recursos de las familias de máquinas.

Multihilo de VM

Cada CPU virtual (vCPU) que asignas a una máquina virtual de Compute Engine se implementa como un único multihilo de hardware. De forma predeterminada, dos vCPUs comparten un núcleo de CPU físico. En las aplicaciones que implican operaciones altamente paralelas o que realizan cálculos de coma flotante (como el análisis de secuencias genéticas y la modelización de riesgos financieros), puedes mejorar el rendimiento reduciendo el número de subprocesos que se ejecutan en cada núcleo de CPU físico. Para obtener más información, consulta Definir el número de hilos por núcleo.

El multihilo de las máquinas virtuales puede tener implicaciones en las licencias de algunos softwares de terceros, como las bases de datos. Para obtener más información, consulta la documentación de licencias del software de terceros.

Niveles de servicio de red

Los niveles de servicio de red te permiten optimizar el coste y el rendimiento de la red de tus cargas de trabajo. Puedes elegir el nivel Premium o el nivel Estándar. El nivel premium ofrece tráfico en la red troncal mundial de Google para minimizar la pérdida de paquetes y la latencia. El nivel Estándar envía el tráfico mediante el emparejamiento, los proveedores de servicios de Internet (ISPs) o las redes de tránsito en un punto de presencia (PoP) de la periferia que esté más cerca de la región en la que se ejecuta tu carga de trabajo de Google Cloud . Para optimizar el rendimiento, le recomendamos que utilice el nivel Premium. Para optimizar los costes, te recomendamos que uses el nivel Estándar.

Rendimiento de la red

En el caso de las cargas de trabajo que necesiten una latencia de red baja entre las máquinas virtuales en los niveles de aplicación y web, puedes crear una política de emplazamiento compacta y aplicarla a la plantilla de MIG que se utilice en esos niveles. Cuando el MIG crea máquinas virtuales, las coloca en servidores físicos que están cerca unos de otros. Aunque una política de emplazamiento compacta ayuda a mejorar el rendimiento de la red entre máquinas virtuales, una política de emplazamiento dispersa puede ayudar a mejorar la disponibilidad de las máquinas virtuales, como se ha descrito anteriormente. Para conseguir un equilibrio óptimo entre el rendimiento y la disponibilidad de la red, cuando crees una política de colocación compacta, puedes especificar la distancia que debe haber entre las VMs. Para obtener más información, consulta el resumen de las políticas de colocación.

Compute Engine tiene un límite por máquina virtual para el ancho de banda de red de salida. Este límite depende del tipo de máquina de la VM y de si el tráfico se enruta a través de la misma red VPC que la VM de origen. En las VMs con determinados tipos de máquinas, puedes habilitar redes Tier_1 para mejorar el rendimiento de la red y obtener un ancho de banda de salida máximo más alto.

Más consideraciones sobre el rendimiento

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias generales que se proporcionan en el artículo Google Cloud Well-Architected Framework: optimización del rendimiento.

Siguientes pasos

• Consulte más información sobre los Google Cloud productos utilizados en esta arquitectura de referencia:
  • Información general sobre Cloud Load Balancing
  • Grupos de instancias
• Empieza a migrar tus cargas de trabajo a Google Cloud.
• Descubre y evalúa los arquetipos de implementación que puedes elegir para crear arquitecturas para tus cargas de trabajo en la nube.
• Consulta las opciones de arquitectura para diseñar una infraestructura fiable para tus cargas de trabajo en Google Cloud.
• Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.

Colaboradores

Autores:

• Kumar Dhanagopal | Desarrollador de soluciones entre productos
• Samantha He | Redactora técnica

Otros colaboradores:

• Ben Good | Arquitecto de soluciones
• Carl Franklin | Director de Arquitectura Empresarial de Servicios Profesionales
• Daniel Lees | Arquitecto de seguridad en la nube
• Gleb Otochkin | Cloud Advocate, Databases
• Mark Schlagenhauf | Redactor técnico de redes
• Pawel Wenda | Responsable de Producto de Grupo
• Sean Derrington | Responsable de grupo de producto, almacenamiento
• Sekou Page | Responsable de producto saliente
• Simon Bennett | Responsable de Producto de Grupo
• Steve McGhee | Defensor de la fiabilidad
• Victor Moreno | Product Manager, Cloud Networking