initial commit

.gitignore

+_book/
+node_modules

411.md

+# Service 411
+
+Rocks Cluster utilise le service 411 pour déployer ses utilisateurs (à l'exception des utilisateurs dont l'uid est inférieur à 500). Ca ressemble au service *NIS*. En fait, ce service va copier les fichiers déclarés dans */var/411/Files.mk* sur chaque noeud par SSH avec un système de clés.
+
+Voyons un peu ce qui est stocké dans les dossiers de configurations de 411:
+
+```bash
+ls /etc/411*
+```
+
+Il y a deux dossiers: celui qui contient les clés et l'autre qui contient les fichiers à copier, chiffrés par 411.
+
+
+- Nous allons rajouter les fichiers modules java créés précédemment dans la liste des fichiers à copier pour 411
+
+
+<button class="section bttnrem" target="filesmk"></button>
+<!--endsec-->
+
+<!--sec data-title="Files.mk" data-id="filesmk" data-show=false ces-->
+```
+FILES += /etc/modulefiles/java1.7
+FILES += /etc/modulefiles/java1.8
+```
+<!--endsec-->
+
+Pour que les modifications soient prises en compte, il faut maintenant recompiler /var/411:
+
+```bash
+cd /var/411
+make clean && make force
+```
+
+Nous utilisons ```rocks sync users``` pour déployer ces nouveaux fichiers sur nos noeuds.
+
+Pour déployer le fichier, nous aurions aussi pu faire:
+```bash
+rocks iterate host "scp /etc/modulefiles/java1.* %:/etc/modulefiles/"
+```
+
+> **Caution** Cependant, dans ce dernier cas, les fichiers ne seront pas recopiés à la réinstallation des noeuds, alors que c'est le cas avec 411 et le fichier Files.mk. Par ailleurs, toute modification ultérieure sur les fichiers modulefiles ne serait pas répercutée par la suite.

GLOSSARY.md

+# Gestionnaire de batch
+Un gestionnaire de batch (ou _Batch Scheduler_) est un logiciel permettant d'allouer des ressources en fonction des utilisateurs, de leurs jobs et des priorités ( = [jobs manager/scheduler](https://en.wikipedia.org/wiki/Job_scheduler) + resources manager) sur un cluster.
+
+# SGE
+Sun Grid Engine. C'est un gestionnaire de batch très utilisé/déployé. SGE fut créé (à partir de Codine/GRD) puis porté par Sun sur Solaris, en 2000, suite à l'acquisition de l'entreprise Gridware. Suite au rachat de Sun par Oracle, SGE devient Oracle Grid Engine. Racheté depuis par Univa. La version propriétaire de SGE est donc désormais Univa Grid Engine.
+
+# OGS
+Open GridScheduler est l'un des deux forks (avec SoG) OpenSource du projet SGE OpenSource, fermé en 2010. Il n'a pas été mis à jour depuis 2012. C'est cette version qui est incluse dans Roll SGE de RocksClusters.
+
+# SoG
+Son Of GridEngine est l'un des deux forks (avec OGS) OpenSource du projet SGE OpenSource, fermé en 2010. Il reste encore assez actif. Ce code représente certainement l'avenir (s'il y en a encore un) de SGE version OpenSource.
+
+# Univa GridEngine
+Univa est une société qui a racheté le code propriétaire Oracle de SGE. Certains des principaux développeurs de SGE ont intégré Univa.
+
+# RocksCluster
+RocksCLuster, développé par le "San Diego Supercomputer Center" à l'UCSD (Université de Californie, San Diego) est une distribution Linux dérivée de CentOS dont le but est de donner la possibilité d'installer un cluster de calcul clé en main, de manière simple. Les surcouches utilisées pour cette distribution clé en main sont une suite de codes en python "rocks", une base mysql, anaconda/kickstart, apache, 411, NFS et autofs. Des packages "rolls" sont proposés en standard pour compléter la distribution (ganglia, SGE, hpc, bio, perl, python, KVM, ZFS...).
+
+# Appliance RocksCluster
+Une appliance RocksCluster permet un découpage du cluster en plusieurs groupes de machines. Ce découpage permet de lancer des commandes rocks juste sur un groupe de machines mais aussi et surtout permet d'avoir un schéma de (post-)installation KickStart différent que pour les autres machines ([voir ici](http://www.rocksclusters.org/roll-documentation/base/5.5/customization-adding-appliance.html)).
+
+# 411
+C'est un démon linux développé par les développeurs de RocksCluster pour déployer les utilisateurs et groupes du noeud maître.
+
+# Roll
+La distribution RocksCluster est découpée en _Rolls_. Ainsi, cette distribution est modulable. Il est par exemple possible de rajouter un Roll _SL_ afin de passer sur une distribution ScientificLinux et l'utiliser à la place du roll _OS_. D'autres _Rolls_ permettent de déployer un ensemble de packages préconfigurés.
+
+# Modules
+*Modules* ou plus exactement _Environment Modules_ permet de gérer dynamiquement les variables d'environnement de vos utilisateurs. Ainsi, un utilisateur peut exécuter plusieurs versions d'un même logiciel en changeant simplement de contexte par *module*.
+
+# File Staging
+Technique en mode diskfull qui permet à un utilisateur de copier ses données sur le noeud d'exécution localement afin d'accélérer les I/Os. De manière générale, il s'agit de rapprocher au maximum les données des processus.
+
+# Fair Sharing
+Le but du _Fair Sharing_ est d'avoir un partage des ressources équitables. Différentes techniques existent, toutefois, elles n'ont pas le même degré d'équité ou ont une définition différente d'_équitable_.
+
+# I/Os
+Inputs/Outputs (entrées/sorties). Elles peuvent s'appliquer aux disques, au réseau, etc... Il est utile de mesurer ces valeurs pour connaître les performances de notre cluster, en compagnie du nombre de _Flops_.
+
+# Flops
+Nombre d'opérations à virgule flottante par seconde.
+
+# FIFO
+First In, First out. Pile à opposer aux piles LIFO (Last In, First Out).
+
+# Environnement parallèle
+Un Environnement parallèle dans SGE permet de définir la manière dont les jobs vont être exécutés dans le cadre d'applications parallélisées (multithreads, MPI...).
+
+# Queue
+Une queue permet à un gestionnaire de batch de découper un cluster en plusieurs sous-grappes fonctionnelles/matérielles. Elle peut être explicitement déclarée à la soumission du job ou non (le job sera lancé où il peut en fonction des droits des disponibilités...).
+
+# userset
+Un _userset_ permet de définir un groupe d'utilisateur SGE afin de définir des droits / des accès spécifiques.
+
+# checkpointing
+Permet à un job qui s'est arrêté de reprendre où il en était. Nécessite de stocker ce qui est mémoire. Intégré au job scheduler HTCondor par défaut.
+
+# Backfilling
+Dans SGE, ce procédé permet de remplir au mieux les ressources disponibles en démarrant des jobs courts, à faible priorité, alors que d'autres jobs - plus importants (en priorité/temps) - sont en attente (d'une _Advance Reservation_ par exemple).
+
+# Advance Reservation
+Ce procédé permet à SGE de réserver des ressources pour un utilisateur sur une période donnée.
+
+# MPI
+*Message Passing Interface* est une norme de communication définissant une bibliothèque de fonctions utilisables en C/C++/Fortran. Il y a deux implémentations principales de MPI: *OpenMPI* et *MPICH*, tous les 2 sont _OpenSource_. Les communications MPI s'appuyant sur le réseau, il est important que celui-ci soit performant. ([source:wikipedia](https://fr.wikipedia.org/wiki/Message_Passing_Interface))
+
+# OpenMP
+Interface de programmation pour faire des applications multithreads (multicoeurs) en C/C++/Fortran. Des directives (ou pramas) permettent d'indiquer dans le code où paralléliser les tâches (généralement devant les boucles). La version 4 de OpenMP est compatible GPU mais n'est pas encore vraiment disponible ([gcc5](https://gcc.gnu.org/gcc-5/changes.html))
+([Exemples OpenMP4](http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf))
+ A ne pas confondre avec OpenMPI qui s'utilise pour des applications MPI.

README.md

+# TP Rocks Cluster 19/01/2016
+
+Installation et exploitation d'un cluster de calcul (18-22 janvier 2016)
+
+Sainte-Foy-Lès-Lyon, 69
+
+# Introduction
+
+Dans ce TP, nous allons effectuer quelques tâches basiques d'un administrateur de cluster *RocksCluster*. Des prérequis concernant les commandes de base linux sont requis. Par ailleurs, vous devez avoir au moins 50Go de disque et 1.5Go de RAM disponibles en local car nous allons faire des tests en machines virtuelles.
+
+Le but est de pouvoir faire rapidement le tour de la distribution RocksCluster basée sur Centos et une surcouche _maison_ Rocks.
+
+[Site Web de RocksCluster](http://www.rocksclusters.org)
+
+Dans ce TP, nous utiliserons le gestionnaire de batch *SGE* (ou plus exactement, un de ses forks, *OGS* (à cause au rachat de _Sun_ par _Oracle_)). Pour le monitoring, *ganglia* pourra être utilisé. Ces applications sont packagées de base dans le "Jumbo DVD" de Rocks Cluster ou peuvent être téléchargées indépendemment.
+
+
+> **Note** Ces packages sont des *Rolls* du point de vue de Rocks Cluster.

SGE_config.md

+
+# Paramétrage de SGE
+
+Tout est faisable dans *qmon*. Toutefois, le paramétrage général de SGE peut se faire avec *qconf*
+
+Nous allons créer une queue (_add queue_) spécifique:
+```bash
+qconf -aq test.q
+```
+
+Une queue permet de découper le cluster selon vos volontés. Ce découpage peut être décidé, par exemple, pour l'une des raisons suivantes:
+- Matériels différents (architecture (64/32 bits), gpu, quantité de mémoires, type et nombre de coeurs...),
+- Systèmes, logiciels, librairies, environnements différents,
+- Règles d'usage différentes (temps de calcul, priorisations (Fair Sharing, FIFO)...),
+- Utilisateurs (périmètres différents, acheteurs/décideurs différents...),
+- ou pour toute autre raison que vous aurez choisi...
+
+ Par défaut l'accès aux queues est autorisé pour tout le monde, mais vous pouvez créer des _userset_ ou des configurations pour des utilisateurs particuliers. Vous pouvez aussi autoriser certains environnements parallèles sur certaines queues et les interdire dans d'autres (ex: mpi, threads...).
+
+
+ > **Info** Par défaut, seule la queue _all.q_ existe. Elle contient l'ensemble des noeuds d'exécution. Dans votre cas, si vous n'avez qu'un seul noeud d'exécution, l'intérêt d'avoir plusieurs queues est nul.
+
+- Vous pouvez lister les queues (_show queue list_) avec:
+```bash
+qconf -sql
+```
+
+> **Warning** Attention, si la configuration des noeuds évolue : les nouveaux noeuds sont rajoutés dans all.q, mais les anciens ne sont pas supprimés ! Cela implique que SGE cherche à contacter ces noeuds absents avant de lancer des nouveaux jobs. Il faudra donc penser à les supprimer proprement de SGE.
+
+
+- Ou la définition d'une queue particulière (_show Queue_) avec:
+```bash
+qconf -sq test.q
+```
+
+- Il est possible d'éditer la queue (_modify Queue_) avec:
+```bash
+qconf -mq test.q
+```
+Toutefois, nous arrivons sur un éditeur avec des options qui nous sont encore inconnues. Nous allons donc continuer avec *qmon*. Sachez toutefois que la documentation en ligne est très bien faite. Vous pouvez aussi utiliser le _man_.
+
+- Nous allons supprimer la queue précédente (_delete queue_):
+```bash
+qconf -dq test.q
+```
+
+> **Comment** On pourra faire de même pour lister, détruire, ajouter, modifier des utilisateurs, des groupes, des managers, des règles, des noeuds (d'administration, de soumission, d'exécution), des environnements parallèles, etc...
+
+
+```bash
+qmon &
+```
+
+Explorer l'interface. Les premiers points d'entrée intéressants sont:
+- "Host" pour voir nos noeuds,
+- "Job Control" afin de voir les jobs en attente/qui tournent/sont finis,
+- "User" pour gérer des groupes (_userset_) ou utilisateurs SGE particuliers ou bien des opérateurs/managers, etc...
+- "Queue Control" pour gérer vos queues.
+
+Vous pouvez être amené à utiliser tous les autres menus SGE mais ça concerne soit de la configuration avancée (la définition de règles ou d'environnements parallèles, etc...), soit des usages particuliers (comme le checkpointing, la réservation de machines, etc...). Rapidement vous aurez surement besoin de définir des règles ou des environnements parallèles, mais ce n'est pas l'objet de ce TP.

SGE_usage.md

+# Mon premier vrai job SGE
+
+Nous avons vu dans le chapitre [Premiers pas](first_steps.md) un premier job avec un simple _sleep_.
+
+Nous allons faire désormais un vrai script de soumission SGE.
+
+Pour cela, il nous d'abord récupérer le RPM de gnuplot (en root) et un script gnuplot (en tant que toto) pour tracer dans un espace tridimensionnel un nuage de points.
+
+```bash
+yum search --enablerepo epel gnuplot
+yum --enablerepo epel install gnuplot44-minimal.x86_64
+rpm -qa |grep gnuplot
+yumdownloader --enablerepo epel gnuplot44-common.x86_64 gnuplot44-minimal.x86_64
+
+su - toto
+wget -O demo_4.4_random.5.gnu http://gnuplot.sourceforge.net/demo_4.4/random.5.gnu
+exit
+```
+
+Il nous faudrait rajouter maintenant ces 2 packages gnuplot au fichier extend-compute.xml (dans des balises ```<packages>```) et les fichiers RPM au dossier /export/rocks/install/contrib/6.2/x86_64/RPMS pour qu'il soit résintallé à chaque réinstallation.
+
+
+Cependant, nous allons nous contenter de déployer et installer les RPM ce coup-ci, pour nous éviter une réinstallation des noeuds (cependant, c'est ce qu'il faudrait faire pour pérreniser l'installation de gnuplot).
+
+```bash
+rocks iterate host compute "scp gnuplot*.rpm %:/tmp/"
+rocks run host compute "rpm -ivh /tmp/gnuplot*"
+```
+
+> **Comment** Nous aurions pu nous contenter de placer le RPM dans le home directory de toto (ou un autre dossier partagé; plutôt que de copier celui-ci dans le dossier /tmp de chaque noeud). Ce dossier étant monté sur tous les noeuds par autofs.
+
+
+### Mon premier script de soumission
+
+Ouvrir un fichier texte en tant que toto que vous nommerez _general_qsub_file.sh_ et insérer ce qui suit:
+
+```
+#!/bin/bash
+# generic submission file to configure for SGE
+# Beginning of SGE Options (all options begin with '#$')
+# Define shell to use for this job (/bin/sh here)
+#$ -S /bin/bash
+# Job name
+#$ -N my_sge_test
+# Using current working directory (otherwise, you will have to use '#$ wd /path/to/run')
+#$ -cwd
+# Specificy a specific resource value; here, the hard time limit for your job
+#$ -l h_rt=12:00:00
+# choose to run on a specific queue
+# (qconf -sql (to list queues) qconf -sq queue_name (to print informations on this queue))
+#$ -q all.q
+# Get a mail when job is finished or suspended
+#$ -m eb
+#$ -M me@mail.com
+# Redirects the standard output to the named file.
+#$ -o my_sge_test.out
+###$ -e my_sge_test.err
+# merge standard and error outputs
+#$ -j y
+# choose a parallel environment and run on N slots (use $PE_HOSTFILE)
+#$ -pe mpi 2
+# Export all my environment variables into job runtime context
+#$ -V
+# other interesting options : -t n (for n tasks array), -sync y (to wait until job is finished),
+# -v PATH (to export only PATH variable))
+# ...
+## for more informations "man qsub"
+
+#you could export/change some environment variables before
+export LD_LIBRARY_PATH=/usr/lib64/:$LD_LIBRARY_PATH
+
+/path/to/my/executable --an_option /path/to/other/file
+```
+
+Ce script de soumission va nous servir de modèle pour nos futures soumissions. Nous nous contenterons de commenter ce qui ne nous intéresse pas et modifier celle qui nous intéressent.
+Les options SGE commencent toutes par *#$*. D'autres options sont disponibles pour *qsub*. Il suffit de lire le _man_. Dans le chapitre [Premiers pas](first_steps.md), nous avions par exemple utilisé _-b y_ qui permet d'exécuter directement une commande sans passer par un script de soumission.
+
+```bash
+cp general_qsub_file.sh submit_gnuplot.sh
+vim submit_gnuplot.sh
+```
+
+
+Modifiez le script _submit_gnuplot.sh_ de manière à lancer le script gnuplot _demo_4.4_random.5.gnu_ avec un fichier de sortie standard et un pour la sortie d'erreur. Le nom du binaire de gnuplot est _gnuplot44_. Il faut décommenter les 2 premières lignes pour que la sortie se fasse dans un fichier d'image png. En effet, il n'y a pas, par défaut, de serveur X sur les noeuds de calcul (sinon, il faudrait installer un serveur _X_ ou utiliser _Xvfb_). Vous pourrez visionner votre image avec le programme _eog_ par exemple.
+
+<button class="section bttnrem" target="nfs_autofs"></button>
+<!--endsec-->
+
+<!--sec data-title="NFS et autofs" data-id="nfs_autofs" data-show=false ces-->
+```
+#!/bin/bash
+#$ -S /bin/bash
+#$ -N gnuplot_rem
+#$ -cwd
+#$ -l h_rt=12:00:00
+#$ -q all.q
+#$ -o gnuplot.out
+#$ -e gnuplot.err
+#$ -V
+
+gnuplot44 demo_4.4_random.5.gnu
+```
+<!--endsec-->

SUMMARY.md

+# Summary
+
+* [Création du noeud maître](master_create.md)
+* [Premiers pas dans Rocks](first_steps.md)
+* [Utilisation de module](module.md)
+* [Le service 411](411.md)
+* [Post-configuration Rocks](post_configure.md)
+* [Paramétrage SGE](SGE_config.md)
+* [Petit job SGE](SGE_usage.md)
+* [Pour aller plus loin: petite application MPI](mpi.md)
+* [Et maintenant (...) ? Dois-je adopter RocksCluster ? _ Réflexions sur RocksCluster_](quoi_faire.md)
+* [Annexes](annexes.md)
+* [Glossaire](GLOSSARY.md)

annexes.md

+# Annexes
+
+
+
+<!-- toc -->
+
+# Rocks
+
+## Autres commandes rocks utiles
+
+- Générer un profil kickstart du noeud:
+```bash
+rocks list host profile [compute-0-0]
+```
+
+- Afficher les attributs/propriétés d'un noeud:
+```bash
+rocks list host attr [compute-0-0]
+```
+
+- Rajouter manuellement quelque chose dans rocks (Frontend, NAS, interface, appliance, roll...):
+```bash
+rocks add ...
+```
+Il est possible de créer des groupes de machines dans rocks pour pouvoir déployer des images/packages/rolls différents en fonction de l'appartenance ou non à un groupe:
+[Adding applicance](http://central6.rocksclusters.org/roll-documentation/base/6.1.1/customization-adding-appliance.html)
+
+
+
+- Assigner une valeur (adresse IP, adresse Mac, hostname...) à une clé Rocks:
+```bash
+rocks set ...
+```
+
+- Supprimer une valeur (adresse IP, adresse Mac, hostname...) à une clé Rocks:
+```bash
+rocks remove ...
+```
+Ainsi, pour supprimer un noeud de calcul pour Rocks, il faudra faire:
+```bash
+rocks remove host compute-0-0
+```
+Et si l'on souhaite aussi le supprimer de la base des machines installées par ```insert-ethers``` (qui stocke adresses IP/adresses Mac):
+```bash
+insert-ethers --remove compute-0-0
+```
+Par ailleurs, voir [ici](#suppression_sge) pour une suppression du noeud de SGE.
+
+- Voir aussi ```rocks report ...```, ```rocks dump ...```. Pour un référentiel des commandes rocks, voir [ici](http://www.rocksclusters.org/roll-documentation/base/5.4.3/c2083.html)
+
+
+## backup rocks
+
+- Création d'un _restore_ roll (il faut LANG en US, sinon ça plante):
+```bash
+cd /export/site-roll/rocks/src/roll/restore/
+LANG=en\_US.iso885915
+make roll
+LANG=fr\_FR.UTF-8
+```
+-> Va créer un ISO nommé _hostname-restore-date-0.arch.disk1.iso_ qu'il faudra insérer en même temps que le choix des rolls à la réinstallation.
+
+- Dump de la base de données:
+```bash
+/opt/rocks/mysql/bin/mysqldump --defaults-file=/root/.rocks.my.cnf --insert-ignore -u root cluster > /root/dump_rocksdb.sql
+```
+
+D'autres fichiers/dossiers intéressants pourront être sauvegardés:
+- tous les fichiers Linux de configuration habituels situés dans /etc
+- /var/named
+- /var/www
+- /var/lib/ganglia
+- /var/411
+- /export/rocks/install/site-profiles/$version/{graphs,nodes}/
+- vos RPMS éventuellement dans /export/rocks/install/contrib/$version/$arch/{,S}RPMS/
+...
+
+
+# SGE
+
+## service SGE
+
+
+D'un point de vue *service*, SGE (_pour rappel OGS dans notre cas_) comprend le processus sge_qmaster qui tourne sur le port 536 par défaut côté noeud maître. Ce démon peut être appelé avec le script de service ```bash
+cat /etc/init.d/sgemaster.`hostname -s`
+```
+Il est possible de relancer le service sans perdre les jobs qui tournent avec ```bash
+service sgemaster.{votre hostname} softstop
+``` puis ```bash
+service sgemaster.{votre hostname} start
+```
+
+Du côté des esclaves, le processus sge_execd tourne sur le port 537 et correspond au script de service ```bash
+/etc/init.d/sgeexecd.`cat $SGE_ROOT/$SGE_CELL/common/act_qmaster |cut -f1 -d.`
+```
+Vous pouvez redémarrer ce service proprement de la même manière que pour le noeud maître.
+
+Toutes les variables d'environnement SGE sont chargées par un fichier _profile_. Dans rocks, ce fichier est ```/etc/profile.d/sge-binaries.{c,}sh```. Vous pouvez changer le port, le chemin vers SGE...
+
+> **Comment** Dans les _Debian like_ le port par défaut est différent:
+```bash
+# cat /etc/services |grep sge
+sge-qmaster	6444/tcp	sge_qmaster	# Grid Engine Qmaster Service
+sge-qmaster	6444/udp	sge_qmaster
+sge-execd	6445/tcp	sge_execd	# Grid Engine Execution Service
+sge-execd	6445/udp	sge_execd
+```
+
+### Logs et debug SGE
+
+#### Logs
+
+Les logs de SGE se trouvent du côté du noeud maître dans le fichier ```$SGE_ROOT/$SGE_CELL/spool/qmaster/messages``` et dans ```$SGE_ROOT/$SGE_CELL/spool/compute-0-n/messages``` (ou n correspond au _rank_ du compute d'un point de vue _RocksCluster_).
+
+Dans le cas où vous utiliseriez SGE sans RocksCluster ou que vous Modifiez la configuration par défaut, les logs peuvent aussi se trouver dans /var/spool ou /tmp.
+
+
+#### Debugs
+
+```bash
+qstat -f
+```
+Peut renvoyer pas mal d'informations.
+
+Vous pouvez vérifier ensuite que execd accepte les jobs sur le port 537 :
+
+```bash
+qping compute-0-0.local 537 execd 1
+```
+
+Inversement, vous pouvez aussi vérifier qu'un noeud peut se connecter au noeud maître :
+
+```bash
+ssh compute-0-0 "qping -info MASTER_NAME 536 qmaster 1"
+ssh compute-0-0 "qping -f MASTER_NAME 536 qmaster 1"
+```
+
+## Autres commandes SGE utiles
+
+
+> **Info** La plupart de ces autres commandes ne sont accessibles  qu'à un manager/opérateur SGE. Néanmoins, un utilisateur peut faire certaines de ces commandes sur ses propres jobs.
+
+### qdel
+
+Tuer un job:
+```bash
+qdel [-f] job_id
+```
+ou:
+```bash
+qdel -u user
+```
+Pour tuer tous les jobs associés à un utilisateur.
+
+### qresub
+
+Pour resoumettre un job:
+```bash
+qresub
+```
+> **Note** Attention à exécuter un qresub avec l'utilisateur qui a lancé le job à l'origine si vous souhaitez qu'il y ai accès...
+
+### qalter
+
+Pour modifier un job en attente (priorité, queue, etc...):
+```bash
+qalter
+```
+
+### qmod
+
+```qmod``` Permet Modifier une queue ou un job qui tourne.
+
+Nettoyer un job qui a le statut en erreur:
+```bash
+qmod -cj job_id
+```
+
+Il est également possible d'appliquer cette action sur une queue:
+```bash
+qmod -cq nom_de_la_queue
+```
+
+### qselect
+
+Vous pouvez sélectionner une queue avec ```qselect```.
+Dans quel but ? Quelques exemples:
+
+Lister les noeuds d'une queue:
+```bash
+qselect -q nom_de_la_queue
+```
+Sélectionner les queues dont un utilisateur à accès:
+```bash
+qselect -U toto
+```
+Désactiver une queue:
+```bash
+qmod -d `qselect -q nom_de_la_queue`
+```
+Réactiver une queue:
+```bash
+qmod -e `qselect -q nom_de_la_queue`
+```
+
+### qhold
+
+Vous pouvez suspendre un job avec ```qhold```
+```bash
+qhold job_id
+```
+Ou tous ceux d'un utilisateur avec:
+```bash
+qhold -u user
+```
+
+### qrls
+
+Opposé de ```qhold```. S'utilise de la même manière.
+
+### qrsub
+
+Permet de faire une réservation "avancée" (Advance Reservation (AR)) de machine(s) par SGE [qrsub](http://gridscheduler.sourceforge.net/htmlman/htmlman1/qrsub.html). Il faut penser à préciser une durée maximum des jobs sur ces machines si l'on veut être en mesure d'utiliser les AR. Ainsi, il sera même possible de faire du _Backfilling_: https://arc.liv.ac.uk/repos/darcs/sge/doc/devel/rfe/resource_reservation.txt
+
+### qrstat
+
+Permet de voir l'état des réservations.
+
+### qrdel
+
+Permet de supprimer une réservation
+
+
+## Backup SGE
+
+Editez le fichier ```$SGE_ROOT/util/install_modules/backup_template.conf```, puis:
+```bash
+cd $SGE_ROOT
+./inst_sge -bup -auto /opt/gridengine/util/install_modules/backup_template.conf
+```
+
+La restauration se fait simplement avec:
+```bash
+cd $SGE_ROOT
+./inst_sge -rst
+```
+
+## A propos des options de soumission SGE
+
+Il est possible de prédéfinir certaines options de soumission pour un utilisateur dans le fichier ```$SGE_ROOT/$SGE_CELL/sge_request```. Ca permet par exemple de définir une limite de temps, une queue par défaut, ou toute autre option.
+
+### Autres options de soumission utiles
+
+Tableau de jobs (utile sur des simulations pour des applications non parallélisées (ou mal)):
+```#$ -t n[-m[:s]]```
+avec:
+- *n*: valeur du premier index si *m* est spécifié, sinon, taille du tableau
+- *m*: valeur du dernier indice du tableau
+- *s*: pas pour passer d'un indice à l'autre.
+On récupère ensuite l'ID dans le noeud d'exécution avec la variable ```$SGE_TASK_ID```
+
+
+Soumettre sur un noeud spécifique:
+```#$ -l hostname=compute-0-0```
+
+Pour attendre qu'un job se termine avant de passer à la suite (utile pour des enchainements de qsub avec des tableaux de jobs par exemple...):
+```#$ -sync y```
+
+Pour le reste, ```man qsub```.
+
+
+## Noeud SGE: Suppression
+
+
+ <a id="suppression_sge"></a> On désactive le noeud:
+```bash
+qmod -d all.q@compute-0-0.local
+```
+On attend que les jobs se terminent sur ce noeud, puis on arrête le démon d'exécution local:
+```bash
+qconf -ke compute-0-0.local
+```
+On le supprime de la queue où il est présent, en éditant celle-ci:
+```bash
+qconf -mq all.q
+```
+On le supprime des éventuels groupes de machines dont il est membre:
+```bash
+qconf -mhgrp @allhosts
+```
+On le supprime en tant que noeud d'exécution:
+```bash
+qconf -de compute-0-0.local
+```
+Et on le supprime éventuellement en tant que noeud de soumission:
+```bash
+qconf -ds compute-0-0.local
+```
+Enfin on supprime sa configuration:
+```bash
+qconf -dconf compute-0-0.local
+```
+
+# Ganglia
+
+Il s'agit d'une application de monitoring très connue dont les données sont stockées par type, et dans le temps, dans une base RRD [fiche plume RRDtool](https://www.projet-plume.org/fiche/rrdtool).
+
+Ce service est composé essentiellement de deux démons: ```gmond``` qui sert à recueillir les données et ```gmetad``` afin de les recueillir/agréger.
+
+Vous pouvez accéder à l'interface de ganglia depuis le noeud maître en ouvrant un navigateur à la page http://127.0.0.1/ganglia ou depuis une autre machine en mettant son adresse IP.
+
+Par ailleurs, il est possible de rajouter des données à monitorer en combinant Ganglia à [collectl](http://collectl.sourceforge.net/). Il faut alors rajouter un module en python _collectl.py_ à Ganglia.

book.json

+{
+    "language": "fr",
+    "plugins": ["toc","wide","sectionx","richquotes"],
+    "pluginsConfig": {
+        "addClass": true,
+        "className": "toc"
+        }
+}

correct_title_href.sh

+#!/bin/bash
+
+if [ -d $1 ];then 
+    echo "replacing href link with kimura website"
+    title=`head -1 README.md | cut -d"#" -f2 |sed "s|^ ||g"`
+    find $1 -type f -print0 | xargs -0 sed -i "s|<a href=\"./\" >$title|<a href=\"http://cbi.isem.univ-montp2.fr\" target=\"_blank\" >$title|g"
+fi