Tiempo atrás escribí una entrada en la que hablaba sobre balancear nuestros servicios de Horizon Connection Server y App Volumes con HAProxy y Keepalived sobre una VM Photon OS.
En el post de hoy, quiero dar una vuelta de tuerca más a esta arquitectura para monitorizar de forma más exhaustiva si los servicios por detrás del balanceador (HAproxy) están o no realmente disponibles. En el post original hacíamos una comprobación muy básica del estado de los connection servers o app volumes manager y solo comprobábamos si el servidor web contestaba o no.
Esto nos puede llevar a una situación no deseada, ya que desde el Horizon Administrator es posible deshabilitar un Connection Server de manera administrativa. El servidor web sigue levantado y, por lo tanto, HAProxy le sigue enviando peticiones, con el consiguiente “deny” del connection server.
Para evitar este escenario he averiguado que podemos monitorizar “connnection-server-url/favicon.ico”. Si el servidor está OK y aceptando sesiones devolverá un código 200, en cambio, si está deshabilitado administrativamente, devolverá un código 503
Con HAProxy podemos verificar esto y declarar un servidor de backend en “down” si el código devuelto es diferente a 200. Para eso, necesitaremos modificar el fichero de configuración /etc/haproxy/haproxy.cfg
y ajustar la configuración:
1 |
|
Añadiremos la línea option httpchk HEAD /favicon.ico y también añadiremos el check-ssl verify none en las 2 líneas de los server.
Tendremos que reiniciar el servicio de ambos servidores con el comando systemctl restart haproxy
Una vez arrancado con la nueva config, en el portal de estadísticas veremos cómo declara el servidor en DOWN porque ha recibido un 503
Al habilitar el conection server de nuevo, el servidor se recuperará y volverá a aceptar peticiones:
Aparte de esto, VMware también recomienda una frecuencia de chequeo que no sobrecargue en exceso los servidores. VMware recomienda una frecuencia de 30 segundos entre chequeos y 91 segundos de timeout (3 check + 1 segundo). Así pues, la configuración quedaria de la siguiente manera:
1 |
|
Añadiremos las líneas timeout client 91s tanto en el bloque de frontend como en backend.
Para acabar, una última optimización que me parece interesante es cambiar el modo de balanceo de “source” a “leastconn”, de esta manera, nos aseguraremos que HAProxy enviará la petición al connection server menos sobrecargado.
Con esta configuración, hay que asegurarnos que la persistencia del source esté habilitado para que un usuario no vaya cambiando de connection server tras una desconexión, ya que eso le obligaría a iniciar sesión de nuevo. En HAProxy, podemos crear una tabla IP y decirle que mantenga las conexiones como “fijas” según la dirección IP.
Al configurar esta tabla, se debe especificar un timeout que se recomienda sea 1/3 de la configuración que tengamos en el Horizon Administrator. En mi caso, lo tengo configurado a 600 minutos, por lo tanto, 200 en la config de HAProxy.
1 |
|
Añadiremos las líneas tbalance leastconn, stick-table type ip size 1m expire 200m y stick on src
Cómo resumen final, el bloque de nuestros connection servers en la configuración del HAProxy debería quedar similar a esto:
1 |
|
Y hasta aquí el post de hoy.
Espero sea de utilidad.
Un saludo!
Miquel.