FLASH INFORMATIQUE FI



public averti Unification de logins et système de files d’attente : l’expérience SuperB


Les clusters de calcul sont devenus tellement courants que chaque laboratoire dont la recherche nécessite des calculs souhaite en avoir un. Par contre, la multiplication des petits clusters augmente le fardeau administratif. Par exemple, chaque cluster a son propre système d’authentification et souvent les utilisateurs collaborant avec plusieurs unités observent une multiplication de leurs comptes. De plus, à un certain instant, un cluster peut être surbooké pendant que les autres sont vides. Dans cet article, nous décrivons une procédure d’unification de logins et files d’attente qui nous a permis de résoudre ces problèmes tout en gardant l’indépendance de chaque cluster.



Computing clusters have lately become so common that every lab performing research involving HPC wants to have its own. However, the multiplication of small local clusters also increases the administration burden - for instance, each cluster has its own authentication method, and users belonging to more labs see their accounts multiply. Moreover, at a given moment, one cluster may be overbooked while the others are under used. In this article, we describe a procedure to unify logins and queues in order to overcome these problems while keeping each cluster’s independence.


Vittoria REZZONICO


La Faculté des Sciences de Base compte dans sa salle machine à peu près 20 clusters de laboratoire. Les membres de la FSB soit appartiennent à une unité qui possède un cluster, soit demandent un compte sur un cluster partagé (DIT, Pleiades).
Le DIT met à disposition les ressources HPC suivantes [1] :

  • quatre clusters centraux, dont trois à accès payant et un à accès gratuit ;
  • un BlueGene/P] ;
  • une grille de calcul, à accès gratuit ;
  • des plates-formes expérimentales à accès gratuit.

De plus, le cluster partagé Pléiades est accessible moyennant une taxe d’entrée.
Les clusters de laboratoire sont achetés pour avoir du temps de calcul à la demande et de façon instantanée. Comme ils appartiennent à un petit groupe de personnes, ils sont parfois sous-utilisés. Les membres du laboratoire ont accès à ces ressources, et les collaborations entre unités font que certaines personnes ont une multitude de comptes. Depuis août 2007, la plupart des clusters des laboratoires sont administrés au niveau facultaire. Ceci nous a permis d’identifier les problèmes pratiques (comme les utilisateurs qui oublient qu’ils ont accès à plusieurs ressources) ou simplement économiques (charges inégales dans les différents clusters).
En janvier 2009, nous avons décidé de récupérer les cycles CPU perdus sur nos clusters, et plusieurs solutions étaient envisageables :

  • insérer les clusters dans la grille de l’EPFL ;
  • unifier les clusters en un gros cluster hétérogène auquel n’importe qui ayant payé une partie aurait accès ;
  • introduire un super-master qui s’occuperait uniquement de l’authentification et du scheduling.

La grille de calcul de l’EPFL compte à peu près 1300 machines hétérogènes, lesquelles sont utilisées par leur propriétaire le jour et sont mises à disposition pour des calculs la nuit, quand les propriétaires ne les utilisent pas. La plupart de ces machines se trouvent dans les salles pour étudiants. Vu la nature de la grille de calcul, les jobs y tournant doivent :

  • être mono-processeur ;
  • durer au maximum 4 heures (avec possibilité de checkpointing) ;
  • être soit compilés, soit utiliser Matlab, R, Maple, Octave ou PovRay.

Certains utilisateurs ne sont pas gênés par les restrictions imposées, mais beaucoup d’utilisateurs de la FSB souhaitent lancer des calculs dont la durée dépasse 8 heures. De plus, ils ont exprimé le besoin d’exécuter parfois des petits jobs parallèles.
À cause de la nature des clusters pré-existants (appartenance à un labo), les joindre en une seule entité poserait trop de défis administratifs et politiques. En outre, les propriétaires préfèrent que seuls des membres de la FSB aient accès à leurs noeuds.
Les raisons indiquées ci-dessus conduisent à opter pour la dernière option : ajouter un Super-Master gérant les files d’attente et l’authentification.

Avant SuperB

Début 2009 nous avons décidé de fédérer 4 clusters ; chacun était installé comme suit :

  • Linux Debian Etch, upgrade à Debian Lenny planifié,
  • authentification NIS, chaque master étant un serveur NIS indépendant,
  • home directories exportées par NFS depuis le master,
  • système de queues (gestionnaire de ressources et ordonnanceur de tâches) installés sur chaque master. Plusieurs files d’attente existent pour chaque cluster, mais les utilisateurs ne doivent rien spécifier - une file de routage distribue les jobs dans la bonne file d’exécution en fonction des propriétés du job (nombre de processeurs, droits de l’utilisateur, temps CPU demandé). Un mapping entre queues et noeuds est défini. Les files d’attente sont gérées par Torque (partie gestionnaire de ressources) et Maui (ordonnancement).

Buts

Nous aurons deux types d’utilisateurs dans notre système :

  • les utilisateurs propriétaires qui appartiennent à un laboratoire qui a acheté du hardware ;
  • les utilisateurs invités qui n’ont rien payé pour le matériel.

Les utilisateurs pré-existants ne doivent remarquer aucune différence entre l’ancien et le nouveau système. De plus, ils doivent être capables de se connecter sur n’importe quel master et lancer des exécutions sur leurs propres noeuds, ainsi que sur des noeuds appartenant à d’autres labos.
Les utilisateurs invités doivent avoir la possibilité de lancer des jobs sur n’importe quel noeud du système, et doivent avoir un home directory.

Authentification, identification et home directories

Les home directories de chaque cluster doivent être montés par tous les clusters. Donc chaque noeud master doit donner accès dans le répertoire /home :

  • aux homes sur le master lui-même,
  • aux homes montés depuis les autres masters, À cet effet nous configurons un serveur NIS sur le Super-Master et nous utilisons autofs pour monter les homes.

Soumission de jobs

Les jobs des propriétaires des clusters doivent tourner comme si les invités n’étaient pas là :

  • dans une queue, les jobs des propriétaires s’exécuteront toujours avant ceux des invités (priorité absolue) ;
  • quand un noeud est occupé par des jobs d’invités, et que le propriétaire souhaite exécuter les siens, les jobs des invités doivent céder la place.

Les invités doivent pouvoir lancer des jobs depuis le Super-Master, afin de ne pas polluer les masters pré-existants.

La solution : SuperB - le Super-Master de la FSB

Le Super-Master (dorénavant appelé SuperB), joue le rôle de serveur master NIS. Un serveur Torque et le Scheduler Maui y sont aussi installés. En plus, SuperB héberge les home directories des invités.

PNG - 11.4 ko
les clusters charon et kobal et le Super Master SuperB

Pour décrire la configuration du système, nous allons simplifier un peu la vraie configuration actuellement en production. Pour cet article, les clusters préexistants s’appellent charon et kobal. Charon a un master (serveur de gestion + home directories) et un front-end séparés en plus des noeuds de calcul. Le master de kobal fait aussi lieu de front-end. Kobal a aussi ses noeuds de calcul. La figure montre la configuration détaillée de charon, kobal et SuperB.

Le serveur NIS

Les masters de charon et kobal seront configurés comme esclaves NIS de SuperB. Les noeuds de calcul utiliseront comme serveurs NIS leur master et SuperB.

Les homes directories

Les répertoires homes seront accessibles au chemin /home/username depuis tous les noeuds et les frontends, et seront stockés dans /srv/home/username sur leur master, ou sur SuperB si l’utilisateur est un invité.
Chaque machine utilisera autofs pour faire le montage :

  • en mode bind si la machine est un master et si l’utilisateur a son home stocké dessus ;
  • sinon via nfs.

La map auto.home sera distribuée par NIS depuis SuperB.

Le système de queues et le scheduler

Avant l’intégration dans SuperB, chaque cluster avait des files d’attente définies selon les souhaits de ses propriétaires. Ces files d’attente seront transférées sur SuperB, qui par conséquent en aura une quantité non négligeable. Une modification très mineure du code source de Maui a été nécessaire pour pouvoir accommoder cette quantité non standard de données de configuration des files d’attente.

file d’attente qui a accès nombre de noeuds auxquels la queue a accès
batch tout le monde l0+l1+l2+i0
institut0 membres de l’institut i0
inst0lab0 membres du lab0 l0 + i0
inst0lab1 membres du lab1 l1 + i0
lab2 membres du lab2 l2

fig. 2 - exemple de queues dans SuperB. Si un institut finance des noeuds, tous ses labos y auront accès. Donc, si un labo de l’institut achète ensuite ses propres noeuds, il aura accès en même temps aux noeuds du labo et à ceux de son institut.

Dans la figure 2 on remarque une queue batch à laquelle tout le monde a accès : c’est la queue dédiée aux invités. Rappelons-nous que les jobs non-batch ont priorité absolue sur les jobs batch et que ces derniers doivent céder la place aux jobs des propriétaires si nécessaire. Pour cela on utilisera la fonction de preempting présente dans Maui. La préemption consiste à interrompre un job pour le reprendre ou relancer plus tard. Comme le checkpointing n’est pas possible dans notre cas, nous nous contentons d’interrompre brusquement le job par un signal KILL, et ensuite le remettre dans la queue (sauf indication explicite par le propriétaire lors de la soumission du job). Malheureusement, Maui ne permet le preempting que sur certains jobs (voir Preemprive Backfill [1]). Ceci a demandé une adaptation du scheduler qui ne va pas être traitée dans cet article.
Par défaut, la queue de routage enverra le job dans la file la plus restrictive (celle du labo). Si on est propriétaire et que l’on souhaite forcer le job à aller par exemple dans la queue /batch/, il faudra le spécifier.

Routing

Par définition, les seules parties visibles d’un cluster sur le réseau sont le front-end et éventuellement le master. Chaque cluster étant indépendant de chaque autre, aucune machine ne voit tous les noeuds directement. Ceci signifie que SuperB ne voit pas les noeuds. Pour que notre système tienne la route, il faut corriger cela, en rajoutant manuellement les routes vers les noeuds sur SuperB :

#Kobal
route add -net 192.168.19.0 netmask 255.255.255.0 gw X.Y.Z.19
#Charon
route add -net 192.168.7.0 netmask 255.255.255.0 gw X.Y.Z.7

En plus de pouvoir contacter les noeuds directement, il faut que SuperB reconnaisse leur adresse IP. Un cluster par définition masque les paquets pour qu’ils apparaissent provenir du master. Les firewalls de kobal et charon doivent donc être adaptés. Par exemple, le firewall de Kobal devient :

iptables -À FORWARD -i lan0 -s 192.168.19.0/255.255.255.0 -j ACCEPT
iptables -À FORWARD -i wan0 -d 192.168.19.0/255.255.255.0 -j ACCEPT
iptables -t nat -À POSTROUTING -o wan0 -d X.Y.Z.254/32 -j ACCEPT
iptables -t nat -À POSTROUTING -o wan0 -j SNAT --to X.Y.Z.19

La 3e règle du firewall spécifie que la source des paquets en direction de SuperB ne doit pas être modifiée, contrairement à la 4e ligne qui dit de manipuler la source en l’indiquant comme provenance du master. La 3e règle étant appliquée avant la 4e (first match), les paquets en direction de SuperB ignoreront la 4e.
Des modifications additionnelles sont requises pour lancer des jobs MPI à travers plusieurs clusters, mais comme ceci est déconseillé pour plusieurs raisons (plus de complexité dans le preempting, noeuds hétérogènes,...), elles n’ont pas été implantées.

Conclusions

L’expérience SuperB est une évolution par rapport à la situation précédente. Toutes les fonctionnalités de plusieurs clusters isolés ont été implantées, et les utilisateurs peuvent travailler comme si SuperB n’avait jamais été introduit. En plus, on peut offrir du temps CPU pour des calculs séquentiels, mais aussi pour des petits calculs en parallèle.
Seul problème, le scheduler Maui n’est pas très robuste dans cette configuration : il doit d’une part être augmenté par le script de préemption, et en plus il ne supporte pas bien les grosses charges (plus de 5000 jobs en attente par exemple). Une étude est en cours pour envisager un possible changement de scheduler.



Tout membre de la FSB peut demander un compte sur SuperB : il suffit de s’adresser à l’auteur de cet article.

Références

[1] Quinn Snell, Mark J. Clement, and David B. Jackson. Preemption based back-fill. In JSSPP ‘02 : Revised Papers from the 8th International Workshop on Job Scheduling Strategies for Parallel Processing, pages 2437, London, UK, 2002. Springer-Verlag.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.