English version

I° Introduction

Afin de prévenir les problèmes causés par une mauvaise utilisation des ressources, nous pensons qu'il est nécessaire de rappeler quelques règles d'usage, qui permettront de réduire le nombre de périodes d'indisponibilité de la machine, ainsi que le temps perdu par les administrateurs à ces occasions.

Il ne s'agit en aucun cas d'astreindre les utilisateurs à des contraintes qui leur feraient perdre du temps. Au contraire, nous pensons que le rappel de ces queqlues règles, permettront de conserver:

• une grande souplesse d'utilisation, permettant aux utilisateurs de prototyper leur code, et d'accéder très facilement à des ressources de calcul suffisante pour répondre à leur besoin.
• une communication, et un partage d'information amicaux entre les différents utilisateurs et entre utilisateurs et administrateurs.

II° Respect des utilisateurs et administrateurs

Il va sans dire, que le respect des différents utilisateurs et des administrateurs est la première des règles. Il est important de bien garder en mémoire:

• qu'il n'y a pas d'utilisateur privilégié de la machine. Par défaut, chacun est soumis aux mêmes règles d'utilisation des ressources. Il est cependant tout à fait possible de faire des dérogations, pour répondre à des besoins exceptionnels, à condition que la décision résulte d'une consultation des différentes personnes affectées par ces exceptions. (les administrateurs en premier lieu).
• les administrateurs de la machine :
  • ne sont pas des spécialistes de l'administration systèmes et réseaux, ni du support utilisateur.
  • n'ont pas été recrutés pour répondre à ce besoin. Ils partagent les mêmes activités que les utilisateurs, tout aussi prenantes et exigeantes. Ils s'arrangent, cependant, pour répondre aussi rapidement que possible, aux différents problèmes matériels et logiciels qui peuvent survenir. Ceci afin de ne pas bloquer le travail en cours des utilisateurs. Il est important de ne pas "polluer" le temps qu'ils consacrent à l'administration, par des questions auxquelles un bon moteur de recherche peut répondre.
  • ils peuvent être consultés pour le passage à l'échelle des codes développés par les utilisateurs. Ces conseils sont donnés dans le cadre de projets à moyen ou long terme, et non dans l'urgence d'un quelconque rendu.

Afin de pallier au manque de ressources humaines de type 'user support', un wiki a été mis en place. Il permet aux administrateurs de passer aisément la main, en cas de départ. Il doit surtout permettre aux utilisateurs de trouver le maximum d'informations dont ils ont besoin, pour profiter au mieux des ressources de la machine (le plus efficacement, et en respectant les règles de bon usage). Il est de la responsabilité des utilisateurs d'alimenter ce wiki.

III° Utilisation des ressources de stockage

Résumé

Comme indiqué sur le wiki, les ressources de stockage sont les suivantes :

/home : 46 Go au total - accès moyen - backup quotidien
/data : 11To au total (1,2To par noeud) - accès lent - pas de backup
/scratch : 150 Go par noeud - accès rapide - suppressions arbitraires possibles.

Réperoire home

Nous demandons de ne pas dépasser 1Go par utilisateur pour ce volume. Si la compilation de certains codes exigent un plus grand espace, nous vous recommandons d'utiliser le /scratch du noeud maître, et de copier le binaire résultant sur votre home.

Répertoire data

Nous demandons de ne pas dépasser 800Go par utilisateur pour ce volume pour de longues périodes de stockage et exceptionnellement 1.5To pour une période de stockage inférieure à un mois. Ce volume ne doit servir qu'à la sauvegarde de données 'finales'. Les accès concurrents (plusieurs jobs accèdent au même fichier en même temps) génèrent des problèmes sur le système de fichiers. En conséquence, il est demandé d'utiliser les répertoires /scratch pour sauvegarder les données auxquelles les codes accèdent.

Il est très important de conserver une juste balance dans l'occupation des différents disques qui contribuent à ce volume (/glfsdata). Lors de la copie de nouvelles données sur le volume /data, le choix d'un disque particulier est dicté par les règles suivantes:

• disque local si la demande est faîte depuis un noeud de calcul.
• un noeud au hasard, si la demande est faîte depuis le noeud maître.

En conséquence, il est demandé d'utiliser /data depuis le noeud maître, pour les volumes de données très importants.

Vu l'évolution constatée de l'occupation de ce volume, nous demandons à chaque utilisateur de veiller à ne pas conserver des données devenues obsolètes. Un rappel en ce sens sera envoyé à la mailing liste chaque mois.

Répertoire scratch

Le répertoire /scratch sert à la sauvegarde des données accédées par les différents jobs. C'est une zone tampon, qu'il convient de nettoyer à la fin de chaque job.

Attention, le répertoire /tmp ne peut être utilisé que par les routines vitales du système. Il est très important de vérifier que les différents codes utilisent /scratch pour les fichiers temporaires. En général, cet emplacement est déduit de la variable d'environnement TEMPDIR que l'on peut redéfinir depuis son fichier de configuration bash personnel. export TEMPDIR=/scratch/username

IV° Utilisation des ressources de calcul

Il n'y a qu'un seul moyen d'utiliser les ressources de calcul du cluster, ce moyen est la soumission d'un job au scheduler. Tout autre réquisition de ressources (calcul lancé depuis une connexion ssh sur un noeud de calcul, ou sur le noeud maître) est susceptible:

• d'entraîner une surcharge des ressources,
• de léser les autres utilisateurs.

Ces deux conséquences vont à l'encontre des principes de respect rappelés plus haut, et ne peuvent être tolérées.

Seule la soumission de job via le scheduler permet une juste répartition et une préservation des ressources.

Il est important de veiller à déclarer précisemment les ressources utilisées. Pour ce faire, une seule option est à spécifier, il s'agit du nombre de coeurs (CPU). Chaque noeud de calcul offre 8 CPUs et 16Go de mémoire vive. Le nombre de coeurs déclaré doit refléter l'occupation de ces deux éléments. Par exemple, un code qui n'utilise qu'un seul CPU, mais 8Go de mémoire, doit déclaré 4 coeurs.

Pour répondre au besoin d'intéractivité (pendant la phase de debuggage par exemple), il est possible d'utiliser la commande qsub intéractive, comme expliqué dans le wiki.

V° Utilisation des jetons IDL

Chaque session IDL ouverte récquisitionne 6 jetons du Centre de Calcul de Lyon. Les pénuries de jetons étant assez courantes, veillez à les utiliser avec modération. Pour cette raison, IDL ne peut pas être utilisé à des fins de calcul parallèle.

VI° Conclusion

Pour toute question ou discussion relative à ce document, nous vous demandons d'utiliser la page wiki correspondante, ou la mailing liste. Il sera tenu à jour en fonction:

• des compléments et modifications suggérées
• de tout changement matériel