Comment gérer des centaines de BMC IPMI?

J'ai plus de 200 ordinateurs qui peuvent fournir des services IPMI . Les serveurs sont fabriqués par plusieurs sociétés différentes (SuperMicro, Dell, etc.), et il existe 6-7 modèles BMC provenant d'environ 5 fournisseurs différents, et chaque modèle a ses propres particularités.

Jusqu'à présent, nous avons configuré les BMC en utilisant une combinaison de DHCP et en configurant manuellement chaque BMC. La configuration manuelle peut être effectuée à l'aide d'un CD-ROM amorçable, à partir du BIOS (si pris en charge), du système d'exploitation hôte avec un utilitaire comme ipmitool , freeipmi , etc. ou à distance à l'aide d'ipmitool si nous pouvons déterminer l'adresse réseau du dispositif.

Cependant, cette configuration manuelle est plutôt fastidieuse. Dans certains cas, nous souhaitons modifier un paramètre globalement sur tous les BMC, ce qui nécessite qu'un administrateur exécute une commande sur des dizaines de boîtes. Étant donné que les BMC sont fournis par différents fournisseurs et que chaque modèle de BMC peut avoir ses propres particularités, la même commande ne fonctionne pas toujours sur tous les BMC.

Existe-t-il des utilitaires qui me permettent de configurer en masse les BMC sur des dizaines de boîtiers? Supposons que je souhaite interroger un paramètre sur des dizaines de BMC différents, ou changer le mot de passe, désactiver l'accès HTTP à l'interface Web ou désactiver le fameux trou de sécurité zéro du chiffre .

Points bonus pour tout utilitaire qui me permettrait de mettre à jour le firmware du BMC, ce qui est nécessaire pour atténuer plusieurs failles de sécurité

J'utiliserais probablement Ansible . C'est un moteur de gestion / orchestration de configuration très simple qui est beaucoup plus simple à démarrer que Puppet (Puppet était mon choix préféré pour cela, mais pas toujours maintenant, après avoir découvert Ansible).

L'avantage d'Ansible ici est qu'il communique directement via SSH, vous pourrez donc commencer à utiliser uniquement vos informations d'identification et votre flux de travail SSH existants.

Si vous configurez actuellement vos BMC avec ipmitool, vous pourrez faire quelque chose comme:

Définir un fichier Hosts - Cela indique à Ansible quels hôtes se trouvent dans le groupe bmc (dans ce cas) et sur lesquels exécuter des éléments.

[bmc]
192.168.1.100
192.168.1.101
192.168.1.102

Et ainsi de suite ... Vous pouvez également utiliser des noms d'hôtes dans ce fichier, tant qu'ils sont résolvables.

Créez ensuite un "playbook", qui est l'ensemble des commandes à exécuter sur chaque hôte d'un groupe d'hôtes. Vous voulez avoir ce type de disposition de répertoire de haut en bas:

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

Un playbook a des rôles , qui sont de petites sections de configuration que vous pouvez décomposer et réutiliser.

Je créerais donc un fichier appelé bmc.yml(la configuration All Ansible est dans les fichiers YAML)

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

Ensuite, à l'intérieur, roles/bmcconfig/tasks/main.ymlvous pouvez commencer à répertorier les commandes à exécuter sur chaque hôte pour communiquer avec ipmi.

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

Lorsque vous exécutez le playbook, ansible-playbook -i hosts bmc.ymlles commandes répertoriées dans tasks/main.ymlpour chaque rôle seront exécutées dans l'ordre descendant sur chaque hôte trouvé dans le groupe d' bmchôtes danshosts

group_vars/all est un fichier intéressant, il vous permet de définir des paires clé-valeur de variables et de valeurs pouvant être utilisées dans vos playbooks.

afin que vous puissiez définir quelque chose comme

ipmitool_password: $512315Adb

dans votre group_vars/allet par conséquent, vous seriez en mesure d'avoir quelque chose comme:

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

dans le playbook.

Vous pouvez trouver bien plus d'informations sur la façon d'utiliser les "modules" - les composants d'Ansible qui vous permettent de faire des choses, comment écrire le vôtre: D, et ainsi de suite sur les pages de documentation Ansible .

J'ai écrit un petit outil python pour exécuter des commandes sur nos 1000 machines (et leurs bmc, drac, ilo et imm)

Ce que j'ai fait, c'est écrire un framework python appelé vsc-manage où je peux exécuter des commandes qui sont soit envoyées au serveur, soit au bmc, puis configuré quel type de machine a besoin de quelle commande.

J'ai plusieurs classes qui combinent un mélange de ces commandes,

Donc, pour les machines avec un imm, il ssh dans l'imm, et s'exécutera power off(d'une manière attendue avec un script)

Pour nos châssis de lame imb , il fonctionnera sur le châssis

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

Pour certains dracs Dell, il s'exécutera sur le système d'exploitation (d'un nœud maître)

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

Pour nos nouveaux systèmes hp qui font ipmi (et je vois de plus en plus ces jours-ci), cela fonctionnera sur le maître:

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

ou les nouveaux systèmes Dell ont besoin ipmitool -I open, vous devrez peut-être jouer un peu avec le protocole.

Pour les paramètres non inclus dans la norme ipmi, j'ai implémenté certaines choses à partir du DMTF SMASH CLP , par exemple en allumant le voyant de localisation:

start /system1/led1

Tout cela dans un outil en ligne de commande qui peut être exécuté à partir de nos ordinateurs portables, qui se connectera au bon nœud maître, exécutera la bonne commande pour le bon nœud et retournera la sortie, avec une liste supplémentaire d'erreurs le cas échéant (basée sur sortie sur stderr et / ou exitcode)

Cela s'est avéré très pratique, et l'ajout de la prise en charge d'une nouvelle classe de matériel est maintenant relativement facile (grâce au fait que la plupart des fournisseurs prennent désormais en charge entièrement ipmi et DMTFSMASHCLP)

Ce n'est pas adapté à la configuration initiale (il a besoin du bmc pour avoir une adresse IP unique et une passerelle correcte, mais c'est ce que nos fournisseurs doivent nous fournir à la livraison) mais peut faire presque n'importe quoi d'autre (également exécuter des commandes arbitraires sur l'hôte d'exploitation système et planifier automatiquement les temps d'arrêt dans icinga / nagios lorsque vous redémarrez un nœud et / ou reconnaissez 1000 hôtes et services dans icinga / nagios à la fois)

La mise à jour du micrologiciel bmc et l'ajout de la prise en charge de nos commutateurs sont des problèmes en suspens qui sont planifiés.

MISE À JOUR

Puisqu'au moins certaines personnes semblaient intéressées, je lui ai donné un dernier polissage aujourd'hui, et l'open source à https://github.com/hpcugent/vsc-manage

Bien que cela soit très ciblé sur notre propre flux de travail (quattor et / ou pbs), j'espère que cela peut au moins être intéressant.

Je suis surpris que personne n'ait mentionné MAAS ( http://maas.io/ ), qui fait exactement ce que vous recherchez. Il peut autoconfigurer et gérer les BMC, et en outre déployer tout système d'exploitation sur les nœuds que vous avez enrôlés dans le système. Il possède une interface utilisateur Web et une API RESTful et est conçu pour s'intégrer à n'importe quel système d'automatisation.

Lorsqu'un ordinateur démarre PXE pour la première fois, MAAS utilise IPMI intrabande pour configurer automatiquement les informations d'identification pour vous. À partir de ce moment, vous pouvez facilement démarrer et arrêter une machine à distance.

Pour plus de détails, consultez la documentation MAAS BMC Power Types qui montre comment configurer manuellement un BMC pour n'importe quel nœud inscrit dans MAAS.