Configura un balanceador de cargas de red de proxy interno entre regiones con backends de grupos de instancias de VM
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se proporcionan instrucciones para configurar un balanceador de cargas de red del proxy interno entre regiones con backends de grupo de instancias de VM de Compute Engine.
En este ejemplo, debes configurar la implementación que se muestra en el siguiente diagrama.
Implementación de alta disponibilidad del balanceador de cargas de red del proxy interno entre regiones (haz clic para ampliar)
Esto crea un balanceador de cargas de red de proxy interno entre regiones en una red de VPC, con un servicio de backend y dos grupos de instancias administrados (MIG) de backend en las regiones REGION_A y REGION_B.
Los balanceadores de cargas de red del proxy interno entre regiones requieren los siguientes recursos:
Una red de VPC con las siguientes subredes:
Una subred de SUBNET_A y una subred de solo proxy en REGION_A.
Una subred de SUBNET_B y una subred de solo proxy en REGION_B.
Debes crear subredes de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de red del proxy interno entre regiones. La subred de solo proxy de la región se comparte entre todos los balanceadores de cargas de red del proxy internos entre regiones de la región. Las direcciones de origen de los paquetes enviados desde los balanceadores de cargas a los backends de tu servicio se asignan desde la subred de solo proxy.
En este ejemplo, la subred solo de proxy para la región REGION_B tiene el rango principal de direcciones IP de 10.129.0.0/23 y para REGION_A tiene un rango de direcciones IP principal de 10.130.0.0/23 que es el tamaño de subred recomendado.
La configuración de alta disponibilidad tiene backends de grupo de instancias administrado para implementaciones de VM de Compute Engine en regiones REGION_A y REGION_B. Si los backends en una región están inactivos, el tráfico se dirige a la otra región.
Un servicio de backend global que supervisa el uso y el estado de los backends.
Un proxy TCP de destino global, que recibe una solicitud del usuario y la reenvía al servicio de backend.
Reglas de reenvío globales, que tienen la dirección IP interna regional de tu balanceador de cargas y pueden reenviar cada solicitud entrante al proxy de destino.
La dirección IP interna asociada con la regla de reenvío puede provenir de una subred en la misma red y región que los backends. Ten en cuenta las siguientes condiciones:
La dirección IP puede (pero no es necesario) provenir de la misma subred que los grupos de instancias de backend.
La dirección IP no debe provenir de la subred de solo proxy reservada que tiene la marca --purpose configurada como GLOBAL_MANAGED_PROXY.
Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.
Dentro de la red de VPC, configura una subred en cada región en la que estén configurados los backends. Además, configura un proxy-only-subnet en cada región en la que desees configurar el balanceador de cargas.
Este ejemplo usa la siguiente red de VPC, región y subredes:
Una subred llamada SUBNET_A en la región REGION_A usa 10.1.2.0/24 para su rango de IP principal.
Una subred llamada SUBNET_B en la región REGION_B usa 10.1.3.0/24 para su rango de IP principal.
Subredes para proxies.
Una subred llamada PROXY_SN_A en la región REGION_A usa 10.129.0.0/23 para su rango de IP principal.
Una subred llamada PROXY_SN_B en la región REGION_B usa 10.130.0.0/23 para su rango de IP principal.
Se puede acceder a los balanceadores de cargas entre regiones desde cualquier región dentro de la VPC.
Los clientes de cualquier región pueden acceder de manera global a los backends del balanceador de cargas.
Una subred de solo proxy proporciona un conjunto de direcciones IP que Google Cloud usa para ejecutar proxies de Envoy en tu nombre. Los proxies finalizan las conexiones del cliente y crean conexiones nuevas a los backends.
Todos los balanceadores de cargas regionales basados en Envoy usan esta subred de solo proxy en la misma región de la red de VPC . Solo puede haber una subred de solo proxy activa para un propósito determinado, por región, por red.
En este ejemplo, se usan las siguientes reglas de firewall:
fw-ilb-to-backends. Es una regla de entrada, aplicable a las instancias con balanceo de cargas, y que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de direcciones IP de origen más restrictivo para esta regla; por ejemplo, puedes especificar solo los rangos de direcciones IP del sistema desde el que inicias sesiones SSH. En este ejemplo, se usa la etiqueta de destino allow-ssh para identificar las VMs a las que se aplica la regla de firewall.
fw-healthcheck. Una regla de entrada aplicable a las instancias con balanceo de cargas y que permite todo el tráfico de TCP de los sistemas de verificación de estado de Google Cloud(en 130.211.0.0/22 y 35.191.0.0/16). En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de firewall.
fw-backends. Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de TCP en los puertos 80, 443 y 8080 desde los proxies administrados del balanceador de cargas de red del proxy interno. En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de firewall.
Las etiquetas de destino definen las instancias de backend. Sin las etiquetas de destino, las reglas de firewall se aplican a todas las instancias de backend en la red de VPC.
Cuando crees las VM de backend, asegúrate de incluir las etiquetas de destino especificadas, como se muestra en Crea un grupo de instancias administrado.
En esta sección, se muestra cómo crear una plantilla y un grupo de instancias administrado. El grupo de instancias administrado proporciona instancias de VM que ejecutan los servidores de backend de un balanceador de cargas de red del proxy interno entre regiones de ejemplo. En tu grupo de instancias, puedes definir un servicio
HTTP y asignar un nombre al puerto pertinente. El servicio de backend del balanceador de cargas reenvía el tráfico a los puertos con nombre.
Las cargas del tráfico de los clientes se balancean a servidores de backend. A modo de demostración, los backends entregan sus propios nombres de host.
En esta sección, se crean los siguientes recursos del balanceador de cargas de red del proxy interno entre regiones:
Una verificación de estado de TCP global.
Un servicio de backend global con los mismos MIG que el backend.
Un proxy de destino global.
Dos reglas de reenvío global con direcciones IP regionales.
Para la dirección IP de la regla de reenvío, usa el rango de direcciones IP SUBNET_A o SUBNET_B. Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.
Disponibilidad del proxy
En ocasiones, las Google Cloud regiones no tienen suficiente capacidad de proxy para un nuevo balanceador de cargas. Si esto sucede, la Google Cloud consola muestra un
mensaje de advertencia de disponibilidad del proxy cuando creas el balanceador de cargas. Para resolver este problema, puedes realizar una de las siguientes acciones:
Selecciona una región diferente para el balanceador de cargas. Esta puede ser una opción práctica si tienes backends en otra región.
Selecciona una red de VPC que ya tenga asignada una subred de solo proxy.
Espera a que se resuelva el problema de capacidad.
Usa SSH para conectarte a cada instancia de cliente.
gcloud compute ssh l4-ilb-client-a --zone=ZONE_A
gcloud compute ssh l4-ilb-client-b --zone=ZONE_B
Verifica que la dirección IP entregue su nombre de host.
Verifica que la VM del cliente pueda acceder a ambas direcciones IP.
El comando debería ejecutarse correctamente y mostrar el nombre de la VM de backend que entregó la solicitud:
curl 10.1.2.99
curl 10.1.3.99
Prueba la conmutación por error
Verifica la conmutación por error a los backends en la región REGION_A cuando los backends en REGION_B estén en mal estado o sean inaccesibles. Para simular la conmutación por error, quita todos los backends de REGION_B:
Envía solicitudes a la dirección IP del balanceo de cargas en la región REGION_B.
El resultado del comando muestra respuestas de las VMs de backend en REGION_A:
{
RESULTS=
for i in {1..100}
do
RESULTS="$RESULTS:$(curl 10.1.3.99)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}
Opciones de configuración adicionales
En esta sección se expande el ejemplo de configuración para proporcionar opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en cualquier orden.
Crea un balanceador de cargas con rutas de TLS
En esta sección, se muestra cómo crear un balanceador de cargas que pueda usar el enrutamiento basado en SNI. El enrutamiento basado en SNI permite que tus balanceadores de cargas de red proxy enruten el tráfico a servicios de backend específicos según el nombre de host de la indicación de nombre del servidor (SNI) proporcionado durante el protocolo de enlace TLS.
Para crear este balanceador de cargas, usamos las mismas redes, subredes y reglas de firewall que creamos anteriormente en esta página. Configurarás la implementación que se muestra en el siguiente diagrama:
Configuración del balanceador de cargas de red del proxy externo con rutas de TLS.
Crea un backend de grupo de instancias administrado
En esta sección, se muestra cómo crear backends de grupo de instancias administrado (MIG) para el balanceador de cargas. El MIG proporciona instancias de VM que ejecutan los servidores de backend para este ejemplo.
En las instrucciones de Google Cloud CLI de esta guía, se supone que usas Cloud Shell o algún otro entorno con bash instalado.
Crea una plantilla de instancias con un servicio HTTPS de "eco" que se exponga en el puerto 443.
PORT_NAME: Es un nombre para el puerto de servicio, por ejemplo, tcp443.
PORT_NUMBER: Es un número de puerto para el puerto de entrega, por ejemplo, 443.
Configura el firewall
Configura una regla de firewall para permitir el tráfico del balanceador de cargas y de los sondeos de verificación de estado a las instancias de backend.
También puedes verificar que, si proporcionas un nombre de host de SNI diferente que no coincida con una ruta de TLS, o si no proporcionas ningún nombre de host de SNI, se descarta la solicitud.
Ejecuta una prueba con un nombre de host de SNI que no coincida con example.com para asegurarte de que se rechace la conexión.
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection
Verás el código de error connection_refused en los registros de proxyStatus cuando el balanceador de cargas rechace esas conexiones no válidas.
Protocolo PROXY para retener información de conexión del cliente
El balanceador de cargas de red de proxy interno finaliza las conexiones TCP del cliente y crea conexiones nuevas con las instancias. De forma predeterminada, no se conservan la IP de cliente original y la información del puerto.
Para conservar y enviar la información de conexión original a tus instancias, habilita el protocolo PROXY (versión 1). Este protocolo envía a la instancia un encabezado adicional que contiene la dirección IP de origen, la dirección IP de destino y los números de puerto como parte de la solicitud.
Asegúrate de que las instancias de backend del balanceador de cargas de red del proxy interno ejecuten servidores HTTP o HTTPS que admitan encabezados del protocolo PROXY. Si los servidores HTTP o HTTPS no están configurados para admitir encabezados del protocolo PROXY, las instancias de backend muestran respuestas vacías. Por ejemplo, el protocolo PROXY no funciona con el software del servidor HTTP de Apache. Puedes usar diferentes softwares de servidor web, como Nginx.
Si configuras el protocolo PROXY para el tráfico de los usuarios, también debes configurarlo para las verificaciones de estado. Si verificas el estado y entregas contenido en el mismo puerto, configura el --proxy-header de la verificación de estado para que coincida con la configuración del balanceador de cargas.
Por lo general, el encabezado del protocolo PROXY será una sola línea de texto legible para el usuario con el siguiente formato:
PROXY TCP4 \r\n
A continuación, se muestra un ejemplo del protocolo PROXY:
PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n
En el ejemplo anterior, la IP de cliente es 192.0.2.1, la IP de balanceo de cargas es 198.51.100.1, el puerto del cliente es 15221 y el puerto de destino es 110.
Cuando no se conoce la IP de cliente, el balanceador de cargas genera un encabezado de protocolo PROXY que tiene el siguiente formato:
PROXY UNKNOWN\r\n
Actualiza el encabezado del protocolo PROXY para el proxy TCP de destino
En el ejemplo de configuración del balanceador de cargas de esta página, se muestra cómo habilitar el encabezado del protocolo PROXY mientras se crea el balanceador de cargas de red del proxy interno. Sigue estos pasos a fin de cambiar el encabezado del protocolo PROXY para un proxy TCP de destino existente.
Usa la misma dirección IP entre varias reglas de reenvío internas
Para que varias reglas de reenvío interno compartan una dirección IP interna común, debes reservar la dirección IP y establecer su marca --purpose en SHARED_LOADBALANCER_VIP.
En la configuración de ejemplo, se crea un servicio de backend sin afinidad de sesión.
En estos procedimientos, se muestran cómo actualizar un servicio de backend para un balanceador de cargas de ejemplo a fin de que el servicio de backend use la afinidad de IP de cliente o la afinidad de cookie generada.
Cuando la afinidad de IP de cliente está habilitada, el balanceador de cargas dirige las solicitudes de un cliente en particular a la misma VM de backend según el hash que se generó en la dirección IP del cliente y la dirección IP del balanceador de cargas (la dirección IP interna de una regla de reenvío interna).
Puedes habilitar el desvío de conexiones en servicios de backend a fin de garantizar una interrupción mínima para tus usuarios cuando se finaliza una instancia que entrega tráfico, se quita de forma manual o la quita un escalador automático. Para obtener más información sobre el vaciado de conexiones, consulta la documentación Habilita el vaciado de conexiones.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2026-10-07 (UTC)"],[],[]]
