Subredes de solo proxy para balanceadores de cargas basados en Envoy

En esta página, se describe cómo trabajar con subredes de solo proxy que usan los balanceadores de cargas basados en Envoy. Una subred de solo proxy proporciona un grupo de direcciones IP que se reservan exclusivamente para proxies de Envoy que usan los balanceadores de cargas Google Cloud . No se puede usar para otros fines.

Los proxies finalizan las conexiones entrantes y 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. Cada proxy escucha en la dirección IP y el puerto que especifica la regla de reenvío del balanceador de cargas correspondiente. Uno de los proxies 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 paquetes enviados desde un proxy a una VM o un extremo de backend tienen una dirección IP de origen de la subred de solo proxy.

La subred de solo proxy no se puede usar para ningún otro propósito. La dirección IP de la regla de reenvío del balanceador de cargas no proviene de la subred de solo proxy. Tampoco lo hacen las direcciones IP de las VMs y los extremos de backend.

Balanceadores de cargas y productos admitidos

Los productos de Cloud Load Balancing y Secure Web Proxy basados en Envoy requieren subredes de solo proxy:

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

En el siguiente diagrama, se muestran los recursos Google Cloud necesarios para un balanceador de cargas de aplicaciones interno regional.

Componentes numerados del balanceador de cargas de aplicaciones interno regional.
Componentes numerados del balanceador de cargas de aplicaciones interno regional (haz clic para ampliar).

Como se muestra en los diagramas, una implementación del balanceador de cargas basado en Envoy requiere al menos dos subredes:

  • Las VM de backend y los extremos de backend del balanceador de cargas usan una sola subred cuyo rango de direcciones IP principal es 10.1.2.0/24 (en este ejemplo). Esta no es la subred de solo proxy. Puedes usar varias subredes para tus extremos y VMs de backend si las subredes están en la misma región que el balanceador de cargas. Para los balanceadores de cargas de aplicaciones internos, la dirección IP del balanceador de cargas asociada con la regla de reenvío también puede estar en esta subred (pero no es necesario que lo esté).
  • La subred de solo proxy es 10.129.0.0/23 (en este ejemplo).

Planifica el tamaño de tu subred de solo proxy

Una subred de solo proxy debe proporcionar 64 direcciones IP o más. Esto corresponde a una longitud de prefijo de /26 o menor. Recomendamos que comiences con una subred de solo proxy con un prefijo /23 (512 direcciones de solo proxy) y que cambies el tamaño a medida que cambia el tráfico.

Los proxies se asignan a nivel de la VPC, no a nivel del balanceador de cargas. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas basados en Envoy. Si implementas múltiples balanceadores de cargas en la misma región y red de VPC, estos comparten la misma subred de solo proxy para el balanceo de cargas. Los balanceadores de cargas basados en Envoy escalan automáticamente la cantidad de proxies disponibles para administrar el tráfico según tus necesidades de tráfico.

La cantidad de proxies asignados a tu balanceador de cargas se calcula según la capacidad medida necesaria para administrar el tráfico durante un período de 10 minutos. Durante este período, observamos el valor más alto que se obtiene en los siguientes supuestos:

  • La cantidad de proxies necesarios para ofrecer un servicio que se adapte a las necesidades de ancho de banda del tráfico. Cada instancia de proxy puede administrar hasta 18 MB por segundo. Supervisamos el ancho de banda total necesario y dividimos ese total por el ancho de banda que una instancia de proxy puede admitir.

  • La cantidad de proxies necesarios para administrar las conexiones y las solicitudes. Contamos la cantidad total de cada uno de los siguientes recursos y dividimos cada valor por lo que una instancia de proxy puede administrar:

    • 600 (HTTP) o 150 (HTTPS) conexiones nuevas por segundo
    • 3,000 conexiones activas

    • 1,400 solicitudes por segundo

      Una instancia de proxy puede controlar 1,400 solicitudes por segundo si Cloud Logging está inhabilitado. Si habilitas Logging, la instancia de proxy puede administrar menos solicitudes por segundo. Por ejemplo: registrar el 100% de las solicitudes disminuye la capacidad de control de solicitudes del proxy a 700 solicitudes por segundo. Puedes configurar Logging para realizar muestras de un porcentaje menor de tráfico. Esto te permite satisfacer tus necesidades de observabilidad mientras controlas los costos.

Cada proxy adicional genera un cargo adicional por hora. Para obtener información sobre cómo se facturan las subredes de solo proxy, consulta la sección Cargo de instancias de proxy en la documentación de precios de Cloud Load Balancing.

Balanceadores de cargas basados en Envoy y proxies de Envoy de Secure Web Proxy

Cuando configures un balanceador de cargas basado en Envoy y un proxy web seguro en la misma VPC, es importante tener en cuenta lo siguiente:

  • Tanto el balanceador de cargas basado en Envoy como el proxy web seguro usan direcciones IP de la misma subred de solo proxy.

  • Para satisfacer los requisitos de direcciones IP de ambos servicios, considera usar una subred de solo proxy más grande, como una subred /22. Esto ayuda a garantizar que haya suficiente espacio de direcciones para ambas configuraciones.

  • Te recomendamos que supervises la capacidad del proxy para hacer un seguimiento del consumo de direcciones IP. Esto ayuda a evitar el agotamiento de la subred solo de proxy, lo que puede interrumpir los servicios.

Crea una subred de solo proxy

Debes crear subredes de solo proxy para los balanceadores de cargas basados en Envoy, sin importar si tu red está en modo automático o personalizado. Crear una subred de solo proxy es casi el mismo procedimiento que se usa para crear cualquier subred, excepto que se agregan algunas marcas.

En el caso de una subred de solo proxy, --purpose debe configurarse como REGIONAL_MANAGED_PROXY o GLOBAL_MANAGED_PROXY, según el balanceador de cargas.

No puedes volver a usar una subred existente como la subred de solo proxy. Debes crear una subred nueva en cada región que tenga un balanceador de cargas HTTP(S) basado en Envoy. Esto se debe en parte a que el comando subnets update no permite modificar el campo --purpose de la subred.

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 regionales. Si intentas configurar un balanceador de cargas sin crear primero una subred de solo proxy para la región, el proceso de creación del balanceador de cargas falla.

Console

  1. En la consola de Google Cloud , ve a la página Redes de VPC.
    Ir a la página Redes de VPC
  2. Haz clic en el nombre de la red de VPC compartida a la que deseas agregar una subred de solo proxy.
  3. Haz clic en Agregar subred.
  4. Escribe un Nombre.
  5. Selecciona una Región.
  6. Configura Propósito en uno de los siguientes valores:
    • Para balanceadores de cargas regionales: Proxy administrado regional
    • Para balanceadores de cargas entre regiones: Proxy administrado entre regiones
    • Ingresa un Rango de direcciones IP.
    • Haz clic en Agregar.

gcloud

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

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

Los campos se definen de la siguiente manera:

  • SUBNET_NAME es el nombre de la subred de solo proxy.
  • SUBNET_PURPOSE es el propósito de la subred. Configura estocomo REGIONAL_MANAGED_PROXY o GLOBAL_MANAGED_PROXY, según el balanceador de cargas.
  • 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 direcciones IP principal de la subred. Debes usar una máscara de subred de una longitud máxima de 26 para que al menos 64 direcciones IP estén disponibles para los proxies de la región. El tamaño recomendado de la máscara de subred es /23.

Para obtener un ejemplo de configuración completo, consulta Configura la subred de solo proxy.

Debes configurar una regla de firewall para que tus backends acepten conexiones de la subred de solo proxy. Para obtener un ejemplo de configuración completo, incluida la configuración de reglas de firewall, consulta lo siguiente:

Disponibilidad del proxy

En ocasiones, las Google Cloud regiones no tienen suficiente capacidad de proxy para un nuevo balanceador de cargas. Si esto sucede, la Google Cloud consola muestra un mensaje de advertencia de disponibilidad del proxy cuando creas el balanceador de cargas. Para resolver este problema, puedes realizar una de las siguientes acciones:

  • Selecciona una región diferente para el balanceador de cargas. Esta puede ser una opción práctica si tienes backends en otra región.
  • Selecciona una red de VPC que ya tenga asignada una subred de solo proxy.
  • Espera a que se resuelva el problema de capacidad.

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

Cuando aumenta la cantidad de tráfico que controla tu balanceador de cargas, es posible que debas aumentar el tamaño de tu subred de solo proxy para permitir que una mayor cantidad de proxies de Envoy alimenten tus balanceadores de cargas.

No puedes expandir el rango de direcciones IPv4 principal de una subred de solo proxy de la misma manera que expandirías el rango de direcciones IPv4 principal de una subred normal (con el comando expand-ip-range). En su lugar, debes reemplazar la subred de solo proxy por una nueva. El proceso de reemplazo funciona de la siguiente manera:

  • Crea una nueva subred de solo proxy en la misma región y red de VPC que la subred de solo proxy existente (original). Cuando crees esta nueva subred de solo proxy, establece su role en BACKUP. (Para cada propósito de subred de solo proxy, Google Cloud permite que existan una subred de solo proxy ACTIVE y una BACKUP en una región y una red de VPC determinadas).

  • Ajusta las reglas de firewall de entrada permitida, aplicables a tus backends, de modo que permitan conexiones desde los rangos de direcciones IPv4 principales de las subredes de solo proxy originales y nuevas.

  • Establece el rol de la nueva subred de solo proxy en ACTIVE y especifica un período de vaciado para permitir que finalicen las conexiones entre tus backends y los proxies de Envoy en la subred de solo proxy original. (Google Cloud establece automáticamente el rol de la subred de solo proxy original en BACKUP cuando estableces el rol de la nueva subred de solo proxy en ACTIVE).

  • Supervisa el estado de la subred original de solo proxy (consulta la pestaña gcloud para obtener más información sobre la supervisión). Una vez que su estado es READY, la subred ya no se usa, siempre que su rol sea BACKUP. En este punto, puedes ajustar las reglas de firewall de permiso de entrada para permitir conexiones solo desde el rango de direcciones IPv4 principal de la nueva subred de solo proxy y puedes borrar la subred de solo proxy original.

Console

  1. Crea la nueva subred de solo proxy en la misma región y red de VPC, y especifica un rango de direcciones IPv4 principal que se adapte a tus necesidades. Establece el rol de la nueva subred de solo proxy como copia de seguridad.

    1. En la consola de Google Cloud , ve a la página Redes de VPC.
      Ir a la página Redes de VPC
    2. Haz clic en el nombre de la red de VPC compartida a la que deseas agregar una subred de solo proxy.
    3. Haz clic en Agregar subred.
    4. Escribe un Nombre.
    5. Selecciona una Región.
    6. Configura Propósito en uno de los siguientes valores:
      • Para balanceadores de cargas regionales: Proxy administrado regional
      • Para balanceadores de cargas entre regiones: Proxy administrado entre regiones
      • En Rol, selecciona Copia de seguridad.
      • Ingresa un Rango de direcciones IP.
      • Haz clic en Agregar.

  2. Actualiza las reglas de firewall de entrada permitida que se aplican a tus VMs o extremos de backend para que incluyan los rangos de direcciones IPv4 principales de ambas subredes de solo proxy, tanto la original como la nueva.

  3. Establece el rol de la nueva subred de solo proxy como activa y especifica un tiempo de espera de vaciado para permitir que finalicen las conexiones entre tus backends y la subred de solo proxy original. Google Cloud establece automáticamente el rol de la subred de solo proxy original como copia de seguridad cuando estableces el rol de la nueva subred de solo proxy como activa.

    1. En la consola de Google Cloud , ve a la página Redes de VPC.
      Ir a la página Redes de VPC
    2. Haz clic en el nombre de la red de VPC compartida que deseas modificar.
    3. En Subredes de solo proxy reservadas para el balanceo de cargas, ubica la subred de copia de seguridad creada en el paso anterior.
    4. Haz clic en Activar.
    5. Especifica un Tiempo de espera de vaciado opcional.
    6. Haz clic en Activar la subred.

  4. Después de que se agote el tiempo de espera del vaciado de conexiones o cuando tengas la certeza de que las conexiones a las VMs o los extremos de backend no provienen de proxies de la subred de solo proxy original, puedes hacer lo siguiente:

    • Actualiza las reglas de firewall de entrada permitida que se aplican a tus VM o extremos de backend para que incluyan el rango de direcciones IPv4 principal de solo la subred de solo proxy nueva.
    • Borra la subred de solo proxy original.

gcloud

En los siguientes pasos, se muestra cómo intercambiar una subred de solo proxy existente por una nueva. En todos los siguientes pasos, haz lo siguiente:

  • ORIGINAL_PROXY_ONLY_SUBNET_NAME: El nombre de la subred de solo proxy existente
  • ORIGINAL_PROXY_ONLY_SUBNET_RANGE: Es el rango de direcciones IPv4 principal de la subred existente de solo proxy en formato CIDR. Este es un rango de direcciones que elegiste anteriormente.
  • NEW_PROXY_ONLY_SUBNET_NAME: El nombre de la nueva subred de solo proxy
  • NEW_PROXY_ONLY_SUBNET_RANGE: Es el rango de direcciones IPv4 principal de la nueva subred de solo proxy en formato CIDR. Elige un rango de direcciones IPv4 que satisfaga tus necesidades.
  • PROXY_ONLY_SUBNET_FIREWALL_RULE: Es el nombre de una regla de firewall de VPC de permiso de entrada que permite conexiones desde subredes de solo proxy.
  • REGION: Es la región que contiene las subredes de solo proxy originales y nuevas.
  • VPC_NETWORK_NAME: El nombre de la red de VPC que contiene las subredes de solo proxy originales y nuevas

  1. Crea una subred de solo proxy nueva en la misma región y red de VPC con el comando gcloud compute networks subnets create con la marca --role=BACKUP.

    gcloud compute networks subnets create NEW_PROXY_ONLY_SUBNET_NAME \
   --purpose=SUBNET_PURPOSE \
   --role=BACKUP \
   --region=REGION \
   --network=VPC_NETWORK_NAME \
   --range=NEW_PROXY_ONLY_SUBNET_RANGE

    Reemplaza lo siguiente:

    • SUBNET_PURPOSE: Puede ser REGIONAL_MANAGED_PROXY o GLOBAL_MANAGED_PROXY, según el balanceador de cargas que necesite usar la subred de solo proxy. Para obtener más información, consulta Balanceadores de cargas compatibles.

  2. Actualiza las reglas de firewall de entrada permitida que se aplican a tus VMs o extremos de backend para que incluyan los rangos de direcciones IPv4 principales de ambas subredes de solo proxy, tanto la original como la nueva.

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=ORIGINAL_PROXY_ONLY_SUBNET_RANGE,NEW_PROXY_ONLY_SUBNET_RANGE

  3. Establece el rol de la nueva subred de solo proxy en ACTIVE y especifica un tiempo de espera de vaciado (--drain-timeout) para permitir que finalicen las conexiones entre tus backends y la subred de solo proxy original.Google Cloud establece automáticamente el rol de la subred de solo proxy original en BACKUP cuando estableces el rol de la nueva subred de solo proxy en ACTIVE.

    Para interrumpir de inmediato las conexiones entre tus backends y los proxies de Envoy en la subred de solo proxy original, configura --drain-timeout como 0s.

    gcloud compute networks subnets update NEW_PROXY_ONLY_SUBNET_NAME \
   --region=REGION \
   --role=ACTIVE \
   --drain-timeout=CONNECTION_DRAINING_TIMEOUT

    Reemplaza lo siguiente:

    • CONNECTION_DRAINING_TIMEOUT: Es la cantidad de tiempo, en segundos, que se permite para que finalicen las conexiones existentes entre tus backends y los proxies de Envoy en la subred de solo proxy original.

  4. Supervisa el estado de la subred original de solo proxy con el comando gcloud compute networks subnets describe.

    gcloud compute networks subnets describe ORIGINAL_PROXY_ONLY_SUBNET_NAME \
   --region=REGION

    Espera a que se complete el desvío. Durante el proceso de desvío, el estado de la subred original de solo proxy es DRAINING. Es posible que debas ejecutar el comando describe varias veces antes de que el estado de la subred original de solo proxy cambie a READY.

  5. Después de que la subred de solo proxy original se READY con el rol BACKUP, ya no se usa la subred. Actualiza las reglas de firewall de entrada permitida que se aplican a tus VMs o extremos de backend para que incluyan el rango de direcciones IPv4 principal de solo la subred de solo proxy nueva.

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=NEW_PROXY_ONLY_SUBNET_RANGE

  6. Borra la subred original de solo proxy.

    gcloud compute networks subnets delete ORIGINAL_PROXY_ONLY_SUBNET_NAME \
  --region=REGION

Migra el propósito de una subred de solo proxy

Si creaste una subred de solo proxy con --purpose=INTERNAL_HTTPS_LOAD_BALANCER, deberás migrar el propósito de la subred a REGIONAL_MANAGED_PROXY antes de que puedas crear otros balanceadores de cargas basados en Envoy en la misma región de la red de VPC.

Console

Si usas la consola de Google Cloud para crear el balanceador de cargas, se te pedirá que migres el propósito de una subred de solo proxy creada antes de --purpose=INTERNAL_HTTPS_LOAD_BALANCER a REGIONAL_MANAGED_PROXY mientras creas el balanceador de cargas.

gcloud

Para cambiar el propósito de una subred de solo proxy existente de --purpose=INTERNAL_HTTPS_LOAD_BALANCER a REGIONAL_MANAGED_PROXY, usa el siguiente comando:

gcloud compute networks subnets update PROXY_ONLY_SUBNET \
    --purpose=REGIONAL_MANAGED_PROXY \
    --region=REGION

La migración del propósito de una subred de solo proxy de --purpose=INTERNAL_HTTPS_LOAD_BALANCER a REGIONAL_MANAGED_PROXY no genera ningún tiempo de inactividad. El cambio se debería aplicar casi al instante.

Borra una subred de solo proxy

Si borras una subred de solo proxy, se libera su rango de direcciones IP principal para que puedas usarlo con otro propósito. Google Cloud 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 regional en la misma región y red de VPC.

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

    Si intentas borrar una subred de solo proxy activa antes de borrar la copia de seguridad, aparecerá el siguiente mensaje de error: “Uso de recursos no válido: no se puede borrar una subred ACTIVE porque existe una subred BACKUP”.

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

  • Si no se define un balanceador de cargas regional 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 regional 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 automáticamente. 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 Borra subredes en la documentación de red de VPC para obtener más información.

Limitaciones

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

  • No puedes tener una subred INTERNAL_HTTPS_LOAD_BALANCER y una REGIONAL_MANAGED_PROXY en la misma red y región, de la misma manera que no puedes tener dos proxies REGIONAL_MANAGED_PROXY o dos proxies INTERNAL_HTTPS_LOAD_BALANCER.

  • 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 hagas, Google Cloud cambiará automáticamente la subred de solo proxy que antes estaba activa para crear una 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 vaciado de conexiones de una subred de solo proxy (--drain-timeout), no se puede cambiar la función de una subred de solo proxy de copia de seguridad a activa.

  • Las subredes de solo proxy no admiten los registros de flujo de VPC.

¿Qué sigue?