Tests CI	Versions galaxy

scicore.slurm

Configurer un cluster SLURM

Ce rôle configurera :

• le démon de comptabilité slurm
• le démon maître slurm
• les nœuds travailleurs slurm
• les hôtes de soumission slurm

Les utilisateurs SLURM sont automatiquement ajoutés à la base de données de comptabilité slurm lors de la première soumission de travail, grâce à un plugin de soumission lua

Exemple d'inventaire

master ansible_host=192.168.56.100 ansible_user=vagrant ansible_password=vagrant
submit ansible_host=192.168.56.101 ansible_user=vagrant ansible_password=vagrant
compute ansible_host=192.168.56.102 ansible_user=vagrant ansible_password=vagrant

[slurm_submit_hosts]
submit

[slurm_workers]
compute

Une fois que vous avez défini votre inventaire, assurez-vous de définir la variable "slurm_master_host" pointant vers le nom d'hôte de votre hôte maître

Variables de rôle

# ajouter tous les hôtes slurm au fichier /etc/hosts sur chaque machine
# les ip proviennent des faits ansible hostvars[ansible_hostname]['ansible_default_ipv4']['address']
slurm_update_etc_hosts_file: true

# pointez cette var vers un dépôt git si vous avez votre configuration slurm dans git
# slurm_config_git_repo: ""

# par défaut, le rôle déploiera un plugin de soumission lua qui ajoutera automatiquement les utilisateurs à la base de données de comptabilité slurm
# Vérifiez "templates/job_submit.lua.j2" pour les détails
slurm_config_deploy_lua_submit_plugin: true

# Utiliser slurm sans configuration  https://slurm.schedmd.com/configless_slurm.html
# Cette fonction nécessite slurm 20.02 ou supérieur
# Testé uniquement sur des systèmes RedHat mais cela devrait fonctionner sur Ubuntu également si vous installez ubuntu 20.02 ou supérieur
slurm_configless: false

# Déployer les scripts requis dans le maître slurm pour la planification cloud utilisant openstack (https://slurm.schedmd.com/elastic_computing.html)
# Cela déploiera "ResumeProgram", "SuspendProgram" pour slurm.conf
# et /etc/openstack/clouds.yaml avec un identifiant d'application dans le maître slurm
# Cela nécessite un slurm.conf personnalisé. Vérifiez "templates/slurm.conf.j2.cloud.example" pour un exemple
# Il est recommandé d'utiliser [la résolution DNS interne d'OpenStack] (https://docs.openstack.org/neutron/latest/admin/config-dns-int.html#the-networking-service-internal-dns-resolution) 
slurm_openstack_cloud_scheduling: false
slurm_openstack_venv_path: /opt/venv_slurm
slurm_openstack_auth_url: https://my-openstack-cloud.com:5000/v3
slurm_openstack_application_credential_id: "4eeabeabcabdwe19451e1d892d1f7"
slurm_openstack_application_credential_secret: "supersecret1234"
slurm_openstack_region_name: "RegionOne"
slurm_openstack_interface: "public"
slurm_openstack_identity_api_version: 3
slurm_openstack_auth_type: "v3applicationcredential"

# nom du cluster slurm tel que défini dans slurm.cfg
slurm_cluster_name: slurm-cluster

# définissez cette var sur l'ansible_hostname du slurm-master
slurm_master_host: slurm-master.cluster.com
# définissez cette var sur l'ansible_hostname de l'hôte slurm-dbd (même que le slurm-master par défaut)
slurm_dbd_host: "{{ slurm_master_host }}"

# groupe dans votre inventaire ansible incluant tous les travailleurs slurm
slurm_workers_group: slurm_workers

# groupe dans votre inventaire ansible incluant tous les hôtes de soumission
slurm_submit_group: slurm_submit_hosts

# il s'agit de l'emplacement "StateSaveLocation" dans slurm.conf
slurm_slurmctld_spool_path: /var/spool/slurmctld

# il s'agit de l'emplacement "SlurmdSpoolDir" dans slurm.conf
slurm_slurmd_spool_path: /var/spool/slurmd

# paramètres pour le démon de comptabilité slurm
slurm_slurmdbd_mysql_db_name: slurm
slurm_slurmdbd_mysql_user: slurm
slurm_slurmdbd_mysql_password: aadAD432saAdfaoiu

# utilisateur et groupe slurm qui exécutent les démons slurm
slurm_user:
  RedHat: "root"
  Debian: "slurm"

slurm_group:
  RedHat: "root"
  Debian: "slurm"

# EPEL est requis pour installer les paquets slurm et certaines dépendances sur les systèmes CentOS/RedHat.
slurm_add_epel_repo: true

# Vous pouvez régler cela sur vrai pour activer les dépôts yum openhpc sur centos
# Si vous prévoyez d'utiliser des paquets d'openhpc, vous devriez également mettre à jour la liste des paquets pour RedHat ci-dessous
slurm_add_openhpc_repo: false
slurm_ohpc_repos_url:
  rhel7: "https://github.com/openhpc/ohpc/releases/download/v1.3.GA/ohpc-release-1.3-1.el7.x86_64.rpm"
  rhel8: "http://repos.openhpc.community/OpenHPC/2/CentOS_8/x86_64/ohpc-release-2-1.el8.x86_64.rpm"

# paquets slurm que nous installons dans chaque membre du cluster
slurm_packages_common:
  RedHat:
    - slurm
    - slurm-doc
    - slurm-contribs
  Debian:
    - slurm-client

# paquets slurm que nous installons uniquement sur le nœud maître
slurm_packages_master:
  RedHat:
    - slurm-slurmctld
    #  - slurm-slurmrestd
  Debian:
    - slurmctld

# paquets slurm que nous installons uniquement sur le nœud slurmdbd
slurm_packages_slurmdbd:
  RedHat:
    - slurm-slurmdbd
    - mariadb-server
  Debian:
    - slurmdbd
    - mariadb-server

# paquets slurm que nous installons uniquement sur les nœuds travailleurs
slurm_packages_worker:
  RedHat:
    - slurm-slurmd
    - vte-profile  # éviter le message d'erreur "bash __vte_prompt_command commande non trouvée" sur les shells interactifs slurm
  Debian:
    - slurmd

Configuration de la planification cloud slurm pour OpenStack

Ce rôle peut configurer votre cluster slurm pour utiliser la planification cloud sur un cloud OpenStack.

Avant d'essayer de le configurer, il est recommandé de lire le guide de planification cloud de Slurm et les documents sans configuration de Slurm

Assurez-vous que votre cloud OpenStack a la résolution DNS interne activée. Ceci est requis pour que, lorsque un nouveau nœud est démarré, son nom d'hôte puisse être résolu par le maître slurm en utilisant le DNS interne d'OpenStack.

Vous devriez également vérifier le fichier de configuration exemple slurm.conf.j2.cloud.example fourni avec ce rôle. slurm.conf.j2.cloud.example est fourni comme un exemple et vous devrez l'adapter à vos besoins spécifiques et pointer la variable de rôle slurm_conf_custom_template vers votre configuration personnalisée

Vue d'ensemble de la configuration de la planification cloud

• Comme décrit dans les documents de planification cloud de slurm, lorsqu'un utilisateur soumet un travail à un nœud cloud, le maître slurm exécutera le "ResumeProgram" défini dans slurm.conf pour démarrer le nœud de calcul dans le cloud.

• Le ResumeProgram fourni avec ce rôle est un script python qui utilisera l'API OpenStack pour démarrer les nœuds de calcul. Ce script python nécessite le client OpenStack, qui est installé dans un virtualenv. L'argument au programme est les noms des nœuds (utilisant le format d'expression hostlist de Slurm) à mettre sous tension.

• Lorsque un nœud de calcul est inactif, le maître slurm exécutera le SuspendProgram pour arrêter les nœuds. L'argument au programme est les noms des nœuds (utilisant le format d'expression hostlist de Slurm) à éteindre.

• Les options OpenStack utilisées pour démarrer les nœuds de calcul dynamiques (flavour, image, réseau, clé et groupes de sécurité) doivent être définies comme caractéristiques de nœuds dans slurm.conf, par exemple. NodeName=compute-dynamic-[01-04] CPUs=4 RealMemory=7820 State=CLOUD Features=image=centos7,flavor=m1.large,keypair=key123,network=slurm_network,security_groups=default|slurm

• Les deux "ResumeProgram" et "SuspendProgram" nécessitent un fichier de configuration OpenStack avec des identifiants valides. Ce fichier est par défaut rempli dans "/etc/openstack/clouds.yaml" sur l'hôte maître slurm. Il est recommandé d'utiliser un identifiant d'application OpenStack. Vérifiez le modèle templates/clouds.yaml.j2 pour trouver les variables de rôle requises pour remplir ce fichier de configuration.

• Les deux "ResumeProgram" et "SuspendProgram" écriront des journaux dans "/var/log/messages" sur l'hôte maître slurm. Vous pouvez vérifier ce journal à des fins de débogage lors de l'amorçage des nœuds cloud.

Approche recommandée pour déployer slurm avec la planification cloud OpenStack

Assurez-vous d'avoir Slurm 20.02 ou supérieur dans vos dépôts pour disposer du support pour le mode sans configuration slurm.

Démarrez au moins 3 machines :

• maître slurm
• soumission slurm (nœud de connexion)
• travailleur slurm (cela peut être une petite machine que nous utiliserons juste pour créer une image OpenStack avec la configuration requise pour les nœuds de calcul cloud)

Remplissez votre inventaire ansible et ajoutez les machines aux bons groupes d'inventaire référencés par les variables de rôle slurm_submit_group et slurm_workers_group.

Définissez la variable de rôle slurm_master_host avec le nom d'hôte du maître slurm. Chaque machine du cluster devrait être capable de résoudre ce nom d'hôte en l'ip du maître. Chaque machine du cluster doit pouvoir se connecter à cette machine (revoyez vos groupes de sécurité et votre pare-feu local)

Créez une copie de slurm.conf.j2.cloud.example, adaptez-la à vos besoins et pointez la variable de rôle slurm_conf_custom_template vers votre fichier de configuration. Votre fichier de configuration doit fournir une partition nommée "static" qui inclut uniquement la machine de travail slurm que nous avons démarrée précédemment.

Définissez la variable ansible slurm_configless: true afin que les nœuds de calcul soient configurés en mode sans configuration. Lorsque un travailleur slurm est configuré en mode sans configuration, le démon slurmd contactera le maître slurm à son premier démarrage et téléchargera slurm.conf vers /var/run/slurm/conf/slurm.conf

Exécutez le rôle pour configurer toutes vos machines et vous devriez obtenir un cluster slurm fonctionnel avec un seul nœud dans la partition "static".

Maintenant, vous pouvez exécuter vos playbooks ou scripts personnalisés pour personnaliser le travailleur slurm, par exemple ajouter des montages NFS, installer le client LDAP, activer des modules logiciels, installer des logiciels supplémentaires, etc.

Créez une image OpenStack à partir de la machine dans la partition "static" qui inclut vos personnalisations requises. Vérifiez create-slurm-compute-node-image.yml pour un exemple.

Mettez à jour votre copie de slurm.conf.j2.cloud.example et définissez les caractéristiques de nœud appropriées avec le nom de l'image openstack, le nom de la clé, le nom du réseau et les groupes de sécurité. Relancez le playbook pour déployer votre configuration mise à jour.

Maintenant (espérons-le) vous devriez avoir un cluster slurm fonctionnel avec le support de la planification cloud. Vous devriez voir les partitions cloud slurm lorsque vous exécutez sinfo -Nel. Essayez de soumettre un travail à l'une des partitions cloud et surveillez /var/log/messages et /var/log/slurm/slurmctld.log sur l'hôte maître slurm.