Configura un balanceador de cargas de red de transferencia externo global con backends de NEG zonales

En este documento, se muestra cómo crear un balanceador de cargas de red de transferencia externo global para balancear el tráfico entre backends de NEG zonales implementados en varias regiones.

Antes de comenzar

Asegúrate de que tu configuración cumpla con los requisitos.

Instala Google Cloud CLI

En las instrucciones de esta guía, se usa Google Cloud CLI para configurar un balanceador de cargas de red de transferencia externo global. Para instalarla, consulta Instala gcloud CLI.

Roles obligatorios

Si eres el creador del proyecto, se te otorga el rol de propietario (roles/owner). De forma predeterminada, el rol de propietario (roles/owner) o el rol de editor (roles/editor) incluyen los permisos necesarios para seguir este documento.

Si no eres el creador del proyecto, se deben otorgar los permisos necesarios en el proyecto a la principal correspondiente. Por ejemplo, una principal puede ser una Cuenta de Google (para usuarios finales) o una cuenta de servicio.

Para obtener los permisos que necesitas para configurar un balanceador de cargas de red externo global de transferencia con backends de grupos de instancias de VM, pídele a tu administrador que te otorgue los siguientes roles de IAM en tu proyecto:

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.

Para obtener más información sobre los roles y permisos de Cloud Load Balancing, consulta Roles y permisos. Si deseas obtener más información para definir políticas de IAM con permisos condicionales para reglas de reenvío, consulta Condiciones de IAM para reglas de reenvío.

Descripción general de la configuración

En el siguiente diagrama, se muestra un balanceador de cargas de red de transferencia externo global con backends de NEG zonales implementados en las regiones us-west1 y europe-west2. Para comprender cómo funciona un balanceador de cargas de red de transferencia externo global, consulta la sección Arquitectura de la guía de descripción general.

En este ejemplo, se configuran los siguientes componentes:

  • Cuatro VM de backend:

    • vm-us-1 y vm-us-2 en la zona us-west1-a
    • vm-eu-1 y vm-eu-2 en la zona europe-west2-a

  • Dos NEG zonales con extremos GCE_VM_IP:

    • Vincula nic0 de vm-us-1 y vm-us-2 al NEG en la zona us-west1-a
    • Vincula nic0 de vm-eu-1 y vm-eu-2 al NEG en la zona europe-west2-a

  • Un solo balanceador de cargas de red de transferencia externo global para balancear el tráfico de TCP:80 entre los cuatro extremos de red.

Un balanceador de cargas de red de transferencia externo global envía tráfico a backends de NEG zonales implementados en las regiones `us-west1` y `europe-west2`.
Distribución del tráfico a backends de NEG zonales con un balanceador de cargas de red de transferencia externo global (haz clic para ampliar).

Configura la red y las subredes

En el ejemplo, se usa una red de VPC en modo personalizado llamada lb-network con subredes en dos regiones diferentes.

Puedes configurar un balanceador de cargas de red de transferencia externo global para que tenga GCE_VM_IP extremos de red que puedan hacer referencia a la interfaz de red de una VM cuyo tipo de pila puede ser solo IPv4 o de pila doble.

En la siguiente tabla, se resume la compatibilidad entre los tipos de tráfico del balanceador de cargas, las interfaces de red de la VM de backend y los tipos de pila de subred de VPC. Asegúrate de conocer los requisitos de compatibilidad de la interfaz de red de la VM de backend con las subredes de VPC que se describen en la guía de arquitectura del balanceador de cargas de red de transferencia externo global.

Tipo de tráfico del balanceador de cargas Tipo de pila de la interfaz de red de la VM de backend Tipo de pila de la subred de VPC
Solo tráfico IPv4 IPV4_ONLY IPV4_ONLY o IPV4_IPV6
IPV4_IPV6 IPV4_IPV6
Solo tráfico IPv6 IPV6_ONLY IPV6_ONLY o IPV4_IPV6
IPV4_IPV6 IPV4_IPV6
Tráfico IPv4 e IPv6 IPV4_IPV6 IPV4_IPV6

gcloud

  1. Crea la red de VPC. En este ejemplo, la red de VPC se llama lb-network.

    gcloud compute networks create lb-network --subnet-mode=custom

  2. Dentro de la red de VPC (lb-network), crea subredes en dos regiones.

    Crea una subred llamada lb-subnet-us para los extremos de red en la región us-west1.

    Para crear una subred de solo IPv4, usa el siguiente comando:

    gcloud compute networks subnets create lb-subnet-us \
    --stack-type=IPV4_ONLY \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

    Para crear una subred de pila doble, usa el siguiente comando:

    gcloud compute networks subnets create lb-subnet-us \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=EXTERNAL \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

    Crea una subred llamada lb-subnet-eu para los extremos de red en la región europe-west2.

    Para el tráfico IPv4, usa el siguiente comando para crear una subred de solo IPv4:

    gcloud compute networks subnets create lb-subnet-eu \
    --stack-type=IPV4_ONLY \
    --network=lb-network \
    --range=10.1.3.0/24 \
    --region=europe-west2

    Para el tráfico IPv4 e IPv6, usa el siguiente comando para crear una subred de pila doble:

    gcloud compute networks subnets create lb-subnet-eu \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=EXTERNAL \
    --network=lb-network \
    --range=10.1.3.0/24 \
    --region=europe-west2

Crea reglas de firewall

Para configurar de forma segura tu entorno de producción, debes crear dos reglas de firewall separadas:

  • Regla de firewall de verificación de estado, que está configurada para permitir el tráfico de entrada desde los siguientes rangos:

  • Regla de firewall de tráfico del usuario, que está configurada para permitir el tráfico de entrada desde los siguientes rangos:

    • Los rangos de IP de origen del cliente específicos que necesitan acceder a tu balanceador de cargas
    • El protocolo IP y los puertos que se configuran en tus reglas de reenvío

Ten en cuenta lo siguiente:

  • Si tu aplicación entrega contenido a todos los usuarios de Internet sin limitaciones, configura los rangos de IP de origen 0.0.0.0/0 para el tráfico de IPv4 y ::/0 para el tráfico de IPv6.

  • Si configuraste tu verificación de estado para sondear el protocolo y los puertos de IP del balanceo de cargas, puedes configurar una sola regla de firewall combinando las reglas de firewall de verificación de estado y de tráfico del usuario.

gcloud

  • Crea una regla de firewall que permita que el tráfico de TCP de todos los rangos de origen llegue a tus instancias de VM de backend en el puerto 80. Este puerto y protocolo se usan tanto para el balanceo de cargas como para la verificación de estado.

    • Para permitir todo el tráfico IPv4, ejecuta el siguiente comando:

      gcloud compute firewall-rules create firewall-allow-traffic-ipv4 \
    --network=lb-network \
    --target-tags=allow-traffic \
    --allow=tcp:80 \
    --source-ranges=0.0.0.0/0

    • Para permitir todo el tráfico IPv6, ejecuta el siguiente comando:

      gcloud compute firewall-rules create firewall-allow-traffic-ipv6 \
    --network=lb-network \
    --target-tags=allow-traffic \
    --allow=tcp:80 \
    --source-ranges=::/0

Crea VM de backend

Para este ejemplo de balanceo de cargas, crearás cuatro VMs, como se destaca en la sección Descripción general de la configuración.

En este ejemplo, la interfaz nic0 de la VM está asociada con la red de VPC lb-network y una de las subredes, ya sea lb-subnet-us o lb-subnet-eu. La interfaz de red a la que hace referencia el extremo GCE_VM_IP debe estar en la misma subred de VPC asociada con el NEG zonal.

En la siguiente tabla, se resume la compatibilidad entre los tipos de tráfico del balanceador de cargas, las interfaces de red de la VM de backend y los tipos de pila de subred de VPC. Asegúrate de conocer los requisitos de compatibilidad de la interfaz de red de la VM de backend con las subredes de VPC que se describen en la guía de arquitectura del balanceador de cargas de red de transferencia externo global.

Tipo de tráfico del balanceador de cargas Tipo de pila de la interfaz de red de la VM de backend Tipo de pila de la subred de VPC
Solo tráfico IPv4 IPV4_ONLY IPV4_ONLY o IPV4_IPV6
IPV4_IPV6 IPV4_IPV6
Solo tráfico IPv6 IPV6_ONLY IPV6_ONLY o IPV4_IPV6
IPV4_IPV6 IPV4_IPV6
Tráfico IPv4 e IPv6 IPV4_IPV6 IPV4_IPV6

gcloud

A fin de crear las cuatro VMs, ejecuta el comando gcloud compute instances create cuatro veces, con las siguientes cuatro combinaciones para VM_NAME, REGION, ZONE y SUBNET. La secuencia de comandos de Bash es idéntica para las cuatro VMs.

VM_NAME REGION ZONE SUBNET
vm-us-1 us-west1 us-west1-a lb-subnet-us
vm-us-2 us-west1 us-west1-a lb-subnet-us
vm-eu-1 europe-west2 europe-west2-a lb-subnet-eu
vm-eu-2 europe-west2 europe-west2-a lb-subnet-eu

Para crear VMs de backend con interfaces de red solo IPv4, usa el siguiente comando.

gcloud compute instances create VM_NAME \
    --zone=ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-traffic \
    --network-interface=network=lb-network,subnet=SUBNET,stack-type=IPV4_ONLY \
    --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'

Para crear VMs de backend con interfaces de red de pila doble, usa el siguiente comando.

gcloud compute instances create VM_NAME \
    --zone=ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-traffic \
    --network-interface=network=lb-network,subnet=SUBNET,stack-type=IPV4_IPV6,ipv6-network-tier=PREMIUM \
    --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'

Crea NEGs zonales con extremos GCE_VM_IP

Para este ejemplo de balanceo de cargas, crearás dos NEG zonales con extremos GCE_VM_IP.

  • NEG zonal neg-us en la zona us-west1-a. El NEG zonal consta de dos extremos de red:
    • Vincula nic0 de vm-us-1 y vm-us-2 al NEG zonal neg-us
  • NEG zonal neg-eu en europe-west2-a. El NEG zonal consta de dos extremos de red:
    • Vincula nic0 de vm-eu-1 y vm-eu-2 al NEG zonal neg-eu

Cuando creas un NEG zonal nuevo con extremos GCE_VM_IP, debes asociar el NEG de forma explícita con una subred de VPC para poder agregar extremos al NEG. El balanceador de cargas entrega paquetes a la interfaz de red que se encuentra en la subred de VPC asociada con el NEG. En este ejemplo, los extremos del NEG zonal apuntarán a nic0 de las VMs.

gcloud

  1. Crea un NEG zonal GCE_VM_IP llamado neg-us en la zona us-west1-a.

    gcloud compute network-endpoint-groups create neg-us \
    --network-endpoint-type=gce-vm-ip \
    --zone=us-west1-a \
    --network=lb-network \
    --subnet=lb-subnet-us

  2. Agrega extremos al NEG zonal neg-us.

    gcloud compute network-endpoint-groups update neg-us \
    --zone=us-west1-a \
    --add-endpoint='instance=vm-us-1' \
    --add-endpoint='instance=vm-us-2'

  3. Crea un NEG zonal GCE_VM_IP llamado neg-eu en la zona europe-west2-a.

    gcloud compute network-endpoint-groups create neg-eu \
    --network-endpoint-type=gce-vm-ip \
    --zone=europe-west2-a \
    --network=lb-network \
    --subnet=lb-subnet-eu

  4. Agrega extremos al NEG zonal neg-eu.

    gcloud compute network-endpoint-groups update neg-eu \
    --zone=europe-west2-a \
    --add-endpoint='instance=vm-eu-1' \
    --add-endpoint='instance=vm-eu-2'

Reserva direcciones IP externas globales

Un balanceador de cargas de red de transferencia externo global requiere dos direcciones IP externas globales, una de cada grupo de disponibilidad. Luego, estas dos direcciones IP se adjuntan a la regla de reenvío del balanceador de cargas.

En el caso de un balanceador de cargas de red de transferencia externo global, las direcciones IP de la regla de reenvío están completamente desacopladas de las subredes de VPC. Las direcciones IP pertenecen a grupos de direcciones IP externas globales propiedad de Google o a prefijos delegados públicos IPv4 externos globales de BYOIP de distintos grupos de disponibilidad y no están asociadas a ninguna subred de VPC.

Cuando configuras una regla de reenvío de IPv6, las direcciones IP de la regla de reenvío se asignan como prefijos /96.

gcloud

Para el tráfico IPv4, haz lo siguiente:

  1. Reserva la primera dirección IP externa global llamada lb-ipv4-ag0 en el grupo de disponibilidad 0.

    gcloud beta compute addresses create lb-ipv4-ag0 \
    --global \
    --purpose=PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP0 \
    --ip-version=IPV4

  2. Reserva la segunda dirección IP externa global lb-ipv4-ag1 en el grupo de disponibilidad 1.

    gcloud beta compute addresses create lb-ipv4-ag1 \
    --global \
    --purpose=PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP1 \
    --ip-version=IPV4

Para el tráfico IPv6, haz lo siguiente:

  1. Reserva la primera dirección IP externa global llamada lb-ipv6-ag0 en el grupo de disponibilidad 0.

    gcloud beta compute addresses create lb-ipv6-ag0 \
    --global \
    --purpose=PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP0 \
    --ip-version=IPV6

  2. Reserva la segunda dirección IP externa global lb-ipv6-ag1 en el grupo de disponibilidad 1.

    gcloud beta compute addresses create lb-ipv6-ag1 \
    --global \
    --purpose=PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP1 \
    --ip-version=IPV6

Configura el balanceador de cargas

La configuración de un balanceador de cargas de red de transferencia externo global implica la creación de una verificación de estado, un servicio de backend y una regla de reenvío.

gcloud

  1. Crea una verificación de estado de TCP configurada para generar sondeos TCP:80.

    gcloud compute health-checks create tcp hc-tcp-80 \
  --global \
  --port=80

  2. Crea un servicio de backend global con el esquema de balanceo de cargas EXTERNAL_PASSTHROUGH.

    gcloud beta compute backend-services create lb-backend-service \
  --load-balancing-scheme=EXTERNAL_PASSTHROUGH \
  --health-checks=hc-tcp-80 \
  --global

  3. Agrega los NEG zonales como backends al servicio de backend.

    Agrega el NEG zonal de la zona us-west1-a al servicio de backend.

    gcloud beta compute backend-services add-backend lb-backend-service \
    --network-endpoint-group=neg-us \
    --network-endpoint-group-zone=us-west1-a \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100000 \
    --global

    Agrega el NEG zonal de la zona europe-west2-a al servicio de backend.

    gcloud beta compute backend-services add-backend lb-backend-service \
    --network-endpoint-group=neg-eu \
    --network-endpoint-group-zone=europe-west2-a \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100000 \
    --global

  4. Crea una regla de reenvío global para atender el tráfico de TCP:80. Debes crear dos reglas de reenvío para controlar el tráfico IPv4 e IPv6.

    Asegúrate de que la versión de IP de tu regla de reenvío coincida con el tipo de pila de las interfaces de red de tu VM de backend.

    La regla de reenvío hace referencia a las direcciones IP de cada grupo de disponibilidad.

    Para el tráfico IPv4, haz lo siguiente:

    gcloud beta compute forwarding-rules create lb-forwarding-rule-ipv4 \
  --load-balancing-scheme=EXTERNAL_PASSTHROUGH \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=lb-backend-service \
  --global \
  --ip-addresses=lb-ipv4-ag0,lb-ipv4-ag1

    Para el tráfico IPv6, haz lo siguiente:

    gcloud beta compute forwarding-rules create lb-forwarding-rule-ipv6 \
  --load-balancing-scheme=EXTERNAL_PASSTHROUGH \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=lb-backend-service \
  --global \
  --ip-addresses=lb-ipv6-ag0,lb-ipv6-ag1

Prueba el balanceador de cargas

  1. Obtén las direcciones IP reservadas asociadas a la regla de reenvío.

      gcloud beta compute forwarding-rules describe lb-forwarding-rule-ipv4 \
      --global

    Esto devuelve dos direcciones IP, una para cada grupo de disponibilidad. Estas direcciones IP se denominan IP_ADDRESS_AVAILABILITY_GROUP_0 y IP_ADDRESS_AVAILABILITY_GROUP_1.

  2. Envía tráfico a cualquiera de las direcciones IP.

      curl http://IP_ADDRESS_AVAILABILITY_GROUP_0

      curl http://IP_ADDRESS_AVAILABILITY_GROUP_1

Deberías ver respuestas de las VMs de backend en diferentes regiones según tu ubicación y el estado del backend.

Verifica la tabla de enrutamiento local para ver las direcciones IP del balanceador de cargas

Las tablas de enrutamiento locales de las VMs de backend contienen las direcciones IP del balanceador de cargas de red de transferencia externo global.

Para verificar las rutas locales en la VM de backend, conéctate a ella a través de SSH y ejecuta el siguiente comando:

  ip route list table local

El resultado es el siguiente:

local 10.1.2.5 dev ens4 proto kernel scope host src 10.1.2.5
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 136.124.69.214 dev ens4 proto 66 scope host
local 136.124.83.205 dev ens4 proto 66 scope host

En el ejemplo anterior, 136.124.69.214 y 136.124.83.205 son las direcciones IP asignadas a la regla de reenvío del balanceador de cargas. Las entradas de línea local 136.124.69.214 dev ens4 proto 66 scope host y local 136.124.83.205 dev ens4 proto 66 scope host en la tabla de enrutamiento local de la VM permiten que el backend acepte los paquetes dirigidos a las direcciones IP del balanceador de cargas. El Cloud de Confiance entorno invitado es responsable de agregar esta entrada.

La entrada de la tabla de enrutamiento local en la VM de backend acepta el paquete para la entrega del host local, en la que la pila de red lo entrega a la aplicación en espera. Luego, los paquetes de respuesta de la aplicación se envían directamente al cliente.

Ten en cuenta que la dirección IP del balanceador de cargas no se configura en realidad en la interfaz de red de la VM. Para verificarlo, ejecuta el siguiente comando:

  ip addr list

El resultado es el siguiente. Las direcciones IP (136.124.69.214 y 136.124.83.205) aparecen en la tabla de enrutamiento local, pero no están configuradas en la interfaz de red.

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: ens4:  mtu 1460 qdisc fq_codel state UP group default qlen 1000
    link/ether 42:01:0a:01:02:0d brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    inet 10.1.2.13/32 metric 100 scope global dynamic ens4
       valid_lft 84283sec preferred_lft 84283sec
    inet6 fe80::4001:aff:fe01:20d/64 scope link
       valid_lft forever preferred_lft forever

¿Qué sigue?