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:
- Diseña redes para migrar cargas de trabajo empresariales: enfoques arquitectónicos
- Herramientas de redes para el acceso seguro dentro de la nube: Arquitecturas de referencia
- Herramientas de redes para la entrega de aplicaciones orientadas a Internet: arquitecturas de referencia
- Herramientas de redes para cargas de trabajo de nubes híbridas y múltiples: arquitecturas de referencia (este documento)
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.
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.
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.
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.
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. Anthos 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 el enrutamiento directo al trabajo de mTLS por parte de la puerta de enlace, a la vez que se conserva la conectividad de mTLS de extremo a extremo.
Figura 5. Malla de servicios de confianza cero implementada en un entorno local y Google Cloud.
Las empresas pueden usar Anthos 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, Anthos Service Mesh proporciona identidad de carga de trabajo y una autoridad certificadora (CA) en el clúster intermedia, por medio del servicio de CA (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. Anthos 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 Anthos 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.
Figura 6. Malla de servicios de confianza cero implementada en las nubes.
Puedes usar Traffic Director para enrutar el tráfico de la malla a las instalaciones locales o a cualquier otra nube.
Por ejemplo, puedes crear servicios en Traffic Director 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, Traffic Director 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 Traffic Director inspecciona la solicitud y la dirige al extremo 10.0.0.1:80. En la figura 7, se ilustra esta configuración.
Figura 7. El tráfico que se dirige desde una malla de servicios mediante Traffic Director.
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. Traffic Director sirve como plano de control versátil y administrado a nivel global para las mallas de servicios.
Figura 8. Tráfico ponderado dirigido mediante Traffic Director.
¿Qué sigue?
- Herramientas de redes para el acceso seguro dentro de la nube: Arquitecturas de referencia.
- Herramientas de redes para la entrega de aplicaciones orientadas a Internet: arquitecturas de referencia
- La migración a Google Cloud puede ayudarte a planificar, diseñar y, luego, implementar el proceso de migración de tus cargas de trabajo en Google Cloud.
- El documento Diseño de zonas de destino en Google Cloud tiene orientación para crear una red de zona de destino.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.