Gestión de tráfico avanzada
Hay las siguientes características de gestión de tráfico avanzado disponibles en IBM Cloud® Application Load Balancer for VPC (ALB).
Número máximo de conexiones
Utilice la configuración max connections para limitar el número máximo de conexiones simultáneas para un puerto virtual frontal determinado. Si no configura un valor, el sistema utiliza el valor predeterminado de 2000 conexiones simultáneas. La cantidad máxima de conexiones simultáneas para un puerto virtual frontal determinado, o de todo el sistema en todos los puertos virtuales frontales, es de 15000.
Retención de sesión
De forma predeterminada, un ALB reenvía solicitudes recibidas a un servidor de fondo basándose en el método de equilibrio de carga configurado. Puede activar la fijación de sesión para asegurarse de que un cliente permanece conectado al mismo servidor back-end durante toda la sesión. Para obtener más información, consulte Actualización de la persistencia de sesión para equilibradores de carga de aplicaciones.
IP de origen
Con esta opción, un ALB crea la afinidad entre un cliente y un servidor de fondo en función de la IP de origen de la conexión. Por ejemplo, si activa la persistencia de sesión de tipo IP de origen para el puerto 80 ( HTTP ), cualquier intento de conexión posterior a HTTP desde el mismo cliente IP de origen será persistente en el mismo servidor back-end. Esta característica está disponible para todos los protocolos soportados (HTTP, HTTPS y TCP).
Keep alive de HTTP
HTTP keep alive permite a un cliente HTTP y a un servidor intercambiar varios pares de solicitud-respuesta a través de una única conexión TCP. Esto reduce la latencia de las solicitudes posteriores, minimiza la sobrecarga de la
red y mejora la eficiencia general.
Application Load Balancer for VPC es compatible con HTTP keep alive cuando está activado tanto en el servidor de consumo como en el servidor back-end. Si el consumidor admite HTTP keep alive, el ALB mantiene la conexión
abierta para múltiples solicitudes. El ALB intenta reutilizar las conexiones HTTP del lado del servidor a los servidores back-end para minimizar la sobrecarga de conexión.
HTTP keep alive Debe estar habilitado tanto en el lado del cliente como en el lado del servidor back-end de la conexión.
Keep alive de TCP
TCP keep alive es un mecanismo de la capa de transporte ( TCP ) que ayuda a mantener las conexiones inactivas de larga duración enviando periódicamente pequeños paquetes (llamados sondas keep alive) para comprobar si el otro extremo
de la conexión sigue accesible.
Application Load Balancer for VPC ayuda a TCP a mantenerse con vida. Con esta configuración, el equilibrador de carga envía paquetes TCP keep alive tanto a los servidores consumidores como a los servidores back-end cada 5 segundos.
Después de que una conexión permanezca inactiva durante un tiempo especificado (llamado tiempo de mantenimiento de vida, a menudo 2 horas por defecto), la pila TCP envía una sonda de mantenimiento de vida. Si el par responde, la conexión permanece
activa. Si no hay respuesta después de varias pruebas, la conexión se considera muerta y se cierra.
TCP keep alive es un paquete a nivel de socket sin datos que se envía al peer para notificarle que el host está vivo. Como tal, solo se ve en la capa de red, y no a nivel de aplicación. Este valor también ayuda a evitar la desconexión de las conexiones TCP por parte de un cortafuegos o un proxy intermedio que pueda tener políticas que descarten las conexiones después de un determinado periodo de inactividad.
Tiempos de espera de conexión
Un ALB utiliza los siguientes valores de tiempo de espera. Actualmente, sólo se pueden personalizar los valores de tiempo de espera de inactividad del lado del cliente y del lado del servidor en la tabla siguiente.
| Nombre | Descripción | Tiempo de espera |
|---|---|---|
| Intento de conexión de lado del servidor | Ventana de tiempo máximo que puede utilizar el equilibrador de carga para establecer una conexión TCP con el servidor de fondo. Si el intento de conexión no es satisfactorio, el equilibrador de carga lo intenta con el siguiente servidor disponible siguiendo el método de equilibrio de carga configurado. | 5 segundos |
| Conexión inactiva de lado del cliente | El tiempo máximo de inactividad, transcurrido el cual el equilibrador de carga desactiva la conexión del lado del cliente si este no ha podido cerrar correctamente la conexión. | 50 segundos (valor predeterminado) a 2 horas |
| Conexión inactiva de lado del servidor | El tiempo máximo de inactividad (con configuración de protocolo de fondo de TCP), transcurrido el cual el equilibrador de carga cierra la conexión del lado del servidor. Si el equilibrador de carga, con la configuración de protocolo back-end de HTTP, no puede recibir una respuesta a la solicitud HTTP enviada en la ventana de tiempo de espera de inactividad, devuelve un mensaje de error al cliente final. | 50 segundos (valor predeterminado) a 2 horas |
Conservación de la dirección IP del cliente final (solo HTTP/HTTPS)
Application Load Balancer for VPC funciona como proxy inverso, finalizando el tráfico entrante desde el cliente. El equilibrador de carga establece una conexión independiente a la instancia de servidor de fondo mediante el uso de una dirección
IP propia. Para las conexiones HTTP con servidores de fondo (con conexiones HTTP o HTTPS frontales), el equilibrador de carga conserva la dirección IP del cliente original incluyéndola en la cabecera HTTP X-Forwarded-For. Para
las conexiones TCP, la información de la IP de cliente original no se conserva.
Conservación del protocolo del cliente final (solo HTTP/HTTPS)
Un ALB conserva el protocolo original que utiliza el cliente para las conexiones HTTP y HTTPS frontales incluyéndolo en la cabecera HTTP X-Forwarded-Proto. Esto no se aplica al protocolo TCP, ya que un ALB no examina el tráfico
de Capa 7 cuando se utiliza el protocolo TCP.
Habilitación de la imposición de un equilibrador de carga privado
La imposición de un equilibrador de carga privado impide que se creen equilibradores de carga públicos. Esto garantiza que solo los clientes que no son de Internet, o los clientes de su entorno de red, puedan acceder a los equilibradores de carga. Cuando se ha habilitado, se indica una restricción en su cuenta para evitar que se creen IP flotantes en todos los ALB.
Para implementar la aplicación del equilibrador de carga privado, abra un caso de soporte de IBM y haga referencia a la necesidad de modificar la cuenta para restringir la creación de IP flotantes. Después de que IBM procese el cambio, ya no podrá crear equilibradores de carga públicos.
La imposición de un equilibrador de carga privado se aplica a todas las regiones cuando están habilitadas.
Soporte de HTTP/2 para clientes que se conectan a escuchas HTTPS
Application Load Balancer for VPC utiliza el protocolo de negociación de la capa de aplicación (ALPN) para negociar con los clientes que se conectan a los receptores de HTTPS, y admite los protocolos HTTP y HTTPS.
El protocolo HTTP/2 todavía no está soportado en las agrupaciones de fondo. No obstante, se da soporte a los protocolos HTTP y HTTPS.
Compresión (solo HTTP/HTTPS)
La compresión HTTP/HTTPS permite comprimir con gzip los datos transmitidos a los usuarios.
Para comprimir los datos transmitidos con un ALB, la cabecera de la petición ha de contener Accept-Encoding: gzip y su tipo MIME tiene que ser text/html, text/plain o text/xml.
Habilitación del protocolo de proxy
Puede habilitar el protocolo de proxy para escuchas TCP, HTTP y HTTPS y agrupaciones de fondo. Los casos de uso son los siguientes.
Caso de uso 1: El cliente se conecta al equilibrador de carga directamente
Si el ALB recibe tráfico de un cliente directamente, la habilitación del protocolo de proxy para la agrupación de programas de fondo de dicho escucha configura el equilibrador de carga de modo que conecte la cabecera de protocolo de proxy a los paquetes TCP que se están enviando a esa agrupación de programas de fondo.
Todos los miembros del programa de fondo de esa agrupación deben dar soporte al protocolo de proxy para que la vía de acceso de datos funcione. Puede elegir la versión de la cabecera de protocolo de proxy (versión 1 o versión 2) cuando habilite este valor. Este valor está inhabilitado de forma predeterminada si no se especifica. Con este valor, los servidores de fondo pueden obtener la información de IP de cliente y de puerto que el equilibrador de carga establece en la cabecera de protocolo de proxy.
Caso de uso 2: El cliente se conecta a un proxy o cadena de proxies, que luego se conecta al equilibrador de carga mediante el protocolo de proxy
Si el Application Load Balancer for VPC está recibiendo tráfico de un proxy (o de una cadena de proxies) que utiliza el protocolo de proxy, el escucha debe tener habilitado el protocolo de proxy para poder analizar la información de cliente de origen que está contenida en las cabeceras del protocolo de proxy. Este valor está inhabilitado de forma predeterminada si no se especifica. Puesto que el equilibrador de carga puede detectar la versión de la cabecera del protocolo de proxy y analizarla correctamente, no es necesario especificar la versión del protocolo de proxy que se está utilizando para enviar tráfico al ALB.
Cuando el protocolo de proxy está habilitado para un escucha frontal, se espera que todo el tráfico que llega a ese puerto frontal sea tráfico de protocolo de proxy. Si alguna de las conexiones no contiene las cabeceras del protocolo de proxy adecuadas, no se establecerán. Para reenviar esta información de cliente a la agrupación de servidores de fondo, debe habilitar el protocolo de proxy para la agrupación. Al igual que en el Caso de uso 1, debe seleccionar la versión 1 o la versión 2 en función de la versión del protocolo de proxy que deban utilizar los servidores de fondo según su configuración. También puede optar por no reenviar esta información de cliente a los servidores de fondo si no son capaces de procesar esta información, y esta información se descarta en el equilibrador de carga.