Herramientas de redes para cargas de trabajo de nubes híbridas y múltiples: arquitecturas de referencia

Last reviewed 2023-11-13 UTC

Este documento forma parte de una serie en la que se describen las arquitecturas de redes y seguridad para las empresas que migran cargas de trabajo de centros de datos a Google Cloud.

La serie consiste en los siguientes documentos:

En este documento, se analizan las herramientas de redes para una situación en la que las cargas de trabajo se ejecutan en más de un lugar, como uno local o la nube, o en varios entornos de nube.

Arquitectura lift-and-shift

La primera situación de acceso a la carga de trabajo híbrida es una arquitectura lift-and-shift.

Establecimiento de la conectividad privada

Puedes establecer conectividad a redes locales mediante la interconexión dedicada o la interconexión de socio. En la topología ilustrada en la figura 1, se muestra cómo puedes usar cuatro conexiones de Interconnect en dos áreas metropolitanas diferentes y dominios de disponibilidad perimetral diferentes para obtener un 99.99% de disponibilidad mediante la interconexión dedicada. Para obtener más información y recomendaciones detalladas, consulta Conectividad híbrida entre un entorno local y Google Cloud en el plano de bases empresariales.

Configuración de conexiones redundantes de Cloud Interconnect para una disponibilidad del 99.99%.

Figura 1. Configuración de conexiones redundantes de Cloud Interconnect para una disponibilidad del 99.99%.

Network Connectivity Center te permite usar la red de Google para la transferencia de datos entre varios sitios locales o alojados en la nube. Este enfoque te permite aprovechar el alcance y la confiabilidad de la red de Google cuando necesites mover datos. Puedes usar tus dispositivos de router de Cloud VPN, Cloud Interconnect y SD-WAN existentes como radios de Network Connectivity Center para admitir la transferencia de datos entre las redes locales y sitios de sucursales, como se muestra en la Figura 2.

Configuración de Network Connectivity Center que conecta diferentes redes empresariales locales fuera de Google Cloud mediante la red troncal de Google.

Figura 2. Configuración de Network Connectivity Center que conecta diferentes empresas locales y otras redes de nube fuera de Google Cloud mediante la red troncal de Google.

Para obtener más información sobre cómo configurar Network Connectivity Center, consulta Consideraciones en la documentación de Network Connectivity Center.

Dispositivos SD-WAN

Network Connectivity Center te permite usar un dispositivo virtual de red de terceros como radio de Network Connectivity Center para establecer la conectividad entre un sitio externo y tus recursos de red de VPC. Un dispositivo de router podría ser un router SD-WAN de terceros compatible con uno de nuestros socios o cualquier otro dispositivo virtual que te permita intercambiar rutas con la instancia de Cloud Router. Estas soluciones basadas en dispositivos se suman a las opciones actuales de conectividad de sitio a nube que están disponibles con Cloud VPN y Cloud Interconnect como radios. En la figura 3, se muestra una topología que usa dispositivos SD-WAN.

Configuración de Network Connectivity Center mediante el dispositivo del router para integrar la implementación de SD-WAN en la red de Google.

Figura 3. Configuración de Network Connectivity Center mediante el dispositivo del router para integrar la implementación de SD-WAN a la red de Google.

Puedes usar dispositivos de terceros para realizar funciones de seguridad. Las capacidades de seguridad del dispositivo se pueden integrar en el dispositivo del router como se muestra en la figura 3. También es un patrón común usar un dispositivo virtual de red, en el que el tráfico de las instalaciones locales llega a una red de VPC de tránsito y el dispositivo establece la conectividad con la red de VPC de la carga de trabajo, como se muestra en la figura 4.

Para obtener más información sobre cómo configurar Network Connectivity Center, consulta Consideraciones en la documentación de Network Connectivity Center.

Arquitectura de servicios híbridos

Al igual que en el caso de uso dentro de la nube que se analiza en Herramientas de redes para el acceso seguro a la nube: arquitecturas de referencia, Network Connectivity Center permite la conectividad desde los sitios de sucursales y las redes locales a Google Cloud. Private Service Connect proporciona acceso privado a los servicios administrados por Google o te permite consumir otros servicios que se compilan y se implementan en la nube.

También puedes implementar la seguridad de red mediante una combinación de Controles del servicio de VPC, firewalls de Google Cloud y dispositivos virtuales de red, como se muestra en la figura 4.

Redes con una arquitectura que usa un patrón lift-and-shift y un patrón de diseño de servicios híbridos diseñado para proporcionar un plano de datos seguro.

Figura 4. Redes con una arquitectura que usa un patrón lift-and-shift y un patrón de diseño de servicios híbridos diseñado para proporcionar un plano de datos seguro.

Arquitectura distribuida de confianza cero

En un entorno híbrido, los microservicios se ejecutan en mallas de servicios que se implementan en diferentes proveedores de servicios en la nube y entornos locales. Puedes ayudar a proteger la comunicación entre los microservicios mediante las políticas de autorización y mTLS. Es normal que las empresas compilen mallas de servicios en la nube y extiendan las mallas a las instalaciones locales. En la figura 5, se muestra un ejemplo en el que los servicios que se implementan de forma local acceden a los servicios en la nube. La mTLS de extremo a extremo entre los servicios se habilita mediante la puerta de enlace este-oeste y el enrutamiento basado en SNI. Cloud Service Mesh te ayuda a proteger las comunicaciones de servicio a servicio, lo que te permite configurar políticas de autorización para los servicios y, luego, implementar certificados y claves que proporciona una autoridad certificadora administrada.

Los entornos híbridos suelen tener varias implementaciones de malla, como varios clústeres de GKE. Un componente importante en este flujo es el enrutamiento de SNI, que se usa en la puerta de enlace este-oeste de GKE para cada clúster. Esta configuración permite que la puerta de enlace enrute mTLS directamente a la carga de trabajo y, al mismo tiempo, conserve la conectividad de mTLS de extremo a extremo.

Malla de servicios de confianza cero implementada en un entorno local y Google Cloud.

Figura 5. Malla de servicios de confianza cero implementada en un entorno local y Google Cloud.

Las empresas pueden usar Cloud Service Mesh para realizar implementaciones en varias nubes. Para abordar los desafíos de administrar identidades y certificados en los proveedores de servicios en la nube, Cloud Service Mesh proporciona identidad de carga de trabajo y una autoridad certificadora (AC) en el clúster intermedia, por medio del servicio de AC (CA Service). La CA intermedia puede encadenarse a una CA externa o se puede alojar en Google. Puedes personalizar los atributos de CA, como la región y el algoritmo de firma, mediante HSM de propiedad de la empresa y Cloud HSM.

Workload Identity te permite asignar identidades y autorizaciones distintas y detalladas para cada microservicio de tu clúster. Cloud Service Mesh administra el proceso de emisión de certificados y de rotación automática de claves y certificados sin interrumpir las comunicaciones. También proporciona una única raíz de confianza en los clústeres de GKE.

En la figura 6, se muestra una arquitectura que usa Cloud Service Mesh para administrar la identidad y la autorización.

Los servicios en la malla pueden acceder a los servicios de Google Cloud mediante la federación de Workload Identity. Esta función permite que los servicios actúen con la autoridad de una cuenta de servicio de Google cuando invocan las APIs de Google Cloud. La federación de Workload Identity también permite que la malla de servicios instalada en otros proveedores de servicios en la nube acceda a las APIs de Google Cloud.

Malla de servicios de confianza cero implementada en las nubes.

Figura 6. Malla de servicios de confianza cero implementada en las nubes.

Puedes usar Cloud Service Mesh para enrutar el tráfico de la malla a las instalaciones locales o a cualquier otra nube.

Por ejemplo, puedes crear servicios en Cloud Service Mesh llamados on-prem-service y other-cloud-service, y agregar grupos de extremos de red de conectividad híbrida (NEG) que tengan extremos 10.1.0.1:80 y 10.2.0.1:80. Luego, Cloud Service Mesh envía el tráfico a sus clientes, que son proxies de sidecar de la malla que se ejecutan junto con las aplicaciones. Por lo tanto, cuando tu aplicación envía una solicitud al servicio on-prem-service, el cliente de Cloud Service Mesh inspecciona la solicitud y la dirige al extremo 10.0.0.1:80. En la figura 7, se ilustra esta configuración.

El tráfico que se dirige desde una malla de servicios mediante Cloud Service Mesh.

Figura 7. El tráfico que se dirige desde una malla de servicios mediante Cloud Service Mesh.

También puedes incorporar funciones avanzadas, como la dirección de tráfico basada en el peso, tal como se muestra en la figura 8. Esta capacidad te permite habilitar necesidades empresariales críticas, como la migración a la nube. Cloud Service Mesh sirve como plano de control versátil y administrado a nivel global para las mallas de servicios.

Tráfico ponderado dirigido mediante Cloud Service Mesh.

Figura 8. Tráfico ponderado dirigido mediante Cloud Service Mesh.

¿Qué sigue?