Compartilhar código de aplicativo da web comum em muitos servidores da web

Question

Qual é a melhor maneira de compartilhar códigos comuns de aplicativos da Web em muitos servidores da Web?

Por exemplo, eu tenho um diretório contendo aplicações web escrito em PHP. Agora, tenho várias máquinas que servirão ao mesmo conteúdo, cada uma executando um servidor da Web, com carga balanceada usando o balanceador TCP / IP.

Ainda não experimentei o NFS para este cenário. Mas, de acordo com o desempenho lento de transferência de NFS de arquivos pequenos , o desempenho da transferência será ser lento, por causa de muitos [pequenos] arquivos envolvidos.

EDIT: Eu quero armazenar todos os arquivos centralmente em um único local, então a atualização para o código será lida instantaneamente pelos servidores da Web.

    

Answer 1

Vou descrever algumas opções, para mostrar alternativas ao código ativo por meio da abordagem NFS .

A "melhor" estratégia depende da sua estratégia de implantação de código escolhida, possivelmente uma delas:

• Editando no sistema ao vivo - o desenvolvedor muda / atualiza o aplicativo em um local central, máquinas ao vivo, em seguida, seleciona a alteração (que soa como seu cenário)
• Código exportado do controle de origem - o desenvolvedor faz alterações em um sistema de controle de origem e executa um programa para exportar o código para todas as máquinas no pool de balanceamento de carga (ou aguarda as máquinas executarem a atualização)
• Código implantado via sistema de pacotes - o desenvolvedor faz alterações em um sistema de controle de origem e cria pacotes de software (por exemplo, via APT ou YUM) armazenados em um repositório. O desenvolvedor executa um programa para forçar as máquinas com carga balanceada a instalar o novo software a partir do repositório.

A "melhor" estratégia também depende dos requisitos de disponibilidade para o aplicativo:

• Tempo de atividade 100% teórico - o aplicativo ainda está disponível enquanto são feitas atualizações de software (funciona com sua abordagem sugerida, mas observe os problemas de atomicidade: durante uma atualização, sua aplicação PHP pode incluir_once () e novos arquivos)
• Manutenção programada aceita - o aplicativo é colocado off-line por breves instantes enquanto são feitas atualizações de software (sem problemas de atomicidade)

Das opções acima, eu pessoalmente escolho a abordagem de implantação de pacotes. No entanto, para solicitações da Web, o compartilhamento de um pequeno número de arquivos no NFS pode funcionar bem: a latência introduzida pelo NFS é pequena em comparação com a Internet. Mas antes de fazer isso, considere as desvantagens:

• Considere quais recursos do sistema estão sendo balanceados: Se você estiver usando várias máquinas para equilibrar o uso da CPU, a configuração poderá funcionar bem. No entanto, se você estiver usando várias máquinas para equilibrar o IO, alterá-lo para uma máquina via NFS (ou de outra forma) pode não ser sensato.
• Considere a falha do servidor de arquivos: Se a máquina que segura os arquivos morrer, ela pode colocar todo o seu aplicativo offline (pois os servidores da Web não conseguem ler os arquivos). Nesse caso, os servidores da Web tenderiam a bloquear a espera, para que o NFS se recuperasse.

Devido a esses possíveis empecilhos (IO ligado ao servidor de arquivos, falha do servidor da Web), eu também sugeriria sincronizar periodicamente os servidores da Web com o aplicativo. Empurrar mudanças para várias máquinas deve levar apenas alguns segundos. Se necessário, você pode configurar algumas lógicas como: if (time () > 23:59:00) {usar o software no dir B} else {usar o software no dir A}). Isso pode ser útil se todas as máquinas precisarem executar a mesma versão de software, por exemplo, se você acabou de alterar um esquema de banco de dados.

Um par de segundos de atraso durante a implantação realmente não é tão ruim. Um desenvolvedor trabalhando em um sistema ao vivo certamente notaria o atraso, mas os desenvolvedores não devem editar sistemas ao vivo de qualquer maneira.

    

Answer 2

se o seu conteúdo não mudar, então qualquer método de transferência fará, mesmo NFS. Se você tar os arquivos primeiro e depois desempacotá-los, a taxa de transferência será muito rápida.

É claro que, se você precisar transferir muitos arquivos pequenos regularmente, talvez não tenha nenhuma solução - seus servidores da web sempre ficarão desatualizados com os arquivos mais recentes (ou, pior, com os arquivos necessários).

Se você quiser configurar uma maneira de implantar arquivos em um servidor central e depois transferi-los automaticamente para os outros, poderá configurar uma transferência de rsync para os servidores, e somente os arquivos alterados serão transferidos (se você usar o daemon rsync, ele usará o protocolo do rsync e não demorará quase nada, segundos em todas as probabilidades).

Um bom método que os outros usam é armazenar arquivos da web em um sistema de controle de versão e usá-los para exportar os arquivos para os outros servidores. Então, basta atualizar os arquivos e os vcs substituirão os arquivos alterados pela nova versão. .

Incidentalmente, o NFS não é bom para arquivos pequenos, mas nada mais existe. O problema é mais sobre latência de rede do que qualquer outra coisa. Isso ainda não deve colocá-lo fora de usá-lo, a menos que você tenha um monte de arquivos para transferir, não será muito lento para usar. Você poderia tentar usar o transporte cifs em vez de nfs, eu faço isso para o meu servidor Windows como eu tenho melhor desempenho para arquivos grandes lá.

    

Answer 3

Arie, Minha empresa webdev possui um grande número de bibliotecas compartilhadas pelos nossos sites. Os sites são executados em vários servidores de produção em diferentes datacenters.

Como os servidores estão em datacenters separados, não podemos servir as bibliotecas a partir de um único local de baixa latência centralizado. Em vez disso, usamos o Webistrano (uma GUI para a excelente ferramenta de implantação do Capistrano) para implantar as bibliotecas em todos os servidores, diretamente de nosso repositório do SVN. O Capistrano é implantado em todos os servidores simultaneamente, e somente após todos os servidores terem sido implantados com sucesso, ele alterna um link simbólico para apontar para o novo diretório de implantação. Caso contrário, faz uma reversão em todos os servidores.

Em outras palavras, a atualização é executada em todos os servidores praticamente no mesmo segundo, ou não é de todo. Transacional ou atômica ou o que você quiser chamá-lo.

Nossa tarefa final no final do script de implantação é uma reinicialização normal do Apache, para liberar todos os caches do PHP (real_path, Zend Framework, etc.) que armazenaram os caminhos anteriores.

Funciona muito bem, é muito seguro e, como todos os arquivos são armazenados localmente em cada servidor, a latência é muito baixa. Também é muito fácil; simplesmente clicando em Implementar no Webistrano.

    

Answer 4

Você poderia olhar para sshfs. Basicamente, você teria um local central que os outros servidores montariam como uma pasta local.

Por exemplo (para montar o servidor como um diretório).

sshfs server.with.content:/home/arie/local_folder

Agora você pode acessar o outro servidor como se fosse uma pasta local. A vantagem é que a transferência de dados é criptografada.

Google sshfs e fusível.