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 œuvre sur des systèmes de traitement de données appelés clusters (parfois traduit « grappes de serveurs »). Un cluster comprend typiquement un ensemble de nœuds interconnectés. Certains nœuds sont utilisés pour effectuer des tâches de calcul (nœuds de calcul), d'autres pour stocker des données (nœuds de stockage) et un ou plusieurs autres gèrent le cluster (nœuds d'administration). Chaque nœud est par exemple un serveur mettant en œuvre un système d'exploitation tel que Linux (Linux est une marque). La connexion entre les nœuds est, par exemple, réalisée à l'aide de liens de communication Ethernet 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 00 d'un cluster, de type fat-tree. Ce dernier comprend un ensemble de nœuds génériquement référencés 105. Les nœuds appartenant à l'ensemble 110 sont ici des nœuds de calcul tandis que les n uds de l'ensemble 1 15 sont des nœuds de service (nœuds de stockage et nœuds d'administration). Les nœuds de calcul peuvent être regroupés en sous-ensembles 120 appelés îlots de calcul, l'ensemble 1 15 étant appelé îlot de service.

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

Comme illustré sur la figure 2, chaque nœud comprend généralement un ou plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication. Plus précisément, le nœud 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 nœud 200 dispose en outre ici de moyens de stockage interne 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 nœud 200 ou reliés à lui. Les microprocesseurs 204 commandent et dirigent l'exécution des 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 œuvre par l'équipement considéré.

Un tel mécanisme peut, par exemple, être mis en œuvre 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 nœuds 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 nœud 305-0 est connecté au commutateur 310-0, les nœuds 305-1 et 305-2 sont connectés au commutateur 310-1 et le nœud 305-3 est connecté au commutateur 310-2. Chaque nœud 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 œuvre par ce dernier.

La figure 3a représente la situation dans laquelle tous les nœuds, 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 nœuds 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 nœuds et peuvent être des services logiciels en tant que tels, des systèmes de fichiers, des processus, des adresses IP (sigle d'Internet Protocol en terminologie anglo-saxonne), etc..

Il est ici considéré que les nœuds 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 nœuds est défaillant (pour une raison matérielle ou logicielle), un ou plusieurs nœuds 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 œuvre 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 nœud 305-0 n'est plus visible des nœuds 305-1 , 305-2 et 305-3 (les nœuds 305-1 , 305-2 et 305-3 ne reçoivent plus le heartbeat du nœud 305-0). Ces derniers en déduisent donc une anomalie visant le nœud 305-0 (comme illustré par la croix en trait pointillé). Le mécanisme de haute disponibilité distribué dans les nœuds 305-1 , 305-2 et 305-3 est donc mis en œuvre pour redistribuer les services exécutés par le nœud 305-0 sur les nœuds 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 nœud ou un équipement réseau associé à ce nœud tombe en panne, une bascule des services mis en œuvre par ce nœud est automatiquement effectuée pour transférer ces services vers un ou plusieurs nœuds 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 œuvre 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 entraîner 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 œuvre 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 uvre 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'extemalisation 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 œuvre 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 uvre 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 comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. 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, 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 nœud d'un cluster ;

- la figure 3, comprenant les figures 3a et 3b, représente 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 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 é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

- 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,

- la figure 8 illustre la mise en œuvre 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 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 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 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 entraîner des problèmes de réponse au niveau de la haute disponibilité ou des ressources, par exemple des services.

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 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 nœuds fonctionnels référencés 400-0 à 400-3, chacun de ces groupes comprenant, dans cet exemple, quatre nœuds. Ainsi, à titre d'illustration, le groupe de nœuds 400-0 comprend les quatre nœuds 405-00 à 405-03. Les ensembles de nœuds 400-0 à 400-3 sont connectés à un groupe de nœuds 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 nœuds 410 dédié à la gestion de la haute disponibilité comprend ici trois nœuds.

Chaque nœud du groupe de nœuds 410 dédié à la gestion de la haute disponibilité est connecté à chaque nœud de chacun des groupes de nœuds 400-0 à 400-3 via les commutateurs 415-0. De même, chaque nœud du groupe de nœuds 410 dédié à la gestion de la haute disponibilité est connecté à chaque nœud de chacun des groupes de nœuds 400-0 à 400-3 via les commutateurs 415-1 Ainsi, par exemple, si la connexion 420 entre un nœud du groupe de nœuds 410 dédié à la gestion de la haute disponibilité et les commutateurs 415-1 comprend un seul lien, la connexion 425 entre les nœud du groupe de nœuds 400-2 et les commutateurs 415-1 comprend ici quatre liens (un par paire de nœud).

L'architecture illustrée sur la figure 4 permet plusieurs mises en œuvre 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 œuvre 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 nœuds 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 nœuds 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 œuvre 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 dual- fencing.

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 œuvre. 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 uvre 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 œuvre. 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 œuvre. 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 1 G et le second du type Ethernet 10G (Ethernet et Infiniband sont des marques).

Une telle implémentation permet ainsi la mise en œuvre 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 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é.

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 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é Timen _j 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 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 / ^' d'équipements à haute disponibilité, notée HBj _j , 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 Timen _j associé à l'équipement j du groupe / 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 Θ 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 Θ, 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 nœud, 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 Timer _{k m} associé à l'équipement m du groupe k au seuil Θ. Si la valeur du compteur T\ er _m associé à l'équipement m du groupe k est inférieure au seuil Θ, l'équipement m du groupe / 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 Timer _{k m} associé à l'équipement m du groupe k est supérieure ou égale au seuil 6> 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 m _max 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 m _max , 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 œuvre dans des équipements d'un groupe d'équipements à haute disponibilité tandis que les étapes représentées sur la figure 5c sont mises en œuvre 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 _j est associé à chaque équipement j du groupe d'équipements à haute disponibilité auquel appartient l'équipement mettant en œuvre 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 œuvre 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 HB _j , 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 _j 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 uvre l'algorithme, ayant une valeur supérieure à un seuil Θ 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 Θ, 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 œuvre l'algorithme (étape 555').

Il est noté ici que l'équipement / est un équipement, par exemple un nœud, 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 œuvre 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_nœud_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 œuvre 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_nœud_op _k 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 uvre les ressources précédemment mises en œuvre 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_nœud_op _k 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 œuvre 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 nœuds. Ainsi, le groupe 600-0 comprend les quatre nœuds 605-00 à 605-03 tandis que le groupe 600-1 comprend les quatre nœuds 605-10 à 605-13.

Chaque nœud de chaque groupe de nœuds 600-0 et 600-1 est connecté à un nœud d'un groupe de nœuds 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 nœuds 610 dédié à la gestion de la haute disponibilité comprend ici trois nœuds référencés 620-0 à 620-2. Ainsi, comme illustré, chaque nœud de chaque groupe de nœuds 600-0 et 600-1 est doublement connecté à un nœud du groupe de nœuds 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 nœuds 600-0 et 600-1 sont ici dédiés à la gestion d'un système de fichiers de type Lustre mettant en œuvre 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 nœud 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 nœuds 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 nœuds du groupe 610 dédié à la gestion de la haute disponibilité détectent la défaillance du nœud 605-01 (directement ou via une notification de fence reçue des nœuds opérationnels du groupe dans lequel la défaillance a été détectée, c'est-à-dire des nœuds 605-00, 605-02 et 605-03). Ils adressent alors une instruction de type fence au nœud 605-01. Ce dernier est alors « tué » afin que les autres nœuds 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 nœud 605-01 vers un ou plusieurs nœuds 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 nœud 605-01 aient été réparties sur les nœuds 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 nœud 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 nœuds 605-02 et 605-03. Le mécanisme de gestion de panne multiple est facile à mettre en œuvre 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 extern a lisé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 des nœuds 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 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 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 nœuds et trois commutateurs (deux nœuds étant connectés de façon distincte à deux commutateurs et deux autres nœuds étant connectés à un même commutateur).

A titre d'illustration, un premier nœud du groupe d'équipements 700- 0 met ici en œuvre les cibles de stockage d'objets OST1 , OST2 et OST3, un deuxième nœud met en œuvre les cibles de stockage d'objets OST4, OST5 et OST6, un troisième nœud met en œuvre les cibles de stockage d'objets OST7, OST8 et OST9 et un quatrième nœud met ici en œuvre 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 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 nœuds 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 nœuds 720-0 et 720-1 permettent ainsi de transférer des services exécutés par des nœuds d'un groupe de haute disponibilité vers un ou plusieurs autres nœuds du même groupe de haute disponibilité selon un niveau de haute disponibilité interne ou vers des nœuds 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 œuvre 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 nœuds 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 nœuds 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 œuvre dans les nœuds du groupe de haute disponibilité 700-0 (service OST1 à OST12) vers des nœuds 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 nœuds, l'invention n'est pas limitée aux nœuds mais peut être mise en œuvre 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 œuvre sur les nœuds, 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.