Implantando aplicativos web (Tornado) do Python em vários servidores

3

Temos 4 servidores de aplicativos e um balanceamento de carga executando um de nossos aplicativos Python. Cada um dos servidores de aplicativos tem 32 núcleos de hyper-threaded, portanto, os guias de implantação do Tornado sugerem que executemos 64 threads em cada. Também usamos o supervisord para gerenciar todos os threads. Isso funciona bem, o problema que temos é quando temos que implantar atualizações, o processo atual para implantar novos aplicativos é um script de shell que faz o seguinte:

  • Fazer checkout da filial / deploy do nosso repositório GIT
  • (Algumas coisas não relacionadas a fazer com CDNs)
  • SCP os arquivos para cada um dos 4 servidores
  • Reinicie o supervisord (para que os aplicativos carreguem o novo código)

Isso é terrivelmente ineficiente e leva cerca de 20 segundos no total. Reiniciar os encadeamentos de tornado individuais leva cerca de um segundo, mas o problema é que, se fizermos grandes alterações, o balanceador de carga alternará entre o antigo e o novo aplicativo, dependendo de qual estágio da reinicialização o encadeamento escolhido (no total, há 256 instâncias possíveis com as quais o balanceador de carga pode se conectar), portanto, precisamos desativar o site por 30 segundos, às vezes por mais tempo, para obter as versões corretas do aplicativo.

Existe alguma maneira melhor de fazer isso? Já ouvi falar do Fabric e de algumas outras ferramentas que podem ser usadas, mas elas são mais eficazes do que a forma como estamos fazendo no momento? Idealmente, precisamos reiniciar todos os threads para a nova versão em 5 segundos, mesmo que isso envolva derrubar o site temporariamente.

Informação (se é útil);
Todos os servidores são RHEL 5.5, o balanceador de carga é um Barracuda 640.

    
por Smudge 26.05.2011 / 19:31

2 respostas

4

A seqüência a seguir deve fazer o que você deseja se puder usar a API do balanceador de carga seu script de implantação:

  1. Remover uma parte dos seus tópicos do balanceador de carga
  2. Atualize esses tópicos
  3. Remover os encadeamentos ativos do balanceador de carga
  4. Adicione os encadeamentos atualizados novamente ao balanceador de carga
  5. Atualizar tópicos restantes
  6. Adicione os tópicos restantes de volta ao balanceador de carga

Dessa forma, você só tem uma versão do código ao vivo a qualquer momento, e o tempo de inatividade deve ser limitado a um segundo ou dois, enquanto as alterações do pool têm efeito.

Disclaimer: Isso pressupõe que o balanceador de carga Barracuda tenha uma API decente. Não consegui encontrar a documentação com um Google rápido. O padrão deve funcionar. Eu fiz isso em uma situação semelhante com um balanceador de carga da Cisco.

    
por 01.06.2011 / 17:47
3

Por que não fazer isso ...

Faça o deploy em 2 pedaços. Você conecta em 2 nós derrubando o servidor web. O balanceador de carga irá parar de enviar tráfego para lá. Implemente o aplicativo. Crie servidores da Web enquanto desativa os outros 2 aplicativos de implantação .. inicie servidores.

Esse método não é muito escalável.

Opções 2

O seu LB faz sessões complicadas? Se assim for, ligue-os uma hora antes de implantar. Derrube 1 servidor de cada vez para fazer as implementações. Quando certos usuários verão o novo site e outros verão o antigo.

Então você faz um de cada vez ... então remova as sessões fixas do LB.

    
por 01.06.2011 / 17:48