Clusters et pipelines avec LSF

Aujourd'hui petit mash-up de deux articles pré­cé­dem­ment publiés dans nos colonnes. Comme je l'avais pro­mis, je vais vous pré­sen­ter ma méthode pour faire du pipe­li­ning avec le ges­tion­naire de res­sources de notre clus­ter. Si vous n'avez pas com­pris la phrase pré­cé­dente, je vous invite à aller (re-)lire l'article sur les pipe­lines et celui sur les clus­ters, tout devrait être plus clair. Je vais pré­sen­ter une idée simple : com­ment iden­ti­fier cha­cune de vos com­mandes sur un clus­ter et uti­li­ser cette iden­ti­fi­ca­tion pour les lier dans un pipe­line. Les exemples de l'article sont basés sur le sys­tème de mana­ge­ment LSF, ins­tal­lé sur les clus­ters Vital-it du SIB. Bien qu'il existe des dif­fé­rences avec d'autres sys­tèmes, vous devriez retrou­ver ces fonc­tion­na­li­tés sur cha­cun d'entre eux.

Nommez vos commandes…

Comme vous le savez main­te­nant, avec un pipe­line, on sou­haite enchaî­ner dif­fé­rentes tâches sans avoir à inter­ve­nir. Il faut donc pou­voir dire quand la com­mande 'une' s'est ter­mi­née, pour lan­cer la 'deux'. Pour cela il faut pou­voir créer une chaîne entre nos dif­fé­rentes com­mandes et un bon moyen pour le faire est de toutes les iden­ti­fier.

Pour cela rien de plus simple. LSF pro­pose de don­ner un nom à vos com­mandes avec l'option '-J'.

Cette option est très utile et pas seule­ment pour faire des pipe­lines. Ima­gi­nez que vous ayez 100 fichiers à trai­ter et que vous uti­li­siez le clus­ter pour le faire. Si vous vous aper­ce­vez qu'il y a une erreur sur cer­taines de ces com­mandes, com­ment allez-vous pou­voir arrê­ter juste celles-ci ? Si elles n'ont pas de nom, vous n'avez plus qu'à cher­cher par­mi les 100 com­mandes ou encore tout arrê­ter. Mais si vous avez uti­li­sé l'option '-J' vous pou­vez arrê­ter juste ces com­mandes. De plus avec le sym­bole '*' vous pou­vez arrê­ter toutes les com­mandes avec le même mor­ceau de nom.

'bkill' est la com­mande LSF pour tuer un job et elle prend aus­si l'option '-J'. Ici je tue toutes les com­mandes dont le nom com­mence par 'groupe_​1_​', on peut ima­gi­ner que j'ai un groupe 2 qui lui ne sera pas arrê­té.

Bien, main­te­nant on sait don­ner un nom à nos com­mandes, mais LSF ne sait pas lire, du coup il faut lui dire quelle com­mande doit attendre l'autre.

…puis connectez-les.

<

p style="text-align : justify;">'bsub' a une autre option extrê­me­ment utile : ‑w
Il s'agit en fait d'une option 'wait' et celle-ci est très bien pen­sée. Elle vous per­met d'attendre qu'une autre com­mande soit ter­mi­née et même de véri­fier si elle s'est bien ache­vée ou si une erreur s'est pro­duite. Elle inclut aus­si l'utilisation d'opérateurs logiques (and, or et not) pour pou­voir attendre la fin (ou le lan­ce­ment) de plu­sieurs com­mandes.
Concrè­te­ment, il existe quatre condi­tions pos­sibles : star­ted, done, exit, ended.
Star­ted teste si la com­mande s'est lan­cée, ended si elle s'est ter­mi­née. Pour 'done' et 'ended' je dois pré­ci­ser que, sous GNU/​Linux, chaque com­mande ren­voie à la fin un code. 0 indique que tout s'est bien pas­sé et toutes les autres pos­si­bi­li­tés cor­res­pondent à dif­fé­rentes erreurs. Si je crée une com­mande 1 puis une com­mande 2 avec la condi­tion '-w done(1)' et une com­mande 3 avec la condi­tion 'exit(1)'. La com­mande 2 sera exé­cu­tée seule­ment si la com­mande 1 se ter­mine sans erreur et la com­mande 3 seule­ment si la com­mande 1 se ter­mine avec une erreur. Il est même pos­sible, avec 'exit', d'attendre un code d'erreur spé­ci­fique (1, 2 ou 3 …), ce qui per­met de pré­voir plu­sieurs réac­tions. Voi­ci donc un exemple :

La com­mande 'mes­sa­ger' ne démar­re­ra que si toutes les com­mandes dont le nom com­mence par 'groupe_​1_​' se sont bien ter­mi­nées ou ('||') si toutes les com­mandes dont le nom com­mence par 'groupe_​2_​' se sont bien ter­mi­nées et ('&&') que la com­mande 'trieur' a été lan­cée.

Et voi­la com­ment, avec les outils mis à dis­po­si­tion par le queuing sys­tème, on peut construire un pipe­line. Il suf­fit ensuite de construire un script (en python par exemple) qui crée et nomme les com­mandes pour vous et vous obte­nez un pipe­line per­for­mant.

Ici je vous ai pré­sen­té une seule stra­té­gie, elle n'est pas unique et n'est pas obli­ga­toi­re­ment la meilleure. On pour­rait aus­si uti­li­ser un fichier de log où les com­mandes notent quand elles com­mencent et quand elles se ter­minent et avoir un dis­tri­bu­teur qui lit ce fichier pour savoir quand lan­cer la com­mande sui­vante. Les stra­té­gies sont nom­breuses et vous devez vous adap­ter à votre envi­ron­ne­ment et aux besoins de vos col­lègues.

Mer­ci à Nel­ly, Yoann, Mica et Sp4M pour leur relec­ture.