desenv-web-rp.com

Rolando atualizações em um farm de servidores Web?

Grandes sites (Amazon, Facebook, Yahoo etc.) não agendam tempo de inatividade para atualizações. Geralmente eles são feitos "ao vivo" e rolados progressivamente pelo farm de servidores. Eles também têm grande infraestrutura e equipes para gerenciar isso.

Os sites menores geralmente colocam o site inteiro offline para atualizar a estrutura do banco de dados e atualizar o código em execução nos servidores web. O tempo de inatividade pode ser muito mínimo, mas ainda é uma interrupção para os clientes.

Como você saltou para as atualizações sem interrupção? Quais são os requisitos mínimos para fazer isso? O que podemos fazer para criar aplicativos que tornam isso possível desde o início?

5
Gareth Farrington

Quais são os requisitos mínimos para fazer isso?

Depois de ter pelo menos dois servidores atrás de um balanceador de carga, você pode remover sequencialmente um servidor do cluster, atualizá-lo e adicioná-lo novamente ao cluster para concluir a atualização (no que diz respeito ao visitante).

O que podemos fazer para criar aplicativos que tornam isso possível desde o início?

Projete seu aplicativo com requisitos de balanceamento de carga em mente.

5
danlefree

0 tempo de inatividade é o equivalente do servidor da Web "o design deve ser exatamente igual em todos os navegadores". O tempo de inatividade programado está ok, basta agendá-lo e colocar um aviso estático. A menos que isso realmente lhe custe toneladas de hits ou dinheiro, o que, como um pequeno site, não seria definição. Se você não quiser que ninguém o veja no dia 4 de julho (ou no Dia de Ação de Graças ou em outro momento oportuno), a menos que seu site seja o resultado de pesquisa número 1 do Google para "Tratamento de queima de fogos de artifício" ou "letras de Francis Scott Key", você será bem.

Fazer isso desde o início geralmente leva a um risco muito maior: o excesso de engenharia.

0
Thomas

Sempre há algum motivo para o tempo de inatividade programado, mas pode ser minimizado.

Dependendo da sua infraestrutura, estratégias diferentes podem minimizar o tempo de inatividade. Atualizações antigas antigas não devem exigir tempo de inatividade.

Em vários sites controlados por PHP que eu gerencio, mantenho cópias lado a lado da base de código, digamos versão 1.0, 1.1 e 1.2:

/sites/site-1-0-0
/sites/site-1-1-0
/sites/site-1-2-0

E, em seguida, crie links simbólicos que o servidor da web possa usar:

/sites/production --> /sites/site-1-1-0
/sites/staging    --> /sites/site-1-2-0

Dessa forma, eu posso preparar meu código no servidor de produção para verificações de sanidade de última hora e, quando quero entrar no ar, eu apenas:

$ rm /sites/production; ln -s /sites/site-1-2-0 /sites/production

O servidor da web usa os links simbólicos na especificação DocumentRoot, portanto, a transição é praticamente instantânea.

Obviamente, existem truques aqui. É preciso garantir que os dados externos sejam armazenados em algum lugar, er, externo. Você não deseja gravar arquivos temporários ou armazenar conteúdo gerado pelo usuário no sistema de arquivos nos diretórios site-x-y-z.

Outra alternativa, se você tiver vários servidores, é fazer a transição via roteamento. Alguns fornecedores de VPS (o Linode vem à mente) facilitam a captura de duas máquinas virtuais e a troca de seus endereços IP. Então, você configura sua nova versão em um novo servidor, faz o teste necessário e troca IPs para implantar sua atualização. Os mesmos problemas sobre a atualização de ativos que não são de código se aplicam, mas algumas reflexões e planejamentos cuidadosos podem tornar isso um problema.

Com configurações mais robustas e com balanceamento de carga, estratégias como as sugeridas na resposta da danlefree também funcionam.

0
timdev