Rolling implementa com Tomcats atrás de uma instância HAProxy

Question

Eu tenho três instâncias do Tomcat sendo executadas atrás de um HAProxy. Quando eu implementei as alterações nos meus aplicativos da web, eu gostaria de fazer uma implantação contínua (por exemplo, rejeitar um Tomcat por vez) para que os usuários não vissem qualquer tempo de inatividade.

Como faço isso? Vejo que uma instância em execução do haproxy pode ser reconfigurada a quente (o que é bom para adicionar ou remover novos servidores de pool), mas como o HAProxy reage quando um dos servidores de destino está temporariamente inativo?

Se houver uma solução melhor do que o HAProxy, eu estaria disposto a ver isso também.

Obrigado!

    

Answer 1

Enviei um e-mail para Willy Tarreau e recebi as seguintes opções:

1. Você pode usar os comandos hot reconfiguration ou socat no servidor de estatísticas para definir o peso de seu servidor de destino como 0. Isso evitará que novas sessões sejam balanceadas para esse servidor, mas não afetará as conexões existentes. / p>

2. Você pode definir a opção http-check disable-on-404 em combinação com a "opção httpcheck / myurl" e fazer seus servidores de destino responderem a / myurl de forma que enviem um status 200 se tudo estiver bem, um 404 se o servidor deve parar de receber novos pedidos, e um 500 se o servidor não receber nada (isto é, quando você estiver pronto para devolver o servidor). O haproxy irá verificar novamente no servidor no intervalo especificado em sua linha de servidores.

Answer 2

Sendo que o HAProxy não suporta remoção sem reconfiguração de acordo com @ Ernest Muller em seu answer , vou lhe fornecer uma alternativa como você pediu outra cenários também.

Eu uso LVS , que é um dos meus favoritos soluções para balanceamento de carga, como ele pode ser usado por mais de HTTP.

Com o LVS, você pode usar ipvsadm para adicionar e remover manualmente os servidores. Um exemplo de remoção é o seguinte comando:

/sbin/ipvsadm -e -t VIP:443 -r SERVERIP:443 -g -w WEIGHT

Ao contrário de adicionar e remover manualmente interagindo com o LVS, geralmente prefiro usar a opção request com ldirectord . O ldirector é um daemon que pesquisa e gerencia sua configuração de ipvs. Você pode especificar um arquivo com um caminho de URI usando esse parâmetro. Durante o rollout, você remove o arquivo e aguarda o servidor parar de ser acessado. Nesse ponto, você pode implantar o código sem afetar os clientes de produção.

    

Answer 3

Muito disso depende de você estar fazendo algum gerenciamento de sessão / estado nos Tomcats. Se a sessão de um usuário for destruída pela reinicialização, a rolagem não impedirá o impacto do usuário (isso pode impedi-lo de ver um 500, mas não de ter que iniciar sua sessão novamente). Se você não estiver usando sessões persistentes, provavelmente não precisa se preocupar com isso.

O HAproxy e outros balanceadores de carga têm maneiras de tentar determinar rapidamente se o servidor por trás dele está ativo ou não e redirecionar o tráfego com base nisso (a "verificação de integridade" no HAProxy). É impossível para eles fazer isso perfeitamente, no entanto. Com o Tomcat, não há apenas "up" e "down"; há "para cima, como em responder na porta, mas as coisas ainda não estão prontas". Portanto, você não deve confiar no LB para impedir completamente o impacto do usuário - mesmo com uma boa verificação de integridade, haverá um intervalo em que você está recebendo tráfego para um nó ruim.

O que fazemos com uma implementação contínua é tirar o servidor do balanceador de carga, mexer / reiniciar o nó, esperar até que ele passe por um teste / monitor automatizado, depois colocá-lo de volta e, em seguida, passar para o próximo servidor. Isso é mais fácil com um balanceador de carga que tem uma API que você pode chamar remotamente (como em um script) para desabilitar um servidor - nosso antigo Netscaler fez isso, mas o HAProxy não. Com HAProxy você tem que editar a configuração e reiniciar (triste) ou você pode alterar a verificação de saúde para onde você pode manipulá-lo - como, talvez, ele verifica um arquivo mágico que você renomeia quando você quer omitir esse nó. Você tem que esperar a verificação de saúde disparar e o nó sair do cluster, mas você deve estar bem.

Eu encontrei esta postagem que tem uma solução relacionada ao iptables para essa postagem problema ...