Patrones de redes híbridas de Google Cloud - Parte 2

Introducción

En las dos primeras entradas de esta serie, exploramos los patrones de red básicos para la conectividad híbrida entre los sistemas locales y Google Cloud. La Parte 1 se centró en la conexión a una VPC única o compartida, mientras que la Parte 2 se extendió a la conectividad híbrida a través de múltiples redes VPC. En esta última entrega, nos adentraremos en patrones más avanzados, concretamente en la conectividad híbrida mediante appliances en redes VPC compartidas dentro de una arquitectura hub en Google Cloud.

Conectividad híbrida mediante dispositivos (redes VPC compartidas en Hub)

1. Interconexión con las instalaciones

Considere un caso de uso en el que las cargas de trabajo se organizan en redes VPC compartidas separadas para Producción (Prod) y No Producción (Non-Prod). La interconexión (o HA-VPN) desde las instalaciones (u otras nubes) termina directamente en la VPC externa.

Este patrón proporciona conectividad híbrida a:

1. Recursos IaaS dentro de la carga de trabajo Redes VPC compartidas
2. API y servicios de Google (por ejemplo, storage.googleapis.com, *.run.app) en los proyectos de carga de trabajo
3. Servicios gestionados de Google Cloud mediante Private Services Access

Usa este patrón cuando:

1. Tiene varias redes VPC compartidas de carga de trabajo que requieren inspección de capa 7 para el tráfico entre redes VPC y locales. Aunque este ejemplo muestra dos redes VPC compartidas (Prod y Non-Prod), puede admitir hasta siete redes VPC. Las redes VPC de carga de trabajo se comunican a través de dispositivos virtuales de red (NVA), que aplican políticas de seguridad de red para permitir o denegar el tráfico.
2. Tiene varias redes VPC compartidas de cargas de trabajo que necesitan compartir una conexión común con las instalaciones u otras nubes. En este ejemplo, la conectividad a los locales y otras nubes se enruta a través de la NVA y la VPC externa.
3. Necesita conectividad de red a servicios gestionados utilizando Private Services Access dentro de las redes VPC compartidas de carga de trabajo. Este patrón permite acceder a los servicios gestionados desde las instalaciones y a cualquier carga de trabajo de la VPC compartida.

Ampliación (número de VPC de carga de trabajo compartida)

El número máximo de redes VPC compartidas de carga de trabajo es siete, limitado por el número máximo de interfaces de red por instancia. Si se requiere una interfaz adicional para el tráfico de gestión hacia el NVA, sólo se pueden desplegar seis redes VPC compartidas de carga de trabajo.

1. Cloud Interconnect Configure una interconexión dedicada o una interconexión de socio a Google Cloud. Conéctese a dos dominios de disponibilidad de borde (EAD) dentro de la misma área metropolitana para lograr un SLA del 99,99%. Sus Cloud Interconnects pueden conectarse a múltiples regiones en la misma VPC compartida.
2. VLAN Attachment Una VLAN Attachment conecta su interconexión en un punto de presencia (PoP) de Google a un router de nube en una región especificada.
3. Cloud Router Un Cloud Router intercambia rutas dinámicas entre sus redes VPC y los routers locales. Puede configurar el enrutamiento dinámico entre sus routers locales y un Cloud Router en una región determinada. Cada Cloud Router se implementa mediante dos tareas de software que proporcionan dos interfaces de alta disponibilidad. Configure el enrutamiento BGP a cada interfaz del enrutador de nube.
4. VPC Global Dynamic Routing Configure el enrutamiento dinámico global en la VPC Compartida para permitir el intercambio de rutas dinámicas entre todas las regiones.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

1.Cloud   HA-VPN La pasarela Cloud HA-VPN establece túneles IPsec con la pasarela VPN local a través de Internet. HA-VPN ofrece un SLA del 99,99%. Puede configurar varios túneles HA-VPN en diferentes regiones de la VPC externa.

2.Cloud   Routers Configure el enrutamiento dinámico entre los routers locales y un Cloud Router en cada región. Cada Cloud Router proporciona dos interfaces de alta disponibilidad. Configure el enrutamiento BGP a ambas interfaces del Cloud Router.

3.VPC   Global Dynamic Routing Configure el enrutamiento dinámico global en la VPC Externa para permitir el intercambio de rutas dinámicas entre todas las regiones.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

3. Opción 1 de DNS híbrido (reenvío y peering de DNS en la nube)

En un entorno híbrido, la resolución DNS puede realizarse en Google Cloud o en las instalaciones. Consideremos un caso de uso de DNS híbrido en el que los servidores DNS locales son autoritativos para las zonas DNS locales y Cloud DNS es autoritativo para las zonas de Google Cloud.

1. Configure sus servidores DNS locales para que sean autoritativos para las zonas DNS locales. Configure el reenvío de DNS (para nombres DNS de Google Cloud) apuntando a la dirección IP de reenvío entrante de DNS de Cloud, que se crea a través de la política de servidor entrante en la VPC compartida Prod. Esto permite que la red local resuelva los nombres DNS de Google Cloud.
2. Anuncie el intervalo de proxy de salida de DNS de Google 35.199.192.0/19 a la red local a través de los routers de la nube. Las solicitudes DNS salientes de Google Cloud a las instalaciones se originan en este intervalo de direcciones IP.
3. VPC externa - DNS en la nube
a) Configure una política de servidor entrante para las solicitudes DNS locales. b) Configure una zona de reenvío DNS en la nube para los nombres DNS locales, dirigida a los resolutores DNS locales.
4. Configure una zona de peering DNS para nombres DNS locales que apunten a la VPC compartida Prod como red par. Esta configuración permite a los recursos No-Prod resolver nombres DNS locales. b) Configure Zonas Privadas DNS No-Prod en el Proyecto Hub Host y adjunte VPC Compartida No-Prod, VPC Compartida Prod y VPC Externa a la zona. Esto permite a los hosts (locales y de todos los proyectos de servicio) resolver los nombres Prod DNS.
5. Configure una zona de peering DNS para nombres DNS locales que apunten a la VPC compartida Prod como red par. Esto permite que los recursos de Prod resuelvan nombres DNS locales. b) Configure zonas privadas DNS de Prod en el proyecto de host central y adjunte la VPC compartida de Prod, la VPC no compartida de Prod y la VPC externa a la zona. Esto permite a los hosts (locales y de todos los proyectos de servicio) resolver los nombres Prod DNS.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

3 4. Private Service Connect (PSC) para las API de Google (acceso a todas las API y servicios compatibles)

Visión general

Puedes utilizar Private Service Connect (PSC) para acceder a todos los servicios y API de Google compatibles desde hosts de Google Compute Engine (GCE) y hosts locales mediante la dirección IP interna de un punto final de PSC en una VPC compartida. Consideremos el acceso PSC a un servicio en el Proyecto de Servicio 4 a través de la VPC Externa y la VPC Compartida Prod.

Creación de puntos finales de PSC

1. Elige una dirección de punto final de PSC (por ejemplo, 10.2.2.2) y crea un punto final de PSC en la VPC compartida de Prod con un objetivo de "all-apis", que da acceso a todas las API y servicios de Google compatibles.
2. Elige una dirección de punto final de PSC (por ejemplo, 10.2.2.2) y crea un punto final de PSC en la VPC compartida de Prod con un objetivo de "all-apis", que da acceso a todas las API y servicios de Google compatibles. Service Directory crea automáticamente un registro DNS (con el nombre DNS de p.googleapis.com) vinculado a la dirección IP del punto final del PSC.

2) Acceso a la API desde hosts de la CME

Los hosts de la CME pueden acceder a todos los servicios y API de Google compatibles a través del punto final de PSC en la VPC compartida de Prod.

1. 2. Habilita Private Google Access en todas las subredes con instancias de cálculo que requieran acceso a las API de Google a través de PSC.
2. 3. Si tus clientes GCE pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puedes utilizar el nombre DNS p.googleapis.com creado automáticamente.
3. 4. Si tus clientes de la CME no pueden utilizar nombres DNS personalizados, puedes crear registros DNS de nube utilizando los nombres DNS predeterminados (por ejemplo, storage.googleapis.com).

Acceso desde hosts locales

Los hosts locales pueden acceder a todos los servicios y API de Google compatibles a través del punto final PSC de la VPC compartida Prod.

• En el enrutador de la nube, anuncie la dirección del punto final de PSC a la red local.
• 5. Si sus clientes locales pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puede crear registros A que asignen los nombres DNS personalizados a la dirección del punto final de PSC.
• 6. Si sus clientes locales no pueden utilizar nombres DNS personalizados, puede crear registros A que asignen los nombres DNS predeterminados (por ejemplo, storage.googleapis.com) a la dirección del punto final de PSC.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

5. Private Service Connect (PSC) para API de Google (acceso a API y servicios compatibles con VPC Service Control)

Visión general

Puedes utilizar Private Service Connect (PSC) para acceder a todos los servicios y API de Google compatibles desde hosts de Google Compute Engine (GCE) y hosts locales mediante la dirección IP interna de un punto final de PSC en una VPC compartida. Consideremos el acceso PSC a un servicio en el Proyecto de Servicio 4 a través de la VPC Externa y la VPC Compartida Prod.

Creación de puntos finales de PSC

1. Elige una dirección de punto final de PSC (por ejemplo, 10.2.2.2) y crea un punto final de PSC en la VPC compartida de Prod con un objetivo de "all-apis", que da acceso a todas las API y servicios de Google compatibles.
2. Elija una dirección de punto final PSC (por ejemplo, 10.2.2.2) y cree un punto final PSC en la VPC compartida Prod con el destino "vpc-sc" Service Directory crea automáticamente un registro DNS (con el nombre DNS de p.googleapis.com) vinculado a la dirección IP del punto final del PSC.

2) Acceso a la API desde hosts de la CME

Los hosts de la CME pueden acceder a todos los servicios y API de Google compatibles a través del punto final de PSC en la VPC compartida de Prod.

1.2. Habilita Private Google Access en todas las subredes con instancias de cálculo que requieran acceso a las API de Google a través de PSC.

2.3. Si tus clientes GCE pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puedes utilizar el nombre DNS p.googleapis.com creado automáticamente.

3.4. Si tus clientes de la CME no pueden utilizar nombres DNS personalizados, puedes crear registros DNS de nube utilizando los nombres DNS predeterminados (por ejemplo, storage.googleapis.com).

Acceso desde hosts locales

1. Los hosts locales pueden acceder a todos los servicios y API de Google compatibles a través del punto final PSC de la VPC compartida Prod.
2. En el enrutador de la nube, anuncie la dirección del punto final de PSC a la red local.
3. 5. Si sus clientes locales pueden utilizar nombres DNS personalizados (por ejemplo, storage-xyz.p.googleapis.com), puede crear registros A que asignen los nombres DNS personalizados a la dirección del punto final de PSC.
4. 6. Si sus clientes locales no pueden utilizar nombres DNS personalizados, puede crear registros A que asignen los nombres DNS predeterminados (por ejemplo, storage.googleapis.com) a la dirección del punto final de PSC.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

6. Control de servicios VPC

Visión general

VPC Service Control utiliza reglas de entrada y salida para controlar el acceso a y desde un perímetro. Las reglas especifican la dirección del acceso permitido hacia y desde diferentes identidades y recursos. 

Consideremos un caso de uso específico en el que se requiere acceso a un servicio protegido en el Proyecto de Servicio 4 a través de la VPC compartida Prod. Se trata de un ejemplo sencillo y no exhaustivo.

Control de servicios VPC

1. Perímetro del proyecto de servicio El perímetro contiene el proyecto de servicio 4 e incluye las API de Google y los servicios que deben protegerse en el proyecto de servicio.
2. Una instancia GCE puede acceder a APIs seguras a través de un endpoint PSC en la VPC compartida. La interfaz de red de la instancia GCE-4 se encuentra en la VPC compartida Prod del proyecto Hub Host. Las llamadas a la API desde la instancia CME-4 a un servicio (por ejemplo, storage.googleapis.com) en el proyecto de servicio 4 parecen originarse en el proyecto host Prod, donde se encuentran la interfaz de la instancia y el punto final PSC.
3. Configure una regla de entrada que permita las llamadas a la API de Google desde el proyecto host Prod a los servicios protegidos dentro del perímetro del Proyecto de servicio 4. Esta regla permite llamadas API desde las instancias de la CME (por ejemplo, CME-4) al perímetro.
4. 4) Acceso a la API para hosts locales Los hosts locales pueden acceder a las API protegidas en el Proyecto de servicio 4 a través del punto final PSC en la VPC compartida Prod. Las llamadas API desde los locales a los servicios del Proyecto de Servicio 4 parecen originarse en el proyecto anfitrión Prod, donde se encuentran la Interconexión (o VPN) y el punto final PSC. La regla de entrada (mencionada en el paso 3) permite llamadas API desde las instalaciones al perímetro del Proyecto de Servicio 4 a través del proyecto de host Prod.

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Liberar todo el potencial de la nube híbrida

La conectividad híbrida es la clave para impulsar tanto la agilidad como la innovación en la nube. A lo largo de esta serie, hemos explorado una serie de patrones de red para ayudarte a conectar sistemas locales con Google Cloud sin problemas, desde configuraciones de VPC básicas hasta arquitecturas avanzadas basadas en dispositivos. Si elige los patrones adecuados para sus cargas de trabajo, podrá conseguir operaciones en la nube seguras, eficientes y escalables. Esperamos que esta serie le haya proporcionado la claridad y la orientación que necesita para diseñar con confianza sus soluciones de redes híbridas. Si tiene alguna pregunta o necesita asistencia personalizada, nuestro equipo de Rackspace Technology está aquí para ayudarle a liberar todo el potencial de su infraestructura en la nube.