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

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 tus subredes de Google Cloud VPC 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 tu Google Cloud zona de destino. 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 o más VPC de tránsito, en las que se maneja toda la conectividad externa.
  • Una o más VPC de acceso a servicios, que se pueden 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 redes, como redes y subredes de VPC, concentradores de Network Connectivity Center, intercambio de tráfico entre redes de VPC 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 redes de 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, como los de transferencia de datos para 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 una 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. Para simplificar la ilustración, el diagrama muestra una sola VPC de tránsito, pero puedes usar varias VPC de tránsito para la conectividad en diferentes regiones.

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 los 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 deGoogle 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 deGoogle 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 enGoogle 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 Google Cloud opciones integradas, como se describe en Alternativas para usar una dirección IP externa. 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 IPs externas y Cloud NAT (el servicio de NAT administrado deGoogle 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 la descripción general de Cloud Router.

Para proteger la conectividad saliente, Google Cloud ofrece la aplicación de Cloud Next Generation Firewall y Secure Web Proxy para proporcionar un filtrado más profundo en las URLs de 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 la 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 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 redes de 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

Para obtener un rendimiento y una escalabilidad óptimos con los servicios de redes en la nube integrados, las VPC deben conectarse con Network Connectivity Center, como se describe en Conectividad entre VPC con Network Connectivity Center. Network Connectivity Center proporciona lo siguiente:

  • Acceso transitivo a los extremos de Private Service Connect de L4 y L7, y a sus servicios asociados
  • Acceso transitivo a redes locales aprendidas a través de BGP
  • Escala de red de VPC de 250 redes por concentrador

Si deseas insertar dispositivos virtuales de red (NVA) para la protección con firewall o para otras funciones de red, debes usar el intercambio de tráfico entre redes de VPC. Los firewalls perimetrales pueden permanecer en redes externas. Si la inserción de la NVA es un requisito, usa el patrón de conectividad entre VPCs con intercambio de tráfico entre redes de VPC para interconectar tus VPCs.

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.

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 puntos de acceso a la API.

Conectividad entre VPCs con Network Connectivity Center

Recomendamos que las VPC de aplicaciones, las VPC de tránsito y las VPC de acceso a servicios se conecten con radios de VPC de Network Connectivity Center.

Los puntos de acceso de los consumidores de servicios se implementan en las VPC de acceso a los servicios cuando deben ser accesibles desde otras redes (otras VPC o redes externas). Puedes implementar puntos de acceso del consumidor de servicios en las VPC de la aplicación si solo se debe acceder a estos puntos desde la VPC de la aplicación.

Si necesitas proporcionar acceso a servicios detrás del acceso privado a servicios, crea una VPC de acceso a servicios que esté conectada a una VPC de tránsito con VPN con alta disponibilidad. Luego, conecta la VPC de los servicios administrados a la VPC de acceso a los servicios. La VPN con alta disponibilidad habilita el enrutamiento transitivo desde otras redes.

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

  • Network Connectivity Center: Proporciona conectividad entre las VPC de tránsito, las VPC de aplicaciones y las VPC de acceso a servicios que alojan extremos de Private Service Connect.
  • Conexiones entre VPC de VPN con alta disponibilidad: Proporcionan conectividad transitiva para las subredes de acceso privado a los servicios alojadas en las VPC de acceso a los servicios. Estas VPC de acceso a servicios no deben agregarse como radio del concentrador de Network Connectivity Center.

Cuando combines estos tipos de conectividad, planifica las siguientes consideraciones:

  • Redistribución de las subredes de intercambio de tráfico de intercambio de tráfico entre redes de VPC y Network Connectivity Center en el enrutamiento dinámico (a la VPC de acceso a servicios a través de VPN con alta disponibilidad y a redes externas a través de interconexiones híbridas)
  • Consideraciones de enrutamiento multirregional
  • Propagación de rutas dinámicas al intercambio de tráfico entre redes de VPC y al intercambio de tráfico de Network Connectivity Center (desde la VPC de acceso a servicios a través de la VPN con alta disponibilidad y desde redes externas a través de interconexiones híbridas)

En el siguiente diagrama, se muestra una VPC de acceso a servicios que aloja subredes de acceso a servicios privados conectadas a la VPC de tránsito con VPN con alta disponibilidad. En el diagrama, también se muestran las VPC de aplicaciones, las VPC de tránsito y las VPC de acceso a servicios que alojan extremos de consumidor de Private Service Connect conectados a través de Network Connectivity Center:

Estructura general de Cross-Cloud Network con radios de VPC de Network Connectivity Center

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

  • Red externa: Es 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.
  • Red de VPC de tránsito: Es una red de VPC en el proyecto de 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.
  • VPC de aplicaciones: Proyectos y redes de VPC que alojan varias aplicaciones.
  • VPC de consumidor para el acceso privado a servicios: Es una red de VPC que aloja el acceso centralizado a través del acceso privado a servicios que necesitan las aplicaciones en otras redes.
  • VPC de servicios administrados: Servicios que proporcionan y administran otras entidades, pero que son accesibles para las aplicaciones que se ejecutan en redes de VPC.
  • VPC del consumidor para Private Service Connect: Es una red de VPC que aloja puntos de acceso de Private Service Connect a servicios alojados en otras redes.

Usa Network Connectivity Center para conectar las VPC de aplicaciones a los adjuntos de VLAN de Cloud Interconnect y a las instancias de VPN con alta disponibilidad en las VPC de tránsito. Convierte todas las VPC en radios del concentrador de Network Connectivity Center y convierte los adjuntos de VLAN y las VPN con alta disponibilidad en radios híbridos del mismo concentrador de Network Connectivity Center. Usa la topología de malla predeterminada de Network Connectivity Center para habilitar la comunicación entre todos los radios (híbridos y de VPC). Esta topología también permite la comunicación entre las VPC de la aplicación que están sujetas a las políticas de Cloud NGFW. Las VPC de servicio del consumidor conectadas a través de la VPN con alta disponibilidad no deben ser radios del concentrador de Network Connectivity Center. Los extremos de Private Service Connect se pueden implementar en los radios de VPC de Network Connectivity Center y no requieren una conexión de VPN con alta disponibilidad para la transitividad entre VPC cuando se usa Network Connectivity Center.

Conectividad entre VPCs con intercambio de tráfico entre redes de VPC

Cuando los puntos de acceso del consumidor de servicios publicados se implementan en una VPC de acceso a servicios, recomendamos que las VPC de aplicaciones se conecten a través del intercambio de tráfico entre redes de VPC a la VPC de tránsito y que las VPC de acceso a servicios se conecten a la VPC de tránsito a través de una 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 acceso a 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 de tránsito y las VPC de aplicaciones.
  • Conexiones entre VPC de VPN con alta disponibilidad: Proporcionan conectividad transitiva entre las VPC de acceso a los servicios y la VPC de tránsito.

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 la VPC de acceso a los servicios a través de VPN con alta disponibilidad y a redes externas a través de conexiones híbridas)
  • Consideraciones de enrutamiento multirregional
  • Propagación de las rutas dinámicas al intercambio de tráfico de VPC (desde la VPC de acceso a los servicios a través de la VPN con alta disponibilidad y desde las redes externas a través de las conexiones híbridas)

En el siguiente diagrama, se muestra una VPC de acceso a servicios, que está conectada a la VPC de tránsito con VPN con alta disponibilidad, y las VPC de aplicaciones, que están 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 acceso a servicios: Es 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 intercambio de tráfico entre redes de VPC, cuando las VPC de aplicaciones necesitan comunicarse entre sí, puedes conectar las VPC de aplicaciones a un concentrador de Network Connectivity Center como radios de VPC. 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.

La seguridad de las cargas de trabajo para las conexiones este-oeste entre las VPC de aplicaciones puede usar el firewall de nueva generación de Cloud.

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

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 deGoogle Cloud . El reenvío de DNS debe habilitarse bidireccionalmente entreGoogle 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 acceso a servicios, 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 con acceso a 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: