Brevet FR2984053A1 — publié le 20130614

La présente invention concerne l'administration d'infrastructures informatiques telles que des clusters et des centres de traitement de données (ou data centre) et plus particulièrement un procédé et un programme d'ordinateur de gestion 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 oeuvre sur des systèmes de traitement de données appelés clusters (parfois traduit « grappes de serveurs »). Un cluster comprend typiquement un ensemble de noeuds interconnectés. Certains noeuds sont utilisés pour effectuer des tâches de calcul (noeuds de calcul), d'autres pour stocker des données (noeuds de stockage) et un ou plusieurs autres gèrent le cluster (noeuds d'administration). Chaque noeud est par exemple un serveur mettant en oeuvre un système d'exploitation tel que Linux (Linux est une marque). La connexion entre les noeuds est, par exemple, réalisée à l'aide de liens de communication Ethernet et de réseaux d'interconnexions (par exemple Infiniband) (Ethernet et Infiniband sont des marques). La figure 1 illustre schématiquement un exemple d'une topologie 100 d'un cluster, de type fat-tree. Ce dernier comprend un ensemble de noeuds génériquement référencés 105. Les noeuds appartenant à l'ensemble 110 sont ici des noeuds de calcul tandis que les noeuds de l'ensemble 115 sont des noeuds de service (noeuds de stockage et noeuds d'administration). Les noeuds de calcul peuvent être regroupés en sous-ensembles 120 appelés îlots de calcul, l'ensemble 115 étant appelé îlot de service. Les noeuds sont reliés les uns aux autres par des commutateurs (appelés switch en terminologie anglo-saxonne), par exemple de façon hiérarchique. Dans l'exemple illustré sur la figure 1, les noeuds sont connectés à des commutateurs 125 de premier niveau qui sont eux-mêmes reliés à des commutateurs 130 de deuxième niveau qui sont à leur tour reliés à des commutateurs 135 de troisième niveau. Comme illustré sur la figure 2, chaque noeud comprend généralement un ou plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication. Plus précisément, le noeud 200 comporte ici un bus de communication 202 auquel sont reliés : - des unités centrales de traitement ou microprocesseurs 204 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - des composants de mémoire vive 206 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution de programmes (comme illustré, chaque composant de mémoire vive peut être associé à un microprocesseur) ; et, - des interfaces de communication 208 adaptées à transmettre et à recevoir des données. Le noeud 200 dispose en outre ici de moyens de stockage interne 210, tels que des disques durs, pouvant notamment comporter le code exécutable de programmes. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le noeud 200 ou reliés à lui. Les microprocesseurs 204 commandent et dirigent l'exécution des 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 oeuvre par l'équipement considéré. Un tel mécanisme peut, par exemple, être mis en oeuvre dans un cluster utilisant le système d'exploitation Unix (Unix est une marque) avec un système de gestion de la haute disponibilité (appelé cluster de haute disponibilité du fait du regroupement d'un ensemble de composants, matériels et logiciels, afin de fournir une fonction donnée) tel que le produit open source connu sous le nom de « Pacemaker ». Il permet le contrôle de composants à haute disponibilité (surveillance et reconfiguration en cas de panne) en utilisant notamment un réseau de surveillance dédié appelé « heartbeat » vérifiant que les composants visés sont opérationnels. 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 noeuds référencés 305-0 à 305-3, et trois commutateurs référencés 310-0 à 310-2 reliés à un réseau de communication 315. Comme illustré, le noeud 305-0 est connecté au commutateur 310-0, les noeuds 305-1 et 305-2 sont connectés au commutateur 310-1 et le noeud 305-3 est connecté au commutateur 310-2. Chaque noeud peut comprendre un ou plusieurs modules logiciels (non représentés) pouvant être à l'origine d'une défaillance. Dans un souci de clarté, il convient de comprendre, dans la suite de la description, que la défaillance d'un équipement peut être liée à une défaillance matérielle d'un composant de ce dernier ou à une défaillance d'un composant logiciel mis en oeuvre par ce dernier. La figure 3a représente la situation dans laquelle tous les noeuds, les commutateurs et le réseau de communication fonctionnent correctement. Dans ce cas, des services, pouvant s'échanger des données, sont exécutés dans les noeuds 305-0 à 305-3. Les services visés ici sont les services au sens de la haute disponibilité. Ils sont liés aux ressources des noeuds et peuvent être des services logiciels en tant que tels, des systèmes de fichiers, des processus, des adresses IP (sigle d'Intemet Protocol en terminologie anglo-saxonne), etc.. Il est ici considéré que les noeuds 305-0 à 305-3 font partie d'un même regroupement d'équipements à haute disponibilité (groupe de haute disponibilité ou groupe HA). Ainsi, lorsque l'un de ces noeuds est défaillant (pour une raison matérielle ou logicielle), un ou plusieurs noeuds opérationnels du groupe prennent le relais. Ceci est également vrai pour les équipements qui les relient au réseau (commutateurs 310-0 à 310-2). Si l'un de ces équipements est défaillant (également pour une raison matérielle ou logicielle), une bascule est effectuée pour assurer la continuité de service. La figure 3b illustre le principe de haute disponibilité mis en oeuvre lorsque le commutateur 310-0 connaît une défaillance, rendant ce dernier indisponible (comme illustré par la croix en trait continu). Lorsque le commutateur 310-0 est défaillant, le noeud 305-0 n'est plus visible des noeuds 305-1, 305-2 et 305-3. Ces derniers en déduisent donc une anomalie visant le noeud 305-0 (comme illustré par la croix en trait pointillé). Le mécanisme de haute disponibilité distribué dans les noeuds 305-1, 305-2 et 305-3 est donc mis en oeuvre pour redistribuer les services exécutés par le noeud 305-0 sur les noeuds 305-1, 305-2 et 305-3 ainsi que les paramètres associés tels que des adresses IP (comme illustré par les flèches). Ainsi, en d'autres termes, si un équipement réseau associé à un noeud tombe en panne, une bascule des services mis en oeuvre par ce noeud 5 est automatiquement effectuée pour transférer ces services vers un ou plusieurs noeuds fonctionnels. La figure 3c illustre les limites du principe de haute disponibilité. Comme décrit précédemment, les noeuds 305-1 et 305-2 partagent ici le même commutateur 310-1, par exemple pour des raisons de coût ou d'architecture. 10 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 noeuds 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 noeuds 305- 15 1 et 305-2 ne sont plus visibles des noeuds 305-0 et 305-3 qui considèrent alors les noeuds 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 oeuvre dans les noeuds. Typiquement, ces mécanismes consistent en une liste de configuration de 20 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 25 garantir que chaque noeud 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. 30 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 oeuvre 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 oeuvre dans de nombreux environnements en utilisant des technologies dites de virtualisation. Toujours selon un mode de réalisation particulier, lesdites étapes du 25 procédé sont mises en oeuvre 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é 30 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 oeuvre 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 oeuvre 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 noeud. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre un exemple de topologie d'un cluster ; - la figure 2 illustre un exemple d'architecture d'un noeud 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 noeud pour mettre en oeuvre 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 oeuvre de mécanismes de haute disponibilité, conformément à l'invention, lorsqu'une panne d'un réseau de communication est détectée dans la partie de l'infrastructure informatique représentée sur la figure 7. De façon générale, l'invention vise à 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 oeuvre des serveurs de stockage d'objets (OSS, sigle d'Object Storage Server en terminologie anglo-saxonne) pour stocker des données dans des cibles de stockage d'objets (OST, sigle d'Object Storage Target en terminologie anglo-saxonne) gérant des systèmes de fichiers de disques locaux. Selon le matériel utilisé, un serveur de stockage d'objets met en oeuvre 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 noeuds 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 noeuds 405-0 et 405-3 sont connectés aux commutateurs 410-0 et 410-2, respectivement, tandis que les noeuds 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 noeud 405-0 met ici en oeuvre les cibles de stockage d'objets 30 OST1, OST2 et OST3, le noeud 405-1 met en oeuvre les cibles de stockage d'objets OST4, OST5 et OST6, le noeud 405-2 met en oeuvre les cibles de stockage d'objets OST7, OST8 et OST9 et le noeud 405-3 met ici en oeuvre 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é Grpl_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 10 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 15 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 20 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 25 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 noeuds, permet de détecter les pannes simples relatives à ces équipements et d'agir en conséquence en répartissant 30 correctement la charge d'un noeud considéré en panne sur les noeuds 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 oeuvre. 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 oeuvre 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 noeud 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 noeud. 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 noeud 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 noeud 405-0 devient invisible pour les noeuds 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 noeud 405-0 considéré comme défaillant, c'est-à-dire ici les cibles de stockage d'objets OST1, OST2 et OST3, vers les noeuds 405-1 à 405-3. Cette solution est alors mise en oeuvre. De même, comme illustré sur la figure 5b, si le commutateur 410-1 tombe en panne, les noeuds 405-1 et 405-2 deviennent invisibles pour les noeuds 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 noeuds 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 noeuds 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 noeud défaillant, ici le noeud 405-1 vers le ou les autres noeuds du groupe de haute disponibilité, c'est-à-dire ici le noeud 405-0. Cette solution est donc mise en oeuvre, comme illustré, en déplaçant les cibles de stockage d'objets OST4 à OST6 vers le noeud 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 noeud défaillant, ici le noeud 405-2 vers le ou les autres noeuds du groupe de haute disponibilité, c'est-à-dire ici le noeud 405-3. Cette solution est donc mise en oeuvre, comme illustré, en déplaçant les cibles de stockage d'objets OST7 à OST9 vers le noeud 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 oeuvre 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 noeud. Ainsi, par exemple, le système d'exploitation (OS, Operating System en terminologie anglo-saxonne) natif du noeud peut être utilisé pour gérer le premier niveau de haute disponibilité tandis qu'un système virtuel mis en oeuvre sur le noeud, représentant un noeud 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 oeuvre sur le noeud 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 oeuvre, au sein d'un noeud, 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 noeud pour mettre en oeuvre l'invention. Selon le mode de réalisation présenté ici, les mêmes applications de gestion de haute disponibilité sont mises en oeuvres dans chacun des noeuds 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 noeuds. 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 noeuds 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 noeuds en panne sur un ou plusieurs autre noeuds 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 noeuds 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 noeud 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 noeuds 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 oeuvre 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 oeuvre 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 noeuds par groupe de haute disponibilité qui est généralement limité à 2, 4 ou 8 noeuds 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 noeuds 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 noeud 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 noeuds 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 oeuvre. 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 noeuds 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 groupes de haute disponibilité. Les noeuds 710-0 et 710-1 permettent ainsi de transférer des services exécutés par des noeuds d'un groupe de haute disponibilité vers des noeuds d'un (ou plusieurs) autre groupe de haute disponibilité de la même cellule ou d'une autre cellule selon un niveau de haute disponibilité externe. La figure 8 illustre la mise en oeuvre de mécanismes de haute disponibilité, conformément à l'invention, lorsqu'une panne du réseau de communication 415 reliant les commutateurs du groupe de haute disponibilité 700-0 et les noeuds 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 noeuds 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 oeuvre dans les noeuds du groupe de haute disponibilité 700-0 (service OST1 à OST12) vers des noeuds du groupe de haute disponibilité 700-1 comme représenté par la flèche 800. Il 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. Il est noté ici que si, pour des raisons d'illustration, la description qui précède vise la gestion de pannes dans des équipements tels que des noeuds, l'invention n'est pas limitée aux noeuds mais peut être mise en oeuvre avec d'autres ressources d'une infrastructure informatique telle qu'un cluster ou un centre de traitement de données (généralement appelé data centre), notamment des commutateurs. De même, bien que la description vise essentiellement les services mis en oeuvre sur les noeuds, l'invention peut également concerner des processus applicatifs ainsi que des contrôleurs d'équipements, par exemple des contrôleurs de stockage et des contrôleurs de réseau, dans lesquels peuvent être implémentés des modules logiciels permettant la gestion de la haute disponibilité selon plusieurs niveaux. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. REVENDICATIONS1. Procédé de gestion dynamique de services dans une infrastructure informatique comprenant une pluralité d'équipements 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, ce procédé étant caractérisé en ce qu'un premier niveau de haute disponibilité est associé audit au moins un groupe d'équipements à haute disponibilité, en ce qu'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é, forme 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 en ce qu'il comprend les étapes suivantes, - détection (605) d'une défaillance d'au moins un équipement dudit ensemble d'équipements ; - recherche (610) 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 (620) 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 (630, 610) d'une solution de haute disponibilité dans des groupes d'équipements à haute disponibilité auxquels estassocié ledit second niveau de haute disponibilité et comprenant ledit au moins un équipement défaillant. 2. Procédé selon la revendication 1 selon lequel 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. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape de transfert d'au moins un service mis en oeuvre dans ledit au moins un équipement défaillant vers au moins un équipement visé dans une solution identifiée. 4. Procédé selon l'une quelconque des revendications 1 à 3 selon lequel 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é. 5. Procédé selon l'une quelconque des revendications précédentes selon lequel lesdites étapes du procédé sont mises en oeuvre par des équipements dudit au moins un premier groupe d'équipements à haute disponibilité. 6. Procédé selon l'une quelconque des revendications précédentes selon lequel 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é leditsecond 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é. 7. Procédé selon la revendication 6 selon lequel 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 oeuvre dans un équipement distinct desdits au moins deux premiers groupes d'équipements à haute disponibilité. 8. Procédé selon l'une quelconque des revendications précédentes selon lequel un équipement défaillant est un équipement en panne ou un équipement considéré en panne du fait d'un autre équipement en panne, ladite panne étant matérielle et/ou logicielle. 9. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite pluralité d'équipements comprend une pluralité de noeuds. 10. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur. 11. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à9.