O Load Balancer fornece saídas de usuário que acionam scripts que podem
ser customizados. É possível criar os scripts para executar ações automatizadas, como alertar
um Administrador quando servidores forem marcados como inativos pelo gerenciador
ou apenas registrar o evento da falha.
Os scripts de amostra que podem ser customizados estão no diretório
install_root/servers/samples. Para executar os arquivos, você deve movê-los para o diretório
install_root/servers/bin
e remover a extensão de arquivo ″sample″. Os seguintes scripts de amostra
são fornecidos:
- serverDown — um servidor é marcado como inativo pelo gerenciador.
- serverUp — um servidor é marcado como ativo pelo gerenciador.
- managerAlert — todos os servidores são marcados como inativos para uma porta específica.
- managerClear — pelo menos um servidor está agora ativo depois que todos foram marcados
como inativos para uma determinada porta.
Se todos os servidores em um cluster forem marcados como inativos (seja pelo usuário ou pelos
orientadores), o managerAlert (se configurado) é iniciado e o Load Balancer tentará rotear o
tráfego para os servidores usando uma técnica round-robin. O script serverDown
não é iniciado quando o último servidor no cluster é detectado como off-line.
Por padrão, o Load Balancer tenta continuar roteando o tráfego no caso de um servidor
entrar on-line novamente e responder ao pedido. Se o Load Balancer em vez de
eliminar todo o tráfego, o cliente não receberia nenhuma resposta. Quando o Load Balancer
detecta que o primeiro servidor de um cluster está novamente on-line, o script
managerClear (se configurado) é iniciado, mas o script serverUp (se configurado) não é
executado até que um servidor adicional seja colocado on-line novamente.
A seguir há algumas considerações para usar os scripts serverUp e serverDown:
- Se você definir o ciclo do gerenciador menor que 25% do tempo do servidor,
relatórios falsos de servidores ativo e inativo podem ocorrer. Por padrão, o gerenciador é executado a cada
2 segundos, mas o orientador é executado a cada 7 segundos. Portanto, o gerenciador
espera novas informações do orientador dentro de 4 ciclos. Entretanto, remover essa restrição (ou seja,
definir o ciclo do gerenciador para maior que 25% do tempo do orientador) diminui
significativamente o desempenho porque vários orientadores podem orientar em um
único servidor.
- Quando um servidor ficar inativo, o script serverDown é iniciado. Entretanto, se você emitir
um comando serverUp, assume-se que o servidor esteja ativo até que o gerenciador
obtenha novas informações a partir do ciclo do orientador. Se o servidor ainda estiver inativo,
o script serverDown será executado novamente.