Apache em vários servidores com uma configuração

Question

Eu quero replicar minha máquina virtual e colocá-la atrás de um balanceador de carga.

Apache1  Apache2 ....ApacheN
   |        |           |
-------------------------
        LoadBalancer

Gostaria de usar apenas UM arquivo de configuração para hosts virtuais (na verdade, um diretório de arquivos conf com Include em cada httpd.conf), UM arquivo de log e um diretório comum do DocumentRoot para todas as instâncias. Isso é possível, apenas compartilhando algum diretório entre as máquinas virtuais e configurando cada Apache de acordo?

Ou haverá algum conflito com a abertura e escrita de arquivos?

Existe talvez uma maneira melhor de manter todas as máquinas com a mesma configuração?

A única outra coisa em que consigo pensar é um script que copia uma configuração principal e reinicia todas as instâncias do Apache. E também algum script para mesclar todos os logs ...

Qualquer sugestão é bem-vinda.

UPDATE: Eu pensei que no meu caso o desempenho não era um problema, mas parei de gravar no mesmo arquivo de log de duas instâncias, quando comecei a perceber a corrupção do log.

[04/Oct/2014:17:10:34 +0200] "GET /index.html HTTP/1.0" 200 15082 22633
[04/Oct/2014:17:10:36 +0200] "GET /index.html HTTP/1.0" 200 15082 13[04/Oct/2014:17:10:38 +0200] "GET /index.html HTTP/1.0"[04/Oct/[04/Oct/2014:17:10:40 +0200] "GET /index.[04/Oct/2014:17:09:42[04/Oct/2014:17:10:42 +0200][04/Oct/2014:17:09:44 +0200] "GET /index.html HTTP/1.0" 200 15082  

    

Answer 1

Você pode muito bem compartilhar a configuração do apache e a raiz do documento entre muitas máquinas idênticas - não há problema em usar, por ex. um compartilhamento NFS para esses fins.

Seria sensato não compartilhar os diretórios de log do apache, porque em carga pesada você obterá muitas gravações simultâneas. Em uma configuração, usei o syslogging remoto para obter logs de apache comuns. Esta será uma questão separada sobre como conseguir isso. Consulte o link como ponto de partida para o remetente.

Você terá que configurar o seu syslog (local do servidor) de acordo.

    

Answer 2

Is there maybe a better way of maintaining all the machines with the same configuration?

Sim, um sistema de gerenciamento de configuração (Puppet, Chef, ...) é a maneira correta de lidar com isso.
Eles podem implantar automaticamente os arquivos de configuração atualizados e reiniciar os serviços posteriormente.
Os logs devem ser enviados via (r) syslog para um servidor de registro central.

Quanto ao conteúdo do DocumentRoot: depende do que está lá.
Se for um código estático, empacotá-lo e implantá-lo através das ferramentas padrão do SO (yum, apt-get, ...) seria preferível.
Também facilita a implementação de novas versões lentamente.

É claro que é possível ter um compartilhamento de arquivos, mas isso pode funcionar como um único ponto de falha.
E será doloroso verificar qual máquina já reiniciou o serviço depois que uma nova configuração foi colocada ali, à medida que você adiciona mais servidores.

    

Answer 3

Eu recomendaria usar um sistema de gerenciamento de configuração, como puppet ou CFEngine, ou pelo menos armazenar centralmente as configurações dentro de um único repositório e puxá-las para todos os servidores web.

Para a solução de gerenciamento de configuração, você pode especificar arquivos inteiros que devem existir e onde obter a cópia canônica no servidor de gerenciamento de configuração ou pode especificar os parâmetros para esses arquivos no idioma de gerenciamento de configuração, o que fornece um camada de abstração e simplifica o processo de introdução de novas configurações de maneira correta.

Para simplesmente manter e distribuir centralmente os arquivos, você provavelmente desejaria verificar os arquivos de configuração em um software de controle de versão, como CVS ou SVN. A partir daqui, existem duas maneiras simples de obter essas configurações em todos os seus servidores da Web.

• Você pode instruir seus servidores da Web a extrair diretamente da ferramenta de gerenciamento de versões ( cvs co ou svn checkout )
• Como alternativa, você poderia fazer um pouco mais de trabalho para criar uma solução mais robusta, escalonável e reutilizável
  • script construindo um RPM de todos os arquivos de configuração do apache (ou o equivalente para o seu sistema operacional)
  • executar um repositório do yum dentro do servidor de controle de versão (ou o equivalente para o seu SO)
  • simplesmente instrua seus servidores da web a executarem uma atualização yum my-apache-configs (ou o equivalente para o seu SO).

A solução somente VCS é mais fácil de configurar e funciona nos sistemas operacionais. A solução de repositório de pacotes é um pouco mais difícil de configurar, mas abrirá o caminho para você empacotar e distribuir configurações, códigos e scripts de todos os tipos, e se alinha mais de perto com a metodologia do fornecedor de SO.

A outra coisa boa sobre a solução do repositório de pacotes é que você pode definir dependências e grupos de pacotes. Isso significa que você pode tornar minha-apache-config dependente do link e do mod_ssl . Você poderia então criar um pacote vazio que você chama de algo como company_com-web_server que depende de my-apache-configs e my-ssl-certificates e quaisquer outros pacotes específicos para sua empresa. Para configurar uma nova instância do servidor web, coloque um servidor recém-instalado (adicione seu yum repo ao kickstart) atrás do balanceador de carga, emita um yum -y install company_com-web_server , saia para tomar um café, e voltar com uma instância de servidor da web pronta para o roll.

===== EDIT =====

O valor deste mecanismo é que ele cria um sistema fracamente acoplado. Se o servidor de gerenciamento de configurações ou o repositório do yum ficar offline, você perderá a capacidade de reconfigurar, mas os servidores da Web permanecerão ativos. Mesmo na instância htat, você pode replicar manualmente as alterações em todas as máquinas e verificar as alterações manualmente quando o repo voltar. Usar armazenamento compartilhado (NFS, sistema de arquivos em cluster, etc) criaria uma falha de ponto único.