Clúster activo/pasivo desde un front-end Apache (modo hot-standby)

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

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.101 y servidor de aplicaciones Jboss.
  • Nodo 2 back-end pasivo (hot-standby) con IP 192.168.2.102 y servidor de aplicaciones Jboss.
Front-end Apache y back-end con 2 nodos de Jboss en clúster

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.