Este documento forma parte de una serie de guías de diseño para Cross-Cloud Network.
La serie consta de las siguientes partes:
- Cross-Cloud Network para aplicaciones distribuidas
- Segmentación de red y conectividad para aplicaciones distribuidas en Red Multinube
- Herramientas de redes de servicio para aplicaciones distribuidas en Red Multinube (este documento)
- Seguridad de redes para aplicaciones distribuidas en Cross-Cloud Network
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 te guiará por las siguientes decisiones:
- Ya sea que crees el servicio individual por tu cuenta o consumas un servicio de terceros
- Si el servicio está disponible de forma global o regional
- Si el servicio se consume de forma local, desde otras nubes o desde ninguna de las dos opciones
- Si accedes al extremo de servicio a través de una VPC de servicios compartidos o distribuyes los extremos a través de todas las VPC de aplicación pertinentes
En este documento, se te guiará por los siguientes pasos:
- Decide si tu aplicación es global o regional
- Elegir servicios administrados de terceros o crear y publicar tus propios servicios
- Configurar el acceso privado a los extremos de servicio con un modo compartido o dedicado
- Ensamblar los servicios en aplicaciones para que coincidan con un arquetipo global o regional
Los desarrolladores definen la capa de red de servicios para Red Multinube. En esta etapa, los administradores diseñaron una capa de conectividad para Red Multinube que permite flexibilidad en las opciones de redes de servicios que se describen en este documento. En algunos casos, existen restricciones de la transitividad limitada entre VPC. Describimos estas restricciones cuando pueden afectar las decisiones de diseño.
Decide si tu aplicación es regional o global
Determina si los clientes de la aplicación que estás creando necesitan un arquetipo de implementación regional o global. Puedes lograr resiliencia regional distribuyendo las cargas entre las zonas de una región. Puedes lograr resiliencia global distribuyendo las cargas entre regiones.
Ten en cuenta los siguientes factores cuando elijas un arquetipo:
- Los requisitos de disponibilidad de la aplicación
- La ubicación en la que se consume la aplicación
- Costo
Para obtener más detalles, consulta los arquetipos de implementación deGoogle Cloud .
En esta guía de diseño, se analiza cómo admitir los siguientes arquetipos de implementación:
- Arquetipo de implementación multirregional deGoogle Cloud
- Arquetipo de implementación global deGoogle Cloud
En una aplicación distribuida multinube, se pueden entregar diferentes servicios de esa aplicación desde distintos proveedores de servicios en la nube (CSP) o centros de datos privados. Para garantizar una estructura de resiliencia coherente, coloca los servicios alojados en diferentes CSP en centros de datos de CSP que estén geográficamente cerca entre sí.
En el siguiente diagrama, se muestra una pila de aplicaciones global que se distribuye en nubes y diferentes servicios de aplicaciones se implementan en diferentes CSP. Cada servicio de aplicación global tiene instancias de carga de trabajo en diferentes regiones del mismo CSP.
Define los servicios de la aplicación y accede a ellos
Para ensamblar tu aplicación, puedes usar servicios administrados de terceros existentes, crear y alojar tus propios servicios de aplicación o usar una combinación de ambos.
Usa servicios administrados de terceros existentes
Decidir qué servicios administrados de terceros puedes usar para tu aplicación Determina cuáles se construyen como servicios regionales o globales. Además, determina qué opciones de acceso privado admite cada servicio.
Cuando sepas qué servicios administrados puedes usar, podrás determinar qué servicios necesitas crear.
Crea servicios de aplicaciones y accede a ellos
Cada servicio se aloja en una o más instancias de carga de trabajo a las que se puede acceder como un solo extremo o como un grupo de extremos.
El patrón general de un servicio de aplicación se muestra en el siguiente diagrama. El servicio de la 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 VM de Compute Engine, un clúster de Google Kubernetes Engine (GKE) o algún otro backend que ejecute código. Las instancias de carga de trabajo se organizan como un conjunto de backends que se asocian con un balanceador de cargas.
En el siguiente diagrama, se muestra un balanceador de cargas genérico con un conjunto de backends.
Para lograr la distribución de carga elegida y automatizar las conmutaciones por error, estos grupos de extremos usan un balanceador de cargas de frontend. Con los grupos de instancias administrados (MIG), puedes aumentar o disminuir de forma elástica la capacidad del servicio ajustando la escala automáticamente de los extremos que forman el backend del balanceador de cargas. Además, según los requisitos del servicio de la aplicación, el balanceador de cargas también puede proporcionar autenticación, finalización de TLS y otros servicios específicos de la conexión.
Determinar el alcance 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 aplicaciones global puede admitir conmutaciones por error síncronas entre nodos que se distribuyen en varias regiones. Si tu aplicación es global, es posible que quieras que los servicios que la respaldan también lo sean. Sin embargo, si tu servicio requiere sincronización entre sus instancias para admitir la conmutación por error, debes considerar la latencia entre las regiones. En tu situación, es posible que debas confiar en los servicios regionales con redundancia en la misma región o en regiones cercanas, lo que admite la sincronización de baja latencia para la conmutación por error.
Cloud Load Balancing admite extremos alojados en una sola región o distribuidos en varias regiones. Por lo tanto, puedes crear una capa global orientada al cliente que se comunique con capas de servicios globales, regionales o híbridas. Elige las implementaciones de servicio para asegurarte de que la conmutación por error de red dinámica (o el balanceo de cargas entre regiones) se alinee con el estado de resiliencia y las capacidades de la lógica de tu aplicación.
En el siguiente diagrama, se muestra cómo un servicio global que se compila a partir de balanceadores de cargas regionales puede llegar a backends en otras regiones, lo que proporciona 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 cargas envía solicitudes principalmente a la región local, pero puede conmutar por error a regiones remotas.
- Un backend global es una colección de backends regionales a los que acceden uno o más balanceadores de cargas.
- Aunque los backends son globales, el frontend de cada balanceador de cargas es regional.
- En este patrón de arquitectura, los balanceadores de cargas distribuyen el tráfico principalmente solo dentro de 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 balanceador de cargas regionales, cada uno accesible desde otras regiones y cada uno capaz de llegar a backends en otras regiones, forma un servicio global agregado.
- Para ensamblar una pila de aplicaciones global, como se analiza en Diseña pilas de aplicaciones globales, puedes usar el enrutamiento de DNS y las verificaciones de estado para lograr la conmutación por error interregional de los frontends.
- Se puede acceder a los frontends del balanceador de cargas desde otras regiones con 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 backends 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 la resiliencia ante fallas regionales en la infraestructura de balanceo de cargas del consumidor. La conmutación por error entre regiones del servicio se debe implementar tanto en la lógica de la aplicación del servicio como en el diseño del balanceo de cargas del productor de servicios. Los productores de servicios pueden implementar otros mecanismos.
Para determinar qué producto de Cloud Load Balancing usar, primero debes determinar qué tipo de tráfico deben manejar tus balanceadores de cargas. Ten en cuenta las siguientes reglas generales:
- Usa un balanceador de cargas de aplicaciones para el tráfico HTTP(S).
- Usa un balanceador de cargas de red de proxy para el tráfico de TCP que no sea HTTP(S). Este balanceador de cargas de proxy también admite la descarga de TLS.
- Usa un balanceador de cargas de red de transferencia para conservar la dirección IP de origen del cliente en el encabezado o para admitir protocolos adicionales, como UDP, ESP o ICMP.
Si deseas obtener orientación detallada para seleccionar el mejor balanceador de cargas para tu caso de uso, consulta Elige un balanceador de cargas.
Servicios con backends sin servidores
Un servicio se puede definir con backends sin servidores. El backend en el entorno del productor se puede organizar en un NEG sin servidores como un backend para un balanceador de cargas. Este servicio se puede publicar con Private Service Connect creando un adjunto de servicio que esté asociado con el frontend del balanceador de cargas del productor. El servicio publicado se puede consumir a través de extremos o backends de Private Service Connect. Si el servicio requiere conexiones iniciadas por el productor, puedes usar un conector de Acceso a VPC sin servidores para permitir que los entornos de Cloud Run, App Engine estándar y Cloud Run Functions envíen paquetes a las direcciones IPv4 internas de los recursos en una red de VPC. El Acceso a VPC sin servidores también admite el envío de paquetes a otras redes conectadas a la red de VPC seleccionada.
Métodos para acceder a los servicios de forma privada
Tu aplicación puede constar de servicios administrados que proporciona Google, servicios de terceros que proporcionan proveedores externos o grupos de pares de tu organización, y servicios que desarrolla tu equipo. Se puede acceder a algunos de esos servicios a través de Internet con direcciones IP públicas. En esta sección, se describen los métodos que puedes usar para acceder a esos servicios con la red privada. Existen los siguientes tipos de servicio:
- APIs públicas de Google
- APIs sin servidores de Google
- Servicios administrados publicados de Google
- Servicios administrados publicados de proveedores y pares
- Tus servicios publicados
Ten en cuenta estas opciones cuando leas las secciones siguientes. Según cómo asignes tus servicios, puedes usar una o más de las opciones de acceso privado descritas.
La organización (o el grupo dentro de una organización) que reúne, publica y administra un servicio se denomina productor de servicios. Tú y tu aplicación se denominan consumidor del servicio.
Algunos servicios administrados se publican exclusivamente con el acceso privado a servicios. Los diseños de red recomendados en Conectividad interna y redes de VPC se adaptan a los servicios publicados con acceso privado a servicios y Private Service Connect.
Para obtener una descripción general de las opciones de acceso privado a los servicios, consulta Opciones de acceso privado a los servicios.
Te recomendamos que uses Private Service Connect para conectarte a los servicios administrados 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.
Existen dos tipos de Private Service Connect, y los diferentes servicios se pueden publicar como cualquiera de los dos tipos:
Los servicios publicados como extremos de Private Service Connect se pueden consumir directamente con otras cargas de trabajo. Los servicios dependen de la autenticación y la resiliencia que aprovisiona el productor del servicio. Si deseas tener un control adicional sobre la autenticación y la resiliencia del servicio, puedes usar backends de Private Service Connect para agregar una capa de balanceo de cargas para la autenticación y la resiliencia en la red del consumidor.
En el siguiente diagrama, se muestra cómo se accede a los servicios a través de los extremos de Private Service Connect:
En el diagrama, se muestra el siguiente patrón:
- Se implementa un extremo de Private Service Connect 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 del consumidor y del productor deben implementarse en la misma región.
En el diagrama anterior, se muestran los extremos como recursos regionales. Se puede acceder a los extremos desde otras regiones debido 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 cargas configurado con backends de grupos de extremos de red (NEG) de Private Service Connect Para obtener una lista de los balanceadores de cargas compatibles, consulta Acerca de los backends de Private Service Connect.
Los backends de Private Service Connect te permiten crear las siguientes configuraciones de backend:
- Dominios y certificados de cliente frente a servicios administrados
- Conmutación por error controlada por el consumidor entre servicios administrados en diferentes regiones
- Configuración de seguridad centralizada y control de acceso para servicios administrados
En el siguiente diagrama, el balanceador de cargas global usa un NEG de Private Service Connect como un backend que establece la comunicación con el proveedor de servicios. No se requiere ninguna configuración de red adicional, y los datos se transportan a través de la estructura de SDN de Google.
La mayoría de los servicios están diseñados para las conexiones que inicia el consumidor. Cuando los servicios necesiten iniciar conexiones desde el productor, usa interfaces de Private Service Connect.
Una consideración clave cuando se implementa el acceso privado a servicios o Private Service Connect es la transitividad. Se puede acceder a los puntos de acceso del consumidor 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 intercambio de tráfico entre redes de VPC para los puntos de acceso de consumidores de Private Service Connect o de acceso privado a servicios. En ausencia de transitividad entre VPC para todos los puntos de acceso del consumidor de servicios, la ubicación de la subred o los extremos de acceso al servicio en la topología de VPC determina si diseñas la red para la implementación de servicios compartidos o dedicados.
Las opciones como la VPN con alta disponibilidad y los proxies administrados por el cliente proporcionan métodos para permitir la comunicación transitiva entre VPC.
No se puede acceder a los extremos de Private Service Connect a través del intercambio de tráfico entre redes de VPC. Si necesitas este tipo de conectividad, implementa un balanceador de cargas interno y un NEG de Private Service Connect como backend, como se muestra en el siguiente diagrama:
Se puede acceder a las APIs de Google de forma privada con extremos y backends de Private Service Connect. Por lo general, se recomienda el uso de extremos, ya que el productor de la API de Google proporciona resiliencia y autenticación basada en certificados.
Crea un extremo de Private Service Connect en cada VPC en la que se deba acceder al servicio. Debido a que la dirección IP del consumidor es una dirección IP global privada, se requiere una sola asignación de DNS para cada servicio, incluso si hay instancias de extremo en varias VPC, como se muestra en el siguiente diagrama:
Define patrones de consumo para los servicios publicados
Los servicios publicados se pueden ejecutar en varias ubicaciones: tu red de VPC, otra red de VPC, en 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 con un punto de acceso, como uno de los siguientes:
- Una dirección IP en una subred de acceso privado a servicios
- Un extremo de Private Service Connect
- Una VIP para un balanceador de cargas que usa NEG de Private Service Connect
Los puntos de acceso del consumidor se pueden compartir entre redes o dedicarse a una sola red. Decide si 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 a cada grupo de aplicaciones o administra el acceso a los servicios de manera consolidada.
La administración del acceso a los servicios implica las siguientes actividades:
- Crea los puntos de acceso
- Implementar los puntos de acceso en una VPC de acceso a servicios, que es una VPC que tiene el tipo de accesibilidad adecuado
- Registra las direcciones IP y las URLs de los puntos de acceso del consumidor en el DNS
- Administrar los certificados de seguridad y la resiliencia del servicio en el espacio del consumidor, cuando se agrega el balanceo de cargas frente a los puntos de acceso del consumidor
En algunas organizaciones, puede ser viable asignar la administració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 consumidores o de aplicaciones. Un subproducto de operar en el modo dedicado es que algunos de los elementos se replican. Por ejemplo, cada grupo de aplicaciones registra un servicio con varios nombres de DNS y administra varios conjuntos de certificados TLS.
El diseño de VPC que se describe en Segmentación de red y conectividad para aplicaciones distribuidas en Red Multinube permite la accesibilidad para implementar puntos de acceso de servicio en un modo compartido o dedicado. Los puntos de acceso de consumidor compartidos se implementan en las VPC 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 VPC de la aplicación, a las que solo se puede acceder desde los recursos dentro de esa VPC de la aplicación.
La principal diferencia entre una VPC de acceso a servicios y una VPC de aplicación es la conectividad transitiva del punto de acceso a servicios que habilita una VPC de acceso a servicios. Las VPC de acceso al servicio 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 tal caso, la VPC se debe configurar y controlar como una VPC de servicio.
Acceso compartido a servicios administrados
Para todos los métodos de consumo de servicios, incluido Private Service Connect, asegúrate de realizar las siguientes tareas:
- Implementa los puntos de acceso de los consumidores de servicios en una VPC de servicios. Las VPC de servicio tienen accesibilidad transitiva a otras VPC.
- Si la VPC de acceso a servicios está conectada con una VPN con alta disponibilidad, anuncia la subred para el punto de acceso del consumidor como un anuncio de ruta personalizado desde el Cloud Router que intercambia tráfico con otras redes a través de la VPN con alta disponibilidad. Para las APIs de Google, anuncia la dirección IP del host de la API.
- Actualiza las reglas de firewall de múltiples nubes para permitir la subred de acceso privado a servicios.
Específicamente para el acceso privado a servicios, asegúrate de que puedas cumplir con los siguientes requisitos adicionales:
- Exportar rutas personalizadas a la red del productor de servicios Para obtener más información, consulta Los hosts locales no pueden comunicarse con la productor de servicios de servicios.
- Crea reglas de firewall de entrada para permitir que la subred de acceso privado a servicios acceda a las VPC de la aplicación
- Crea reglas de firewall de entrada para permitir que la subred de acceso privado a servicios ingrese a la VPC de servicios
Para el acceso a servicios sin servidores, asegúrate de poder cumplir con los siguientes requisitos:
- El conector de acceso requiere una subred regular /28 dedicada
- Cloud Router anuncia subredes normales de forma predeterminada
- Crear reglas de firewall de entrada para permitir el acceso a la subred de VPC dentro de las VPC
- Actualiza las reglas de firewall de múltiples nubes para permitir la subred del conector de acceso a VPC
- Crea reglas de firewall de entrada para permitir que la subred de acceso privado a servicios ingrese a las VPC de la aplicación
Acceso dedicado a servicios administrados
Asegúrate de realizar las siguientes tareas:
- En cada VPC de aplicación en la que se necesite acceso, implementa una regla de reenvío para que el servicio cree un punto de acceso.
- Para el acceso privado a servicios, crea reglas de firewall de entrada que permitan que la subred de acceso privado a servicios ingrese a las VPC de la aplicación.
Para el acceso a servicios sin servidores, asegúrate de poder cumplir con los siguientes requisitos:
- El conector de acceso requiere una subred regular /28 dedicada
- Crea reglas de firewall de entrada para permitir la subred del conector de Acceso a VPC dentro de las VPC de la aplicación.
Ensambla la pila de aplicaciones
En esta sección, se describe cómo ensamblar una pila de aplicaciones regional o global.
Diseña pilas de aplicaciones regionales
Cuando una aplicación sigue los arquetipos de implementación regional o multirregional, usa pilas de aplicaciones regionales. Las pilas 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 en la misma región, que, a su vez, se comunica con una capa de base de datos en la misma región, es una pila de aplicaciones regional.
Cada capa de servicio de aplicación regional usa balanceadores de cargas para distribuir el tráfico entre los extremos de la capa en esa región. La confiabilidad se logra distribuyendo los recursos de backend en tres o más zonas de la región.
Las capas de servicio de aplicaciones en otros CSP o centros de datos locales deben implementarse en regiones equivalentes en 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 dentro de una región, las URLs de la capa de servicio de la aplicación deben resolverse en la dirección IP regional de frontend del balanceador de cargas específico. Estas asignaciones de DNS se registran en la zona del DNS correspondiente para cada servicio de aplicación.
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 en los diferentes centros de datos de la nube. Cuando se produce una falla 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 supervisión fuera de banda de las diferentes capas de servicio de la aplicación.
Cuando se informa una falla 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 dentro de la misma región.
Diseña pilas de aplicaciones globales
Cuando una aplicación sigue el arquetipo de implementación de aplicaciones global, cada capa de servicio de la aplicación incluye backends en varias regiones. Incluir backends en varias regiones expande el grupo de resiliencia para la capa de servicio de la aplicación más allá de una sola región y habilita la detección de conmutación por error y la reconvergencia automatizadas.
En el siguiente diagrama, se muestra una pila de aplicaciones global:
En el diagrama anterior, se muestra una aplicación global ensamblada a partir de los siguientes componentes:
- Servicios que se ejecutan en centros de datos locales con frontends de balanceador de cargas. Se puede acceder a los puntos de acceso del balanceador de cargas 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 las instancias de carga de trabajo. Estas instancias de carga de trabajo están detrás de balanceadores de cargas. Se puede acceder a los balanceadores de cargas desde cualquier región de la red y pueden llegar a los backends en 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 VPC de terceros. Se puede acceder a estos puntos de acceso de servicio a través de la conexión de VPN con alta disponibilidad entre la VPC de servicios y la VPC de tránsito.
- VPC de productores de servicios alojadas por otras organizaciones o la organización principal y aplicaciones que se ejecutan en otras ubicaciones. Los backends de Private Service Connect, implementados como backends globales en los balanceadores de cargas regionales alojados en la VPC de servicios, permiten acceder a los servicios pertinentes. Se puede acceder a los balanceadores de cargas regionales desde cualquier otra región.
Si deseas que se pueda acceder a la aplicación creada desde Internet, puedes agregar un balanceador de cargas de aplicaciones 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, usamos backends globales para cada capa de aplicación. Esto permite la recuperación de una falla de todos los extremos de backend en una región. Cada región tiene un frontend de balanceador de cargas regional para cada capa de servicio de la aplicación. Cuando se produce una conmutación por error regional, se puede acceder a los frontends del balanceador de cargas interno regional en todas las regiones, ya que usan el acceso global. Debido a que la pila de aplicaciones es global, se usan políticas de enrutamiento de ubicación geográfica de DNS para seleccionar el frontend regional más adecuado para una solicitud o un flujo en particular. En caso de que falle el frontend, se pueden usar las verificaciones de estado de DNS para automatizar la conmutación por error de un frontend a otro.
Los servicios publicados con 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 por fallas en la capa de servicio de la aplicación. Esto significa que los backends de Private Service Connect se pueden aprovechar como backends globales, como se describe en Determina el alcance del servicio: regional o global.
Proporcionar acceso privado a servicios alojados en redes externas
Es posible que quieras publicar un punto de acceso local para un servicio alojado en otra red. En estos casos, puedes usar un balanceador de cargas de proxy TCP regional interno con NEG híbridos. Puedes crear un productor de servicios alojado de forma local o en otros entornos de nube que estén disponibles para los consumidores de servicios (clientes) en tu red de VPC, como se muestra en el siguiente diagrama:
Si quieres que el servicio híbrido esté disponible en una red de VPC que no sea la que aloja el balanceador de cargas, puedes usar Private Service Connect para publicar el servicio. Si colocas un adjunto de servicio frente al balanceador de cargas del proxy TCP regional interno, puedes permitir que los clientes de otras redes de VPC accedan a los servicios híbridos que se ejecutan en entornos locales o en otros entornos de nube.
En un entorno multinube, el uso de un NEG híbrido permite la comunicación segura entre aplicaciones.
Cuando una organización diferente publica un servicio de aplicación, usa un NEG híbrido para extender las abstracciones de acceso privado para ese servicio. En el siguiente diagrama, se ilustra esta situación:
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 cargas híbridos se usan junto con los adjuntos de servicio de Private Service Connect como un mecanismo para publicar el servicio de aplicación externo para el consumo privado dentro de Google Cloud. Los balanceadores de cargas híbridos con NEG híbridos y adjuntos de servicio de Private Service Connect están en una VPC que forma parte de un proyecto del productor de servicios. Por lo general, este proyecto del productor de servicios puede ser una VPC diferente de la VPC de tránsito, ya que se encuentra dentro del permiso administrativo de la organización o el proyecto del productor y, por lo tanto, está separado de los servicios de tránsito comunes. La VPC del productor no necesita estar conectada a través del intercambio de tráfico entre VPC o la VPN con alta disponibilidad con la VPC del consumidor (que es la VPC compartida de servicios en el diagrama).
Centraliza el acceso a los servicios
El acceso a los servicios se puede centralizar en una red de VPC y se puede acceder a él desde otras redes de aplicaciones. En el siguiente diagrama, se muestra el patrón común 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 exponen con balanceadores de cargas de aplicaciones, puedes consolidar en menos balanceadores de cargas con mapas de URLs para dirigir el tráfico a diferentes backends de servicio en lugar de usar diferentes balanceadores de cargas para cada servicio. En principio, una pila de aplicaciones podría componerse por completo con un solo balanceador de cargas de aplicaciones, backends de servicio y mapas de URLs adecuados.
En esta implementación, debes usar NEG híbridos en las VPC para la mayoría de los tipos de backends. La excepción es un NEG o backend de Private Service Connect, como se describe en Encadenamiento explícito de balanceadores de cargas de L7 de Google Cloud con Private Service Connect.
El uso de NEG híbridos en las VPC se realiza a expensas de la reparación automática y el ajuste de escala automático para los backends. Los servicios publicados ya tienen un balanceador de cargas en el inquilino del productor que proporciona el ajuste de escala automático. Por lo tanto, solo te encontrarás con las limitaciones de los NEG híbridos si centralizas la función de balanceo de cargas para las capas de servicio que se componen de forma nativa en lugar de consumirse desde la publicación.
Cuando uses este patrón de redes de servicios, recuerda que los servicios se consumen a través de una capa adicional de balanceo de cargas.
Se puede acceder a los extremos de servicio de Private Service Connect a través de las VPC de radio de NCC.
El modo centralizado agrega una capa de balanceo de cargas en el lado del consumidor del servicio. Cuando usas este modo, también debes administrar los certificados, la resiliencia y las asignaciones de DNS adicionales en el proyecto del consumidor.
Otras consideraciones
En esta sección, se incluyen consideraciones para productos y servicios comunes que no se tratan de forma explícita en este documento.
Consideraciones sobre el plano de control de GKE
El plano de control de GKE se implementa en un proyecto de usuario administrado por Google que está conectado a la VPC del cliente a través del intercambio de tráfico entre redes de VPC. Debido a que el intercambio de tráfico entre redes de VPC no es transitivo, no es posible la comunicación directa con el plano de control a través de una topología de red de intercambio de tráfico de VPC de concentrador y radio.
Cuando se consideran las opciones de diseño de GKE, como el acceso directo centralizado o descentralizado al plano de control desde fuentes de múltiples nubes, es una consideración clave. Si GKE se implementa en una VPC centralizada, el acceso al plano de control está disponible en todas las nubes y dentro de Google Cloud. Sin embargo, si GKE se implementa en VPC descentralizadas, no es posible la comunicación directa con el plano de control. Si los requisitos de una organización necesitan acceso al plano de control de GKE, además de adoptar el patrón de diseño descentralizado, los administradores de red pueden implementar un agente de conexión que actúe como proxy, lo que supera la limitación de intercambio de tráfico no transitivo al plano de control de GKE.
Seguridad: Controles del servicio de VPC
En las cargas de trabajo que involucran datos sensibles, usa los Controles del servicio de VPC a fin de configurar perímetros de servicio en torno a los recursos de VPC y los servicios administrados por Google y controlar el movimiento de datos en el límite del perímetro. Con los Controles del servicio de VPC, puedes agrupar proyectos y la red local en un solo perímetro que impida el acceso a los datos a través de los servicios administrados por Google. Las reglas de entrada y salida de los Controles del servicio de VPC se pueden usar para permitir que los proyectos y servicios de diferentes perímetros de servicio se comuniquen (incluidas las redes de VPC que no están dentro del perímetro).
Para conocer las arquitecturas de implementación recomendadas, un proceso de integración integral y las prácticas recomendadas operativas, consulta las Prácticas recomendadas para los Controles del servicio de VPC para empresas y el Plano de bases de seguridad.
DNS para APIs y servicios
Los productores de servicios pueden publicar servicios mediante Private Service Connect. El productor de servicios puede configurar de forma opcional un nombre de dominio DNS para asociarlo con el servicio. Si se configura un nombre de dominio y un consumidor de servicios crea un extremo que se orienta a ese servicio, Private Service Connect y el Directorio de servicios crean de forma automática entradas de DNS para el servicio en una zona del DNS privada en la red de VPC del consumidor de servicios.
¿Qué sigue?
- Diseña la seguridad de redes para las aplicaciones de Red Multinube.
- Obtén más información sobre los productos de Google Cloud que se usan en esta guía de diseño:
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.
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:
- Zach Seils | Especialista en herramientas de redes
- Christopher Abraham | Ingeniero de atención al cliente especializado en herramientas de redes
- Emanuele Mazza | Especialista en productos de herramientas de redes
- Aurélien Legrand | Ingeniero estratégico de la nube
- Eric Yu | Ingeniero de atención al cliente especializado en herramientas de redes
- Autor: Kumar Dhanagopal | Desarrollador de soluciones entre productos
- Mark Schlagenhauf | Escritor técnico, Herramientas de redes
- Marwan Al Shawi | Ingeniero de Atención al Cliente para Socios
- Ammett Williams | Ingeniero de relaciones con desarrolladores