Descripción general del balanceo de cargas de HTTP(S) externo

En este documento, se presentan los conceptos que debes comprender para configurar el balanceo de cargas de HTTP(S) externo de Google Cloud.

Para obtener información sobre la diferencia entre los balanceadores de cargas de Google Cloud, consulta los siguientes documentos:

Casos prácticos

Los balanceadores de cargas de HTTP(S) externos abordan muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Balanceo de cargas con varios tipos de backend

El balanceo de cargas de HTTP(S) externo admite los siguientes tipos de backend:

Un caso práctico común es el tráfico de balanceo de cargas entre los servicios. En el siguiente ejemplo, los clientes IPv4 y IPv6 externos pueden solicitar contenido de imágenes, API y video mediante la misma URL base, con las rutas de acceso /api, /video y /images.

El mapa de URL del balanceador de cargas de HTTP(S) externo especifica lo siguiente:

  • Las solicitudes a la ruta de acceso /api van a un servicio de backend con un grupo de instancias de VM o un backend de NEG zonal.
  • Las solicitudes a la ruta de acceso /images van a un depósito de backend con un backend de Cloud Storage.
  • Las solicitudes a la ruta de acceso /video van a un servicio de backend que apunta a un NEG de Internet que contiene un extremo externo ubicado de manera local, fuera de Google Cloud.

Cuando un cliente envía una solicitud a la dirección IPv4 o IPv6 externa del balanceador de cargas, este evalúa la solicitud según el mapa de URL y la envía al servicio correspondiente.

En el siguiente diagrama, se ilustra este caso práctico.

Diagrama del balanceo de cargas con un origen personalizado (haz clic para ampliar)
Diagrama del balanceo de cargas con un origen personalizado (haz clic para ampliar)

En cada servicio de backend, puedes habilitar de manera opcional Cloud CDN y Google Cloud Armor. Si usas Google Cloud Armor con Cloud CDN, las políticas de seguridad solo se aplican a las solicitudes de contenido dinámico, errores de caché y otras solicitudes que están destinadas al servidor de origen de CDN. Los aciertos de caché se entregan incluso si la política de seguridad posterior de Google Cloud Armor evitará que la solicitud llegue al servidor de origen de CDN.

En los depósitos de backend, se admite Cloud CDN, pero no Google Cloud Armor.

Servicios web de tres niveles

Puedes usar el balanceo de cargas de HTTP(S) externo para servicios web tradicionales de tres niveles. En el siguiente ejemplo, se muestra cómo puedes usar tres tipos de balanceadores de cargas de Google Cloud para escalar en los tres niveles. En cada nivel, el tipo de balanceador de cargas depende del tipo de tráfico:

En el diagrama, se muestra cómo se mueve el tráfico por los niveles:

  1. Un balanceador de cargas de HTTP(S) externo (el asunto de esta descripción general) distribuye el tráfico desde Internet hasta un conjunto de grupos de instancias de frontend web en varias regiones.
  2. Estos frontends envían el tráfico de HTTP(S) a un conjunto de balanceadores de cargas de HTTP(S) internos y regionales.
  3. Los balanceadores de cargas de HTTP(S) internos distribuyen el tráfico a grupos de instancias de middleware.
  4. Estos grupos de instancias de middleware envían el tráfico a balanceadores de cargas de TCP/UDP internos, que balancean la carga del tráfico a los clústeres de almacenamiento de datos.
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles (haz clic para ampliar)
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles

Balanceo de cargas entre regiones

Representación del balanceo de cargas entre regiones

Cuando configuras un balanceador de cargas de HTTP(S) externo en el nivel Premium, se usa una dirección IP externa global y se pueden enrutar de forma inteligente las solicitudes de los usuarios al grupo de instancias de backend o NEG más cercano, según la proximidad. Por ejemplo, si configuras grupos de instancias en Norteamérica, Europa y Asia, y los conectas al servicio de backend de un balanceador de cargas, las solicitudes de usuarios de todo el mundo se envían de manera automática a las VM más cercanas a los usuarios, en caso de que las VM pasen las verificaciones de estado y tengan capacidad suficiente (definida por el modo de balanceo). Si las VM más cercanas están en mal estado, o si el grupo de instancias más cercano está al máximo de capacidad y otro grupo no, el balanceador de cargas envía solicitudes de manera automática a la siguiente región más cercana con capacidad.


Balanceo de cargas basado en contenido

Representación del balanceo de cargas basado en contenido

El balanceo de cargas de HTTP(S) admite el balanceo de cargas basado en contenido mediante mapas de URL para seleccionar un servicio de backend según el nombre de host solicitado, la ruta de acceso de la solicitud o ambos. Por ejemplo, puedes usar un conjunto de grupos de instancias o NEG para manejar el contenido de video y otro conjunto a fin de manejar todo lo demás.

También puedes usar el balanceo de cargas de HTTP(S) en depósitos de Cloud Storage. Una vez que configures el balanceador de cargas, podrás agregarle depósitos de Cloud Storage.


Crea un balanceador de cargas combinado

Representación del balanceo de cargas basado en contenido y entre regiones

Puedes configurar un balanceador de cargas de HTTP(S) externo en el nivel Premium para proporcionar el balanceo de cargas basado en contenido y entre regiones, mediante varios servicios de backend, cada uno con grupos de instancias de backend o NEG en varias regiones. Puedes combinar y extender los casos prácticos para configurar un balanceador de cargas de HTTP(S) externo que satisfaga tus necesidades.


Configuración de ejemplo

Si deseas comenzar directamente a compilar un balanceador de cargas funcional, consulta Configura un balanceador de cargas de HTTP externo simple o Configura un balanceador de cargas de HTTPS externo simple.

Para ver un ejemplo más complejo que usa el balanceo de cargas basado en contenido y entre regiones, consulta Crea un balanceador de cargas de HTTPS.

Cómo funcionan las conexiones en el balanceo de cargas de HTTP(S)

El balanceo de cargas de HTTP(S) externo es un servicio implementado por muchos proxies llamados Google Front End (GFE). No hay un solo proxy. En el nivel Premium, la misma dirección IP externa global se anuncia desde varios puntos de presencia y el tráfico se dirige al GFE del cliente más cercano.

Según dónde se encuentren tus clientes, varios GFE pueden iniciar conexiones HTTP(S) con tus backends. Los paquetes enviados desde GFE tienen direcciones IP de origen del mismo rango que usan los verificadores de estado: 35.191.0.0/16130.211.0.0/22.

Según la configuración del servicio de backend, el protocolo que usa cada GFE para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Si es HTTP o HTTPS, la versión HTTP es HTTP 1.1. El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. GFE usa un tiempo de espera de 600 segundos para el keepalive, y no puedes configurarlo. Sin embargo, puedes configurar el tiempo de espera de la solicitud o la respuesta mediante la configuración del tiempo de espera del servicio de backend. Para obtener más información, consulta Tiempos de espera y reintentos.

Los keepalives de HTTP intentan usar la misma sesión de TCP de forma eficiente; sin embargo, no hay garantía. Aunque están muy relacionados, un tiempo de espera de keepalive de HTTP y uno de inactividad de TCP no son lo mismo.

La cantidad de conexiones HTTP y sesiones TCP varía según la cantidad de conexiones de GFE, la cantidad de clientes que se conectan a GFE, el protocolo a los backends y la ubicación de implementación de backends.

Para obtener más información, consulta Cómo funciona el balanceo de cargas de HTTP(S) en la guía de soluciones: Optimizaciones de la capacidad de las aplicaciones con el balanceo de cargas global.

Arquitectura y recursos

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

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

Los siguientes recursos definen un balanceador de cargas de HTTP(S) externo:

  • Una regla de reenvío externo especifica una dirección IP externa, un puerto y un proxy HTTP(S) de destino global. Los clientes usan la dirección IP y el puerto para conectarse al balanceador de cargas.

  • Un proxy HTTP(S) de destino global recibe una solicitud del cliente. El proxy HTTP(S) evalúa la solicitud mediante el mapa de URL para tomar decisiones de enrutamiento de tráfico. El proxy también puede autenticar las comunicaciones mediante el uso de certificados SSL.

  • Si usas el balanceo de cargas de HTTPS, el proxy HTTPS de destino usa certificados SSL globales para demostrar su identidad a los clientes. Un proxy HTTPS de destino admite hasta una cantidad determinada de certificados SSL.

  • El proxy HTTP(S) usa un mapa de URL global para determinar el enrutamiento según los atributos HTTP (como la ruta de acceso de la solicitud, las cookies o los encabezados). Según la decisión de enrutamiento, el proxy reenvía las solicitudes del cliente a servicios de backend o depósitos específicos. El mapa de URL puede especificar acciones adicionales, como el envío de redireccionamientos a los clientes.

  • Un servicio de backend o un depósito de backend distribuye solicitudes a backends en buen estado.

  • Uno o más backends deben estar conectados al servicio o al depósito de backend. Los backends pueden ser grupos de instancias, NEG o depósitos en cualquiera de las siguientes opciones de configuración:

    • Grupos de instancias administrados (zonales o regionales)
    • Grupos de instancias no administrados (zonales)
    • Grupos de extremos de red (zonales)
    • Grupos de extremos de red (Internet)
    • Depósitos de Cloud Storage

    No puedes tener grupos de instancias y NEG en el mismo servicio de backend.

  • Una verificación de estado global supervisa de manera periódica la preparación de los backends. Esto reduce el riesgo de que las solicitudes se envíen a backends que no puedan procesar la solicitud.

  • Un firewall para que los backends acepten sondeos de verificaciones de estado.

Direcciones IP de origen

Las direcciones IP de origen de los paquetes, vistas por los contenedores o instancias de máquina virtual (VM) de backend, son una dirección IP de estos rangos:

  • 35.191.0.0/16
  • 130.211.0.0/22

La dirección IP de origen para el tráfico real del balanceo de cargas es la misma que la de los rangos de IP del sondeo de verificación de estado.

Las direcciones IP de origen del tráfico, vistas por los backends, no son la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos sesiones HTTP, SSL o TCP:

  • Sesión 1, que abarca desde el cliente original hasta el balanceador de cargas (GFE):

    • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.
  • Sesión 2, que abarca desde el balanceador de cargas (GFE) hasta el contenedor o la VM de backend:

    • Dirección IP de origen: Es una dirección IP en uno de estos rangos: 35.191.0.0/16130.211.0.0/22.

      No puedes predecir la dirección real de origen.

    • Dirección IP de destino: Es la dirección IP interna del contenedor o la VM de backend en la red de nube privada virtual (VPC).

Comunicaciones del cliente con el balanceador de cargas

  • Los clientes se pueden comunicar con el balanceador de cargas mediante el protocolo HTTP 1.1 o HTTP/2.
  • Cuando se usa HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas de HTTPS.
  • No puedes inhabilitar HTTP/2 aunque realices un cambio de configuración en el balanceador de cargas. Sin embargo, puedes configurar algunos clientes para usar HTTP 1.1 en lugar de HTTP/2. Por ejemplo, con curl, usa el parámetro --http1.1.
  • Los balanceadores de cargas de HTTPS no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.

Puertos abiertos

Los balanceadores de cargas de HTTP(S) externos son balanceadores de cargas de proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre conexiones nuevas del balanceador de cargas a los backends. Google Front End (GFE) proporciona la función de proxy inverso.

Las reglas de firewall que configuras bloquean el tráfico de los GFE a los backends, pero no bloquean el tráfico entrante a los GFE.

Los balanceadores de cargas de HTTP(S) externos tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Si ejecutas un análisis de puertos o de seguridad con la dirección IP externa de un balanceador de cargas de HTTP(S) externo de Google Cloud, parecerá que hay puertos adicionales abiertos.

Esto no afecta a los balanceadores de cargas de HTTP(S) externos. Las reglas de reenvío externas, que se usan en la definición de un balanceador de cargas de HTTP(S) externo, solo pueden hacer referencia a los puertos TCP 80, 8080 y 443. El tráfico con un puerto de destino TCP diferente no se reenvía al backend del balanceador de cargas.

Componentes

Los siguientes son componentes de balanceadores de cargas HTTP(S) externos.

Direcciones y reglas de reenvío

Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino, un mapa de URL y uno o más servicios de backend.

Cada regla de reenvío proporciona una única dirección IP que se puede usar en registros DNS para tu aplicación. No se requiere el balanceo de cargas basado en DNS. Puedes especificar una dirección IP para usarla o permitir que Cloud Load Balancing te asigne una.

  • La regla de reenvío para un balanceador de cargas de HTTP solo puede hacer referencia a los puertos TCP 80 y 8080.
  • La regla de reenvío de un balanceador de cargas de HTTPS solo puede hacer referencia al puerto TCP 443.

El tipo de regla de reenvío que se necesita para los balanceadores de cargas de HTTP(S) externos depende del nivel de servicio de red en el que se encuentra el balanceador de cargas.

  • Los balanceadores de cargas de HTTP(S) externos en el nivel Premium usan reglas de reenvío externas globales.
  • Los balanceadores de cargas de HTTP(S) externos en el nivel Estándar usan reglas de reenvío externas regionales.

Proxies de destino

Los proxies de destino finalizan las conexiones HTTP(S) de los clientes. Una o más reglas de reenvío dirigen el tráfico al proxy de destino y este consulta el mapa de URL para determinar cómo dirigir el tráfico a los backends.

Los proxies configuran encabezados de solicitud o respuesta HTTP de la siguiente manera:

  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-Proto: [http | https] (solo solicitudes)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo solicitudes)
    Contiene parámetros de Cloud Trace.

Puedes crear encabezados de solicitud personalizados si los encabezados predeterminados no satisfacen tus necesidades. Para obtener más información sobre esta función, consulta Crea encabezados de solicitud definidos por el usuario.

No dependas del proxy para conservar las mayúsculas de los nombres de encabezado de solicitud o respuesta. Por ejemplo, es posible que un encabezado de respuesta Server: Apache/1.0 aparezca en el cliente como server: Apache/1.0.

Encabezado X-Forwarded-For

El balanceador de cargas agrega dos direcciones IP al encabezado X-Forwarded-For: la primera es la dirección IP del cliente que se conecta al balanceador de cargas y la segunda es la dirección IP del balanceador de cargas. Si no hay un encabezado X-Forwarded-For en la solicitud entrante, estas dos direcciones IP son el valor completo del encabezado. Si la solicitud tiene un encabezado X-Forwarded-For, otra información, como las direcciones IP registradas por los proxies en el camino hacia el balanceador de cargas, se conserva antes de las dos direcciones IP. Esto da como resultado el encabezado X-Forwarded-For que se pasa a tu instancia de backend. El balanceador de cargas no verifica ninguna dirección IP que preceda a las últimas dos direcciones IP en este encabezado.

Si ejecutas un proxy en tu instancia de backend, este suele agregar más información al encabezado X-Forwarded-For y es posible que el software deba tenerlo en cuenta. Las solicitudes de un proxy del balanceador de cargas provienen de una dirección IP en el rango 130.211.0.0/2235.191.0.0/16. Es posible que tu proxy en la instancia de backend registre esta dirección, así como la dirección IP de la instancia de backend.

Mapas de URL

Los mapas de URL definen los patrones de coincidencia para el enrutamiento basado en URL de las solicitudes a los servicios de backend apropiados. Se define un servicio predeterminado para manejar cualquier solicitud que no coincida con una regla de coincidencia de ruta o una regla de host especificadas. En algunas situaciones, como en el ejemplo de balanceo de cargas entre regiones, es posible que no definas ninguna regla de URL y solo te bases en el servicio predeterminado. Para el enrutamiento de tráfico basado en el contenido, la asignación de URL te permite dividir tu tráfico mediante el análisis de los componentes de URL a fin de enviar solicitudes a diferentes conjuntos de backends.

Certificados SSL

Si usas el balanceo de cargas basado en HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino.

Los proxies HTTPS de destino usan estos certificados para proteger las comunicaciones entre el balanceador de cargas y el cliente.

A fin de obtener más información sobre los límites y las cuotas de los certificados SSL, consulta Certificados SSL en la página de cuotas del balanceo de cargas.

Para obtener la mejor seguridad, usa la encriptación de extremo a extremo en la implementación del balanceador de cargas de HTTPS. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Para obtener información sobre cómo Google encripta el tráfico de los usuarios, consulta el informe Encriptación en tránsito en Google Cloud.

Políticas de SSL

Las políticas de SSL te permiten controlar las funciones de SSL que el balanceador de cargas de HTTPS negocia con clientes HTTPS.

De forma predeterminada, el balanceo de cargas HTTPS usa un conjunto de funciones de SSL que proporciona una buena seguridad y una amplia compatibilidad. Algunas aplicaciones requieren más control sobre los cifrados y las versiones de SSL que se usan para sus conexiones HTTPS o SSL. Puedes definir políticas de SSL para controlar las características de SSL que tu balanceador de cargas negocia y asocia una política de SSL con tu proxy HTTPS de destino.

Control geográfico sobre la ubicación en la que se finaliza TLS

El balanceador de cargas de HTTPS finaliza TLS en ubicaciones distribuidas de manera global a fin de minimizar la latencia entre los clientes y el balanceador de cargas. Si necesitas un control geográfico sobre la ubicación donde se finaliza TLS, usa el balanceo de cargas de red de Google Cloud y finaliza TLS en backends ubicados en regiones adecuadas para tus necesidades.

Servicios de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Un balanceador de cargas de HTTP(S) externo debe tener al menos un servicio de backend, pero puede tener varios.

Los balanceadores de cargas usan la información en el servicio de backend para dirigir el tráfico entrante a uno o más backends conectados.

Los backends de un servicio de backend pueden ser grupos de instancias o grupos de extremos de red (NEG), pero no una combinación de ambos. Cuando agregas un grupo de instancias de backend o NEG, debes especificar un modo de balanceo, el cual define un método para distribuir solicitudes y una capacidad objetivo. Para obtener más información, consulta Algoritmo de distribución de cargas.

El balanceo de cargas de HTTP(S) es compatible con el escalador automático de Cloud Load Balancing, que permite a los usuarios realizar ajustes de escalas automáticos en los grupos de instancias de un servicio de backend. Para obtener más información, consulta Escala en función de la capacidad de entrega del balanceo de cargas de HTTP(S).

Puedes habilitar el vaciado de conexiones en servicios de backend a fin de garantizar una interrupción mínima para tus usuarios cuando se finaliza una instancia que entrega tráfico, se quita de forma manual o la quita un escalador automático. Para obtener más información, consulta Habilita el vaciado de conexiones.

Los cambios en un servicio de backend asociado con un balanceador de cargas de HTTP(S) externo no son instantáneos. Pueden tomar varios minutos en propagarse por la red.

Comportamiento del balanceador de cargas en diferentes niveles de servicio de red

El balanceo de cargas de HTTP(S) es un servicio global cuando se usa el nivel de servicio de red Premium. Es posible que tengas más de un servicio de backend en una región y que puedas crear servicios de backend en más de una región, todos atendidos por el mismo balanceador de cargas global. El tráfico se asigna a los servicios de backend de la manera siguiente:

  1. Cuando llega una solicitud de usuario, el servicio de balanceo de cargas determina el origen aproximado de la solicitud a partir de la dirección IP de origen.
  2. El servicio de balanceo de cargas conoce las ubicaciones de las instancias que posee el servicio de backend, su capacidad general y su uso actual general.
  3. Si las instancias más cercanas al usuario tienen capacidad disponible, la solicitud se reenviará a ese conjunto de instancias.
  4. Las solicitudes entrantes a la región determinada se distribuyen de manera uniforme entre todos los servicios de backend y las instancias disponibles en esa región. Sin embargo, con cargas muy pequeñas, la distribución puede parecer desigual.
  5. Si no hay instancias en buen estado con capacidad disponible en una región determinada, el balanceador de cargas envía la solicitud a la siguiente región más cercana con capacidad disponible.

El balanceo de cargas de HTTP(S) es un servicio regional cuando se usa el nivel Estándar del servicio de red. Sus grupos de instancias de backend o NEG deben estar ubicados en la región que usa la dirección IP externa y la regla de reenvío del balanceador de cargas.

Verificaciones de estado

Cada servicio de backend también especifica qué verificación de estado se realiza en cada instancia disponible. Para que los sondeos de verificación de estado funcionen de manera correcta, debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/2235.191.0.0/16 llegue a las instancias.

Para obtener más información sobre las verificaciones de estado, consulta Crea verificaciones de estado.

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas de HTTP(S) externo, debes configurar el protocolo que usa el servicio de backend a fin de comunicarse con otros. Puedes elegir entre HTTP, HTTPS o HTTP/2. El balanceador de cargas usa solo el protocolo que especifiques. El balanceador de cargas no recurre a uno de los otros protocolos si no logra negociar una conexión al backend con el protocolo especificado.

Si usas HTTP/2, debes usar TLS. No se admite HTTP/2 sin encriptación.

Aunque no es obligatorio, se recomienda usar una verificación de estado cuyo protocolo coincida con el protocolo del servicio de backend. Por ejemplo, una verificación de estado HTTP/2 comprueba de forma más precisa la conectividad HTTP/2 con los backends.

Usa gRPC con tus aplicaciones de Google Cloud

gRPC es un framework de código abierto para llamadas de procedimiento remoto. Se basa en el estándar HTTP/2. Los casos prácticos para gRPC incluyen lo siguiente:

  • Sistemas distribuidos altamente escalables y de baja latencia
  • Desarrollo de clientes móviles que se comuniquen con un servidor en la nube
  • Diseño de protocolos nuevos que deben ser precisos, independientes del lenguaje y eficientes
  • Diseño en capas para habilitar extensiones, autenticación y registros

Para usar gRPC con tus aplicaciones de Google Cloud, debes usar las solicitudes del proxy de extremo a extremo en HTTP/2. Para hacerlo con un balanceador de cargas de HTTP(S) externo, sigue estos pasos:

  1. Configura un balanceador de cargas HTTPS.
  2. Habilita HTTP/2 como protocolo desde el balanceador de cargas hasta los backends.

El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL mediante la extensión ALPN TLS.

Es posible que el balanceador de cargas aún negocie HTTPS con algunos clientes o acepte solicitudes HTTP no seguras en un balanceador de cargas de HTTP(S) externo configurado para usar HTTP/2 entre las instancias del backend y el balanceador de cargas. El balanceador de cargas transforma esas solicitudes HTTP o HTTPS para entregar mediante el proxy las solicitudes a través de HTTP/2 en las instancias de backend.

Si quieres configurar un balanceador de cargas de HTTP(S) externo mediante HTTP/2 con Ingress de Google Kubernetes Engine o mediante gRPC y HTTP/2 con Ingress, consulta HTTP/2 para el balanceo de cargas con Ingress.

Para obtener información sobre cómo solucionar problemas con HTTP/2, consulta Soluciona problemas de los backends con HTTP/2.

Para obtener información sobre las limitaciones de HTTP/2, consulta Limitaciones de HTTP/2.

Depósitos de backend

Los depósitos de backend dirigen el tráfico entrante a los depósitos de Cloud Storage.

Como se muestra en el siguiente diagrama, puedes hacer que el balanceador de cargas envíe tráfico con una ruta de acceso de /static a un depósito de almacenamiento y todas las demás solicitudes a tus otros backends.

Distribución de tráfico a varios tipos de backends con balanceo de cargas de HTTP(S) (haz clic para ampliar)
Distribución del tráfico a varios tipos de backend con balanceo de cargas de HTTP(S) (haz clic para ampliar)

Para ver un ejemplo que muestra cómo agregar un depósito a un balanceador de cargas existente, consulta Configura un balanceador de cargas con depósitos de backend.

Reglas de firewall

Las instancias de backend deben permitir conexiones desde los rangos de verificación de estado o GFE del balanceador de cargas. Esto significa que debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/2235.191.0.0/16 llegue a tus instancias o extremos de backend. Estos rangos de direcciones IP se usan como orígenes para los paquetes de verificación de estado y para todos los paquetes con balanceo de cargas que se envían a tus backends.

Los puertos que configuras para esta regla de firewall deben permitir el tráfico a instancias o a extremos de backend:

  • Debes permitir los puertos que usa cada regla de reenvío.
  • Debes permitir los puertos que usa cada verificación de estado que se configuró para cada servicio de backend.

Las reglas de firewall se implementan a nivel de la instancia de VM, no en los proxies de Google Front End (GFE). No puedes usar las reglas de firewall de Google Cloud para evitar que el tráfico llegue al balanceador de cargas.

Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico de 130.211.0.0/2235.191.0.0/16, consulta Rangos de IP del sondeo y reglas de firewall.

Ruta de acceso de retorno

Google Cloud usa rutas especiales no definidas en tu red de VPC para las verificaciones de estado. Para obtener más información, consulta Rutas de acceso de retorno del balanceador de cargas.

Algoritmo de distribución de cargas

Cuando agregas un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo, que define un método que mide la carga de backend y una capacidad objetivo. El balanceo de cargas de HTTP(S) externo admite dos modos de balanceo:

  • RATE, para grupos de instancias o NEG, es la cantidad máxima de solicitudes (consultas) de destino por segundo (RPS, QPS). Se puede exceder la cantidad máxima de RPS/QPS si se alcanza o supera la capacidad de todos los backends.

  • UTILIZATION es el uso de backend de las VM en un grupo de instancias.

Antes de que Google Front End (GFE) envíe solicitudes a instancias de backend, GFE estima qué instancias de backend tienen capacidad para recibir solicitudes. Esta estimación de capacidad se realiza de forma proactiva, no al mismo tiempo que cuando llegan las solicitudes. Los GFE reciben información de manera periódica sobre la capacidad disponible y distribuyen las solicitudes entrantes según corresponda.

El significado de capacidad depende en parte del modo de balanceo. Para el modo RATE, es bastante simple: un GFE determina con exactitud cuántas solicitudes puede asignar por segundo. El balanceo de cargas basado en UTILIZATION es más complejo: el balanceador de cargas verifica el uso actual de las instancias y, luego, calcula una carga de consulta que cada instancia puede controlar. Esta estimación cambia a medida que cambian el uso de la instancia y los patrones de tráfico.

Ambos factores, la estimación de capacidad y la asignación proactiva, influyen en la distribución entre las instancias. Por lo tanto, Cloud Load Balancing se comporta de manera diferente a un balanceador de cargas round robin simple que distribuye las solicitudes en 50:50 exactas entre dos instancias. En cambio, el balanceo de cargas de Google Cloud intenta optimizar la selección de la instancia de backend para cada solicitud.

Para obtener más información, consulta Distribución de tráfico.

Para obtener más información sobre los modos de balanceo, consulta Modos de balanceo.

Niveles de servicio de red

Cuando un balanceador de cargas de HTTP(S) externo está en nivel Premium, las solicitudes enviadas al balanceador de cargas se entregan a grupos de instancias de backend o NEG en la región más cercana al usuario, si es que un backend en esa región tiene capacidad disponible. La capacidad disponible se configura mediante el modo de balanceo del balanceador de cargas.

Cuando un balanceador de cargas de HTTP(S) externo está en el nivel Estándar, sus grupos de instancias de backend o NEG deben ubicarse en la región que usan la dirección IP externa y la regla de reenvío del balanceador de cargas.

Regiones y zonas

A continuación, se describe lo que sucede después de seleccionar una región:

  • Cuando configuras backends en varias zonas dentro de la región, un balanceador de cargas de HTTP(S) externo intenta balancear las solicitudes de la forma más uniforme posible en las zonas, sujeto a la capacidad de la instancia de backend y la afinidad de sesión.

  • Dentro de una zona, un balanceador de cargas de HTTP(S) externo intenta balancear las solicitudes mediante el algoritmo de balanceo de cargas, sujeto a la capacidad disponible y la afinidad de sesión.

Afinidad de sesión

La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que el backend esté en buen estado y tenga la capacidad necesaria, según el modo de balanceo configurado.

El balanceo de cargas de HTTP(S) de Google Cloud ofrece tres tipos de afinidad de sesión:

  • NONE. No se configuró la afinidad de sesión para el balanceador de cargas.
  • La afinidad de IP de cliente envía solicitudes desde la misma dirección IP de cliente al mismo backend.
  • La afinidad de cookie generada establece una cookie de cliente cuando se realiza la primera solicitud y, luego, envía las solicitudes con esa cookie al mismo backend.

Cuando uses la afinidad de sesión, te recomendamos el modo de balanceo RATE, en lugar de UTILIZATION. La afinidad de sesión funciona mejor si configuras el modo de balanceo en solicitudes por segundo (RPS).

Compatibilidad de proxy con WebSocket

El balanceo de cargas de HTTP(S) tiene compatibilidad nativa con el protocolo WebSocket cuando se usa HTTP o HTTPS (no HTTP/2) como protocolo para el backend.

Los backends que usan el protocolo WebSocket a fin de comunicarse con los clientes pueden usar el balanceador de cargas de HTTP(S) externo como frontend para el escalamiento y la disponibilidad. El balanceador de cargas no necesita ninguna configuración adicional para usar un proxy en las conexiones WebSocket.

El protocolo WebSocket, que se define en RFC 6455, proporciona un canal de comunicación dúplex completo entre clientes y servidores. El canal se inicia a partir de una solicitud HTTP(S).

Cuando el balanceo de cargas de HTTP(S) reconoce una solicitud de WebSocket Upgrade de un cliente de HTTP(S) y la solicitud es seguida por una respuesta Upgrade exitosa de la instancia de backend, el balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual. Si el backend no muestra una respuesta Upgrade de éxito, el balanceador de cargas cierra la conexión.

El tiempo de espera para una conexión de WebSocket depende del tiempo de espera de respuesta configurable del balanceador de cargas, que es de 30 segundos de forma predeterminada. Este tiempo de espera se aplica a las conexiones WebSocket sin importar si están en uso. Para obtener más información sobre el tiempo de espera de respuesta y cómo configurarlo, consulta Tiempos de espera y reintentos.

Si configuraste la IP de cliente o generaste afinidad de sesión de cookies para tu balanceador de cargas de HTTP(S) externo, todas las conexiones WebSocket de un cliente se envían a la misma instancia de backend, siempre que la instancia no deje de aprobar las verificaciones de estado y tenga capacidad.

El protocolo WebSocket es compatible con Ingress.

Compatibilidad con el protocolo QUIC para el balanceo de cargas de HTTPS

El balanceo de cargas de HTTPS admite el protocolo QUIC en las conexiones entre el balanceador de cargas y los clientes. QUIC es un protocolo de capa de transporte que proporciona control de congestión similar a TCP. También proporciona seguridad equivalente a SSL/TLS para HTTP/2 con un rendimiento mejorado. QUIC permite un inicio más rápido de la conexión del cliente, resuelve el bloqueo de línea en las transmisiones multiplexadas y admite la migración de conexión cuando cambia la dirección IP de un cliente.

Afecta las conexiones entre los clientes y el balanceador de cargas, no aquellas conexiones entre el balanceador de cargas y sus backends.

La configuración de anulación QUIC del proxy de destino te permite habilitar una de las siguientes opciones:

  • Negociar QUIC para un balanceador de cargas cuando sea posible
  • Inhabilitar QUIC siempre para un balanceador de cargas

Si no especificas un valor para la configuración de anulación QUIC, se permite que Google administre cuándo se usa. Google lo habilita solo cuando la marca --quic-override en la herramienta de línea de comandos de gcloud se configura como ENABLE o cuando la marca quicOverride en la API de REST se configura como ENABLE.

Para obtener información sobre cómo inhabilitar y habilitar la compatibilidad con QUIC, consulta Proxies de destino. Puedes habilitar o inhabilitar la compatibilidad con QUIC de la siguiente manera:

QUIC tiene los siguientes requisitos de certificado SSL:

  • El atributo commonName (CN) del certificado SSL debe coincidir con un nombre de DNS que se resuelva en la dirección IP del balanceador de cargas. De lo contrario, el balanceador de cargas no entrega contenido QUIC.
  • El certificado SSL debe estar firmado por una autoridad certificada (CA) de confianza del cliente. El transporte QUIC no se puede negociar si tu balanceador de cargas usa un certificado autofirmado o uno firmado por una CA que no es de confianza del cliente.

Cómo se negocia QUIC

Cuando habilitas QUIC, el balanceador de cargas puede anunciar su capacidad QUIC a los clientes, lo que permite que los clientes que admiten QUIC intenten establecer conexiones QUIC con el balanceador de cargas HTTPS. Los clientes implementados de forma correcta siempre recurren a HTTPS o HTTP/2 cuando no pueden establecer una conexión QUIC. Debido a esta solución alternativa, habilitar o inhabilitar QUIC en el balanceador de cargas no interrumpe la capacidad de este para conectarse con los clientes.

Cuando tienes QUIC habilitado en el balanceador de cargas de HTTPS, algunas circunstancias pueden hacer que tu cliente recurra a HTTPS o HTTP/2 en lugar de negociar QUIC. Esto incluye los siguientes casos:

  • Cuando un cliente admite versiones de QUIC que no son compatibles con las que admite el balanceador de cargas de HTTPS
  • Cuando el balanceador de cargas detecta que el tráfico de UDP está bloqueado o sometido a un límite de frecuencia tal que impediría el funcionamiento de QUIC
  • Si QUIC está inhabilitado de manera temporal para los balanceadores de cargas de HTTPS en respuesta a errores, vulnerabilidades u otros problemas

Cuando una conexión recurre a HTTPS o HTTP/2 debido a estas circunstancias, no consideramos esto como una falla del balanceador de cargas.

Antes de habilitar QUIC, asegúrate de que los comportamientos antes descritos sean aceptables para tus cargas de trabajo.

Certificados SSL

Debes hacer referencia a uno o más certificados SSL en el proxy HTTPS de destino.

Los proxies HTTPS de destino usan estos certificados para proteger las comunicaciones entre Google Front End (GFE) y el cliente. Estos pueden ser certificados SSL autoadministrados o administrados por Google.

A fin de obtener más información sobre los límites y las cuotas de los certificados SSL, consulta Certificados SSL en la página de cuotas del balanceo de cargas.

Para obtener la mejor seguridad, también puedes encriptar el tráfico de los GFE a tus backends. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Para obtener información sobre cómo Google encripta el tráfico de los usuarios, consulta el informe Encriptación en tránsito en Google Cloud.

Compatibilidad con TLS

De forma predeterminada, un proxy HTTPS de destino solo acepta TLS 1.0, 1.1, 1.2 y 1.3 cuando finaliza las solicitudes SSL del cliente. Puedes usar las políticas de SSL para cambiar este comportamiento predeterminado y controlar cómo el balanceador de cargas negocia SSL con los clientes.

Cuando el balanceador de cargas usa HTTPS como un protocolo de servicio de backend, puede negociar TLS 1.0, 1.1 o 1.2 con el backend.

Tiempos de espera y reintentos

El balanceo de cargas de HTTP(S) tiene dos tipos distintos de tiempos de espera:
  • Un tiempo de espera de respuesta HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera de respuesta es de 30 segundos. Considera aumentar este tiempo en cualquiera de estas circunstancias:

    • Si esperas que un backend tarde más en mostrar respuestas HTTP
    • Si la conexión se actualiza a un WebSocket (solo balanceo de cargas de HTTP o HTTPS)

    Para el tráfico WebSocket enviado mediante un balanceador de cargas, el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión WebSocket puede permanecer abierta, ya sea que esté activa o no. Para obtener más información, consulta Configuración del servicio de backend.

  • Un tiempo de espera de sesión TCP, cuyo valor se fija en 10 minutos (600 segundos). Este tiempo de espera de la sesión a veces se denomina tiempo de espera keepalive o inactivo, y su valor no se puede configurar mediante la modificación del servicio de backend. Debes configurar el software del servidor web que usan tus backends para que su tiempo de espera keepalive sea superior a 600 segundos a fin de evitar que el backend cierre de forma prematura las conexiones. Este tiempo de espera no se aplica a WebSockets.

En esta tabla, se ilustran los cambios necesarios a fin de modificar los tiempos de espera de keepalive para el software del servidor web común:

Software del servidor web Parámetro Parámetro de configuración predeterminado Configuración recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

El balanceador de cargas reintenta las solicitudes GET que fallaron en ciertas circunstancias, como cuando se agota el tiempo de espera de respuesta. No se reintentan solicitudes POST con errores. Solo se puede reintentar dos veces. Las solicitudes recuperadas solo generan una entrada de registro para la respuesta final.

Para obtener más información, consulta Registro y supervisión del balanceo de cargas de HTTP(S).

Solicitud ilegal y manejo de respuestas

El balanceador de cargas de HTTP(S) externo impide que las solicitudes de clientes y las respuestas de backend lleguen al backend o al cliente, respectivamente, por varios motivos. Algunas razones son solo para el cumplimiento de HTTP/1.1 y otras para evitar que se pasen datos inesperados a los backends o desde ellos. No se puede inhabilitar ninguna de las verificaciones.

El balanceador de cargas bloquea lo siguiente para el cumplimiento de HTTP/1.1:

  • No se puede analizar la primera línea de la solicitud.
  • A un encabezado le falta el delimitador :.
  • Los encabezados o la primera línea contienen caracteres no válidos.
  • La longitud del contenido no es un número válido o hay varios encabezados de longitud del contenido.
  • Hay varias claves de codificación de transferencia o hay valores de codificación de transferencia no reconocidos.
  • Hay un cuerpo no fragmentado y no se especifica la longitud del contenido.
  • Los fragmentos del cuerpo no se pueden analizar. Este es el único caso en el que algunos datos llegan al backend. El balanceador de cargas cierra las conexiones con el cliente y el backend cuando recibe un fragmento no analizable.

El balanceador de cargas bloquea la solicitud si se cumple alguna de las siguientes condiciones:

El balanceador de cargas bloquea la respuesta del backend si se cumple alguna de las siguientes condiciones:

  • El tamaño total de los encabezados de respuesta supera el límite del tamaño máximo del encabezado de respuesta del balanceo de cargas de HTTP(S) externo.
  • La versión HTTP es desconocida.

Especificaciones y limitaciones

  • El balanceo de cargas de HTTP(S) admite la respuesta HTTP/1.1 100 Continue.

Limitaciones de HTTP/2

  • En comparación con el protocolo HTTP(S), el uso de HTTP/2 entre el balanceador de cargas y la instancia puede requerir una cantidad significativamente mayor de conexiones TCP a la instancia. La agrupación de conexiones, una optimización que reduce la cantidad de conexiones cuando se usa el protocolo HTTP(S), no está disponible con HTTP/2 por el momento.
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no es compatible con lo siguiente:
    • Extracción del servidor
    • WebSockets

Restricción sobre el uso de Cloud CDN

  • No puedes habilitar Identity-Aware Proxy ni Cloud CDN con el mismo servicio de backend. Si intentas hacerlo, el proceso de configuración fallará.

Qué sigue