Brevet FR2984054A1 — publié le 20130614

La présente invention concerne l'administration d'infrastructures informatiques telles que des clusters et des centres de traitement de données (ou data centre) et plus particulièrement un procédé et un programme d'ordinateur de gestion externalisée et centralisée de pannes dans une infrastructure informatique comprenant des équipements à haute disponibilité. 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'automobile, 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 oeuvre sur des systèmes de traitement de données appelés clusters (parfois traduit « grappes de serveurs »). Un cluster comprend typiquement un ensemble de noeuds interconnectés. Certains noeuds sont utilisés pour effectuer des tâches de calcul (noeuds de calcul), d'autres pour stocker des données (noeuds de stockage) et un ou plusieurs autres gèrent le cluster (noeuds d'administration). Chaque noeud est par exemple un serveur mettant en oeuvre un système d'exploitation tel que Linux (Linux est une marque). La connexion entre les noeuds est, par exemple, réalisée à l'aide de liens de communication Ethernet et de réseaux d'interconnexions (par exemple Infiniband) (Ethernet et Infiniband sont des marques). 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 noeuds génériquement référencés 105. Les noeuds appartenant à l'ensemble 110 sont ici des noeuds de calcul tandis que les noeuds de l'ensemble 115 sont des noeuds de service (noeuds de stockage et noeuds d'administration). Les noeuds de calcul peuvent être regroupés en sous-ensembles 120 appelés îlots de calcul, l'ensemble 115 étant appelé îlot de service. Les noeuds 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 noeuds 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. Comme illustré sur la figure 2, chaque noeud comprend généralement un ou plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication. Plus précisément, le noeud 200 comporte ici un bus de communication 202 auquel sont reliés : - des unités centrales de traitement ou microprocesseurs 204 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - des composants de mémoire vive 206 (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 de programmes (comme illustré, chaque composant de mémoire vive peut être associé à un microprocesseur) ; et, - des interfaces de communication 208 adaptées à transmettre et à recevoir des données. Le noeud 200 dispose en outre ici de moyens de stockage interne 25 210, tels que des disques durs, pouvant notamment comporter le code exécutable de programmes. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le noeud 200 ou reliés à lui. Les microprocesseurs 204 commandent et dirigent l'exécution des 30 instructions ou portions de code logiciel du ou des programmes. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple un disque dur, sont transférés dans la mémoire vive 206. Pour certaines applications dites critiques, il est nécessaire de proposer des solutions permettant d'assurer la disponibilité du cluster en cas de panne de l'un de ces composants. Ces solutions offrant des caractéristiques de haute disponibilité, appelées High-Availability (ou HA) en terminologie anglo- saxonne, nécessitent un ensemble de composants techniques relativement complexes et une couverture du champ de haute disponibilité clairement identifiée. De façon générale, un système à haute disponibilité couvre un type de pannes communément appelées « simples pannes » selon lequel un seul équipement d'un ensemble prédéterminé d'équipements tombe en panne à un instant donné. Une panne d'un équipement peut notamment être provoquée par la défaillance d'un composant matériel tel qu'une unité centrale de traitement (CPU), une mémoire ou une alimentation électrique, ou par une défaillance (typiquement appelée bug) d'un composant logiciel mis en oeuvre par l'équipement considéré. Un tel mécanisme peut, par exemple, être mis en oeuvre dans un cluster utilisant le système d'exploitation Unix (Unix est une marque) avec un système de gestion de la haute disponibilité (appelé cluster de haute disponibilité du fait du regroupement d'un ensemble de composants, matériels et logiciels, afin de fournir une fonction donnée) tel que le produit open source connu sous le nom de « Pacemaker ». Il permet le contrôle de composants à haute disponibilité (surveillance et reconfiguration en cas de panne) en utilisant notamment un réseau de surveillance dédié appelé « heartbeat» vérifiant que les composants visés sont opérationnels. Typiquement, il consiste, pour chaque équipement d'un ensemble d'équipements à haute disponibilité, à surveiller chacun des autres équipements (réception d'un heartbeat de chaque équipement). Lorsqu'un équipement est considéré en panne, ce dernier est isolé et les processus exécutés par celui-ci sont répartis sur les autres équipements de l'ensemble d'équipement selon une liste de configuration de pannes et une liste d'adaptation correspondante. Ces listes sont prédéterminées et exhaustives. Elles ne peuvent donc viser toutes les configurations possibles de pannes et s'il est possible de gérer toutes les pannes simples, il est impossible, en pratique, de gérer les doubles de pannes de cette façon. Les solutions de haute disponibilité aujourd'hui utilisées sont généralement déployées directement sur les équipements concernés par la problématique de continuité de service. A titre d'illustration, la figure 3, comprenant les figures 3a et 3b, représente schématiquement une partie 300 d'un cluster comprenant des équipements à haute disponibilité, ici quatre noeuds référencés 305-0 à 305-3, et trois commutateurs référencés 310-0 à 310-2 reliés à un réseau de communication 315. Comme illustré, le noeud 305-0 est connecté au commutateur 310-0, les noeuds 305-1 et 305-2 sont connectés au commutateur 310-1 et le noeud 305-3 est connecté au commutateur 310-2. Chaque noeud peut comprendre un ou plusieurs modules logiciels (non représentés) pouvant être à l'origine d'une défaillance. Dans un souci de clarté, il convient de comprendre, dans la suite de la description, que la défaillance d'un équipement peut être liée à une défaillance matérielle d'un composant de ce dernier ou à une défaillance d'un composant logiciel mis en oeuvre par ce dernier. La figure 3a représente la situation dans laquelle tous les noeuds, les commutateurs et le réseau de communication fonctionnent correctement. Dans ce cas, des services, pouvant s'échanger des données, sont exécutés dans les noeuds 305-0 à 305-3. Les services visés ici sont les services au sens de la haute disponibilité. Ils sont liés aux ressources des noeuds et peuvent être des services logiciels en tant que tels, des systèmes de fichiers, des processus, des adresses IP (sigle d'Intemet Protocol en terminologie anglo-saxonne), etc.. Il est ici considéré que les noeuds 305-0 à 305-3 font partie d'un même regroupement d'équipements à haute disponibilité (groupe de haute disponibilité ou groupe HA). Ainsi, lorsque l'un de ces noeuds est défaillant (pour une raison matérielle ou logicielle), un ou plusieurs noeuds opérationnels du groupe prennent le relais. Ceci est également vrai pour les équipements qui les relient au réseau (commutateurs 310-0 à 310-2). Si l'un de ces équipements est défaillant (également pour une raison matérielle ou logicielle), une bascule est effectuée pour assurer la continuité de service. La figure 3b illustre le principe de haute disponibilité mis en oeuvre lorsque le commutateur 310-0 connaît une défaillance, rendant ce dernier indisponible (comme illustré par la croix en trait continu). Lorsque le commutateur 310-0 est défaillant, le noeud 305-0 n'est plus visible des noeuds 305-1, 305-2 et 305-3 (les noeuds 305-1, 305-2 et 305-3 ne reçoivent plus le heartbeat du noeud 305-0). Ces derniers en déduisent donc une anomalie visant le noeud 305-0 (comme illustré par la croix en trait pointillé). Le mécanisme de haute disponibilité distribué dans les noeuds 305-1, 305-2 et 305-3 est donc mis en oeuvre pour redistribuer les services exécutés par le noeud 305-0 sur les noeuds 305-1, 305-2 et 305-3 ainsi que les paramètres associés tels que des adresses IP (comme illustré par les flèches). Ainsi, en d'autres termes, si un noeud ou un équipement réseau associé à ce noeud tombe en panne, une bascule des services mis en oeuvre par ce noeud est automatiquement effectuée pour transférer ces services vers un ou plusieurs noeuds fonctionnels. 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é de gestion dynamique de services dans une infrastructure informatique comprenant une pluralité d'équipements dont au moins un ensemble forme au moins un groupe d'équipements à haute disponibilité selon lequel des services gérés par un équipement dudit au moins un groupe d'équipements à haute disponibilité sont transférés à au moins un autre équipement dudit groupe d'équipements à haute disponibilité lorsque ledit équipement est considéré défaillant, le procédé comprenant une étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance, ce procédé étant au moins partiellement mis en oeuvre dans au moins un équipement de gestion de haute disponibilité, ledit au moins un équipement de gestion de haute disponibilité étant un équipement dudit cluster et étant distinct des équipements dudit ensemble d'équipements formant ledit au moins un groupe d'équipements à haute disponibilité. Le procédé selon l'invention permet ainsi une prise de décision par un système externe de contrôle de haute disponibilité ayant une visibilité globale de l'état des équipements d'un même groupe d'équipements à haute disponibilité. Il permet ainsi de supprimer des risques liés au fait que deux équipements se croyant seuls peuvent lancer chacun des ressources identiques, pouvant notamment entraîner des problèmes de corruption de données et des erreurs de fonctionnement. Il permet également de supprimer des risques selon lesquels deux équipements ne se voyant plus se « tuent » mutuellement, pouvant entraîner une perte de ressources. En outre, il permet également de s'affranchir de problèmes liés à la charge intrinsèque des équipements, c'est-à-dire la charge système pouvant entrainer des problèmes de réponse au niveau de la haute disponibilité ou des ressources, par exemple des services. Selon un mode de réalisation particulier, ladite étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance comprend une étape de réception d'une indication de fonctionnement de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité, ladite étape de réception d'une indication de fonctionnement étant mise en oeuvre dans ledit au moins un équipement de gestion de haute disponibilité ou dans au moins un équipement dudit au moins un groupe d'équipements à haute disponibilité. Selon ce mode de réalisation, un équipement peut notamment être considéré comme défaillant en l'absence de réception d'une indication de fonctionnement de cet équipement durant un intervalle de temps prédéterminé. Le procédé selon l'invention permet également de s'affranchir d'une problématique de gestion de quorum. En effet, dans une solution de haute disponibilité standard, il est nécessaire d'avoir, pour un groupe d'équipements à haute disponibilité, un nombre minimum d'équipements "actifs" (c'est-à-dire fonctionnant correctement, sans défaillance). Dans un cas général, cette valeur est calculée selon la formule Quorum = (N / 2) + 1 où N est le nombre total d'équipements dans le groupe d'équipements à haute disponibilité. Ainsi, dans le cas d'un groupe d'équipements à haute disponibilité comprenant quatre équipements, un quorum minimum est égal à trois (3 = 4 / 2 + 1). Cela signifie qu'un seul équipement peut-être défaillant dans un groupe d'équipements à haute disponibilité comprenant quatre équipements. Il n'est pas envisageable, lorsque l'organe décisionnel de haute disponibilité est mis en oeuvre dans le groupe d'équipements à haute disponibilité, de se passer de quorum car dans ce cas les risques de split-brain (risques liés au fait que deux équipements se croyant seuls lancent chacun les mêmes ressources) ou de dual-fencing (risques liés au fait deux équipements ne se voyant plus s'inhibent mutuellement) sont extrêmement élevés. Conformément au procédé selon l'invention, l'externalisation d'une partie de la gestion de la haute disponibilité permet de ne plus avoir besoin de maintenir un quorum car l'ensemble des décisions sont prises par l'équipement de gestion de la haute disponibilité qui peut donc décider d'inhiber autant d'équipements qu'il le juge utile avec une redistribution, pour un groupe d'équipements à haute disponibilité comprenant quatre équipements, pouvant aller de quatre équipements vers un seul (lorsque trois équipements sont défaillants). Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'une notification visant l'arrêt d'un équipement considéré défaillant. Un tel mode de réalisation présente l'avantage de ne requérir que peu de modifications des solutions existantes de haute disponibilité qui peuvent ainsi être utilisées pour mettre en oeuvre le procédé selon l'invention. De façon avantageuse, le procédé comprend en outre une étape de vérification d'au moins une condition liée à un ensemble d'équipements dudit au moins un groupe d'équipements à haute disponibilité, une étape de transfert de services entre un équipement considéré défaillant et un autre équipement dudit au moins un groupe d'équipements à haute disponibilité étant effectuée en réponse à ladite étape de vérification. Le procédé selon l'invention peut ainsi prendre en compte l'état général des équipements dudit au moins un groupe d'équipements à haute disponibilité. Le procédé selon l'invention comprend en outre, de préférence, une étape d'identification d'au moins un équipement opérationnel dudit au moins un groupe d'équipements à haute disponibilité, lesdits services gérés par ledit équipement considéré défaillant étant transférés audit au moins un équipement opérationnel. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de sélection d'au moins un équipement opérationnel parmi un ou des équipements opérationnels identifiés, ladite sélection étant basée sur des niveaux de haute disponibilité associés à des groupes d'équipements à haute disponibilité auxquels appartient ledit au moins un équipement opérationnel identifié, l'utilisation de plusieurs niveaux de haute disponibilité facilitant la gestion de pannes multiples. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de transfert desdits services gérés par ledit équipement considéré défaillant vers au moins un équipement d'un second groupe d'équipements à haute disponibilité, ledit au moins un groupe d'équipements à haute disponibilité étant appelé au moins un premier groupe d'équipements à haute disponibilité, lorsqu'aucun équipement opérationnel n'est identifié dans ledit au moins un premier groupe d'équipements à haute disponibilité. Il est ainsi possible de migrer des services d'un groupe d'équipements à haute disponibilité à un autre pour assurer une continuité de service. Toujours selon un mode de réalisation particulier, ladite étape de transfert desdits services gérés par ledit équipement considéré défaillant est mise en oeuvre au moins partiellement par au moins un équipement vers lequel au moins un desdits services est transféré. Il est ainsi possible d'utiliser une partie des solutions de haute disponibilité existantes. Selon un mode de réalisation particulier, ledit au moins un équipement de gestion de haute disponibilité appartient à un groupe d'équipements à haute disponibilité dédié à la gestion de la haute disponibilité et distinct dudit au moins un groupe d'équipements à haute disponibilité. L'invention a aussi pour objet un programme d'ordinateur 30 comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. Les avantages procurés par ce programme d'ordinateur 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, 5 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 d'architecture d'un noeud d'un cluster ; - la figure 3, comprenant les figures 3a et 3b, représente 10 schématiquement une partie d'une infrastructure informatique comprenant des équipements à haute disponibilité lorsque tous ces équipements fonctionnent correctement et lorsqu'une panne est détectée, respectivement ; - la figure 4 illustre schématiquement l'architecture d'une partie d'une infrastructure informatique comprenant plusieurs groupes à haute 15 disponibilité dont l'un est utilisé pour gérer de façon externe et centralisée la gestion de haute disponibilité ; - la figure 5, comprenant les figures 5a, 5b et 5c, illustre des étapes de deux exemples d'algorithmes pour gérer la haute disponibilité de groupes d'équipements à haute disponibilité conformément à l'invention à partir d'un 20 équipement d'un groupe dédié à la gestion de la haute disponibilité ; - la figure 6, comprenant les figures 6a à 6d, illustre un scénario de gestion de panne dans une partie d'une infrastructure informatique comprenant un mécanisme centralisé de gestion de haute disponibilité conforme à l'invention 25 - la figure 7 illustre schématiquement une partie d'une infrastructure informatique comprenant des équipements à haute disponibilité regroupés par groupes de haute disponibilité selon plusieurs niveaux de haute disponibilité internes et externes, permettant une gestion de pannes multiples au sein de groupes de haute disponibilité et entre groupes de haute disponibilité ; et, 30 - la figure 8 illustre la mise en oeuvre de mécanismes de haute disponibilité, conformément à l'invention, lorsqu'une panne d'un réseau de communication est détectée dans la partie de l'infrastructure informatique représentée sur la figure 7. De façon générale, l'invention vise à externaliser au moins une partie de la responsabilité de la gestion de la haute-disponibilité d'un groupe 5 d'équipements à un autre groupe d'équipements ayant en charge cette tâche, de façon centralisée et dédiée. Il est d'ores et déjà observé qu'une prise de décision par un système externe de contrôle de haute disponibilité ayant une visibilité globale de l'état des équipements d'un même groupe d'équipements à haute disponibilité offre 10 de nombreux avantages. En particulier, cette approche permet de supprimer des risques dits de split-brain, c'est-à-dire des risques liés au fait que deux équipements se croyant seuls lancent chacun les mêmes ressources, pouvant notamment entraîner des problèmes de corruption de données et des erreurs de fonctionnement, ainsi que des risques dits de dual-fencing selon lesquels 15 deux équipements ne se voyant plus se « tuent » mutuellement, pouvant entraîner une perte de ressources. Elle permet également de s'affranchir de problèmes liés à la charge intrinsèque des équipements, c'est-à-dire la charge système pouvant entrainer des problèmes de réponse au niveau de la haute disponibilité ou des ressources, par exemple des services. 20 En d'autres termes, l'invention a pour objet de déplacer au moins une partie de la gestion de haute disponibilité d'un ensemble de groupes de haute disponibilité à un groupe spécifique d'équipements (également configuré en groupe d'équipements à haute disponibilité). La figure 4 illustre schématiquement l'architecture d'une partie d'une 25 infrastructure informatique telle qu'un cluster comprenant plusieurs groupes d'équipements à haute disponibilité dont l'un est utilisé pour gérer de façon externe et centralisée la gestion de haute disponibilité. La partie illustrée de l'infrastructure informatique comprend ici quatre groupes de noeuds fonctionnels référencés 400-0 à 400-3, chacun de ces 30 groupes comprenant, dans cet exemple, quatre noeuds. Ainsi, à titre d'illustration, le groupe de noeuds 400-0 comprend les quatre noeuds 405-00 à 405-03. Les ensembles de noeuds 400-0 à 400-3 sont connectés à un groupe de noeuds 410 dédié à la gestion de la haute disponibilité via des commutateurs référencés 415-0 et 415-1. Comme illustré, le groupe de noeuds 410 dédié à la gestion de la haute disponibilité comprend ici trois noeuds. Chaque noeud du groupe de noeuds 410 dédié à la gestion de la haute disponibilité est connecté à chaque noeud de chacun des groupes de noeuds 400-0 à 400-3 via les commutateurs 415-0. De même, chaque noeud du groupe de noeuds 410 dédié à la gestion de la haute disponibilité est connecté à chaque noeud de chacun des groupes de noeuds 400-0 à 400-3 via les commutateurs 415-1 Ainsi, par exemple, si la connexion 420 entre un noeud du groupe de noeuds 410 dédié à la gestion de la haute disponibilité et les commutateurs 415-1 comprend un seul lien, la connexion 425 entre les noeud du groupe de noeuds 400-2 et les commutateurs 415-1 comprend ici quatre liens (un par paire de noeud). L'architecture illustrée sur la figure 4 permet plusieurs mises en oeuvre de l'invention. Selon une première implémentation, l'ensemble de la gestion de la haute disponibilité est traitée par le groupe dédié à la gestion de la haute disponibilité. Alternativement, selon une seconde implémentation, seules certaines opérations relatives à la gestion de la haute disponibilité sont traitées par ce groupe. Il est observé ici que s'il semble intéressant de mettre en oeuvre l'ensemble de la gestion de la haute disponibilité dans le groupe dédié à la gestion de la haute disponibilité, une telle solution s'avère néanmoins, en pratique, aujourd'hui, peu réalisable du fait de la charge générée et la complexité d'implémentation. En effet, l'ensemble des tâches de surveillance et d'opérations gérées par l'ensemble des noeuds de chaque groupe étant ici reporté dans un groupe distant dédié à la gestion de la haute disponibilité, ce groupe doit comprendre un nombre de noeuds important, pouvant engendrer un coût excessif. Par conséquent, le transfert d'une partie seulement de la gestion de la haute disponibilité dans un groupe distant dédié à la gestion de la haute disponibilité s'avère généralement efficace en termes de performances et de coûts et adapté à de grandes et très grandes infrastructures informatiques, notamment des clusters de type HPC. Comme décrit précédemment, un mécanisme de haute disponibilité couramment utilisé a pour objet la vérification, par chacun des équipements d'un groupe, du bon fonctionnement des autres équipements du même groupe, auxquels des ressources ou des ensembles de ressources sont affectés, ainsi que des ressources elles-mêmes, par exemple des services, des systèmes de gestion de fichiers et des configurations d'adresses (typiquement des adresses IP). Plus généralement, ce mécanisme a pour objet la vérification de toutes les ressources matérielles et/ou logicielles d'un groupe. Un tel mécanisme, mis en oeuvre au sein d'un groupe d'équipements formant un réseau, peut notamment consister à vérifier le bon fonctionnement des ressources par la réception d'indications de bon fonctionnement. Il est observé ici que de telles indications peuvent transiter par un réseau secondaire, par exemple un réseau d'administration. L'invention vise donc à déplacer ce mécanisme et, le cas échéant (conformément à la première implémentation décrite) les mécanismes de surveillance de chaque ressource surveillée, vers des équipements d'un groupe dédié à la gestion de la haute disponibilité afin d'optimiser la gestion de la haute disponibilité et, notamment, supprimer des risques de split-brain et de dualfencing. Selon la seconde implémentation, les équipements des groupes d'équipements à haute disponibilité (à l'exception des équipements du groupe dédié à la gestion de la haute disponibilité) gèrent leurs ressources de façon standard, c'est-à-dire de la même manière que dans les solutions actuelles. Il n'est donc pas nécessaire d'effectuer un redéveloppement logiciel complet des mécanismes mis en oeuvre. Néanmoins, il est observé ici que le mécanisme de surveillance permettant de prendre la décision d'activer le mécanisme d'inhibition d'un équipement (opération appelée fence en terminologie anglo- saxonne) n'est pas nécessaire au sein de chaque équipement des groupes à haute disponibilité. En effet, en cas de défaillance d'un équipement, les équipements du groupe dédié de gestion de la haute disponibilité détectent cette défaillance et prennent la décision de réaliser l'opération dite de fencing. Lorsque cette opération est réalisée et acquittée (c'est-à-dire effectivement exécutée), les équipements du groupe dédié de gestion de la haute disponibilité en informent chaque équipement actif du groupe d'équipements à haute disponibilité concerné afin d'autoriser un redéploiement des ressources précédemment mises en oeuvre par l'équipement défaillant sur les autres équipements du groupe. Une autre méthode de gestion de défaillances est également possible en conservant une gestion de la haute disponibilité de façon locale au groupe d'équipements à haute disponibilité. Ainsi, la défaillance d'une ressource est détectée par tous les (autres) équipements du groupe qui génèrent une instruction de fence, comme dans les solutions couramment mises en oeuvre. Cependant, contrairement à ces dernières, l'instruction de fence générée n'est pas ici adressée à l'équipement défaillant (ou à l'équipement comprenant une ressource défaillante), mais aux équipements du groupe dédié à la gestion de la haute disponibilité à l'aide d'une requête particulière visant une instruction de fence de l'équipement détecté comme défaillant. Les équipements du groupe dédié de gestion de la haute disponibilité décident d'exécuter ou non l'instruction de fence en fonction des informations à leur disposition en vérifiant l'état global du groupe d'équipements à haute disponibilité (et, le cas échéant, des autres groupes d'équipements à haute disponibilité qu'ils contrôlent). Si l'instruction de fence doit être exécutée, une confirmation est transmise aux équipements du groupe d'équipements à haute disponibilité ayant soumis la requête initiale avec une indication de succès. Si, au contraire, l'instruction de fence ne doit pas être exécutée, une indication correspondante est transmise aux équipements du groupe d'équipements à haute disponibilité ayant soumis la requête initiale afin qu'aucune ressource ne soit redéployée dans le groupe d'équipements à haute disponibilité. Une telle méthode permet de détourner le fonctionnement standard de l'opération de fencing sans autre modifications particulières. Il est rappelé ici que l'opération appelée fence vise à « tuer » un équipement considéré défaillant afin de l'inhiber pour qu'aucune des ressources de cet équipement ne réponde à des sollicitations. Il en résulte que le système à haute disponibilité associé (centralisé ou non) détecte que l'ensemble des ressources de l'équipement considéré défaillant ne répond plus et, par conséquent, migre ces ressources sur des équipements opérationnels, typiquement des équipements opérationnels du groupe d'équipements à haute disponibilité auquel appartient l'équipement considéré défaillant. En d'autres termes, cette opération vise à « tuer » l'équipement défaillant de telle sorte qu'il ne soit plus pris en compte par les équipements opérationnels et que ses ressources soient migrées sur ces derniers. Comme décrit précédemment, le groupe dédié de gestion de la haute disponibilité est lui-même un groupe d'équipements à haute disponibilité comprenant au minimum deux équipements ou plus, utilisés, par exemple, selon un mécanisme de décision par quorum. Un double système de surveillance utilisant deux réseaux de communication distincts, c'est-à-dire ici deux réseaux heartbeat, est mis en oeuvre. Ce groupe dédié de gestion de la haute disponibilité ne nécessite pas d'élément particulier. En effet, il ne prend en charge que la surveillance des équipements des groupes d'équipements à haute disponibilité, la prise de décision d'exécution ou non des instructions de "fencing" demandées par les groupes d'équipements à haute disponibilité et le traitement des instructions de "fencing" devant être réalisées. Comme illustré sur la figure 4, chaque équipement du groupe dédié de gestion de la haute disponibilité est connecté à tous les équipements des groupes d'équipements à haute disponibilité par deux réseaux de communication, afin d'assurer la surveillance de tous ces équipements et la redondance d'accès pour cette surveillance (afin d'éviter des points de blocage, appelés SPOF, acronyme de Single Point Of Failure en terminologie anglo-saxonne). Les deux réseaux de communication utilisés peuvent être de même type ou de types différents. Ainsi, par exemple, un premier réseau de communication peut être du type Ethernet et le second du type Inifiniband ou le premier de type Ethernet 1G et le second du type Ethernet 10G (Ethernet et Infiniband sont des marques). Une telle implémentation permet ainsi la mise en oeuvre centralisée d'une gestion de haute disponibilité de type heartbeat, c'est-à-dire une gestion de type heartbeat de tous les groupes d'équipements à haute disponibilité. Il est observé ici que si, sur la figure 4, chaque équipement du groupe dédié de gestion de la haute disponibilité est connecté à tous les équipements des groupes d'équipements à haute disponibilité par deux réseaux de communication, afin d'assurer la surveillance de tous ces équipements, il 10 suffit qu'au moins deux équipements du groupe dédié de gestion de la haute disponibilité soient connectés à tous les équipements des groupes d'équipements à haute disponibilité. En outre, il est possible d'utiliser plus de deux réseaux de communication pour surveiller tous les équipements des groupes d'équipements à haute disponibilité. 15 La figure 5a illustre des étapes d'un premier exemple d'algorithme pour gérer la haute disponibilité de groupes d'équipements à haute disponibilité conformément à l'invention à partir d'un équipement d'un groupe dédié à la gestion de la haute disponibilité. Comme illustré, une première étape (étape 500) consiste en une 20 initialisation de l'algorithme. Cette étape vise, en particulier, l'initialisation de compteurs utilisés pour identifier une panne d'un équipement. A ces fins, un compteur noté Timerij est associé à chaque d'équipement j de chaque groupe i d'équipements à haute disponibilité. Ces compteurs sont initialisés à la valeur zéro durant la phase d'initialisation. Ces compteurs sont automatiquement 25 incrémentés au cours du temps, par exemple de la valeur un toutes les n ms. Une étape suivante (étape 505) consiste à recevoir des indications de fonctionnement d'équipements de groupes d'équipements à haute disponibilité. Les indications de fonctionnement sont de type heartbeat. Ainsi, la réception d'une indication de fonctionnement d'un équipement j d'un groupe i 30 d'équipements à haute disponibilité, notée HE3u, permet d'établir que cet équipement fonctionne correctement à l'instant présent. Le compteur correspondant à l'équipement duquel est reçue une notification de fonctionnement, c'est-à-dire ici le compteur Timerij associé à l'équipement j du groupe i d'équipements à haute disponibilité, est réinitialisé à la valeur zéro (étape 510). Comme représenté, ces deux étapes sont répétées pour chaque indication de fonctionnement reçue. Parallèlement, un test est effectué (étape 515) pour déterminer s'il existe un compteur associé à un équipement d'un groupe d'équipements à haute disponibilité ayant une valeur supérieure à un seuil 0 prédéterminé, indiquant une panne de l'équipement correspondant. Dans la négative, l'algorithme reboucle sur lui-même. S'il existe un compteur associé à un équipement / d'un groupe k d'équipements à haute disponibilité dont la valeur est supérieure au seuil 0, des variables m et n sont initialisées à la valeur zéro (étape 520). La variable m représente ici un index d'équipement dans un groupe d'équipements à haute disponibilité tandis que la variable n a pour objet d'indiquer le nombre d'équipements opérationnels dans ce groupe. Il est observé que l'équipement / du groupe k est un équipement, par exemple un noeud, qui ne transmet plus correctement son heartbeat (conformément au processus permettant de vérifier que l'équipement est opérationnel et accessible) à des équipements du groupe dédié de gestion de la haute disponibilité. Dans ce cas, il convient donc de déterminer quels sont les équipements opérationnels appartenant au même groupe d'équipements de haute disponibilité que l'équipement défaillant afin de réorganiser les ressources. A ces fins, un test est exécuté (étape 525) pour comparer la valeur du compteur Timerk,m associé à l'équipement m du groupe k au seuil O. Si la valeur du compteur Timerk,m associé à l'équipement m du groupe k est inférieure au seuil 0, l'équipement m du groupe k est opérationnel. L'index m est alors mémorisé et la variable n est incrémentée de un (étape 530). Si la valeur du compteur Timerk,m associé à l'équipement m du groupe k est supérieure ou égale au seuil 0 ou après avoir mémorisé l'index m et incrémenté la variable n, l'index m est incrémenté de un (étape 535) et un test est effectué (étape 540) pour déterminer si la valeur de l'index m est supérieure ou égale à une valeur trima, représentant le nombre d'équipement dans le groupe k. Dans la négative, les étapes précédentes référencées 525 à 540 sont répétées. Si, au contraire, la valeur de l'index m est supérieure ou égale à une valeur mmax, un autre test est effectué (étape 545) pour déterminer s'il existe des équipements opérationnels dans le groupe k, c'est-à-dire si la variable n est supérieure à zéro. Si aucun des équipements du groupe k n'est opérationnel, c'est-à- dire si la valeur de la variable n est nulle, aucune solution standard de haute disponibilité ne peut être envisagée car il n'est pas possible de migrer les ressources de l'équipement défaillant vers un autre équipement du même groupe de haute disponibilité. Cependant, dans ce cas, il peut être possible, comme décrit ci-après, si l'architecture de l'infrastructure informatique le permet, de migrer toutes les ressources associées au groupe k, dans lequel une défaillance a été détectée et dont aucun équipement ne répond, vers des équipements d'un autre groupe d'équipements à haute disponibilité (étape 550). Au contraire, s'il existe au moins un équipement opérationnel dans le groupe k, c'est-à-dire si la valeur de la variable n est supérieure ou égale à un, un équipement du groupe dédié de gestion de la haute disponibilité émet une instruction de fence à destination des équipements opérationnels de ce groupe pour « tuer » l'équipement défaillant afin de redistribuer les ressources qui lui étaient affectées et qu'il ne soit plus pris en compte par les équipements opérationnels (étape 555). En outre, cet équipement du groupe dédié de gestion de la haute disponibilité informe les équipements opérationnels du groupe k que l'opération de fence s'est bien déroulée. Le transfert des ressources, typiquement de services et de paramètres associés, entre l'équipement défaillant et les équipements opérationnels est réalisé par ces derniers, de façon standard. L'implémentation de cette opération peut être réalisée, par exemple, via le réseau de communication utilisé, au niveau du système d'exploitation ou au niveau BMC/IPMI (sigles de Baseboard Management Controller et d'Intelligent Platform Management Interface en terminologie anglo-saxonne), ou via une gestion électrique pouvant utiliser un PDU (sigle de Power Distribution Unit en terminologie anglo-saxonne) contrôlable. Comme illustré, l'algorithme reboucle alors sur lui-même pour traiter, le cas échéant, d'autres défaillances. Les figures 5b et 5c illustrent des étapes d'un second exemple d'algorithme pour gérer la haute disponibilité de groupes d'équipements à haute disponibilité conformément à l'invention à partir d'un équipement d'un groupe dédié à la gestion de la haute disponibilité. Les étapes représentées sur la figure 5b sont ici mises en oeuvre dans des équipements d'un groupe d'équipements à haute disponibilité tandis que les étapes représentées sur la figure 5c sont mises en oeuvre dans un équipement d'un groupe d'équipements dédié à la gestion de la haute disponibilité. Comme illustré, une première étape (étape 500') consiste en une initialisation qui vise, en particulier, l'initialisation de compteurs utilisés pour identifier une panne d'un équipement. A ces fins, un compteur noté Timer; est associé à chaque équipement j du groupe d'équipements à haute disponibilité auquel appartient l'équipement mettant en oeuvre l'algorithme, à l'exception de ce dernier. Ces compteurs sont initialisés à la valeur zéro durant la phase d'initialisation. Ils sont automatiquement incrémentés au cours du temps, par exemple de la valeur un toutes les n ms. Une étape suivante (étape 505') consiste à recevoir des indications de fonctionnement d'équipements du groupe d'équipements à haute disponibilité auquel appartient l'équipement mettant en oeuvre l'algorithme. Les indications de fonctionnement sont de type heartbeat. Ainsi, la réception d'une indication de fonctionnement d'un équipement j, notée HB1, permet d'établir que cet équipement fonctionne correctement à l'instant présent. Le compteur correspondant à l'équipement duquel est reçue une notification de fonctionnement, c'est-à-dire ici le compteur Timer; associé à l'équipement j, est réinitialisé à la valeur zéro (étape 510'). Comme représenté, ces deux étapes sont répétées pour chaque indication de fonctionnement reçue. Parallèlement, un test est effectué (étape 515') pour déterminer s'il existe un compteur associé à un équipement du groupe d'équipements à haute disponibilité, auquel appartient l'équipement mettant en oeuvre l'algorithme, ayant une valeur supérieure à un seuil 0 prédéterminé, indiquant une panne de l'équipement correspondant. Dans la négative, l'algorithme reboucle sur lui-même. S'il existe un compteur associé à un équipement / du groupe d'équipements à haute disponibilité auquel appartient l'équipement mettant en oeuvre l'algorithme dont la valeur est supérieure au seuil 0, une notification de fence est adressée aux équipements du groupe d'équipements dédié à la gestion de la haute disponibilité du groupe auquel appartient l'équipement mettant en oeuvre l'algorithme (étape 555'). Il est noté ici que l'équipement / est un équipement, par exemple un noeud, qui ne transmet plus correctement son heartbeat (conformément au processus permettant de vérifier que l'équipement est opérationnel et accessible) aux équipements de son groupe d'équipements à haute disponibilité. Dans ce cas, une notification de fence est transmise à des équipements d'un groupe d'équipements dédié à la gestion de la haute disponibilité. Ce dernier ayant une vue globale des équipements du groupe à haute disponibilité comprenant l'équipement considéré défaillant peut déterminer s'il convient d'effectuer une opération de fence ou non. L'algorithme mis en oeuvre dans des équipements d'un groupe d'équipements dédié à la gestion de la haute disponibilité, illustré sur la figure 5c, comprend une première étape d'initialisation (étape 560) au cours de laquelle est initialisée une variable Nb noeud op, pour chaque groupe d'équipements à haute disponibilité contrôlé par le groupe d'équipements dédié à la gestion de la haute disponibilité auquel appartient l'équipement mettant en oeuvre l'algorithme. Cette variable correspond au nombre d'équipements opérationnels dans le groupe correspondant lorsque l'algorithme est lancé. Dans une étape suivante (étape 565), un test est effectué pour déterminer si une notification de fence a été reçue d'un équipement d'un groupe k d'équipements à haute disponibilité. Dans la négative, l'algorithme boucle sur lui-même, comme illustré. Si, au contraire, une notification de fence a été reçue, un test est effectué (étape 570) pour déterminer si le nombre d'équipements opérationnels du groupe k d'équipements à haute disponibilité, noté Nb noeud opk est supérieur à un, c'est-à-dire si, outre l'équipement considéré défaillant, il y a au moins un équipement susceptible de mettre en oeuvre les ressources précédemment mises en oeuvre par l'équipement considéré défaillant. Ce test vise également à vérifier que des conditions liées au groupe d'équipements à haute disponibilité auquel appartient l'équipement considéré défaillant sont remplies pour réaliser une opération de fence. Dans l'affirmative, une instruction de fence est transmise à l'équipement considéré défaillant (étape 575). Un test est ensuite effectué pour vérifier que l'opération de fence a été correctement effectuée (étape 580). Si l'opération de fence a été correctement effectuée, la valeur de la variable Nb noeud opk est décrémentée de un (étape 585) et un message de confirmation est adressé aux équipements opérationnels du groupe d'équipements à haute disponibilité auquel appartient l'équipement considéré défaillant (étape 590) pour permettre la migration des ressources mises en oeuvre par l'équipement considéré défaillant, typiquement de services et de paramètres associés. L'algorithme reboucle alors sur lui-même, comme illustré, pour traiter, le cas échéant, d'autres opérations de fence. Si, au contraire, le nombre d'équipements opérationnels du groupe k d'équipements à haute disponibilité est inférieur ou égal à un, un message d'erreur est, de préférence, généré (étape 595). A nouveau, l'algorithme reboucle sur lui-même, comme illustré, pour traiter, le cas échéant, d'autres opérations de fence. Comme décrit précédemment, les équipements des groupes d'équipements à haute disponibilité sont chacun interconnectés avec chaque équipement du groupe d'équipements dédié à la gestion de la haute disponibilité par au moins deux réseaux de communication indépendants et fiables. Ces deux réseaux sont physiquement séparés (ils utilisent des commutateurs différents) pour tous les groupes d'équipements à haute disponibilité. Il est observé ici que les équipements du groupe d'équipements dédié à la gestion de la haute disponibilité doivent être robustes et avoir une configuration conforme à la réalité physique et logique de l'infrastructure globale de l'infrastructure informatique. La figure 6, comprenant les figures 6a à 6d, illustre un scénario de gestion de panne dans une partie d'une infrastructure informatique comprenant un mécanisme centralisé de gestion de haute disponibilité conforme à l'invention. La figure 6a illustre schématiquement l'architecture d'une partie d'une infrastructure informatique comprenant ici trois groupes d'équipements à haute disponibilité dont l'un est utilisé pour gérer de façon externe et centralisée la gestion de haute disponibilité. La partie illustrée de l'infrastructure informatique comprend ici deux groupes d'équipements fonctionnels référencés 600-0 et 600-1, chacun de ces groupes comprenant, dans cet exemple, quatre noeuds. Ainsi, le groupe 600-0 comprend les quatre noeuds 605-00 à 605-03 tandis que le groupe 600-1 comprend les quatre noeuds 605-10 à 605-13. Chaque noeud de chaque groupe de noeuds 600-0 et 600-1 est connecté à un noeud d'un groupe de noeuds 610 dédié à la gestion de la haute disponibilité via des commutateurs référencés 615-0 et 615-1, par exemple des commutateurs Ethernet. Comme illustré, le groupe de noeuds 610 dédié à la gestion de la haute disponibilité comprend ici trois noeuds référencés 620-0 à 620-2. Ainsi, comme illustré, chaque noeud de chaque groupe de noeuds 600-0 et 600-1 est doublement connecté à un noeud du groupe de noeuds 610 dédié à la gestion de la haute disponibilité via deux réseaux de communication différents (utilisant des commutateurs différents). A titre d'illustration, les groupes de noeuds 600-0 et 600-1 sont ici dédiés à la gestion d'un système de fichiers de type Lustre mettant en oeuvre des serveurs de stockage d'objets (OSS, sigle d'Object Storage Server en terminologie anglo-saxonne) pour stocker des données dans des cibles de stockage d'objets (OST, sigle d'Object Storage Target en terminologie anglo-saxonne) gérant des systèmes de fichiers de disques locaux. Toujours à titre d'illustration, il est supposé qu'une défaillance intervient dans le noeud 605-01, comme représenté par la plus grande croix en trait gras sur la figure 6b. Du fait de cette défaillance, aucune notification de fonctionnement (heartbeat) n'est adressée aux noeuds du groupe 610 dédié à la gestion de la haute disponibilité, comme représenté par les deux plus petites croix en trait gras sur la figure 6b. Ainsi, en utilisant un algorithme tel que ceux décrits en référence à la figure 5, les noeuds du groupe 610 dédié à la gestion de la haute disponibilité détectent la défaillance du noeud 605-01 (directement ou via une notification de fence reçue des noeuds opérationnels du groupe dans lequel la défaillance a été détectée, c'est-à-dire des noeuds 605-00, 605-02 et 605-03). Ils adressent alors une instruction de type fence au noeud 605-01. Ce dernier est alors « tué » afin que les autres noeuds du groupe soient informés de la défaillance par le groupe dédié à la gestion de la haute disponibilité (représenté sur la figure 6b par des flèches droites en trait gras) et puissent migrer les ressources allouées au noeud 605-01 vers un ou plusieurs noeuds opérationnels du groupe (représenté sur la figure 6b par des flèches courbes en trait gras). La figure 6c illustre la configuration des groupes d'équipements 600- 0, 600-1 et 610 après que les ressources allouées au noeud 605-01 aient été réparties sur les noeuds 605-00, 605-02 et 605-03. Il est observé ici que le mécanisme de gestion centralisé de la haute disponibilité est capable de gérer les pannes multiples. Ainsi, par exemple, si le noeud 605-00 connaît à son tour une défaillance, comme illustré sur la figure 6d, les ressources qu'il gère sont transférées sur les noeuds 605-02 et 605-03. Le mécanisme de gestion de panne multiple est facile à mettre en oeuvre du fait que la gestion de la haute disponibilité est centralisée avec une vision d'ensemble de l'état des groupes d'équipements à haute disponibilité du fait qu'il n'est plus nécessaire d'avoir une gestion de quorum dans les groupes d'équipements à haute disponibilité surveillés car la partie décisionnelle est externalisée. En outre, le mécanisme de gestion centralisé de la haute disponibilité permet une bascule entre groupes, c'est-à-dire un transfert de services entre 5 des noeuds de groupes différents. Lors de la détection de défaillances, l'identification d'une solution est avantageusement réalisée en deux temps. Tout d'abord, une analyse est effectuée au niveau du ou des groupes d'équipements à haute disponibilité dans lequel la ou les défaillances ont été détectées pour tenter de trouver une 10 solution à ce niveau, comme décrits précédemment. Si aucune solution n'est identifiée au cours de cette première analyse, une seconde analyse basée sur des mécanismes de haute disponibilité externes aux groupes de haute disponibilité est alors effectuée. Un tel mode de réalisation est illustré sur la figure 7 qui représente 15 une partie d'une infrastructure informatique comprenant quatre groupes de haute disponibilité référencés 700-0 à 700-4. Chaque groupe de haute disponibilité comprend ici quatre noeuds et trois commutateurs (deux noeuds étant connectés de façon distincte à deux commutateurs et deux autres noeuds étant connectés à un même 20 commutateur). A titre d'illustration, un premier noeud du groupe d'équipements 7000 met ici en oeuvre les cibles de stockage d'objets OST1, OST2 et OST3, un deuxième noeud met en oeuvre les cibles de stockage d'objets OST4, OST5 et OST6, un troisième noeud met en oeuvre les cibles de stockage d'objets OST7, 25 OST8 et OST9 et un quatrième noeud met ici en oeuvre les cibles de stockage d'objets OST10, OST11 et OST12. Les équipements de chaque groupe d'équipements à haute disponibilité sont avantageusement répartis en groupes de haute disponibilité selon plusieurs niveaux internes. Ainsi, par exemple, un premier niveau de 30 haute disponibilité interne est associé au groupe 700-0 tandis qu'un second niveau interne est associé aux groupes 705-00 et 705-01 qui comprennent ici chacun deux noeuds du groupe 700-0, comme illustré. Les équipements des groupes 700-1, 700-2 et 700-3 sont répartis par groupes de haute disponibilité selon plusieurs niveaux internes, de façon similaire. Par convention, le second niveau de haute disponibilité a ici une valeur supérieure à celle du premier niveau de haute disponibilité. Lorsqu'une solution de haute disponibilité est recherchée au sein d'un groupe d'équipements à haute disponibilité, une solution est cherchée pour le niveau le plus faible. Si aucune solution n'est trouvée pour ce niveau, une solution est cherchée pour le niveau supérieur et ainsi de suite. Comme illustrés, des équipements sont communs à plusieurs groupes de niveaux différents (chaque groupe HA d'un niveau comprend des équipements d'un groupe HA d'un niveau inférieur). Par exemple, des commutateurs appartiennent au groupe 700-0 de premier niveau et au groupe 705-01 de second niveau. En outre, des équipements sont communs à plusieurs groupes de même niveau. Par exemple, un commutateur du groupe 700-0 appartient aux deux groupes 705-00 et 705-01 de second niveau. Les groupes de haute disponibilité 700-0 et 700-1 correspondent ici à un premier système de fichiers tandis que les groupes de haute disponibilité 700-2 et 700-3 correspondent ici à un second système de fichiers. Les groupes de haute disponibilité 700-0 et 700-1 sont regroupés pour former une première cellule de haute disponibilité. Un premier niveau de haute disponibilité externe référencé 710-0 est associé aux éléments de cette cellule. De façon similaire, les groupes de haute disponibilité 700-2 et 700-3 sont regroupés pour former une seconde cellule de haute disponibilité à laquelle est également associé un premier niveau de haute disponibilité externe (710-1), deux niveaux de haute disponibilité étant également associés à chaque élément de la cellule comme représenté. Il est observé ici que si les cellules ne comprennent ici que deux groupes de haute disponibilité, le nombre de groupes n'est pas limité à deux. Un second niveau de haute disponibilité externe (non représenté) est ici associé à l'ensemble des équipements des deux cellules. Chaque groupe de haute disponibilité est relié à deux noeuds 720-0 et 720-1 d'un groupe 715 d'équipements dédié à la gestion de la haute disponibilité (et formant un autre groupe de haute disponibilité). Les noeuds 720-0 et 720-1 permettent ainsi de transférer des services exécutés par des noeuds d'un groupe de haute disponibilité vers un ou plusieurs autres noeuds du même groupe de haute disponibilité selon un niveau de haute disponibilité interne ou vers des noeuds d'un (ou plusieurs) autre groupe de haute disponibilité de la même cellule ou d'une autre cellule selon un niveau de haute disponibilité externe. La figure 8 illustre la mise en oeuvre de mécanismes de haute disponibilité, conformément à l'invention, lorsqu'une panne du réseau de communication 800 reliant les commutateurs du groupe de haute disponibilité 700-0 et les noeuds 720-0 et 720-1 est détectée (représentée par la croix en trait plein). Dans cette configuration de panne, il n'existe pas de solution basée sur les mécanismes de haute disponibilité liés aux niveaux de haute disponibilité interne (c'est-à-dire aux groupes 700-0, 705-00 et 705-01). En effet, la panne du réseau de communication 800 reliant les commutateurs du groupe de haute disponibilité 700-0 et les noeuds 720-0 et 720-1 engendre une panne multiple dans les groupes de haute disponibilité correspondant aux groupes 700-0, 705-00 et 705-01 (représentée par les croix en trait pointillé). Par contre, il existe une solution liée à la cellule 710-0 consistant à transférer les services mis en oeuvre dans les noeuds du groupe de haute disponibilité 700-0 (service OST1 à OST12) vers des noeuds du groupe de haute disponibilité 700-1 comme représenté par la flèche 805. Il est observé ici que si aucune solution n'avait été trouvée dans la cellule 710-0, une solution aurait consisté à chercher dans la cellule dont le niveau de haute disponibilité externe est directement supérieur au précédent (lié à la cellule 710-0), c'est-à-dire ici la cellule comprenant les cellules 710-0 et 710-1. Il est noté ici que si, pour des raisons d'illustration, la description qui précède vise la gestion de pannes dans des équipements tels que des noeuds, l'invention n'est pas limitée aux noeuds mais peut être mise en oeuvre avec d'autres ressources d'une infrastructure informatique telle qu'un cluster ou un centre de traitement de données (généralement appelé data centre), notamment des commutateurs. De même, bien que la description vise essentiellement les services mis en oeuvre sur les noeuds, l'invention peut également concerner des processus applicatifs ainsi que des contrôleurs d'équipements, par exemple des contrôleurs de stockage et des contrôleurs de réseau, dans lesquels peuvent être implémentés des modules logiciels permettant la gestion de la haute disponibilité selon plusieurs niveaux. 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. REVENDICATIONS1. Procédé de gestion dynamique de services dans une infrastructure informatique comprenant une pluralité d'équipements (405) dont au moins un ensemble forme au moins un groupe (400) d'équipements à haute disponibilité selon lequel des services gérés par un équipement dudit au moins un groupe d'équipements à haute disponibilité sont transférés à au moins un autre équipement dudit groupe d'équipements à haute disponibilité lorsque ledit équipement est considéré défaillant, le procédé comprenant une étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance, ce procédé étant caractérisé en ce que ledit procédé est au moins partiellement mis en oeuvre dans au moins un équipement de gestion de haute disponibilité, ledit au moins un équipement de gestion de haute disponibilité étant un équipement dudit cluster et étant distinct des équipements dudit ensemble d'équipements formant ledit au moins un groupe d'équipements à haute disponibilité. 2. Procédé selon la revendication 1 selon lequel ladite étape de surveillance de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité pour identifier une défaillance comprend une étape de réception (505, 505') d'une indication de fonctionnement de chaque équipement dudit au moins un groupe d'équipements à haute disponibilité, ladite étape de réception d'une indication de fonctionnement étant mise en oeuvre dans ledit au moins un équipement de gestion de haute disponibilité ou dans au moins un équipement dudit au moins un groupe d'équipements à haute disponibilité. 3. Procédé selon la revendication 2 selon lequel un équipement est considéré comme défaillant (515, 515') en l'absence de réception d'une indication de fonctionnement de cet équipement durant un intervalle de temps 30 prédéterminé. 4. Procédé selon la revendication 2 ou la revendication 3 comprenant en outre une étape de réception (565) d'une notification visant l'arrêt d'un équipement considéré défaillant. 5. Procédé selon la revendication 4 comprenant en outre une étape de vérification (570) d'au moins une condition liée à un ensemble d'équipements dudit au moins un groupe d'équipements à haute disponibilité, une étape de transfert de services entre un équipement considéré défaillant et un autre équipement dudit au moins un groupe d'équipements à haute disponibilité étant effectuée en réponse à ladite étape de vérification. 6. Procédé selon l'une quelconque des revendications 2 à 5 comprenant en outre une étape d'identification (540) d'au moins un équipement opérationnel dudit au moins un groupe d'équipements à haute disponibilité, lesdits services gérés par ledit équipement considéré défaillant étant transférés audit au moins un équipement opérationnel. 7. Procédé selon la revendication 6 comprenant en outre une étape de sélection d'au moins un équipement opérationnel parmi un ou des équipements opérationnels identifiés, ladite sélection étant basée sur des niveaux de haute disponibilité associés à des groupes d'équipements à haute disponibilité auxquels appartient ledit au moins un équipement opérationnel identifié. 8. Procédé selon la revendication 6 ou la revendication 7 comprenant en outre une étape de transfert desdits services gérés par ledit équipement considéré défaillant vers au moins un équipement d'un second groupe d'équipements à haute disponibilité, ledit au moins un groupe d'équipements à haute disponibilité étant appelé au moins un premier groupe d'équipements à haute disponibilité, lorsqu'aucun équipement opérationnel n'est identifié dans ledit au moins un premier groupe d'équipements à haute disponibilité. 9. Procédé selon l'une quelconque des revendications précédentes 30 selon lequel ladite étape de transfert desdits services gérés par ledit équipement considéré défaillant est mise en oeuvre au moins partiellement par au moins un équipement vers lequel au moins un desdits services est transféré. 10. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit au moins un équipement de gestion de haute disponibilité appartient à un groupe d'équipements à haute disponibilité dédié à la gestion de la haute disponibilité et distinct dudit au moins un groupe d'équipements à haute disponibilité. 11. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur. 12. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 10.