Topologías de red en implementaciones de nube híbrida y de múltiples nubes

En este artículo, que es el tercero de una serie de varias partes, se analizan las implementaciones de nube híbrida y múltiples nubes, los patrones de arquitectura y las topologías de red. En esta parte, se exploran las topologías de red comunes que puedes usar para la configuración de nube híbrida y múltiples nubes. En el artículo, se describen las situaciones y los patrones arquitectónicos para los que estas topologías son más adecuadas y se proporcionan prácticas recomendadas a fin de implementarlas mediante Google Cloud.

La serie consta de estas partes:

Conectar entornos de computación privados a Google Cloud de manera segura y confiable es clave para cualquier implementación exitosa de nube híbrida o de múltiples nubes. La topología de red que eliges para una configuración de nube híbrida y múltiples nubes debe cumplir con los requisitos únicos de las cargas de trabajo empresariales y adaptarse a los patrones arquitectónicos que pretendes aplicar. Aunque cada topología puede necesitar una adaptación, existen topologías comunes que pueden utilizarse como modelo.

Duplicado

La idea de la topología duplicada es hacer que el entorno de computación en la nube y el entorno de computación privado se reflejen mutuamente. Esta topología se aplica en especial en la configuración que sigue el patrón híbrido de entornos, en el que puedes ejecutar cargas de trabajo de desarrollo y de prueba en un entorno mientras ejecutas cargas de trabajo de etapas de prueba y de producción en el otro.

Las cargas de trabajo de prueba y de producción no deben comunicarse directamente entre sí. Sin embargo, debería ser posible implementar y administrar ambos grupos de cargas de trabajo de manera coherente. Por lo tanto, conecta los dos entornos de computación de manera tal que se cumplan los requisitos que figuran a continuación:

  • La integración continua/implementación continua (IC/CD) y los sistemas administrativos pueden implementar y administrar las cargas de trabajo en entornos de computación.
  • La supervisión y otras herramientas de administrativas funcionan en entornos de computación.
  • Las cargas de trabajo no pueden comunicarse en entornos de computación.

Arquitectura de referencia

En el siguiente diagrama, se muestra una arquitectura de referencia que cumple con estos requisitos.

Arquitectura de referencia que cumple con los requisitos anteriores.

  • En Google Cloud, usa dos nubes privadas virtuales (VPC) independientes: una VPC compartida para las cargas de trabajo de desarrollo y de prueba, y una VPC adicional para todas las herramientas administrativas y de CI/CD. Las dos VPC intercambian tráfico, lo que permite una comunicación entre las VPC que usa direcciones IP internas. El intercambio de tráfico permite que los sistemas administrativos y de IC/CD implementen y administren las cargas de trabajo de desarrollo y de prueba.
  • Además, conecta la VPC de CI/CD a la red que ejecuta las cargas de trabajo de producción en el entorno de computación privado. Establece esta conexión mediante Cloud Interconnect o Cloud VPN. Esta conexión te permite implementar y administrar las cargas de trabajo de producción.
  • Todos los entornos comparten un espacio común de dirección IP RFC 1918 sin superposición.
  • De forma opcional, puedes configurar reglas de firewall para garantizar que las cargas de trabajo de producción y las de desarrollo y prueba no se puedan comunicar entre sí.

Variaciones

Para una variación de esta topología, puedes utilizar VPC separadas para el desarrollo y las diferentes etapas de prueba, y todas intercambian tráfico con la VPC de IC/CD.

Cuando ejecutas cargas de trabajo basadas en VM, también podría ser beneficioso ejecutar agentes de CI en cada entorno que asuma el trabajo de realizar implementaciones. Según las capacidades de tu sistema de CI, el uso de agentes podría permitirte bloquear aún más la comunicación entre entornos y aplicar un control más estricto sobre los sistemas que pueden comunicarse entre sí.

En el siguiente diagrama, se muestra cómo podría ser esta variación.

Topología duplicada con agentes.

Cuando ejecutas cargas de trabajo de Kubernetes de forma exclusiva, es posible que no necesites intercambiar tráfico entre las dos VPC. Debido a que el plano de control de Google Kubernetes Engine (GKE) es público, puedes usar la función de las redes autorizadas principales y RBAC para garantizar que solo tus sistemas de CI puedan realizar implementaciones. En el siguiente diagrama, se muestra esta topología.

Topología duplicada.

Prácticas recomendadas

  • Asegúrate de que los sistemas de IC/CD necesarios para implementar o reconfigurar implementaciones de producción se implementen con alta disponibilidad. Además, considera utilizar una red privada virtual (VPN) redundante o vínculos de interconexión para aumentar la disponibilidad.
  • Configura las instancias de VM en la VPC de desarrollo y de prueba para tener direcciones IP públicas de modo que esas instancias puedan acceder a Internet directamente. De lo contrario, implementa Cloud NAT en la misma VPC para controlar el tráfico de salida.
  • Para utilizar redes públicas, usa el acceso privado de Google con el fin de evitar la comunicación entre las cargas de trabajo de VPC y las API de Google.
  • También considera las recomendaciones generales sobre las topologías de red para nube híbrida y múltiples nubes.

De malla

La idea de la topología de malla es establecer una red plana que abarque varios entornos de computación en los cuales todos los sistemas puedan comunicarse entre sí. Esta topología se aplica en especial en la configuración por niveles, particionada o con picos de actividad, y requiere que conectes los entornos de computación de manera tal que se cumplan los requisitos que figuran a continuación:

  • Las cargas de trabajo pueden comunicarse entre sí a través de los límites del entorno mediante UDP o TCP con direcciones IP RFC 1918 privadas.

  • Puedes utilizar las reglas de firewall para restringir los flujos de tráfico de manera detallada, tanto entre los entornos de computación como dentro de ellos.

Arquitectura de referencia

En el siguiente diagrama, se muestra una arquitectura de referencia que cumple con estos requisitos.

Arquitectura de referencia de malla

  • En Google Cloud, implementa cargas de trabajo en una sola VPC compartida.

  • Para conectar la VPC a la red del entorno de computación privado, usa Cloud Interconnect o Cloud VPN. Esta configuración garantiza que la comunicación entre los entornos se pueda realizar mediante direcciones IP privadas.

  • Usa Cloud Router para intercambiar rutas entre entornos de forma dinámica.

  • Todos los entornos comparten un espacio común de dirección IP RFC 1918 sin superposición.

Variantes

Puedes implementar una inspección profunda de paquetes adicional o, también, otros mecanismos avanzados de firewall que excedan las capacidades de las reglas de firewall de Google Cloud. Para implementar estos mecanismos, puedes extender la topología a fin de pasar todo el tráfico entre entornos a través de un dispositivo de firewall, como se muestra en el siguiente diagrama.

Topología de malla extendida

  • Establece el vínculo de VPN o de interconexión entre una VPC de tránsito dedicada y la VLAN en el entorno de computación privado.

  • Establece la conexión entre la VPC de tránsito y la VPC de la aplicación mediante el uso de las VM que ejecutan el dispositivo de firewall. Configura estas VM para el reenvío de IP. Las VM usan varias interfaces de red: una conectada a la VPC de tránsito y otra conectada a la VPC de la aplicación.

  • El dispositivo de firewall también puede actuar como una puerta de enlace NAT para las instancias de VM que se implementan en la VPC de la aplicación. Esta puerta de enlace permite que estas instancias accedan a Internet sin necesidad de direcciones IP públicas.

Recomendaciones

Salida cerrada

La idea de la topología de salida cerrada es exponer las API seleccionadas del entorno de computación privado a las cargas de trabajo implementadas en Google Cloud sin exponerlas a la Internet pública. Puedes facilitar esta exposición limitada a través de una puerta de enlace de API que actúe como fachada para las cargas de trabajo existentes. Implementa la puerta de enlace en una red perimetral (DMZ) mientras implementas las cargas de trabajo en una red dedicada y más segura dentro del entorno de procesamiento privado.

La topología de salida cerrada se aplica principalmente a la configuración escalonada y requiere que conectes los entornos de computación de manera tal que se cumplan los requisitos que figuran a continuación:

  • Las cargas de trabajo que implementas en Google Cloud pueden comunicarse con la puerta de enlace de API mediante el uso de direcciones IP privadas. No se puede acceder a otros sistemas en el entorno de computación privado desde Google Cloud.

  • No se permite la comunicación del entorno de computación privado a ninguna carga de trabajo implementada en Google Cloud.

Arquitectura de referencia

En el siguiente diagrama, se muestra una arquitectura de referencia que cumple con estos requisitos.

Topología de salida cerrada

  • En Google Cloud, implementa cargas de trabajo en una VPC compartida.

  • Mediante el uso de Cloud Interconnect o Cloud VPN, conecta la VPC a una red perimetral en el entorno de procesamiento privado, lo que permite llamadas a la puerta de enlace de la API.

  • Con las reglas de firewall, no permites las conexiones entrantes a la VPC.

  • De manera opcional, utiliza Cloud Router para intercambiar rutas entre entornos de forma dinámica.

  • Todos los entornos comparten un espacio común de dirección IP RFC 1918 sin superposición.

Variaciones

Para acceder a Internet, las instancias de VM que implementas en la VPC de la aplicación deben tener direcciones IP externas. Para evitar tener que configurar estas direcciones externas, puedes implementar Cloud NAT en la misma red de VPC, como se muestra en el siguiente diagrama.

Variaciones en la topología de salida cerrada

Prácticas recomendadas

Entrada cerrada

La idea de la topología de entrada cerrada es exponer las API seleccionadas de las cargas de trabajo que se ejecutan en Google Cloud al entorno de computación privado sin exponerlas a la Internet pública. Esta topología es la contraparte de la situación de salida cerrada y es adecuada para las situaciones híbridas perimetrales.

Puedes exponer las API seleccionadas a través de una puerta de enlace de API que pongas a disposición para acceder al entorno de computación privado, de la siguiente manera:

  • Las cargas de trabajo que implementas en el entorno de computación privado pueden comunicarse con la puerta de enlace de API mediante el uso de direcciones IP privadas. No se puede acceder a otros sistemas implementados en Google Cloud.

  • No se permite la comunicación de Google Cloud al entorno de computación privado.

Arquitectura de referencia

En el siguiente diagrama, se muestra una arquitectura de referencia que cumple con estos requisitos.

Topología de entrada cerrada

  • En Google Cloud, implementa cargas de trabajo en una VPC de aplicación.

  • Establece una conexión de Cloud Interconnect o de Cloud VPN entre una VPC de tránsito dedicada y el entorno de computación privado.

  • Establece la conexión entre la VPC de tránsito y la VPC de la aplicación mediante el uso de VM que ejecutan la puerta de enlace de API. Estas VM usan dos interfaces de herramientas de redes: una conectada a la VPC de tránsito y otra a la VPC de la aplicación. Para equilibrar el tráfico entre varias instancias de puerta de enlace de API, configura un balanceador de cargas interno en la VPC de tránsito.

  • Implementa Cloud NAT en la VPC de la aplicación para permitir que las cargas de trabajo accedan a Internet. Esta puerta de enlace evita tener que equipar las instancias de VM con direcciones IP externas, las cuales se prefiere evitar en los sistemas que se implementan detrás de una puerta de enlace de API.

  • De manera opcional, puedes utilizar Cloud Router para intercambiar rutas entre entornos de forma dinámica.

  • Todos los entornos comparten un espacio común de dirección IP RFC 1918 sin superposición.

Prácticas recomendadas

Entrada y salida cerradas

La combinación de entradas y salidas cerradas permite el uso bidireccional de las API seleccionadas entre las cargas de trabajo que se ejecutan en Google Cloud y en un entorno de computación privado. En ambos lados, usa las puertas de enlace de API para exponer las API seleccionadas y, de manera opcional, autentica, autoriza y audita las llamadas.

La comunicación de API funciona de la siguiente manera:

  • Las cargas de trabajo que implementas en Google Cloud pueden comunicarse con la puerta de enlace de API mediante el uso de direcciones IP privadas. No se puede acceder a otros sistemas implementados en el entorno de computación privado.

  • Por otro lado, las cargas de trabajo que implementes en el entorno de computación privado pueden comunicarse con la puerta de enlace de API de Google Cloud mediante direcciones IP privadas. No se puede acceder a otros sistemas implementados en Google Cloud.

Arquitectura de referencia

En el siguiente diagrama, se muestra una arquitectura de referencia para la topología de entrada y salida cerradas.

Topología de entrada y salida cerradas

  • En Google Cloud, implementa cargas de trabajo en una VPC compartida y no las expongas a Internet.

  • Establece una conexión de Cloud Interconnect o de Cloud VPN entre una VPC de tránsito dedicada y el entorno de computación privado.

  • Establece la conexión entre la VPC de tránsito y la VPC de la aplicación mediante el uso de VM que ejecutan la puerta de enlace de API. Estas VM usan dos interfaces de herramientas de redes: una conectada a la VPC de tránsito y otra a la VPC de la aplicación. Para equilibrar el tráfico entre varias instancias de puerta de enlace de API, configura un balanceador de cargas interno en la VPC de tránsito.

  • También puedes usar Cloud NAT, que permite que las cargas de trabajo accedan a Internet y se comuniquen con la puerta de enlace de la API que se ejecuta en el entorno de procesamiento privado.

  • De manera opcional, puedes utilizar Cloud Router para intercambiar rutas entre entornos de forma dinámica.

  • Todos los entornos comparten un espacio común de dirección IP RFC 1918 sin superposición.

Prácticas recomendadas

Traspaso

La idea de la topología de traspaso es usar los servicios de almacenamiento que proporciona Google Cloud para conectar un entorno de computación privado con los proyectos en Google Cloud. Esta topología se aplica en especial en la configuración que sigue el patrón de estadísticas, que tiene las siguientes características:

  • Las cargas de trabajo que se ejecutan en un entorno de computación privado suben datos a ubicaciones de almacenamiento compartidas. Según los casos prácticos, las cargas pueden ocurrir en forma masiva o en mensajes pequeños.

  • Las cargas de trabajo alojadas en Google Cloud consumen datos de estas ubicaciones y los procesan en forma de transmisión o por lotes.

Arquitectura de referencia

En el siguiente diagrama, se muestra una arquitectura de referencia para la topología de traspaso.

Arquitectura de referencia para la topología de traspaso

  • En Google Cloud, implementa cargas de trabajo en una VPC de la aplicación. Estas cargas de trabajo pueden incluir procesamiento de datos, estadísticas y aplicaciones de frontend relacionadas con las estadísticas.

  • Para exponer las aplicaciones de frontend de forma segura a los usuarios corporativos, puedes usar Identity-Aware Proxy.

  • Usa un conjunto de depósitos de Cloud Storage o colas de Pub/Sub a fin de subir datos del entorno de computación privado y hacer que estén disponibles para el procesamiento posterior mediante cargas de trabajo implementadas en Google Cloud. Mediante las políticas de IAM, puedes restringir el acceso a las cargas de trabajo de confianza.

  • Debido a que no hay conectividad de red privada entre entornos, los espacios de direcciones IP RFC 1918 pueden superponerse entre entornos.

Recomendaciones

Prácticas recomendadas sobre topologías de red para nube híbrida y múltiples nubes

  • En Google Cloud, aprovecha las VPC compartidas. Una VPC compartida es una VPC que se puede usar en varios proyectos de Google Cloud, lo que evita la necesidad de mantener muchas VPC individuales. Las VPC compartidas también te permiten administrar la configuración del intercambio de tráfico, las subredes, las reglas de firewall y los permisos de forma centralizada.

  • Cuando se administran las reglas de firewall, es preferible utilizar el filtrado basado en cuentas de servicio por sobre el filtrado basado en etiquetas de red.

  • Evita el uso de VPC para aislar las cargas de trabajo individuales entre sí. En su lugar, es preferible utilizar subredes y reglas de firewall. Cuando uses GKE, puedes complementar este enfoque mediante el uso de políticas de red.

  • Mientras que Cloud VPN garantiza que el tráfico entre entornos esté encriptado, Cloud Interconnect no lo garantiza. Para ayudar a proteger la comunicación entre cargas de trabajo, considera usar la seguridad de la capa de transporte (TLS).

  • Sigue nuestras recomendaciones para crear VPN con alta capacidad de procesamiento.

  • Deja espacio de dirección suficiente en la dirección IP RFC 1918 existente para todos los sistemas alojados en la nube.

  • Cuando uses GKE, considera usar clústeres privados y ten en cuenta los requisitos de tamaño de la red.

  • Usa el acceso privado a Google para permitir que las instancias de VM que se ejecutan en Google Cloud y que no tienen asignada una dirección IP externa puedan acceder a los servicios de Google.

¿Qué sigue?