Mantenha-os iguais. A chance de você ter alguma incompatibilidade que se manifesta apenas em uma certa configuração é mínima e depois você terá que lembrar as diferenças para tudo que você faz.
Se você fornecer um serviço em dois servidores para garantir alta disponibilidade, é melhor configurá-los exatamente da mesma maneira; em vez disso, você deve introduzir pequenas diferenças para evitar erros de "configuração maluca"?
Hospedamos um site baseado em Django em uma pilha de Linux (Ubuntu LTS), Nginx, Apache e Python WSGI, duplicados em três servidores atrás de um balanceador de carga. Atualmente eles estão hospedados na nuvem da Amazon, mas podemos nos mudar para nosso próprio datacenter no futuro. Recentemente, tivemos um problema em todos os três servidores que só foi resolvido com a atualização do kernel, o que nos faz pensar que era uma incompatibilidade entre versão específica do kernel e do hardware físico que a Amazon pode ter começado a usar no momento.
Isso me fez pensar: seria melhor manter todas as máquinas exatamente na mesma configuração (gerenciamento mais fácil?) ou deveríamos manter as coisas um pouco diferentes, de modo que uma incompatibilidade entre dois componentes só se manifestaria em uma máquina? e nem todos eles, mantendo o seu site no ar?
Para simplificar, todos devem ser a mesma configuração, no entanto existem ocasiões (principalmente ditadas pelo software em uso) onde não é possível balancear a carga e o failover se torna a única opção - e nesses casos ter configurações diferentes pode ser necessário.
OTOH, para um serviço voltado para a Internet, disponibilidade e segurança deve estar no topo da lista de prioridades. Boa segurança significa aplicar correções regularmente, boa disponibilidade significa que você não pode corrigir todas as caixas ao mesmo tempo - na verdade, a prática que adotei para uma configuração semelhante era aplicar correções a uma máquina viva assim que elas estivessem disponíveis e tivessem sido aplicadas e brevemente avaliado em uma máquina de teste, mas para atrasar o lançamento para os outros nós por alguns dias até que eu soubesse que os patches não tinham nenhum efeito adverso.
Enquanto o Sirex está correto - em um mundo perfeito - você implementaria patches em um cluster de pré-produção e testaria usando tráfego / dados do sistema de produção - na prática isso está longe de ser econômico em uma escala tão pequena. p>
Sim definitivamente. Isso ajudará na solução de problemas que surgirem.
Veja o Puppet para gerenciar suas alterações no arquivo de configuração. Nós armazenamos os arquivos de configuração no svn e depois pressionamos as mudanças. Nós tínhamos um servidor de gerenciamento centralizado que checava nossas mudanças e o Puppet as empurrava. Isso gera um histórico de alterações, por isso, quando você cometer um erro, poderá retrocedê-lo sem problemas e, quando tiver vários administradores, as alterações de configuração poderão ser rastreadas.
Ref: link