Comment travailler sur une grappe de serveurs (cluster)

Avec les avan­cées en bio­lo­gie ces der­nières années, la quan­ti­té de don­nées pro­duites et les res­sources infor­ma­tiques néces­saires à leur trai­te­ment ont gran­de­ment aug­men­té. Pour faire face à ces pro­blèmes, l'une des solu­tions les plus répan­dues est la mise en place de grappes de ser­veurs (plus sou­vent dési­gnées par le terme anglais com­pu­ter clus­ter ou sim­ple­ment clus­ter). Sur ces sys­tèmes, les com­mandes à exé­cu­ter sont sou­mises à un ges­tion­naire de res­sources qui répar­tit les tâches sur les ordi­na­teurs du clus­ter. Il existe plu­sieurs solu­tions sur le mar­ché, mais leur com­por­te­ment est sou­vent simi­laire.

Aujourd'hui je vais uti­li­ser l'une d'entre elles, Load Sha­ring Faci­li­ty (LSF), comme exemple pour vous pré­sen­ter cer­taines règles essen­tielles au bon fonc­tion­ne­ment d'un clus­ter. Cela s'adresse aux per­sonnes débu­tantes sur ce type de sys­tème, mais éga­le­ment à ceux qui n'ont pas eu de for­ma­tion avant de tra­vailler sur un clus­ter.

C'est quoi une grappe ?

Une grappe est un réseau d'ordinateurs, indé­pen­dants et inter­con­nec­tés, gérés tous ensemble comme une seule res­source infor­ma­tique. Cette struc­ture offre l'avantage d'additionner les res­sources de toutes les machines ain­si connec­tées dans un seul sys­tème. Par exemple, sur un clus­ter com­po­sé de deux machines ayant 24 pro­ces­seurs et 100 Go de mémoire vive cha­cune, il sera pos­sible d'exécuter une tâche uti­li­sant 48 pro­ces­seurs et 200 Go de mémoire. L'exemple don­né est sur deux machines iden­tiques, mais une grappe peut être com­po­sée d'ordinateurs aux capa­ci­tés dif­fé­rentes (pour en savoir plus : La page wiki­pé­dia sur les grappes). Bien sur c'est un sys­tème com­plexe à gérer et il existe pour cela dif­fé­rents ges­tion­naires de res­sources sur le mar­ché.

Le gestionnaire de ressources

Avoir un clus­ter c'est bien, mais il faut aus­si pou­voir le gérer effi­ca­ce­ment. La per­sonne res­pon­sable de la mise en place du sys­tème va choi­sir les règles, qui s'appliqueront aux uti­li­sa­teurs, grâce au ges­tion­naire de res­sources. Chaque admi­nis­tra­teur a sa façon de faire, qui peut être plus ou moins res­tric­tive. Je vais détailler ici uni­que­ment les règles qui concernent les uti­li­sa­teurs et plus par­ti­cu­liè­re­ment celles que j'ai ren­con­trées. Je fais cette pré­ci­sion car je n'ai cer­tai­ne­ment pas ren­con­tré tout les formes de res­tric­tion et il vous fau­dra peut-être apprendre à gérer d'autres règles.

Habi­tuel­le­ment, en tant qu'utilisateur, on n'a à se sou­cier que de cinq ou six valeurs. Les plus évi­dentes sont celles que l'on retrouve sur tout sys­tème infor­ma­tique, com­bien d'espace sur le disque, de mémoire vive et de CPU sont à dis­po­si­tion. A celles-ci s'ajoutent le nombre de tâches que l'on peut lan­cer simul­ta­né­ment et la limite dans le temps pour celles-ci. C'est prin­ci­pa­le­ment ces options que l'administrateur aura limi­té pour évi­ter tout abus. Si le tra­vail est bien fait, l'utilisateur aura plu­sieurs options, comme lan­cer un tra­vail très inten­sif (beau­coup de mémoire et de CPU) mais qui devra être court ou au contraire, lan­cer une tâche légère mais qui pour­ra tour­ner sur plu­sieurs jours. Ces choix sont repré­sen­tés par ce qu'on appelle les queues, celle-ci sont mise en place par l'administrateur et cor­res­pondent cha­cune à dif­fé­rents besoins et en consé­quence à dif­fé­rentes règles. On peut par exemple ima­gi­ner un sys­tème avec deux queues ; la queue « longue » qui per­met­tra de lan­cer un tra­vail sur 8 CPU mais sans limite de temps et la queue « nor­male » qui per­met­tra de lan­cer un job sur 64 CPU mais celui-ci ne pour­ra pas durer plus de 24h. C'est ensuite à l'utilisateur de choi­sir cor­rec­te­ment dans quelle queue sa tâche devra aller.

Soumettre un travail au cluster

Pour tra­vailler sur une grappe, l’utilisateur s'y connecte en SSH, il pour­ra ensuite tra­vailler comme sur n'importe quel autre sys­tème. Toutes les com­mandes qui vont suivre fonc­tion­ne­ment sur le sys­tème LSF, les com­mandes pour les autres ges­tion­naires de res­sources sont faci­le­ment trou­vables sur Inter­net et vous seront très pro­ba­ble­ment pré­sen­tées le jour où vous devrez tra­vailler sur un clus­ter. Cepen­dant, les règles que je vais pré­sen­ter devraient être appli­quées par tous les uti­li­sa­teurs, quel que soit le ges­tion­naire uti­li­sé.

Si l'administrateur ne vous a pas don­né assez d'informations sur le sys­tème, vous pou­vez com­men­cer par véri­fier quelles queues sont dis­po­nibles et quelles sont les règles qui s'y appliquent. Pour cela, uti­li­sez la com­mande sui­vante :

[/​crayon]

La com­mande bqueue sans l'option « -l » donne un petit résu­mé, bien utile, du sta­tut des queues, com­bien de jobs tournent et com­bien sont en attente, sur cha­cune d'entre elles. Avec l'option « ‑l » elle donne tous les détails sur les limites (mémoire, cpu, temps, nombre de tâches simul­ta­nées…) qui s'appliquent aux queues mises en place par l'administrateur.

Main­te­nant que vous connais­sez mieux le sys­tème, vous pou­vez exé­cu­ter vos pre­mières com­mandes sur le clus­ter. A pre­mière vue, cela peut paraître effrayant, toute cette puis­sance et toutes ces règles… « Lan­cer une tâche sur un clus­ter doit être affreu­se­ment com­pli­qué ! »

# Atten­tion, à ne pas repro­duire chez vous. Lire la suite pour com­prendre pour­quoi.

Pour les nou­veaux sur GNU/​Linux. La com­mande 'ls' sert à lis­ter le conte­nu de votre dos­sier.

Je viens de deman­der au clus­ter de lis­ter le conte­nu du dos­sier cou­rant. 'bsub » (sub pour sub­mit) est la com­mande qui envoie une tâche se faire exé­cu­ter sur la grappe. Le ges­tion­naire va alors véri­fier si il y a la place pour lan­cer la com­mande et l'exécutera si c'est le cas. Ici la com­mande est tel­le­ment petite qu'elle sera, presque à coup sûr, lan­cée immé­dia­te­ment. Et voi­ci un pre­mier conseil, n'utilisez pas une grappe pour faire un tra­vail, comme celui-ci, qui peut tour­ner sur un simple ordi­na­teur. Rien ne vous empê­che­ra de la faire, mais c'est contre-pro­duc­tif, trop de puis­sance est uti­li­sée pour une simple tâche.

Bsub est donc la com­mande magique pour envoyer un tra­vail sur le clus­ter. Je vais ici détailler les options qui per­mettent de lan­cer un tra­vail pro­pre­ment :

Les options « ‑o » et « ‑e » prennent comme argu­ment le nom d'un fichier. Si ces options sont uti­li­sées, le rap­port d'exécution de la com­mande et les éven­tuelles erreurs ren­con­trées seront écrits dans ces fichiers. Le rap­port donne des infor­ma­tions sur la mémoire et les CPU uti­li­sés par la com­mande, cela ser­vi­ra à opti­mi­ser les pro­chaines com­mandes. Le rap­port d'erreur per­met­tra éven­tuel­le­ment de com­prendre ce qui n'a pas mar­ché.

L'option « -q » per­met de choi­sir sur quelle queue le tra­vail sera lan­cé. A l'utilisateur de choi­sir en fonc­tion des besoins.

Les options « ‑n » et « -R » informent le clus­ter des res­sources uti­li­sées par la com­mande, res­pec­ti­ve­ment le nombre de CPU et la quan­ti­té de mémoire (en MB). La com­mande pour­rait éven­tuel­le­ment fonc­tion­ner sans ces deux options, mais il s'agit ici d'informer le sys­tème pour évi­ter l'encombrement. En l'absence de ces options, le sys­tème consi­dé­re­ra que le job uti­lise un seul slot. Un slot est une uni­té de tra­vail sur le clus­ter, l'administrateur déter­mine à quoi cela cor­res­pond. Cela pour­rait par exemple être 2 GB de mémoire et 1 CPU. Dans ce cas si les options « ‑n » et « -R » ne sont pas don­nées et que la com­mande pré­cé­dente est exé­cu­tée, le sys­tème pen­se­ra uti­li­ser 2 GB alors que la com­mande uti­lise 10 GB. Si tout le monde agit ain­si, le sys­tème sera très vite sur­char­gé.

L'option « ‑M » entre dans une autre caté­go­rie. Elle per­met de fixer la limite de mémoire à uti­li­ser pour cette com­mande. En effet, l'administrateur peut déci­der qu'en absence d'information, un job n'utilise pas plus de mémoire que 2 GB. Dans ce cas, si une com­mande uti­lise 3 GB et que l'option « ‑M » n'a pas été don­née, le sys­tème tue la com­mande quand elle dépasse les 2 GB de mémoire uti­li­sée. Il existe plu­sieurs autres options comme celle-ci, pour le nombre de CPU, le temps d'exécution… Je vous laisse les décou­vrir par vous-même si votre sys­tème l'exige.

Fina­le­ment, une der­nière com­mande qui peut ser­vir pour débu­ter sur un clus­ter :

Celle-ci liste les jobs que l'utilisateur a sou­mis au clus­ter et donne leur sta­tut (pen­ding, run­ning, exit…). Elle peut prendre dif­fé­rentes options pour lis­ter de façon plus pré­cise vos tâches (queue, sta­tut…).

Exemple

Voi­ci un exemple des com­mandes décrites dans le para­graphe pré­cé­dent, avec leur résul­tat.

Il y a donc 4 queues sur ce sys­tème. Un uti­li­sa­teur peut avoir 256 jobs tour­nant simul­ta­né­ment sur la queue 'nor­male'. Actuel­le­ment 68 tâches ont été sou­mises à cette queue et 19 tournent sur le clus­ter.

Main­te­nant deman­dons au clus­ter d'exécuter un job sur la queue 'long', en l'informant que la com­mande uti­li­se­ra envi­ron 5GB de mémoire vive.

Véri­fions l'état de notre job avec la com­mande « bjobs ‑all » qui affiche les détails de notre tâche, la com­mande, le dos­sier d'où elle est lan­cée, l'utilisateur, la mémoire uti­li­sée…

Récapitulatif

Commandes :

• bsub : sou­mettre un job

  • « ‑o file » et « ‑e  file »  : per­mettent d'ecrire le stan­dard out­put et stan­dard error dans un fichier
    
  • « ‑q  nom_​queue » : per­met de pré­ci­ser sur quelle queue le job tour­ne­ra
    
  • « ‑M 1000 » : limite de mémoire vive (en KB)
    
  • « ‑R 'rusage[mem=1000]' » : informe le clus­ter de la mémoire uti­li­sée par le job (en MB)
    
  • « ‑n 2  »: informe le clus­ter sur le nombre de cœurs uti­li­sés
    
• bjobs : lis­ter les job sou­mis au clus­ter
  
• bqueues : infor­ma­tions sur les queues
  

Conseils :

1- Ne pas lan­cer de trop petites tâches sur un clus­ter,

2- Véri­fier les dif­fé­rentes queues pro­po­sées,

3- Tou­jours infor­mer le clus­ter de l'énergie requise par une com­mande, pour évi­ter les sur­charges.

Voi­là qui, je l'espère, devrait vous per­mettre de com­men­cer à tra­vailler pro­pre­ment sur un clus­ter. N'oubliez pas que la liste de conseils don­née ici n'est pas exhaus­tive. A vous d'être res­pon­sable et d'utiliser votre clus­ter de la façon la plus civique pos­sible. J'espère aus­si avoir ras­su­ré ceux qui avaient peur à l'idée de tra­vailler sur ce type de machine, cela n'a vrai­ment rien de com­pli­qué. Je ferais peut-être un article sur des exemples d'utilisations plus avan­cées, si cet article sus­cite un inté­rêt. Et bien sûr comme d'habitude, n'hésitez pas à don­ner vos conseils dans les com­men­taires, pour une meilleure uti­li­sa­tion des clus­ters.