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.
Persistencia de sesiones
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 habilitar la persistencia de sesiones para asegurarse de que un cliente permanece conectado al mismo servidor de fondo durante toda una sesión.
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. Como ejemplo, si habilita la persistencia de sesión de tipo IP de origen para el puerto 80 (HTTP), cualquier intento de conexión HTTP posterior desde el mismo cliente IP de origen es persistente en el mismo servidor de fondo. Esta característica está disponible para todos los protocolos soportados (HTTP, HTTPS y TCP).
Keep alive de HTTP
Application Load Balancer for VPC admite el modo HTTP keep alive cuando esté habilitado tanto en el cliente como en los servidores de fondo. El equilibrador de carga intenta reutilizar las conexiones HTTP del lado del servidor para
mejorar la eficiencia de conexión y reducir la latencia.
Keep alive de TCP
Application Load Balancer for VPC da soporte a TCP keep alive. Con este valor, el equilibrador de carga envía paquetes mantener activo TCP a servidores de cliente y de fondo cada 5 segundos.
Se trata de un paquete de nivel de socket sin datos que se envía al igual para notificarle que el host está activo. 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 ALPN (Application-Layer Protocol Negotiation) para negociar con clientes que se conectan a escuchas HTTPS, y da soporte a HTTP/1.1 y HTTP/2. Si el cliente que se conecta al ALB utiliza HTTP/2, el ALB también utiliza HTTP/2 como su protocolo preferido y procesa la solicitud a la agrupación de fondo. De lo contrario, se elige HTTP/1.1 de forma predeterminada.
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.