Brevet FR2978576A1 — publié le 20130201

La présente invention concerne le domaine des calculateurs hautes performances, généralement désignés sous leur appellation anglo-saxonne « clusters » HPC (HPC étant le signe de « High Performance Computing »). La présente invention vise plus particulièrement la génération de la documentation relative à de tels calculateurs. Lors de la livraison d'un cluster HPC à un client, une documentation lui est remise décrivant l'ensemble des équipements mis en oeuvre dans le système. Cette documentation comporte des informations techniques permettant l'installation, la configuration, l'utilisation, la maintenance et/ou le dépannage du cluster lors de son utilisation. La documentation relative à un cluster HPC revêt une importance pour l'utilisateur final. Toutefois, elle est souvent trop complexe ou trop "généraliste". En fait, les documentations relatives aux clusters HPC sont souvent 15 des documentations génériques recensant l'ensemble des équipements susceptibles d'être inclus dans le cluster par le constructeur. Or, les clusters HPC sont souvent des systèmes très personnalisés et adaptés aux besoins du client. Ainsi, la plupart du temps, une grande partie de la documentation fournie au client concerne des informations qui lui sont 20 inutiles car le cluster qui lui a été livré ne comporte pas un tel élément ou parce que plusieurs centaines de pages concernent une configuration qu'il n'a pas choisi de mettre en oeuvre. Un cluster HPC peut comporter des centaines voire des milliers d'équipements. Souvent, la documentation fournie au client intègre l'ensemble 25 des configurations possibles pour l'ensemble des équipements disponibles auprès du constructeur et ce, pour tous les types d'architectures possibles. Une grande partie de la documentation n'est donc pas utilisée par le client et/ou par les équipes de support du constructeur car les informations qu'elle contient ne correspondent pas à la réalité de la solution livrée au client. 30 Par exemple, si deux types de commutateurs réseau sont disponibles auprès du constructeur du cluster mais que le client final ne choisit qu'un seul type pour son cluster, toute la documentation concernant l'autre type s'avère inutile. La présence d'informations inutiles peut également provenir de modes de fonctionnement de certains équipements qui ne sont pas utilisés par le client final. Lorsque ces informations sont fournies au client alors que son cluster ne met pas en oeuvre le mode de fonctionnement, des erreurs de manipulation peuvent survenir. Il apparaît ainsi que la documentation accompagnant les clusters HPC peut atteindre plusieurs centaines de pages, sans que son contenu soit en totalité en adéquation avec les besoins du client. La recherche d'informations et l'exécution des tâches à réaliser pour l'installation ou la configuration du cluster sont ainsi perturbées par des données considérées comme inappropriées. Il résulte de cette documentation non adaptée une perte de temps pour le client final qui ne peut pas trouver de manière rapide et efficace les informations dont il a besoin. Il en résulte une perte de temps pour le constructeur également car le client se retourne vers lui pour lui demander des informations qu'il a pourtant déjà fournit dans la documentation. Les inventeurs ont ainsi mis à jour un besoin pour fournir de manière simple et efficace une documentation relative à un cluster HPC qui soit pertinente pour l'utilisation faite par le client. Un premier aspect de l'invention concerne un procédé de 20 génération automatique de fichier de documentation relative à un système informatique, comportant les étapes suivantes de : - détermination d'un ensemble d'équipements formant ledit système informatique, - détermination, pour chaque équipement de l'ensemble, de données de 25 documentation d'équipement, - détermination de liens de documentation entre lesdites données de documentation de chaque équipement et des données de documentation complémentaires d'équipement, et - agrégation d'au moins lesdites données de documentation d'équipement et 30 lesdites données de documentation complémentaires d'équipement pour former un fichier de documentation relative audit système informatique. Le procédé selon la présente invention permet de générer automatiquement un fichier de documentation ne comportant que des informations utiles pour le système informatique, comme par exemple un calculateur hautes performances (ou centre de calcul ou cluster HPC). Le fichier de documentation généré correspond au plus proche à la réalité physique et logique du système informatique. L'utilisation de lien de documentation permet d'enrichir de manière suffisante le fichier de documentation, sans pour autant incorporer d'informations superflues. Le procédé peut en outre comporter les étapes suivantes de : - détermination d'un ensemble de logiciels mis en oeuvre par lesdits équipements, - détermination, pour chaque logiciel de l'ensemble, de données de documentation de logiciel, - détermination de liens de documentation entre lesdites données de documentation de logiciel et des données de documentation complémentaires de logiciel, et - agrégation desdites données de documentation de logiciel et desdites données de documentation complémentaires de logiciel dans ledit fichier. Par exemple, la détermination de l'ensemble d'équipements formant le système et/ou la détermination de l'ensemble de logiciels mis en oeuvre par lesdits équipements, comporte la lecture d'un fichier de description du système. Un tel fichier de description est par exemple un fichier Netlist, un fichier racking, un fichier d'architecture ou autre. Ce type de fichiers est généralement disponible assez tôt dans la conception d'un cluster pour pouvoir l'utiliser pour générer un fichier de documentation spécifique au cluster. Le fichier Netlist comporte notamment une liste des interconnexions logiques entre les éléments du cluster. Par exemple, le fichier Netlist comprend une première partie visant les caractéristiques d'un connecteur, notamment sa position et son type, et une seconde partie visant les caractéristiques du connecteur auquel le connecteur défini doit être connecté. Si un connecteur n'est pas connecté, il est indiqué comme tel. Le fichier Netlist peut avoir la forme d'un tableau associé au cluster dans lequel chaque ligne est associée à un connecteur. Chaque ligne peut comporter des informations relatives à l'identification du connecteur auquel elle est liée, des informations relatives au connecteur auquel il est connecté ainsi que des informations relatives au type de connexion et aux dispositifs connectés via ce connecteur. Chaque lien logique du fichier Netlist peut être caractérisé selon des considérations physiques comme par exemple l'emplacement et la longueur de chaque câble devant être utilisé. Par exemple, la lecture du fichier comporte la recherche de 10 marqueurs spécifiques à des équipements et/ou à des logiciels. Cela permet une analyse lexicale du fichier, ce qui permet de déterminer de manière simple et efficace l'ensemble des équipements et/ou des logiciels mis en oeuvre dans le système informatique. La détermination des données peut comporter l'interrogation d'une 15 base de données de documentation. Ainsi, le concepteur du système informatique peut tenir à jour une bibliothèque (ou « base ») d'éléments de données de documentation atomiques pouvant être agrégés pour former un fichier de documentation. Cette base peut être tenue en sorte à être exhaustive en ce qui concerne les équipements 20 disponibles auprès du concepteur et susceptibles d'être mis en oeuvre dans un cluster. La détermination des liens de documentation comporte l'interrogation d'une base de données de liens de documentation. Cette base de liens de documentation peut permettre de définir des 25 règles d'association des données de documentation de la base de documentation. Ainsi, la définition de ces règles peut être indépendante de la base de documentation elle-même. Les liens de documentation peuvent indiquer des données de documentation complémentaires qui ne sont pas directement liées à un équipement ou à un logiciel mais qui peuvent être utiles 30 pour le fichier de documentation final. Il peut s'agir d'introductions générales à un type de matériel, de données relatives à une association d'équipements ou autre. Alternativement, ou en combinaison, la détermination des liens de documentation comporte la lecture de liens dans une structure arborescente d'une base de données de documentation. Ainsi, les liens de documentation peuvent être faits directement dans 5 la base de données de documentation. Cela peut permettre de simplifier le procédé en économisant une interrogation d'une base différente de la base de données de documentation. Le procédé peut en outre comporter les étapes suivantes de : - détermination d'un type d'équipement, 10 - détermination de données de documentation relatives audit type déterminé, et - agrégation desdites données de documentation relatives audit type dans ledit fichier. Les données relatives au type d'équipement peuvent constituer des 15 données complémentaires. Le procédé peut en outre comporter une étape de filtrage d'au moins l'un parmi : - lesdites données de documentation d'équipement, - lesdites données de documentation complémentaires 20 d'équipement, - lesdites données de documentation de logiciel, - lesdites données de documentation complémentaires de logiciel, ledit filtrage étant effectué en fonction d'une configuration d'au moins un équipement au sein du système informatique. 25 Ainsi, lorsque des données de documentation provenant par exemple de la base de données de documentation comportent des parties non pertinentes pour le système informatique, elles peuvent être supprimées avant l'agrégation dans le fichier de documentation. Par exemple, il peut s'agir de supprimer des parties relatives à une 30 configuration d'un équipement qui n'est pas mise en oeuvre dans le système informatique. Les données agrégées peuvent être structurées pour les organiser dans le fichier de documentation généré. Par exemple, il s'agit d'ordonner les données pour les présenter selon un ordre prédéterminé (présentation matérielle en premier puis présentation logicielle, présentation d'un type de matériel avant un autre, ou autre). Par exemple encore, il s'agit d'intégrer dans le fichier de documentation des informations relatives à la mise en place effective du système informatique (noms réseau des équipements ou autre) Les données agrégées sont par exemple des données du type SGML (Standard Generalized Markup Language), XML (eXtensible Markup Language), des données du type HTML (Hypertext Markup Language), ou autre. Un deuxième aspect de l'invention concerne un programme d'ordinateur ainsi qu'un produit programme d'ordinateur et un support de stockage pour de tels programme et produit, permettant la mise en oeuvre d'un procédé selon le premier aspect de l'invention, lorsque le programme est stocké dans une mémoire d'un dispositif de génération automatique de fichier documentation relative à un système informatique et exécuté par un processeur d'un tel dispositif. Un troisième aspect de l'invention concerne un dispositif de génération automatique de fichier de documentation relative à un système informatique. Un tel dispositif comporte une unité de traitement configurée pour déterminer un ensemble d'équipements formant ledit système informatique, déterminer, pour chaque équipement de l'ensemble, des données de documentation d'équipement, déterminer des liens de documentation entre lesdites données de documentation de chaque équipement et des données de documentation complémentaires d'équipement, et agréger au moins lesdites données de documentation d'équipement et lesdites données de documentation complémentaires d'équipement pour former un fichier de documentation relative audit système informatique. L'unité de traitement peut en outre être configurée pour déterminer un ensemble de logiciels mis en oeuvre par lesdits équipements, déterminer, pour chaque logiciel de l'ensemble, des données de documentation de logiciel, déterminer des liens de documentation entre lesdites données de documentation de logiciel et des données de documentation complémentaires de logiciel, et agréger lesdites données de documentation de logiciel et desdites données de documentation complémentaires de logiciel dans ledit fichier. La détermination de l'ensemble d'équipements formant le système et/ou la détermination de l'ensemble de logiciels mis en oeuvre par lesdits équipements, peut comporter la lecture d'un fichier de description du système. La lecture du fichier peut comporter la recherche de marqueurs spécifiques à des équipements et/ou à des logiciels. Le dispositif peut en outre comporter une unité de communication configurée pour communiquer avec une base de données de documentation, et la détermination des données peut comporter l'interrogation de ladite base de données de documentation. Le dispositif peut en outre comporter une unité de communication configurée pour communiquer avec une base de données de liens de documentation, et la détermination des liens de documentation peut comporter l'interrogation de ladite base de données de liens de documentation. Le dispositif peut en outre comporter une unité de communication configurée pour communiquer avec une base de données de documentation, et la détermination des liens de documentation peut comporter la lecture de liens dans une structure arborescente de ladite base de données de documentation. L'unité de traitement peut en outre être configurée pour déterminer un type d'équipement, déterminer des données de documentation relatives audit type déterminé, et agréger lesdites données de documentation relatives audit type dans ledit fichier. L'unité de traitement peut en outre être configurée pour filtrer au 30 moins l'un parmi : - lesdites données de documentation d'équipement, - lesdites données de documentation complémentaires d'équipement, - lesdites données de documentation de logiciel, - lesdites données de documentation complémentaires de logiciel, ledit filtrage étant effectué en fonction d'une configuration d'au moins un équipement au sein du système informatique. L'unité de traitement peut en outre être configurée pour structurer les données agrégées pour organiser lesdites données. Les données agrégées sont par exemple des données du type 10 SGML (Standard Generalized Markup Language), XML (Extensible Markup Language), des données du type HTML (Hypertext Markup Language), ou autre. Les objets selon les deuxième et troisième aspects de l'invention procurent au moins les mêmes avantages que ceux procurés par le procédé 15 selon le premier aspect. Le dispositif selon le troisième aspect peut comporter des moyens pour la mise en oeuvre de caractéristiques optionnelles évoquées pour le premier aspect en termes de procédé. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la présente description détaillée qui suit, à titre d'exemple non 20 limitatif, et des figures annexées parmi lesquelles : la figure 1 illustre un contexte général de mise en oeuvre de modes de réalisation ; les figures 2 et 3 illustrent des structures arborescentes de données de documentation ; 25 la figure 4 est un organigramme d'étapes mises en oeuvre selon des modes de réalisation ; et la figure 5 illustre une architecture de cluster ; la figure 6 illustre une agrégation de données selon l'architecture de la figure 5 ; 30 la figure 7 illustre schématiquement un dispositif selon un mode de réalisation de l'invention. Dans la description qui suit, il est proposé un outil de génération automatique de documentation relative à un système informatique comme par exemple un calculateur hautes performances (ou cluster HPC). II s'agit de générer de manière simple et peu coûteuse pour le constructeur du cluster, un fichier de documentation comportant les informations pertinentes pour un cluster donné. Une fois la structure d'un cluster HPC acceptée par le client final, la liste des équipements composant le cluster ainsi que leurs paramétrages et leurs configurations (notamment logicielles) respectives sont connus. II est proposé de tirer profit de cette connaissance pour générer un fichier de documentation spécifique ne traitant que des parties utiles au client pour le cluster qui a été construit pour lui. La génération d'un tel fichier peut se faire lors de la livraison et de la mise en place du cluster et de l'ensemble de ses composants logiciels et matériels. Cette solution présente l'avantage d'attendre le dernier moment pour générer le fichier et de tenir d'éventuelles modifications survenues depuis la validation de l'architecture par le client. La génération du fichier peut également se faire alors que le cluster est encore en fabrication. Cette solution présente l'avantage de pouvoir fournir au client la documentation du cluster très tôt, avant sa livraison et son installation sur site, pour qu'il puisse commencer à se familiariser avec le cluster. Il est possible de combiner les deux solutions en fournissant dans un premier temps un premier fichier généré lors de la fabrication du cluster puis en fournissant dans un second temps un deuxième fichier généré lors de la mise en place du cluster chez le client. Par exemple, dans le cas de la génération du fichier de documentation lors de la mise en place du cluster chez le client, les sources de données de documentation comportent: - le fichier « Netlist », c'est-à-dire la liste comportant l'ensemble des relations entre les équipements à installer dans le cluster, - le fichier « racking », c'est-à-dire qui un fichier contenant le descriptif exhaustif des marques et modèles d'équipements du cluster, - le fichier « d'architecture » décrivant le mode de fonctionnement des différentes parties du cluster. Par exemple, ces fichiers sont au format HTML (acronyme de « Hypertext Markup Language ») ou au format XML (acronyme de « Extended Markup Language »). Une base de données documentaire est à disposition pour extraire des données de documentation à agréger pour former le fichier de documentation. A partir du fichier racking il est possible de sélectionner les équipements devant être documentés. Pour cela, des marqueurs (ou « tags » en terminologie anglo-saxonne) peuvent être positionnés dans le fichier afin de permettre une analyse lexicale des données. Une règle d'extraction peut permettre d'extraire de la base de données des données de documentation à partir d'un un ou plusieurs marqueurs contenus dans le fichier. Typiquement, lorsqu'un type d'équipement (par exemple un noeud) est associé à un marqueur, une documentation relative aux noeuds est extraite de la base de données. A partir du fichier Netlist, il est possible d'obtenir des informations complémentaires comme par exemple le mode de configuration (ou paramétrage) de certains équipements. Le fichier Netlist permet également de déterminer si une incohérence existe avec le fichier de racking. II peut par exemple être détecté si un équipement est mentionné dans un fichier mais pas dans l'autre. Le fichier Netlist peut être analysé de manière lexicale, comme le fichier de racking, à partir de mots-clés ou des empreintes prédéfinies permettant d'extraire précisément notamment les marques, modèles et modes de fonctionnement de chaque composant du cluster. A partir du fichier d'architecture, il est possible d'extraire certaines informations concernant la configuration d'équipements (par exemple les équipements réseau et les équipements de stockage). Le fichier d'architecture peut également être analysé de manière lexicale afin de déterminer les informations utiles à l'extraction de données de la base de données documentaire. Une fois l'un ou plusieurs de ces fichiers analysés, la base de données documentaire est interrogée pour extraire des données d'installation, 'de configuration, de support ou autre. Ces données sont ensuite agrégées pour former un fichier de documentation final ne contenant alors que des informations cohérentes par rapport aux équipements réellement en place et à leurs configurations respectives dans le cluster livré au client. Un contexte général de mise en oeuvre de modes de réalisation de l'invention est décrit en référence à la figure 1. Une base de données documentaire 100 stocke un catalogue de données de documentation. Ces données concernent notamment la description et la configuration de l'ensemble des équipements et des logiciels (ainsi que de leurs configurations) disponibles auprès d'un fournisseur de clusters HPC. Cette base de données recense ainsi toutes les références disponibles auprès du fournisseur de cluster HPC. Pour un équipement donné (ou pour un logiciel donné) différents types de données peuvent être disponibles, notamment : des données d'introduction concernant des généralités (présentation, fonction dans le cluster, marque, année de fabrication ou autre), des donnés techniques (consommation, dimensions, ou autre), des données de configuration (compatibilités ou incompatibilités matérielles, logicielles, ou autre), - des données d'utilisation, d'administration et de maintenance. La base de données est organisée en sous-ensembles de données atomiques permettant ensuite de les agréger entre eux pour former des fichiers 'de documentation en fonction de configurations de cluster données. Une base de marqueurs 101 stocke un ensemble de règles définies pour déterminer, en fonction de marqueurs rencontrés dans les fichiers de description du cluster (par exemple le fichier Netlist, le fichier de racking, et/ou le fichier d'architecture), des données à extraire de la base de données 100. Un dispositif de génération de fichier de documentation 102 reçoit en entrée un ou plusieurs fichiers de description de cluster. Par exemple, il reçoit un fichier Netlist 103, un fichier racking 104 et un fichier d'architecture 105. Selon une réalisation, le fichier de documentation 106 généré par le dispositif 102 de la figure 1 est personnalisé avec une identification des équipements auxquels se rapportent les différentes données de documentation contenues dans le fichier. Par exemple, cette identification correspond au nom de réseau de l'équipement. Pour personnaliser le fichier de la sorte, le dispositif peut en outre recevoir en entrée des données provenant de la base de données « cluster DB » 107 qui est généralement associée au cluster notamment pour recenser, toutes les informations relatives au cluster d'un point de vue « réseau ». Avec un fichier de documentation ainsi personnalisé, la personne en charge de l'installation et de la configuration du cluster peut savoir exactement sur quel équipement, via son nom réseau, une opération décrite dans le fichier de documentation doit être réalisée. Le dispositif analyse les fichiers reçus (par exemple une analyse lexicale pour reconnaître des marqueurs) puis interroge la base de marqueurs 101 pour connaître, à partir de marqueurs contenus dans les fichiers analysés, les données à extraire de la base de données de documentation 100. Le dispositif peut par exemple mettre en oeuvre un algorithme de parcours automatisé des fichiers d'architecture, de racking et Netlist afin d'obtenir une extraction des composants matériels (équipements) avec un descriptif comportant notamment la marque, le modèle, le mode de fonctionnement ou autre. Une corrélation des données extraites des documents de description du cluster peut être mise en oeuvre pour déterminer le mode de fonctionnement du cluster (architecture centralisée ou distribuée, routage par le haut ou par le bas, utilisation d'un réseau Infiniband ou non, ou autre). Cette corrélation peut être mise en oeuvre par le dispositif 102 grâce à des algorithmes stockés auprès de lui. Alternativement, ou en combinaison, cette corrélation est mise en oeuvre grâce à une règle de la base de marqueurs 101. Grâce aux marqueurs des documents analysés, le dispositif 102 peut interroger la base de marqueurs pour obtenir des informations de relations entre ces marqueurs et les sous-ensembles de la base de données de documentation. Le dispositif peut alors interroger la base de données de documentation pour obtenir ces sous-ensembles pour ensuite les agréger et former le fichier de documentation 106. Une approche peut consister à stocker dans la base de données de documentation 100 une structure arborescente organisant les données documentaires atomiques. Cette approche peut permettre de ne pas avoir à gérer de marqueurs et créer les liens entre les données documentaires via la structure arborescente. Selon une telle approche la base de marqueurs 101 n'est pas mise en oeuvre. La structuration des données de manière hiérarchique permet de gérer plus facilement les interdépendances et permet d'en ajouter et/ou d'en supprimer facilement La figure 2 illustre un exemple d'une telle structure arborescente. Cette structure comporte une partie "matériel" et une partiel "logiciel". La partie "matériel" comporte différents types d'équipements (ethernet, Infiniband, Stockage, ou autre). Ces différents types d'équipements peuvent être de différentes marques (Marque 1, Marque 2, Marque 3) et également de différentes fonctions (Carte, Commutateur, ou autre). Enfin, les marques et les fonctions regroupent différents modèles. Ainsi, sous une même arborescence il est possible d'avoir des éléments de natures différentes mais pourtant reliés entre eux. Un intérêt de la structure arborescente est à la fois de pouvoir découper les informations de la base de données documentaire de manière précise et simple mais également de pouvoir créer des liens "virtuels" entre eux. Ces liens peuvent être bidirectionnels (c'est-à-dire valables dans les deux sens). Ceci est également vrai sur les interdépendances de la documentation par exemple, tous les éléments peuvent avoir de multiples pointeurs sur l'ensemble des autres éléments dont ils dépendent. Comme illustré par la figure 2, le modèle « Modèle 11 » de la marque « Marque 1 » est lié à au type « Commutateur ». Les commutateurs de la marque « Marque 1 » peuvent être du modèle « Modèle 11 » ou « Modèle 12 ». Les modèles « Modèle 31 » et « Modèle 32 » de la marque « Marque 3 » sont du type « Carte ». D'autres liens sont illustrés par la figure 2. Dans l'exemple de la figure 3, on considère que l'ajout d'un équipement de type « Refl » ou « Ref2 » de marque « Marque » implique l'agrégation de données de documentation relatives à ces équipements, de données relatives à la marque « Marque » de données relatives à la présentation du matériel dans le cluster et de données relatives à l'introduction du matériel dans le cluster. Selon cet exemple, les liens sont unidirectionnels. Pour des raisons techniques (modification non maîtrisée de l'environnement logique ou physique par l'ajout d'équipements ou de services), il peut s'avérer utile et intéressant de pouvoir réaliser la même opération de génération de documentation à partir de l'état actuel d'un cluster (par exemple à partir de la base de données cluster DB). Au lieu de prendre en entrée les données d'origine de la définition du cluster, on part, dans ce cas, des données utilisées en fonctionnement. L'analyse est similaire, seule la source de données est modifiée. On se retrouve alors avec une documentation en phase avec l'état technique courant du cluster. La figure 4 est un organigramme d'étapes mises en oeuvre dans un mode de réalisation. Il est supposé qu'une réponse à un appel d'offre pour un cluster HPC est formulée avec la liste des équipements à fournir ainsi que les composants logiciels nécessaires. A partir de cette liste, il est déterminé lors d'une étape 5400 l'ensemble des équipements et des logiciels constituant le cluster HPC. Par exemple, cette liste est définie par un ou plusieurs fichiers de description du cluster (ficher Netlist, fichier racking, fichier d'architecture ou autre) comme évoqué ci-avant, et la détermination se fait par lecture de ces fichiers. Ensuite, lors d'une étape 5401, il est déterminé un ensemble de données de documentation relatives aux équipements de l'ensemble déterminé lors de l'étape S400. Par exemple, cet ensemble de données est obtenu par interrogation d'une base de données de documentation. La liste d'équipements et de logiciels permet de ne retenir que les données de documentation pertinentes. Par exemple, les équipements sont identifiés par un modèle, une référence ou autre. Pour chaque équipement, il est vérifié, lors d'une étape S402, si les données correspondantes déterminées lors de l'étape S401 sont liées avec d'autres données de documentation complémentaires. Par exemple, cette vérification se fait en interrogeant une base de marqueurs telle que décrite en référence à la figure 1. Alternativement, cette détermination se fait par analyse d'une structure arborescente de la base de données de documentation comme déjà évoqué ci-avant. Par exemple, dans le cas de la présence d'un réseau Infiniband dans le cluster, les données de documentation complémentaires peuvent par exemple comporter une introduction pour expliquer l'intérêt d'un tel réseau. De même, si des éléments sont interdépendants, c'est-à-dire par exemple s'ils doivent être associés l'un à l'autre pour fonctionner, la partie documentaire relative à l'un est automatiquement ajoutée à celle relative à l'autre au bon endroit sans pour autant attendre le parcours complet de la liste des équipements/logiciels. Les données complémentaires sont ensuite obtenues lors d'une étape S403, par exemple par une nouvelle interrogation de la base de données de documentation. Les données obtenues lors des étapes S401 et S403 sont agrégées lors d'une étape S404. Elles peuvent également être structurées pour les organiser selon un schéma choisi (ordre, réplication ou autre). Enfin, le fichier de documentation est généré lors d'une étape S405 par exemple sous forme d'un fichier HTML, XML ou autre. De manière alternative, les étapes ci-dessus sont mises en oeuvre lorsque le cluster est mis en place chez le client. Par exemple, un dispositif de génération de fichier de documentation est couplé à la base de données Cluster DB contenant les informations de la première livraison mais également les informations ajoutées durant une éventuelle mise-à-jour de l'architecture du cluster. Ainsi, le fichier de documentation généré correspond exactement à la solution finalement retenue (mise-à-jour comprise). Le fichier de documentation peut en outre comporter des informations de configuration "sur site". Le séquencement (et ou la réplication) des données de documentation peuvent alors être organisées pour être conformes à ce que l'opérateur doit exécuter afin d'installer et configurer le cluster. La figure 5 représente une architecture de cluster. L'architecture de la figure 5 comporte un commutateur principal « Top switch » 500 connecté à des noeuds Ethernet 501 à 504. Les noeuds Ethernet sont connectés à des noeuds de service (par exemple des noeuds de calcul et des noeuds d'administration) disposés dans des armoires informatiques 505 à 508. Les noeuds de service sont par ailleurs connectés à des noeuds Infiniband 509 à 512. Un exemple d'agrégation de données de documentation pour une architecture selon la figure 5 est illustré par la figure 6. Des données d'introduction 600 sont placées en début de fichier pour présenter le cluster (par exemple ses fonctions, ses caractéristiques techniques comme sa consommation ou autre). Des données 611 de conclusion sont placées en fin de fichier pour 25 donner par exemple des instructions finales de configuration. Le fichier est organisé selon trois sections débutées respectivement par des données 601, 604 et 608. Les données 601 présentent l'installation des noeuds dans le cluster. Elles sont suivies par des données 602 concernant l'installation des noeuds 30 d'administration et des données 603 concernant l'installation des noeuds de calcul. Les données 604 présentent la configuration Ethernet du cluster. Elles sont suivies par des données 605 concernant une introduction générale aux réseaux Ethernet, puis des données 606 concernant la configuration du Top switch, puis des données 607 concernant la configuration des commutateurs Ethernet. Les données 608 présentent la configuration Infiniband. Elles sont suivies de données 609 concernant une introduction générale aux réseaux Infiniband, puis des données 610 concernant la configuration des commutateurs Infiniband. Le fichier selon la figure 6 ne comporte que des données relatives à des équipements effectivement présents dans le cluster. Il en résulte une facilité d'utilisation pour la personne chargée de configurer le cluster. Un programme d'ordinateur pour la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention peut-être réalisé à partir notamment de l'organigramme de la figure 4 et de la présente description détaillée. Un dispositif de génération de fichier de documentation selon un mode de réalisation est décrit en référence à la figure 7. Le dispositif 700 de la figure 7 comporte une unité de mémoire 701 (MEM). Cette unité de mémoire comporte une mémoire vive pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé conforme à l'invention, selon divers modes de réalisation. L'unité de mémoire comporte par ailleurs une mémoire non volatile (par exemple du type EEPROM) pour stocker par exemple un programme d'ordinateur, selon un mode de réalisation, pour son exécution par un processeur (non représenté) d'une unité de traitement 702 (PROC) du dispositif. Le dispositif comporte par ailleurs une unité de communication 403 (COM) pour par exemple recevoir des fichiers de description de cluster ou autre. L'unité de communication peut par ailleurs être configurée pour 30 communiquer avec une base de données de documentation ou de liens de documentation. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.15 REVENDICATIONS1. Procédé de génération automatique de fichier de documentation relative à un système informatique, comportant les étapes suivantes de : .- détermination (S400) d'un ensemble d'équipements formant ledit système informatique, - détermination (S401), pour chaque équipement de l'ensemble, de données de documentation d'équipement, - détermination (S402) de liens de documentation entre lesdites données de 10 documentation de chaque équipement et des données de documentation complémentaires d'équipement, et - agrégation (5404) d'au moins lesdites données de documentation d'équipement et lesdites données de documentation complémentaires d'équipement pour former un fichier de documentation relative audit système 15 informatique. 2. Procédé selon la revendication 1, comportant en outre les étapes suivantes de - détermination d'un ensemble de logiciels mis en oeuvre par lesdits 20 équipements, détermination, pour chaque logiciel de l'ensemble, de données de documentation de logiciel, - détermination de liens de documentation entre lesdites données de documentation de logiciel et des données de documentation complémentaires 25 de logiciel, et agrégation desdites données de documentation de logiciel et desdites données de documentation complémentaires de logiciel dans ledit fichier. 3. Procédé selon l'une des revendications précédentes, dans lequel la 30 détermination de l'ensemble d'équipements formant le système et/ou la détermination de l'ensemble de logiciels mis en oeuvre par lesdits équipements, comporte la lecture d'un fichier de description du système. 4. Procédé selon la revendication 3, dans lequel la lecture du fichier comporte la recherche de marqueurs spécifiques à des équipements et/ou à des logiciels. 5. Procédé selon l'une des revendications précédentes, dans lequel la détermination des données comporte l'interrogation d'une base de données de documentation. 6. Procédé selon l'une des revendications précédentes, dans lequel la détermination des liens de documentation comporte l'interrogation d'une base de données de liens de documentation. 7. Procédé selon l'une des revendications 1 à 5, dans lequel la détermination des liens de documentation comporte la lecture de liens dans une structure 15 arborescente d'une base de données de documentation. 8. Procédé selon l'une des revendications précédentes, comportant en outre les étapes suivantes de : - détermination d'un type d'équipement, 20 détermination de données de documentation relatives audit type déterminé, et - agrégation desdites données de documentation relatives audit type dans ledit fichier. 9. Procédé selon l'une des revendications précédentes, comportant en outre 25 une étape de filtrage d'au moins l'un parmi : - lesdites données de documentation d'équipement, - lesdites données de documentation complémentaires d'équipement, - lesdites données de documentation de logiciel, - lesdites données de documentation complémentaires de logiciel, 30 ledit filtrage étant effectué en fonction d'une configuration d'au moins un équipement au sein du système informatique. 10. Procédé selon l'une des revendications précédentes, comportant en outre une étape de structuration des données agrégées pour organiser lesdites données. 11. Procédé selon l'une des revendications précédentes, dans lequel les données agrégées sont des données du type SGML (Standard Generalized Markup Language). 12. Procédé selon l'une des revendications précédentes, dans lequel les 10 données agrégées sont des données du type XML (Extensible Markup Language). 13. Procédé selon l'une des revendications 1 à 12, dans lequel les données 'agrégées sont des données du type HTML (Hypertext Markup Language). 14. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une des revendications 1 à 13, lorsqu'il est exécuté par un processeur d'un dispositif de génération automatique de fichier documentation relative à un système informatique. 20 15. Dispositif (102, 700) de génération automatique de fichier de documentation relative à un système informatique comportant une unité de traitement (702) configurée pour déterminer un ensemble d'équipements formant ledit système informatique, déterminer, pour chaque équipement de l'ensemble, des données 25 de documentation d'équipement, déterminer des liens de documentation entre lesdites données de documentation de chaque équipement et des données de documentation complémentaires d'équipement, et agréger au moins lesdites données de documentation d'équipement et lesdites données de documentation complémentaires d'équipement pour former un fichier de 30 'documentation relative audit système informatique. 15 16. Dispositif selon la revendication 15, dans lequel l'unité de traitement est en outre configurée pour déterminer un ensemble de logiciels mis en oeuvre par lesdits équipements, déterminer, pour chaque logiciel de l'ensemble, de données de documentation de logiciel, déterminer des liens de documentation entre lesdites données de documentation de logiciel et des données de documentation complémentaires de logiciel, et agréger lesdites données de documentation de logiciel et desdites données de documentation complémentaires de logiciel dans ledit fichier. 17. Dispositif selon l'une des revendications 15 et 16, dans lequel la détermination de l'ensemble d'équipements formant le système et/ou la détermination de l'ensemble de logiciels mis en oeuvre par lesdits équipements, comporte la lecture d'un fichier de description du système. 18. Dispositif selon la revendication 17, dans lequel la lecture du fichier comporte la recherche de marqueurs spécifiques à des équipements et/ou à des logiciels. 19. Dispositif selon l'une des revendications 15 à 18, comportant en outre une unité de communication (703) configurée pour communiquer avec une base de données de documentation, et dans lequel la détermination des données comporte l'interrogation de ladite base de données de documentation. 20. Dispositif selon l'une des revendications 15 à 19, comportant en outre une unité de communication (703) configurée pour communiquer avec une base de données de liens documentation, et dans lequel la détermination des liens de documentation comporte l'interrogation de ladite base de données de liens documentation. 21. Dispositif selon l'une des revendications 15 à 20, comportant en outre une unité de communication (703) configurée pour communiquer avec une base de données de documentation, et dans lequel la détermination des liens dedocumentation comporte la lecture de liens dans une structure arborescente de ladite base de données de documentation. 22. Dispositif selon l'une des revendications 15 à 21, dans lequel l'unité de traitement (702) est en outre configurée pour déterminer un type d'équipement, déterminer des données de documentation relatives audit type déterminé, et agréger lesdites données de documentation relatives audit type dans ledit fichier. 23. Dispositif selon l'une des revendications 15 à 22, dans lequel l'unité de traitement (702) est en outre configurée pour filtrer au moins l'un parmi : - lesdites données de documentation d'équipement, - lesdites données de documentation complémentaires d'équipement, - lesdites données de documentation de logiciel, - lesdites données de documentation complémentaires de logiciel, ledit filtrage étant effectué en fonction d'une configuration d'au moins un équipement au sein du système informatique. 24. Dispositif selon l'une des revendications 15 à 23, dans lequel l'unité de 20 traitement (702) est en outre configurée pour structurer les données agrégées pour organiser lesdites données. 25. Dispositif selon l'une des revendications 15 à 24, dans lequel les données agrégées sont des données du type SGML (Standard Generalized Markup 25 Language). 26. Dispositif selon l'une des revendications 15 à 25, dans lequel les données agrégées sont des données du type XML (Extensible Markup Language). 30 27. Dispositif selon l'une des revendications 15 à 26, dans lequel les données agrégées sont des données du type HTML (Hypertext Markup Language).