Como posso gerenciar centenas de BMCs do IPMI?


30

Eu tenho mais de 200 computadores que podem fornecer serviços IPMI . Os servidores são fabricados por várias empresas diferentes (SuperMicro, Dell, etc.), e existem 6-7 modelos BMC de cerca de 5 fornecedores diferentes, e cada modelo possui suas próprias idiossincrasias.

Até o momento, configuramos os BMCs usando uma combinação de DHCP e configurando manualmente cada BMC. A configuração manual pode ser feita usando um CD-ROM inicializável, configuração do BIOS (se suportado), do sistema operacional host com um utilitário como ipmitool , freeipmi , etc. ou usando remotamente o ipmitool se pudermos determinar o endereço de rede do dispositivo.

No entanto, essa configuração manual é bastante entediante. Em alguns casos, queremos alterar uma configuração globalmente em todos os BMCs, o que exige que um administrador execute um comando em dezenas de caixas. Como os BMCs são fornecidos por diferentes fornecedores e cada modelo do BMC pode ter suas próprias idiossincrasias, o mesmo comando nem sempre funciona em todos os BMCs.

Existem utilitários que permitem configurar em massa os BMCs em dezenas de caixas? Digamos que eu queira consultar um parâmetro em dezenas de BMCs diferentes ou alterar a senha, desativar o acesso HTTP à WebUI ou desativar a infame falha de segurança zero da cifra .

Pontos de bônus por qualquer utilitário que me permita atualizar o firmware do BMC, necessário para mitigar várias vulnerabilidades de segurança


3
Isso com certeza parece algo que você poderia fazer se fosse fantoche / coletivo. Você usa o facter , possivelmente com alguns fatos personalizados para detectar qual tipo de dispositivo você possui, depois configura as coisas usando fantoches ou pressionando comandos com o mcollective.
Zoredache

Você também pode dar uma olhada no xcat . Não é tão sofisticado quanto o fantoche quando se trata de gerenciamento de configuração, o put possui shell distribuído integrado, que pode operar em grupos e se integra perfeitamente ao IPMI.
Isaac

Puppet Navalha pode ser uma solução, também, embora eu não olhei para isso ainda: vdatacloud.com/blogs/2012/05/23/...
Stefan Lasiewski

Estou no Puppetconf e acabei de falar com o gerente de projetos do Mcollective (também conhecido como Puppet Enterprise Orchestration). Do Mcollective gerencia seus nós (no nível do SO), fazê-lo funcionar no nível do IPMI parece muito além do que o Mcollective foi projetado. Mas provavelmente é possível.
Stefan Lasiewski

Respostas:


16

Eu provavelmente usaria o Ansible . É um mecanismo de gerenciamento / orquestração de configuração muito mais simples do que o Puppet (o Puppet costumava ser minha escolha preferida para isso, mas nem sempre agora, tendo descoberto o Ansible).

O benefício do Ansible aqui é que ele se comunica diretamente pelo SSH, para que você possa começar a usar apenas as credenciais e o fluxo de trabalho existentes do SSH.

Se você está configurando seus BMCs com o ipmitool, poderá fazer algo como:

Definir um arquivo Hosts - Isso informa ao Ansible quais hosts estão no grupo bmc (nesse caso) e em quais itens executar.

[bmc]
192.168.1.100
192.168.1.101
192.168.1.102

E assim por diante ... Você também pode usar nomes de host nesse arquivo, desde que sejam solucionáveis.

Em seguida, crie um "manual", que é o conjunto de comandos para executar em cada host em um grupo de hosts. Você deseja ter esse tipo de layout de diretório de cima para baixo:

ansible/
   playbooks/
      bmc.yml
      roles/
        bmcconfig/
           files/
           handlers/
             main.yml
           tasks/
             main.yml
           templates/
   group_vars/
      all

Um manual tem Funções , que são pequenas seções de configuração que você pode quebrar e reutilizar.

Então, eu criaria um arquivo chamado bmc.yml(Toda a configuração Ansible está nos arquivos YAML)

---
- name: Configure BMC on the hosts
  hosts: bmc
  user: root
  roles: 
    - bmcconfig

Então, dentro, roles/bmcconfig/tasks/main.ymlvocê pode começar a listar os comandos que devem ser executados em cada host, para se comunicar com o ipmi.

---
  - name: Install ipmitool
    apt: pkg=ipmitool state=installed
  - name: Run ipmitool config
    shell: ipmitool -your -options -go -here

Quando você executa o manual, ansible-playbook -i hosts bmc.ymlos comandos listados em tasks/main.ymlcada função serão executados em ordem descendente em cada host encontrado no grupo de bmchosts emhosts

group_vars/all é um arquivo interessante, permite definir pares de valores-chave de variáveis ​​e valores que podem ser usados ​​em seus playbooks.

para que você possa definir algo como

ipmitool_password: $512315Adb

no seu group_vars/alle, como resultado, você poderá ter algo como:

shell: ipmitool -your -options -go -here --password=${ipmitool_password}

no manual.

Você pode descobrir muito mais informações sobre como usar os "módulos" - os componentes do Ansible que permitem fazer coisas, como escrever seus próprios: D e assim por diante nas Páginas de documentação do Ansible .


12

Eu escrevi uma pequena ferramenta python para executar comandos em nossas 1000 máquinas (e seus bmc, drac, ilo e imm)

O que fiz foi escrever uma estrutura python chamada vsc-manage, onde eu posso executar comandos que são enviados para o servidor ou para o bmc e, em seguida, configuramos que tipo de máquina precisa de qual comando.

Eu tenho várias classes que combinam uma mistura desses comandos,

Portanto, para máquinas com um imm, ele será ssh para o imm e será executado power off(da maneira esperada)

Para o nosso chassi blade imb , ele executará isso no chassi

power -%(command)s -T system:blade[%(blade)s]

Para alguns dell dracs, ele será executado no sistema operacional (de um nó mestre)

idracadm -r %(hostname)s -u root -p '%(password)s' serveraction %(command)s

Para os nossos sistemas hp mais recentes que executam o ipmi (e vejo mais e mais nos dias de hoje), ele será executado no master:

ipmitool -I lanplus -H %(hostname)s -U %(user)s -P '%(password)s' chassis power %(command)s

ou os sistemas dell mais recentes precisam ipmitool -I open, talvez seja necessário jogar um pouco com o protocolo.

Para configurações não incluídas no padrão ipmi, implementei algumas coisas do DMTF SMASH CLP , por exemplo, ativar o localizador:

start /system1/led1

Tudo isso em uma ferramenta de linha de comando que pode ser executada em nossos laptops, que se conectará ao nó mestre certo, execute o comando certo para o nó direito e retorne a saída, com uma lista adicional de erros, se houver (com base em saída em stderr e / ou exitcode)

Isso provou ser muito útil, e adicionar suporte para uma nova classe de hardware é relativamente fácil agora (graças ao fato de a maioria dos fornecedores oferecer suporte total ao ipmi e ao DMTFSMASHCLP agora)

Isso não é adequado para a configuração inicial (ele precisa que o bmc tenha um ip exclusivo e um gateway correto, mas é isso que nossos fornecedores precisam nos fornecer na entrega), mas pode fazer quase qualquer outra coisa (também executar comandos arbitrários no host que está operando) e programe automaticamente o tempo de inatividade no icinga / nagios quando você reinicia um nó e / ou reconhece 1000 hosts e serviços no icinga / nagios de uma só vez)

Atualizar o firmware bmc e adicionar suporte para nossos comutadores são questões pendentes que estão planejadas.

ATUALIZAR

Como pelo menos algumas pessoas pareciam interessadas, eu dei um último polimento hoje, e o código aberto está em https://github.com/hpcugent/vsc-manage

Embora isso seja muito direcionado ao nosso próprio fluxo de trabalho (quattor e / ou pbs), espero que pelo menos possa ser interessante.


Obrigado por isso! Existe alguma vantagem que seu trabalho tenha sobre soluções estabelecidas, como a Ansible?
MikeyB

Eu nunca tinha ouvido falar de Ansible antes, Definitivamente vou investigar.
Jens Timmerman

Até onde eu vejo, o Ansible ainda não tem suporte para impi e DMTF SMASH.
Jens Timmerman

É interessante, Jens. Obrigado por compartilhar este projeto. O Ansible + vsc-manage começa a parecer realmente útil ao lidar com servidores em massa.
ILIV

ILIV, eu acho que seria bom se eu tinha algum tempo para adicionar todas as características de VSC-conseguem ansible ;-)
Jens Timmerman

3

Estou surpreso que ninguém tenha mencionado o MAAS ( http://maas.io/ ), que faz exatamente o que você está procurando. Ele pode autoconfigurar e gerenciar BMCs e, além disso, implantar qualquer sistema operacional nos nós que você inscreveu no sistema. Ele possui uma interface da Web e uma API RESTful e foi desenvolvido para integrar-se a qualquer sistema de automação.

Quando uma máquina PXE é inicializada pela primeira vez, o MAAS usa IPMI em banda para configurar credenciais automaticamente para você. A partir desse momento, você pode facilmente inicializar e desligar remotamente uma máquina.

Para obter mais detalhes, consulte a documentação do MAAS BMC Power Types que mostra como configurar manualmente um BMC para qualquer nó listado no MAAS.


Uma boa dica, obrigado. Parece bem legal. O MAAS do Ubuntu parece fazer um bom provisionamento, gerenciamento do ciclo de vida e parece que ele tem algumas ferramentas úteis de gerenciamento de IPMI. Já usamos o Foreman, o que já faz parte disso. No entanto, o gerenciamento IPMI do Foreman é bastante fraco e não fornece agrupamento ou estrutura organizacional, mas pelo menos possui alguma coisa. Nós o usamos em combinação com várias outras ferramentas para gerenciar todo o kit e o caboodle.
Stefan Lasiewski

Observe que o Foreman tem organizações e locais (consulte projects.theforeman.org/projects/foreman/wiki/… ) a partir da v1.1. Você pode usar esses recursos (junto com os Grupos de host) para fornecer coleções de hosts razoavelmente granulares (mesmo hierárquicas com suporte a pares de parâmetros ou de valores-chave).
Mxmader
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.