> Place centrale > L'informatique à l'EPFL > DIT > publications > FI 10 du 21 décembre 2010 > Version PDA accueil

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

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

version pda

 

Vittoria REZZONICO

pour la version html complète cliquez ici

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] :

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 :

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 :

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 :

Buts

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

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 :

Soumission de jobs

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

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.

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 :

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.