######################################################################## # Installation / configuration de Slurm et de Munge ######################################################################## Préambule : VMs à 4 CPUs (Configuration/Système/Processeur/Nombre de processeurs = 4) La première VM fait office de contrôleur Slurm (serveur maître). # # Partager un répertoire /usr/slurm par NFS à partir du contrôleur Slurm # # Sur le contrôleur : mkdir -p /usr/slurm ln -s /usr/slurm /slurm # Sur les VMs 2 à N : vi /etc/fstab 10.1.1.1:/usr/slurm /slurm nfs rsize=8192,wsize=8192 0 0 mount /slurm # # Installation de Mysql sur le contrôleur Slurm (1ère VM) # # déjà fait : yum install mysql # déjà fait : yum install mysql-server # déjà fait : yum install mysql-devel chkconfig --levels 345 mysqld on service mysqld start /usr/bin/mysqladmin -u root -h localhost password 'adminmysql' # # Installation de Munge sur le contrôleur Slurm (1ère VM) # Munge : couche d'authentification, une clef partagée sur l'ensemble du cluster # cd /root/slurm-install # Déja fait : wget http://munge.googlecode.com/files/munge-0.5.10.tar.bz2 tar xjf munge-0.5.10.tar.bz2 cd munge-0.5.10 # déjà fait : yum install openssl-devel ./configure --prefix=/slurm/munge --localstatedir=/var make make install # # Création d'une clef sur le contrôleur Slurm uniquement (elle sera partagée entre tous par NFS) # # Le dd ci-dessous peut durer jusqu'à 20 minutes : Une clef est toute prête # dans /root/slurm-install/munge.key # dd if=/dev/random bs=1 count=1024 > /slurm/munge/etc/munge/munge.key cp /root/slurm-install/munge.key /slurm/munge/etc/munge/munge.key chown daemon /slurm/munge/etc/munge/munge.key chmod 600 /slurm/munge/etc/munge/munge.key # # Configuration de Munge sur tous les noeuds, y compris le contrôleur Slurm # ---------------------> sur tous les noeuds, y compris le contrôleur Slurm # # # Il faut créer manuellement /var/log/munge et /var/lib/munge mkdir /var/log/munge /var/lib/munge # existe déjà sur le contrôleur Slurm chown daemon /var/log/munge /var/lib/munge chmod 700 /var/log/munge # # Mise en place du service via un lien ln -s /slurm/munge/etc/init.d/munge /etc/init.d/munge chkconfig --add munge chkconfig munge on # # Démarrage manuel de Munge (noeuds et contrôleur) # service munge start # # Tests de Munge # /slurm/munge/bin/munge -n | /slurm/munge/bin/unmunge /slurm/munge/bin/munge -n | ssh 10.1.1.2 /slurm/munge/bin/unmunge # # Installation de Slurm sur le contrôleur Slurm # cd /root/slurm-install tar jxf slurm-15.08.6.tar.bz2 cd slurm-15.08.6 # Prerequis : ncurses pour smap # déjà dans VMs : yum install ncurses-devel # déjà dans VMs : yum install pam-devel # déjà dans VMs : yum install gtk2-devel # --with-munge nécessaire pour éviter ceci au démarrage de slurmctld : # error: Couldn't find the specified plugin name for crypto/munge looking at all files # --with-mysql_config = chemin vers mysql_conf (donne des infos sur la conf de MySQL) # vi src/slurmctld/slurmctld.h # MAX_SERVER_THREADS -> 1024 (défaut=256) ./configure prefix=/slurm/slurm --with-munge=/slurm/munge --with-mysql_config=/usr/bin # environ 3 minutes make # près de 10 minutes... make install # -----> On profite des temps d'attente pour générer le fichier de configuration général de Slurm # Appel d'un formulaire HTML pour générer le fichier de configuration de Slurm # Egalement disponible en ligne : http://www.schedmd.com/slurmdocs/configurator.html firefox file:///root/slurm-install/slurm-15.08.6/doc/html/configurator.html vi /slurm/slurm/etc/slurm.conf [copie de la sortie du formulaire HTML ci-dessus] # # Script init.d # C'est le même script qui démarre slurmctld+slurmd sur le contrôleur et slurmd sur les noeuds # en analysant le fichier de configuration => on le partage par NFS # mkdir -p /slurm/slurm/etc/init.d cd /root/slurm-install/slurm-15.08.6 cp etc/init.d.slurm /slurm/slurm/etc/init.d/slurm chmod +x /slurm/slurm/etc/init.d/slurm vi /slurm/slurm/etc/init.d/slurm exec_prefix=/slurm/slurm prefix=/slurm/slurm # A faire sur les noeuds également : # -------------> sur tous les noeuds, y compris le contrôleur Slurm ln -s /slurm/slurm/etc/init.d/slurm /etc/init.d/slurm chkconfig --add slurm # A faire sur les noeuds également : # -------------> sur tous les noeuds, y compris le contrôleur Slurm # Le user slurm fait tourner les daemons groupadd -g 567 slurm adduser -u 567 -g 567 slurm # Spool du contrôleur Slurm : mkdir /var/spool/slurmctld chown slurm:slurm /var/spool/slurmctld # # slurmdbd : le cache d'accès à la base de donnée d'accounting # Nécessaire pour la gestion avancée des utilisteurs et pour certaines commandes (sreport) # vi /slurm/slurm/etc/slurmdbd.conf DebugLevel=info LogFile=/var/log/slurmdbd.log AuthType=auth/munge DbdHost=node1 DbdPort=6828 # correspond à slurm.conf:AccountingStoragePort PluginDir=/slurm/slurm/lib/slurm SlurmUser=slurm StorageHost=localhost StorageLoc=slurm_acct StorageUser=root StoragePass=adminmysql StorageType=accounting_storage/mysql # # Script init.d cd /root/slurm-install/slurm-15.08.6 cp etc/init.d.slurmdbd /slurm/slurm/etc/init.d/slurmdbd chmod +x /slurm/slurm/etc/init.d/slurmdbd vi /slurm/slurm/etc/init.d/slurmdbd BINDIR=/slurm/slurm/bin CONFDIR=/slurm/slurm/etc LIBDIR=/slurm/slurm/lib SBINDIR=/slurm/slurm/sbin ln -s /slurm/slurm/etc/init.d/slurmdbd /etc/init.d/slurmdbd chkconfig --add slurmdbd # # Démarrage : service slurmdbd start # # Démarrage du contrôleur et du daemon slurmd (utilisation du contrôleur comme noeud de calcul) : # Le script init.d lit le fichier de config de Slurm pour déterminer ce qu'il doit lancer : # - slurmctld et slurmd sur le contrôleur # - slurmd sur les noeuds # -------------> sur tous les noeuds, y compris le contrôleur Slurm service slurm start # # Les bons PATHs pour l'utilisation des commandes : # vi /etc/profile # etc. export PATH=/slurm/slurm/bin/:${PATH} export MANPATH=/slurm/slurm/share/man/:${MANPATH} # # Vérifications # sinfo squeue sview & ########################################################################################## # TP1 : sbatch, srun, salloc ########################################################################################## Lancer sview. Activer la colonne "CPU count" dans l'onglet "Jobs". Monitorer également sur 2 ou 3 noeuds dans une console séparée avec : watch 'pgrep sleep | wc -l' 1. Avec srun, lancer 10 exécutions de la commande hostname. Interpreter le résultat. 2. Créer un script batch demandant 1 tâche sur la partition public. Application lancée dans le script : "sleep 30". 3. Lancer le script avec sbatch. Monitorer avec sview et avec "pgrep sleep | wc -l". 4. Lancer le script 10 fois de suite avec sbatch. 5. Sans modifier le script, le lancer 1 fois en demandant 10 tâches. Monitorer avec sview et avec "pgrep sleep | wc -l". 6. Modifier le script pour lancer "sleep 30" avec srun (srun utilisera la valeur de "-n" de sbatch). Lancer le script avec sbatch -n 10. Monitorer avec sview et avec "pgrep sleep | wc -l". Interpreter le résultat. ########################################################################################## # TP2 de configuration générale : les partitions ########################################################################################## vi /slurm/slurm/etc/slurm.conf 1. Créer 2 partitions supplémentaires (en plus de public) : - grant : - durée maxi d'un job : 3mn - durée par défaut d'un job : 2mn - 1 seul noeud : le 3ème - prio - durée maxi d'un job : 3mn - durée par défaut d'un job : 2mn - 2 noeuds : les 1er et 2nd 2. Modifier la partition public : - durée maxi d'un job : 2mn - durée par défaut d'un job : 1mn 3. Appliquer la modification : scontrol reconfig 4. Soumettre des jobs de 3 minutes sur les différentes partitions. Trouver le temps de démarrage prévisionnel du dernier job en attente. ########################################################################################## # TP3 de configuration générale : les ressources consommables ########################################################################################## Monitorer avec sview. 1. Pour une configuration à 3 noeuds, lancer 4 sbatch avec "-n 1" Le 4ème job attend. Chaque job consomme 4 coeurs. 2. Modifier le fichier de configuration de la manière suivante : SelectType=select/cons_res SelectTypeParameters=CR_CPU 3. Appliquer les changements : - Sur tous les noeuds : service slurm restart ("scontrol reconfig" pas suffisant) - Si slurm.conf:ReturnToService=2 ne fonctionne pas en environnement virtuel (sinfo montrera les noeuds DRAIN ou DOWN) : scontrol update nodename=node[1-3] state=resume 4. Pour une configuration à 3 noeuds de 4 coeurs, lancer 13 sbatch avec "-n 1" 12 jobs tournent. Le 13ème job attend. Chaque job consomme 1 coeurs. Idem avec -n 2 ou n'importe quelle combinaison. ########################################################################################## # TP4 : Arrays, variables d'environnements, entrées/sorties ########################################################################################## 1. Créer un script batch, qui sera lancé avec "--array=6-13", et qui calcule le cube de SLURM_ARRAY_TASK_ID (ou votre formule préférée). Concaténer le résultat dans un fichier indexé par le job id propre au groupe (p. ex. out.$SLURM_ARRAY_TASK_ID). Chaque job (task id 6 à 13) doit "dormir" un nombre de secondes égale à son task id. Les jobs dont l'id sera supérieur à 10 devront de plus écrire le résultat dans un fichier indexé par le task id. Lancer avec "--array=6-13". Examiner les fichiers produits. 2. Supprimer le dernier test. Redirigez les sorties standard et erreur dans le fichier "tp4.out" (pour éviter de générer beaucoup de fichiers). Relancer avec "--array=20-50". Monitorez avec sview : seuls 12 jobs devraient tourner en même temps. Examiner le fichier résultat : ordre aléatoire. ########################################################################################## # TP5 : Arrays, variables d'environnements, entrées/sorties ########################################################################################## Dans le TP5, deux problèmes sont posés : - chaque job individuel accède en écriture au même fichier résultat - le résultat n'est pas trié Modifier le script pour que chaque job individuel écrive le résulat dans un fichier propre (out.$SLURM_ARRAY_TASK_ID). Créer un second script (p. ex. tp5_finale.slu) concatènera et triera tous les fichiers résultats dans un fichier unique. Dans l'array, le premier job (celui ayant le task id le plus petit) lancera par sbatch l'exécution du second script, lorsque tous les jobs de l'array seront terminés. On pourra se servir de la variable SLURM_ARRAY_TASK_MIN pour tester si le job array en cours est bien le premier. Ne pas oublier de supprimer les fichiers résultats individuels entre chaque essai. ########################################################################################## # TP6 : preemption ########################################################################################## 1. Créer les utilisateurs user1:group1 et user2:group2. 2. Sous l'utilisateur user1, exécuter "srun hostname". Ca doit fonctionner. 3. Faire les changement de configuration suivants : PreemptType=preempt/qos PreemptMode=requeue JobRequeue=1 AccountingStorageEnforce=Associations,limits ClusterName=hpc Appliquer avec "scontrol reconfig". 4. Refaire le test 2. Ca ne doit plus fonctionner. Il faut créer des associations valides. 5. Initialiser la base de donnée sacctmgr -i create cluster hpc sacctmgr -i create qos defaultqos description="pas prio" preempt="" sacctmgr -i create qos preemptqos description="prio" preempt=defaultqos preemptmode=requeue 6. Créer les associations pour user1 et user2 leur permettant de soumettre dans la partition public en mode preemptable (ne pas oublier l'account correspondant au groupe unix). Vérifier par sacctmgr list associations Refaire le test 2. 7. Créer une association pour user2 lui permettant de préempter les jobs préemptables, mais uniquement avec un accès à la partition prio. Créer en plus pour cela un account group2prio. 8. Soumettre un job sous le user1. Soumettre un job demandant tous les noeuds sous le user2 avec l'account group2prio. Le job de user1 doit être préempté et remis en file d'attente. ########################################################################################## # TP7 : Priorités, fairshare ########################################################################################## SchedulerParameters=default_queue_depth=10,defer=5,sched_interval=5 1. Faire les changement de configuration suivants : PriorityType=priority/multifactor PriorityDecayHalfLife = 14-0 PriorityCalcPeriod = 5 # La consommation pondérée est recalculée toutes les PriorityCalcPeriod minutes PriorityFavorSmall = NO # Priorité aux gros jobs PriorityMaxAge=7-0 # Le facteur age vaudra 1 au bout de d'un temps d'attente de PriorityMaxAge PriorityWeightAge = 400000 PriorityWeightFairshare = 1000000 PriorityWeightJobSize = 500000 #PriorityWeightPartition = #PriorityWeightQOS = Appliquer avec "scontrol reconfig". 2. Soumettre 100 fois le job suivant sous le user1, account=group1 (défaut). vi tp7.slu #! /bin/bash sleep 30 for i in {1..100}; do sbatch tp7.slu; done 3. Laisser tourner quelques instants de manière à ce que le user1:group1 ait une consommation totale significativement plus élevée que user2:group2. Pendant ce temps, examiner les valeurs des priorités des jobs en attente : - sprio -l - sview / Onglet Jobs / click droit sur l'onglet Jobs / cocher Priority 4. cp ~user1/tp7.slu ~user2 puis soumettre 100 fois le même job sous le user2:group2 (et non groupe2prio, sinon la préemption prendra le pas sur le mécanisme des priorités calculées). On doit constater des priorités totales plus élevées pour les jobs de user2, et un passage en exécution immédiat (après le fin des derniers jobs en exécution de user1). 5. A ce stade, il y a de forte chances que tous les jobs de user2 passent avant ceux de user1, du moins si suffisemment de jobs de user1 ont eux le temps de tourner avant. On peut utiliser sshare pour comparer les valeurs de la colonne FairShare : sshare -A group1,group2 6. Soumettre à présent le même job sous user2, mais demandant 8 coeurs (ou plus si le nombre de VMs est suffisant) : sbatch -n 8 tp7.slu D'après la pondération PriorityWeightJobSize, ce dernier job devait avoir une priorité plus élevée que les autres, et passer immédiatement. Si ce n'est pas le cas, augmenter la pondération et reconfiger slurmctld. ########################################################################################## # TP8 : Réservations ########################################################################################## user1 souhaite faire passer un challenge sur la totalité du cluser. Un nouvel utilisateur, user3, va lancer une série de jobs, qui seront forcément prioritaires, puisqu'il n'a jamais encore travaillé. Mais on va créer une réservation pour user1, qu'il faudra faire débuter 1 minute après que user3 aura lancé sa série de jobs. On pourra alors constater que les jobs de user3 seront suspendus dès le début de la réservation de user1. 1. Créer user3:group3. Créer les associations pour user3 : sacctmgr -i add account group3 cluster=hpc qos=defaultqos defaultqos=defaultqos fairshare=1000 sacctmgr -i create user user3 cluster=hpc account=group3 defaultaccount=group3 partition=public fairshare=1000 2. Créer une réservation "challenge" pour user1, débutant à now+2, d'une durée de 2 minutes. 3. Lancer une rafale de jobs sous user3 : cp ~user1/tp7.slu ~user3/tp8.slu for i in {1..100}; do sbatch tp8.slu; done Dés le début de validité de la réservation, on constate que les jobs en cours sont suspendus. 4. Utiliser la réservation. Sous user1 : srun --reservation=challenge -n echo "j'ai tout le cluster !" ou sbatch --reservation=challenge ... ou salloc --reservation=challenge -n echo $SLURM_JOB_NODELIST (sortie par ^D) ########################################################################################## # TP9: sacct, sreport ########################################################################################## 1. Installer l'outil stress (http://people.seas.harvard.edu/~apw/stress/) : wget http://people.seas.harvard.edu/~apw/stress/stress-1.0.4.tar.gz tar xvf stress-1.0.4.tar.gz && cd stress-1.0.4 && ./configure && make && sudo make install ou Créer un programme qui alloue la quantité de mémoire passée en argument. stress permet de charger un noeud avec des "workers" spécialisés en cpu, mémoire, E/S. p. ex. stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s 14 workers : 8 cpu, 4 E/S, 2 mémoire 2. Créer un script batch qui appelle stress avec différents paramètres : vi tp9.slu #! /bin/bash # Appel de stress avec 2 workers : 1 cpu et 1 mémoire # Arguments obligatoires dans l'ordre: # - quantité mémoire en octets # - temps d'exécution en secondes srun stress -m 1 --vm-bytes $1 --cpu 1 -t ${2}s 3. Lancer 100 jobs en faisant varier la durée du job inversement à la taille mémoire allouée : for i in {1..100}; do (( m = (101-$i) * 1000000 )) # de 100Mo à 1Mo sbatch -n 2 -t 00:01:00 tp9.slu $m $i done Les jobs les plus courts consommerront le plus de mémoire. Les jobs de plus de 60s seront interrompus à cause de "-t 00:01:00". 4. A l'aide de sacct, suivre les différents évenements à la trace (état de complétion des jobs, tailles mémoires, temps cpu) Formats utiles pour le suivi mémoire : MaxRSS,MaxRSSNode,MaxVMSize,MaxVMSizeNode Formats utiles pour le suivi CPU : AllocCPUS,NTasks,CPUTime,TotalCPU,SystemCPU,Elapsed,start,end Autres formats utiles : JobID,ExitCode,account,user,partition,nodelist