Uso de HAProxy para el equilibrio de carga en la nube E2E:permanencia y seguridad de la sesión

En la primera parte de este blog, configuramos HAProxy en un nodo de Virtual Load Balancer en E2E Cloud. También configuramos HAProxy para enrutar las solicitudes a los servidores web de back-end mediante una política de rotación.

En esta segunda y última parte de este blog, analizaremos un par de ajustes de configuración avanzados que la mayoría de los sitios web requieren:permanencia en la sesión y acceso seguro al sitio web mediante SSL. Pero antes de hacerlo, mostraremos cómo nuestra única instancia de HAProxy puede atender a un sitio web grande con muchas aplicaciones web, en virtud de las ACL. Mientras lo hacemos, mencionaremos algunas opciones de configuración adicionales, como la política de rotación ponderada, y concluiremos con sugerencias sobre otras consideraciones importantes para una implementación de producción.

Configuración del balanceador de carga para varias aplicaciones web

Muchos sitios web grandes constan de varios grupos de servidores web, cada uno de los cuales aloja una aplicación web diferente. Por ejemplo, puede haber un sitio web con contenido principal junto con un sitio web para la diversión y el entretenimiento. HAProxy es capaz de enrutar solicitudes al clúster correcto en función de patrones de URL y Listas de control de acceso (ACL).

Para ilustrar esta capacidad, primero creamos dos nuevos nodos de servidor web en E2E Cloud, denominados 'webserver3' y 'webserver4'. Como de costumbre, instalamos el servidor web Apache y los paquetes PHP en los dos nuevos nodos. Luego implementamos una segunda aplicación PHP en la URL '/fun/films.php' en solo estos dos nodos recién agregados . (La segunda aplicación usa persistencia de sesión y su funcionalidad se explicará en la siguiente sección).

Entonces, tenemos los siguientes nodos (4 servidores web y un balanceador de carga) visibles en nuestro Tablero:

Figura 1:servidores web para varias aplicaciones web

Entonces, HAProxy debe enrutar las solicitudes de los clientes para la URL '/fun/films.php' a uno de los nodos 'webserver3' y 'webserver4' únicamente, o de lo contrario, la solicitud no podrá ser atendida. Para cumplir con este requisito, modificamos la configuración de HAProxy (/etc/haproxy/haproxy.cfg) y creamos un backend más (llamado 'películas') que consta solo de los dos nuevos nodos del servidor web. Esto se suma al backend existente llamado 'sitio'.

Figura 2:Configuración de back-end para una nueva aplicación

Luego, en la configuración de interfaz existente, introducimos una ACL como se muestra a continuación. Lo que esto significa es que cualquier ruta de URL que comience con '/fun' se enrutará al backend denominado 'films', mientras que, de forma predeterminada, todas las demás solicitudes llegarán al backend (preexistente) denominado 'site' (que consta de nodos 'websrv1' y 'websrv2' solamente).

Figura 3:configuración de interfaz con ACL

Figura 4:Equilibrio de carga de HAProxy con ACL

Parámetros de configuración avanzada

Política Round Robin ponderada :Al realizar modificaciones para las ACL, introdujimos un peso a cada servidor. En producción, diferentes servidores pueden tener diferente potencia informática, por lo que el uso de ponderaciones permite a HAProxy enrutar más solicitudes a servidores más potentes. (En nuestro caso, todos los nodos del servidor web son similares y todos los pesos son iguales, pero podemos usar esto como plantilla y modificarlo en un escenario diferente).

Conexiones máximas por servidor :En segundo lugar, también hicimos uso del parámetro 'maxconn' a nivel del servidor backend , para que cada servidor pueda limitar el número de conexiones a lo que sea razonable para su potencia de procesamiento. El 'maxconn' global debe ser mayor que la suma total de los valores de nivel de servidor de este parámetro (dejando algo de espacio para que se agreguen más nodos de servidor web para la escalabilidad).

Permanencia en la sesión

La nueva aplicación PHP utiliza sesiones PHP. Cada vez que un cliente accede a esta aplicación, proporciona el nombre de una película favorita (a través de un parámetro HTTP GET llamado 'fav'), que se agrega a la sesión de PHP. El servidor responde con la lista de películas favoritas (únicas para cada cliente) reunidas hasta el momento.

2. inicio_sesión();
3. $favorito =$_GET[‘favorito’];
4. if ( isset( $_SESSION[‘favoritos’] ) ) {
5.     $_SESSION[‘favoritos’] .=‘ , ‘;
6.     $_SESSION[‘favoritos’] .=$fav;
7. } más {
8.     $_SESSION[‘favoritos’] =$fav;
10. $msg ='Mis películas favoritas:'. $_SESSION['favoritos'];
11. ?>
13.    
14.        
15.    
16.    
17.        
18.         echo $mensaje;
19.         ?>
20.    

Las sesiones de PHP pueden ser locales para una instancia de servidor web (a menos que la persistencia de la sesión o la replicación estén habilitadas). Por lo tanto, si el mismo cliente se enruta aleatoriamente a diferentes instancias de servidor web back-end en diferentes momentos, cuando realiza una serie de solicitudes, sus datos de sesión pueden volverse impredecibles. Pero un cliente puede verse obligado a 'pegarse ‘ a una sola instancia de servidor web dentro de la duración de una sesión.

Una forma de configurar esto en HAProxy es introducir el parámetro 'appsession' en la configuración de backend relevante ('películas', en nuestro caso). Diferentes tipos de aplicaciones utilizan diferentes Cookies HTTP para la gestión de sesiones. En el caso de las aplicaciones PHP, esta Cookie se denomina 'PHPSESSID'. Al configurar 'appsession', HAProxy asocia un único servidor web con cada uno 'PHPSESSID' (donde se creó esta sesión) y enruta las solicitudes repetidas de los clientes que contienen la misma ID de sesión a ese mismo servidor web, siempre que esté en funcionamiento o se haya agotado el tiempo de espera de la sesión .

1. appsession PHPSESSID len 32 timeout 1h

Por supuesto, si ese servidor web deja de estar disponible por algún motivo, HAProxy debería tener la libertad de enrutar las solicitudes con esa misma identificación de sesión a una instancia de servidor activo diferente. Esto se puede garantizar agregando la opción 'reenvío' en la sección 'predeterminados' del archivo de configuración de HAProxy.

1. opción de reenvío

Pruebas

Ahora podemos probar tanto las ACL como la adherencia de la sesión. Podemos seguir los registros de HAProxy en el nodo del balanceador de carga:

1. cola -f /var/log/haproxy.log

También rastreamos los registros de acceso al servidor web en cada uno de los nodos 'webserver3' y 'webserver4'.

1. cola -f /var/log/apache2/access.log

Desde dos máquinas cliente diferentes, enviamos solicitudes a la siguiente URL desde un navegador:http:///fun/films.php?fav=afilm

En cada solicitud podemos establecer un valor diferente para el parámetro de consulta llamado 'fav'.

Desde el primer cliente, enviamos las siguientes solicitudes sucesivas:

1. http:///fun/films.php?fav=avengers
2. http:///fun/films.php?fav=jurassicworld

La ventana del navegador en el primer cliente mostrará:

Figura 5:Una sesión de cliente

Desde el segundo cliente, enviamos las siguientes solicitudes sucesivas:

1. http:///fun/films.php?fav=race3
2. http:///fun/films.php?fav=gold

La ventana del navegador en el segundo cliente mostrará:

Figura 6:Otra sesión de cliente

De la respuesta que se muestra en el navegador de cada cliente, está claro que las sesiones se mantienen correctamente en cada caso. En Firefox, desde la consola web, también podemos inspeccionar los valores de PHPSESSID.

Podemos hacer las siguientes dos observaciones de los registros de HAProxy y del servidor web:

1. Estas solicitudes con el patrón de URL '/diversión' se enrutan solo al backend llamado 'películas' (políticas de ACL)
2. Una solicitud de la misma dirección IP del cliente llega al mismo nodo del servidor web (permanencia de la sesión)

Figura 7:registros de HAProxy con sesiones pegajosas

Figura 8:registros de acceso en el nodo webserver3 con sesiones pegajosas

Figura 9:registros de acceso en el nodo webserver4 con sesiones pegajosas

Seguridad:Terminación SSL

Una última pero crucial configuración que nos gusta abordar está relacionada con la seguridad. Los servidores web Apache se pueden configurar para admitir HTTPS, pero cuando tenemos HAProxy instalado en la interfaz, las solicitudes de los clientes llegarán primero al balanceador de carga.

Por lo tanto, se recomienda que configuremos HAProxy para admitir HTTPS. Este es un proceso de cuatro pasos:

1. Obtenga un certificado SSL para nuestro sitio web. Con fines experimentales, creamos un certificado autofirmado llamado haproxy.pem usando openssl
2. Asocie la interfaz a un puerto HTTPS (por defecto 443) y asigne el certificado SSL a esta interfaz
3. Habilite HAProxy para redirigir las solicitudes de los clientes enviadas a través de HTTP al puerto HTTPS
4. Agregue o configure los encabezados requeridos para la solicitud HTTP en cada uno de los backends configurados

Los primeros tres pasos anteriores se implementan en el nivel de interfaz. (Hemos cambiado el nombre de nuestra interfaz como 'alltraffic' en lugar de 'httptraffic'.)

Figura 10:Configuración de interfaz para SSL

El cuarto paso anterior se implementa en cada backend:

Figura 11:Configuración de servidor para SSL

Por lo general, los encabezados X-Forward-Port y X-Forward-Proto ayudan a la aplicación a crear la URL correctamente cuando las solicitudes HTTP y HTTPS son posibles.

Terminar SSL en el nodo del balanceador de carga crea cierta sobrecarga de procesamiento en este nodo (en comparación con la retransmisión de la solicitud cifrada a los backends). Hay un parámetro relacionado con el algoritmo de cifrado subyacente que se está utilizando. Un valor más alto aumenta la sobrecarga de procesamiento en el nodo HAProxy. Se puede configurar en la sección 'global' de la configuración de HAProxy:

1. tune.ssl.default-dh-parámetro 2048

Entonces, las solicitudes cifradas con SSL terminan en el balanceador de carga, que enruta las solicitudes HTTP sin cifrar a los servidores web backend.

Figura 12:Terminación SSL

Configuración del cortafuegos

Necesitamos abrir el puerto 443 en el nodo del balanceador de carga virtual (ejecutándose en CentOS), ejecutando el comando:

1. iptables -A INPUT -i eth0 -p tcp –dport 443 -m state –state NUEVO, ESTABLECIDO -j ACEPTAR
2. systemctl reiniciar iptables

Pruebas

Ahora tratamos de acceder a nuestra aplicación PHP Greeter a través de un navegador (Firefox), señalando el HTTP no seguro URL:

http:///greet.php

Incluso entonces, Firefox nos pedirá que agreguemos una excepción de seguridad, indicando que el cliente está siendo reenviado a la URL HTTPS segura . Esto también se indica en la barra de direcciones del propio navegador.

Figura 13:Acceso a la aplicación web a través de SSL

Creación de imágenes y supervisión de máquinas

Consejo :Se ha invertido mucho esfuerzo en configurar la instancia del balanceador de carga virtual. Se puede guardar una imagen de máquina de este nodo para que se puedan crear instancias de balanceador de carga similares en el futuro usándola como plantilla. En E2E Cloud, esto se puede lograr cerrando primero el nodo HAProxy y luego guardando una imagen de este nodo desde el Tablero.

Figura 14:Guardar la imagen de la máquina HAProxy

Figura 15:Creación de una imagen de máquina desde el nodo HAProxy

Opcionalmente, también se puede guardar una imagen de máquina de las instancias del servidor web.

Monitoreo usando Zabbix :El nodo HAProxy, como cualquier otro nodo virtual en E2E Cloud, se puede monitorear usando Zabbix. Deberíamos aprovechar esta capacidad.

Figura 16:Supervisión del estado del equilibrador de carga

Conclusión y próximos pasos

E2E Cloud ofrece nodos de Equilibrador de carga virtual para configurar el equilibrio de carga mediante HAProxy. En estos dos blogs, revisamos cómo se puede configurar una instalación de HAProxy en E2E Cloud para admitir el balanceo de carga por turnos para sitios web simples y grandes de múltiples aplicaciones con permanencia en la sesión y acceso seguro a través de HTTPS.

Terminaremos este blog tomando nota de algunas otras consideraciones para una implementación de producción:

• En primer lugar, el nodo del Equilibrador de carga virtual (y, opcionalmente, los nodos del servidor web) deben vincularse a un dominio utilizando la configuración de DNS adecuada
• En consecuencia, el certificado SSL para el acceso seguro a la instancia de HAProxy debe estar vinculado al mismo dominio
• Por último, el equilibrador de carga no debe convertirse en un único punto de falla. Por lo tanto, se puede recomendar una implementación activa-pasiva de HAProxy.