En esta página, se muestra cómo implementar un balanceador de cargas de aplicaciones interno entre regiones para balancear las cargas del tráfico a los extremos de red locales o en otras nubes públicas y a los que se puede acceder mediante conectividad híbrida.
Si aún no lo hiciste, revisa la descripción general de los NEG de conectividad híbrida para comprender los requisitos de red para configurar el balanceo de cargas híbrido.
Descripción general de la configuración
En el ejemplo, se configura un balanceador de cargas de aplicaciones interno entre regiones para backends de NEGs de conectividad híbrida y zonal, como se muestra en la siguiente figura:
Debes configurar la conectividad híbrida antes de configurar una implementación de balanceo de cargas híbrido. Según el producto de conectividad híbrida que elijas, usa Cloud VPN o Cloud Interconnect (dedicado o de socio).
Configura un recurso de certificado SSL
Crea un recurso de certificado SSL del Administrador de certificados como se describe a continuación:
- Implementa un certificado autoadministrado global.
- Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
- Crea un certificado administrado por Google con autorización de DNS.
Recomendamos que uses un certificado administrado por Google.
Permisos
Para configurar el balanceo de cargas híbrido, debes tener los siguientes permisos:
En Google Cloud
- Permisos para establecer la conectividad híbrida entre Google Cloud y tu entorno local o cualquier otro entorno de nube. Para obtener la lista de permisos necesarios, consulta la documentación del producto de conectividad de red.
- Permisos para crear un NEG de conectividad híbrida y el balanceador de cargas.
El rol Administrador de balanceadores de cargas de Compute (
roles/compute.loadBalancerAdmin
) contiene el permiso necesario para realizar las tareas descritas en esta guía.
En tu entorno local o en otro entorno de nube que no sea de Google Cloud
- Permisos para configurar los extremos de red que permiten que se pueda acceder a los servicios en tu entorno local o en otros entornos de nube desde Google Cloud a través de una combinación
IP:Port
. Para obtener más información, comunícate con el administrador de red de tu entorno. - Permisos para crear reglas de firewall en tu entorno local o en otros entornos de nube a fin de permitir que los sondeos de verificación de estado de Google lleguen a los extremos.
- Permisos para configurar los extremos de red que permiten que se pueda acceder a los servicios en tu entorno local o en otros entornos de nube desde Google Cloud a través de una combinación
Además, a fin de completar las instrucciones de esta página, debes crear un NEG de conectividad híbrida, un balanceador de cargas y NEG zonales (y sus extremos) que funcionen como backends basados en Google Cloud para el balanceador de cargas.
Debes ser Propietario o Editor de un proyecto o tener los siguientes roles de IAM de Compute Engine.
Tarea | Rol requerido |
---|---|
Crear redes, subredes y componentes del balanceador de cargas | Administrador de red de Compute
(roles/compute.networkAdmin ) |
Agrega y quita reglas de firewall | Administrador de seguridad de Compute
(roles/compute.securityAdmin ) |
Crea instancias | Administrador de instancias de Compute
(roles/compute.instanceAdmin ) |
Establece una conectividad híbrida
Tu Google Cloud y otros entornos de nube deben estar conectados a través de la conectividad híbrida, mediante adjuntos de VLAN de Cloud Interconnect o túneles de Cloud VPN con Cloud Router. Te recomendamos usar una conexión de alta disponibilidad.
Un Cloud Router habilitado con enrutamiento dinámico global aprende sobre el extremo específico a través del protocolo de puerta de enlace de frontera (BGP) y lo programa en tu red de VPC de Google Cloud. No se admite el enrutamiento dinámico regional. Tampoco se admiten las rutas estáticas.
La red de VPC que usas para configurar Cloud Interconnect o Cloud VPN es la misma red que usas a fin de configurar la implementación del balanceo de cargas híbrido. Asegúrate de que los rangos de CIDR de la subred de la red de VPC no entren en conflicto con los rangos de CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred se priorizan por sobre la conectividad remota.
Para obtener instrucciones, consulta la siguiente documentación:
Configura tu entorno fuera de Google Cloud
Realiza los pasos siguientes a fin de configurar tu entorno local o algún otro entorno de nube para el balanceo de cargas híbrido:
- Configura los extremos de red para exponer los servicios locales a Google Cloud (
IP:Port
). - Configura reglas de firewall en tu entorno local o en otro entorno de nube.
- Configura Cloud Router para anunciar ciertas rutas obligatorias a tu entorno privado.
Configura extremos de red
Luego de configurar la conectividad híbrida, configura uno o más extremos de red en tus entornos de nube locales o en otros a los que se pueda acceder mediante Cloud Interconnect o Cloud VPN mediante una combinación IP:port
. Esta combinación IP:port
se configura como uno o más extremos para el NEG de conectividad híbrida que se crea más adelante en Google Cloud en este proceso.
Si hay varias rutas de acceso al extremo de IP, el enrutamiento seguirá el comportamiento descrito en la descripción general de Cloud Router.
Configura reglas de firewall
Las siguientes reglas de firewall se deben crear en tu entorno local o en otro entorno de nube:
- Crea una regla de firewall de permiso de entrada en entornos locales o en otros entornos de nube para permitir que el tráfico de la subred de solo proxy de la región llegue a los extremos.
No se requiere incluir en la lista de entidades permitidas los rangos de sondeo de verificación de estado de Google para los NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes incluir en la lista de anunciantes permitidos los rangos de sondeo de verificación de estado de Google para los NEG zonales.
Anuncia rutas
Configura Cloud Router para Anunciar los siguientes rangos de IP personalizados a tu entorno local o a otro entorno de nube:
- El rango de la subred solo de proxy de la región.
Configura el entorno de Google Cloud
Para los siguientes pasos, asegúrate de usar la misma red de VPC (llamada NETWORK
en este procedimiento) que se usó para configurar la conectividad híbrida entre los entornos.
Además, asegúrate de que las regiones que se usan (llamadas REGION_A
y REGION_B
en este procedimiento) sean las mismas que se usan para crear el túnel de Cloud VPN o la VLAN de Cloud Interconnect. adjuntos.
GEO
para enrutar el tráfico del cliente a la VIP del balanceador de cargas en la región más cercana al cliente durante las interrupciones regionales.
Configura las subredes de backend
Usa esta subred para crear los backends de NEGs zonales del balanceador de cargas:
Console
En la consola de Google Cloud, ve a la página Redes de VPC.
Ve a la red que se usó para configurar la conectividad híbrida entre los entornos.
En la sección Subredes:
- Establece Modo de creación de subred en Personalizado.
- En la sección Nueva subred, ingresa la siguiente información:
- Proporciona un Nombre para la subred.
- Selecciona una Región: REGION_A
- Ingresa un Rango de direcciones IP.
- Haz clic en Listo.
Haz clic en Crear.
Para agregar más subredes en diferentes regiones, haz clic en Agregar subred y repite los pasos anteriores para REGION_B.
gcloud
Crea subredes en la red que se usó para configurar la conectividad híbrida entre los entornos.
gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=LB_SUBNET_RANGE1 \ --region=REGION_A
gcloud compute networks subnets create SUBNET_B \ --network=NETWORK \ --range=LB_SUBNET_RANGE2 \ --region=REGION_B
API
Realiza una solicitud POST
al método subnetworks.insert
.
Reemplaza PROJECT_ID
con el ID del proyecto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks { "name": "SUBNET_A", "network": "projects/PROJECT_ID/global/networks/NETWORK", "ipCidrRange": "LB_SUBNET_RANGE1", "region": "projects/PROJECT_ID/regions/REGION_A", }
Realiza una solicitud POST
al método subnetworks.insert
.
Reemplaza PROJECT_ID
con el ID del proyecto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks { "name": "SUBNET_B", "network": "projects/PROJECT_ID/global/networks/NETWORK", "ipCidrRange": "LB_SUBNET_RANGE2", "region": "projects/PROJECT_ID/regions/REGION_B", }
Reemplaza lo siguiente:
SUBNET_A
ySUBNET_B
: el nombre de las subredes.LB_SUBNET_RANGE1
yLB_SUBNET_RANGE2
: el rango de direcciones IP para las subredesREGION_A
yREGION_B
: las regiones en las que configuraste el balanceador de cargas.
Configura la subred de solo proxy
La subred de solo proxy proporciona un conjunto de direcciones IP que Google 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.
Console
Si usas la consola de Google Cloud, puedes esperar y crear la subred de solo proxy más adelante en la página Balanceo de cargas.
Si quieres crear la subred de solo proxy ahora, sigue estos pasos:
En la consola de Google Cloud, ve a la página Redes de VPC.
- Haz clic en el nombre de la red de VPC.
- En la pestaña Subredes, haz clic en Agregar subred.
- Proporciona un Nombre para la subred de solo proxy.
- En la lista Región, selecciona REGION_A.
- En la lista Propósito, selecciona Proxy administrado entre regiones.
- En el campo Rango de direcciones IP, ingresa
10.129.0.0/23
. - Haz clic en Agregar.
Crea la subred de solo proxy en REGION_B
- Haz clic en Agregar subred.
- Proporciona un Nombre para la subred de solo proxy.
- En la lista Región, selecciona REGION_B.
- En la lista Propósito, selecciona Proxy administrado entre regiones.
- En el campo Rango de direcciones IP, ingresa
10.130.0.0/23
. - Haz clic en Agregar.
gcloud
Crea las subredes de solo proxy con el comando gcloud compute networks subnets create
.
gcloud compute networks subnets create PROXY_SN_A \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=REGION_A \ --network=NETWORK \ --range=PROXY_ONLY_SUBNET_RANGE1
gcloud compute networks subnets create PROXY_SN_B \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=REGION_B \ --network=NETWORK \ --range=PROXY_ONLY_SUBNET_RANGE2
Reemplaza lo siguiente:
PROXY_SN_A
yPROXY_SN_B
: el nombre de las subredes de solo proxyPROXY_ONLY_SUBNET_RANGE1
yPROXY_ONLY_SUBNET_RANGE2
: el rango de direcciones IP para las subredes de solo proxyREGION_A
yREGION_B
: las regiones en las que configuraste el balanceador de cargas.
API
Crea las subredes de solo proxy con el método subnetworks.insert
y reemplaza PROJECT_ID
por el ID del proyecto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks { "name": "PROXY_SN_A", "ipCidrRange": "PROXY_ONLY_SUBNET_RANGE1", "network": "projects/PROJECT_ID/global/networks/NETWORK", "region": "projects/PROJECT_ID/regions/REGION_A", "purpose": "GLOBAL_MANAGED_PROXY", "role": "ACTIVE" }
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks { "name": " PROXY_SN_B", "ipCidrRange": "PROXY_ONLY_SUBNET_RANGE2", "network": "projects/PROJECT_ID/global/networks/NETWORK", "region": "projects/PROJECT_ID/regions/REGION_B", "purpose": "GLOBAL_MANAGED_PROXY", "role": "ACTIVE" }
Crea reglas de firewall
En este ejemplo, se crean las siguientes reglas de firewall para los backends de NEG zonales en Google Cloud:
fw-allow-health-check
: Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de los sistemas de verificación de estado de Google Cloud (130.211.0.0/22
y35.191.0.0/16
). En este ejemplo, se usa la etiqueta de destinoallow-health-check
para identificar los NEGs a los que debe aplicarse.fw-allow-ssh
: una regla de entrada que permita la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de IP de origen más restrictivo para esta regla; por ejemplo, puedes especificar los rangos de IP de los sistemas desde los que planeas iniciar sesiones SSH. En este ejemplo, se usa la etiqueta de destinoallow-ssh
para identificar las instancias de máquina virtual (VM) a las que se debe aplicar.fw-allow-proxy-only-subnet
: Una regla de entrada que permite que las conexiones de la subred de solo proxy lleguen a los backends de NEGs zonales.
Console
En la consola de Google Cloud, ve a la página Políticas de firewall.
Haz clic en Crear regla de firewall para crear la regla que permite el tráfico de los sondeos de verificación de estado:
- Ingresa un Nombre de
fw-allow-health-check
. - En Red, selecciona NETWORK.
- En Destinos, selecciona Etiquetas de destino especificadas.
- Propaga el campo Etiquetas de destino con
allow-health-check
. - Configura Filtro de fuente como Rangos de IPv4.
- Establece Rangos de IPv4 de origen en
130.211.0.0/22
y35.191.0.0/16
. - En Protocolos y puertos, selecciona Puertos y protocolos especificados.
- Selecciona TCP y, luego, ingresa
80
para el número de puerto. - Haz clic en Crear.
- Ingresa un Nombre de
Vuelve a hacer clic en Crear regla de firewall para crear la regla que permita conexiones SSH entrantes:
- Nombre:
fw-allow-ssh
- Red: NETWORK
- Prioridad:
1000
- Dirección del tráfico: entrada
- Acción si hay coincidencia: permitir
- Objetivos: etiquetas de destino especificadas
- Etiquetas de destino:
allow-ssh
- Filtro de fuente: Rangos de IPv4
- Rangos de IPv4 de origen:
0.0.0.0/0
- Protocolos y puertos: Elige Protocolos y puertos especificados.
- Selecciona TCP y, luego, ingresa
22
para el número de puerto. - Haz clic en Crear.
- Nombre:
Haz clic en Crear regla de firewall de nuevo para crear la regla que permite conexiones entrantes desde la subred de solo proxy:
- Nombre:
fw-allow-proxy-only-subnet
- Red: NETWORK
- Prioridad:
1000
- Dirección del tráfico: entrada
- Acción si hay coincidencia: permitir
- Objetivos: etiquetas de destino especificadas
- Etiquetas de destino:
allow-proxy-only-subnet
- Filtro de fuente: Rangos IPv4
- Rangos IPv4 de origen: PROXY_ONLY_SUBNET_RANGE1 y PROXY_ONLY_SUBNET_RANGE2
- Protocolos y puertos: Elige Protocolos y puertos especificados
- Selecciona TCP y, luego, ingresa
80
para el número de puerto. - Haz clic en Crear.
- Nombre:
gcloud
Crea la regla
fw-allow-health-check-and-proxy
para permitir que las verificaciones de estado de Google Cloud lleguen a las instancias de backend en el puerto TCP80
:gcloud compute firewall-rules create fw-allow-health-check \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:80
Crea la regla de firewall
fw-allow-ssh
para permitir la conectividad SSH a las VM con la etiqueta de redallow-ssh
. Cuando omitessource-ranges
, Google Cloud interpreta que la regla significa cualquier fuente.gcloud compute firewall-rules create fw-allow-ssh \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Crea una regla de firewall de permiso de entrada para la subred de solo proxy a fin de permitir que el balanceador de cargas se comunique con instancias de backend en el puerto TCP
80
:gcloud compute firewall-rules create fw-allow-proxy-only-subnet \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-proxy-only-subnet \ --source-ranges=PROXY_ONLY_SUBNET_RANGE1,PROXY_ONLY_SUBNET_RANGE2 \ --rules=tcp:80
Configura el NEG zonal
Para los backends basados en Google Cloud, te recomendamos configurar varios NEG zonales en la misma región en la que configuraste la conectividad híbrida.
Para este ejemplo, configura un NEG zonal (con extremos de tipo GCE_VM_IP_PORT
) en la región REGION_A
. Primero, crea las VMs en la zona ZONE_A
. Luego, crea un NEG zonal en la zona ZONE_A
y, luego, agrega los extremos de red de las VMs al NEG.
Para admitir la alta disponibilidad, configuramos un NEG zonal similar en la región REGION_B
. Si los backends en una región están inactivos, el tráfico se dirige a la otra región.
Crea las VM
Console
En la consola de Google Cloud, ve a la página Instancias de VM.
Repite los pasos 3 a 8 para cada VM y usa las siguientes combinaciones de nombre y zona.
- Nombre de
vm-a1
- Zona: ZONE_A en la región REGION_A
- Subred: SUBNET_A
- Nombre de
vm-b1
- Zona: ZONE_B en la región REGION_B
- Subred: SUBNET_B
- Nombre de
Haz clic en Crear instancia.
Establece el nombre como se indicó en el paso anterior.
En Región, elige como se indicó en el paso anterior.
En Zona, elige como se indicó en el paso anterior.
En la sección Disco de arranque, asegúrate de que Debian GNU/Linux 12 (bookWorm) esté seleccionado como las opciones del disco de arranque. Haz clic en Elegir para cambiar la imagen si es necesario.
En la sección Opciones avanzadas, expande Herramientas de redes y, luego, haz lo siguiente:
- Agrega las siguientes etiquetas de red:
allow-ssh
,allow-health-check
yallow-proxy-only-subnet
. - En la sección Interfaces de red, haz clic en Agregar una interfaz de red, realiza los siguientes cambios y, luego, haz clic en Listo:
- Red: NETWORK
- Subred: como se indicó en el paso anterior.
- IP interna principal: efímera (automática)
- IP externa: efímera
Expande Administración. En el campo Automatización, copia y pega el siguiente contenido de la secuencia de comandos. El contenido de la secuencia de comandos es idéntico para todas las VMs.
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2
- Agrega las siguientes etiquetas de red:
Haz clic en Crear.
gcloud
Para crear las VMs, ejecuta el siguiente comando, con estas combinaciones para el nombre de la VM y su zona. El contenido de la secuencia de comandos es idéntico para ambas VMs.
gcloud compute instances create VM_NAME \ --zone=GCP_NEG_ZONE \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check,allow-proxy-only-subnet \ --subnet=LB_SUBNET_NAME \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'
VM_NAME
devm-a1
- La zona
GCP_NEG_ZONE
comoZONE_A
en la regiónREGION_A
- La subred
LB_SUBNET_NAME
comoSUBNET_A
- La zona
VM_NAME
devm-b1
- Zona
GCP_NEG_ZONE
comoZONE_B
en la regiónREGION_B
- Subred
LB_SUBNET_NAME
comoSUBNET_B
- Zona
Crea el NEG zonal
Console
Para crear un grupo de extremos de red por zonas, sigue estos pasos:
En la consola de Google Cloud, ve a la página Grupos de extremos de red.
Repite los pasos 3 a 8 para cada NEG zonal y usa las siguientes combinaciones de nombre y zona:
- Nombre:
neg-1
- Zona: ZONE_A en la región REGION_A
- Subred: SUBNET_A
- Nombre:
neg-2
- Zona: ZONE_B en la región REGION_B
- Subred: SUBNET_B
- Nombre:
Haz clic en Crear un grupo de extremos de red.
Establece el nombre como se indicó en el paso anterior.
Selecciona el Tipo de grupo de extremos de red: Grupo de extremos de red (zonal).
Selecciona la Red: NETWORK
Selecciona la Subred como se indicó en el paso anterior.
Selecciona la Zona como se indicó en el paso anterior.
Ingresa el Puerto predeterminado:
80
.Haz clic en Crear.
Agrega extremos al NEG zonal.
En la consola de Google Cloud, ve a la página Grupos de extremos de red.
Haz clic en el Nombre del grupo de extremos de red que se creó en el paso anterior. Verás la página Detalles del grupo de extremos de red.
En la sección Extremos de red de este grupo, haz clic en Agregar extremo de red. Verás la página Agregar extremo de red.
Selecciona una instancia de VM para agregar sus direcciones IP internas como extremos de red. En la sección Interfaz de red, se muestra el nombre, la zona y la subred de la VM.
Ingresa la dirección IP del extremo de red nuevo.
Selecciona el tipo de puerto.
- Si seleccionas Predeterminado, el extremo usará el puerto predeterminado
80
para todos los extremos del grupo de extremos de red. Esto es suficiente para nuestro ejemplo, ya que el servidor Apache entrega solicitudes en el puerto80
. - Si seleccionas Personalizado, deberás ingresar el número de puerto para el extremo que se usará.
- Si seleccionas Predeterminado, el extremo usará el puerto predeterminado
Para agregar más extremos, haz clic en Agregar extremo de red y repite los pasos anteriores.
Después de agregar todos los extremos, haz clic en Crear.
gcloud
Crea NEGs zonales (con extremos
GCE_VM_IP_PORT
) mediante las combinaciones de nombre, zona y subred. Usa el comandogcloud compute network-endpoint-groups create
.gcloud compute network-endpoint-groups create GCP_NEG_NAME \ --network-endpoint-type=GCE_VM_IP_PORT \ --zone=GCP_NEG_ZONE \ --network=NETWORK \ --subnet=LB_SUBNET_NAME
- Nombre:
neg-1
- Zona
GCP_NEG_ZONE
:ZONE_A
en la regiónREGION_A
- Subred
LB_SUBNET_NAME
:SUBNET_A
- Zona
- Nombre:
neg-2
- Zona
GCP_NEG_ZONE
:ZONE_B
en la regiónREGION_B
- Subred
LB_SUBNET_NAME
:SUBNET_B
- Zona
Puedes especificar un puerto con la opción
--default-port
mientras creas el NEG o especificar un número de puerto para cada extremo, como se muestra en el siguiente paso.- Nombre:
Agrega extremos a
neg1
yneg2
.gcloud compute network-endpoint-groups update neg1 \ --zone=ZONE_A \ --add-endpoint='instance=vm-a1,port=80'
gcloud compute network-endpoint-groups update neg2 \ --zone=ZONE_B \ --add-endpoint='instance=vm-b1,port=80'
Configura el NEG de conectividad híbrida
Cuando crees el NEG, usa una zona que minimice la distancia geográfica entre Google Cloud y tu entorno local o de otra nube. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort, Alemania, puedes especificar la zona europe-west3-a
de Google Cloud cuando crees el NEG.
Si usas Cloud Interconnect, la zona que se usa para crear el NEG se encuentra en la misma región en la que se configuró el adjunto de Cloud Interconnect.
Los NEGs híbridos solo admiten las verificaciones de estado de Envoy distribuidas.
Console
Para crear un grupo de extremos de red de conectividad híbrida, haz lo siguiente:
En la consola de Google Cloud, ve a la página Grupos de extremos de red.
Haz clic en Crear un grupo de extremos de red.
Repite los pasos del 4 al 9 para cada NEG híbrida con las siguientes combinaciones de nombre y zona.
- Nombre ON_PREM_NEG_NAME:
hybrid-1
- Zona: ON_PREM_NEG_ZONE1
- Subred: SUBNET_A
- Nombre ON_PREM_NEG_NAME:
hybrid-2
- Zona: ON_PREM_NEG_ZONE2
- Subred: SUBNET_B
- Nombre ON_PREM_NEG_NAME:
Establece el nombre como se indicó en el paso anterior.
Selecciona el Tipo de grupo de extremos de red: Grupo de extremos de red de conectividad híbrida (zonal).
Selecciona la Red: NETWORK
En Subred, elige como se indicó en el paso anterior.
En Zona, elige como se indicó en el paso anterior.
Ingresa el Puerto predeterminado.
Haz clic en Crear.
Agrega extremos al NEG de conectividad híbrida:
En la consola de Google Cloud, ve a la página Grupos de extremos de red.
Haz clic en el Nombre del grupo de extremos de red que se creó en el paso anterior. Verás la página Detalles del grupo de extremos de red.
En la sección Extremos de red de este grupo, haz clic en Agregar extremo de red. Verás la página Agregar extremo de red.
Ingresa la dirección IP del extremo de red nuevo.
Selecciona el tipo de puerto.
- Si seleccionas Predeterminado, el extremo usará el puerto predeterminado para todos los extremos del grupo de extremos de red.
- Si seleccionas Personalizado, puedes ingresar un Número de puerto diferente para que lo use el extremo.
Para agregar más extremos, haz clic en Agregar extremo de red y repite los pasos anteriores.
Después de agregar todos los extremos que no son de Google Cloud, haz clic en Crear.
gcloud
Crea un NEG de conectividad híbrida que use las siguientes combinaciones de nombres. Usa el comando
gcloud compute network-endpoint-groups create
.gcloud compute network-endpoint-groups create ON_PREM_NEG_NAME \ --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \ --zone=ON_PREM_NEG_ZONE \ --network=NETWORK
- Nombre
ON_PREM_NEG_NAME
:hybrid-1
- Zona
ON_PREM_NEG_ZONE
:ON_PREM_NEG_ZONE1
- Zona
- Nombre
ON_PREM_NEG_NAME
:hybrid-2
- Zona
GCP_NEG_ZONE
:ON_PREM_NEG_ZONE2
- Zona
- Nombre
Agrega el extremo de la VM de backend local a
ON_PREM_NEG_NAME
:gcloud compute network-endpoint-groups update ON_PREM_NEG_NAME \ --zone=ON_PREM_NEG_ZONE \ --add-endpoint="ip=ON_PREM_IP_ADDRESS_1,port=PORT_1" \ --add-endpoint="ip=ON_PREM_IP_ADDRESS_2,port=PORT_2"
Puedes usar este comando para agregar los extremos de red que configuraste antes de forma local o en tu entorno de nube.
Repite --add-endpoint
tantas veces como sea necesario.
Configura el balanceador de cargas
Console
gcloud
Define la verificación de estado de HTTP con el comando
gcloud compute health-checks create http
.gcloud compute health-checks create http gil7-basic-check \ --use-serving-port \ --global
Crea el servicio de backend y habilita el registro con el comando
gcloud compute backend-services create
.gcloud compute backend-services create BACKEND_SERVICE \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --enable-logging \ --logging-sample-rate=1.0 \ --health-checks=gil7-basic-check \ --global-health-checks \ --global
Agrega backends al servicio de backend con el comando
gcloud compute backend-services add-backend
.gcloud compute backend-services add-backend BACKEND_SERVICE \ --global \ --balancing-mode=RATE \ --max-rate-per-endpoint=MAX_REQUEST_RATE_PER_ENDPOINT \ --network-endpoint-group=neg1 \ --network-endpoint-group-zone=ZONE_A \ --network-endpoint-group=neg2 \ --network-endpoint-group-zone=ZONE_B
Si deseas obtener detalles sobre la configuración del modo de balanceo, consulta la documentación de la CLI de gcloud para la marca
--max-rate-per-endpoint
.Agrega los NEGs híbridos como un backend al servicio de backend:
gcloud compute backend-services add-backend BACKEND_SERVICE \ --global \ --balancing-mode=RATE \ --max-rate-per-endpoint=MAX_REQUEST_RATE_PER_ENDPOINT \ --network-endpoint-group=hybrid1 \ --network-endpoint-group-zone=ON_PREM_NEG_ZONE1 \ --network-endpoint-group=hybrid2 \ --network-endpoint-group-zone=ON_PREM_NEG_ZONE2 \
Si deseas obtener detalles sobre la configuración del modo de balanceo, consulta la documentación de la CLI de gcloud para el parámetro
--max-rate-per-endpoint
.Crea el mapa de URL con el comando
gcloud compute url-maps create
.gcloud compute url-maps create gil7-map \ --default-service=BACKEND_SERVICE \ --global
Crea el proxy de destino.
Para HTTP:
Crea el proxy de destino con el comando
gcloud compute target-http-proxies create
.gcloud compute target-http-proxies create gil7-http-proxy \ --url-map=gil7-map \ --global
Para HTTPS:
Para crear un certificado administrado por Google, consulta la siguiente documentación:
- Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
- Crea un certificado administrado por Google con autorización de DNS.
Después de crear el certificado administrado por Google, adjúntalo al proxy de destino. Los mapas de certificados no son compatibles con los balanceadores de cargas de aplicaciones internos entre regiones.
Para crear un certificado autoadministrado, consulta la siguiente documentación:
Asigna tus rutas de archivos a nombres de variables.
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
export LB_PRIVATE_KEY=PATH_TO_PEM_LB_PRIVATE_FILE
Crea un certificado SSL para todas las regiones con el comando
gcloud certificate-manager certificates create
.gcloud certificate-manager certificates create gilb-certificate \ --private-key-file=$LB_CERT \ --certificate-file=$LB_PRIVATE_KEY \ --scope=all-regions
Usa el certificado SSL regional para crear un proxy de destino con el comando
gcloud compute target-https-proxies create
.gcloud compute target-https-proxies create gil7-https-proxy \ --url-map=gil7-map \ --certificate-manager-certificates=gilb-certificate \ --global
Crea dos reglas de reenvío, una con una VIP
IP_ADDRESS1
en la regiónREGION_A
y otra con una VIPIP_ADDRESS2
en la regiónREGION_B
. Para la dirección IP de la regla de reenvío, usa el rango de direcciones IPLB_SUBNET_RANGE1
oLB_SUBNET_RANGE2
. Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.Para redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que esta es la subred de VM, no la subred de proxy.
Para HTTP:
Usa el comando
gcloud compute forwarding-rules create
con las marcas correctas.gcloud compute forwarding-rules create FWRULE_A \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_A \ --subnet-region=REGION_A \ --address=IP_ADDRESS1 \ --ports=80 \ --target-http-proxy=gil7-http-proxy \ --global
gcloud compute forwarding-rules create FWRULE_B \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_B \ --subnet-region=REGION_B \ --address=IP_ADDRESS2 \ --ports=80 \ --target-http-proxy=gil7-http-proxy \ --global
Para HTTPS:
Crea la regla de reenvío con el comando
gcloud compute forwarding-rules create
con las marcas correctas.gcloud compute forwarding-rules create FWRULE_A \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_A \ --subnet-region=REGION_A \ --address=IP_ADDRESS1 \ --ports=443 \ --target-https-proxy=gil7-https-proxy \ --global
gcloud compute forwarding-rules create FWRULE_B \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_B \ --subnet-region=REGION_B \ --address=IP_ADDRESS2 \ --ports=443 \ --target-https-proxy=gil7-https-proxy \ --global
Conecta tu dominio al balanceador de cargas
Después de crear el balanceador de cargas, toma nota de la dirección IP asociada con este: por ejemplo, IP_ADDRESS1
y IP_ADDRESS2
.
Para apuntar tu dominio al balanceador de cargas, crea un registro A
con Cloud DNS o el servicio de registro de dominios. Si agregaste varios dominios a tu certificado SSL, debes agregar un registro A
para cada uno, que apunte a la dirección IP del balanceador de cargas.
Prueba el balanceador de cargas
Crea una instancia de VM para probar la conectividad
Crea una VM de cliente:
gcloud compute instances create l7-ilb-client-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=NETWORK \ --subnet=SUBNET_A \ --zone=ZONE_A \ --tags=allow-ssh
gcloud compute instances create l7-ilb-client-b \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=NETWORK \ --subnet=SUBNET_B \ --zone=ZONE_B \ --tags=allow-ssh
Usa SSH para conectarte a cada instancia de cliente.
gcloud compute ssh l7-ilb-client-a \ --zone=ZONE_A
gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
Verifica que la 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 IP_ADDRESS1
curl IP_ADDRESS2
Para la prueba de HTTPS, reemplaza
curl
por lo siguiente:curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS1:443
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS2:443
La marca
-k
hace que curl omita la validación del certificado.Opcional: Usa el registro DNS configurado para resolver la dirección IP más cercana a la VM del cliente. Por ejemplo, DNS_ENTRY puede ser
service.example.com
.curl DNS_ENTRY
Ejecuta 100 solicitudes
Ejecuta 100 solicitudes curl y confirma que las respuestas tienen balanceo de cargas.
Para HTTP:
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:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent IP_ADDRESS1)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS1: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent IP_ADDRESS2)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS2: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
Para HTTPS:
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:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS1:443)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS1: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS2:443)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS2: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
Prueba la conmutación por error
Verifica la conmutación por error a los backends en la región
REGION_A
cuando los backends enREGION_B
estén en mal estado o sean inaccesibles. Para simular esto, quitamos todos los backends deREGION_B
:gcloud compute backend-services remove-backend BACKEND_SERVICE \ --balancing-mode=RATE \ --network-endpoint-group=neg2 \ --network-endpoint-group-zone=ZONE_B
Usa SSH para conectarte a la VM del cliente en
REGION_B
.gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
Envía solicitudes a la dirección IP del balanceo de cargas en la región
REGION_B
. El resultado es similar al siguiente:{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS2:443)" done echo "***" echo "*** Results of load-balancing to IP_ADDRESS2: " 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.
Configura políticas de enrutamiento de DNS
Si tus clientes están en varias regiones, es posible que desees hacer que el balanceador de cargas de aplicaciones interno entre regiones sea accesible mediante VIPs en estas regiones. Esta configuración de varias regiones minimiza la latencia y los costos de tránsito de red. Además, te permite configurar una solución de balanceo de cargas global basada en DNS que proporcione resiliencia contra interrupciones regionales. Para obtener más información, consulta Administra las políticas de enrutamiento de DNS y las verificaciones de estado.
gcloud
Para crear una entrada de DNS con un TTL de 30 segundos, usa el comando gcloud dns record-sets create
.
gcloud dns record-sets create DNS_ENTRY --ttl="30" \ --type="A" --zone="service-zone" \ --routing-policy-type="GEO" \ --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \ --enable-health-checking
Reemplaza lo siguiente:
DNS_ENTRY
: el nombre de dominio o DNS del conjunto de registros.Por ejemplo,
service.example.com
REGION_A
yREGION_B
: las regiones en las que configuraste el balanceador de cargas.
API
Para crear el registro DNS, realiza una solicitud POST
al método ResourceRecordSets.create
.
Reemplaza PROJECT_ID con el ID del proyecto.
POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets { "name": "DNS_ENTRY", "type": "A", "ttl": 30, "routingPolicy": { "geo": { "items": [ { "location": "REGION_A", "healthCheckedTargets": { "internalLoadBalancers": [ { "loadBalancerType": "globalL7ilb", "ipAddress": "IP_ADDRESS", "port": "80", "ipProtocol": "tcp", "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network", "project": "PROJECT_ID" } ] } }, { "location": "REGION_B", "healthCheckedTargets": { "internalLoadBalancers": [ { "loadBalancerType": "globalL7ilb", "ipAddress": "IP_ADDRESS_B", "port": "80", "ipProtocol": "tcp", "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network", "project": "PROJECT_ID" } ] } } ] } } }
Actualiza el tiempo de espera de keepalive del HTTP del cliente
El balanceador de cargas creado en los pasos anteriores se configuró con un valor predeterminado para el tiempo de espera de keepalive de HTTP del cliente.Para actualizar el tiempo de espera de keepalive del cliente HTTP, sigue las siguientes instrucciones.
Console
En la consola de Google Cloud, ve a la página Balanceo de cargas.
- Haz clic en el nombre del balanceador de cargas que deseas modificar.
- Haz clic en Editar.
- Haz clic en Configuración de frontend.
- Expande Funciones avanzadas. Para el tiempo de espera de keepalive de HTTP, ingresa un valor de tiempo de espera.
- Haz clic en Actualizar.
- Para revisar los cambios, haz clic en Revisar y finalizar y, luego, haz clic en Actualizar.
gcloud
Para un balanceador de cargas de HTTP, actualiza el proxy HTTP de destino con el comandogcloud compute target-http-proxies update
:
gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
Para un balanceador de cargas de HTTPS, actualiza el proxy HTTPS de destino con el comandogcloud compute target-https-proxies update
:
gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
Reemplaza lo siguiente:
TARGET_HTTP_PROXY_NAME
: el nombre del proxy HTTP de destino.TARGET_HTTPS_PROXY_NAME
: el nombre del proxy HTTPS de destino.HTTP_KEEP_ALIVE_TIMEOUT_SEC
: El valor de tiempo de espera de keepalive de HTTP de 5 a 600 segundos.
Habilitar la detección de valores atípicos
Puedes habilitar la detección de valores atípicos en los servicios de backend globales para identificar los NEGs sin servidores y reducir la cantidad de solicitudes enviadas a los NEGs sin servidores en mal estado.
La detección de valores atípicos se habilita en el servicio de backend con uno de los siguientes métodos:
- El método
consecutiveErrors
(outlierDetection.consecutiveErrors
), en el que un código de estado HTTP de la serie5xx
califica como un error. - El método
consecutiveGatewayFailure
(outlierDetection.consecutiveGatewayFailure
), en el que solo los códigos de estado HTTP502
,503
y504
califican como un error.
Sigue los pasos a continuación para habilitar la detección de valores atípicos para un servicio de backend existente. Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, algunas solicitudes se pueden enviar al servicio deteriorado y mostrar un código de estado 5xx
a los clientes. Para reducir aún más la tasa de error, puedes configurar valores más agresivos para los parámetros de detección de valores atípicos. Para obtener más información, consulta el campo outlierDetection
.
Console
En la consola de Google Cloud, ve a la página Balanceo de cargas.
Haz clic en el nombre del balanceador de cargas cuyo servicio de backend quieres editar.
En la página Detalles del balanceador de cargas, haz clic en
Editar.En la página Editar balanceador de cargas de aplicaciones interno entre regiones, haz clic en Configuración de backend.
En la página de Configuración de backend, haz clic en
Editar en el servicio de backend que deseas modificar.Desplázate hacia abajo y expande la sección Configuración avanzada.
En la sección Detección de valores atípicos, selecciona la casilla de verificación Habilitar.
Haz clic en
Editar para configurar la detección de valores atípicos.Verifica que las siguientes opciones estén configuradas con estos valores:
Propiedad Valor Errores consecutivos 5 Interval 1000 Tiempo de expulsión base 30,000 Porcentaje de expulsión máximo 50 Aplicación de errores consecutivos 100 En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP
5xx
consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.Haz clic en Guardar.
Para actualizar el servicio de backend, haz clic en Actualizar.
Para actualizar el balanceador de cargas, en la página Edita el balanceador de cargas de aplicaciones interno entre regiones, haz clic en Actualizar.
gcloud
Exporta el servicio de backend a un archivo YAML.
gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME.yaml --global
Reemplaza
BACKEND_SERVICE_NAME
por el nombre del servicio de backend.Edita la configuración YAML del servicio de backend para agregar los campos para la detección de valores atípicos, como se destaca en la siguiente configuración de YAML, en la sección
outlierDetection
:En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP
5xx
consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.name: BACKEND_SERVICE_NAME backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2 outlierDetection: baseEjectionTime: nanos: 0 seconds: 30 consecutiveErrors: 5 enforcingConsecutiveErrors: 100 interval: nanos: 0 seconds: 1 maxEjectionPercent: 50 port: 80 selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME sessionAffinity: NONE timeoutSec: 30 ...
Reemplaza lo siguiente:
BACKEND_SERVICE_NAME
: es el nombre del servicio de backend.PROJECT_ID
: Es el ID de tu proyecto.REGION_A
yREGION_B
: las regiones en las que se configuró el balanceador de cargas.SERVERLESS_NEG_NAME
: Es el nombre del primer NEG sin servidores.SERVERLESS_NEG_NAME_2
: es el nombre del segundo NEG sin servidores.
Para actualizar el servicio de backend, importa la configuración más reciente.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME.yaml --global
La detección de valores atípicos ahora está habilitada en el servicio de backend.
¿Qué sigue?
- Convierte el balanceador de cargas de aplicaciones a IPv6
- Descripción general del balanceador de cargas de aplicaciones interno
- Subredes de solo proxy para balanceadores de cargas basados en Envoy
- Administrar certificados
- Limpia una configuración de balanceo de cargas