Arquitectura de red de concentrador y radio

Last reviewed 2023-07-12 UTC

En este documento, se presentan dos opciones de arquitectura para configurar una topología de red de concentrador y radio en Google Cloud. Una opción usa la capacidad de intercambio de tráfico de red de la nube privada virtual (VPC) y la otra usa Cloud VPN.

Las empresas pueden separar las cargas de trabajo en redes de VPC individuales para fines de facturación, aislamiento del entorno y otras consideraciones. Sin embargo, es posible que la empresa también necesite compartir recursos específicos entre estas redes, como un servicio compartido o una conexión local. En esos casos, puede ser útil colocar el recurso compartido en una red concentrador y adjuntar las otras redes de VPC como radios. En el siguiente diagrama, se muestra un ejemplo de la red de concentrador y radio resultante, que a veces se denomina topología de estrella.

Esquema de red de concentrador y radio

En este ejemplo, se usan redes de VPC de radio independientes para las cargas de trabajo de unidades de negocios individuales dentro de una empresa grande. Cada red de VPC de radio está conectada a una red de VPC central de concentrador que contiene servicios compartidos y puede servir como el único punto de entrada a la nube desde la red local de la empresa.

Arquitectura en la que se usa el intercambio de tráfico entre redes de VPC

En el siguiente diagrama, se muestra una red de concentrador y radio que usa el intercambio de tráfico entre redes de VPC. El intercambio de tráfico entre redes de VPC permite la comunicación mediante direcciones IP internas entre recursos en redes de VPC independientes. El tráfico permanece en la red interna de Google y no se desvía a la Internet pública.

Arquitectura de concentrador y radio mediante el intercambio de tráfico entre redes de VPC
  • En esta arquitectura, los recursos que necesitan aislamiento a nivel de red usan redes de VPC de radio separadas. Por ejemplo, la arquitectura muestra una VM de Compute Engine en la red de VPC spoke-1. La red de VPC spoke-2 tiene una VM de Compute Engine y un clúster de Google Kubernetes Engine (GKE).
  • Cada red de VPC de radio en esta arquitectura tiene una relación de intercambio de tráfico con una red de VPC de concentrador central.
  • El intercambio de tráfico entre redes de VPC no limita el ancho de banda de la VM. Cada VM puede enviar tráfico con el ancho de banda completo de esa VM individual.
  • Cada red de VPC de radio tiene una puerta de enlace de Cloud NAT para la comunicación saliente con Internet.
  • El intercambio de tráfico entre redes de VPC no proporciona anuncios de ruta transitiva. A menos que se use un mecanismo adicional, la VM en la red spoke-1 no puede enviar tráfico a la VM en la red spoke-2. Para evitar esta restricción de no transitividad, la arquitectura muestra la opción de usar Cloud VPN para reenviar rutas entre las redes. En este ejemplo, los túneles VPN entre la red de VPC de spoke-2 y la red de VPC de concentrador permiten la accesibilidad a la red de VPC de spoke-2 desde los otros radios. Si necesitas conectividad entre solo unos radios específicos, puedes intercambiar tráfico directamente entre esos pares de red de VPC.

Arquitectura en la que se usa Cloud VPN

La escalabilidad de una topología de concentrador y radio que usa intercambio de tráfico entre redes de VPC está sujeta a los límites de intercambio de tráfico entre redes de VPC. Como se señaló antes, las conexiones de intercambio de tráfico entre redes de VPC no permiten el tráfico transitorio más allá de las dos redes de VPC que tienen una relación de intercambio de tráfico. En el siguiente diagrama, se muestra una arquitectura de red de concentrador y radio alternativa que usa Cloud VPN para superar las limitaciones del intercambio de tráfico entre redes de VPC.

Arquitectura de concentrador y radio mediante Cloud VPN
  • Los recursos que necesitan aislamiento a nivel de red usan redes de VPC de radio independientes.
  • Los túneles VPN IPSec conectan cada red de VPC de radio a una red de VPC de concentrador.
  • Hay una zona privada de DNS en la red de concentrador, y una zona de intercambio de tráfico de DNS y una zona privada en cada red de radio.
  • El ancho de banda entre redes está limitado por los anchos de banda de los túneles en total.

Cuando elijas entre las dos arquitecturas analizadas hasta ahora, considera las ventajas relativas del intercambio de tráfico entre redes de VPC y Cloud VPN:

  • El intercambio de tráfico entre redes de VPC tiene restricción de no transitividad, pero admite el ancho de banda completo que define el tipo de máquina de las VM y otros factores que determinan el ancho de banda de la red. Sin embargo, puedes agregar enrutamiento transitivo si agregas túneles VPN.
  • Cloud VPN permite el enrutamiento transitivo, pero el ancho de banda total (entrada y salida) se limita a los anchos de banda de los túneles.

Alternativas de diseño

Considera las siguientes alternativas de arquitectura para la interconexión de recursos que se implementan en redes de VPC independientes en Google Cloud:

Conectividad entre radios mediante una puerta de enlace en la red de VPC del concentrador
Si deseas habilitar la comunicación entre radios, puedes implementar un dispositivo virtual de red (NVA) o un firewall de última generación (NGFW) en la red de VPC del concentrador para que funcione como puerta de enlace de radio para el tráfico de radio. Consulta Dispositivos de red centralizados en Google Cloud.
Intercambio de tráfico entre redes de VPC sin concentrador
Si no necesitas control centralizado sobre la conectividad local o los servicios de uso compartido en redes de VPC, no es necesario usar una red de VPC de concentrador. Puedes configurar el intercambio de tráfico para los pares de redes de VPC que requieren conectividad y administrar las interconexiones de forma individual. Ten en cuenta los límites para la cantidad de relaciones de intercambio de tráfico por red de VPC.
Varias redes de VPC compartidas

Crea una red de VPC compartida para cada grupo de recursos que quieras aislar a nivel de red. Por ejemplo, si deseas separar los recursos utilizados en entornos de producción y desarrollo, crea una red de VPC compartida para producción y otra red de VPC compartida para desarrollo. Luego, realiza un intercambio de tráfico entre las dos redes de VPC para habilitar la comunicación entre las redes de VPC. Los recursos de proyectos individuales para cada aplicación o departamento pueden usar los servicios de la red de VPC compartida adecuada.

Para la conectividad entre las redes de VPC y tu red local, puedes usar túneles VPN separados para cada red de VPC o adjuntos de VLAN independientes en la misma conexión de interconexión dedicada.

¿Qué sigue?