Segmentación y conectividad de red para aplicaciones distribuidas en Cross-Cloud Network

Last reviewed 2024-04-05 UTC

Este documento forma parte de una serie de guías de diseño para Cross-Cloud Network.

La serie consta de las siguientes partes:

En esta parte, se explora la estructura y la conectividad de la segmentación de red, que es la base del diseño. En este documento, se explican las fases en las que debes tomar las siguientes decisiones:

  • La segmentación de red general y la estructura del proyecto.
  • Dónde ubicas tu carga de trabajo.
  • Cómo se conectan tus proyectos a redes locales externas y otras redes de proveedores de servicios en la nube, incluido el diseño para la conectividad, el enrutamiento y la encriptación.
  • Cómo tus redes de VPC se conectan entre sí de forma interna.
  • Cómo las subredes de VPC de Google Cloud se conectan entre sí y con otras redes, incluida la forma en que configuras la accesibilidad del servicio y el DNS.

Segmentación de red y estructura del proyecto

Durante la etapa de planificación, debes decidir entre una de las dos estructuras del proyecto:

  • Un proyecto host de infraestructura consolidada, en el que usas un proyecto host de infraestructura único para administrar todos los recursos de red de todas las aplicaciones
  • Proyectos host segmentados, en los que usas un proyecto host de infraestructura en combinación con un proyecto host diferente para cada aplicación

Durante la etapa de planificación, te recomendamos que también decidas los dominios administrativos para tus entornos de carga de trabajo. Determinar el alcance de los permisos para tus administradores y desarrolladores de infraestructura según el principio de privilegio mínimo y definir el alcance de los recursos de la aplicación en diferentes proyectos de aplicaciones. Debido a que los administradores de infraestructura deben configurar la conectividad para compartir recursos, los recursos de infraestructura se pueden manejar dentro de un proyecto de infraestructura. Por ejemplo, para configurar la conectividad con los recursos de infraestructura compartidos, los administradores de infraestructura pueden usar un proyecto de infraestructura para manejar esos recursos compartidos. Al mismo tiempo, el equipo de desarrollo puede administrar sus cargas de trabajo en un proyecto y el equipo de producción puede administrar sus cargas de trabajo en un proyecto independiente. Luego, los desarrolladores usarán los recursos de infraestructura en el proyecto de infraestructura para crear y administrar recursos, servicios, balanceo de cargas y políticas de enrutamiento de DNS para sus cargas de trabajo.

Además, debes decidir cuántas redes de VPC implementarás en un principio y cómo se organizarán en tu jerarquía de recursos. Para obtener detalles sobre cómo elegir una jerarquía de recursos, consulta Elige una jerarquía de recursos para la zona de destino de Google Cloud. Para obtener detalles sobre cómo elegir la cantidad de redes de VPC, consulta Decide si crear o no varias redes de VPC.

En el caso de Cross-Cloud Network, recomendamos usar las siguientes VPC:

  • Una o más VPC de aplicaciones para alojar los recursos de las diferentes aplicaciones.
  • Una VPC de tránsito, en la que se maneja toda la conectividad externa.
  • Una VPC de servicios centrales opcional, que se puede usar para consolidar la implementación del acceso privado a los servicios publicados.

En el siguiente diagrama, se muestra una representación visual de la estructura de VPC recomendada que se acaba de describir. Puedes usar la estructura de VPC que se muestra en el diagrama con un proyecto consolidado o segmentado, como se describe en las secciones posteriores. En el diagrama que se muestra aquí, no se muestra la conectividad entre las redes de VPC.

Estructura de VPC recomendada

Proyecto host de infraestructura consolidada

Puedes usar un proyecto host de infraestructura consolidada para administrar todos los recursos de red, como subredes, intercambio de tráfico y balanceadores de cargas.

Se pueden crear varias VPC compartidas de aplicaciones con sus proyectos de servicio de aplicaciones correspondientes en el proyecto host de infraestructura para que coincidan con la estructura de la organización. Usa varios proyectos de servicio de aplicaciones para delegar la administración de recursos. Todas las herramientas de redes en todas las VPC de aplicaciones se facturan en el proyecto host de infraestructura consolidada.

Para esta estructura del proyecto, muchos proyectos de servicio de aplicaciones pueden compartir una cantidad menor de VPC de aplicaciones.

En el siguiente diagrama, se proporciona una representación visual del proyecto host de infraestructura consolidada y varios proyectos de servicio de aplicaciones que se acaban de describir. En el diagrama, no se muestra la conectividad entre todos los proyectos.

Proyecto host de infraestructura consolidada y varios proyectos de servicio de aplicaciones

Proyectos host segmentados

En este patrón, cada grupo de aplicaciones tiene su propio proyecto host de aplicación y VPC. Se pueden conectar varios proyectos de servicio de aplicaciones al proyecto host. La facturación de los servicios de red se divide entre el proyecto host de infraestructura y los proyectos host de aplicaciones. Los cargos de infraestructura se facturan al proyecto host de infraestructura y los cargos de red de las aplicaciones se facturan a cada proyecto host de la aplicación.

En el siguiente diagrama, se proporciona una representación visual de los varios proyectos host y proyectos de servicio de aplicaciones que se acaban de describir. En el diagrama, no se muestra la conectividad entre todos los proyectos.

Varios proyectos host y varios proyectos de servicio de aplicaciones

Posición de la carga de trabajo

Muchas opciones de conectividad dependen de las ubicaciones regionales de tus cargas de trabajo. Si deseas obtener orientación sobre cómo colocar las cargas de trabajo, consulta Prácticas recomendadas para la selección de regiones de Compute Engine. Debes decidir dónde se encontrarán tus cargas de trabajo antes de elegir las ubicaciones de conectividad.

Conectividad híbrida y externa

En esta sección, se describen los requisitos y las recomendaciones para las siguientes rutas de conectividad:

  • Conexiones privadas a otros proveedores de servicios en la nube
  • Conexiones privadas a centros de datos locales
  • Conectividad a Internet para cargas de trabajo, en especial la conectividad saliente

Cross-Cloud Network implica la interconexión de múltiples redes de nubes o locales. Las redes externas pueden ser de propiedad y administración de diferentes organizaciones. Estas redes se conectan físicamente entre sí en una o más interfaces de red a red (NNI). La combinación de las NNI debe diseñarse, aprovisionarse y configurarse para mejorar el rendimiento, la resiliencia, la privacidad y la seguridad.

Para la modularidad, la reutilización y la capacidad de insertar NVA de seguridad, coloca conexiones externas y enrutamiento en una VPC de tránsito, que luego funciona como un servicio de conectividad compartida para otras VPC. Las políticas de enrutamiento para la resiliencia, la conmutación por error y la preferencia de ruta de acceso entre dominios se pueden configurar una vez en la VPC de tránsito y muchas otras redes de VPC pueden aprovecharlas.

El diseño de las NNI y la conectividad externa se usa más adelante para la conectividad interna y las herramientas de redes de VPC.

En el siguiente diagrama, se muestra la VPC de tránsito que funciona como un servicio de conectividad compartida para otras VPC, que están conectadas a través del intercambio de tráfico entre redes de VPC, Network Connectivity Center o VPN con alta disponibilidad:

VPC de tránsito que se usa como servicio de conectividad compartida para otras VPC

Conexiones privadas a otros proveedores de servicios en la nube

Si tienes servicios que se ejecutan en otras redes de proveedores de servicios en la nube (CSP) que deseas conectar a tu red de Google Cloud, puedes conectarte a ellos a través de Internet o conexiones privadas. Recomendamos conexiones privadas.

Cuando elijas las opciones, ten en cuenta la capacidad de procesamiento, la privacidad, el costo y la viabilidad operativa.

Para maximizar la capacidad de procesamiento y mejorar la privacidad, usa una conexión directa de alta velocidad entre las redes de la nube. Las conexiones directas eliminan la necesidad de equipos de redes físicas intermedios. Te recomendamos usar Cross-Cloud Interconnect, que proporciona estas conexiones directas, así como encriptación MACsec y una tasa de capacidad de procesamiento de hasta 100 Gbps por vínculo.

Si no puedes usar Cross-Cloud Interconnect, puedes usar la interconexión dedicada o la interconexión de socio a través de una instalación de colocación.

Selecciona las ubicaciones en las que te conectas a los otros CSP según la proximidad de la ubicación a las regiones de destino. Para la selección de la ubicación, considera lo siguiente:

  • Consulta la lista de ubicaciones:
    • En el caso de Cross-Cloud Interconnect, consulta la lista de ubicaciones disponibles para Google Cloud y CSP (la disponibilidad varía según el proveedor de servicios en la nube).
    • En el caso de la interconexión dedicada o de socio, elige una ubicación de baja latencia para la instalación de colocación.
  • Evalúa la latencia entre el perímetro del punto de presencia (POP) determinado y la región relevante en cada CSP.

Para maximizar la confiabilidad de tus conexiones entre nubes, recomendamos una configuración que admita un ANS de tiempo de actividad del 99.99% para las cargas de trabajo de producción. Para obtener más detalles, consulta Alta disponibilidad de Cross-Cloud Interconnect, Establece una disponibilidad del 99.99% para la interconexión dedicada y Establece una disponibilidad del 99.99% para la interconexión de socio.

Si no necesitas un ancho de banda alto entre diferentes CSP, es posible usar túneles VPN. Este enfoque puede ayudarte a comenzar y puedes actualizar a Cross-Cloud Interconnect cuando tus aplicaciones distribuidas usen más ancho de banda. Los túneles VPN también pueden lograr un ANS del 99.99%. Para obtener más información, consulta Topologías de VPN con alta disponibilidad.

Conexiones privadas a centros de datos locales

Para la conectividad a centros de datos privados, puedes usar una de las siguientes opciones de conectividad híbrida:

  • Interconexión dedicada
  • Interconexión de socio
  • VPN con alta disponibilidad

Las consideraciones de enrutamiento para estas conexiones son similares a las de las conexiones privadas a otros proveedores de servicios en la nube.

En el siguiente diagrama, se muestran las conexiones a las redes locales y cómo los routers locales pueden conectarse a Cloud Router a través de una política de intercambio de tráfico:

Conexiones a redes locales

Enrutamiento entre dominios con redes externas

Para aumentar la resiliencia y la capacidad de procesamiento entre las redes, usa varias rutas de acceso para conectar las redes.

Cuando el tráfico se transfiere entre dominios de red, debe inspeccionarse con dispositivos de seguridad con estado. Como resultado, se requiere la simetría del flujo en el límite entre los dominios.

En el caso de las redes que transfieren datos entre varias regiones, el costo y el nivel de calidad del servicio de cada red pueden diferir de manera significativa. Es posible que decidas usar algunas redes en lugar de otras, según estas diferencias.

Configura tu política de enrutamiento entre dominios para cumplir con los requisitos de tránsito interregional, simetría del tráfico, capacidad de procesamiento y resiliencia.

La configuración de las políticas de enrutamiento entre dominios depende de las funciones disponibles en el perímetro de cada dominio. La configuración también depende de cómo se estructuran los dominios cercanos desde la perspectiva de un sistema autónomo y un direccionamiento IP (subredes) en diferentes regiones. Para mejorar la escalabilidad sin exceder los límites de prefijos en los dispositivos perimetrales, te recomendamos que tu plan de direccionamiento de IP genere menos prefijos agregados para cada región y combinación de dominio.

Cuando diseñes el enrutamiento interregional, ten en cuenta lo siguiente:

  • Las redes de VPC de Google Cloud y Cloud Router admiten el enrutamiento global entre regiones. Otros CSP pueden tener VPC regionales y alcances del protocolo de puerta de enlace de frontera (BGP). Para obtener más detalles, consulta la documentación de tu otro CSP.
  • Cloud Router anuncia rutas automáticamente con preferencias de ruta predeterminadas según la proximidad regional. Este comportamiento de enrutamiento depende del modo de enrutamiento dinámico configurado de la VPC. Es posible que debas anular estas preferencias para el comportamiento de enrutamiento que deseas.
  • Los diferentes CSP admiten distintas funciones de BGP y detección de reenvío bidireccional (BFD), y Cloud Router de Google también tiene capacidades específicas de política de ruta, como se describe en Establece sesiones de BGP.
  • Diferentes CSP pueden usar distintos atributos de desempate de BGP para determinar la preferencia de las rutas. Consulta la documentación de tu CSP para obtener más detalles.

Enrutamiento entre dominios de una sola región

Sugerimos que comiences con el enrutamiento entre dominios de una sola región, que usas para crear varias conexiones de región con enrutamiento entre dominios.

Los diseños que usan Cloud Interconnect deben tener un mínimo de dos ubicaciones de conexión que se encuentren en la misma región, pero en diferentes dominios de disponibilidad perimetral.

Decide si deseas configurar estas conexiones duplicadas en un diseño activo/activo o activo/pasivo:

  • Activo/activo usa el enrutamiento de múltiples rutas de acceso de igual costo (ECMP) para agregar el ancho de banda de ambas rutas y usarlas simultáneamente para el tráfico entre dominios. Cloud Interconnect también admite el uso de vínculos agregados con LACP para alcanzar hasta 200 Gbps de ancho de banda agregado por ruta.
  • Activo/pasivo obliga a un vínculo a ser un modo de espera listo y solo acepta tráfico si se interrumpe el vínculo activo.

Recomendamos un diseño activo/activo para los vínculos dentro de la región. Sin embargo, ciertas topologías de red locales combinadas con el uso de funciones de seguridad con estado pueden necesitar un diseño activo/pasivo.

Se crea una instancia de Cloud Router en varias zonas, lo que proporciona una resiliencia mayor que la que proporciona un solo elemento. En el siguiente diagrama, se muestra cómo todas las conexiones resilientes convergen en un solo Cloud Router dentro de una región. Este diseño puede admitir un ANS de disponibilidad del 99.9% dentro de una sola área metropolitana cuando se siguen los lineamientos para establecer el 99.9% de disponibilidad para la interconexión dedicada.

En el siguiente diagrama, se muestran dos routers locales conectados de forma redundante al servicio administrado de Cloud Router en una sola región:

Las conexiones resilientes pueden usar un solo Cloud Router

Enrutamiento multirregional entre dominios

Para proporcionar conectividad de respaldo, las redes pueden intercambiar tráfico en varias áreas geográficas. Si conectas las redes en varias regiones, el ANS de disponibilidad puede aumentar al 99.99%.

En el siguiente diagrama, se muestran las arquitecturas del ANS del 99.99%. Muestra routers locales en dos ubicaciones diferentes conectadas de manera redundante a los servicios administrados de Cloud Router en dos regiones diferentes.

Conexiones de Cloud Interconnect en varias regiones

Más allá de la resiliencia, el diseño de enrutamiento multirregional debe lograr la simetría del flujo. El diseño también debe indicar la red preferida para las comunicaciones interregionales, lo que puedes hacer con el enrutamiento de papas calientes y frías. Vincula el enrutamiento de papas frías en un dominio con el enrutamiento de papas calientes en el dominio de intercambio de tráfico. Para el dominio de papas frías, recomendamos usar el dominio de red de Google Cloud, que proporciona una funcionalidad de enrutamiento de VPC global.

La simetría de flujo no siempre es obligatoria, pero la asimetría de flujo puede causar problemas con las funciones de seguridad con estado.

En el siguiente diagrama, se muestra cómo puedes usar el enrutamiento de papas calientes y frías para especificar tu red de tránsito interregional preferida. En este caso, el tráfico de los prefijos X y Y permanece en la red de origen hasta que se llega a la región más cercana al destino (enrutamiento de papas frías). El tráfico de los prefijos A y B cambia a la otra red en la región de origen y, luego, viaja a través de la otra red hasta el destino (enrutamiento de papas calientes).

Usar el enrutamiento de papas calientes y frías para especificar tu red de tránsito interregional preferida

Encriptación del tráfico entre dominios

A menos que se indique lo contrario, el tráfico no se encripta en las conexiones de Cloud Interconnect entre diferentes CSP o entre Google Cloud y los centros de datos locales. Si tu organización requiere encriptación para este tráfico, puedes usar las siguientes capacidades:

  • MACsec para Cloud Interconnect: encripta el tráfico a través de conexiones de Cloud Interconnect entre tus routers y los routers perimetrales de Google. Si deseas obtener más detalles, consulta la descripción general de MACsec para Cloud Interconnect.
  • VPN con alta disponibilidad en Cloud Interconnect: usa varios túneles VPN con alta disponibilidad para poder proporcionar el ancho de banda completo de las conexiones subyacentes de Cloud Interconnect. Los túneles VPN con alta disponibilidad están encriptados con IPsec y se implementan a través de conexiones de Cloud Interconnect que también pueden encriptarse con MACsec. En esta configuración, las conexiones de Cloud Interconnect están configuradas para permitir solo el tráfico de VPN con alta disponibilidad. Para obtener más información, consulta Descripción general de la VPN con alta disponibilidad en Cloud Interconnect.

Conectividad a Internet para cargas de trabajo

Para la conectividad a Internet entrante y saliente, se supone que el tráfico de respuesta sigue con estado la dirección inversa de la dirección de la solicitud original.

Por lo general, las funciones que proporcionan conectividad a Internet entrante son independientes de las funciones de Internet saliente, con la excepción de las direcciones IP externas, que proporcionan ambas direcciones de manera simultánea.

Conectividad a Internet entrante

La conectividad a Internet entrante se relaciona principalmente con proporcionar extremos públicos para los servicios alojados en la nube. Algunos ejemplos de esto incluyen la conectividad a Internet a los servidores de aplicaciones web y los servidores de juegos alojados en Google Cloud.

Las funciones principales que proporcionan la conectividad a Internet entrante son los productos de Cloud Load Balancing de Google. El diseño de una red de VPC es independiente de su capacidad de proporcionar conectividad a Internet entrante:

Conectividad a Internet saliente

Los ejemplos de conectividad a Internet saliente (en la que la solicitud inicial se origina desde la carga de trabajo a un destino de Internet) incluyen cargas de trabajo que acceden a las APIs de terceros, descargan paquetes y actualizaciones de software, y envían notificaciones push a los extremos de webhook en Internet.

Para la conectividad saliente, puedes usar las opciones integradas de Google Cloud, como se describe en Compila la conectividad a Internet para VMs privadas. Como alternativa, puedes usar los NVA de NGFW centrales, como se describe en Seguridad de red.

La ruta principal para proporcionar conectividad a Internet saliente es el destino de la puerta de enlace de Internet predeterminado en la tabla de enrutamiento de VPC, que suele ser la ruta predeterminada en las VPC de Google. Las IP externas y Cloud NAT (el servicio de NAT administrado de Google Cloud) requieren una ruta que apunte a la puerta de enlace de Internet predeterminada de la VPC. Por lo tanto, los diseños de enrutamiento de VPC que anulan la ruta predeterminada deben proporcionar conectividad saliente a través de otros medios. Para obtener más información, consulta Descripción general de Cloud Router.

Para proteger la conectividad saliente, Google Cloud ofrece la aplicación del firewall de nueva generación de Cloud y el proxy web seguro para proporcionar un filtrado más profundo en las URL HTTP y HTTPS. Sin embargo, en todos los casos, el tráfico sigue la ruta predeterminada hacia la puerta de enlace de Internet predeterminada o a través de una ruta predeterminada personalizada en la tabla de enrutamiento de VPC.

Usa tus propias IP

Puedes usar direcciones IPv4 de Google para la conectividad a Internet o puedes trasladar tus propias direcciones IP (BYOIP) para usar un espacio IPv4 de tu organización. La mayoría de los productos de Google Cloud que requieren una dirección IP enrutable por Internet admiten el uso de rangos de BYOIP, en su lugar.

También puedes controlar la reputación del espacio de IP con su uso exclusivo. BYOIP ayuda con la portabilidad de la conectividad y puede ahorrar los costos de las direcciones IP.

Conectividad interna y herramientas de redes de VPC

Con el servicio de conectividad híbrida y externa configurado, los recursos en la VPC de tránsito pueden llegar a las redes externas. El siguiente paso es hacer que esta conectividad esté disponible para los recursos alojados en otras VPC.

En el siguiente diagrama, se muestra la estructura general de la VPC, sin importar cómo habilitaste la conectividad externa. Muestra una VPC de tránsito que finaliza las conexiones externas y aloja un Cloud Router en cada región. Cada Cloud Router recibe rutas de sus pares externos a través de las NNI de cada región. Las VPC de las aplicaciones están conectadas a la VPC de tránsito para que puedan compartir la conectividad externa. Además, la VPC de tránsito funciona como un concentrador para las VPC de radio. Las VPC de radio pueden alojar aplicaciones, servicios o una combinación de ambos.

Estructura general de Cross-Cloud Network

Configura también el reenvío de DNS y el intercambio de tráfico en la VPC de tránsito. Para obtener más información, consulta la sección de diseño de infraestructura de DNS.

Para obtener un mejor rendimiento y servicios de herramientas de redes en la nube integrados, recomendamos interconectar las VPC con Cross-Cloud Network o el intercambio de tráfico entre redes de VPC, en lugar de la VPN con alta disponibilidad.

No se puede acceder a los extremos de Private Service Connect ni a los frontends de acceso privado a servicios en el intercambio de tráfico entre redes de VPC ni en Cross-Cloud Network. Recomendamos el uso de VPN con alta disponibilidad para la conectividad entre VPC para superar esas limitaciones. Debido a que el uso de VPN con alta disponibilidad para la conectividad entre VPC puede reducir la capacidad de procesamiento y aumentar la sobrecarga operativa, el diseño de servicios centralizados reduce el intervalo de la implementación de VPN con alta disponibilidad.

Como alternativa, puedes implementar la conectividad transitiva entre VPC en los extremos del servicio publicado si colocas un balanceador de cargas de red de proxy interno frente a los extremos del servicio. Este enfoque tiene algunas limitaciones que se deben tener en cuenta, que se analizan en la sección Conectividad con los radios de Network Connectivity Center a través del balanceo de cargas.

En las siguientes secciones, se analizan los posibles diseños para la conectividad híbrida que admiten la conectividad IP base y las implementaciones de extremos de API.

Conectividad entre VPC para el acceso a servicios compartidos

Cuando los extremos del servicio publicado se implementan en una VPC de servicios, recomendamos que las VPC de aplicaciones se conecten a través del intercambio de tráfico entre redes de VPC al concentrador (VPC de tránsito) y que la VPC de servicios se conecta al concentrador a través de VPN con alta disponibilidad.

En este diseño, la VPC de tránsito es el concentrador y, luego, implementas los puntos de acceso del consumidor para los extremos del servicio privado en una VPC de servicios.

El diseño es una combinación de dos tipos de conectividad:

  • Intercambio de tráfico entre redes de VPC: proporciona conectividad entre la VPC del concentrador y las VPC de aplicaciones.
  • Conexiones entre VPC de VPN con alta disponibilidad: proporcionan conectividad transitiva para la VPC de servicios al concentrador.

Para obtener orientación detallada y planos de configuración para implementar estos tipos de conectividad, consulta Arquitectura de red de concentrador y radio.

Cuando combines estas arquitecturas, planifica las siguientes consideraciones:

  • Redistribución de las subredes de intercambio de tráfico de VPC en el enrutamiento dinámico (a VPN con alta disponibilidad y a opción híbrida)
  • Consideraciones de enrutamiento multirregional
  • Propagación de las rutas dinámicas al intercambio de tráfico de VPC (desde VPN con alta disponibilidad y desde la opción híbrida)

En el siguiente diagrama, se muestra una VPC de servicios conectada a la VPC de tránsito con VPN con alta disponibilidad y las VPC de aplicaciones conectadas a la VPC de tránsito con intercambio de tráfico entre redes de VPC:

VPC de servicios centrales conectada a la VPC de tránsito con VPN con alta disponibilidad y las VPC de aplicaciones conectadas a la VPC de tránsito con intercambio de tráfico entre redes de VPC

La estructura que se muestra en el diagrama anterior contiene estos componentes:

  • Ubicación del cliente: un centro de datos o una oficina remota en la que tienes equipos de red. En este ejemplo, se supone que las ubicaciones están conectadas a través de una red externa.
  • Área metropolitana: un área metropolitana que contiene uno o más dominios de disponibilidad perimetral de Cloud Interconnect. Cloud Interconnect se conecta a otras redes en esas áreas metropolitanas.
  • Proyecto de concentrador: un proyecto que aloja al menos una red de VPC que funciona como concentrador para otras redes de VPC.
  • VPC de tránsito: una red de VPC en el proyecto del concentrador que llega a conexiones desde entornos locales y otros CSP y, luego, funciona como una ruta de tránsito de otras VPC a redes locales y de CSP.
  • Proyectos host de aplicaciones y VPC: proyectos y redes de VPC que alojan varias aplicaciones.
  • VPC de servicios: una red de VPC que aloja el acceso centralizado a los servicios que necesitan las aplicaciones en las redes de VPC de aplicaciones.
  • VPC de servicios administrados: los servicios que proporcionan y administran otras entidades, pero accesibles para las aplicaciones que se ejecutan en redes de VPC.

Para el diseño de concentrador y radio, cuando las VPC de aplicaciones necesitan comunicarse entre sí, puedes conectar las VPC de aplicaciones a un concentrador de Network Connectivity Center como radios. Este enfoque proporciona conectividad entre todas las VPC en el concentrador de Network Connectivity Center. Se pueden crear subgrupos de comunicación a través de varios concentradores de Network Connectivity Center. Cualquier restricción de comunicación requerida entre los extremos dentro de un concentrador en particular se puede lograr a través de políticas de firewall.

Conectividad con VPC de radio de Network Connectivity Center a través del balanceo de cargas

Este patrón incluye todas las VPC como radios en un concentrador de Network Connectivity Center y puede alojar hasta 250 VPC interconectadas. Un concentrador de Network Connectivity Center es una construcción de plano de administración que crea una conectividad del plano de datos de malla completa entre cualquier red de VPC que esté registrada como radios al concentrador de Network Connectivity Center. El patrón proporciona conectividad de cualquier forma y habilita la implementación de puntos de acceso en servicios administrados en cualquier VPC.

Para superar las limitaciones de transitividad, los puntos de acceso a servicios administrados y conexiones híbridas y se accede a través de balanceadores de cargas de red del proxy internos. La seguridad de las cargas de trabajo para las conexiones este-oeste puede usar el firewall de nueva generación de Cloud. También puedes usar NAT entre VPC con este patrón.

Este patrón tiene algunas limitaciones, por lo que se debe considerar lo siguiente antes de adoptarlo:

  • No puedes usar NVA para firewalls perimetrales con este patrón. Los firewalls perimetrales deben permanecer en redes externas.
  • Solo se admite tráfico de TCP desde y hacia redes externas. Esta limitación se produce porque las conexiones a las redes externas se ejecutan a través de un balanceador de cargas de red de proxy interno.
  • Los servicios publicados tendrán un frontend adicional en el balanceador de cargas del proxy. Este frontend adicional multiplica los registros adicionales en el DNS y requiere búsquedas de DNS dividido.
  • Los servicios de capa 4 requieren un balanceador de cargas de red de proxy interno nuevo para cada servicio nuevo. Es posible que necesites balanceadores de cargas diferentes según los protocolos necesarios para la conexión.
  • Las cuotas del balanceo de cargas son limitadas para cada red de VPC. Esta es una consideración importante porque los servicios de capa 4 requieren un balanceador de cargas de red de proxy interno nuevo para cada servicio de destino.
  • La opción de diseño de alta disponibilidad y conmutación por error entre regiones elegida depende de tus requisitos.
  • El tráfico encriptado en el límite híbrido tiene implicaciones en la coordinación de la administración de certificados.

Si las consideraciones anteriores son compromisos administrables o irrelevantes para tu entorno, recomendamos este patrón como la opción preferida.

En el siguiente diagrama, se muestra un concentrador híbrido de Network Connectivity Center como plano de administración para las conexiones de Cloud Interconnect. También muestra un concentrador de VPC de Network Connectivity Center que conecta los radios de VPC de la aplicación y los servicios:

VPC de aplicaciones conectadas como radios a un concentrador de Network Connectivity Center

Balanceo de cargas de proxy para la transitividad

No se puede acceder a las siguientes opciones en las VPC de radio de Network Connectivity Center:

  • Extremos del servicio de Private Service Connect y frontends del servicio administrado.
  • Redes detrás de conexiones híbridas (Cloud Interconnect o VPN con alta disponibilidad) porque las rutas dinámicas no se propagan a través de Cross-Cloud Network.

Estas limitaciones de transitividad se pueden superar a través de la implementación de balanceadores de cargas de red de proxy internos con los recursos no transitivos administrados como grupos de extremos de red (NEG) híbridos. Puedes implementar balanceadores de cargas de red de proxy internos frente a los frontends de servicio y frente a los extremos a los que se puede acceder en las conexiones híbridas. Los frontends del balanceador de cargas de red de proxy interno se implementan en subredes de VPC que se propagan en las VPC de radio de Cross-Cloud Network. Los balanceadores de cargas de red de proxy internos permiten la accesibilidad a través de Cross-Cloud Network de los recursos no transitivos. Para hosts y servicios externos, extremos de Private Service Connect y redes de acceso a servicios privados, los backends deben configurarse como NEG híbridos. Los backends de Private Service Connect son el único modelo en el que no es necesario que los NEG sean híbridos.

Diseño de infraestructura de DNS

En un entorno híbrido, Cloud DNS o un proveedor externo (local o CSP) puede controlar una búsqueda de DNS. Los servidores DNS externos son confiables para las zonas de DNS externas, y Cloud DNS es confiable para las zonas de Google Cloud. El reenvío de DNS debe habilitarse bidireccionalmente entre Google Cloud y las redes externas, y los firewalls deben configurarse para permitir el tráfico de resolución de DNS.

Si usas una VPC compartida para la VPC de servicios centrales, en la que los administradores de diferentes proyectos de servicio de aplicaciones pueden crear instancias de sus propios servicios, usa la vinculación entre proyectos de las zonas del DNS. La vinculación entre proyectos permite la segmentación y la delegación del espacio de nombres de DNS a los administradores del proyecto de servicio.

En el caso de tránsito, en el que las redes externas se comunican con otras redes externas a través de Google Cloud, las zonas del DNS externas deben configurarse para reenviar solicitudes directamente entre sí. Cross-Cloud Network de Google proporciona conectividad para que se completen las solicitudes y respuestas de DNS, pero Google Cloud DNS involucra el reenvío de cualquiera de los tráficos de resolución de DNS entre zonas de redes externas. Cualquier regla de firewall aplicada en Cross-Cloud Network debe permitir el tráfico de resolución de DNS entre las redes externas.

En el siguiente diagrama, se muestra que un diseño de DNS se puede usar con cualquiera de las opciones de configuración de conectividad de VPC de concentrador y radio propuestas en esta guía de diseño:

Diseño de DNS que se puede usar con patrones de conectividad de concentrador y radio

En el diagrama anterior, se muestran los siguientes pasos en el flujo de diseño:

  1. DNS local
    Configura tus servidores DNS locales para que estén autorizados para las zonas DNS locales. Configura el reenvío de DNS (para los nombres de Google Cloud DNS) a través de la orientación a la dirección IP de reenvío entrante de Cloud DNS, que se crea a través de la configuración de la política del servidor entrante en la VPC del concentrador. Esta configuración permite que la red local resuelva los nombres de Google Cloud DNS.
  2. VPC de tránsito: proxy de salida de DNS
    Anuncia el rango de proxy de salida de DNS de Google 35.199.192.0/19 a la red local a través de los routers de Cloud Router. Las solicitudes de DNS salientes de Google a las instalaciones locales provienen de este rango de direcciones IP.
  3. VPC de tránsito: Cloud DNS
    1. Configura una política del servidor entrante para las solicitudes DNS entrantes desde las instalaciones.
    2. Configura la zona de reenvío de Cloud DNS (para nombres de DNS locales) orientada a los servidores DNS locales.
  4. VPC de servicios: Cloud DNS
    1. Configura la zona de intercambio de tráfico de DNS de los servicios (para nombres de DNS locales) que establece la VPC del concentrador como la red de intercambio de tráfico. La resolución de DNS para los recursos locales y de servicio pasa por la VPC de concentrador.
    2. Configura las zonas privadas de DNS de servicios en el proyecto host de servicios y conecta la VPC compartida de los servicios, la VPC compartida de la aplicación y la VPC del concentrador a la zona. Esto permite que todos los hosts (locales y en todos los proyectos de servicio) resuelvan los nombres de DNS de los servicios.
  5. Proyecto host de la app: Cloud DNS
    1. Configura una zona de intercambio de tráfico del DNS de la app para los nombres de DNS locales que configuren la VPC del concentrador como la red de intercambio de tráfico. La resolución de DNS para los hosts locales pasa por la VPC del concentrador.
    2. Configura las zonas privadas del DNS de la app en el proyecto host de la aplicación y conecta la VPC de la aplicación, la VPC compartida de los servicios y la VPC del concentrador a la zona. Esta configuración permite que todos los hosts (locales y en todos los proyectos de servicio) resuelvan los nombres de DNS de la app.

Para obtener más información, consulta Arquitectura híbrida con una red de VPC del concentrador conectada a redes de VPC de radio.

¿Qué sigue?

Colaboradores

Autores:

  • Victor Moreno | Gerente de producto, Herramientas de redes de Cloud
  • Ghaleb Al-habian | Especialista en redes
  • Deepak Michael | Ingeniero de Atención al cliente especializado en herramientas de redes
  • Osvaldo Costa | Ingeniero de Atención al cliente especializado en herramientas de redes
  • Jonathan Almaleh | Consultor de soluciones técnicas de personal

Otros colaboradores: