Descripción general del balanceo de cargas de proxy TCP

El balanceo de cargas de proxy TCP de Google Cloud te permite usar una sola dirección IP para todos los usuarios en todo el mundo. El balanceador de cargas de proxy TCP enruta el tráfico de manera automática a los backends que están más cerca del usuario.

El balanceo de cargas global requiere que uses el nivel Premium de los niveles de servicio de red, que es el nivel predeterminado. De lo contrario, el balanceo de cargas se maneja a nivel regional.

El balanceo de cargas de proxy TCP se diseñó para el tráfico TCP en puertos conocidos específicos, como el puerto 25 para el protocolo para transferencia simple de correo (SMTP). Para obtener más información, consulta Especificaciones de puertos. Para el tráfico de clientes encriptado en estos mismos puertos, usa Balanceo de cargas de proxy SSL.

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

El balanceo de cargas de proxy TCP admite direcciones IPv6 y direcciones IPv4 para el tráfico del cliente. Las solicitudes de cliente IPv6 se finalizan en la capa de balanceo de cargas y, luego, se redirigen mediante proxies IPv4 a tus backends.

Cuando usas el balanceo de cargas de proxy TCP, puedes finalizar las sesiones TCP del cliente en la capa de balanceo de cargas y reenviar el tráfico a tus instancias de backend mediante TCP o SSL.

Ejemplo de balanceo de cargas de proxy TCP

Mediante el uso del balanceo de cargas del proxy TCP, el tráfico que llega a través de una conexión TCP finaliza en la capa de balanceo de cargas y, luego, se dirige al backend más cercano disponible.

En este ejemplo, las conexiones del tráfico de los usuarios de Seúl y Boston se finalizan en la capa de balanceo de cargas. Estas conexiones están etiquetadas como 1a2a. Se establecen conexiones independientes desde el balanceador de cargas hasta las instancias de backend seleccionadas. Estas conexiones están etiquetadas como 1b2b.

Cloud Load Balancing con finalización TCP (haz clic para ampliar)
Cloud Load Balancing con finalización TCP (haz clic para ampliar)

El balanceo de cargas de proxy TCP se puede configurar como un servicio de balanceo de cargas global. Con esta configuración, puedes implementar tus backends en varias regiones. El balanceo de cargas global dirige de manera automática el tráfico a la región más cercana al usuario. Si una región está al máximo de capacidad, el balanceador de cargas dirige de forma automática las conexiones nuevas a otra región con capacidad disponible. Las conexiones de los usuarios existentes permanecen en la región actual.

Ventajas

A continuación, se presentan algunos beneficios de usar el balanceo de cargas de proxy TCP:

  • Enrutamiento inteligente: El balanceador de cargas puede enrutar solicitudes a ubicaciones de backend en las que haya capacidad. Por el contrario, un balanceador de cargas L3/L4 debe dirigirse a backends regionales sin considerar la capacidad. El uso del enrutamiento inteligente permite el aprovisionamiento en N + 1 o N + 2 en lugar de x * N.

  • Parches de seguridad. Si surgen vulnerabilidades en la pila TCP, Cloud Load Balancing aplica parches al balanceador de cargas de manera automática para proteger tus instancias.

  • Compatibilidad con el balanceo de cargas de proxy TCP para los siguientes puertos: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 y 9300.

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

El balanceo de cargas del proxy TCP es un servicio global con nivel Premium. Solo puedes tener un servicio de backend y este puede tener backends en varias regiones (en el nivel Premium). El tráfico se asigna a los backends como se indica a continuación:

  1. Cuando un cliente envía una solicitud, 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 determina las ubicaciones de los backends que son propiedad del servicio de backend, su capacidad general y su uso actual general.
  3. Si las instancias de backend más cercanas al usuario tienen capacidad disponible, la solicitud se reenvía al conjunto de backends más cercano.
  4. Las solicitudes entrantes a la región determinada se distribuyen de manera uniforme entre todas las instancias de backend disponibles en esa región. Sin embargo, en cargas muy pequeñas, la distribución puede parecer desigual.
  5. Si no hay instancias de backend 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.

En el nivel Estándar, el balanceo de cargas del proxy TCP es un servicio regional. Todos sus backends deben estar ubicados en la región que usa la dirección IP externa y la regla de reenvío del balanceador de cargas.

Componentes

Los siguientes son componentes de balanceadores de cargas de proxy TCP.

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 en un proxy de destino y uno o más servicios de backend.

Cada regla de reenvío proporciona una sola dirección IP que puedes usar en los registros DNS de tu aplicación. No se requiere balanceo de cargas basado en DNS. Puedes reservar una dirección IP estática para usar o permitir que Cloud Load Balancing te asigne una. Te recomendamos reservar una dirección IP estática; de lo contrario, deberás actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que borres una regla de reenvío y crees una nueva.

Proxies objetivos

El balanceo de cargas de proxy TCP finaliza las conexiones TCP desde el cliente y crea conexiones nuevas con los backends. De forma predeterminada, la dirección IP de cliente original y la información del puerto no se conservan. Puedes conservar esta información con el protocolo PROXY. Los proxies de destino enrutan las solicitudes entrantes directamente a los servicios de backend.

Servicios de backend

Los servicios de backend dirigen el tráfico entrante a uno o más backends conectados. Cada backend está compuesto por un grupo de instancias o un grupo de extremos de red y metadatos de capacidad de entrega. La capacidad de entrega del backend se puede basar en CPU o en solicitudes por segundo (RPS).

Cada balanceador de cargas del proxy TCP tiene un solo recurso de servicio de backend. Los cambios en el servicio de backend no son instantáneos. Los cambios pueden llevar varios minutos en propagarse a Google Front End (GFE).

Cada servicio de backend especifica las verificaciones de estado que se realizarán para los backends disponibles.

Para garantizar interrupciones mínimas a tus usuarios, puedes habilitar el desvío de la conexión en los servicios de backend. Estas interrupciones pueden ocurrir cuando un backend se finaliza, se quita de forma manual o un escalador automático lo quita. Si deseas obtener más información sobre el uso del vaciado de conexiones para minimizar las interrupciones del servicio, consulta Habilita el vaciado de conexiones.

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas de proxy TCP, configuras el protocolo que usa el servicio de backend a fin de comunicarse con estos. Puedes elegir SSLTCP. El balanceador de cargas solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo.

Reglas de firewall

Las instancias de backend deben permitir conexiones desde los rangos de verificación de estado/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/22 y 35.191.0.0/16 llegue a tus instancias o extremos de backend. Estos rangos de direcciones IP se usan como fuentes 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 de sondeo y reglas de firewall.

Direcciones IP de origen

Las direcciones IP de origen de los paquetes, vistas por cada contenedor o instancia 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/16 o 130.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).

Modo de balanceo

Cuando agregas un backend al servicio de backend, debes configurar un modo de balanceo de cargas.

Para el balanceo de cargas de proxy TCP, el modo de balanceo puede ser connection o backend utilization.

Si el modo de balanceo de cargas es connection, la carga se distribuye según la cantidad de conexiones simultáneas que pueda controlar el backend. También debes especificar exactamente uno de los siguientes parámetros: maxConnections (excepto para los grupos de instancias regionales administrados), maxConnectionsPerInstance o maxConnectionsPerEndpoint.

Si el modo de balanceo de cargas es backend utilization, la carga se distribuye según la utilización de instancias en un grupo de instancias.

Para obtener información sobre cómo comparar los tipos de balanceador de cargas y los modos de balanceo admitidos, consulta Métodos de balanceo de cargas.

Afinidad de sesión

Afinidad de sesión envía todas las solicitudes del mismo cliente al mismo backend si este se encuentra en buen estado y tiene capacidad.

El balanceo de cargas de proxy TCP ofrece afinidad de IP de cliente, que reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend.

Puertos abiertos

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

Los GFE tienen varios puertos abiertos para admitir otros balanceadores de cargas de Google Cloud y otros servicios de Google. Si ejecutas un escaneo de puertos o de seguridad sobre la dirección IP externa de tu balanceador de cargas, parecerá que hay puertos adicionales abiertos.

Esto no afecta a los balanceadores de cargas de proxy TCP. Las reglas de reenvío externas, que se usan en la definición de un balanceador de cargas de proxy SSL, solo pueden hacer referencia a un conjunto específico de puertos. El tráfico con un puerto de destino TCP diferente no se reenvía al backend del balanceador de cargas. Para verificar que no se procese el tráfico a otros puertos, puedes tratar de abrir una sesión TCP a un puerto no autorizado. El GFE que controla tu solicitud cierra la conexión con un paquete de restablecimiento de TCP (RST).

Qué sigue