Este documento forma parte de una serie en la que se describen las arquitecturas de redes y seguridad para empresas que están migrando cargas de trabajo de centros de datos a Google Cloud.
La serie consta de los siguientes documentos:
- Diseñar redes para migrar cargas de trabajo empresariales: enfoques de arquitectura
- Redes para un acceso seguro entre nubes: arquitecturas de referencia
- Redes para la entrega de aplicaciones orientadas a Internet: arquitecturas de referencia
- Redes para cargas de trabajo híbridas y multinube: arquitecturas de referencia (este documento)
En este documento se analiza la creación de redes en un escenario en el que las cargas de trabajo se ejecutan en más de un lugar, como on-premise y en la nube, o en varios entornos de nube.
Arquitectura de lift-and-shift
El primer escenario de acceso a cargas de trabajo híbridas es una arquitectura de lift-and-shift.
Establecer conectividad privada
Puedes establecer la conectividad con redes on-premise mediante una interconexión dedicada o Partner Interconnect. En la topología que se muestra en la figura 1 se explica cómo puede usar cuatro conexiones de interconexión dedicada en dos áreas metropolitanas diferentes y en distintos dominios de disponibilidad de borde para conseguir una disponibilidad del 99,99%. También puedes conseguir una disponibilidad del 99,99% con Partner Interconnect.
Para conectar tus Google Cloud redes con las redes alojadas por otro proveedor de servicios en la nube, usa Cross-Cloud Interconnect.
Para obtener más información y recomendaciones detalladas, consulta la sección sobre conectividad híbrida entre un entorno local y Google Cloud en el plan técnico de las bases de la empresa.
Imagen 1. Configuración de conexiones de interconexión dedicada redundantes para lograr una disponibilidad del 99,99 %.
Network Connectivity Center te permite usar la red de Google para transferir datos entre varios sitios on-premise o alojados en la nube. Este método te permite aprovechar la cobertura y la fiabilidad de la red de Google cuando necesites mover datos. Puede usar sus redes de Cloud VPN, Cloud Interconnect, SD-WAN y VPC como radios de Network Connectivity Center para admitir la transferencia de datos entre las redes on-premise, las sucursales, otros proveedores de servicios en la nube y las redes deGoogle Cloud VPC, tal como se muestra en la figura 2.
Imagen 2. Configuración de Network Connectivity Center para conectar diferentes redes empresariales locales y otras redes en la 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 las consideraciones de la documentación de Network Connectivity Center.
Dispositivos SD-WAN
Network Connectivity Center te permite usar un dispositivo router de terceros como radio de Network Connectivity Center para establecer la conectividad entre un sitio externo y los recursos de tu red VPC. Un dispositivo de router puede ser un router SD-WAN de terceros compatible con uno de nuestros partners u otro dispositivo virtual que te permita intercambiar rutas con la instancia de Cloud Router. Estas soluciones basadas en dispositivos se suman a las opciones de conectividad de sitio a nube que ya 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.
Imagen 3. Configuración de Network Connectivity Center mediante el dispositivo router para integrar tu implementación de SD-WAN con la red de Google.
Puedes usar dispositivos de terceros para realizar funciones de seguridad. Las funciones de seguridad del dispositivo se pueden integrar en el dispositivo de router, como se muestra en la figura 3. También es habitual usar un dispositivo virtual de red, donde el tráfico local 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, tal como se muestra en la figura 4.
Para obtener más información sobre cómo configurar Network Connectivity Center, consulta las consideraciones de la documentación de Network Connectivity Center.
Arquitectura de servicios híbridos
Al igual que en el caso práctico de la nube interna que se describe en Redes para el acceso seguro en la nube: arquitecturas de referencia, Network Connectivity Center permite la conectividad desde tus sucursales y redes on-premise a Google Cloud. Private Service Connect proporciona acceso privado a servicios gestionados por Google o te permite consumir otros servicios creados e implementados en la nube.
También puedes implementar la seguridad de red mediante una combinación de Controles de Servicio de VPC, Google Cloud cortafuegos y dispositivos virtuales de red, como se muestra en la figura 4.
Imagen 4. Redes con una arquitectura que utiliza tanto un patrón de lift-and-shift como 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 despliegan en diferentes proveedores de servicios en la nube y entornos on‐premise. Puedes proteger la comunicación entre los microservicios mediante la seguridad de la capa de transporte mutua (mTLS) y las políticas de autorización. Es una práctica habitual que las empresas creen mallas de servicios en la nube y las amplíen a entornos locales. En la imagen 5 se muestra un ejemplo en el que los servicios implementados de forma local acceden a los servicios en la nube. El mTLS de extremo a extremo entre los servicios se habilita mediante la pasarela este-oeste y el enrutamiento basado en el indicador del nombre del servidor (SNI). Cloud Service Mesh te ayuda a proteger las comunicaciones entre servicios, lo que te permite configurar políticas de autorización para los servicios y desplegar certificados y claves proporcionados por una autoridad de certificación gestionada.
Los entornos híbridos suelen incluir varios despliegues de malla, como varios clústeres de GKE. Un componente importante de este flujo es el enrutamiento SNI, que se usa en la puerta de enlace este-oeste de GKE de cada clúster. Esta configuración permite el enrutamiento mTLS directo a la carga de trabajo por parte de la pasarela, al tiempo que se mantiene la conectividad mTLS de extremo a extremo.
Imagen 5. Malla de servicios de confianza cero implementada en un entorno local y en Google Cloud.
Las empresas pueden usar Cloud Service Mesh para realizar despliegues en varias nubes. Para hacer frente a los problemas que conlleva gestionar identidades y certificados en distintos proveedores de servicios en la nube, Cloud Service Mesh proporciona identidad de carga de trabajo y una autoridad de certificación (CA) intermedia en el clúster mediante el servicio de CA. La CA intermedia se puede encadenar a una CA externa o se puede alojar en Google. Puedes personalizar los atributos de la AC, como la región y el algoritmo de firma, usando tanto HSMs propiedad de la empresa como Cloud HSM.
Workload Identity te permite asignar identidades distintas y detalladas, así como autorizaciones a cada microservicio de tu clúster. Cloud Service Mesh gestiona 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 todos los clústeres de GKE.
En la figura 6 se muestra una arquitectura que usa Cloud Service Mesh para gestionar la identidad y la autorización.
Los servicios de la malla pueden acceder a los Google Cloud servicios mediante la federación de identidades de cargas de trabajo. Esta función permite que los servicios actúen con la autoridad de una cuenta de servicio de Google cuando invocan APIs. Google Cloud La federación de identidades de carga de trabajo también permite que la malla de servicios instalada en otros proveedores de nube acceda a las APIs de Google Cloud.
Imagen 6. Malla de servicios de confianza cero implementada en varias nubes.
Puedes usar Cloud Service Mesh para enrutar el tráfico de la malla a un entorno local o a cualquier otra nube.
Por ejemplo, puedes crear servicios en Cloud Service Mesh llamados on-prem-service y other-cloud-service, y añadir grupos de puntos finales de red (NEGs) de conectividad híbrida
que tengan los endpoints 10.1.0.1:80 y 10.2.0.1:80.
A continuación, Cloud Service Mesh envía el tráfico a sus clientes, que son proxies sidecar de la malla que se ejecutan junto a tus 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 endpoint 10.2.0.1:80. En la figura 7 se muestra esta configuración.
Imagen 7. Tráfico dirigido desde una malla de servicios mediante Cloud Service Mesh.
También puedes incorporar funciones avanzadas, como el enrutamiento del tráfico basado en el peso, como se muestra en la figura 8. Esta función te permite habilitar necesidades empresariales críticas, como la migración a la nube. Cloud Service Mesh actúa como un plano de control versátil y gestionado a nivel mundial para tus mallas de servicios.
Imagen 8. Tráfico ponderado dirigido mediante Cloud Service Mesh.
Siguientes pasos
- Redes para un acceso seguro entre nubes: arquitecturas de referencia.
- Redes para la entrega de aplicaciones orientadas a Internet: arquitecturas de referencia
- Migración a Google Cloud puede ayudarte a planificar, diseñar e implementar el proceso de migración de tus cargas de trabajo a Google Cloud.
- Diseño de la zona de aterrizaje en Google Cloud incluye directrices para crear una red de zona de aterrizaje.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.