Load Balancer proporciona salidas de usuario que desencadenan scripts que se pueden personalizar.
Puede crear los scripts para realizar acciones automatizadas, como avisar a un administrador cuando el gestor ha
marcado que los servidores están inactivos o simplemente anotar el suceso de la anomalía.
Los scripts de ejemplo, que puede personalizar, están en el directorio
install_root/servers/samples. Para ejecutar los archivos, debe trasladarlos al directorio
raíz_instalación/servers/bin
y eliminar la extensión de archivo ″sample″. Se proporcionan los siguientes scripts de ejemplo:
- serverDown: el gestor marca un servidor como inactivo.
- serverUp: el gestor marca un servidor como activo.
- managerAlert: todos los servidores de un determinado puerto se marcan como inactivos.
- managerClear: como mínimo hay un servidor activo, después de que todos se marcaran como
inactivos para un puerto determinado.
Si todos los servidores de un clúster se marcan como inactivos (por el usuario o por los asesores), se inicia managerAlert (si está configurado) y Load Balancer intenta direccionar el tráfico a los servidores utilizando una técnica de turno rotativo. El script serverDown no se inicia cuando se ha detectado que el último servidor del clúster está fuera de línea.
Load Balancer se ha diseñado de modo que intente continuar direccionando el tráfico en caso de que un servidor vuelva a estar en línea y responda a la petición. Si en lugar de esto, Load Balancer dejara de direccionar todo el tráfico, el cliente no recibiría ninguna respuesta. Cuando Load Balancer detecta que el primer servidor de un clúster vuelve a estar en línea, se inicia el script managerClear (si está configurado), aunque el script serverUp (si está configurado) no se ejecutará hasta que no vuelva a estar en línea un servidor adicional.
A continuación se muestran algunos factores que deben tenerse en cuenta cuando se utilizan los scripts serverUp y serverDown:
- Si define el ciclo del gestor en un valor inferior al 25% del tiempo del asesor, pueden generarse falsos informes de servidores activos o inactivos. De forma predeterminada, el gestor se ejecuta cada 2 segundos, pero el asesor se ejecuta cada 7
segundos. Por lo tanto, el gestor espera nueva información de asesor cada 4 ciclos. Sin embargo, si se elimina esta restricción (es decir, definir el ciclo de gestor de forma que tenga un valor superior al 25% del tiempo del asesor) se disminuirá de forma significativa el rendimiento porque varios asesores pueden asesorar sobre un solo servidor.
- Cuando un servidor pasa a estar inactivo, se inicia el script serverDown. Sin embargo, si emite un mandato
serverUp, se da por supuesto que el servidor está activo hasta que el gestor obtiene nueva información del ciclo del asesor. Si el servidor sigue estando inactivo, el script serverDown se ejecutará de nuevo.