La présente invention concerne l'administration de systèmes informatiques complexes et plus particulièrement un procédé et un dispositif de traitement de commandes d'administration dans un cluster.

Le calcul haute performance, aussi appelé HPC (sigle de High Performance Computing en terminologie anglo-saxonne) se développe pour la recherche universitaire comme pour l'industrie, notamment dans des domaines techniques tels que l'aéronautique, l'énergie, la climatologie et les sciences de la vie. La modélisation et la simulation permettent en particulier de réduire les coûts de développement, d'accélérer la mise sur le marché de produits innovants, plus fiables et moins consommateurs d'énergie. Pour les chercheurs, le calcul haute performance est devenu un moyen d'investigation indispensable.

Ces calculs sont généralement mis en œuvre sur des systèmes de traitement de données appelés clusters. Un cluster comprend typiquement un ensemble de nœuds interconnectés. Certains nœuds sont utilisés pour effectuer des tâches de calcul (nœuds de calcul), d'autres pour stocker des données (nœuds de stockage) et un ou plusieurs autres gèrent le cluster (nœuds d'administration). Chaque nœud est par exemple un serveur mettant en œuvre un système d'exploitation tel que Linux (Linux est une marque). La connexion entre les nœuds est, par exemple, réalisée à l'aide de liens de communication Ethernet ou Infiniband (Ethernet et Infiniband sont des marques). Chaque nœud comprend généralement un ou plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication.

La figure 1 illustre schématiquement un exemple d'une topologie 100 d'un cluster, de type fat-tree. Ce dernier comprend un ensemble de nœuds génériquement référencés 105. Les nœuds appartenant à l'ensemble 1 10 sont ici des nœuds de calcul tandis que les nœuds de l'ensemble 1 15 sont des nœuds de service (nœuds de stockage et nœuds d'administration). Les nœuds de calcul peuvent être regroupés en sous-ensembles 120 appelés îlots de calcul, l'ensemble 1 15 étant appelé îlot de service.

Les nœuds sont reliés les uns aux autres par des commutateurs (appelés switch en terminologie anglo-saxonne), par exemple de façon hiérarchique. Dans l'exemple illustré sur la figure 1 , les nœuds sont connectés à des commutateurs 125 de premier niveau qui sont eux-mêmes reliés à des commutateurs 130 de deuxième niveau qui sont à leur tour reliés à des commutateurs 135 de troisième niveau.

Les nœuds d'un cluster ainsi que d'autres éléments tels que les commutateurs sont souvent regroupés dans des armoires informatiques, aussi appelées racks en terminologie anglo-saxonne, qui peuvent elles-mêmes être regroupées par îlots. Par ailleurs, pour assurer un bon fonctionnement des éléments contenus dans une armoire informatique, cette dernière comprend généralement un système de refroidissement, par exemple une porte refroidissante (souvent appelée porte froide).

La gestion d'un cluster, notamment le démarrage, l'arrêt ou la mise à jour logicielle d'éléments du cluster, est typiquement réalisée à partir de nœuds d'administration à l'aide de processus prédéterminés ou directement par un opérateur. Certaines opérations telles qu'une mise en route ou une mise à l'arrêt de l'ensemble du cluster, d'îlots ou d'armoires informatiques, peuvent également être réalisées manuellement, par nœud ou par armoire informatique.

Il a été observé que si les problèmes liés à la gestion de clusters n'ont généralement pas d'influence directe sur les performances d'un cluster, ils peuvent être critiques. Ainsi, par exemple, si un problème de refroidissement d'une salle abritant des armoires informatiques est détecté, il est souvent nécessaire d'arrêter rapidement au moins partiellement le cluster pour éviter une surchauffe d'éléments qui pourrait notamment conduire à la détérioration de matériel et/ou la perte de données.

Il existe donc un besoin pour améliorer la gestion de clusters, notamment pour traiter des commandes d'administration.

L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé pour ordinateur de traitement d'au moins une commande visant au moins un élément d'un cluster, ledit cluster comprenant une pluralité d'éléments, ledit au moins un élément ayant un lien de dépendance selon ladite au moins une commande avec au moins un autre élément de ladite pluralité d'éléments, ce procédé comprenant les étapes suivantes,

- identification dudit au moins un élément de ladite pluralité d'éléments ;

- identification d'au moins une règle de dépendance à partir de ladite au moins une commande ;

- génération d'un graphe de dépendances à partir dudit au moins un élément identifié, en application de ladite au moins une règle de dépendance identifiée, ledit graphe de dépendances comprenant des sommets représentant au moins ledit élément et ledit au moins un autre élément, une action liée à ladite au moins une commande étant associée aux sommets dudit graphe de dépendances ; et,

- génération d'une séquence d'instructions à partir dudit graphe de dépendances.

Le procédé selon l'invention permet ainsi de générer, à partir d'une commande et d'identifiants d'éléments d'un cluster, une séquence d'instructions satisfaisant des contraintes relatives à des actions visant des éléments de ce cluster. Le procédé selon l'invention permet de traiter des commandes dans un cluster hétérogène, pouvant évoluer, facilitant l'administration du cluster, notamment en réduisant le nombre et les noms de commandes.

De façon avantageuse, une fonction d'identification d'éléments et une règle de dépendance sont associées à ladite au moins une règle de dépendance identifiée, le procédé comprenant en outre une étape d'identification d'au moins ledit autre élément à partir de ladite fonction d'identification, ledit graphe de dépendances étant généré à partir dudit au moins un élément identifié, dudit au moins un autre élément, de ladite au moins une règle de dépendance identifiée et de ladite règle de dépendance associée à ladite au moins une règle de dépendance identifiée. Le procédé selon l'invention permet ainsi, de façon récursive, de déterminer l'ensemble des éléments impliqués dans l'exécution de la commande traitée, selon différents niveaux de granularité des éléments (matériels ou logiciels).

Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'affichage d'informations relatives audit graphe de dépendances, ladite étape de génération de ladite séquence d'instructions étant effectuée en réponse à une validation desdites informations affichées relatives audit graphe de dépendances. Ainsi, conformément au procédé selon l'invention, un utilisateur peut visualiser le graphe de dépendances afin, notamment, de le valider, le modifier ou modifier des règles de dépendances pour regénérer, le cas échéant, un nouveau graphe de dépendances.

Toujours selon un mode de réalisation particulier, ladite étape de génération d'un graphe de dépendances est récursive et comprend les étapes suivantes,

- création d'un graphe de dépendances initial comprenant au moins ledit au moins un élément ;

- sélection d'un élément dans ledit graphe de dépendances

- identification d'au moins un élément dont dépend ledit élément sélectionné au regard d'une règle de dépendance ; et,

- modification dudit graphe de dépendances selon ledit élément sélectionné et ledit au moins un élément identifié dont dépend ledit élément sélectionné au regard d'une règle de dépendance.

Le procédé selon l'invention permet ainsi de construire simplement et efficacement un graphe de dépendances à partir duquel peut être générée une séquence d'instructions satisfaisant des contraintes relatives à des actions visant des éléments de ce cluster pour traiter une commande.

De façon avantageuse, ladite étape de sélection d'un élément dans ledit graphe de dépendances est basée sur un graphe de règles, ledit graphe de règles étant une représentation ordonnée de ladite au moins une règle de dépendance identifiée et de règles de dépendances directement ou indirectement associées à ladite au moins une règle de dépendance identifiée. Le procédé selon l'invention permet ainsi de trouver simplement et efficacement un ordre d'exécution d'actions sur des éléments d'un cluster selon des contraintes prédéterminées.

Selon un mode de réalisation particulier, ladite étape de génération d'une séquence d'instructions comprend la génération d'au moins un groupe d'instructions pour chaque niveau dudit graphe de dépendances. Le procédé selon l'invention permet ainsi une gestion intelligente de pannes pour éviter la perte de données et l'endommagement de matériel tout en exécutant autant que possible les instructions définies selon la commande visée.

Toujours selon un mode de réalisation particulier, ladite séquence d'instructions est générée sous forme d'un fichier de type XML, une balise de niveau étant associée à chaque niveau dudit graphe de dépendances et une balise de groupe étant associée à chaque groupe d'instructions pour chaque balise de niveau correspondant à un niveau pour lequel il existe au moins deux groupes d'instructions distincts. Le procédé selon l'invention offre ainsi une lecture aisée des séquences d'instructions liées à une commande qui peuvent alors être vérifiées et/ou modifiées simplement tout en limitant les risques d'erreurs pour un utilisateur.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'exécution de ladite séquence d'instructions.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'affichage d'informations relatives à ladite séquence d'instructions, ladite étape d'exécution de ladite séquence d'instructions étant effectuée en réponse à une validation desdites informations affichées relatives à ladite séquence d'instructions. Ainsi, conformément au procédé selon l'invention, un utilisateur peut visualiser ladite séquence d'instructions afin, notamment, de la valider, la modifier ou modifier des règles de dépendances ou le graphe de dépendances utilisé pour regénérer, le cas échéant, une nouvelle séquence d'instructions.

De façon avantageuse, des instructions relatives à deux niveaux distincts du graphe de dépendances sont exécutées de façon séquentielle et selon lequel des instructions de groupes d'instructions distincts d'un même niveau du graphe de dépendances sont exécutées de façon parallèle. Le procédé selon l'invention permet en outre d'effectuer en parallèle des actions visant plusieurs ensembles d'éléments afin, notamment, d'optimiser le temps d'exécution d'une commande.

L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur et un dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment.

D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :

- la figure 1 illustre un exemple de topologie d'un cluster ;

- la figure 2 illustre un exemple de mise en œuvre de certaines phases du procédé selon l'invention ;

- la figure 3 représente un exemple de relations de dépendances entre des éléments d'un cluster ;

- la figure 4 illustre un exemple de graphe de règles ;

- la figure 5 illustre certaines étapes d'un exemple d'algorithme récursif utilisé pour générer un graphe de dépendances conformément à l'invention ;

- la figure 6, comprenant les figures 6a à 6f, illustre la mise en œuvre de l'algorithme décrit en référence à la figure 5 selon l'exemple décrit en référence aux figures 3 et 4 ; et,

- la figure 7 illustre un exemple de dispositif adapté à mettre en œuvre l'invention ou une partie de l'invention.

L'invention a notamment pour objet la génération de séquences d'instructions permettant l'exécution de commandes d'administration de clusters. De telles commandes sont, par exemple, l'arrêt ou la mise en route d'un cluster ou d'une partie d'un cluster telle que des armoires informatiques ou des îlots (ensemble d'armoires informatiques). L'invention permet de limiter le temps d'exécution de ces commandes et faciliter la maintenance de clusters, en tenant compte des spécificités de chaque équipement.

Le procédé selon l'invention comprend essentiellement trois phases, la génération d'un graphe de dépendances, la génération d'une séquence d'instructions et l'exécution de cette séquence d'instructions. Un graphe de dépendances est ici obtenu à partir de règles de dépendances, d'une liste d'éléments du cluster sur lesquels la commande d'administration doit être appliquée ainsi que de la configuration de ces éléments. Ce graphe peut, par exemple, indiquer qu'une porte froide d'une armoire informatique donnée ne peut être arrêtée qu'après que les serveurs contenus dans cette armoire informatique aient été arrêtés.

La séquence d'instructions générée est conforme aux contraintes de dépendances exprimées dans le graphe de dépendances. Ainsi, à titre d'illustration, cette séquence peut indiquer que des nœuds donnés peuvent être arrêtés en parallèle tandis que des nœuds donnés et une porte froide donnée doivent être arrêtés de façon séquentielle. Elle est avantageusement optimisée selon les instructions pouvant être exécutées de façon parallèle. Enfin, l'exécution de cette séquence d'instructions tient compte, de préférence, des erreurs. Ainsi, par exemple, si un serveur n'a pas été correctement arrêté de façon logicielle, il convient de ne pas éteindre l'unité d'alimentation électrique (ou PDU, sigle de Power Distribution Unit en terminologie anglo-saxonne) dont il dépend.

La figure 2 représente un exemple de mise en œuvre de ces trois phases, implémentées dans un générateur de graphe de dépendances 200, un générateur d'instructions 205 et un exécuteur d'instructions 210, respectivement.

Le générateur de graphe de dépendances 200 repose ici sur l'utilisation d'une liste d'éléments, référencée 215, de règles de dépendances, référencées 220, et de données 225 caractérisant les éléments et les liens les unissant. Il permet d'obtenir un graphe de dépendances 230 à partir duquel peuvent être générées des séquences d'instructions. Le graphe de dépendances est avantageusement obtenu à l'aide, notamment, d'un graphe de règles, caractérisant les liens de dépendances entre les règles d'un même ensemble de règles de dépendances, qui permet d'identifier des racines pouvant être utilisées pour déterminer un ordre d'application d'actions à des éléments, comme décrit ci-après.

Le graphe de dépendances 230 peut être vérifié par un utilisateur (étape 235) qui peut le valider, le modifier ou modifier ou ajouter des règles de dépendances pour re-générer un nouveau graphe de dépendances.

Le graphe de dépendances 230 est utilisé par le générateur d'instructions 205 pour générer une séquence d'instructions 240 permettant d'effectuer la commande d'administration visée sur les éléments déterminés selon des règles de dépendances identifiées selon cette commande.

La séquence d'instructions 240 peut être vérifiée par un utilisateur (étape 245) qui peut la valider, la modifier, modifier le graphe de dépendances 230 ou modifier ou ajouter des règles de dépendances pour re-générer un nouveau graphe de dépendances et re-générer une nouvelle séquence d'instructions.

La séquence d'instructions 240 peut alors être exécutée par le générateur d'instructions 210. Une séquence d'instructions peut être générée lorsqu'une commande d'administration visant un ensemble d'éléments déterminés doit être exécutée ou de façon anticipée pour permettre son exécution lorsqu'une commande visant un ensemble d'éléments déterminés doit être exécutée sans qu'il soit nécessaire de générer la séquence d'instructions correspondante (la séquence d'instructions peut ainsi être exécutée immédiatement).

Il est observé ici que si l'algorithme décrit en référence à la figure 2 permet à un utilisateur de contrôler chaque phase, les phases de génération de graphe de dépendances, de génération de séquences d'instructions et d'exécution de ces séquences peuvent être exécutées les unes à la suite des autres, de façon transparente pour l'utilisateur.

La liste d'éléments 215 identifie l'ensemble des éléments sur lesquels s'applique une commande d'administration à traiter. A titre d'illustration, cette liste peut s'exprimer par un ensemble d'expressions de la forme suivante :

componentNamePrefix[a-b, c-d, ...] #type @ category

où

- componentNamePrefix[a-b, c-d, ...] est une notation standard contractée pour designer un ensemble de noms d'éléments ayant le préfixe componentNamePrefix et un suffixe égale à une valeur prise dans les intervalles [a-b], [c-d], etc. ;

- type est une description de l'élément considéré. Ainsi, par exemple, si l'élément considéré est un nœud, le type peut être égal à compute pour indiquer qu'il s'agit d'un nœud de calcul. Les types d'éléments sont décrits plus en détail ci-après ; et,

- category est la catégorie de l'élément considéré par rapport aux catégories définies dans une base de données définissant les éléments d'un cluster (généralement appelée cluster database ou clusterDB). A titre d'illustration, les catégories définies dans la clusterDB utilisée sont par exemple les suivantes,

o hwmanager ou hw (cette catégorie désigne des contrôleurs d'éléments matériels, notamment de type BMC (sigle de Baseboard Management Controller en terminologie anglo- saxonne)) ;

o disk-array ou da (cette catégorie désigne typiquement des baies de stockage) ;

o switch (cette catégorie désigne typiquement des commutateurs, par exemple de commutateurs de type Ethernet, Infiniband ou

PDU) ;

o node (cette catégorie désigne typiquement des nœuds, par exemple des nœuds de calcul, d'entrée/sortie ou de gestion) ; o hw_group et rack (ces catégories désignent des ensembles d'éléments matériels) ; et, o soft (cette catégorie désigne tous les éléments logiciels du cluster, par exemple un serveur de type nfs, sigle de Network File System en terminologie anglo-saxonne).

Les éléments du cluster peuvent être définis de façon différente. II est observé que si la partie type@category est manquante, elle peut généralement être retrouvée, par exemple à partir de la clusterDB, une erreur étant générée si l'élément considéré n'est pas retrouvé. Cependant, pour éviter d'interroger la clusterDB de façon fréquente, ce qui peut être préjudiciable en termes de temps de traitement, il est préférable de spécifier ce paramètre dans la liste des éléments.

Un exemple de liste d'éléments est donné en annexe A1 . Selon cet exemple, la première expression vise les éléments nommés Calcul_1, Calcul_2 et Calcul_3, correspondant à des îlots (islet) et définis dans la clusterDB par la catégorie hw_group. De même, la quatrième expression vise un ensemble de neuf nœuds nommés bullx12 à bullx20 qui sont ici des nœuds de calcul (#compute@node) .

Les règles de dépendances 220 sont les règles de dépendances devant être appliquées aux éléments visés par la liste d'éléments 215. Elles permettent d'associer des actions à des éléments d'un cluster et d'identifier des dépendances entre des éléments d'un cluster selon des actions requises. Les règles de dépendances 220, identifiées par un même nom ou un même identifiant de commande d'administration, forment un RuIeSet, c'est-à-dire un ensemble de règles devant être potentiellement appliquées (selon les éléments visés) pour exécuter une commande d'administration appelée.

II est observé ici que si une commande d'administration vise directement un ensemble de règles de dépendances, elle peut également viser, de façon indirecte, d'autres règles de dépendances qui sont elles-mêmes liées directement ou indirectement aux règles de dépendances directement visées par la commande d'administration.

Un exemple de règles de dépendances est illustré en annexe A2.

Ces règles de dépendances sont ici représentées sous forme d'un tableau dans lequel chaque ligne correspond à une règle de dépendances. Comme indiqué précédemment, une commande d'administration correspond ici à une sélection initiale de règles de dépendances. Ainsi, par exemple, la commande d'administration appelée « stop » fait appel à plusieurs règles de dépendances pouvant s'appliquer à des éléments de différents types.

Les colonnes de ce tableau sont ici définies de la façon suivante :

- RuIeSet : nom de la commande d'administration appelant la règle de dépendances faisant l'objet de la ligne considérée ;

- Symbolic name : nom symbolique unique de la règle de dépendances faisant l'objet de la ligne considérée ;

- Comp. type : type de l'élément sur lequel s'applique la règle de dépendances. La syntaxe utilisée ici est similaire à celle décrite précédemment, de la forme type@category. Plusieurs types d'éléments peuvent être concernés par une règle de dépendances. Dans ce cas, ces types sont séparés par un symbole logique, par exemple « OR » ou « | ». Certaines expressions telles que « ail » peuvent être utilisées pour désigner plusieurs types sans qu'il soit nécessaire de les définir un par un. Les catégories sont, par exemple, celles définies précédemment (hwmanager ou hw, disk-array, switch, node, hw_group, rack et soft), les types d'éléments pouvant être, par exemple, les suivants,

o compute, login, io et mngt pour caractériser une fonction telle que, par exemple, compute@node désigne un nœud de calcul, login@node désigne un nœud de connexion, io@node désigne un nœud d'entrée/sortie et mngt@node désigne un nœud d'administration ;

o ail désigne tous les types d'une catégorie donnée, par exemple all@disk_array désigne l'ensemble des baies de stockage ;

o colddoor vise les portes froides. Une porte froide étant un élément matériel, elle est désignée par colddoor@hwmanager ; o eth, ib et pdu vise des types de commutateurs tels que, par exemple, eth@switch désigne un commutateur Ethernet, ib@switch désigne un commutateur Infiniband et pdu@switch désigne un commutateur PDU ; et o nfsd, sshd et lustre désignent des éléments logiciels tels que, par exemple nfsd@soft désigne un démon NFS, sshd@soft désigne un serveur SSH et lustre@soft désigne un démon lustre (lustre est une marque désignant ici un système de fichiers distribué).

- Filter : filtre ayant une expression de la forme « %var =~ regexp » ou « %var l~ regexp », utilisé pour sélectionner les éléments sur lesquels l'action liée à la règle de dépendance doit être appliquée (l'application d'un filtre est décrit ci-dessous) ;

- Action : action devant être exécutée pour les éléments sélectionnés (l'expression « %comp. » est remplacée par le nom de l'élément considéré). Comme décrit ci-dessous, selon la valeur du code de retour de l'action, après son exécution, le générateur du graphe de dépendances peut, selon le mode d'exécution choisi, indiquer une erreur et s'arrêter ou continuer l'exécution d'instructions ;

- DepsFinder : nom d'un script à appeler qui, pour des éléments donnés (définis par Comp. type et Filter), retourne une liste de paires (x, t) où x représente le nom d'un élément qui doit être traité, typiquement arrêté ou démarré, avant les éléments donnés ou les éléments correspondant au type donné d'éléments et où t représente le type de cet élément. Ce type est, de préférence, l'un des types décrit précédemment. Une expression particulière, « none », est avantageusement utilisée lorsqu'il n'existe pas de dépendance. Cette expression particulière indique que le ou les éléments considérés ne dépendent pas d'autres éléments (pour le traitement de la commande d'administration visée) ;

- DependsOn : liste de noms symboliques de règles de dépendances (compris dans la colonne Symbolic name) faisant références à d'autres éléments ou types d'éléments identifiés par le champ DepsFinder. Une expression particulière, « none », est de préférence utilisée lorsqu'il n'existe pas de dépendance. Cette expression est ignorée si l'expression « DepsFinder » est « none ». Les règles de dépendances visées ici appartiennent, de préférence, à l'ensemble de règles de dépendances visées par la commande d'administration considérée ; et, - Comments : commentaires sans incidence sur la règle de dépendances.

Il est observé ici que l'ensemble des règles de dépendances peut, par exemple, être mémorisé dans la clusterDB.

Comme indiqué précédemment, l'application d'une règle de dépendances peut comprendre une étape de filtrage selon un filtre pouvant être exprimé, par exemple, sous la forme « %var =~ regexp » ou « %var !~ regexp » où %var est remplacé par sa valeur durant l'évaluation de l'expression (par exemple %id, %ruleset et %comp.), l'opérateur =~ indique que l'élément (%comp.) n'est filtré que si l'expression est vérifiée alors que l'opérateur !- indique que l'élément n'est filtré que si l'expression n'est pas vérifiée. Si l'expression ne commence pas par une variable « %var » connue, l'expression est interprétée comme une commande de type shell qui, lorsqu'elle est appelée, précise si l'élément donné doit être retenu (code de retour égal à zéro) ou rejeté (code de retour différent de zéro). Deux expressions particulières « ail » et « null » sont réservées pour accepter tous les éléments et pour les rejeter, respectivement. A titre d'illustration, pour accepter tous les éléments dont le nom contient « bullx104 », l'expression « %name =~ bullx104 » peut être utilisée.

A titre d'illustration, la deuxième règle de dépendances données en annexe A2, appelée « nodeOn », vise une commande (RuIeSet) de démarrage (starf) pour des éléments de type nœuds de calcul (compute@node). Un filtre est utilisé pour ne sélectionner que les nœuds de calcul ne contenant pas le nom compute12 (%name !~ compute12). La règle de dépendances nodeOn fait appel à la fonction nodectri avec les paramètres poweron et %comp. ayant pour objet de démarrer les nœuds de calcul sélectionnés. La règle de dépendances nodeOn fait appel au script find_nodeon_deps pour identifier tous les nœuds qui doivent être traités (ici démarrés) avant chaque nœud de calcul considéré. Par ailleurs, il est précisé que l'exécution de la règle de dépendances nodeon dépend de la règle de dépendances CoIddoorStart visant le démarrage d'une porte froide. En d'autres termes, un nœud de calcul sélectionné ne peut être démarré que si la porte froide de l'armoire informatique dans laquelle il se trouve a été préalablement démarrée. La règle de dépendances CoIddoorStart s'applique aux éléments retournés par le script DepsFinder correspondant à la règle de dépendance nodeOn.

De même, la troisième règle de dépendances donnée en annexe A2, appelée « coIddoorOff » , vise une commande (RuIeSet) d'arrêt (stop) pour des éléments matériels de type porte froide (colddoor@hw). Aucun filtre n'est ici utilisé. Par conséquent, toutes les portes froides sont visées par cette règle de dépendances. Cette dernière fait appel à la fonction bsm_power avec les paramètres off %comp. ayant pour objet d'arrêter une porte froide. La règle de dépendances coIddoorOff fait appel au script find_colddoorOff_dep pour identifier tous les nœuds qui doivent être traités (ici arrêtés) avant la porte froide considérée. Par ailleurs, il est précisé que l'exécution de la règle de dépendances coIddoorOff dépend de la règle de dépendances nodeOff visant l'arrêt de nœuds. En d'autres termes, une porte froide ne peut être arrêtée que si les nœuds liés à la porte froide ont été préalablement arrêtés. Cependant, si un nœud ne peut être arrêté, il est néanmoins possible d'arrêter les portes froides des armoires informatiques ne comprenant pas de nœud.

Lorsqu'une commande (RuIeSet) est appelée pour traiter un ensemble d'éléments, toutes les règles de dépendances correspondant à celle- ci sont sélectionnées ainsi que, le cas échéant, les règles de dépendances liées, du fait des dépendances, directement ou indirectement, à ces règles initialement sélectionnées. Parmi ces règles sélectionnées, certaines, liées à des éléments de la liste d'éléments, sont mises en œuvre et d'autres, liées directement ou indirectement à des règles mises en œuvre, le sont également. Certaines règles sélectionnées peuvent ainsi ne pas être mises en œuvre.

Ainsi, selon l'exemple donné en annexe A2, si la commande start est appelée, toutes les règles de dépendance correspondant à cette commande, dont la règle de dépendance nodeOn, sont sélectionnées. Il est observé que parmi ces règles sélectionnées, la règle de dépendance CoIddoorStart (non représentée) est mise en œuvre si la règle de dépendance nodeOn est mise en œuvre du fait de la dépendance. Après avoir identifié un ensemble initial d'éléments (liste d'éléments), un ensemble de règles de dépendances et un ensemble d'éléments dont dépendent les éléments de l'ensemble initial d'éléments, il est possible de générer un graphe de règles qui est avantageusement utilisé pour générer un graphe de dépendances. Une telle étape est ici réalisée dans le générateur de graphe.

Le graphe de règles est créé à partir de toutes les règles de dépendances identifiées et mises en œuvre, selon les relations de dépendances identifiées ici dans le champ DependsOn.

Le graphe de règles permet, par itération, de construire un graphe de dépendances entre tous les éléments identifiés.

A titre d'illustration, il est considéré ici un cluster (particulièrement simplifié) comprenant plusieurs éléments liés les uns aux autres par des relations de dépendances dont certaines sont illustrées sur la figure 3. Le cluster 300 comprend deux armoires informatiques 305-1 et 305-2. L'armoire informatique 305-1 , refroidie par une porte froide 310 (appelée cdO), comprend un serveur 315-1 de type NFS (appelé nfsl) et un nœud de calcul 320 (appelé d) tandis que l'armoire informatique 305-2 comprend un serveur 315-2 de type NFS (appelé nfs2). Il est supposé que le serveur nfsl est un client du serveur nfs2, que, réciproquement, le serveur nfs2 est un client du serveur nfsl et que le nœud de calcul c1 est un client des serveurs nfsl et nfs2.

L'objet est ici d'arrêter (commande d'administration stop) le démon NFS du serveur nfsl (élément nfs1#nfsd@soft dans la liste d'éléments visés par la commande d'administration considérée), d'éteindre la porte froide cdO (élément cd0#colddoor@hw dans la liste d'éléments visés par la commande d'administration considérée) et d'arrêter le serveur nfs2 (élément nfs2#nfs@node dans la liste d'éléments visés par la commande d'administration considérée).

Les contraintes sont d'éteindre le nœud de calcul d {nodeOff) avant la porte froide cdO (colddoorOff), d'arrêter les démons NFS (nfsDown) sur les serveurs nfsl et nfs2, d'afficher une alerte (unmountNFS) pour chaque client des serveurs NFS (afin d'alerter de l'arrêt des serveurs NFS) et d'arrêter le serveur nfs2 (nodeOff). Ces contraintes peuvent s'exprimer sous forme de graphe de règles comme illustré sur la figure 4. Comme indiqué précédemment, l'ordre des règles de dépendances peut notamment être déterminé selon les indications associées à chacune d'elles, par exemple les indications du champ DependsOn décrites précédemment.

La figure 5 illustre certaines étapes d'un exemple d'algorithme récursif utilisé pour générer un graphe de dépendances conformément à l'invention. Une première étape (étape 500) a pour objet de créer un graphe de dépendances initial. Ce dernier comprend, de préférence, tous les éléments de la liste d'éléments (référence 215 sur la figure 2) visés par la commande d'administration considérée.

Une étape suivante (étape 505) consiste à sélectionner un élément dans le graphe de dépendances en cours de construction. De façon avantageuse, l'élément sélectionné est choisi à partir du graphe de règles, comme étant le premier élément d'une racine du graphe de règles (dans lequel des racines ont éventuellement été virtuellement supprimées au cours de la construction du graphe de dépendances). Si aucun élément ne correspond à une racine du graphe de règles, ces racines sont supprimées (virtuellement) et l'étape est répétée avec le graphe de règles résultant.

Les éléments dépendants de l'élément sélectionné sont alors identifiés (étape 510). Comme décrit précédemment, ces éléments sont, de préférence, identifiés à l'aide des règles de dépendances qui leur sont associées et des scripts du champ DepsFinder.

Ces éléments sont ajoutés au graphe de dépendances en cours de construction puis des liens de dépendances entre les éléments du graphe de dépendances sont ajoutés (étape 515). Les éléments ajoutés sont à leur tour traités (en fonction des règles de dépendances définies dans le champ DependOn associé au champ DepsFinder ayant conduit à l'identification de ces éléments) pour déterminer s'ils dépendent d'autres éléments. L'étape 515 est ainsi exécutée de façon récursive. Si un élément ne dépend pas d'autres éléments, l'action qui lui est associée (définie dans le champ action de la règle de dépendances) est mémorisée et l'élément suivant (en remontant dans la hiérarchie du graphe de dépendance) est traité pour déterminer si tous les éléments dont il dépend ont été traités et, le cas échéant, mémoriser l'action associée.

Lorsque tous les éléments identifiés et ajoutés au graphe de dépendances ont été traités, un autre élément du graphe de dépendances, non encore traité, est, le cas échéant, sélectionné (étape 505). Comme indiqué précédemment, si aucun élément n'est associé à une racine du graphe de règles, ces racines sont supprimées (virtuellement) et l'étape est répétée avec le graphe de règles résultant.

L'algorithme prend fin lorsque tous les éléments associés au graphe de règles (et les éléments qui en dépendent) ont été traités.

Ainsi, un graphe de dépendances est ici créé à partir des éléments présents dans la liste d'éléments en ajoutant des éléments dépendants en fonction de règles de dépendance, en ajoutant des liens de dépendance et en modifiant les noeuds du graphe pour ajouter des actions selon les règles de dépendances visées. En d'autres termes, lorsqu'un élément est traité à travers une règle de dépendance, le script DepsFinder est appelé. Les éléments déterminés par ce script, sur lesquels une action doit être effectuée avant d'effectuer l'action visée sur l'élément traité, ne figurant pas dans le graphe de dépendances, sont ajoutés à celui-ci. Tous les éléments devant être traités (éléments de la liste d'éléments et éléments dont dépendent ces éléments) forment un ensemble d'éléments à traiter. Lorsqu'un élément est traité, il est retiré de cet ensemble. Le processus de génération du graphe de dépendances prend fin lorsque cet ensemble est vide.

L'algorithme décrit en référence à la figure 5 est maintenant illustré, en référence aux figures 6a à 6f, selon l'exemple illustré sur les figures 3 et 4.

La première étape de l'algorithme de construction du graphe de dépendances consiste à créer un graphe comprenant les éléments spécifiés dans la liste d'éléments sur lesquels doit être appliquée la commande d'administration visée, c'est-à-dire, selon l'exemple décrit en référence à la figure 3, le démon nfsl (nfs1#nfsd@soft), la porte froide cdO (cdO#colddoor@hw) et le serveur nfs2 (nfs2#nfs@node), comme représenté sur la figure 6a.

Comme représenté sur la figure 4, le graphe de règles lié à cet exemple ne comprend qu'une racine visant la règle d'arrêt d'une porte froide (œlddoorOff). Cette règle est ici associée à la porte froide cdO. Cet élément est donc sélectionné comme premier élément conformément à l'étape 505.

Le script DepsFinder lié à l'arrêt de la porte froide cdO permet d'identifier le serveur de calcul d (c1#compute@node) ainsi que le serveur nfsl (nfs1#nfs@node). Ces éléments sont alors ajoutés au graphe de dépendances avec les liens de dépendances correspondant, comme illustré sur la figure 6b.

Le nœud d est ensuite sélectionné ainsi que la règle de dépendance nodeOff (liée à la règle d'arrêt de la porte froide cdO). Le script DepsFinder correspondant ne retourne rien (l'arrêt du nœud ne dépend ici d'aucun autre élément). L'action de la règle associée au nœud d est mémorisée (comme illustré sur la figure 6c). Cette action vise une fonction de contrôle de nœud (nodectrf) ayant pour paramètres poweroff afin de préciser le type de contrôle à effectuer (arrêt d'un nœud) et d pour identifier le nœud sur lequel porte l'action.

De façon similaire, le nœud nfsl est traité. A nouveau, la règle de dépendance nodeOff (liée à la règle d'arrêt de la porte froide cdO) s'applique ici. Le script DepsFinder correspondant identifie le démon NFS associé (nfs1#nfsd@soft). Cet élément est alors ajouté au graphe de dépendances avec le lien de dépendance correspondant (comme illustré sur la figure 6c).

De façon récursive, l'élément nfs1#nfsd@soft est traité. Deux nouveaux éléments (clients NFS liés aux nœuds d et nfs2) sont alors créés (c1#unmountNFS@soft et nfs2#unmountNFS@soft) dans le graphe de dépendances avec les liens de dépendances correspondants. Ces nouveaux éléments n'ayant pas de dépendance, les actions associées sont mémorisées, puis celles de l'élément nfs1#nfsd@soft et finalement celles de l'élément nfs1#nfs@node, comme illustré sur la figure 6d. Dans une itération suivante, l'action associée à la porte froide est mémorisée.

Dans la liste d'éléments, comprenant le démon nfsl (nfs1#nfsd@soft), la porte froide cdO (cdO#colddoor@hw) et le serveur nfs2 (nfs2#nfs@node), seule la porte froide cdO a été traitée. Cependant, en traitant la porte froide cdO, le démon nfsl a été incidemment traité. Par conséquent, il ne reste que le serveur nfs2 (nfs2#nfs@node) à traiter. A nouveau, le premier élément associé à une racine du graphe de règles (représenté sur la figure 4) est recherché. Aucun élément n'étant associé à la racine CoIddoorOff (la porte froide cdO a déjà été traitée et il n'y a pas d'autre élément), cette racine est retirée (virtuellement) du graphe de règles. Dans le graphe de règles résultant, c'est la règle nodeOff qui est la racine. Le serveur nfs2, correspond à la règle nodeOff, est donc sélectionné.

Le script DepsFinder associé au serveur nfs2 selon la règle nodeOff permet d'identifier le démon nfs2 (nfs2@nfsd@soft). Cet élément est donc ajouté au graphe de dépendance avec le lien de dépendance correspondant, comme illustré sur la figure 6e.

Le démon nfs2 est alors sélectionné pour déterminer ses dépendances, ici c1#unmountNFS@soft et nfs1#unmountNFS@soft. L'élément c1#unmountNFS@soft ayant déjà été ajouté au graphe de dépendances, seul l'élément nfs1#unmountNFS@soft est ajouté à ce graphe, un lien de dépendance étant ajouté vers chacun de ces éléments. De façon récursive, il est déterminé que ces éléments n'ont pas de dépendance. Les actions associées à ces éléments sont alors mémorisées.

II est observé ici que, de préférence, une même action ne peut être mémorisée deux fois pour un même nœud. Cependant, des actions différentes, provenant de règles de dépendances différentes, peuvent être associées à un même nœud du graphe de dépendances. En d'autres termes, une règle de dépendances donnée ne peut être appliquée qu'une seule fois à un élément donné alors que plusieurs règles de dépendances distinctes peuvent être appliquées à un même élément ce qui peut entraîner l'association de plusieurs actions à un même nœud du graphe de dépendances. En remontant dans la structure du graphe de dépendances, il est ensuite possible d'associer les actions aux éléments dépendants des éléments précédemment traités comme illustré sur la figure 6f qui représente le graphe de dépendance à partir duquel peut être générée une séquence d'instructions.

Il est observé ici que, si un cycle est observé dans le graphe de dépendances, il peut être mis fin au procédé et le problème peut être signalé à un utilisateur.

Plusieurs algorithmes peuvent être utilisés pour générer une séquence d'instructions à partir d'un graphe de dépendances. Cependant, quelque soit l'algorithme utilisé, une séquence d'instructions est avantageusement représentée sous forme d'un fichier de type XML (sigle d'eXtensible Markup Language en terminologie anglo-saxonne), pour être facilement lisible et modifiable par un utilisateur.

Selon un premier mode de réalisation, une séquence d'instructions est obtenue à partir d'un graphe de dépendances selon un algorithme standard de tri topologique. La séquence d'instructions obtenue correspond à un parcours trivial du graphe, garantissant le respect des contraintes. Cependant, si un tel algorithme est facile à mettre en œuvre et respecte les contraintes déterminées, il ne permet pas une exécution de façon parallèle de certaines instructions. En outre, si une instruction ne peut être exécutée (par exemple suite à une erreur d'exécution), les instructions suivantes peuvent, selon le mode d'exécution choisi, ne pas être exécutées, même si elles ne dépendent pas de l'instruction ne pouvant être exécutée.

Selon un autre mode de réalisation, les instructions sont organisées de telle façon à être exécutées en parallèle. Les instructions dont l'exécution dépend de l'exécution d'autres instructions sont mises en attentes jusqu'à l'exécution de ces dernières. Dès qu'une instruction ou qu'un ensemble d'instructions est exécuté, celles qui en dépendent sont exécutées. Un tel mode de réalisation offre de bonnes performances. Cependant, la représentation des séquences d'instructions ainsi générées est difficilement compréhensible, et donc modifiable, pour un utilisateur. Un autre mode de réalisation a pour objet de combiner les approches parallèles et séquentielles décrites précédemment, c'est-à-dire, par exemple, d'exécuter des instructions en parallèle par niveaux. A ces fins, les sommets du graphe de dépendances représentant des feuilles sont identifiés. Ces sommets correspondent, dans l'exemple décrit en référence à la figure 6, aux éléments suivants,

- c1#unmountNFS@soft [warning: nfs mounted!];

- nfs1#unmountNFS@soft [warning: nfs mounted!];

- nfs2#unmountNFS@soft [warning: nfs mounted!]; et,

- c1#compute@node [nodectrl poweroff c1].

Les instructions associées à ces sommets forment alors un premier ensemble d'instructions qui peuvent être exécutées, par groupe (chaque groupe correspondant à un sommet), de façon parallèle.

Les sommets ainsi identifiés sont alors retirés (virtuellement) du graphe de dépendances et les sommets du graphe de dépendances résultant représentant des feuilles sont identifiés. Ces sommets correspondent, dans l'exemple considéré, aux éléments suivants,

- nfs 1 #nfsd@soft [ssh nfs /etc/init.d/nfs step] ; et

- nfs2#nfsd@soft [ssh nfs2 /etc/init.d/nfs step].

Les instructions associées à ces sommets forment alors un second ensemble d'instructions qui peuvent être exécutées, par groupe (chaque groupe correspondant à un sommet), de façon parallèle, après que le premier ensemble d'instructions ait été exécuté.

A nouveau, les sommets identifiés sont retirés (virtuellement) du graphe de dépendances et les sommets du graphe de dépendances résultant représentant des feuilles sont identifiés. Ces sommets correspondent, dans l'exemple considéré, aux éléments suivants,

- nfs1#nfs@node [nodectrl poweroff nfsl ]; et,

- nfs2#nfs@node [nodectrl poweroff nfs2].

Les instructions associées à ces sommets forment alors un troisième ensemble d'instructions qui peuvent être exécutées, par groupe (chaque groupe correspondant à un sommet), de façon parallèle, après que les premier et second ensembles d'instructions aient été exécutés.

A nouveau, les sommets identifiés sont retirés (virtuellement) du graphe de dépendances et les sommets du graphe de dépendances résultant représentant des feuilles sont identifiés. Les instructions associées au seul sommet restant (cdO#colddoor@hw [bsm power -a off_force cdO]) forment alors un quatrième ensemble d'instructions qui peuvent être exécutées en parallèle, après que les premier, second et troisième ensembles d'instructions aient été exécutés.

L'annexe A3 illustre un exemple de fichier XML correspondant à un tel mode de réalisation. La balise <seq> indique une section de groupes d'instructions devant être traités de façon séquentielle tandis que la balise <par> indique des sections de groupes d'instructions devant être traités de façon parallèle. Ainsi, par exemple, le groupe d'instruction comprenant les identifiants 1 , 2, 3 et 4 doit être traité avant le groupe d'instructions comprenant les identifiants 5 et 6 alors que les instructions liées aux identifiants 1 , 2, 3 et 4 sont avantageusement traitées de façon parallèle.

Une telle représentation est facilement compréhensible par un utilisateur qui peut ainsi la modifier pour, le cas échéant, l'adapter.

Une séquence d'instructions ainsi générée peut alors être exécutée.

De façon avantageuse, les actions visées par les instructions sont unitaires (chaque instruction ne vise qu'un élément) et atomiques (obtention d'une indication du résultat d'exécution de l'instruction) afin de contrôler l'exécution de la séquence d'instructions.

L'atomicité peut notamment être obtenue par la réception d'une indication d'exécution d'instruction de type OK si l'instruction a été correctement exécutée, NOK si l'instruction n'a pas été correctement exécutée ou WARNING si l'exécution de l'instruction peut engendrer une perturbation d'éléments du cluster (par exemple l'arrêt d'un serveur NFS alors qu'un nœud est client de ce serveur). Dans le cas d'un WARNING, l'exécution d'une instruction liée à un élément dépendant de l'exécution de cette instruction ayant produit un WARNING peut être soumise à une acceptation d'un utilisateur ou forcée par le système selon un mode d'exécution sélectionné (par exemple forcé ou non).

Il est ainsi possible de gérer les pannes pour, par exemple, ne pas arrêter une porte froide si tous les nœuds ne sont pas arrêtés (par exemple si un nœud refuse de s'arrêter).

Un dispositif adapté à mettre en œuvre l'invention ou une partie de l'invention, notamment les algorithmes décrits en référence aux figures 2 et 5, est illustré sur la figure 7. Le dispositif 700 est par exemple un ordinateur de type PC (sigle de Personal Computer en terminologie anglo-saxonne).

Le dispositif 700 comporte ici un bus de communication 702 auquel sont reliés :

- une unité centrale de traitement ou microprocesseur 703 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ;

- une mémoire morte 704 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes "Prog" ;

- une mémoire vive ou mémoire cache 706 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et,

- une interface de communication 718 adaptée à transmettre et à recevoir des données.

De préférence, le dispositif 700 dispose en outre :

- d'un écran 708 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 710 ou d'un autre dispositif de pointage tel qu'un crayon optique, un écran tactile ou une télécommande ;

- d'un disque dur 712 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ; et,

- d'un lecteur de cartes mémoires 714 adapté à recevoir une carte mémoire 716 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 700 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 700 directement ou par l'intermédiaire d'un autre élément du dispositif 700.

Le code exécutable de chaque programme permettant au dispositif programmable de mettre en œuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 712 ou en mémoire morte 704.

Selon une variante, la carte mémoire 716 peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lus par le dispositif 700, sera stocké dans le disque dur 712.

Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 718, pour être stocké de façon identique à celle décrite précédemment.

De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 700 avant d'être exécutés.

L'unité centrale 703 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 712 ou dans la mémoire morte 704 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 712 ou la mémoire morte 704, sont transférés dans la mémoire vive 706 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre de l'invention.

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. ANNEXE

Calcul_[1-3]#isIet@hw_group

CC-[1-10]#CC@rack

bullx[10- 11 ]#mds@node

bullx[12-20]#compute@node

hwm[101-110]#bmc@hwmanager

colddoor[0-5]#coldoor@hwmanager

esw-CU[2-3]-1#eth@switch

foo[1-5]#bar@soft

A1 : exemple de liste d'éléments

Rule Symbolic Comp. Deps Dépends

Filter Action Comments Set name type Finder On

Stop nodeOff compute ail Nodectrl findjtod nfsDown Powering off

@node poweroff e_ compute and OR %comp. deps nfs nodes nfs %comp.

@node

Start nodeOn compute %name !~ nodectrl find_ Colddoor Power on

@node compute poweron nodeon_ Start cold door

12 %comp. deps before nodes

%name

Stop colddoorOff colddoor ail Bsm_powe find_ nodeOff Power off

@hw r colddoor nodes before off %comp. Off_dep a

%comp. cold door

Stop daOff all@da Bash -c da_admin find_da_ ioServer Powering off

'[[ %comp. poweroff \ deps Off disk arrays = ^■ * ]]' %comp. %comp. requires their clients to be powered off first

Stop nfsDown nfsd@soft ail ssh Find_nfs unmount Stopping %comp. client NFS NFS

/etc/init.d/n %comp. daemons: fs stop take care of clients

Stop unmountNFS unmount all Warning : none none Display a

NFS@soft nfs waming mounted ! message for each client

A2 : exemple de règles de dépendances <seq>

<par>

<action component_set="c1#unmountNFS@soft" id="1 ">

echo "WARNING : nfs mounted";

</action>

<action component_set-"nfs1#unmountNFS@soft" id="2">

echo "WARNING : nfs mounted";

</action>

<action component_set="nfs2#unmountNFS@soft" id="3">

echo "WARNING : nfs mounted";

</action>

<action component_set- "c 1 #compute@node " id= "4 ">

nodectrl poweroff c1 ;

</action>

</par>

<par>

<action component_set- 'nfs1#nfsd@soft" id="5">

ssh nfsl /etc/init.d/nfs stop

</action>

<action component_set="nfs2#nfsd@soft" id-"6">

ssh nfs2 /etc/init.d/nfs stop

</action>

</par>

<par>

<action component_set="nfs1#nfs@node" id-"7">

nodectrl poweroff nfsl

</action>

<action component_set="nfs2#nfs@node" id="8">

nodectrl poweroff nfs2

</action>

</par>

<action component_set="cdO#coldoor@hw" id-"9">

nodectrl poweroff cdO

</action>

</seq>

A3 : exemple de fichier XML représentant une séquence d'instructions