Esta página se ha traducido con Cloud Translation API.

Configurar un balanceador de carga de aplicaciones interno entre regiones con conectividad híbrida

En esta página se explica cómo desplegar un balanceador de carga de aplicación interno entre regiones para balancear la carga del tráfico a los endpoints de red que están en las instalaciones locales o en otras nubes públicas y a los que se puede acceder mediante conectividad híbrida.

Si aún no lo has hecho, consulta la descripción general de los NEG de conectividad híbrida para conocer los requisitos de red necesarios para configurar el balanceo de carga híbrido.

Descripción general de la configuración

En el ejemplo se configura un balanceador de carga de aplicaciones interno entre regiones para back-ends de NEG con conectividad híbrida y de zonas mixta, como se muestra en la siguiente figura:

Ejemplo de balanceador de carga de aplicaciones interno entre regiones para back-ends de conectividad híbrida y de zona mixta. — Ejemplo de balanceador de carga de aplicaciones interno entre regiones para backends de NEG de conectividad híbrida y por zonas mixta (haz clic para ampliar).

Debes configurar la conectividad híbrida antes de configurar una implementación de equilibrio de carga híbrida. En función del producto de conectividad híbrida que elijas, usa Cloud VPN o Cloud Interconnect (Dedicated o Partner).

Configurar un recurso de certificado SSL

Crea un recurso de certificado SSL de Certificate Manager tal como se describe en los siguientes artículos:

Te recomendamos que uses un certificado gestionado por Google.

Permisos

Para configurar el balanceo de carga híbrido, debes tener los siguientes permisos:

Activado Google Cloud
- Permisos para establecer la conectividad híbrida entre Google Cloud y tu entorno on-premise u otros entornos de nube. Para ver la lista de permisos necesarios, consulta la documentación del producto de conectividad de red correspondiente.
- Permisos para crear un NEG de conectividad híbrida y el balanceador de carga. El rol Administrador de balanceadores de carga de Compute (roles/compute.loadBalancerAdmin) contiene los permisos necesarios para realizar las tareas descritas en esta guía.
En tu entorno local u otro entorno que no sea deGoogle Cloud cloud
- Permisos para configurar endpoints de red que permitan que los servicios de tu entorno local u otros entornos de nube sean accesibles desdeGoogle Cloud mediante una combinación de IP:Port. Para obtener más información, ponte en contacto con el administrador de red de tu entorno.
- Permisos para crear reglas de cortafuegos en tu entorno local u otros entornos de nube para permitir que las sondas de comprobación del estado de Google lleguen a los endpoints.

Además, para completar las instrucciones de esta página, debe crear un NEG de conectividad híbrida, un balanceador de carga y NEGs zonales (y sus endpoints) para que actúen como back-ends basados en Google Clouddel balanceador de carga.

Debes tener el rol de propietario o editor del proyecto, o bien los siguientes roles de gestión de identidades y accesos de Compute Engine.

Tarea	Rol necesario
Crear redes, subredes y componentes de balanceador de carga	Administrador de red de Compute (`roles/compute.networkAdmin`)
Añadir y eliminar reglas de cortafuegos	Administrador de seguridad de Compute (`roles/compute.securityAdmin`)
Crear instancias	Administrador de instancias de Compute (`roles/compute.instanceAdmin`)

Establecer una conectividad híbrida

Tu entorno Google Cloud y el entorno on-premise u otros entornos de nube deben conectarse mediante conectividad híbrida usando vinculaciones de VLAN de Cloud Interconnect o túneles de Cloud VPN con Cloud Router o VMs de dispositivo router. Te recomendamos que uses una conexión de alta disponibilidad.

Un Cloud Router habilitado con enrutamiento dinámico global obtiene información sobre el endpoint específico mediante el protocolo de pasarela fronteriza (BGP) y lo programa en tu Google Cloud red de VPC. No se admite el enrutamiento dinámico regional. Tampoco se admiten las rutas estáticas.

Puedes usar la misma red de VPC o una diferente en el mismo proyecto para configurar tanto la red híbrida (Cloud Interconnect, Cloud VPN o una VM de dispositivo Router) como el balanceador de carga. Ten en cuenta lo siguiente:

Si usas redes de VPC diferentes, las dos redes deben estar conectadas mediante el emparejamiento entre redes de VPC o deben ser radios de VPC en el mismo hub de Network Connectivity Center.
Si usas la misma red de VPC, asegúrate de que los intervalos CIDR de las subredes de tu red de VPC no entren en conflicto con los intervalos CIDR remotos. Cuando las direcciones IP se superponen, se priorizan las rutas de subred sobre la conectividad remota.

Para obtener instrucciones, consulta la siguiente documentación:

Configurar un entorno externo Google Cloud

Sigue estos pasos para configurar tu entorno local u otro entorno de nube para el balanceo de carga híbrido:

Configura los endpoints de red para exponer los servicios locales aGoogle Cloud (IP:Port).
Configura reglas de cortafuegos en tu entorno local u otro entorno de nube.
Configura Cloud Router para que anuncie determinadas rutas necesarias a tu entorno privado.

Configurar endpoints de red

Después de configurar la conectividad híbrida, configura uno o varios endpoints de red en tu entorno local u otros entornos de nube a los que se pueda acceder a través de Cloud Interconnect, Cloud VPN o el dispositivo Router mediante una combinación de IP:port. Esta IP:portcombinación se configura como uno o varios endpoints para el NEG de conectividad híbrida que se crea Google Cloud más adelante en este proceso.

Si hay varias rutas al endpoint IP, el enrutamiento sigue el comportamiento descrito en la descripción general de Cloud Router.

Configurar reglas de cortafuegos

Debes crear las siguientes reglas de cortafuegos en tu entorno local u otro entorno de nube:

Crea una regla de cortafuegos de entrada en un entorno local o en otra nube para permitir que el tráfico de la subred de solo proxy de la región llegue a los endpoints.
No es necesario permitir el tráfico de los intervalos de sondeo de comprobación del estado de Google para los NEGs híbridos. Sin embargo, si utilizas una combinación de NEGs híbridos y zonales en un mismo servicio de backend, debes permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEGs zonales.

Anunciar rutas

Configura Cloud Router para anunciar los siguientes intervalos de IP personalizados a tu entorno local u otro entorno de nube:

Intervalo de la subred de solo proxy de la región.

Configurar el Google Cloud entorno

En los pasos siguientes, 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 utilizadas (denominadas REGION_A y REGION_B en este procedimiento) sean las mismas que las que se usaron para crear el túnel de Cloud VPN o las vinculaciones de VLAN de Cloud Interconnect.

También puede configurar políticas de enrutamiento de DNS de tipo GEO para enrutar el tráfico de los clientes a la IP virtual del balanceador de carga de la región más cercana al cliente durante las interrupciones regionales.

Configurar las subredes de backend

Usa esta subred para crear los back-ends de NEG zonales del balanceador de carga:

Consola

En la Google Cloud consola, ve a la página Redes de VPC.

Ir a redes de VPC
Ve a la red que se usó para configurar la conectividad híbrida entre los entornos.
En la sección Subredes:
- Elige Personalizado en Modo de creación de subred.
- En la sección Nueva subred, introduce la siguiente información:
  - Asigna un nombre a la subred.
  - Selecciona una región: REGION_A
  - Introduce un intervalo de direcciones IP.
- Haz clic en Listo.
Haz clic en Crear.
Para añadir más subredes en otras regiones, haz clic en Añadir subred y repite los pasos anteriores para REGION_B.

gcloud

Crea subredes en la red que se ha usado 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. Sustituye PROJECT_ID por el ID de tu 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. Sustituye PROJECT_ID por el ID de tu 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",
}

Haz los cambios siguientes:

SUBNET_A y SUBNET_B: el nombre de las subredes
LB_SUBNET_RANGE1 y LB_SUBNET_RANGE2: el intervalo de direcciones IP de las subredes
REGION_A y REGION_B: las regiones en las que has configurado el balanceador de carga

Configurar la subred de solo proxy

Una subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Los proxies terminan las conexiones del cliente y crean nuevas conexiones con los back-ends.

Todos los balanceadores de carga regionales basados en Envoy de la misma región de la red de VPC usan esta subred de solo proxy. Solo puede haber una subred solo proxy activa para un propósito determinado por región y por red.

Consola

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

Si quieres crear la subred de solo proxy ahora, sigue estos pasos:

En la Google Cloud consola, ve a la página Redes de VPC.

Ir a redes de VPC
Haga clic en el nombre de la red VPC.
En la pestaña Subredes, haz clic en Añadir subred.
Asigna un nombre a la subred de solo proxy.
En la lista Región, selecciona REGION_A.
En la lista Propósito, selecciona Proxy gestionado entre regiones.
En el campo Intervalo de direcciones IP, introduce 10.129.0.0/23.
Haz clic en Añadir.

Crea la subred de solo proxy en REGION_B

Haz clic en Añadir subred.
Asigna un nombre a la subred de solo proxy.
En la lista Región, selecciona REGION_B.
En la lista Propósito, selecciona Proxy gestionado entre regiones.
En el campo Intervalo de direcciones IP, introduce 10.130.0.0/23.
Haz clic en Añadir.

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

Haz los cambios siguientes:

PROXY_SN_A y PROXY_SN_B: el nombre de las subredes de solo proxy
PROXY_ONLY_SUBNET_RANGE1 y PROXY_ONLY_SUBNET_RANGE2: el intervalo de direcciones IP de las subredes de solo proxy
REGION_A y REGION_B: las regiones en las que has configurado el balanceador de carga

API

Crea las subredes de solo proxy con el método subnetworks.insert. Sustituye PROJECT_ID por el ID de tu 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"
    }

Crear reglas de cortafuegos

En este ejemplo, se crean las siguientes reglas de cortafuegos para los back-ends de NEG zonal en Google Cloud:

fw-allow-health-check: una regla de entrada aplicable a las instancias que se están balanceando, que permite el tráfico de los sistemas de comprobación del estadoGoogle Cloud (130.211.0.0/22 y 35.191.0.0/16). En este ejemplo, se usa la etiqueta de destino allow-health-check para identificar los NEGs zonales a los que se debe aplicar.
fw-allow-ssh: una regla de entrada que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puede elegir un intervalo de IPs de origen más restrictivo para esta regla. Por ejemplo, puede especificar solo los intervalos de IPs de los sistemas desde los que iniciará sesiones SSH. En este ejemplo se usa la etiqueta de destino allow-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 NEG zonales.

Consola

En la Google Cloud consola, ve a la página Políticas de cortafuegos.

Ir a Políticas de cortafuegos
Haz clic en Crear regla de cortafuegos para crear la regla que permita el tráfico de las sondas de comprobación del estado:
1. Asigne un Nombre de fw-allow-health-check.
2. En Red, selecciona NETWORK.
3. En Destinos, seleccione Etiquetas de destino especificadas.
4. Rellene el campo Etiquetas de destino con allow-health-check.
5. En Filtro de origen, elija Intervalos de IPv4.
6. Asigna los valores 130.211.0.0/22 y 35.191.0.0/16 a Intervalos de IPv4 de origen.
7. En Protocolos y puertos, selecciona Protocolos y puertos especificados.
8. Selecciona TCP y, a continuación, introduce 80 como número de puerto.
9. Haz clic en Crear.
Vuelve a hacer clic en Crear regla de cortafuegos para crear la regla que permita las conexiones SSH entrantes:
1. Nombre: fw-allow-ssh
2. Red: NETWORK
3. Prioridad: 1000
4. Dirección del tráfico: entrada
5. Acción tras coincidencia: permitir
6. Destinos: etiquetas de destino especificadas
7. Etiquetas de destino: allow-ssh
8. Filtro de origen: Intervalos de IPv4
9. Intervalos de IPv4 de origen: 0.0.0.0/0
10. Protocolos y puertos: elige Protocolos y puertos especificados.
11. Selecciona TCP y, a continuación, introduce 22 como número de puerto.
12. Haz clic en Crear.
Vuelve a hacer clic en Crear regla de cortafuegos para crear la regla que permita las conexiones entrantes de la subred de solo proxy:
1. Nombre: fw-allow-proxy-only-subnet
2. Red: NETWORK
3. Prioridad: 1000
4. Dirección del tráfico: entrada
5. Acción tras coincidencia: permitir
6. Destinos: etiquetas de destino especificadas
7. Etiquetas de destino: allow-proxy-only-subnet
8. Filtro de origen: Intervalos de IPv4
9. Intervalos de IPv4 de origen: PROXY_ONLY_SUBNET_RANGE1 y PROXY_ONLY_SUBNET_RANGE2
10. Protocolos y puertos: elige Protocolos y puertos especificados.
11. Selecciona TCP y, a continuación, introduce 80 como número de puerto.
12. Haz clic en Crear.

gcloud

Crea la regla fw-allow-health-check-and-proxy para permitir que las comprobaciones del estado lleguen a las instancias de backend en el puerto TCP 80: Google Cloud

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 cortafuegos fw-allow-ssh para permitir la conectividad SSH a las VMs con la etiqueta de red allow-ssh. Si omite source-ranges, Google Cloud interpreta que la regla se aplica a 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 cortafuegos de entrada para la subred de solo proxy que permita que el balanceador de carga se comunique con las 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

Configurar el NEG de zona

En el caso de los back-ends basados en Google Cloud, le recomendamos que configure varios NEG zonales en la misma región en la que haya configurado la conectividad híbrida.

En este ejemplo, configura un NEG por zonas (con endpoints de tipo GCE_VM_IP_PORT) en la región REGION_A. Primero, crea las VMs en la zona ZONE_A. A continuación, crea un NEG por zonas en la zona ZONE_A y añade los endpoints de red de las VMs al NEG. Para admitir la alta disponibilidad, configura un NEG por zona similar en la región REGION_B. Si los backends de una región no funcionan, el tráfico se redirige a la otra región.

Crear VMs

Consola

En la consola de Google Cloud , ve a la página Instancias de VM.

Ir a instancias de VM
Repite los pasos del 3 al 8 para cada VM, usando 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
Haz clic en Crear instancia.
Asigna el nombre tal como se indica en el paso anterior.
En Región, elige la opción que se indica en el paso anterior.
En Zona, elige la opción que se indica en el paso anterior.
En la sección Disco de arranque, asegúrate de que la opción Debian GNU/Linux 12 (bookworm) esté seleccionada para el disco de arranque. Haz clic en Elegir para cambiar la imagen si es necesario.
En la sección Opciones avanzadas, despliega Redes y, a continuación, haz lo siguiente:
- Añade las siguientes etiquetas de red: allow-ssh, allow-health-check y allow-proxy-only-subnet.
- En la sección Interfaces de red, haz clic en Añadir una interfaz de red haz los siguientes cambios y, a continuación, haz clic en Hecho:
  - Red: NETWORK
  - Subred: como se indica en el paso anterior.
  - IP interna principal: efímera (automática)
  - IP externa: efímera
- Despliega Gestió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 en 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
```
Haz clic en Crear.

gcloud

Crea las VMs ejecutando el siguiente comando y usando estas combinaciones para el nombre de la VM y su zona. El contenido de la secuencia de comandos es idéntico en ambas máquinas virtuales.

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 de vm-a1
- La zona GCP_NEG_ZONE como ZONE_A en la región REGION_A
- La subred LB_SUBNET_NAME como SUBNET_A
VM_NAME de vm-b1
- Zona GCP_NEG_ZONE como ZONE_B en la región REGION_B
- Subred LB_SUBNET_NAME como SUBNET_B

Crear el NEG de zona

Consola

Para crear un grupo de endpoints de red de zona, sigue estos pasos:

En la Google Cloud consola, ve a la página Grupos de puntos finales de red.

Ve a Grupos de puntos finales de red.
Repite los pasos del 3 al 8 para cada NEG zonal, con 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
Haz clic en Crear grupo de endpoints de red.
Asigna el nombre tal como se indica en el paso anterior.
Selecciona el Tipo de grupo de puntos finales de red: Grupo de puntos finales de red (por zonas).
Selecciona Red: NETWORK
Seleccione la Subred, tal como se indica en el paso anterior.
Selecciona la zona como se indica en el paso anterior.
Introduce el puerto predeterminado: 80.
Haz clic en Crear.

Añade los endpoints al NEG de zona:

En la Google Cloud consola, ve a la página Grupos de puntos finales de red.

Ve a Grupos de endpoints de red
Haga clic en el nombre del grupo de endpoints de red creado en el paso anterior. Verás la página Detalles del grupo de puntos finales de red.
En la sección Puntos finales de red de este grupo, haz clic en Añadir punto final de red. Verás la página Añadir punto final de red.
Selecciona una instancia de VM para añadir sus direcciones IP internas como endpoints de red. En la sección Interfaz de red, se muestra el nombre, la zona y la subred de la máquina virtual.
Introduce la dirección IP del nuevo endpoint de red.
Seleccione el Tipo de puerto.
1. Si selecciona Predeterminado, el endpoint usará el puerto predeterminado 80 para todos los endpoints del grupo de endpoints de red. Esto es suficiente para nuestro ejemplo, ya que el servidor Apache sirve solicitudes en el puerto 80.
2. Si seleccionas Personalizado, introduce el Número de puerto del endpoint que quieras usar.
Para añadir más endpoints, haz clic en Añadir endpoint de red y repite los pasos anteriores.
Una vez que hayas añadido todos los endpoints, haz clic en Crear.

gcloud

Crea NEGs zonales (con GCE_VM_IP_PORT endpoints) con las combinaciones de nombre, zona y subred. Usa el comando gcloud 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ón REGION_A
  - Subred LB_SUBNET_NAME: SUBNET_A
- Nombre: neg-2
  - Zona GCP_NEG_ZONE: ZONE_B en la región REGION_B
  - Subred LB_SUBNET_NAME: SUBNET_B
Puedes especificar un puerto mediante la opción --default-port al crear el NEG o especificar un número de puerto para cada endpoint, como se muestra en el siguiente paso.

Añade los endpoints a neg1 y neg2.

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'

Configurar el NEG de conectividad híbrida

Al crear el NEG, usa una zona que minimice la distancia geográfica entre Google Cloud y tu entorno on-premise u otro entorno de nube. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort (Alemania), puedes especificar la zona europe-west3-a Google Cloud al crear el NEG.

Además, si usas Cloud Interconnect, la zona utilizada para crear el NEG está en la misma región en la que se configuró la vinculación de Cloud Interconnect.

Las NEGs híbridas solo admiten las comprobaciones de estado de Envoy distribuidas.

Consola

Para crear un grupo de endpoints de red de conectividad híbrida, sigue estos pasos:

En la Google Cloud consola, ve a la página Grupos de puntos finales de red.

Ir a grupos de puntos finales de red
Haz clic en Crear grupo de endpoints de red.
Repite los pasos del 4 al 9 para cada NEG híbrido, utilizando 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
Asigna el nombre como se indica en el paso anterior.
Selecciona el Tipo de grupo de puntos finales de red: Grupo de puntos finales de red de conectividad híbrida (por zonas).
Selecciona Red: NETWORK
En Subred, elija la opción que se indica en el paso anterior.
En Zona, elige la opción que se indica en el paso anterior.
Introduce el puerto predeterminado.
Primero, haz clic en Crear.

Añade endpoints al NEG de conectividad híbrida:

En la Google Cloud consola, ve a la página Grupos de puntos finales de red.

Ir a grupos de puntos finales de red
Haga clic en el nombre del grupo de endpoints de red creado en el paso anterior. Verás la página Detalles del grupo de puntos finales de red.
En la sección Puntos finales de red de este grupo, haz clic en Añadir punto final de red. Verás la página Añadir punto final de red.
Introduce la dirección IP del nuevo endpoint de red.
Seleccione el Tipo de puerto.
1. Si seleccionas Predeterminado, el endpoint usará el puerto predeterminado para todos los endpoints del grupo de endpoints de red.
2. Si selecciona Personalizado, puede introducir otro Número de puerto para que lo use el endpoint.
Para añadir más endpoints, haz clic en Añadir endpoint de red y repite los pasos anteriores.
Una vez que hayas añadido todos los endpoints que no seanGoogle 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
- Nombre ON_PREM_NEG_NAME: hybrid-2
  - Zona GCP_NEG_ZONE: ON_PREM_NEG_ZONE2

Añade el endpoint de la VM 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 añadir los endpoints de red que hayas configurado anteriormente en tu entorno local o en la nube. Repite --add-endpoint tantas veces como sea necesario.

Configurar el balanceador de carga

Consola

gcloud

Define la comprobación del 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

Añade 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

Para obtener información sobre cómo configurar el modo de balanceo, consulta la documentación de la CLI de gcloud sobre la marca --max-rate-per-endpoint.

Añade los NEGs híbridos como 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 \

Para obtener información sobre cómo configurar el modo de balanceo, consulta la documentación de la CLI de gcloud sobre el parámetro --max-rate-per-endpoint.

Crea el mapa de URLs 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.

En 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 gestionado por Google, consulta la siguiente documentación:
- Crea un certificado gestionado por Google emitido por tu instancia del servicio de autoridad de certificación.
- Crea un certificado gestionado por Google con autorización de DNS.
Después de crear el certificado gestionado por Google, adjúntalo al proxy de destino. Los balanceadores de carga de aplicaciones internos entre regiones no admiten mapas de certificados.

Para crear un certificado autogestionado, consulta la siguiente documentación:
- Crea una clave privada y un certificado.
Asigna las rutas de los 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 de 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 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 dirección IP virtual IP_ADDRESS1 en la región REGION_A y otra con una dirección IP virtual IP_ADDRESS2 en la región REGION_B. Para la dirección IP de la regla de reenvío, usa el intervalo de direcciones IP LB_SUBNET_RANGE1 LB_SUBNET_RANGE2. Si intentas usar la subred de solo proxy, no se podrá crear la regla de reenvío.

En el caso de las redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que se trata de la subred de la VM, no de la subred del proxy.

En 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

Conectar tu dominio a tu balanceador de carga

Después de crear el balanceador de carga, anota la dirección IP asociada a él (por ejemplo, IP_ADDRESS1 y IP_ADDRESS2). Para dirigir tu dominio a tu balanceador de carga, crea un registro A con Cloud DNS o con un servicio de registro de dominios. Si has añadido varios dominios a tu certificado SSL, debes añadir un registro A para cada uno de ellos, todos apuntando a la dirección IP del balanceador de carga.

Probar el balanceador de carga

Crear una instancia de máquina virtual para probar la conectividad

Crea una VM 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 dirección IP esté sirviendo su nombre de host.
- Verifica que la VM cliente pueda acceder a ambas direcciones IP. El comando debería completarse correctamente y devolver el nombre de la VM backend que ha servido la solicitud:
  
  Para las pruebas HTTP:
```
curl IP_ADDRESS1
```
```
curl IP_ADDRESS2
```
  Para probar HTTPS:
```
curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS1:443
```
```
curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS2:443
```
  Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.
  
  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
```

Ejecutar 100 solicitudes

Ejecuta 100 solicitudes curl y confirma en las respuestas que están balanceadas.

Para HTTP:

Verifica que la VM cliente pueda acceder a ambas direcciones IP. El comando debería completarse correctamente y devolver el nombre de la VM de backend que ha atendido 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 cliente pueda acceder a ambas direcciones IP. El comando debería completarse correctamente y devolver el nombre de la VM de backend que ha atendido la solicitud.

Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.

{
  RESULTS=
  for i in {1..100}
  do
    RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME: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://DOMAIN_NAME:443' --connect-to DOMAIN_NAME: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 de conmutación por error

Verifica la conmutación por error a los back-ends de la región REGION_A cuando los back-ends de la región REGION_B no estén en buen estado o no se pueda acceder a ellos. Para simularlo, eliminamos todos los back-ends de REGION_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 cliente de REGION_B.

gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

Envía solicitudes a la dirección IP balanceada de carga de la región REGION_B. El resultado debería ser similar al siguiente:

{
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME: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 amplía el ejemplo de configuración para ofrecer opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en el orden que prefieras.

Configurar políticas de enrutamiento de DNS

Si tus clientes se encuentran en varias regiones, puede que quieras que tu balanceador de carga de aplicación interno entre regiones sea accesible mediante VIPs en esas regiones. Esta configuración multirregión minimiza la latencia y los costes de tránsito de red. Además, te permite configurar una solución de balanceo de carga global basada en DNS que proporciona resiliencia frente a las interrupciones regionales. Para obtener más información, consulta Gestionar políticas de enrutamiento de DNS y comprobaciones de estado.

gcloud

Para crear una entrada 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

Haz los cambios siguientes:

DNS_ENTRY: nombre de DNS o de dominio del conjunto de registros
Por ejemplo, service.example.com
REGION_A y REGION_B: las regiones en las que has configurado el balanceador de carga

API

Crea el registro DNS haciendo una solicitud POST al método ResourceRecordSets.create. Sustituye PROJECT_ID por el ID de tu 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"
              }
            ]
          }
        }
      ]
    }
  }
}

Actualizar el tiempo de espera de keep-alive HTTP del cliente

El balanceador de carga creado en los pasos anteriores se ha configurado con un valor predeterminado para el tiempo de espera de keep-alive HTTP del cliente.

Para actualizar el tiempo de espera de keep-alive HTTP del cliente, sigue estas instrucciones.

Consola

En la Google Cloud consola, ve a la página Balanceo de carga.

Ve a Balanceo de carga.
Haga clic en el nombre del balanceador de carga que quiera modificar.
Haz clic en Editar.
Haz clic en Configuración de frontend.
Despliega Funciones avanzadas. En Tiempo de espera de HTTP Keep-Alive, introduce un valor de tiempo de espera.
Haz clic en Actualizar.
Para revisar los cambios, haz clic en Revisar y finalizar y, a continuación, en Actualizar.

gcloud

En el caso de un balanceador de carga HTTP, actualiza el proxy HTTP de destino con el comando gcloud 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

En el caso de un balanceador de carga HTTPS, actualiza el proxy HTTPS de destino con el comando gcloud 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

Haz los cambios siguientes:

TARGET_HTTP_PROXY_NAME: nombre del proxy HTTP de destino.
TARGET_HTTPS_PROXY_NAME: nombre del proxy HTTPS de destino.
HTTP_KEEP_ALIVE_TIMEOUT_SEC: el valor del tiempo de espera de HTTP Keep-Alive 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 servidor que no estén en buen estado y reducir el número de solicitudes que se envían a esos NEGs.

La detección de valores atípicos se habilita en el servicio backend mediante uno de los siguientes métodos:

El método consecutiveErrors (outlierDetection.consecutiveErrors), en el que un código de estado HTTP de la serie 5xx se considera un error.
El método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), en el que solo los códigos de estado HTTP 502, 503 y 504 se consideran errores.

Sigue estos pasos para habilitar la detección de anomalías en un servicio backend. Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, algunas solicitudes se pueden enviar al servicio no operativo y devolver 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.

Consola

En la Google Cloud consola, ve a la página Balanceo de carga.

Ir a Balanceo de carga
Haga clic en el nombre del balanceador de carga cuyo servicio de backend quiera editar.
En la página Detalles del balanceador de carga, haga clic en Editar.
En la página Editar balanceador de carga de aplicación interno entre regiones, haz clic en Configuración de backend.
En la página Configuración de backend, haga clic en Editar en el servicio de backend que quiera modificar.
Desplázate hacia abajo y despliega la sección Configuración avanzada.
En la sección Detección de valores atípicos, selecciona la casilla 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
Intervalo	1000
Tiempo base de expulsión	30000
Porcentaje máximo de expulsión	50
Aplicar errores consecutivos	100

En este ejemplo, el análisis de detección de anomalías se ejecuta cada segundo. Si el número de códigos de estado HTTP 5xx consecutivos que recibe un proxy Envoy es cinco o más, el endpoint de backend se expulsa del grupo de balanceo de carga de ese proxy Envoy durante 30 segundos. Cuando el porcentaje de aplicación es del 100%, el servicio backend aplica la expulsión de los endpoints que no están en buen estado de los grupos de balanceo de carga 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 endpoints de backend del grupo de balanceo de carga.

Haz clic en Guardar.
Para actualizar el servicio de backend, haz clic en Actualizar.
Para actualizar el balanceador de carga, en la página Editar balanceador de carga de aplicación interno entre regiones, haz clic en Actualizar.

gcloud

Exporta el servicio backend a un archivo YAML.

gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

Sustituye BACKEND_SERVICE_NAME por el nombre del servicio backend.

Edita la configuración YAML del servicio backend para añadir los campos de detección de valores atípicos, tal como se destaca en la siguiente configuración YAML, en la sección outlierDetection:

En este ejemplo, el análisis de detección de anomalías se ejecuta cada segundo. Si el número de códigos de estado HTTP 5xx consecutivos que recibe un proxy Envoy es cinco o más, el endpoint de backend se expulsa del grupo de balanceo de carga de ese proxy Envoy durante 30 segundos. Cuando el porcentaje de aplicación es del 100%, el servicio backend aplica la expulsión de los endpoints que no están en buen estado de los grupos de balanceo de carga 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 endpoints de backend del grupo de balanceo de carga.
```
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
...
```
Haz los cambios siguientes:
- BACKEND_SERVICE_NAME: el nombre del servicio de backend
- PROJECT_ID: el ID de tu proyecto
- REGION_A y REGION_B: las regiones en las que se ha configurado el balanceador de carga.
- SERVERLESS_NEG_NAME: el nombre del primer NEG sin servidor
- SERVERLESS_NEG_NAME_2: el nombre del segundo NEG sin servidor
Actualiza el servicio de backend importando 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.

Configurar un balanceador de carga de aplicaciones interno entre regiones con conectividad híbrida Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Descripción general de la configuración

Configurar un recurso de certificado SSL

Permisos

Establecer una conectividad híbrida

Configurar un entorno externo Google Cloud

Configurar endpoints de red

Configurar reglas de cortafuegos

Anunciar rutas

Configurar el Google Cloud entorno

Configurar las subredes de backend

Consola

gcloud

API

Configurar la subred de solo proxy

Consola

gcloud

API

Crear reglas de cortafuegos

Consola

gcloud

Configurar el NEG de zona

Crear VMs

Consola

gcloud

Crear el NEG de zona

Consola

gcloud

Configurar el NEG de conectividad híbrida

Consola

gcloud

Configurar el balanceador de carga

Consola

gcloud

Conectar tu dominio a tu balanceador de carga

Probar el balanceador de carga

Crear una instancia de máquina virtual para probar la conectividad

Ejecutar 100 solicitudes

Prueba de conmutación por error

Opciones de configuración adicionales

Configurar políticas de enrutamiento de DNS

gcloud

API

Actualizar el tiempo de espera de keep-alive HTTP del cliente

Consola

gcloud

Habilitar la detección de valores atípicos

Consola

gcloud

Siguientes pasos

Configurar un balanceador de carga de aplicaciones interno entre regiones con conectividad híbrida