Despliegue multirregional en Compute Engine

En este documento se proporciona una arquitectura de referencia para una aplicación multinivel que se ejecuta en VMs de Compute Engine en varias regiones de 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 multirregional 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 han desplegado en dos regiones de Google Cloud . En cada región, la aplicación se ejecuta de forma independiente en tres zonas. La arquitectura se ajusta al Google Cloud arquetipo de implementación multirregional, lo que asegura que tu Google Cloud topología sea resistente a las interrupciones de zonas y regiones, y que proporcione una latencia baja a los usuarios de la aplicación.

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, y conservas el control total y la responsabilidad del sistema operativo, el middleware y las capas superiores de la pila de aplicaciones. Para obtener más información sobre IaaS y otros modelos de nube, consulta el artículo PaaS, IaaS, SaaS y CaaS: ¿en qué se diferencian?

El diagrama anterior incluye los siguientes componentes:

Componente	Purpose
Balanceador de carga externo global	El balanceador de carga externo global recibe y distribuye las solicitudes de los usuarios a la aplicación. El balanceador de carga externo global anuncia una sola dirección IP anycast, pero se implementa como un gran número de proxies en Google Front Ends (GFEs). Las solicitudes de los clientes se dirigen al GFE más cercano.
Grupos de instancias gestionados (MIGs) regionales para el nivel web	El nivel web de la aplicación se despliega en máquinas virtuales de Compute Engine que forman parte de MIGs regionales. Estos MIGs son los backends del balanceador de carga mundial. Cada 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.
Balanceadores de carga internos regionales	El balanceador de carga interno de cada región distribuye el tráfico de las VMs de la capa web a las VMs de la capa de aplicación de esa región.
Grupos regionales de instancias gestionados para el nivel de aplicación	El nivel de aplicación se despliega en máquinas virtuales de Compute Engine que forman parte de grupos de instancias gestionados regionales. El MIG de cada región es el backend del balanceador de carga interno de esa región. Cada 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 máquinas virtuales de Compute Engine	La arquitectura de este documento muestra una base de datos de terceros (como PostgreSQL) que se ha desplegado en máquinas virtuales de Compute Engine en las dos regiones. Puede configurar la réplica entre regiones de las bases de datos y configurar la base de datos de cada región para que se replique en la base de datos de la otra región. Las funciones de replicación y conmutación por error dependen de la base de datos que utilices. Instalar y gestionar una base de datos de terceros implica un esfuerzo adicional y un coste operativo para la replicación, la aplicación de actualizaciones, la monitorización y la garantía de 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 una base de datos totalmente gestionada, como una instancia de Spanner multirregional.
Red de nube privada virtual y subredes	Todos los recursos de la arquitectura usan una sola red VPC que tiene subredes en dos regiones diferentes. Google Cloud En función de tus requisitos, puedes crear una arquitectura que utilice varias redes de VPC y subredes. Para obtener más información, consulta Decidir si se deben crear varias redes de VPC.
Segmentos de Cloud Storage de doble región	Las copias de seguridad de la base de datos se almacenan en segmentos de Cloud Storage de doble región. También puedes usar el servicio de copia de seguridad y recuperación tras fallos 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 adecuado realizar una implementación multirregional 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 están alojados 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 de costes, la fiabilidad, el rendimiento y la sencillez operativa que ofrece Google Cloud.

Alta disponibilidad para usuarios dispersos geográficamente

Recomendamos una implementación multirregional para las aplicaciones que sean críticas para la empresa y en las que la alta disponibilidad y la solidez ante las interrupciones regionales sean esenciales. Si una región deja de estar disponible por cualquier motivo (incluso si se trata de una interrupción a gran escala causada por un desastre natural), los usuarios de la aplicación no experimentarán ningún tiempo de inactividad. El tráfico se dirige a la aplicación en las otras regiones disponibles. Si los datos se replican de forma síncrona, el tiempo objetivo de recuperación (TOR) es casi cero.

Latencia baja para los usuarios de la aplicación

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

Diseño alternativo

La arquitectura anterior usa un balanceador de carga global, que admite determinadas funciones para mejorar la fiabilidad de tus implementaciones, como el almacenamiento en caché perimetral con Cloud CDN. En esta sección se presenta una arquitectura alternativa que usa balanceadores de carga regionales y Cloud DNS. Esta arquitectura alternativa admite las siguientes funciones adicionales:

• Terminación de Seguridad en la capa de transporte (TLS) en regiones específicas.
• Posibilidad de servir contenido desde la región que especifiques. Sin embargo, es posible que esa región no sea la que tenga el mejor rendimiento en un momento dado.
• Una gama más amplia de protocolos de conexión si usas un balanceador de carga de red de paso a través.

Para obtener más información sobre las diferencias entre los balanceadores de carga regionales y globales, consulta Balanceo de carga global y regional y Modos de funcionamiento.

La arquitectura alternativa del diagrama anterior es robusta frente a las interrupciones de zonas y regiones. Una zona pública de Cloud DNS dirige las solicitudes de los usuarios a la región adecuada. Los balanceadores de carga externos regionales reciben solicitudes de los usuarios y las distribuyen entre las instancias de la capa web de la aplicación en cada región. Los demás componentes de esta arquitectura son idénticos a los de la arquitectura basada en balanceador de carga global.

Factores del diseño

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

Cuando crees una arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias del Google Cloud framework Well-Architected.

Diseño de sistemas

En esta sección se ofrecen directrices para ayudarte a elegir las Google Cloud regiones para tu implementación multirregional 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

Las arquitecturas que se muestran en este documento usan volúmenes de disco persistente regional en 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.

Cuando elijas y configures la base de datos para una implementación multirregional, ten en cuenta los requisitos de tu aplicación en cuanto a la coherencia de los datos entre regiones y los trade-offs de rendimiento y coste.

• Si la aplicación requiere una coherencia sólida (todos los usuarios deben leer los mismos datos en todo momento), los datos se deben replicar de forma síncrona en todas las regiones de la arquitectura. Sin embargo, la replicación síncrona puede conllevar un coste más elevado y un rendimiento menor, ya que los datos que se escriben deben replicarse en tiempo real en todas las regiones antes de que estén disponibles para las operaciones de lectura.
• Si tu aplicación puede tolerar la coherencia final, puedes replicar los datos de forma asíncrona. Esto puede ayudar a mejorar el rendimiento, ya que no es necesario replicar los datos de forma síncrona en todas las regiones. Sin embargo, los usuarios de diferentes regiones pueden leer datos distintos porque es posible que los datos no se hayan replicado por completo en el momento de la solicitud.

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

Cifrado del disco

De forma predeterminada, los datos almacenados en volúmenes de Persistent Disk se encriptan medianteGoogle-owned and Google-managed encryption keys. Como medida de protección adicional, puedes cifrar los Google-owned and managed key con claves que poseas y gestiones en Cloud Key Management Service (Cloud KMS). Para obtener más información, consulta Acerca del cifrado de discos sobre los volúmenes de Hyperdisk y Cifrar datos con claves de cifrado gestionadas por el cliente.

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.

Consideraciones sobre la residencia de datos

Puede usar balanceadores de carga regionales para crear una arquitectura multirregional que le ayude a cumplir los requisitos de residencia de datos. Por ejemplo, en un país de Europa, puede que se exija 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 usar la arquitectura basada en balanceadores de carga regionales. En esa arquitectura, la aplicación se ejecuta en Google Cloud regiones de Europa y usas Cloud DNS con una política de enrutamiento geovallada para enrutar el tráfico a través de balanceadores de carga regionales. Para cumplir los requisitos de residencia de datos de la capa de base de datos, usa una arquitectura fragmentada en lugar de la replicación entre regiones. Con este enfoque, los datos de cada región están aislados, pero no puedes implementar una alta disponibilidad y una conmutación por error entre regiones para la base de datos.

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

Robustez frente a las interrupciones de la infraestructura

En una arquitectura de implementación multirregional, 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 la capacidad adecuada 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 nuevas VMs para mantener el número mínimo de VMs configurado. 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 una de las regiones sufren una interrupción o si se produce una interrupción en toda una región, la aplicación de la otra región seguirá estando disponible y respondiendo. El balanceador de carga externo global dirige el tráfico a la región que no se ve afectada por la interrupción. Una vez que Google haya resuelto la interrupción en la región, debes verificar que la aplicación funciona correctamente en la región afectada.

Si se producen interrupciones en ambas regiones de esta arquitectura, la aplicación no estará disponible. Debe esperar a que Google resuelva la interrupción y, a continuación, verificar que la aplicación funciona correctamente.

Autoescalado de MIG

Si ejecutas tu aplicación en varios MIGs regionales, la aplicación seguirá disponible durante las interrupciones aisladas de zonas o regiones. La función de autoescalado de los MIGs sin estado te permite mantener la disponibilidad y el rendimiento de las aplicaciones en niveles predecibles.

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.

Disponibilidad de la base de datos

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 multirregional Google Cloud que se crea 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 multirregional 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 multirregional 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.

Almacenamiento en caché

Si tu aplicación sirve recursos de sitios web estáticos y tu arquitectura incluye un balanceador de carga de aplicaciones externo global, puedes usar Cloud CDN para almacenar en caché el contenido estático al que se accede con regularidad más cerca de tus usuarios. Cloud CDN puede ayudarte a mejorar el rendimiento para tus usuarios, reducir el uso de recursos de infraestructura en el backend y reducir los costes de distribución de la red. Para obtener más información, consulta Rendimiento web más rápido y protección web mejorada del balanceo de carga.

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
  • Descripción general de Cloud DNS
• 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 consultar más arquitecturas de referencia, guías de diseño y prácticas recomendadas, visita el centro de arquitectura en la nube.

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
• Shobhit Gupta | Arquitecto de soluciones
• Simon Bennett | Responsable de Producto de Grupo
• Steve McGhee | Defensor de la fiabilidad
• Victor Moreno | Product Manager, Cloud Networking