Temos um aplicativo que está sendo executado em algumas (5 ou mais e aumentará) caixas. O hardware é idêntico em todas as máquinas e, idealmente, o software também. Eu os tenho gerenciado manualmente até agora e não quero mais (endereços IP estáticos, desativando todos os serviços necessários, instalando os pacotes necessários ...). Alguém pode equilibrar os prós e contras das seguintes opções ou sugerir algo mais inteligente?

1: Instale centos individualmente em todas as caixas e gerencie as configurações com chef / cfengine / puppet. Isso seria bom, pois eu queria uma desculpa para aprender a usar um dos aplicativos, mas não sei se essa é realmente a melhor solução.

2: Faça uma caixa perfeita e crie uma imagem. Sirva a imagem no PXE e sempre que eu quiser fazer modificações, basta reiniciar as caixas a partir de uma nova imagem. Como os caras do cluster normalmente lidam com coisas como ter endereços mac nos arquivos / etc / sysconfig / network-scripts / ifcfg *? Também usamos infiniband, e ele também se recusa a iniciar se o hwaddr estiver errado. Eles podem ser gerados corretamente na inicialização?

Estou me inclinando para a solução PXE, mas acho que o monitoramento com munin ou nagios será um pouco mais complicado com isso. Alguém tem experiência com esse tipo de problema?

Todos os servidores possuem SSDs e são rápidos e poderosos.

Obrigado, Matt.

Seu cluster parece mais um cluster HPC do que um OLTP como o meu, mas acho que a configuração que estou usando funcionaria para você também. Eu chamo isso de "mpdehaan trifecta" porque esse é o truque do cara que escreveu ou gerencia as três ferramentas envolvidas.

1.) Cobbler para provisionamento de construção de base. O Sapateiro é um projeto que visa ser a interseção dos seus sistemas kickstart, pxe, yum-repo, dhcp, dns, etc. É de longe a maneira mais fácil de instalar e executar um kickstart, e você pode desenvolver outros recursos, conforme necessário.

2.) Puppet para gerenciamento de configuração. Idealmente seus sapateiro construído anfitriões são muito barebones configurações que sabem apenas o suficiente para telefone de casa para o seu servidor fantoche na inicialização. O Puppet aplicará suas definições de configuração e as manterá consistentes em todo o ambiente em perpetuidade.

3.) Func para comandos ad-hoc para várias máquinas em paralelo. Por exemplo "implante uma nova verificação svn do código e reinicie o apache". É muito fácil usar func para chamar o mesmo comando bash em um grupo de servidores, como o cluster-ssh. Se você realmente quer entrar nele, você pode escrever seus próprios módulos com algum python realmente simples.

Todas essas três ferramentas possuem bons wiki e canais irc ativos para obter ajuda no freenode.

Visão geral

De certa forma, você tem duas perguntas aqui ..

• Como crio e mantenho servidores padrão?
• Como mantenho a configuração padrão e faço alterações posteriormente?

Dividi minha resposta abaixo, abordando essas duas coisas separadamente, mas elas estão intimamente relacionadas. Estou abordando as soluções de tecnologia aqui e não nenhuma das melhores práticas relacionadas, como controle de alterações.

Se isso não cobrir o escopo da sua pergunta, esclareça e terei prazer em elaborar. Essa é a base necessária, essencial para uma infraestrutura de tecnologia bem administrada.

Criando servidores

Não gosto de imagens no mundo UNIX; isso é mais uma abordagem de estilo do Windows. Até mesmo algumas pessoas do Windows parecem estar se concentrando nos scripts para compilações padrão agora.

O satélite parece estar ficando um pouco popular no mundo do RHEL. Spacewalk é a contraparte de código aberto. Você definitivamente precisa comprar a abordagem RHEL inteiramente para usá-la. Isso serve como criação de servidor e gerenciamento de configuração.

Idealmente, você desejaria estabelecer espelhos e repositórios locais em um servidor de arquivos para todo o software necessário.

Primeiro, aproveite sua automação de construção de distribuição, como o Kickstart no RHEL / CentOS. O Kickstart seria uma linha de base com variações, dependendo de suas necessidades. As compilações do Kickstart podem ser iniciadas a partir de um servidor PXE.

Para a parte mais avançada da compilação e qualquer coisa que não seja adequada para um arquivo Kickstart, você pode escrever seus próprios scripts personalizados. No entanto, você pode achar que o puppet ou o cfengine funcionam bem para você, em vez de scripts personalizados. Eu achei os scripts personalizados os mais flexíveis e não estão limitados a uma única abordagem.

Se você optar por escrever seus próprios scripts, recomendo um script principal para configuração universal. Isso seria configuração de segurança, proteção e qualquer coisa que se aplique a todas as compilações. Em seguida, um script final para finalizar a função de servidor. Por exemplo, um servidor web ou um servidor de banco de dados.

Manutenção de padrões

O que você descreve também se enquadra na manutenção de configurações. Os padrões de compilação, atualizações de software e outras coisas estão relacionadas às compilações, mas de várias maneiras separadas.

Se você optar por confiar nos pacotes do sistema, em vez de criar suas próprias construções baseadas na fonte para as funções de servidor mais importantes, muito disso poderá ser mantido com os utilitários nativos do sistema. Esse pode ser um script tão simples para executar um forloop na sua lista de servidores e executar um yum -y update package.

Para gerenciamento de configuração, este é o lugar onde fantoches, cfengine, e outra de gerenciamento de configuração utilitários entram em jogo. Estes são utilitários muito úteis e fornecem a base necessária sem escrever seus próprios scripts do zero.

Quando você atualiza seus padrões de configuração para seus servidores, é importante preencher isso em suas compilações de servidor padrão.

Recentemente, concluí um grande projeto para implantar um sistema centralizado de gerenciamento de criação / provisionamento e configuração em $ WORK. Estamos executando o CentOS.

Meu design, do qual realmente gosto, nos dá um processo de criação de praticamente um clique (bem, uma página da GUI da web), usando alguns scripts PHP personalizados para unir tudo por meio de uma interface da web simples, mas eficaz.

A teoria geral é:

1. Faça todas as instalações de um único arquivo KickStart minimalista e unificado (bem, OK, um para x86 e outro para x86-64, mas ainda assim, arquivos praticamente idênticos com seleção mínima de pacotes).
2. Script de inicialização do KickStat pós-instalação Puppet.
3. O Puppet aplica toda a configuração específica do nó / host, instalação do pacote, etc.

Eu concordo que as imagens não são uma maneira Unix-y de fazer as coisas ... elas são realmente mais adequadas ao mundo do Windows, onde a instalação e configuração com script / automatizadas não é tão simples.

Você pode substituir o Puppet por qualquer outro sistema de gerenciamento de configuração que se encaixe no projeto, mas gosto da natureza declarativa do Puppet e de seu conceito de convergência.

Este sistema gera vários benefícios:

• O Puppet lida com tudo após uma instalação básica genérica, para que todos os pacotes e configurações necessários estejam em um único local.
• Os manifestos do Puppet servem como uma fonte adicional de documentação de baixo nível.
• Contanto que você se atenha ao Puppet (ou seja, não faça alterações locais na configuração ou mescle-as novamente ao Puppet), é trivial criar uma duplicata de uma máquina.
• Como todos os hosts são criados a partir de uma base comum, você pode pré-instalar o hardware ou as VMs com o conjunto de pacotes base (KickStart) e transformá-los em nós funcionais simplesmente adicionando classes conforme necessário.
• O Puppet permite a "marcação" de hosts para produção ou desenvolvimento, por isso é incrivelmente fácil criar uma cópia de desenvolvimento / teste de um host, atualizar pacotes ou fazer alterações na configuração conforme necessário, testar e depois voltar à produção.

Se você seguir a rota pxe, não deixe de dar uma olhada

http://etherboot.org/wiki/index.php

O Gpxe lhe dará mais flexibilidade com os objetivos de inicialização. É muito fácil inicializar um blade aoe e não há nada como inicializar um kernel em um servidor http remoto !!!!!!!!!! :-).

Qual servidor você precisa?

É impossível criar uma imagem perfeita, pois você sempre precisará aplicar patches de segurança e atualizações de software. Se eles estão voltados para a Internet, você não pode simplesmente ignorar as correções.

No lado do pxe, você tem algumas opções, dependendo da E / S do arquivo do cluster. Basta inicializar um kernel e montar o disco remotamente sobre aoe ou iscsi.

Você também pode fazer algumas coisas muito inteligentes com cópia em imagens de gravação. É ótimo para atualizações e reversão de alterações que possam ser problemáticas.

Eu também tive sucesso usando o nfs root, usando uma solução de nfs em cluster. Você pode especificar arquivos diferentes para serem exibidos, dependendo dos endereços dos clientes.

Novamente, você deve verificar se seu (s) aplicativo (s) gosta (s) de executar o nfs. Não é adequado para todas as cargas de trabalho.

o servidor nfs cluster pode conter 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

portanto, todo cliente faz referência ao mesmo arquivo, mas recebe o arquivo relevante para o cliente. É uma coisa bastante impressionante, no entanto, não é simples!

Tudo isso proporcionará tempos de implementação mais rápidos se você centralizar o sistema de arquivos no armazenamento em rede. A criação de imagens de um sistema operacional em uma rede para um disco remoto leva tempo !!!!

Se você estiver usando alguma dessas soluções, verifique se possui uma camada de rede bem projetada e tolerante a falhas e se o servidor nfs / SAN está bem projetado + seguro!

Perder a conexão do seu NFS / SAN seria prejudicial à integridade do servidor. :-(

É muito fácil criar alguns scripts para o tftp / pxe controlar o processo de inicialização.

Se eu soubesse mais o que você está realmente tentando agrupar, talvez pudesse pensar em uma solução mais adequada para você.