Subredes de solo proxy para balanceadores de cargas de HTTP(S) internos

En esta página, se describe cómo trabajar con subredes de solo proxy para el balanceo de cargas de HTTP(S) interno. Para obtener una descripción general del balanceo de cargas de HTTP(S) interno, consulta los conceptos del balanceo de cargas de HTTP(S) interno.

El balanceador de cargas de HTTP(S) interno proporciona un conjunto de proxies para tu red. Los proxies evalúan dónde debe ir cada solicitud HTTP(S) según la asignación de URL, la afinidad de sesión del servicio de backend, el modo de balanceo de cada grupo de instancias de backend o NEG y otros factores.

  1. Un cliente establece una conexión a la dirección IP y al puerto de la regla de reenvío del balanceador de cargas.

  2. Uno de los servidores proxy recibe y finaliza la conexión de red del cliente.

  3. El proxy establece una conexión con la VM o el extremo de backend en un NEG, según lo determinan los servicios de backend y la asignación de URL del balanceador de cargas.

A cada uno de los proxies del balanceador de cargas se le asigna una dirección IP interna. Los proxies para todos los balanceadores de cargas HTTP(S) internos en una región usan direcciones IP internas de una única subred de solo proxy en esa región, en tu red de VPC. Esta subred está reservada de forma exclusiva para proxies de balanceo de cargas de HTTP(S) interno y no puede usarse con otros fines. Una subred de solo proxy debe proporcionar 64 o más direcciones IP. Esto corresponde a una longitud de prefijo de /26 o menor. Solo puede estar activa una subred de solo proxy por región y por red de VPC.

Solo los proxies que crea GCP para los balanceadores de cargas HTTP(S) internos de una región usan la subred de solo proxy. La dirección IP de la regla de reenvío del balanceador de cargas no proviene de la subred de solo proxy. Además, las direcciones IP de las VM y los extremos de backend no provienen de la subred de solo proxy.

Cada proxy escucha en la dirección IP y el puerto que especifica la regla de reenvío del balanceador de cargas correspondiente. Cada paquete enviado desde un proxy a una VM o extremo de backend tiene una dirección IP de origen de la subred de solo proxy.

En el siguiente diagrama, se proporciona una vista de alto nivel del flujo de tráfico.

Servicios internos con balanceo de cargas basado en la capa 7 (haz clic para ampliar)
Servicios internos con balanceo de cargas basado en la capa 7 (haz clic para ampliar)

Cómo las subredes de solo proxy encajan en la arquitectura del balanceador de cargas

En el siguiente diagrama, se muestran los recursos de GCP necesarios para un balanceador de cargas interno HTTP(S).

Componentes del balanceo de cargas de HTTP(S) interno (haz clic para ampliar)
Componentes del balanceo de cargas de HTTP(S) interno (haz clic para ampliar)

Como se muestra en el diagrama, la implementación del balanceador de cargas de HTTP(S) interno requiere al menos dos subredes:

  • La regla de reenvío administrado interno del balanceador de cargas y las direcciones IP de las VM y los extremos de backend usan una única subred cuyo rango de direcciones IP principal es 10.1.2.0/24. Esta no es la subred de solo proxy. Puedes usar varias subredes para tus extremos y VM de backend si las subredes están en la misma región que el balanceador de cargas.

  • La subred de solo proxy es 10.129.0.0/26.

Crea una subred de solo proxy

Reservar una subred para un balanceador de cargas de HTTP(S) es básicamente el mismo procedimiento que se usa con el fin de crear cualquier subred, excepto que se agregan algunas marcas.

Debes crear una subred de solo proxy de modo que la usen los proxies del balanceador de cargas antes de crear reglas de reenvío para tus balanceadores de cargas HTTP(S) internos. Si intentas configurar un balanceador de cargas de HTTP(S) interno sin crear primero una subred de solo proxy para la región, el proceso de creación del balanceador de cargas falla.

Debes crear una subred de solo proxy en cada región de una red virtual (VPC) en la que uses balanceadores de cargas HTTP(S) internos. Todos los balanceadores de cargas HTTP(S) internos en la región comparten esta subred.

Debes crear subredes de solo proxy sin importar si tu red está en modo automático o personalizado. El tamaño de subred recomendado es /24 (256 direcciones de solo proxy). Debe ser de al menos /26 (64 direcciones de solo proxy).

El comando gcloud compute networks subnets create crea una subred de solo proxy.

gcloud beta compute networks subnets create SUBNET_NAME \
    --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

En el que sucede lo siguiente:

  • SUBNET_NAME es el nombre de la subred de solo proxy.
  • REGION es la región de la subred de solo proxy.
  • VPC_NETWORK_NAME es el nombre de la red de VPC que contiene la subred.
  • CIDR_RANGE es el rango de IP principal de la subred. Debes usar una máscara de subred de una longitud máxima de 26 a fin de que al menos 64 direcciones IP estén disponibles para los servidores proxy en la región.

Para ver un ejemplo de configuración completo, consulta la sección sobre cómo crear la subred de solo proxy.

Si usas GCP Console, puedes crear la subred de solo proxy en la IU del balanceo de cargas, como se describe en las siguientes secciones:

Debes configurar una regla de firewall para que tus backends acepten conexiones de la subred de solo proxy. Consulta la configuración de l7-ilb-firewall en la sección sobre cómo configurar reglas de firewall.

Cambia el tamaño o el rango de direcciones de una subred de solo proxy

Debido a que solo una subred de solo proxy puede estar activa por región y por red de VPC, y a que solo puedes expandir el rango de IP principal de una subred, debes usar el siguiente procedimiento para modificar la subred de solo proxy:

  1. Crea una subred de solo proxy de copia de seguridad en la misma región y especifica un rango de IP principal que se adapte a tus necesidades mediante el comando gcloud compute networks subnets create.

    gcloud beta compute networks subnets create subnet-name \
       --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
       --role=BACKUP \
       --region=region \
       --network=vpc-network-name \
       --range=cidr-range
    
  2. Crea o modifica reglas de firewall de entrada permitida que se apliquen a tus VM o extremos de backend de modo que incluyan el rango de IP principal de la subred de solo proxy de copia de seguridad.

  3. El siguiente comando de gcloud promueve una subred de solo proxy de copia de seguridad a la función activa y desciende el nivel de la subred de solo proxy activa a la función de copia de seguridad:

    gcloud beta compute networks subnets update backup-proxy-subnet \
       --role=ACTIVE \
       --drainTimeoutSeconds=connection-draining-timeout<\var>
    

    Reemplaza los marcadores de posición por valores válidos:

    • <var>backup-proxy-subnet</var> es el nombre de la subred de solo proxy recién creada.
    • <var>connection-draining-timeout<\var> es la cantidad de tiempo, en segundos, que usa GCP para migrar las conexiones existentes fuera de los proxies de la subred de solo proxy que estaba activa.

    Cambiar una subred de solo proxy de copia de seguridad a activa no interrumpe las conexiones nuevas:

    • La subred de solo proxy recién activada se usa para conexiones nuevas.
    • La subred de solo proxy que estaba activa (y ahora es de copia de seguridad) ya no se usa para conexiones nuevas.
    • GCP comienza a desviar las conexiones existentes de los proxies en la subred de solo proxy que estaba activa (y ahora es de copia de seguridad).
  4. Después de que se agote el tiempo de espera del desvío de la conexión o cuando estés seguro de que las conexiones a las VM o los extremos de backend de tu servidor no provienen de proxies de la subred de solo proxy que estaba activa (y ahora es de copia de seguridad), puedes hacer lo siguiente:

    • Modifica las reglas de firewall de entrada permitida que se aplican a las VM o extremos de backend para que no incluyan el rango de IP principal de la subred de solo proxy que estaba activa (y ahora es de copia de seguridad).
    • Borra la subred de solo proxy que estaba activa (y ahora es de copia de seguridad) a fin de liberar las direcciones IP que la subred usaba para su rango de direcciones IP principal.

Requisitos y limitaciones

Se aplican las siguientes restricciones a las subredes de solo proxy:

  • Solo puedes crear una subred de solo proxy activa y una de copia de seguridad en cada región de cada red de VPC.

  • No puedes crear una subred de solo proxy de copia de seguridad, a menos que ya hayas creado una subred de solo proxy activa en esa región y red.

  • Puedes cambiar la función de una subred de solo proxy de copia de seguridad a activa si actualizas la subred. Cuando lo haces, GCP cambia de forma automática la subred de solo proxy de activa a copia de seguridad. No puedes establecer de forma explícita la función de una subred de solo proxy a copia de seguridad con solo actualizarla.

  • Durante el período de desvío de conexiones de una subred de solo proxy (drainTimeoutSeconds), no puedes cambiar la función de una subred de solo proxy de copia de seguridad a activa.

  • Antes de poder crear tu primer balanceador de cargas de HTTP(S) interno en una región y una red de VPC determinadas, ya debes tener una subred de solo proxy activa en esa región y esa red.

  • GCP no te avisa si tu subred de solo proxy se queda sin direcciones IP.

Ejemplo

  1. Crea una subred de solo proxy de copia de seguridad dedicada a la región.

    gcloud beta compute networks subnets create new-l7ibackend-subnet-us-west1 \
       --purpose INTERNAL_HTTPS_LOAD_BALANCER \
       --role BACKUP \
       --region us-west1 \
       --network default \
       --addresses 10.130.0.0/26
    
  2. Actualiza tu firewall de backend para aceptar conexiones desde la subred nueva.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.129.0.0/26,10.130.0.0/26
    
  3. Actualiza la subred nueva, configúrala como la subred de solo proxy ACTIVE en la región y espera a que la antigua subred se desvíe.

    gcloud beta compute networks subnets update new-l7ilb-ip-range-us-west1 \
       --drain-timeout 1h --role ACTIVE
    

    Para desviar de inmediato un rango de direcciones IP, establece --drain-timeout en 0s. Esto finalizará con rapidez todas las conexiones a los proxies que tengan direcciones asignadas en la subred que se desvía.

  4. Supervisa el estado del desvío mediante un comando list o describe. El estado de la subred será DRAINING mientras se desvía.

    gcloud beta compute networks subnets list
    

    Espera a que se complete el desvío. Cuando se desvía la subred de solo proxy anterior, el estado de la subred pasa a READY.

  5. Actualiza tu regla de firewall de backend para permitir solo conexiones desde la subred nueva.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.130.0.0/26
    
  6. Borra la subred anterior.

    gcloud beta compute networks subnets delete l7ilb-ip-range-us-west1 \
       --region us-west1
    

Borra una subred de solo proxy

Si borras una subred de solo proxy, se libera su rango de IP principal para que puedas usarlo con otro propósito. GCP aplica las siguientes reglas cuando recibe una solicitud para borrar una subred de solo proxy:

  • Una subred de solo proxy activa no se puede borrar si hay al menos un balanceador de cargas de HTTP(S) interno en la misma región y red de VPC.

  • Una subred de solo proxy activa no se puede borrar si existe una subred de solo proxy de copia de seguridad en la misma región y red de VPC.

En la práctica, estas reglas tienen el siguiente efecto:

  • Si no se define un balanceador de cargas de HTTP(S) interno en una región y una red de VPC determinadas, puedes borrar las subredes de solo proxy en esa región. Si existe una subred de solo proxy de copia de seguridad, primero debes borrarla para poder borrar la subred de solo proxy activa.

  • Si tienes al menos un balanceador de cargas de HTTP(S) interno definido en una región y una red de VPC determinadas, no puedes borrar la subred de solo proxy activa; sin embargo, puedes promover una subred de solo proxy de copia de seguridad a la función activa, lo que desciende el nivel de la subred de solo proxy que estaba activa a la función de copia de seguridad de forma automática. Una vez que se desvíen las conexiones, puedes borrar la subred de solo proxy de copia de seguridad (que antes estaba activa).

Consulta la sección sobre cómo borrar subredes en la documentación de red de VPC para obtener más información.

Próximos pasos

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...