Gerenciando um aplicativo em vários servidores ou PXE vs cfEngine / Chef / Puppet

Question

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

1: Instale individualmente o centos em todas as caixas e gerencie as configurações com o 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: Crie uma caixa perfeita e crie uma imagem. Sirva a imagem sobre o PXE e sempre que quiser fazer modificações, posso simplesmente reinicializar 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 também se recusa a iniciar se o hwaddr estiver errado. Estes podem ser gerados corretamente na inicialização?

Estou inclinado 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 mate.

    

Answer 1

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

1.) Cobbler para provisionamento de base de compilação. O Cobbler é um projeto que pretende ser a interseção de 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 evoluir para os outros recursos conforme necessário.

2.) Puppet para gerenciamento de configuração. O ideal é que seus hosts construtores de cobblers sejam muito barebones e conheçam apenas o suficiente para ligar para o seu servidor de marionetes na inicialização. O Puppet aplicará suas configurações e as manterá consistentes em todo o seu ambiente em perpetuidade.

3.) Func para comandos ad-hoc em várias máquinas em paralelo. Por exemplo, "implemente um novo svn checkout do código e reinicie o apache". É bem fácil usar o func para chamar o mesmo comando bash em um grupo de servidores muito parecido com o cluster-ssh. Se você realmente quiser entrar nele, pode escrever seus próprios módulos para ele com um python bem simples.

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

    

Answer 2

Visão geral

De algumas maneiras, você tem duas perguntas aqui ...

• Como faço para criar e manter servidores padrão?
• Como faço para manter a configuração padrão e fazer alterações mais tarde?

Eu 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 as melhores práticas relacionadas, como o controle de alterações.

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

Construindo Servidores

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

O satélite parece estar ficando um pouco popular no mundo do RHEL. O passeio espacial é a contraparte do Open Source. Você definitivamente tem que comprar na abordagem do RHEL inteiramente para usar isso. Isso serve como gerenciamento de configuração e construção de servidor.

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

Primeiro, tire proveito de 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 construções do Kickstart podem ser iniciadas em um servidor PXE.

Para a parte mais avançada da compilação e qualquer coisa que não fosse adequada para um arquivo do Kickstart, você poderia escrever seus próprios scripts personalizados. No entanto, você pode encontrar fantoche ou cfengine funciona bem para você, em vez de scripts personalizados. Eu descobri que os scripts personalizados são os mais flexíveis e não estão limitados a nenhuma abordagem única.

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 tudo o que se aplica a todas as compilações. Em seguida, um script final para finalizar a função do servidor. Por exemplo, um servidor da web ou um servidor de banco de dados.

Mantendo Padrões

O que você descreve também se enquadra nas configurações de manutenção. Crie padrões, atualizações de software e outras coisas relacionadas a construçõ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 em origem para as funções de servidor mais importantes, muito disso pode ser mantido com utilitários nativos do sistema. Isso pode ser um script simples para executar um loop for em sua lista de servidores e executar um yum -y update package .

Para o gerenciamento de configuração, é onde entram os utilitários puppet, cfengine e outros gerenciamento de configuração . Esses 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 fazer isso em suas compilações de servidor padrão.

    

Answer 3

Recentemente, terminei um grande projeto para implantar um sistema de gerenciamento / configuração e configuração centralizado em $ WORK. Estamos rodando o CentOS.

Meu design, do qual realmente gosto, nos dá um processo de construção virtualmente de um clique (bem, uma página GUI da web), usando alguns scripts PHP personalizados para unir tudo através de uma interface de usuário simples, mas eficaz.

A teoria geral é:

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

Concordo que as imagens não são uma maneira Unix-y de fazer as coisas ... elas são realmente mais adequadas para o mundo do Windows, onde a instalação / configuração com script / automatizada 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 por acaso eu gosto da natureza declarativa do Puppet e do seu conceito de convergência.

Esse sistema gera vários benefícios:

• O Puppet manipula tudo além de uma instalação de base genérica, portanto, todos os pacotes e configurações necessários estão em um só lugar.
• Os manifestos do Puppet servem como uma fonte adicional de documentação de baixo nível.
• Contanto que você fique com o Puppet (ou seja, não faça alterações na configuração local nem as mescle no Puppet) é trivial construir 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 VMs com o conjunto de pacotes base (KickStart) e depois transformá-los em nós funcionais simplesmente adicionando classes conforme necessário.
• O Puppet permite "marcar" hosts para produção ou desenvolvimento, por isso é incrivelmente fácil criar uma cópia de desenvolvimento / teste de um host, fazer upgrade de pacotes ou fazer alterações de configuração conforme necessário, testar e mesclar novamente na produção.

Answer 4

Se você descer a rota da pxe, não deixe de conferir

link

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

Quais tempos de 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 enfrentando internet, você não pode simplesmente ignorar o patch.

No lado da pxe, você tem algumas opções, dependendo do seu arquivo I / O do seu cluster. Ou Basta inicializar um kernel e montar o disco remotamente ao longo de aoe ou iscsi.

Você também pode fazer algumas coisas muito inteligentes com cópia nas imagens escritas. É ótimo para atualizações e reverter quaisquer alterações que possam ser problemáticas.

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

Mais uma vez, você deve verificar se sua (s) inscrição (ões) gosta de executar o nfs. Não é adequado para toda carga de trabalho.

O

cluster nfs sever pode conter 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

Assim, cada cliente faz referência ao mesmo arquivo, mas recebe o arquivo relevante para o cliente. É bastante impressionante, mas não é simples!

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

Se você usar qualquer uma dessas soluções, verifique se você tem uma falha bem projetada camada de rede tolerante e que seu servidor nfs / SAN é bem projetado + seguro!

Perdendo a conexão, seu NFS / SAN seria ruim para a integridade do servidor. : - (

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

Se eu soubesse mais o que você está tentando agrupar, talvez consiga pensar em uma solução que foi mais adequado para você.