Arquitectura y rendimiento de Private Service Connect

En esta página, se explica cómo funciona Private Service Connect.

Private Service Connect se implementa con una red definida por software (SDN) de Google Cloud llamada Andromeda (PDF). Andromeda es el plano de control y de datos distribuido para las redes deGoogle Cloud que habilita las redes de nube privada virtual (VPC). La estructura de red de Andromeda procesa paquetes en los servidores físicos que alojan las VMs. Como resultado, el plano de datos está completamente distribuido y no tiene cuellos de botella centralizados en proxies o dispositivos intermedios.

Debido a que el tráfico de Private Service Connect se procesa por completo en los hosts físicos, tiene importantes beneficios de rendimiento en comparación con un modelo orientado al proxy:

  • Private Service Connect no impone límites de ancho de banda adicionales. El ancho de banda combinado de las interfaces de VM de origen y destino es, en realidad, el límite de ancho de banda de Private Service Connect.
  • Private Service Connect agrega una latencia mínima al tráfico. La ruta de tráfico es la misma que el tráfico de VM a VM dentro de una sola red de VPC. La traducción de direcciones de red del tráfico es el único paso de procesamiento de tráfico adicional que se realiza por completo en el host de destino.

En el siguiente diagrama, se muestra una ruta de tráfico típica para el tráfico de Private Service Connect entre una red de VPC del consumidor y una red de VPC del productor.

Los hosts físicos realizan el balanceo de cargas de los clientes para determinar a qué host de destino se enviará el tráfico (haz clic para ampliar).

Desde una perspectiva lógica, hay extremos de consumidor Private Service Connect y balanceadores de cargas del productor. Sin embargo, desde una perspectiva física, el tráfico va directamente del servidor físico que aloja la VM de cliente al servidor físico que aloja la VM del balanceador de cargas del productor.

Andromeda aplica funciones al tráfico de Private Service Connect, como se muestra en el siguiente diagrama:

  • El balanceo de cargas del cliente se aplica en el host de origen (Host 1), que decide a qué host de destino se enviará el tráfico. Esta decisión se basa en la ubicación, la carga y el estado.
  • El paquete interno de VPC1 se encapsula en un encabezado de Andromeda con la red de destino de VPC2.
  • El host de destino (Host 2) aplica SNAT y DNAT al paquete, mediante la subred NAT como el rango de direcciones IP de origen del paquete y la dirección IP del balanceador de cargas del productor como la dirección IP de destino.

Hay excepciones en las que los hosts de enrutamiento intermedio procesan el tráfico, como el tráfico interregional o los flujos de tráfico muy pequeños o intermitentes. Sin embargo, Andromeda descarga de forma dinámica los flujos de tráfico para las redes de host a host directo siempre que sea posible para optimizar la latencia y la capacidad de procesamiento.

¿Qué sigue?