Conceptos del balanceo de cargas de HTTP(S) interno

El balanceo de cargas HTTP(S) interno es un balanceador de cargas regional de la capa 7 basado en proxies que te permite ejecutar y escalar tus servicios detrás de una dirección IP de balanceo de cargas privada que solo es accesible en la región del balanceador de cargas en tu red de VPC.

Descripción general

El balanceo de cargas HTTP(S) interno de Google Cloud Platform (GCP) es un balanceador de cargas HTTP y HTTPS privado basado en proxies. Distribuye el tráfico a extremos o instancias de VM de backend en los grupos de extremos de red (NEG) en una sola región de tu red de VPC mediante una asignación de URL. Solo se puede acceder al balanceador de cargas en la región elegida de tu red de VPC en una dirección IP privada interna (RFC 1918).

Para obtener información sobre cómo se compara un balanceador de cargas HTTP(S) interno con otros balanceadores de carga de GCP, consulta la página sobre cómo elegir un balanceador de cargas.

Tipos de tráfico, esquema y alcance

Un balanceador de cargas HTTP(S) interno se define mediante una única asignación de URL, que hace referencia a uno o más servicios de backend con un esquema de balanceo de cargas interno administrado. Cada servicio de backend admite uno de los siguientes protocolos: HTTP, HTTPS o HTTP/2; también, admite extremos o VM de backend en un grupo de extremos de red (NEG).

Debido a que el alcance de un balanceador de cargas HTTP(S) interno es regional en vez de global, los clientes y los extremos o VM de backend deben estar todos en la misma región. Los clientes en las redes conectadas pueden usar un túnel de Cloud VPN o un archivo adjunto de Cloud Interconnect en la misma región que el balanceador de cargas.

Diagrama de alto nivel

Cada balanceador de cargas HTTP(S) interno tiene una dirección IP privada que actúa como frontend en sus extremos o VM de backend. Tus solicitudes de clientes internos permanecen internas en tu red y región.

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)

Casos prácticos

Servicios

Un caso práctico común es el tráfico de balanceo de cargas entre los servicios. En este ejemplo, el usuario obtiene contenido de video y de imagen con la misma URL base, mygcpservice.internal, con las rutas de acceso /video y /images.

La asignación de URL del balanceador de cargas HTTP(S) interno dirige el tráfico a un servicio de backend para video y a otro servicio de backend para images, según el comparador de rutas de acceso de la asignación de URL.

En el siguiente diagrama, se muestran tres servicios: video, imágenes y pagos.

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

Servicios web de 3 niveles

Puedes usar el balanceo de cargas HTTP(S) interno para admitir los servicios web tradicionales de 3 niveles.

En el siguiente diagrama, tres tipos diferentes de balanceadores de cargas escalan los tres niveles:

En el diagrama, se muestran tres tipos de balanceadores de cargas de GCP.

  1. Un balanceador de cargas HTTP(S) global externo distribuye el tráfico de Internet a un conjunto de grupos de instancias de frontend web en varias regiones.
  2. Estos frontends envían el tráfico HTTP(S) a un conjunto de balanceadores de cargas HTTP(S) regionales internos (el asunto de esta descripción general).
  3. Los balanceadores de cargas HTTP(S) distribuyen el tráfico a los grupos de instancias de middleware.
  4. Estas instancias de middleware envían el tráfico a los balanceadores de cargas 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 aplicaciones de varios niveles (haz clic para ampliar)
Enrutamiento basado en la capa 7 para niveles internos en aplicaciones de varios niveles (haz clic para ampliar)

Arquitectura y recursos

El frontend de un balanceador de cargas HTTP(S) interno consta de una dirección IP interna, una regla de reenvío interno y un proxy HTTP o HTTPS de destino. Una sola asignación de URL dirige el tráfico a uno o más servicios de backend con un esquema de balanceo de cargas INTERNAL_MANAGED. Cada servicio de backend distribuye el tráfico entre sus grupos de instancias de backend o NEG de backend de acuerdo con un modo de balanceo configurable. Dentro de cada grupo de instancias o NEG, el tráfico se distribuye aún más de acuerdo con una política configurable. Consulta la distribución de tráfico para obtener detalles sobre cómo funciona esto.

Cada servicio de backend es regional. Todos los backends en un servicio de backend determinado deben ser grupos de instancias o NEG. Se admiten grupos de instancias no administrados, administrados zonales y administrados regionales.

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

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

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

  • Una regla de reenvío interno regional, que especifica la dirección IP interna y el puerto del balanceador de cargas (la dirección usada cuando los clientes se conectan al balanceador de cargas) y el proxy de destino al que reenvía cada solicitud entrante.

  • Un proxy HTTP(S) de destino regional recibe una solicitud del usuario y la reenvía a la asignación de URL. Un proxy HTTPS de destino admite una cantidad documentada de certificados SSL que permiten que el proxy demuestre su identidad a los clientes.

  • Una asignación de URL regional analiza la URL de una solicitud y reenvía las solicitudes a servicios de backend específicos en función del host y la ruta de acceso de la URL de la solicitud.

  • Un servicio de backend regional distribuye las solicitudes a backends en buen estado (grupos de instancias o NEG).

  • Una verificación de estado regional informa la preparación de tus backends.

  • Uno o más backends deben estar conectados al servicio de backend. Los backends pueden ser de los siguientes tipos:

    • Grupos de instancias administrados (zonales o regionales)
    • Grupos de instancias no administrados (zonales)
    • Grupos de extremos de red (zonales)

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

  • Una subred de solo proxy cuyas direcciones IP sean el origen del tráfico del balanceador de cargas a tus backends. Debes crear una subred de solo proxy en cada región de una red de 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.

  • Un firewall para que tus backends acepten conexiones desde la subred de solo proxy. Consulta el ejemplo en esta página sobre la configuración de reglas de firewall.

Limitaciones

  • El balanceo de cargas HTTP(S) interno opera a nivel regional. No hay garantía de que una solicitud de un cliente en una zona de la región se envíe a un backend que se encuentre en la misma zona que el cliente. La afinidad de sesión no reduce la comunicación entre zonas.

  • El balanceo de cargas HTTP(S) interno no es compatible con las siguientes características:

  • El balanceo de cargas HTTP(S) interno no es compatible con el intercambio de tráfico entre redes de VPC. Si necesitas un balanceador de cargas interno que sea compatible con el intercambio de tráfico entre redes de VPC, usa el balanceo de cargas TCP/UDP interno.

  • El protocolo WebSocket no es compatible.

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

Próximos pasos