Procédé et programme d'ordinateur de gestion de pannes multiples dans une infrastructure informatigue comprenant des équipements à haute disponibilité 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 de pannes multiples, notamment de doubles 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 œ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 115 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 115 é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 tombe en panne à un instant donné. Les pannes dites « multiples », ou pannes simultanées, sont beaucoup plus complexes à gérer car le nombre de cas à traiter augmente exponentiellement avec le nombre d'équipements. 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.

A titre d'illustration, la figure 3, comprenant les figures 3a, 3b et 3c, 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. 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 équipement réseau associé à un 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.

La figure 3c illustre les limites du principe de haute disponibilité. Comme décrit précédemment, les nœuds 305-1 et 305-2 partagent ici le même commutateur 310-1 , par exemple pour des raisons de coût ou d'architecture. Par conséquent, la défaillance du commutateur 310-1 (représenté par une croix en trait continu sur la figure 3c) entraîne la détection d'une double panne car chacun des nœuds 305-1 et 305-2 devient isolé (représenté par une croix en trait pointillé sur la figure 3c).

En effet, lorsque le commutateur 310-1 est défaillant, les nœuds 305- 1 et 305-2 ne sont plus visibles des nœuds 305-0 et 305-3 qui considèrent alors les nœuds 305-1 et 305-2 comme défaillants.

Une telle configuration n'est généralement pas gérée par les mécanismes de haute disponibilité mis en œuvre dans les nœuds. Typiquement, ces mécanismes consistent en une liste de configuration de pannes et une liste d'adaptation correspondante, formant une solution. Ces listes étant exhaustives, elles ne peuvent 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.

Une solution matérielle consiste à ajouter un commutateur pour garantir que chaque nœud dispose d'un commutateur qui lui est propre. Cependant, une telle solution peut ne pas être envisageable, notamment pour des raisons de coûts et/ou d'architecture.

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 au moins un groupe d'équipements à haute disponibilité lorsque ledit équipement est considéré défaillant, un premier niveau de haute disponibilité étant associé audit au moins un groupe d'équipements à haute disponibilité, une pluralité de sous-ensembles dudit ensemble d'équipements dudit au moins un groupe d'équipements à haute disponibilité, appelé premier groupe d'équipements à haute disponibilité, formant une pluralité de second groupes d'équipements à haute disponibilité, un second niveau de haute disponibilité étant associé auxdits seconds groupes d'équipements à haute disponibilité et le procédé comprenant les étapes suivantes,

- détection d'une défaillance d'au moins un équipement dudit ensemble d'équipements ;

- recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit premier niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant ; et,

- si aucune solution de haute disponibilité n'est identifiée dans des groupes d'équipements à haute disponibilité auxquels est associé ledit premier niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant,

o recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant.

Le procédé selon l'invention permet ainsi d'apporter des solutions de haute disponibilité à des infrastructures informatiques lorsque des pannes multiples sont identifiées sans nécessiter l'ajout d'équipements particuliers engendrant des coûts importants.

Da façon avantageuse, ladite étape de recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant est appliquée de façon récursive à des groupes d'équipements à haute disponibilité auxquels est associé un niveau de haute disponibilité de rang supérieur au niveau précédemment utilisé pour la recherche . d'une solution et comprenant ledit au moins un équipement défaillant.

Le procédé selon l'invention permet ainsi de trouver des solutions de hautes disponibilités pour de nombreuses configurations d'infrastructures informatiques et/ou des pannes multiples variées.

Le procédé comprend en outre, de préférence, une étape de transfert d'au moins un service mis en œuvre dans ledit au moins un équipement défaillant vers au moins un équipement visé dans une solution identifiée afin d'assurer une fonction de haute disponibilité de l'infrastructure informatique.

Selon un mode de réalisation particulier, ladite étape de recherche d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant comprend une étape de changement d'environnement d'exécution d'au moins un service d'au moins un équipement dudit au moins un premier groupe d'équipements à haute disponibilité. Le procédé selon l'invention est ainsi facile à mettre en œuvre dans de nombreux environnements en utilisant des technologies dites de virtualisation.

Toujours selon un mode de réalisation particulier, lesdites étapes du procédé sont mises en œuvre par des équipements dudit au moins un premier groupe d'équipements à haute disponibilité sans qu'il soit nécessaire d'utiliser d'équipements particuliers.

Toujours selon un mode de réalisation particulier, ladite infrastructure informatique comprend au moins deux premiers groupes de haute disponibilité et, lorsqu'au moins un équipement desdits au moins deux premiers groupes d'équipements à haute disponibilité est défaillant et qu'aucune solution n'a été identifiée dans le premier groupe d'équipements à haute disponibilité comprenant l'équipement défaillant ni dans des groupes d'équipements à haute disponibilité auxquels est associé ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant, le procédé comprend en outre une étape d'identification d'au moins un premier groupe d'équipements à haute disponibilité parmi lesdits au moins deux groupes d'équipements à haute disponibilité, distinct du premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant, adapté à recevoir des services exécutés par des équipements dudit premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant et formant une solution de haute disponibilité. Le procédé selon l'invention permet ainsi d'améliorer une fonction de haute disponibilité de l'infrastructure informatique.

Toujours selon un mode de réalisation particulier, ladite étape d'identification d'au moins un premier groupe d'équipements à haute disponibilité parmi lesdits au moins deux groupes d'équipements à haute disponibilité, adapté à recevoir des services exécutés par des équipements dudit premier groupe d'équipements à haute disponibilité comprenant ledit au moins un équipement défaillant et formant une solution de haute disponibilité, est mise en œuvre dans un équipement distinct desdits au moins deux premiers groupes d'équipements à haute disponibilité. Il est ainsi possible d'utiliser un équipement particulier pour mettre en œuvre certaines étapes de l'invention afin de limiter la charge des équipements des groupes d'équipements à haute disponibilité.

Un équipement défaillant est typiquement un équipement en panne ou un équipement considéré en panne du fait d'un autre équipement en panne, ladite panne pouvant être matérielle et/ou logicielle, un équipement pouvant notamment être un nœud.

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

P'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, 3b et 3c, représente schématiquement une partie d'une infrastructure informatique comprenant des équipements à haute disponibilité lorsque tous ces équipements fonctionnent correctement, lorsqu'une panne est détectée et lorsqu'une double panne est détectée, respectivement ;

- la figure 4 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é conformément à l'invention ;

- la figure 5, comprenant les figures 5a et 5b, illustre des exemples de panne et de double panne, respectivement, dans la partie de l'infrastructure informatique décrite en référence à la figure 4 ;

- la figure 6 illustre un exemple de certaines étapes d'un algorithme utilisé dans un nœud pour mettre en œuvre 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 à contourner la limitation selon laquelle les systèmes dits de haute disponibilité ne savent pas gérer deux pannes simultanées en définissant plusieurs niveaux de surveillance, appelés par la suite niveaux de haute disponibilité, et en imbriquant ces niveaux.

Une telle solution présente un avantage économique particulièrement important en ce qu'elle permet de réduire les équipements considérés comme des points uniques de défaillance (SPOF, Single Point Of Failure en terminologie anglo-saxonne) en ne multipliant pas le nombre d'équipements mais en donnant la responsabilité de la reprise sur panne à une couche applicative de plusieurs niveaux imbriqués.

A titre d'illustration, il est ici considéré une partie d'une infrastructure informatique telle qu'un cluster, utilisant un système de fichiers distribué 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. Selon le matériel utilisé, un serveur de stockage d'objets met en œuvre entre deux et huit cibles de stockage d'objets. Une telle partie de infrastructure informatique est, par exemple, similaire à celle illustrée sur la figure 3.

Comme illustré sur la figure 4, une telle partie d'infrastructure informatique, référencée ici 400, comprend, selon cet exemple, quatre nœuds référencés 405-0 à 405-3 et trois commutateurs référencés 410-0 à 410-2. De façon similaire à la partie de l'infrastructure informatique représentée sur la figure 3, les nœuds 405-0 et 405-3 sont connectés aux commutateurs 410-0 et 410-2, respectivement, tandis que les nœuds 405-1 et 405-2 sont connectés au commutateur 410-1, les commutateurs 410-0 à 410-2 étant reliés entre eux par un réseau de communication 415.

Le nœud 405-0 met ici en œuvre les cibles de stockage d'objets OST1 , OST2 et OST3, le nœud 405-1 met en œuvre les cibles de stockage d'objets OST4, OST5 et OST6, le nœud 405-2 met en œuvre les cibles de stockage d'objets OST7, OST8 et OST9 et le nœud 405-3 met ici en œuvre les cibles de stockage d'objets OST10, OST11 et OST12.

Conformément à l'invention, ces ensembles d'équipements sont répartis en groupes de haute disponibilité (groupes HA) selon plusieurs niveaux. Ainsi, selon l'exemple illustré sur la figure 4, un premier niveau de haute disponibilité est associé au groupe 420, noté Grp1_HA niv 1 , qui comprend ici tous les équipements de la partie 400 de l'infrastructure informatique.

De même, un second niveau de haute disponibilité est associé aux groupes 425-0 et 425-1 , notés Grp1_HA niv 2 et Grp2_HA niv 2, respectivement. Par convention, le second niveau de haute disponibilité a ici une valeur. supérieure à celle du premier niveau de haute disponibilité.

Comme illustrés sur la figure 4, 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, les commutateurs 410-0 et 410-1 appartiennent au groupe 420 de premier niveau et au groupe 425-1 de second niveau. En outre, des équipements sont communs à plusieurs groupes de même niveau. Par exemple, le commutateur 410-1 appartient aux groupes 425-0 et 425-1 de second niveau.

L'utilisation de plusieurs groupes de haute disponibilité ayant différents niveaux de haute disponibilité et comprenant des équipements communs permet de gérer facilement des situations de pannes multiples et en particulier de doubles pannes en décomposant l'infrastructure informatique considérée pour permettre le traitement de ces pannes multiples comme de simples pannes.

En effet, le premier niveau en charge de gérer le groupe d'équipements concernés, ici des nœuds, permet de détecter les pannes simples relatives à ces équipements et d'agir en conséquence en répartissant correctement la charge d'un nœud considéré en panne sur les nœuds restants. Lorsque plusieurs pannes sont détectées dans le groupe de haute disponibilité de premier niveau, il est fait appel aux groupes de haute disponibilité concernés, de second niveau, comprenant les équipements défaillants afin d'identifier un ou plusieurs groupes de haute disponibilité de telle sorte qu'une seule panne soit détectée par groupe de haute disponibilité identifié.

Ainsi, en d'autres termes, lorsqu'une ou plusieurs pannes sont détectées dans un groupe de haute disponibilité d'un niveau donné, un test est effectué pour déterminer s'il est possible de trouver une solution pour répartir la charge de l'équipement ou des équipements défaillants aux autres équipements du groupe. Dans l'affirmative, cette solution est mise en œuvre. Au contraire, s'il n'existe pas de solution, les groupes de haute disponibilité liés à ce groupe de haute disponibilité et du niveau directement supérieur sont sélectionnés et, pour chacun d'eux, un test est effectué pour déterminer s'il est possible de trouver une solution pour répartir la charge de l'équipement ou des équipements défaillants aux autres équipements du groupe considéré. Dans l'affirmative, cette solution est mise en œuvre et l'algorithme se poursuit pour les autres groupes de même niveau dans lesquels des pannes ont été détectées. Dans la négative, l'algorithme se poursuit de façon récursive.

Il est rappelé ici qu'un équipement peut être considéré comme défaillant pour des raisons matérielles ou logicielles. Cependant, un transfert de services est typiquement réalisé entre des équipements différents d'un même groupe d'équipements à haute disponibilité. Néanmoins, par exemple, si un nœud comprend un ensemble de plusieurs cartes réseau et que l'une d'elles tombe en panne, les données qui transitaient par l'interface défaillante (carte réseau en panne) peuvent être redirigées vers une autre interface du même nœud. Ainsi, il peut être considéré qu'en cas de panne logicielle, les services sont transférés entre des équipements différents (typiquement d'un nœud vers un autre) mais que dans le cas d'une panne matérielle, des services peuvent être transférés au sein d'un même équipement (exemple précédent de la carte réseau) ou vers un autre équipement.

La figure 5, comprenant les figures 5a et 5b, illustre des exemples de panne et de double panne, respectivement, dans la partie de l'infrastructure informatique décrite en référence à la figure 4. Comme illustré sur la figure 5a, si le commutateur 410-0 tombe en panne, le nœud 405-0 devient invisible pour les nœuds 405-1 , 405-2 et 405-3 qui appellent alors le mécanisme de haute disponibilité décrit précédemment.

Le groupe de haute disponibilité ayant le niveau le plus bas, c'est-à- dire le groupe 420 (Grp1_H1 niv 1), est ainsi sélectionné. Comme décrit en référence à la figure 3b, il existe une solution standard pour répartir la charge du nœud 405-0 considéré comme défaillant, c'est-à-dire ici les cibles de stockage d'objets OST1 , OST2 et OST3, vers les nœuds 405-1 à 405-3. Cette solution est alors mise en œuvre.

De même, comme illustré sur la figure 5b, si le commutateur 410-1 tombe en panne, les nœuds 405-1 et 405-2 deviennent invisibles pour les nœuds 405-0 et 405-3 qui appellent alors le mécanisme de haute disponibilité décrit précédemment.

Le groupe de haute disponibilité ayant le niveau le plus bas, c'est-à- dire le groupe 420 (Grp1_H1 niv 1), est ainsi sélectionné. Cependant, comme décrit en référence à la figure 3c, il n'existe pas de solution standard pour répartir la charge des nœuds 405-1 et 405-2 considérés comme défaillants, c'est-à-dire ici les cibles de stockage d'objets OST4 à OST9, vers les nœuds 405-0 et 405-3.

Les groupes de haute disponibilité appartenant au groupe 420 précédemment sélectionné et dont le niveau est directement supérieur, c'est-à- dire les groupes 425-0 (Grp1_H1 niv 2) et 425-1 (Grp2_H1 niv 2), sont alors sélectionnés.

Il y a une seule panne dans le groupe de haute disponibilité 425-0 et il existe une solution standard à ce problème consistant à transférer la charge du nœud défaillant, ici le nœud 405-1 vers le ou les autres nœuds du groupe de haute disponibilité, c'est-à-dire ici le nœud 405-0. Cette solution est donc mise en œuvre, comme illustré, en déplaçant les cibles de stockage d'objets OST4 à OST6 vers le nœud 405-0.

De même, il y a une seule panne dans le groupe de haute disponibilité 425-1 et il existe une solution standard à ce problème consistant à transférer la charge du nœud défaillant, ici le nœud 405-2 vers le ou les autres nœuds du groupe de haute disponibilité, c'est-à-dire ici le nœud 405-3. Cette solution est donc mise en œuvre, comme illustré, en déplaçant les cibles de stockage d'objets OST7 à OST9 vers le nœud 405-3.

Pour gérer le mécanisme de haute disponibilité par niveaux, un logiciel de haute disponibilité spécifique, prenant en considération un ou plusieurs niveaux de haute disponibilité, peut être utilisé.

Selon un mode de réalisation particulier, des réseaux dits Heartbeat différents sont utilisés pour chaque groupe de haute disponibilité de chaque niveau.

L'implémentation peut être faite de différentes façons au niveau de la couche applicative.

Il est possible de mettre en œuvre un environnement de haute disponibilité permettant de gérer les divers niveaux et également d'intégrer un système de classement automatique d'équipements par niveau, selon un type d'équipement considéré, une position dans l'infrastructure informatique (par exemple un équipement de réseau ou de stockage) et une fonction. Via les informations disponibles dans une base de données descriptive de l'infrastructure informatique, il est possible de prédéterminer le rôle et les relations entre des composants devant faire partie d'un même groupe HA ou devant faire partie d'un groupe HA d'un niveau supérieur. Il est alors possible de définir la hiérarchie des groupes HA en se basant sur la topologie (relations entre les équipements, principalement au niveau du réseau et/ou du stockage), le rôle de l'équipement visé et surtout sur les liens de cet équipement vers d'autres équipements devant également être opérationnels pour que cet équipement puisse fournir le service attendu.

Il est également possible d'utiliser des produits disponibles utilisant des mécanismes de virtualisation afin de simuler divers niveaux au sein d'un même nœud. Ainsi, par exemple, le système d'exploitation (OS, Operating System en terminologie anglo-saxonne) natif du nœud peut être utilisé pour gérer le premier niveau de haute disponibilité tandis qu'un système virtuel mis en œuvre sur le nœud, représentant un nœud virtuel (aussi appelé OS virtuel), peut être utilisé pour gérer un second niveau de haute disponibilité. De façon similaire, d'autres systèmes virtuels peuvent être mis en œuvre sur le nœud et utilisés pour gérer d'autres niveaux de haute disponibilité.

Selon un tel mode de réalisation, les services devant être migrés avec des paramètres associés lorsqu'un équipement est défaillant sont mis en œuvre, au sein d'un nœud, dans le système (natif ou virtuel) correspondant au premier niveau de haute disponibilité. Puis, lorsqu'une panne est détectée et qu'il n'existe pas de solution dans le premier niveau de haute disponibilité, ces services et, le cas échéant, des paramètres associés, sont déplacés (en général avec des services de l'équipement en panne) vers le système (natif ou virtuel) correspondant au niveau de haute disponibilité pour lequel il existe une solution.

La figure 6 illustre un exemple de certaines étapes d'un algorithme utilisé dans un nœud pour mettre en œuvre l'invention. Selon le mode de réalisation présenté ici, les mêmes applications de gestion de haute disponibilité sont mises en œuvres dans chacun des nœuds d'un groupe de haute disponibilité (du niveau le plus bas). Il n'est donc pas nécessaire de prévoir de mécanisme de synchronisation entre les nœuds.

Une première étape (étape 600) consiste ici à initialiser une variable appelée Niv.HA, représentative du niveau de haute disponibilité courant, à la valeur 1.

Dans une étape suivante (étape 605), un test est effectué pour déterminer si une ou plusieurs pannes sont détectées. Ce test utilise des mécanismes standard des algorithmes de haute disponibilité visant notamment à vérifier que les nœuds du même groupe de haute disponibilité (initialement du plus bas niveau de haute disponibilité) sont accessibles et/ou dans un état prédéterminé.

Si aucune panne n'est détectée, l'algorithme boucle sur lui-même jusqu'à ce qu'au moins une panne soit détectée ou qu'il soit mis fin à l'algorithme.

Au contraire, si une panne est détectée, une solution de haute disponibilité est recherchée (étape 610). Typiquement, une telle étape consiste à identifier une configuration de panne prédéterminée dans une table ou une base de données 615, pour le niveau de haute disponibilité courant (Niv.HA), afin d'identifier la façon de répartir les services exécutés par le ou les nœuds en panne sur un ou plusieurs autre nœuds du même groupe de haute disponibilité du niveau de haute disponibilité courant.

Un test est alors effectué (étape 620) pour déterminer s'il existe une solution prédéterminée pour la répartition des services exécutés par le ou les nœuds en panne.

Dans l'affirmative, la solution est appliquée en effectuant les transferts (étape 625), de façon standard. L'algorithme reboucle alors à l'étape 605 pour traiter, le cas échéant, de nouvelles pannes.

Il est observé ici que s'il n'y a pas de panne dans le groupe de haute disponibilité correspondant au nouveau niveau de haute disponibilité auquel appartient le nœud considéré, il existe une solution qui consiste à ne rien faire.

Dans le cas contraire, s'il n'existe pas de solution prédéterminée pour la répartition des services exécutés par le ou les nœuds en panne, la variable Niv.HA, représentant le niveau de haute disponibilité courant, est incrémentée de un (étape 630).

Un test est alors effectué pour déterminer si la nouvelle valeur de la variable Niv.HA correspond à un niveau de haute disponibilité réel (étape 635), c'est-à-dire si le niveau de haute disponibilité Niv.HA est défini.

Dans la négative, il est mis fin à l'algorithme, aucune solution ne pouvant être apportée à la panne ou aux pannes détectées.

Dans le cas contraire, si la nouvelle valeur de la variable Niv.HA correspond à un niveau de haute disponibilité réel, les étapes précédentes étapes 610 à 635) sont répétées, comme illustré, pour déterminer s'il existe une solution dans le groupe de haute disponibilité correspondant au nouveau niveau de haute disponibilité.

Selon le mode de mise en œuvre de l'invention, il peut être nécessaire, après avoir modifié le niveau de haute disponibilité, de changer d'environnement (étape 640). Un tel changement peut notamment consister à passer d'un système (natif ou virtuel) à un autre et, si nécessaire, à transférer les services exécutés dans le système initial vers le nouveau système utilisé. L'invention peut également être mise en œuvre pour des ensembles de groupes de haute disponibilité, par exemple des groupes de haute disponibilité utilisant un même système de fichiers distribué. L'invention permet alors d'écarter la limitation du nombre de n uds par groupe de haute disponibilité qui est généralement limité à 2, 4 ou 8 nœuds de stockage (OSS), notamment du fait du nombre de liens de type fibre vers les baies de stockage, une telle contrainte ayant en particulier pour conséquence que le nombre de groupes de haute disponibilité de nœuds de stockage est, dans un cluster, typiquement compris entre deux et plusieurs dizaines.

Une solution basée sur un mécanisme de haute disponibilité par niveaux permet, via un système de contrôle externe aux groupes de haute disponibilité, par exemple un nœud lui-même configuré selon un mécanisme de haute disponibilité, dédié à la gestion de ces groupes, de gérer un niveau de haute disponibilité particulier permettant une bascule entre groupes, c'est-à-dire un transfert de services entre des nœuds de groupes différents.

En cas de détection de panne, l'identification d'une solution est avantageusement réalisée en deux temps. Tout d'abord, une analyse utilisant les mécanismes de haute disponibilité internes aux groupes de haute disponibilité, comme décrits précédemment, est, de préférence, effectuée. 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 tel que celui décrit en référence à la figure 4 (référence 400).

Dans un souci de clarté, ces groupes ont ici des architectures similaires cependant, des architectures différentes peuvent tout aussi bien être mises en œuvre.

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é 705-0 est associé aux éléments de cette cellule.

Comme illustré, deux niveaux de haute disponibilité internes sont associés à chaque élément de la cellule (groupes ayant les références 420 d'une part et 425-0 et 425-1 d'autre part), conformément au groupe 400 de haute disponibilité décrit en référence à la figure 4.

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 (705-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 nœuds de gestion de haute disponibilité (formant un autre groupe de haute disponibilité), référencés 710-0 et 710-1 , assurant la fonction de haute disponibilité au niveau des groupés de haute disponibilité. Les nœuds 710-0 et 710-1 permettent ainsi de transférer des services exécutés par des nœuds d'un groupe de haute disponibilité 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 415 reliant les commutateurs du groupe de haute disponibilité 700-0 et les nœuds 710-0 et 710-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 420, 425-0 et 425-1). En effet, la panne du réseau de communication 415 reliant les commutateurs du groupe de haute disponibilité 700-0 et les nœuds 710-0 et 710-1 engendre une panne multiple dans les groupes de haute disponibilité correspondant aux groupes 420, 425-0 et 425-1 de la figure 4 (représentée par les croix en trait pointillé).

Par contre, il existe une solution liée à la cellule 705-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 800.

II est observé ici que si aucune solution n'avait été trouvée dans la cellule 705-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 705-0), c'est-à-dire ici la cellule comprenant les cellules 705-0 et 705-1.

11 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.