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

Este artículo es el tercero de una serie de varias partes que trata sobre 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 este artículo, se describen las situaciones y los patrones arquitectónicos que son más adecuados para estas topologías, y se proporcionan recomendaciones para implementarlas mediante el uso de Google Cloud Platform (GCP).

La serie consta de las siguientes partes:

Conectar los entornos de computación privados a GCP de manera segura y confiable es clave para el éxito de cualquier implementación de nube híbrida o 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 principalmente a las configuraciones que siguen el patrón híbrido del entorno, en el que puedes ejecutar las cargas de trabajo de desarrollo y de prueba en un entorno, al tiempo que ejecutas cargas de trabajo de staging 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 GCP, utilizas dos nubes privadas virtuales (VPC) separadas, una VPC compartida para las cargas de trabajo de desarrollo y de prueba, y una VPC adicional para todas las herramientas administrativas y de IC/CD. Las dos VPC intercambian tráfico, lo que permite una comunicación de VPC cruzada que utiliza 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 IC/CD a la red que ejecuta las cargas de trabajo de producción en el entorno de computación privado. Para establecer esta conexión, utiliza Cloud Interconnect o Cloud VPN. Esta conexión te permite implementar y administrar cargas de trabajo de producción.
  • Debido a que el intercambio de tráfico de VPC no es transitivo, las cargas de trabajo de producción y las cargas de trabajo de desarrollo y de prueba no pueden comunicarse entre sí.
  • Todos los entornos comparten un espacio común de dirección IP RFC 1918 sin superposición.

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 exclusivamente, es posible que no necesites intercambiar el tráfico de las dos redes de VPC. Debido a que el plano de control de Google Kubernetes Engine (GKE) es público, puedes utilizar la característica de redes autorizadas maestras y RBAC para garantizar que solo los sistemas de IC puedan realizar implementaciones. En el siguiente diagrama, se muestra esta topología.

Topología duplicada

Recomendaciones

  • 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 puertas de enlace NAT en la misma VPC a fin de manejar 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 principalmente a las configuraciones escalonadas, particionadas 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 el lado de GCP, implementa cargas de trabajo en una única VPC compartida.

  • Para conectar la VPC a la red en el entorno de computación privado, utiliza Cloud Interconnect o Cloud VPN. Esta configuración garantiza que la comunicación entre los entornos pueda realizarse con direcciones IP privadas.

  • 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

Puedes implementar una inspección profunda de paquete adicional o también otros mecanismos avanzados de firewall que excedan las capacidades de las reglas de firewall de GCP. 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 utilizan 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 cargas de trabajo que se implementan en GCP 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 DMZ, al tiempo que implementas las cargas de trabajo reales en una red dedicada, con mayor grado de seguridad dentro del entorno de computación 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 GCP 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 GCP.

  • No se permite la comunicación desde el entorno de computación privado a cualquier carga de trabajo implementada en GCP.

Arquitectura de referencia

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

topología de salida cerrada

  • En el lado de GCP, implementa cargas de trabajo en una VPC compartida.

  • Con el uso de Cloud Interconnect o Cloud VPN, conecta la VPC a una DMZ en el entorno de computación privado, lo que permite llamadas a la puerta de enlace de 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. A fin de evitar tener que configurar estas direcciones externas, puedes implementar puertas de enlace NAT en la misma VPC, como se muestra en el diagrama que aparece a continuación.

variaciones en la topología de salida cerrada

Recomendaciones

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 GCP 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 GCP.

  • No se permite la comunicación desde GCP 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 el lado de GCP, implementa cargas de trabajo en una VPC de la 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 utilizan dos interfaces de red: una conectada a la VPC de tránsito y otra conectada a la VPC de la aplicación. A fin de equilibrar el tráfico para varias instancias de la puerta de enlace de API, configura el balanceador de cargas interno en la VPC de tránsito.

  • Implementa una puerta de enlace 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, que no deseas 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.

Recomendaciones

Entrada y salida cerradas

La combinación de la entrada y la salida cerradas permite el uso bidireccional de las API seleccionadas entre las cargas de trabajo que se ejecutan en GCP y en un entorno de computación privado. En ambos lados, utiliza 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 GCP 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.

  • De modo inverso, las cargas de trabajo que implementas en el entorno de computación privado pueden comunicarse con la puerta de enlace de API del lado de GCP mediante el uso de direcciones IP privadas. No se puede acceder a otros sistemas implementados en GCP.

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 el lado de GCP, 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 utilizan dos interfaces de red: una conectada a la VPC de tránsito y otra conectada a la VPC de la aplicación. A fin de equilibrar el tráfico para varias instancias de la puerta de enlace de API, configura el balanceador de cargas interno en la VPC de tránsito.

  • También utiliza las instancias de VM que actúan como una puerta de enlace NAT que se conecta a ambas VPC. Estas instancias permiten a las cargas de trabajo acceder a Internet y comunicarse con la puerta de enlace de API que se ejecuta en el entorno de computación 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.

Recomendaciones

Traspaso

La idea de la topología de traspaso es utilizar los servicios de almacenamiento que proporciona GCP para conectar un entorno de computación privado a proyectos en GCP. Esta topología se aplica principalmente a las configuraciones que siguen el patrón de estadísticas, en el que:

  • 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 GCP 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 el lado de GCP, 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.

  • A fin de exponer de manera segura aplicaciones de frontend a los usuarios corporativos, puedes utilizar Cloud Identity-Aware Proxy.

  • Utiliza un conjunto de depósitos de Cloud Storage o colas de Cloud Pub/Sub para subir datos desde el entorno de procesamiento privado y a fin de que estén disponibles para su procesamiento posterior por las cargas de trabajo implementadas en GCP. Con las políticas de IAM, puedes restringir el acceso a las cargas de trabajo confiables.

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

Recomendaciones

Recomendaciones sobre topologías de red para nube híbrida y múltiples nubes

  • En el lado de Google Cloud Platform, aprovecha las VPC compartidas. Una VPC compartida es una VPC que puede utilizarse en varios proyectos de Google Cloud Platform, lo que evita la necesidad de mantener muchas VPC individuales. Las VPC compartidas también te permiten administrar la configuración de intercambio de tráfico, las subredes, las reglas de firewall y los permisos de manera 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 se utiliza 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 asegurar la comunicación entre cargas de trabajo, considera utilizar 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 se utilice GKE, considera utilizar clústeres privados y ten en cuenta los requisitos de tamaño de la red.

  • Utiliza Private Google Access para permitir que las instancias de VM que se ejecutan en GCP y que no tienen una dirección IP externa asignada accedan a los servicios de Google.

¿Qué sigue?

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…