Brevet FR3031203A1 — publié le 20160701

METHODE D'ORDONNANCEMENT DE TACHES AU NIVEAU DES NOEUDS D'UN CLUSTER INFORMATIQUE, ORDONNANCEUR DE TACHES ET CLUSTER ASSOCIES DOMAINE DE L'INVENTION L'invention concerne une méthode d'ordonnancement de tâches au niveau d'au moins certains noeuds d'un cluster informatique, un ordonnanceur de tâches à affecter aux noeuds d'un cluster informatique, et un cluster informatique comprenant un tel ordonnanceur de tâches. CONTEXTE DE L'INVENTION Selon un premier art antérieur, il est connu d'arrêter l'exécution de la tâche standard au niveau du noeud considéré, et d'affecter les ressources du noeud considéré pour exécuter la tâche prioritaire avant de pouvoir reprendre l'exécution de la tâche standard ensuite. L'inconvénient de ce premier art antérieur est de devoir intégralement recommencer la tâche standard interrompue, tout le traitement déjà réalisé au niveau de cette tâche standard étant complètement perdu, ou à tout le moins perdu depuis le dernier point de synchronisation. Or, un tel traitement, même depuis le dernier point de synchronisation, peut facilement représenter plusieurs heures, voire plusieurs jours, de traitement au niveau d'un grand nombre de noeuds d'un cluster informatique de taille importante, ce qui représente une masse de traitement ou un temps de calcul considérables, lesquels sont irrémédiablement perdus. Par ailleurs, certaines tâches sont exécutées sans aucun point de synchronisation. Selon un deuxième art antérieur, il est connu d'attendre la fin de l'exécution de cette tâche standard, ou à tout le moins son prochain point de synchronisation, puis de faire passer la tâche prioritaire devant toutes les 3031203 2 autres tâches standard en attente dans une queue de séquencement de ces tâches standard. Aucun traitement de tâche standard déjà effectué n'est alors perdu. Mais, la tâche prioritaire doit attendre sinon la fin de la tâche standard 5 en cours d'exécution ou à tout le moins son exécution jusqu'au prochain point de synchronisation, ce qui peut être très long. Le retardement correspondant d'une tâche prioritaire critique peut être très dommageable. RESUME DE L'INVENTION 10 Le but de la présente invention est de fournir une méthode d'ordonnancement des tâches au niveau des noeuds d'un cluster informatique palliant au moins partiellement les inconvénients précités. Plus particulièrement, l'invention vise à fournir une méthode 15 d'ordonnancement des tâches au niveau des noeuds d'un cluster informatique, laquelle méthode d'abord lance au moins deux containers, un container standard et un container prioritaire, sur un noeud, puis bascule des ressources du container standard vers le container prioritaire, lorsqu'une tâche prioritaire survient pendant que le noeud exécute une tâche standard 20 dans le container standard, ceci afin de pouvoir, d'une part exécuter la tâche prioritaire en urgence dans le container prioritaire avec suffisamment de ressources, et d'autre part continuer à exécuter la tâche standard, même au ralenti, sans devoir l'arrêter et donc sans perdre le travail de traitement déjà effectué. En effet, une tâche arrêtée en cours, doit être intégralement 25 recommencée, tout le travail déjà réalisé étant alors perdu. De cette manière, la gestion des niveaux de priorités de l'ordonnanceur de tâches est optimisée, et la bande passante d'un tel ordonnanceur de tâches est globalement augmentée. La flexibilité d'utilisation d'un cluster implémentant cette méthode d'ordonnancement 30 des tâches au niveau des noeuds du cluster s'en trouve également nettement améliorée. 3031203 3 A cette fin, la présente invention propose une méthode d'ordonnancement de tâches, au niveau d'au moins certains noeuds d'un cluster informatique, comprenant : d'abord, le lancement de deux containers sur chacun desdits noeuds, un container standard et un container prioritaire, 5 ensuite, pour tout ou partie desdits noeuds à deux containers, au niveau de chaque noeud, tant qu'une tâche prioritaire ne survient pas, l'affectation de ou des ressources disponibles du noeud à son container standard pour exécuter une tâche standard, son container prioritaire n'exécutant pas de tâche, lorsqu'une tâche prioritaire survient, le basculement dynamique d'une 10 partie seulement des ressources de son container standard vers son container prioritaire, de manière à ce que, d'une part la tâche prioritaire soit exécutée dans le container prioritaire avec la partie basculée des ressources, et d'autre part la tâche standard continue d'être exécutée, sans être arrêtée, dans le container standard avec la partie non basculée des ressources. 15 Les ressources disponibles du noeud sont les ressources non nécessitées par le fonctionnement interne du noeud ou par l'ouverture du container prioritaire. En cas d'absence de tâche prioritaire, préférentiellement la majorité, voire l'essentiel ou la quasi-totalité des ressources disponibles est affectée au container standard. 20 Les ressources considérées englobent au moins les ressources processeur, et préférentiellement également les ressources mémoire vive. Les ressources considérées peuvent optionnellement englober encore les ressources entrées/sorties et/ou les ressources réseau. Ladite tâche standard peut continuer à être exécutée, sans être arrêtée, 25 jusqu'à la terminaison de cette tâche standard ou jusqu'à un prochain point de synchronisation de cette tâche standard, permettant alors de ne pas perdre le traitement partiel déjà effectué pour cette tâche. L'important est de ne pas arrêter l'exécution de la tâche standard dans des conditions où le travail déjà exécuté pour cette tâche standard va être perdu, mais au contraire, soit de ne 30 pas du tout arrêter l'exécution de la tâche standard soit de n'arrêter 3031203 4 l'exécution de la tâche standard que dans des conditions où le travail déjà exécuté pour cette tâche standard peut être récupéré sans pertes. A cette fin, la présente invention propose aussi un cluster informatique comprenant : plusieurs noeuds, un ordonnanceur de tâches à affecter auxdits 5 noeuds, configuré, pour au moins certains desdits noeuds, de manière à : d'abord, lancer deux containers sur chacun desdits noeuds, un container standard et un container prioritaire, ensuite, pour tout ou partie desdits noeuds à deux containers, au niveau de chaque noeud, tant qu'une tâche prioritaire ne survient pas, affecter des ressources du noeud à son container 10 standard pour exécuter une tâche standard, son container prioritaire n'exécutant pas de tâche, lorsqu'une tâche prioritaire survient, basculer dynamiquement une partie seulement des ressources de son container standard vers son container prioritaire, de manière à ce que, d'une part la tâche prioritaire soit exécutée dans le container prioritaire avec la partie 15 basculée des ressources, et d'autre part la tâche standard continue d'être exécutée, sans être arrêtée, dans le container standard avec la partie non basculée des ressources. A cette fin, la présente invention propose encore un ordonnanceur de tâches à affecter aux noeuds d'un cluster informatique, configuré, pour au 20 moins certains desdits noeuds, de manière à : d'abord, lancer deux containers sur chacun desdits noeuds, un container standard et un container prioritaire, ensuite, pour tout ou partie desdits noeuds à deux containers, au niveau de chaque noeud, tant qu'une tâche prioritaire ne survient pas, affecter des ressources du noeud à son container standard pour exécuter une tâche 25 standard, son container prioritaire n'exécutant pas de tâche, lorsqu'une tâche prioritaire survient, basculer dynamiquement une partie seulement des ressources de son container standard vers son container prioritaire, de manière à ce que, d'une part la tâche prioritaire soit exécutée dans le container prioritaire avec la partie basculée des ressources, et d'autre part la 30 tâche standard continue d'être exécutée, sans être arrêtée, dans le container standard avec la partie non basculée des ressources. 3031203 5 Il pourrait également être envisagé d'installer plusieurs machines virtuelles sur chaque noeud du cluster, mais la gestion de plusieurs machines virtuelles sur un même noeud réel engendrerait une perte importante des performances de traitement des tâches au niveau de ce noeud réel. Cette 5 perte est nettement plus importante dans le cas d'une gestion d'une deuxième machine virtuelle que dans le cas d'une gestion d'un deuxième container, d'un ordre de grandeur supérieur, par exemple environ d'un facteur 10 (par exemple pertes de performances de l'ordre de 30% au lieu de pertes de performances de l'ordre de 3%). 10 Il pourrait également être envisagé d'installer plusieurs « chroots » sur chaque noeud du cluster, mais il ne serait alors pas possible de basculer dynamiquement des ressources d'un chroot vers un autre chroot, au niveau d'un noeud exécutant une tâche standard et recevant une tâche prioritaire pendant qu'il exécute une tâche standard. 15 Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles, avec l'un ou l'autre de chacun des objets précédemment présentés. 20 De préférence, tant qu'une tâche prioritaire ne survient pas, toutes les ressources disponibles du noeud sont affectées à son container standard. De préférence, tant qu'une tâche prioritaire ne survient pas, au moins 90%, de préférence au moins 95%, des ressources du noeud sont affectées au container standard, et/ou moins de 5% des ressources du noeud sont 25 affectées au container prioritaire. Ainsi, en mode normal, c'est-à-dire en l'absence de survenue de tâche prioritaire à effectuer en urgence, les performances du cluster sont similaires à celles qu'il aurait si les noeuds n'avaient pas chacun deux containers. De préférence, une fois la tâche prioritaire terminée, les ressources 30 ayant été basculées du container standard vers le container prioritaire sont rebasculées du container prioritaire vers le container standard. Ainsi, une 3031203 6 fois le cluster revenu au mode normal, c'est-à-dire une fois la tâche prioritaire exécutée en urgence, les performances du cluster redeviennent similaires à celles qu'il aurait si les noeuds n'avaient pas chacun deux containers. 5 De préférence, lorsqu'une tâche prioritaire survient, le basculement des ressources est effectué par un ou plusieurs groupes de contrôle de virtualisation au niveau système d'exploitation disposés dans la couche noyau du noeud. Ainsi, le dimensionnement des ressources affectées aux différents containers, standard et prioritaire, est effectué au niveau du noyau 10 du noeud hôte des containers, c'est-à-dire du noeud hébergeant les containers. De préférence, chaque container possède son système d'exploitation lui permettant de communiquer directement avec le noyau du noeud hôte de ces containers standard et prioritaire, indépendamment du système 15 d'exploitation dudit noeud hôte. Ainsi, chacun des containers, standard et prioritaire, peut se comporter comme un noeud virtuel et être considéré par l'ordonnanceur des tâches comme un noeud virtuel. De préférence, ladite méthode est effectuée au niveau de la majorité des noeuds dudit cluster informatique, de préférence au niveau de tous les 20 noeuds dudit cluster informatique. Ainsi, le cluster aura l'aptitude de gérer une tâche prioritaire requérant un volume de traitement plus important. De préférence, au moins l'un des noeuds à deux containers, de préférence plusieurs noeuds à deux containers, plus de préférence la majorité des noeuds à deux containers, encore plus de préférence tous les noeuds à 25 deux containers, est ou sont des noeuds de calcul. C'est effectivement au niveau des noeuds de calcul que la survenue d'une tâche prioritaire est la plus probable. De préférence, chaque container est un container Linux. En effet, le container Linux d'une part est totalement adapté pour pouvoir être 30 facilement redimensionné dynamiquement en cas de besoin, et d'autre part 3031203 7 dispose d'une structure déjà manipulable par l'ordonnanceur de tâches sans modification notable de cet ordonnanceur de tâches. De préférence, les ressources comprennent à la fois les ressources processeur et les ressources mémoire vive du noeud. Ce sont les ressources 5 les plus importantes requises pour pouvoir exécuter en urgence une tâche prioritaire. De préférence, les ressources comprennent également les ressources entrées/sorties et les ressources réseau du noeud. De préférence, toutes les ressources, processeur et mémoire vive, d'une même puce électronique du noeud ou d'un même réceptacle de 10 processeur ou de mémoire vive, sont affectées au même container, soit toutes au container standard soit toutes au container prioritaire. Ainsi, on évite de partager des ressources processeur ou des ressources mémoire d'une même puce électronique entre différents containers, ce qui serait plus difficile à gérer au niveau du noyau du noeud hôte. Par exemple, dans le cas 15 de deux processeurs, l'un est affecté au container prioritaire tandis que l'autre reste affecté au container standard. Par exemple, dans le cas de quatre processeurs, trois sont affectés au container prioritaire tandis que l'un des quatre reste affecté au container standard. De préférence, la proportion des ressources à basculer du container 20 standard vers le container prioritaire est paramétrable par l'administrateur du cluster. Ainsi, l'administrateur du cluster, en fonction de la fréquence et du type de tâches prioritaires susceptibles de survenir, peut optimiser la proportion de ressources à basculer pour d'une part exécuter dans le temps requis la tâche prioritaire tout en ralentissant le moins possible l'exécution 25 de la tâche standard. De préférence, lorsqu'une tâche prioritaire survient, au moins 50%, de préférence au moins 75% des ressources processeur du container standard sont basculées vers le container prioritaire. De préférence, lorsqu'une tâche prioritaire survient, au moins 50%, de préférence au moins 75% des 30 ressources mémoire vive du container standard sont basculées vers le container prioritaire. La tâche prioritaire devant être effectuée généralement 3031203 8 très vite, une majorité des ressources est alors affectée au container prioritaire dans lequel cette tâche prioritaire va être exécutée. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de 5 l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement un exemple de noeud sur 10 lequel sont lancés deux containers selon un mode de réalisation de l'invention. La figure 2 représente schématiquement un exemple de fonctionnement de noeud sur lequel sont lancés deux containers, selon un mode de réalisation de l'invention, tant qu'une tâche prioritaire ne survient 15 pas. La figure 3 représente schématiquement un exemple de fonctionnement de noeud sur lequel ont été lancés deux containers, selon un mode de réalisation de l'invention, lorsqu'une tâche prioritaire survient. La figure 4 représente schématiquement un exemple de déroulement 20 des étapes de la méthode d'ordonnancement de tâches selon un mode de réalisation de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION 25 La figure 1 représente schématiquement un exemple de noeud sur lequel sont lancés deux containers selon un mode de réalisation de l'invention. Un noeud 1 comporte un matériel 2 (« hardware » en langue anglaise), au-dessus duquel est disposé un noyau 3 (« kernel » en langue anglaise), au- 30 dessus duquel est disposé un système d'exploitation 4 (« OS distribution » pour « Operating System Distribution » en langue anglaise). Le matériel 2 et 3031203 9 le noyau 3 communiquent entre eux de manière bidirectionnelle. Le noyau 3 et le système d'exploitation 4 communiquent entre eux de manière bidirectionnelle. Le système d'exploitation 4 est appelé système d'exploitation hôte car c'est le système d'exploitation du noeud 1 lui-même. 5 Le noyau 3 comprend un groupe de contrôle 11 (« cgroup » pour « control group » en langue anglaise). Un groupe de contrôle est un élément du noyau dont les fonctions essentielles sont de limiter, de comptabiliser, et d'isoler l'usage des ressources (incluant ressources processeur, ressources mémoire, ressources entrées/sorties, ressources réseau) par les différents groupes de 10 processus. Les ressources mémoire sont essentiellement des ressources mémoire vive. Sur le noeud 1, qui est un noeud réel, sont lancés deux containers 5 et 8. Un container (« container » en langue anglaise) est une forme de virtualisation de l'environnement d'exécution (incluant notamment 15 processeur, mémoire vive, réseau, système de fichiers) où s'exécute un ensemble de processus isolés de la machine hôte ; un container est de préférence un container Linux (« LXC » ou « Linux Container » en langue anglaise). Le groupe de contrôle 11 du noyau 3 gère donc la répartition des ressources entre les deux containers 5 et 8. Un container Linux combine 20 groupes de contrôle et espaces de nommage pour pouvoir constituer un environnement isolé permettant l'exécution de tâches indépendamment à la fois du noeud lui-même et de l'autre ou des autres containers de ce noeud. Le container 5, qui est un container standard, comprend une application 6 située au-dessus d'un système d'exploitation 7. L'application 25 6 et le système d'exploitation 7 communiquent entre eux de manière bidirectionnelle. Le système d'exploitation 7 est le système d'exploitation du container 5 qui est indépendant du système d'exploitation 4 du noeud 1 et qui communique de manière bidirectionnelle directement avec le noyau 3 du noeud 1. 30 Le container 8, qui est un container prioritaire, comprend une application 9 située au-dessus d'un système d'exploitation 10. L'application 3031203 10 9 et le système d'exploitation 10 communiquent entre eux de manière bidirectionnelle. Le système d'exploitation 10 est le système d'exploitation du container 8 qui est indépendant du système d'exploitation 4 du noeud 1 et qui communique de manière bidirectionnelle directement avec le noyau 3 du 5 noeud 1. Les systèmes d'exploitation 7 et 10 sont représentés identiques entre eux et différents du système d'exploitation 4, sur la figure 1. Mais ces systèmes d'exploitations 4, 7 et 10 pourraient aussi être tous identiques entre eux, ou bien tous différents entre eux. Des exemples de système 10 d'exploitation pour les containers 5 et 8 sont SUSE ou REDHAT ou UBUNTU. La figure 2 représente schématiquement un exemple de fonctionnement de noeud sur lequel sont lancés deux containers, selon un mode de réalisation de l'invention, tant qu'une tâche prioritaire ne survient 15 pas. La répartition des ressources décrite correspond à la répartition par exemple des ressources processeur. Mais la répartition des autres ressources, notamment mémoire vive, entrées/sorties, réseau, est effectuée de manière similaire. Les différentes ressources peuvent être réparties de manière différente, par exemple 75%/25% entre les deux containers pour les 20 ressources processeur, avec la plus grande partie affectée au container prioritaire, et 50%/50% entre les deux containers pour les ressources mémoire vive. La figure 2 correspond à l'exécution normale d'une tâche standard au niveau du container standard 5. Ainsi, tant qu'une tâche prioritaire ne 25 survient pas, les ressources processeur disponibles du noeud 1 sont affectées à son container standard 5 pour exécuter une tâche standard, son container prioritaire 8 n'exécutant pas de tâche. Une faible partie des ressources processeur reste tout de même affectée au container prioritaire 8 pour pouvoir l'ouvrir et le maintenir en veille, cette faible partie restant le plus 30 souvent inférieure à 5% des ressources processeur du noeud 1, et valant avantageusement entre 2% et 3% des ressources processeur du noeud 1. 3031203 11 L'absence de la case application 9 montre que le container prioritaire 8 n'exécute pas de tâche. Une forte partie des ressources processeur est alors affectée au container standard 5, lequel exécute une tâche standard, cette forte partie restant le plus souvent supérieure à 95% des ressources 5 processeur du noeud 1, et valant avantageusement entre 97% et 98% des ressources processeur du noeud 1. Cette répartition des ressources processeur en faveur du container standard 5 qui exécute une tâche standard au détriment du container prioritaire 8 qui n'exécute pas de tâche a été effectuée par le groupe de contrôle 11 du noyau 3. 10 La figure 3 représente schématiquement un exemple de fonctionnement de noeud sur lequel ont été lancés deux containers, selon un mode de réalisation de l'invention, lorsqu'une tâche prioritaire survient. Une tâche prioritaire est fournie par l'ordonnanceur de tâches (« batch scheduler » en langue anglaise), non représenté sur la figure, qui gère la 15 queue des tâches en attente d'être exécutées au niveau des noeuds en général et au niveau du noeud 1 en particulier. Lorsqu'une tâche prioritaire survient, le groupe de contrôle 11 du noyau 3 réalise un basculement dynamique d'une partie seulement des ressources processeur de son container standard 5 vers son container 20 prioritaire 8, de manière à ce que, d'une part la tâche prioritaire soit exécutée dans le container prioritaire 8 avec la partie basculée des ressources processeur, et d'autre part la tâche standard continue d'être exécutée, sans être arrêtée, dans le container standard 5 avec la partie non basculée des ressources processeur. 25 Entre les figures 2 et 3, on voit que 70% des ressources processeur du noeud 1 ont été basculées du container standard 5 vers le container prioritaire 8. Ainsi, dans ce mode prioritaire représenté à la figure 3, le container prioritaire 8 peut réaliser rapidement et efficacement sa tâche prioritaires avec 75% des ressources processeur du noeud 1, tandis que le 30 container standard 5 continue à exécuter au ralenti sa tâche standard avec 3031203 12 seulement 25% des ressources processeur du noeud 1 au lieu des 95% dont il disposait dans le mode normal représenté à la figure 2. Une fois la tâche prioritaire terminée dans le container prioritaire 8, les ressources basculées du container standard 5 vers le container prioritaire 5 8 sont rebasculées du container prioritaire 8 vers le container standard 5, pour aboutir à nouveau à la configuration du mode normal représenté sur la figure 2, permettant au container standard de continuer à exécuter sa tâche standard avec 95% des ressources processeur, jusqu'à ce qu'elle soit terminée ou jusqu'à ce qu'une nouvelle tâche prioritaire arrive au niveau du 10 noeud 1. L'arrivée simultanée ou concomitante de deux tâches prioritaires au niveau d'un noeud sur lequel une tâche standard est déjà en cours d'exécution est très rare. Pour gérer ce cas, il est possible d'ouvrir non pas deux mais trois containers ou plus. Cependant, l'ouverture de nombreux 15 containers oisifs la plupart du temps utilise des ressources inutilement et fait chuter les performances globales du noeud. Par conséquent, préférentiellement seulement deux containers sont lancés sur un même noeud, et pas plus. La deuxième tâche prioritaire devrait alors être mise en attente jusqu'à la fin de la première tâche prioritaire. Une tâche prioritaire 20 prend généralement moins de temps, voire beaucoup moins de temps qu'une tâche standard, à égale utilisation des ressources du noeud. La figure 4 représente schématiquement un exemple de déroulement des étapes de la méthode d'ordonnancement de tâches selon un mode de réalisation de l'invention. 25 La méthode d'ordonnancement de tâches déroule successivement une étape 20 de paramétrage de la proportion de noeuds concernés, une étape 21 de paramétrage de la proportion de ressources, une étape 22 de lancement des deux containers, une étape 23 d'exécution normale d'une tâche standard, la survenue 24 d'une tâche prioritaire pendant l'exécution de la 30 tâche standard, une étape 25 de basculement des ressources, une étape 26 d'exécution en parallèle de la tâche prioritaire et de la tâche standard 3031203 13 ralentie, la terminaison 27 de l'exécution de la tâche prioritaire, une étape 28 de rebasculement des ressources, une étape 29 d'exécution normale de la tâche standard. Dans l'étape 20 de paramétrage de la proportion de noeuds concernés 5 par le lancement simultané de deux containers, l'administrateur du cluster décide du nombre et du type de noeuds sur lesquels deux containers vont être simultanément lancés, un container standard pour exécuter les tâches standard et un container prioritaire pour exécuter les tâches prioritaires. L'ordonnanceur de tâches du cluster verra, au niveau du noeud, en fait deux 10 noeuds virtuels constitués par les deux containers, standard et prioritaire, du noeud. Les autres noeuds fonctionneront classiquement et seront vus par l'ordonnanceur de tâches chacun comme un noeud réel. Dans l'étape 21 de paramétrage de la proportion de ressources, sur chaque noeud, pour chaque type de ressource, notamment ressource 15 processeur et ressource mémoire vive et ressources entrées/sorties et ressources réseau, va être paramétrée la répartition des ressources entre le container standard et le container prioritaire, en cas de survenue de tâche prioritaire, l'essentiel des ressources restant affecté au container standard tant qu'une telle tâche prioritaire ne survient pas. Par exemple, lorsqu'une 20 tâche prioritaire survient, le groupe de contrôle redimensionne les containers de manière à ce que le container prioritaire commence à disposer d'environ 75% des ressources processeur, 50% des ressources mémoire vive, 25% des ressources entrées/sorties, 50% des ressources réseau, tandis que le container standard va conserver environ 25% des ressources processeur, 25 50% des ressources mémoire vive, 75% des ressources entrées/sorties, 50% des ressources réseau. Préférentiellement, la répartition des ressources entre container standard et container prioritaire est identique ou similaire pour l'ensemble des noeuds concernés, mais elle peut être différente par groupe de noeuds ou même varier d'un noeud à l'autre. En option, il est possible que 30 l'un des types de ressources, par exemple les ressources réseau, ne soit pas du tout prévu pour être basculé du container standard vers le container 3031203 14 prioritaire, lorsqu'une tâche prioritaire survient, si le type de tâches prioritaires susceptibles de survenir ne requiert jamais ce type de ressources. Dans l'étape 22 de lancement des deux containers, les deux containers, un container standard et un container prioritaire sont lancés sur 5 chacun des noeuds concernés du cluster. Dans l'étape 23 d'exécution normale d'une tâche standard, le container standard, disposant d'au moins 95% des ressources disponibles, moins de 5% étant affecté au container prioritaire n'exécutant pas de tâche, déroule normalement l'exécution d'une tâche standard, donc à vitesse 10 normale. Lors de la survenue 24 d'une tâche prioritaire pendant l'exécution de la tâche standard, le groupe de contrôle se prépare à effectuer le basculement des ressources prévu à l'étape 21 de paramétrage de la proportion de ressources. 15 Dans l'étape 25 de basculement des ressources, l'affectation des ressources entre les deux containers est rééquilibrée au profit du conteneur prioritaire qui prend une partie notable ou même préférentiellement la majorité des ressources auparavant affectées au container standard, tout en laissant au container standard suffisamment de ressources pour pouvoir 20 continuer à effectuer sa tâche standard, même sur un mode ralenti, afin que tout le travail déjà effectué pour la tâche standard par le container standard ne soit pas perdu mais soit au contraire conservé. Dans l'étape 26 d'exécution en parallèle de la tâche prioritaire et de la tâche standard ralentie, d'une part la tâche prioritaire est exécutée dans le 25 container prioritaire avec les ressources basculées, et d'autre part la tâche standard continue d'être exécutée dans le container standard avec des ressources réduites, à savoir les ressources non basculées, sur un mode ralenti. Lors de la terminaison 27 de l'exécution de la tâche prioritaire, le 30 groupe de contrôle se prépare à rebasculer, du container prioritaire vers le 3031203 15 container standard, les ressources qui avaient été préalablement basculées, du container standard vers le container prioritaire. Dans l'étape 28 de rebasculement des ressources, le container prioritaire ne conserve que moins de 5% des ressources disponibles pour 5 rester ouvert et rester prêt à exécuter une future tâche prioritaire, tandis que le container standard reprend plus de 95% des ressources disponibles pour continuer à exécuter la tâche standard qu'il n'avait jamais arrêtée, mais cette fois à nouveau à vitesse normale et non plus à vitesse ralentie comme au cours de l'étape 26 d'exécution en parallèle des tâches. 10 Dans l'étape 29 d'exécution normale de la tâche standard, la tâche standard est exécutée dans le container standard avec l'essentiel voire la quasi-totalité des ressources du noeud, comme au cours de l'étape 23, et ceci, jusqu'à l'arrivée d'une nouvelle tâche prioritaire qui fait reprendre le processus au niveau de la survenue 24 de tâche prioritaire précédemment 15 décrite. Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. REVENDICATIONS1. Méthode d'ordonnancement de tâches, au niveau d'au moins certains noeuds (1) d'un cluster informatique, comprenant : d'abord, le lancement (22) de deux containers (5, 8) sur chacun desdits noeuds (1), un container standard (5) et un container prioritaire (8), ensuite, pour tout ou partie desdits noeuds (1) à deux containers (5, 8), au niveau de chaque noeud (1), o tant qu'une tâche prioritaire ne survient pas, l'affectation de ou des ressources disponibles du noeud (1) à son container standard (5) pour exécuter une tâche standard, son container prioritaire (8) n'exécutant pas de tâche, o lorsqu'une tâche prioritaire survient, le basculement (25) dynamique d'une partie seulement des ressources de son container standard (5) vers son container prioritaire (8), de manière à ce que, d'une part la tâche prioritaire soit exécutée dans le container prioritaire (8) avec la partie basculée des ressources, et d'autre part la tâche standard continue d'être exécutée, sans être arrêtée, dans le container standard (5) avec la partie non basculée des ressources. 2. Méthode de séquencement de tâches selon la revendication 1, caractérisée en ce que, tant qu'une tâche prioritaire ne survient pas, toutes les ressources disponibles du noeud (1) sont affectées à son container standard (5). 3. Méthode de séquencement de tâches selon la revendication 1 ou 2, caractérisée en ce que, tant qu'une tâche prioritaire ne survient pas, au 3031203 17 moins 90%, de préférence au moins 95%, des ressources du noeud (1) sont affectées au container standard (5), et/ou moins de 5% des ressources du noeud (1) sont affectées au container prioritaire (8). 5 4. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que, une fois la tâche prioritaire terminée (27), les ressources ayant été basculées du container standard (5) vers le container prioritaire (8) sont rebasculées (28) du container prioritaire (8) vers le container standard (5). 10 5. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que, lorsqu'une tâche prioritaire survient (24), le basculement (25) des ressources est effectué par un ou plusieurs groupes de contrôle (11) de virtualisation au niveau 15 système d'exploitation disposés dans la couche noyau (3) du noeud (1). 6. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que chaque container (5, 8) possède son système d'exploitation (7, 10) lui permettant de 20 communiquer directement avec le noyau (3) du noeud (1) hôte de ces containers standard (5) et prioritaire (8), indépendamment du système d'exploitation (4) dudit noeud (1) hôte. 7. Méthode de séquencement de tâches selon l'une quelconque des 25 revendications précédentes, caractérisée en ce que ladite méthode est effectuée au niveau de la majorité des noeuds (1) dudit cluster informatique, de préférence au niveau de tous les noeuds (1) dudit cluster informatique. 30 8. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce qu'au moins l'un des 3031203 18 noeuds (1) à deux containers (5, 8), de préférence plusieurs noeuds (1) à deux containers (5, 8), plus de préférence la majorité des noeuds (1) à deux containers (5, 8), encore plus de préférence tous les noeuds (1) à deux containers (5, 8), est ou sont des noeuds de calcul. 5 9. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que chaque container (5, 8) est un container Linux. 10 10. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que les ressources comprennent à la fois les ressources processeur et les ressources mémoire vive du noeud (1). 15 11. Méthode de séquencement de tâches selon la revendication 10, caractérisée en ce que toutes les ressources, processeur et mémoire vive, d'une même puce électronique du noeud ou d'un même réceptacle de processeur ou de mémoire vive sont affectées au même container, soit toutes au container standard (5) soit toutes au container prioritaire (8). 20 12. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que les ressources comprennent également les ressources entrées/sorties et les ressources réseau du noeud (1). 25 13. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que la proportion des ressources à basculer du container standard (5) vers le container prioritaire (8) est paramétrable par l'administrateur du cluster. 30 3031203 19 14. Méthode de séquencement de tâches selon l'une quelconque des revendications précédentes, caractérisée en ce que, lorsqu'une tâche prioritaire survient (24), au moins 50%, de préférence au moins 75% des ressources processeur du container standard (5) sont basculées vers le 5 container prioritaire (8), et/ou, lorsqu'une tâche prioritaire survient (24), au moins 50%, de préférence au moins 75% des ressources mémoire vive du container standard (5) sont basculées vers le container prioritaire (8). 10 15. Cluster informatique comprenant : - plusieurs noeuds (1), un ordonnanceur de tâches à affecter auxdits noeuds (1), configuré, pour au moins certains desdits noeuds (1), de manière à : o d'abord, lancer (22) deux containers (5, 8) sur chacun 15 desdits noeuds (1), un container standard (5) et un container prioritaire (8), o ensuite, pour tout ou partie desdits noeuds (1) à deux containers (5, 8), au niveau de chaque noeud (1), ^tant qu'une tâche prioritaire ne survient pas, affecter 20 des ressources du noeud (1) à son container standard (5) pour exécuter une tâche standard, son container prioritaire (8) n'exécutant pas de tâche, ^lorsqu'une tâche prioritaire survient, basculer (25) dynamiquement une partie seulement des 25 ressources de son container standard (5) vers son container prioritaire (8), de manière à ce que, d'une part la tâche prioritaire soit exécutée dans le container prioritaire (8) avec la partie basculée des ressources, et d'autre part la tâche standard 30 continue d'être exécutée, sans être arrêtée, dans le 3031203 20 container standard (5) avec la partie non basculée des ressources. 16. Ordonnanceur de tâches à affecter aux noeuds (1) d'un cluster 5 informatique, configuré, pour au moins certains desdits noeuds (1), de manière à : d'abord, lancer (22) deux containers (5, 8) sur chacun desdits noeuds (1), un container standard (5) et un container prioritaire (8), ensuite, pour tout ou partie desdits noeuds (1) à deux containers (5, 10 8), au niveau de chaque noeud (1), o tant qu'une tâche prioritaire ne survient pas, affecter des ressources du noeud (1) à son container standard (5) pour exécuter une tâche standard, son container prioritaire (8) n'exécutant pas de tâche, 15 o lorsqu'une tâche prioritaire survient, basculer (25) dynamiquement une partie seulement des ressources de son container standard (5) vers son container prioritaire (8), de manière à ce que, d'une part la tâche prioritaire soit exécutée dans le container prioritaire (8) avec la partie 20 basculée des ressources, et d'autre part la tâche standard continue d'être exécutée, sans être arrêtée, dans le container standard (5) avec la partie non basculée des ressources.