Tengo tres instancias de Tomcat ejecutándose detrás de HAProxy. Cuando implemento cambios en mis aplicaciones web, me gustaría realizar una implementación continua (es decir, rebotar un Tomcat a la vez) para que los usuarios no vean ningún tiempo de inactividad.
¿Cómo hago esto? Veo que una instancia en ejecución de haproxy se puede reconfigurar en caliente (lo cual es bueno para agregar o eliminar nuevos servidores de grupo), pero ¿cómo reacciona HAProxy cuando uno de sus servidores de destino está temporalmente inactivo?
Si hay una solución mejor que HAProxy, estaría dispuesto a considerarla también.
¡Gracias!
Respuesta1
Envié un correo electrónico a Willy Tarreau y recibí las siguientes opciones:
Puede utilizar comandos socat o reconfiguración en caliente en el servidor de estadísticas para establecer el peso de su servidor de destino en 0. Esto evitará que se equilibren nuevas sesiones con ese servidor, pero no afectará las conexiones existentes.
Puede configurar la opción http-check enable-on-404 en combinación con la "opción httpcheck /myurl" y luego hacer que sus servidores de destino respondan a /myurl de modo que envíen un estado 200 si todo está bien, un 404 si el servidor debería dejar de recibir nuevas solicitudes y un 500 si el servidor no debe recibir nada (es decir, cuando esté listo para rebotar el servidor). haproxy volverá a verificar el servidor en el intervalo especificado en la línea de su servidor.
Respuesta2
Siendo así HAProxy no admite la eliminación sin reconfiguración según @Ernesto Mülleren surespuesta, Le proporcionaré una alternativa ya que también solicitó otros escenarios.
yo sueloLVS, que es una de mis soluciones favoritas para el equilibrio de carga, ya que puede usarse para más que HTTP.
Con LVS, puede utilizarlo ipvsadmpara agregar y eliminar servidores manualmente. Un ejemplo de eliminación es el siguiente comando:
/sbin/ipvsadm -e -t VIP:443 -r SERVERIP:443 -g -w WEIGHT
En lugar de agregar y eliminar manualmente interactuando con LVS, a menudo prefiero usar la requestopción conldirectord. ldirector es un demonio que sondea y administra su configuración de ipvs. Puede especificar un archivo con una ruta URI usando ese parámetro. Durante la implementación, elimina el archivo y espera a que deje de acceder al servidor. En ese punto, puede implementar el código sin afectar a los clientes de producción.
Respuesta3
Mucho de esto depende de si está realizando alguna gestión de sesión/estado en los Tomcats. Si el reinicio destruye la sesión de un usuario, entonces rodar no evita el impacto del usuario (podría evitar que vea un 500, pero no tener que iniciar su sesión de nuevo). Si no estás utilizando sesiones fijas, probablemente no tengas que preocuparte por eso.
HAproxy y otros balanceadores de carga tienen formas de intentar determinar con bastante rapidez si el servidor detrás está activo o inactivo y redirigir el tráfico en función de eso (la "verificación de estado" en HAProxy). Sin embargo, les resulta imposible hacerlo perfectamente. Con Tomcat, no sólo hay "arriba" y "abajo"; hay "arriba, como responder en el puerto, pero las cosas aún no están listas". Por lo tanto, no debe confiar en el LB para evitar por completo el impacto del usuario; incluso con una buena verificación de estado, habrá un intervalo en el que llevará tráfico a un nodo defectuoso.
Lo que hacemos con una implementación continua es sacar activamente el servidor del balanceador de carga, luego modificar/reiniciar el nodo, esperar hasta que pase una prueba/monitor automatizado, luego volver a colocarlo y luego pasar al siguiente servidor. Esto es más fácil con un equilibrador de carga que tiene una API a la que puede llamar de forma remota (como, desde un script) para deshabilitar un servidor; nuestro antiguo Netscaler hacía esto, pero HAProxy no. Con HAProxy tienes que editar la configuración y reiniciar (triste) o puedes cambiar la verificación de estado para que puedas manipularla, como tal vez verifique un archivo mágico al que le cambias el nombre cuando quieres que omita ese nodo. Debe esperar a que se active la verificación de estado y el nodo salga del clúster, pero entonces debería estar bien.
me encontréesta publicaciónque tiene una solución relacionada con iptables para ese problema...