Buscando las distintas formas que hay de montar un clúster activo-pasivo con nodos de Jboss, encontré una interesante solución que podría implementarse a nivel de front-end. Siempre que nuestro frontal web fuera un servidor web Apache bastaría con utilizar una funcionalidad del módulo mod_proxy llamada hot-standby.
Echando un vistazo a la documentación oficial, conceptualmente la implementación quedaría bastante clara. En el apartado BalancerMember parameters está la parte que me interesa, opción H para el parámetro status:
Parámetros para un worker balanceador
Visto esto y como las cosas se entienden mejor con ejemplos prácticos, supongamos el siguiente escenario:
- Servidor front-end Apache. Al balanceador de clúster lo he llamado
clusterjboss. - Nodo 1 back-end activo con IP
192.168.2.101y servidor de aplicaciones Jboss. - Nodo 2 back-end pasivo (hot-standby) con IP
192.168.2.102y servidor de aplicaciones Jboss.
Front-end Apache y back-end con 2 nodos de Jboss en clúster
La configuración en el servidor Apache (normalmente en el fichero httpd.conf) quedaría:
ProxyPass "/" "balancer://clusterjboss/"
<Proxy "balancer://hotcluster">
# Nodo 1 activo
BalancerMember "ajp://192.168.2.101:8009" retry=30
# Nodo 2 pasivo en modo hot-standby
BalancerMember "ajp://192.168.2.102:8009" status=+H
ProxySet lbmethod=bytraffic
</Proxy>
El nodo 192.168.2.102 se declara como pasivo (hot-standby, con el parámetro status=+H) por lo que no se le envía ninguna petición hasta que el nodo activo 192.168.2.101 haya caído. Apache realiza comprobaciones cada 30 segundos (retry=30) del primer nodo para determinar su estado. Poniéndonos en el caso de que el servidor Jboss del nodo 192.168.2.101 tuviera un error crítico y dejara de prestar servicio, tras verificar que está caído Apache comenzaría a dirigir todo el tráfico a 192.168.2.102 evitando así una pérdida de servicio para el usuario. Una vez que el nodo 1 vuelva a estar operativo, las peticiones dejarían de enviarse al nodo 2 pasivo y volverían al activo.
Se pueden diseñar arquitecturas de clúster más complejas siempre y cuando nuestros recursos lo permitan. Por ejemplo, con 3 nodos activos y 1 en pasivo:
ProxyPass "/" "balancer://clusterjboss/"
<Proxy "balancer://hotcluster">
# Nodos 1,2 y 3 activos
BalancerMember "ajp://192.168.2.101:8009" retry=30
BalancerMember "ajp://192.168.2.102:8009" retry=30
BalancerMember "ajp://192.168.2.103:8009" retry=30
# Nodo 4 pasivo en modo hot-standby
BalancerMember "ajp://192.168.2.104:8009" status=+H
ProxySet lbmethod=bytraffic
</Proxy>
En este caso las peticiones se balancean entre los 3 nodos activos y en caso de que los 3 estuvieran caídos (lo cual sería una demostración empírica de la Ley de Murphy) Apache comenzaría a redirigir el tráfico al nodo 4 pasivo.
La ventaja de implementar hot-standy desde un front-end Apache es que lo mismo sirve para Jboss como para Weblogic, Tomcat, WebSphere Application Server o cualquier servicio que se preste desde un back-end. Apache simplemente se encarga en este sentido de funcionar como proxy con los servidores que hay detrás y de realizar una comprobación en forma de ping a esos back-end para saber si están operativos.
Por otro lado, es una solución de alta disponibilidad más sencilla de implementar que otras como por ejemplo Pacemaker. Eso sí, sacrificamos flexibilidad y robustez por sencillez, ya que Pacemaker ofrece un abanico de posibilidades y gestión de recursos en clúster mayor y mucho más eficiente que la configuración activo/pasivo hot-standby de Apache.