Este documento forma parte de una serie de guías de diseño de redes entre nubes.
La serie consta de las siguientes partes:
- Red Multinube para aplicaciones distribuidas
- Segmentación y conectividad de redes para aplicaciones distribuidas en Cross-Cloud Network
- Red de servicios para aplicaciones distribuidas en la red entre nubes (este documento)
- Seguridad de redes para aplicaciones distribuidas en la Red Multinube
En este documento se describe cómo ensamblar una aplicación a partir de un conjunto de servicios de componentes elegidos o creados. Te recomendamos que leas todo el documento una vez antes de seguir los pasos.
En este documento se explica cómo tomar las siguientes decisiones:
- Si creas el servicio individual tú mismo o consumes un servicio de terceros
- Si el servicio está disponible en todo el mundo o solo en algunas zonas
- Si el servicio se consume desde un entorno local, desde otras nubes o desde ninguno de los dos
- Si accedes al endpoint de servicio a través de una VPC de servicios compartidos o distribuyes los endpoints en todas las VPCs de aplicaciones pertinentes
En este documento se explican los siguientes pasos:
- Decidir si tu aplicación es global o regional
- Elegir servicios gestionados de terceros o crear y publicar tus propios servicios
- Configurar el acceso privado a los endpoints de servicio mediante el modo compartido o el dedicado
- Ensamblar los servicios en aplicaciones para que se ajusten a un arquetipo global o regional
Los desarrolladores definen la capa de redes de servicios de Cross-Cloud Network. En esta fase, los administradores han diseñado una capa de conectividad para la red multinube que permite flexibilidad en las opciones de red de servicios descritas en este documento. En algunos casos, existen restricciones debido a la transitividad entre VPCs limitada. Describimos estas limitaciones cuando pueden afectar a las decisiones de diseño.
Decide si tu aplicación es regional o global
Determina si los clientes de la aplicación que vas a crear necesitan un arquetipo de implementación regional o global. Puedes conseguir la resiliencia regional repartiendo las cargas entre las zonas de una región. Puedes conseguir una resiliencia global distribuyendo las cargas entre regiones.
A la hora de elegir un arquetipo, ten en cuenta los siguientes factores:
- Los requisitos de disponibilidad de la aplicación
- La ubicación en la que se consume la aplicación
- Coste
Para obtener más información, consulta los Google Cloud arquetipos de implementación.
En esta guía de diseño se explica cómo admitir los siguientes arquetipos de implementación:
En una aplicación distribuida entre nubes, los distintos servicios de esa aplicación se pueden ofrecer desde diferentes proveedores de servicios en la nube o centros de datos privados. Para asegurar una estructura de resiliencia coherente, coloque los servicios alojados en diferentes CSPs en centros de datos de CSPs que estén cerca geográficamente.
En el siguiente diagrama se muestra una pila de aplicaciones global distribuida en varias nubes, y los diferentes servicios de aplicaciones se implementan en distintos CSPs. Cada servicio de aplicación global tiene instancias de carga de trabajo en diferentes regiones del mismo CSP.
Definir y acceder a servicios de aplicaciones
Para ensamblar tu aplicación, puedes usar servicios gestionados de terceros, crear y alojar tus propios servicios de aplicaciones o usar una combinación de ambos.
Usar servicios gestionados por terceros
Decide qué servicios gestionados de terceros puedes usar en tu aplicación. Determina cuáles se han creado como servicios regionales o globales. Además, determina qué opciones de acceso privado admite cada servicio.
Cuando sepas qué servicios gestionados puedes usar, podrás determinar qué servicios necesitas crear.
Crear y acceder a servicios de aplicaciones
Cada servicio está alojado en una o varias instancias de carga de trabajo a las que se puede acceder como un único endpoint o como un grupo de endpoints.
En el siguiente diagrama se muestra el patrón general de un servicio de aplicación. El servicio de aplicación se implementa en una colección de instancias de carga de trabajo. En este caso, una instancia de carga de trabajo podría ser una máquina virtual de Compute Engine, un clúster de Google Kubernetes Engine (GKE) u otro backend que ejecute código. Las instancias de carga de trabajo se organizan como un conjunto de backends asociados a un balanceador de carga.
En el siguiente diagrama se muestra un balanceador de carga genérico con un conjunto de backends.
Para conseguir la distribución de carga elegida y automatizar las conmutaciones por error, estos grupos de endpoints usan un balanceador de carga frontend. Si usas grupos de instancias gestionados (MIGs), puedes aumentar o reducir de forma flexible la capacidad del servicio mediante el autoescalado de los endpoints que forman el backend del balanceador de carga. Además, en función de los requisitos del servicio de aplicación, el balanceador de carga también puede proporcionar autenticación, finalización de TLS y otros servicios específicos de la conexión.
Determina el ámbito del servicio: regional o global
Decide si tu servicio necesita y puede admitir la resiliencia regional o global. Un servicio de software regional se puede diseñar para la sincronización dentro de un presupuesto de latencia regional. Un servicio de aplicación global puede admitir conmutaciones por error síncronas entre nodos distribuidos en varias regiones. Si tu aplicación es global, puede que quieras que los servicios que la admiten también lo sean. Sin embargo, si tu servicio requiere sincronización entre sus instancias para admitir la conmutación por error, debes tener en cuenta la latencia entre regiones. En tu caso, es posible que tengas que usar servicios regionales con redundancia en la misma región o en regiones cercanas, lo que permite una sincronización de baja latencia para la conmutación por error.
Cloud Load Balancing admite puntos finales alojados en una sola región o distribuidos en varias regiones. De esta forma, puedes crear una capa global visible para los clientes que se comunique con capas de servicio globales, regionales o híbridas. Elige las implementaciones de tu servicio para asegurarte de que la conmutación por error de red dinámica (o el balanceo de carga entre regiones) se ajusta al estado de resiliencia y a las funciones de la lógica de tu aplicación.
En el siguiente diagrama se muestra cómo un servicio global creado a partir de balanceadores de carga regionales puede acceder a backends de otras regiones y, de este modo, ofrecer una conmutación por error automática entre regiones. En este ejemplo, la lógica de la aplicación es global y el backend elegido admite la sincronización entre regiones. Cada balanceador de carga envía principalmente solicitudes a la región local, pero puede conmutar por error a regiones remotas.
- Un backend global es un conjunto de backends regionales a los que acceden uno o varios balanceadores de carga.
- Aunque los backends son globales, el frontend de cada balanceador de carga es regional.
- En este patrón de arquitectura, los balanceadores de carga distribuyen el tráfico principalmente solo en su región, pero también pueden balancear el tráfico a otras regiones cuando los recursos de la región local no están disponibles.
- Un conjunto de frontends de balanceadores de carga regionales, cada uno accesible desde otras regiones y capaz de llegar a backends de otras regiones, forma un servicio global agregado.
- Para ensamblar una pila de aplicaciones global, como se explica en Diseñar pilas de aplicaciones globales, puedes usar el enrutamiento de DNS y las comprobaciones de estado para conseguir la conmutación por error entre regiones de los front-ends.
- Se puede acceder a los front-ends del balanceador de carga desde otras regiones mediante el acceso global (no se muestra en el diagrama).
Este mismo patrón se puede usar para incluir servicios publicados con conmutación por error global. En el siguiente diagrama se muestra un servicio publicado que usa back-ends globales.
En el diagrama, observa que el servicio publicado tiene implementada la conmutación por error global en el entorno del productor. La incorporación de la conmutación por error global en el entorno del consumidor permite que la infraestructura de balanceo de carga del consumidor sea resistente a los fallos regionales. La conmutación por error entre regiones del servicio debe implementarse tanto en la lógica de la aplicación de servicio como en el diseño del balanceo de carga del productor del servicio. Los productores de servicios pueden implementar otros mecanismos.
Para determinar qué producto de Cloud Load Balancing debes usar, primero debes determinar qué tipo de tráfico deben gestionar tus balanceadores de carga. Ten en cuenta las siguientes reglas generales:
- Usa un balanceador de carga de aplicaciones si tu tráfico es HTTP o HTTPS.
- Usa un balanceador de carga de red de proxy para el tráfico TCP que no sea HTTP(S). Este balanceador de carga de proxy también admite la descarga de TLS.
- Usa un balanceador de carga de red de tipo pases para conservar la dirección IP de origen del cliente en el encabezado o para admitir protocolos adicionales, como UDP, ESP e ICMP.
Para obtener instrucciones detalladas sobre cómo seleccionar el balanceador de carga más adecuado para tu caso de uso, consulta Elegir un balanceador de carga.
Servicios con backends sin servidor
Un servicio se puede definir mediante backends sin servidor. El backend del entorno de producción se puede organizar en un NEG sin servidor como backend de un balanceador de carga. Este servicio se puede publicar mediante Private Service Connect creando un archivo adjunto de servicio asociado al frontend del balanceador de carga del productor. El servicio publicado se puede consumir a través de los endpoints o los backends de Private Service Connect. Si el servicio requiere conexiones iniciadas por el productor, puedes usar un conector de acceso a VPC sin servidor para que los entornos de Cloud Run, App Engine estándar y funciones de Cloud Run envíen paquetes a las direcciones IPv4 internas de los recursos de una red de VPC. Acceso a VPC sin servidor también permite enviar paquetes a otras redes conectadas a la red de VPC seleccionada.
Métodos para acceder a servicios de forma privada
Tu aplicación puede estar formada por servicios gestionados proporcionados por Google, servicios de terceros proporcionados por proveedores externos o grupos de usuarios de tu organización, y servicios que desarrolle tu equipo. Es posible que se pueda acceder a algunos de esos servicios a través de Internet mediante direcciones IP públicas. En esta sección se describen los métodos que puedes usar para acceder a esos servicios mediante la red privada. Existen los siguientes tipos de servicio:
- APIs públicas de Google
- APIs sin servidor de Google
- Servicios gestionados publicados de Google
- Servicios gestionados publicados por proveedores y partners
- Tus servicios publicados
Tenga en cuenta estas opciones al leer las secciones siguientes. En función de cómo asignes tus servicios, puedes usar una o varias de las opciones de acceso privado descritas.
La organización (o el grupo de una organización) que ensambla, publica y gestiona un servicio se denomina productor del servicio. Tú y tu aplicación sois los consumidores del servicio.
Algunos servicios gestionados se publican exclusivamente mediante acceso a servicios privados. Los diseños de red recomendados en Conectividad interna y redes de VPC se adaptan a los servicios publicados con acceso a servicios privados y Private Service Connect.
Para obtener una descripción general de las opciones de acceso privado a servicios, consulta el artículo Opciones de acceso privado a servicios.
Te recomendamos que uses Private Service Connect para conectarte a servicios gestionados siempre que sea posible. Para obtener más información sobre los patrones de implementación de Private Service Connect, consulta Patrones de implementación de Private Service Connect.
Hay dos tipos de Private Service Connect, y los diferentes servicios se pueden publicar como cualquiera de los dos tipos:
Otros servicios pueden consumir directamente los servicios publicados como endpoints de Private Service Connect. Los servicios dependen de la autenticación y la resiliencia proporcionadas por el productor del servicio. Si quieres tener más control sobre la autenticación y la resiliencia de los servicios, puedes usar backends de Private Service Connect para añadir una capa de balanceo de carga para la autenticación y la resiliencia en la red del consumidor.
En el siguiente diagrama se muestran los servicios a los que se accede a través de los endpoints de Private Service Connect:
En el diagrama se muestra el siguiente patrón:
- Un punto final de Private Service Connect se implementa en la VPC del consumidor, lo que hace que el servicio del productor esté disponible para las VMs y los nodos de GKE.
- Las redes de consumidor y de productor deben desplegarse en la misma región.
En el diagrama anterior, los endpoints se muestran como recursos regionales. Se puede acceder a los endpoints desde otras regiones gracias al acceso global.
Para obtener más información sobre los patrones de implementación, consulta Patrones de implementación de Private Service Connect.
Los backends de Private Service Connect usan un balanceador de carga configurado con backends de grupo de endpoints de red (NEG) de Private Service Connect. Para ver una lista de los balanceadores de carga admitidos, consulta Información sobre los back-ends de Private Service Connect.
Los backends de Private Service Connect te permiten crear las siguientes configuraciones de backend:
- Dominios y certificados propiedad del cliente delante de servicios gestionados
- Conmutación por error controlada por el consumidor entre servicios gestionados de diferentes regiones
- Configuración de seguridad y control de acceso centralizados para servicios gestionados
En el siguiente diagrama, el balanceador de carga global usa un NEG de Private Service Connect como backend que establece la comunicación con el proveedor de servicios. No se necesita ninguna configuración de red adicional y los datos se transfieren a través de la estructura SDN de Google.
La mayoría de los servicios están diseñados para conexiones que inicia el consumidor. Cuando los servicios necesiten iniciar conexiones desde el productor, usa interfaces de Private Service Connect.
Un aspecto clave que se debe tener en cuenta al implementar el acceso a servicios privados o Private Service Connect es la transitividad. Se puede acceder a los puntos de acceso de cliente de Private Service Connect a través de Network Connectivity Center. No se puede acceder a los servicios publicados a través de una conexión de emparejamiento entre redes VPC para los puntos de acceso de consumidor de Private Service Connect o de acceso a servicios privados. Si no hay transitividad entre VPCs para todos los puntos de acceso de los consumidores de servicios, la ubicación de la subred o los endpoints de acceso al servicio en la topología de la VPC determinará si diseñas la red para una implementación de servicio compartida o dedicada.
Opciones como la VPN de alta disponibilidad y los proxies gestionados por el cliente proporcionan métodos para permitir la comunicación transitiva entre VPCs.
No se puede acceder a los endpoints de Private Service Connect a través del emparejamiento entre redes VPC. Si necesitas este tipo de conectividad, implementa un balanceador de carga interno y un NEG de Private Service Connect como backend, tal como se muestra en el siguiente diagrama:
Se puede acceder a las APIs de Google de forma privada mediante endpoints y backends de Private Service Connect. Por lo general, se recomienda usar endpoints, ya que el productor de la API de Google proporciona autenticación basada en certificados y resiliencia.
Crea un endpoint de Private Service Connect en cada VPC en la que se deba acceder al servicio. Como la dirección IP del consumidor es una dirección IP privada global, se requiere una sola asignación de DNS para cada servicio, aunque haya instancias de endpoint en varias VPCs, como se muestra en el siguiente diagrama:
Definir patrones de consumo de servicios publicados
Los servicios publicados se pueden ejecutar en varias ubicaciones: tu red de VPC, otra red de VPC, un centro de datos local o en la nube. Independientemente de dónde se ejecute la carga de trabajo del servicio, tu aplicación consume esos servicios mediante un punto de acceso, como uno de los siguientes:
- Una dirección IP de una subred de acceso de servicios privados
- Un endpoint de Private Service Connect
- Una dirección IP virtual de un balanceador de carga que usa NEGs de Private Service Connect
Los puntos de acceso de los consumidores se pueden compartir entre redes o dedicarse a una sola red. Decide si quieres crear puntos de acceso de consumidor compartidos o dedicados en función de si tu organización delega la tarea de crear puntos de acceso de servicio de consumidor en cada grupo de aplicaciones o gestiona el acceso a los servicios de forma consolidada.
La gestión del acceso a los servicios implica las siguientes actividades:
- Crear los puntos de acceso
- Desplegar los puntos de acceso en una VPC de acceso a servicios, que es una VPC que tiene el tipo de accesibilidad adecuado
- Registrar las direcciones IP y las URLs de los puntos de acceso de los consumidores en DNS
- Gestionar los certificados de seguridad y la resiliencia del servicio en el espacio de consumo al añadir el balanceo de carga delante de los puntos de acceso de los consumidores
En algunas organizaciones, puede ser viable asignar la gestión del acceso a los servicios a un equipo central, mientras que otras pueden estar estructuradas para dar más independencia a cada equipo de consumidor o de aplicación. Un efecto secundario de operar en el modo dedicado es que algunos de los elementos se replican. Por ejemplo, un servicio se registra con varios nombres de DNS por cada grupo de aplicaciones y gestiona varios conjuntos de certificados TLS.
El diseño de VPC descrito en Segmentación de red y conectividad para aplicaciones distribuidas en Cross-Cloud Network permite la accesibilidad para implementar puntos de acceso de servicio en modo compartido o dedicado. Los puntos de acceso de consumidor compartidos se implementan en VPCs de acceso al servicio, a las que se puede acceder desde cualquier otra VPC o red externa. Los puntos de acceso de consumidor dedicados se implementan en las VPCs de las aplicaciones, a las que solo se puede acceder desde los recursos de esa VPC de aplicación.
La principal diferencia entre una VPC de acceso a servicios y una VPC de aplicación es la conectividad transitiva que permite una VPC de acceso a servicios. Las VPCs de acceso a servicios no se limitan a alojar puntos de acceso de consumidores. Una VPC puede alojar recursos de aplicaciones, así como puntos de acceso de consumidores compartidos. En ese caso, la VPC debe configurarse y gestionarse como una VPC de servicio.
Acceso compartido a servicios gestionados
En todos los métodos de consumo de servicios, incluido Private Service Connect, asegúrate de hacer lo siguiente:
- Despliega los puntos de acceso de los consumidores de servicios en una VPC de servicios. Las VPCs de servicio tienen accesibilidad transitiva a otras VPCs.
- Si la VPC de acceso al servicio está conectada con una VPN de alta disponibilidad, anuncia la subred del punto de acceso del consumidor como un anuncio de ruta personalizada desde el Cloud Router que se empareja con otras redes a través de la VPN de alta disponibilidad. En el caso de las APIs de Google, anuncia la dirección IP del host de la API.
- Actualiza las reglas de cortafuegos multicloud para permitir la subred de acceso a servicios privados.
En el caso del acceso a servicios privados, asegúrate de que puedes cumplir los siguientes requisitos adicionales:
- Exporta rutas personalizadas a la red del productor de servicios. Para obtener más información, consulta Los hosts locales no pueden comunicarse con la red del productor de servicios.
- Crea reglas de cortafuegos de entrada para permitir que la subred de servicios privados acceda a las VPCs de la aplicación
- Crea reglas de cortafuegos de entrada para permitir que la subred de acceso a los servicios privados entre en la VPC de los servicios.
Para acceder a servicios sin servidor, asegúrate de que cumples los siguientes requisitos:
- El conector de acceso requiere una subred normal /28 específica
- Cloud Router anuncia subredes normales de forma predeterminada
- Crea reglas de cortafuegos de entrada para permitir el acceso a la subred de la VPC en las VPCs
- Actualiza las reglas de cortafuegos multicloud para permitir la subred del conector de acceso a la VPC
- Crea reglas de cortafuegos de entrada para permitir que la subred de acceso a servicios privados entre en las VPCs de la aplicación.
Acceso a servicios gestionados específicos
Asegúrate de hacer lo siguiente:
- En cada VPC de aplicación en la que se necesite acceso, implementa una regla de reenvío para el servicio con el fin de crear un punto de acceso.
- Para el acceso a servicios privados, crea reglas de cortafuegos de entrada que permitan que la subred de acceso a servicios privados entre en las VPCs de la aplicación.
Para acceder a servicios sin servidor, asegúrate de que cumples los siguientes requisitos:
- El conector de acceso requiere una subred normal /28 específica
- Crea reglas de cortafuegos de entrada para permitir la subred del conector de acceso a la VPC en las VPCs de la aplicación.
Montar la pila de aplicaciones
En esta sección se describe cómo ensamblar una pila de aplicaciones regional o global.
Diseñar pilas de aplicaciones regionales
Si una aplicación sigue los arquetipos de implementación regional o multirregional, usa pilas de aplicaciones regionales. Los stacks de aplicaciones regionales se pueden considerar como una concatenación de capas de servicios de aplicaciones regionales. Por ejemplo, una capa de servicio web regional que se comunica con una capa de aplicación de la misma región, que a su vez se comunica con una capa de base de datos de la misma región, es una pila de aplicaciones regional.
Cada capa de servicio de aplicación regional usa balanceadores de carga para distribuir el tráfico entre los endpoints de la capa en esa región. La fiabilidad se consigue distribuyendo los recursos de backend en tres o más zonas de la región.
Las capas de servicio de aplicaciones de otros CSPs o centros de datos on-premise deben desplegarse en regiones equivalentes de las redes externas. Además, haz que los servicios publicados estén disponibles en la región de la pila. Para alinear la pila de aplicaciones en una región, las URLs de la capa de servicio de la aplicación deben resolverse en la dirección IP regional específica del frontend del balanceador de carga. Estas asignaciones de DNS se registran en la zona DNS correspondiente de cada servicio de aplicaciones.
En el siguiente diagrama se muestra una pila regional con resiliencia activa-en espera:
Se implementa una instancia completa de la pila de aplicaciones en cada región de los diferentes centros de datos de la nube. Cuando se produce un fallo regional en cualquiera de las capas de servicio de la aplicación, la pila de la otra región se encarga de la entrega de toda la aplicación. Esta conmutación por error se realiza en respuesta a la monitorización fuera de banda de las diferentes capas de servicio de la aplicación.
Cuando se informa de un error en una de las capas de servicio, el frontend de la aplicación se vuelve a anclar a la pila de copia de seguridad. La aplicación se escribe para hacer referencia a un conjunto de registros de nombres regionales que reflejan la pila de direcciones IP regionales en el DNS, de modo que cada capa de la aplicación mantenga sus conexiones en la misma región.
Diseñar pilas de aplicaciones globales
Cuando una aplicación sigue el arquetipo de implementación de aplicaciones globales, cada capa de servicio de la aplicación incluye backends en varias regiones. Incluir backends en varias regiones amplía el grupo de resiliencia de la capa de servicio de la aplicación más allá de una sola región y permite la detección y la reconvergencia automáticas de la conmutación por error.
En el siguiente diagrama se muestra una pila de aplicaciones global:
En el diagrama anterior se muestra una aplicación global creada a partir de los siguientes componentes:
- Servicios que se ejecutan en centros de datos locales con front-ends de balanceador de carga. Se puede acceder a los puntos de acceso del balanceador de carga a través de Cloud Interconnect desde la VPC de tránsito.
- Una VPC de tránsito aloja conexiones híbridas entre el centro de datos externo y la VPC de la aplicación.
- Una VPC de aplicación que aloja la aplicación principal que se ejecuta en instancias de carga de trabajo. Estas instancias de carga de trabajo se encuentran detrás de balanceadores de carga. Se puede acceder a los balanceadores de carga desde cualquier región de la red y pueden acceder a los backends de cualquier región de la red.
- Una VPC de servicios que aloja puntos de acceso para servicios que se ejecutan en otras ubicaciones, como en VPCs de terceros. Se puede acceder a estos puntos de acceso de servicio a través de la conexión de VPN de alta disponibilidad entre la VPC de servicios y la VPC de tránsito.
- VPCs de productores de servicios alojadas por otras organizaciones o por la organización principal, así como aplicaciones que se ejecutan en otras ubicaciones. Los servicios pertinentes se pueden alcanzar mediante backends de Private Service Connect desplegados como backends globales en balanceadores de carga regionales alojados en la VPC de los servicios. Se puede acceder a los balanceadores de carga regionales desde cualquier otra región.
Si quieres que se pueda acceder a la aplicación creada desde Internet, puedes añadir un balanceador de carga de aplicación externo global que apunte a las cargas de trabajo de la aplicación en la VPC de la aplicación (no se muestra en el diagrama).
Para admitir una pila de aplicaciones global, hemos usado back-ends globales para cada capa de aplicación. Esto permite recuperarse de un fallo de todos los endpoints backend de una región. Cada región tiene un frontend de balanceador de carga regional para cada capa de servicio de aplicación. Cuando se produce una conmutación por error regional, se puede acceder a los front-ends del balanceador de carga regional interno desde otras regiones, ya que usan el acceso global. Como la pila de aplicaciones es global, se usan políticas de enrutamiento por geolocalización de DNS para seleccionar el frontend regional más adecuado para una solicitud o un flujo concretos. En caso de que falle el frontend, se pueden usar comprobaciones del estado del DNS para automatizar la conmutación por error de un frontend a otro.
Los servicios publicados mediante backends de Private Service Connect se benefician del acceso global de Private Service Connect. Esta función permite que se pueda acceder a un backend de Private Service Connect desde cualquier región y reduce las interrupciones provocadas por fallos en la capa de servicio de la aplicación. Esto significa que los backends de Private Service Connect se pueden usar como backends globales, tal y como se describe en Determinar el ámbito del servicio: regional o global.
Proporcionar acceso privado a servicios alojados en redes externas
Puede que quieras publicar un punto de acceso local para un servicio alojado en otra red. En estos casos, puedes usar un balanceador de carga de proxy TCP regional interno con NEGs híbridos. Puedes crear un productor de servicios alojado en un entorno local o en otro entorno de nube que esté disponible para los consumidores de servicios (clientes) de tu red VPC, tal como se muestra en el siguiente diagrama:
Si quieres que el servicio híbrido esté disponible en una red de VPC distinta de la que aloja el balanceador de carga, puedes usar Private Service Connect para publicar el servicio. Si colocas una vinculación de servicio delante de tu balanceador de carga de proxy TCP regional interno, puedes permitir que los clientes de otras redes de VPC accedan a los servicios híbridos que se ejecutan de forma local o en otros entornos de nube.
En un entorno multicloud, el uso de un NEG híbrido permite una comunicación segura entre aplicaciones.
Cuando otra organización publique un servicio de aplicación, usa un NEG híbrido para ampliar las abstracciones de acceso privado de ese servicio. El siguiente diagrama ilustra este caso:
En el diagrama anterior, la capa de servicio de la aplicación se compone por completo en el CSP vecino, que se destaca en las partes del diagrama que no están atenuadas. Los balanceadores de carga híbridos se usan junto con las vinculaciones de servicio de Private Service Connect como mecanismo para publicar el servicio de aplicación externo para el consumo privado enGoogle Cloud. Los balanceadores de carga híbridos con NEGs híbridos y vinculaciones de servicio de Private Service Connect se encuentran en una VPC que forma parte de un proyecto de productor de servicios. Este proyecto de productor de servicios suele ser una VPC diferente de la VPC de tránsito, ya que se encuentra en el ámbito administrativo de la organización o el proyecto del productor y, por lo tanto, está separado de los servicios de tránsito comunes. No es necesario que la VPC del productor esté conectada mediante el emparejamiento de VPC o la VPN de alta disponibilidad con la VPC del consumidor (que es la VPC compartida de servicios en el diagrama).
Centralizar el acceso a los servicios
El acceso a los servicios se puede centralizar en una red de VPC y se puede acceder a ellos desde otras redes de aplicaciones. En el siguiente diagrama se muestra el patrón habitual que permite centralizar los puntos de acceso:
En el siguiente diagrama se muestran todos los servicios a los que se accede desde una VPC de servicios dedicada:
Cuando los servicios se encuentran en la parte frontal de los balanceadores de carga de aplicaciones, puedes consolidarlos en menos balanceadores de carga usando mapas de URLs para dirigir el tráfico a diferentes back-ends de servicio en lugar de usar un balanceador de carga diferente para cada servicio. En principio, una pila de aplicaciones podría estar compuesta por completo por un único balanceador de carga de aplicaciones, además de backends de servicio y asignaciones de URLs adecuadas.
En esta implementación, debe usar NEGs híbridos en las VPCs para la mayoría de los tipos de backend. La excepción es un NEG o un backend de Private Service Connect, tal como se describe en Encadenamiento explícito de balanceadores de carga de nivel 7 con Private Service Connect Google Cloud .
El uso de NEGs híbridos en varias VPCs implica renunciar a la reparación automática y al autoescalado de los back-ends. Los servicios publicados ya tienen un balanceador de carga en el arrendatario productor que proporciona escalado automático. Por lo tanto, solo te encontrarás con las limitaciones de los NEGs híbridos si centralizas la función de balanceo de carga de las capas de servicio que se componen de forma nativa en lugar de consumirse a partir de la publicación.
Cuando utilices este patrón de red de servicios, recuerda que los servicios se consumen a través de una capa adicional de balanceo de carga.
Se puede acceder a los puntos finales de servicio de Private Service Connect en las VPCs de radio de Network Connectivity Center.
El modo centralizado añade una capa de equilibrio de carga en el lado del consumidor del servicio. Cuando usas este modo, también debes gestionar los certificados, la resiliencia y las asignaciones de DNS adicionales en el proyecto de consumidor.
Otras cuestiones:
En esta sección se incluyen consideraciones sobre productos y servicios comunes que no se tratan explícitamente en este documento.
Consideraciones sobre el plano de control de GKE
El plano de control de GKE se implementa en un proyecto de inquilino gestionado por Google que está conectado a la VPC del cliente mediante el emparejamiento entre redes de VPC. Como el emparejamiento entre redes de VPC no es transitivo, no es posible comunicarse directamente con el plano de control a través de una topología de red emparejada de VPC de concentrador y radios.
Al plantearse las opciones de diseño de GKE, como la centralizada o la descentralizada, el acceso directo al plano de control desde fuentes multinube es un factor clave. Si GKE se implementa en una VPC centralizada, se puede acceder al plano de control en todas las nubes y enGoogle Cloud. Sin embargo, si GKE se despliega en VPCs descentralizadas, no es posible comunicarse directamente con el plano de control. Si los requisitos de una organización exigen el acceso al plano de control de GKE, además de adoptar el patrón de diseño descentralizado, los administradores de red pueden desplegar un agente de conexión que actúe como proxy. De esta forma, se supera la limitación de emparejamiento no transitivo al plano de control de GKE.
Seguridad - Controles de Servicio de VPC
En el caso de las cargas de trabajo que impliquen datos sensibles, utiliza Controles de Servicio de VPC para configurar perímetros de servicio en torno a tus recursos de VPC y servicios gestionados por Google, así como para controlar el movimiento de datos a través del límite del perímetro. Con los Controles de Servicio de VPC, puedes agrupar proyectos y tu red local en un único perímetro que impida el acceso a los datos a través de los servicios gestionados por Google. Las reglas de entrada y salida de Controles de Servicio de VPC se pueden usar para permitir que los proyectos y los servicios de diferentes perímetros de servicio se comuniquen (incluidas las redes de VPC que no están dentro del perímetro).
Para ver las arquitecturas de implementación recomendadas, un proceso de incorporación completo y las prácticas recomendadas operativas, consulta el artículo Prácticas recomendadas para usar los controles del servicio VPC en empresas y el plan técnico de las bases de seguridad.
DNS para APIs y servicios
Los productores de servicios pueden publicar servicios mediante Private Service Connect. El productor del servicio puede configurar un nombre de dominio DNS para asociarlo al servicio. Si se configura un nombre de dominio y un consumidor de servicios crea un punto final que apunta a ese servicio, Private Service Connect y Directorio de servicios crearán automáticamente entradas de DNS para el servicio en una zona DNS privada de la red de VPC del consumidor de servicios.
Siguientes pasos
- Diseña la seguridad de la red para las aplicaciones de Cross-Cloud Network.
- Consulta más información sobre los Google Cloud productos que se usan en esta guía de diseño:
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.
Colaboradores
Autores:
- Victor Moreno | Product Manager, Cloud Networking
- Ghaleb Al-habian | Especialista en redes
- Deepak Michael | Ingeniero de clientes especialista en redes
- Osvaldo Costa | Ingeniero de clientes especializado en redes
- Jonathan Almaleh | Asesor técnico de soluciones
Otros colaboradores:
- Zach Seils | Especialista en redes
- Christopher Abraham | Ingeniero de clientes especializado en redes
- Emanuele Mazza | Especialista de Producto de Redes
- Aurélien Legrand | Ingeniero estratégico de Cloud
- Eric Yu | Ingeniero de clientes especialista en redes
- Kumar Dhanagopal | Desarrollador de soluciones entre productos
- Mark Schlagenhauf | Redactor técnico de redes
- Marwan Al Shawi | Ingeniero de clientes de partners
- Ammett Williams | Ingeniero de Relaciones con Desarrolladores