Brevet FR3076004A1 — publié le 20190628

PROCEDE DE GESTION DE PANNE DANS UN RESEAU DE NOEUDS ET PARTIE DE RESEAU DE NOEUDS ASSOCIEE DOMAINE DE L'INVENTION L'invention concerne le domaine des procédés de gestion de panne dans un réseau de noeuds et le domaine des parties de réseau de noeuds associées à cette gestion de panne. CONTEXTE DE L'INVENTION Dans un réseau de noeuds effectuant un même calcul, des sauvegardes sont effectuées à un ou à plusieurs niveaux, ce sont des sauvegardes multiniveaux. Lorsqu'une panne survient, le calcul peut être récupéré au moins en partie sans devoir être intégralement recommencé, justement grâce aux sauvegardes effectuées. Selon le type de panne survenu, l'un ou l'autre des niveaux de sauvegarde est utilisé pour récupérer le calcul en partie ou en même en majorité ou encore presque totalement. Les applications distribuées peuvent durer beaucoup plus longtemps que la durée moyenne sans panne d'un réseau, encore appelée MTBF d'un cluster (pour « Mean Time Between Failures » en langue anglaise), elles ont donc beaucoup de chances d'être interrompues. Elles n'ont en général pas de solution interne de gestion des pannes, ce peut alors entraîner d'abord la perte des données de sauvegarde locales en cas de panne physique du noeud de calcul, ensuite suivie de la perte de l'ensemble de l'avancement du calcul entraînée par la perte d'un seul noeud de calcul mais dont les données locales de sauvegarde ne peuvent plus être récupérées. Il existe des solutions de sauvegarde et de redémarrage (« checkpoint/restart » en langue anglaise) à partir de sauvegarde permettant 2 aux applications de sauvegarder leur contexte régulièrement sur différents niveaux de sauvegarde, plus ou moins rapides. Les différents niveaux de sauvegarde vont de la sauvegarde la plus locale à la sauvegarde la plus globale, allant ainsi de la sauvegarde la plus 5 simple et la plus rapide à la sauvegarde la plus complexe, la plus lente et la plus coûteuse, allant également ainsi de la sauvegarde la plus fragile et la plus faible à la sauvegarde la plus robuste et la plus résiliente. Selon un art antérieur correspondant à la librairie FTI (« interface de tolérance aux pannes » ou bien « fault tolerance interface » en langue 10 anglaise), il est connu quatre niveaux de sauvegarde qui sont : > Le premier niveau Li qui réalise une sauvegarde locale, simple et peu coûteuse, effectuée très souvent, d'où une perte minime en temps de calcul lors d'une panne pouvant être récupérée à ce seul premier niveau Li, 15 > Le deuxième niveau L2 qui réalise une première sauvegarde intermédiaire par duplication sur un noeud partenaire, moins simple et plus coûteuse, d'où une perte plus importante en temps de calcul lors d'une panne ne pouvant être récupérée qu'à ce deuxième niveau L2, 20 > Le troisième niveau L3, qui réalise une deuxième sauvegarde intermédiaire par encodage de type Reed-Solomon, encore moins simple et encore plus coûteuse, d'où une perte encore un peu plus importante en temps de calcul lors d'une panne ne pouvant être récupérée qu'à ce troisième niveau L3, 25 > Le quatrième niveau L4, qui réalise une sauvegarde globale à un niveau système de fichier, complexe et très coûteuse, d'où une perte vraiment importante en temps de calcul lors d'une panne ne pouvant être récupérée qu'à ce quatrième niveau L4. Du niveau local Li au niveau global L4, la sauvegarde est de plus en 30 plus robuste et résiliente, mais elle devient également de plus en plus complexe et coûteuse. C'est pour cela, que la sauvegarde du premier niveau 3 Li est réalisée souvent, la sauvegarde du deuxième niveau L2 moins souvent, la sauvegarde du troisième niveau L3 encore moins souvent, la sauvegarde du quatrième niveau L4 relativement rarement. Par conséquent, statistiquement, lorsqu'une panne survient, le dernier état cohérent qui peut 5 être récupéré est, très récent au premier niveau Li, moins récent au deuxième niveau L2, encore moins récent au troisième niveau L3, plus ancien au quatrième niveau L4. Par conséquent le volume de travail perdu est, très faible au premier niveau Li, relativement limité au deuxième niveau L2, notable au troisième niveau L3, plus important ancien au 10 quatrième niveau L4. RESUME DE L'INVENTION Le but de la présente invention est de fournir un procédé de gestion de 15 panne dans un réseau de noeuds palliant au moins partiellement les inconvénients précités. Plus particulièrement, l'invention vise à fournir un procédé de gestion de panne dans un réseau de noeuds améliorant le compromis entre efficacité d'une part et coût et complexité d'autre part, pour au moins un niveau de 20 sauvegarde considéré. Plus particulièrement, l'invention vise à fournir un procédé de gestion de panne dans un réseau de noeuds qui ait une efficacité similaire ou comparable à celle d'une sauvegarde de niveau intermédiaire, préférentiellement celle de la première sauvegarde intermédiaire, 25 avantageusement celle du deuxième niveau L2, pour un coût et une complexité similaires ou comparables à ceux d'une sauvegarde de niveau local, avantageusement ceux du premier niveau Li. Pour cela, l'invention propose de rendre le lien entre un support de stockage et son noeud redirigeable vers un autre noeud, de manière à pouvoir 30 disposer de la sauvegarde réalisée sur le support de stockage lorsque le noeud est défaillant, éventuellement par le biais d'une copie au niveau d'un 4 noeud voisin, mais sans avoir réalisé de copie de sauvegarde au niveau d'un noeud voisin pour la plupart des noeuds qui ne sont pas défaillants ou pour tous les noeuds qui ne sont pas défaillants. Le lien entre un support de stockage et son noeud n'est pas réalisé directement, mais indirectement au 5 travers d'un élément de réseau apte à reconfigurer ce lien pour rattacher ce support de stockage à un autre noeud lorsque le précédent noeud devient défaillant. Cet élément de réseau relie plusieurs noeuds à leurs supports de stockage respectifs, chaque noeud étant relié à son support de stockage associé (ou éventuellement à ses supports de stockage associés). 10 En résumé, pour un noeud défaillant, on dispose d'une sauvegarde malgré la défaillance de ce noeud, d'où une efficacité similaire au deuxième niveau L2, mais on ne réalise pas d'opération plus complexe qu'une simple sauvegarde locale pour la plupart ou pour tous les noeuds qui ne sont pas défaillants, ce qui est la majorité ou même la grande majorité des noeuds du 15 réseau effectuant le calcul considéré, d'où un coût et une complexité du moins comparable sinon similaire à celles du premier niveau Li. Ainsi, selon des modes de réalisation de l'invention, le coût du deuxième niveau L2 est économisé, alors qu'est conservée la capacité à redémarrer une application à partir des sauvegardes du premier niveau Li en 20 cas de panne d'un noeud de calcul. La copie vers un noeud voisin traditionnellement effectuée au deuxième niveau L2 n'est ici pas réalisée pendant l'exécution de l'application de manière préventive pour tous les noeuds de calcul, mais seulement en cas de panne et seulement pour les noeuds défaillants après survenue de la panne. La copie est alors faite 25 uniquement pour relancer l'application avec les données manquantes, remontées de la sauvegarde locale. D'une part, cette sauvegarde de coût et de complexité similaires ou comparables à une sauvegarde locale présente l'efficacité d'une sauvegarde intermédiaire, ce qui améliore beaucoup le rapport qualité prix de cette 30 sauvegarde. 5 D'autre part, cette sauvegarde de coût et de complexité similaires ou comparables à une sauvegarde locale présentant l'efficacité d'une sauvegarde intermédiaire, permet préférentiellement de remplacer à la fois une sauvegarde locale classique et une ou plusieurs sauvegardes 5 intermédiaires classiques, en ne gardant en plus que la sauvegarde globale en dernier recours, pour gérer les pannes les plus sévères, la plupart des pannes pouvant être maintenant gérées par la sauvegarde locale-intermédiaire proposée par l'invention, celle-ci ayant l'efficacité d'une sauvegarde intermédiaire pratiquement au prix d'une sauvegarde locale. 10 A cette fin, la présente invention propose un procédé de gestion de panne dans un réseau de noeuds, comprenant, pour chaque noeud considéré de tout ou partie des noeuds du réseau effectuant un même calcul : d'abord, une étape de sauvegarde locale de l'état de ce noeud considéré, au niveau d'un support de stockage de ce noeud considéré, le lien entre ce support de 15 stockage et ce noeud considéré pouvant être redirigé de ce support de stockage vers un autre noeud, ensuite, une étape de relance : soit du noeud considéré si celui-ci n'est pas défaillant, à partir de la sauvegarde locale de l'état de ce noeud considéré, soit d'un noeud opérationnel différent du noeud considéré, si le noeud considéré est défaillant, à partir de la récupération de 20 la sauvegarde locale de l'état de ce noeud considéré, en redirigeant ledit lien entre le noeud considéré et son support de stockage de manière à relier ledit support de stockage vers ledit noeud opérationnel, les sauvegardes locales de ces noeuds considérés, utilisées pour les étapes de relance, sont cohérentes entre elles de sorte à correspondre à un même état de ce calcul. 25 A cette fin, la présente invention propose également une partie d'un réseau de noeuds, comprenant : un commutateur, une pluralité de noeuds d'un groupe de noeuds effectuant un même calcul dans ce réseau de noeuds, plusieurs supports de stockage respectivement rattachés à ces noeuds par l'intermédiaire du commutateur, ces supports de stockage étant structurés et 30 disposés pour sauvegarder localement l'état des noeuds auxquels ils sont respectivement rattachés, ce commutateur étant structuré et disposé pour 6 changer au moins un rattachement entre un noeud défaillant et son support de stockage lequel va alors devenir rattaché à un autre noeud de ladite pluralité de noeuds. Selon des modes de réalisation de l'invention, ce procédé de gestion 5 de panne permet l'optimisation et la résilience de la sauvegarde de données d'une application susceptible de rencontrer une panne et le redémarrage de cette application à l'aide des données sauvegardées. Selon des modes de réalisation de l'invention, ce procédé de gestion de panne offre la possibilité de migrer un support de stockage du noeud de 10 calcul en panne grâce au commutateur, permettant alors d'exploiter directement les données locales sauvegardées d'un noeud de calcul en panne en un temps qui ne dépend que peu de la quantité de données sauvegardées. Selon des modes de réalisation de l'invention, ce procédé de gestion de panne offre une tolérance aux pannes qui s'étend dans l'absolu à un 15 grand nombre de noeuds de calcul tant qu'il existe, sur chaque noeud de calcul qui tombe en panne, un noeud de calcul rattaché au même commutateur qui pourra reprendre le calcul du noeud de calcul tombé en panne. Il est alors possible de repartir de la dernière sauvegarde locale, même si un grand nombre des noeuds de calcul tombe en panne, tant que 20 chaque noeud de calcul tombé en panne dispose d'un commutateur et d'un noeud de calcul voisin non défaillant connecté au même commutateur. 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 25 entre elles, appliquées à l'un ou à l'autre des objets de l'invention précités. De préférence, pour chaque noeud considéré non défaillant : il n'y a pas d'étape de récupération par un autre noeud, de la sauvegarde locale de l'état de ce noeud considéré non défaillant. Ainsi, pour tous les noeuds non défaillants, c'est-à-dire pour la grande 30 majorité des noeuds du réseau effectuant un même calcul, aucune opération plus complexe qu'une simple sauvegarde locale n'a été réalisée. 7 De préférence, le noeud opérationnel différent du noeud considéré défaillant est un noeud de rechange. Ainsi, les noeuds non défaillants, qui ont déjà chacun leur propre tâche de calcul à effectuer, ne sont pas chargés en plus d'effectuer cette opération 5 de récupération d'un noeud voisin défaillant. Une éventuelle surcharge de ces noeuds non défaillants est alors évitée. De préférence, ladite redirection dudit lien entre le noeud considéré et son support de stockage de manière à relier ledit support de stockage vers ledit noeud opérationnel, est réalisée par un changement d'aiguillage dans un 10 commutateur reliant plusieurs noeuds à leurs supports de stockage. Ainsi, cette redirection est effectuée par une opération simple réalisée au niveau d'un élément de réseau qui est fiable et maîtrisé. De préférence, toutes les étapes de relance de noeuds sont synchronisées entre elles, de manière à relancer tous lesdits noeuds dans un 15 même état de calcul. Ainsi, une complète cohérence du reste du calcul, effectué après la relance, est assurée. De préférence, dans une première réalisation, l'étape de récupération comprenant une sous-étape de migration, vers le noeud opérationnel ou vers 20 le noeud de rechange, du support de stockage de la sauvegarde locale de l'état du noeud défaillant, qui rattache, ce support de stockage de la sauvegarde locale de l'état du noeud défaillant, à un endroit prédéterminé de l'arborescence de fichiers de ce noeud opérationnel ou de ce noeud de rechange, ce noeud opérationnel ou ce noeud de rechange venant ensuite lire, 25 à cet endroit prédéterminé, le lien vers la sauvegarde locale de l'état du noeud défaillant, lors de l'étape de relance de ce noeud opérationnel ou de ce noeud de rechange, aucune copie, de la sauvegarde locale de l'état du noeud défaillant, n'étant réalisée, au niveau d'un autre noeud. Ainsi, la récupération est rendue encore plus simple, puisque même 30 pour un noeud défaillant, il n'y a aucune duplication de sa sauvegarde locale 8 qui est réalisée. Il n'y avait déjà pas de duplication réalisée pour la sauvegarde locale des noeuds non défaillants. De préférence, le noeud de rechange et le noeud défaillant qu'il remplace appartiennent tous les deux à la même lame de calcul. 5 Ainsi, la redirection du lien entre support et noeud est effectuée plus simplement et plus rapidement, en raison de la proximité géographique entre eux du noeud de rechange et du noeud défaillant. De préférence, dans une deuxième réalisation, l'étape de récupération comprend : d'abord, une sous-étape de migration, vers un noeud 10 intermédiaire, du support de stockage de la sauvegarde locale de l'état du noeud défaillant, qui rattache, ce support de stockage de la sauvegarde locale de l'état du noeud défaillant, à un endroit prédéterminé de l'arborescence de fichiers de ce noeud intermédiaire, ensuite, une sous-étape de copie, de la sauvegarde locale de l'état du noeud défaillant, du support de stockage 15 rattaché au noeud intermédiaire vers le support de stockage du noeud opérationnel ou du noeud de rechange, ce noeud opérationnel ou ce noeud de rechange venant ensuite lire son support de stockage, lors de son étape de relance. Ainsi, même si la récupération, pour un noeud défaillant, réalise une 20 duplication de sa sauvegarde locale, en revanche il n'y a pas besoin d'indiquer au noeud opérationnel ou au noeud de rechange à quel endroit aller chercher le lien vers le support de stockage du noeud défaillant à récupérer. Par contre, bien sûr, il n'y a toujours pas de duplication réalisée pour la sauvegarde locale des noeuds non défaillants. 25 La sous-étape de copie n'est pas nécessaire et peut être évitée en remontant le support de stockage au bon endroit dans l'arborescence de fichier du noeud de rechange comme dans la première réalisation décrite précédemment, ou bien en changeant simplement la configuration de la bibliothèque de tolérance aux pannes. Cette remontée est instantanée et 30 permet alors d'éviter une copie supplémentaire qui pourrait prendre un peu de temps en fonction du volume de données à sauvegarder. 9 De préférence, pour tout ou partie des noeuds du réseau effectuant un même calcul : le noeud de rechange et le noeud défaillant qu'il remplace appartiennent à des lames de calcul différentes. Ainsi, la redirection du lien entre support et noeud peut être effectuée 5 même en cas de panne importante et même relativement généralisée au niveau de toute une lame de calcul. De préférence, toutes ces étapes sont réalisées pour tous les noeuds du réseau effectuant un même calcul. Ainsi, le bénéfice du procédé de gestion de panne proposé par 10 l'invention, est généralisé en étant étendu à l'ensemble des noeuds du réseau effectuant un même calcul. De préférence, la sous-étape de migration change le rattachement du support de stockage de la sauvegarde locale de l'état du noeud défaillant en passant par l'intermédiaire d'un commutateur auquel était rattaché le noeud 15 défaillant et son support de stockage de la sauvegarde locale de l'état du noeud défaillant, mais sans passer par le noeud défaillant lui-même. Ainsi, la redirection peut être effectuée même en cas de panne physique complète du noeud défaillant. De préférence, le changement de rattachement est réalisé par l'envoi 20 d'une commande au commutateur, cette commande passant par l'un des noeuds rattachés au commutateur par un port de management. Ainsi, c'est le port de management ou de gestion qui est affecté à la récupération des supports de stockage des noeuds défaillants rattachés à un même commutateur. 25 De préférence, ce commutateur est un commutateur PCIe (« Peripheral Component Interconnect express » en langue anglaise). Ainsi, ce commutateur est particulièrement avantageux car il est particulièrement adapté à pouvoir faire communiquer entre eux des périphériques sans devoir passer par l'intermédiaire d'un microprocesseur, 30 donc en pouvant contourner un noeud de calcul défaillant par exemple. 10 L'utilisation de ce commutateur PCIe permet de rattacher le support de stockage, par exemple un disque de stockage, contenant les sauvegardes locales du noeud de calcul en panne à un noeud de calcul de rechange. Cette opération est rapide et ne nécessite pas de copie systématique des données 5 de sauvegarde locales, et en particulier pas pour les noeuds de calcul non défaillants. De préférence, 3 à 10 noeuds sont rattachés à un même commutateur. Ainsi, le commutateur peut gérer facilement ce petit groupe de noeuds pour lequel un seul noeud de rechange semble devoir être suffisant. 10 De préférence, le procédé de gestion de panne comprend aussi, pour tout ou partie des noeuds du réseau effectuant un même calcul : une étape de sauvegarde globale de l'ensemble de ces noeuds, réalisée moins souvent que l'ensemble des étapes de sauvegarde locales de ces noeuds. Ainsi, avec d'une part la sauvegarde locale-intermédiaire proposée par 15 l'invention pour de gérer la grande majorité des pannes de manière simple et efficace, et d'autre part la sauvegarde globale plus complexe et plus coûteuse mais réservée à une minorité de pannes sévères, un excellent compromis entre complexité globale et efficacité globale du procédé de gestion de panne proposé par l'invention est réalisé. 20 Dans le cadre d'une application tolérante aux pannes, en utilisant plusieurs niveaux de sauvegarde, comme ici une sauvegarde locale rapide et une sauvegarde globale distante plus complexe et plus coûteuse, le procédé de gestion de panne proposé par l'invention permet alors de redémarrer l'application, suite à une panne physique sur un noeud, même complète, et 25 ceci dans la plupart des cas, en repartant de toutes les sauvegardes locales, plus récentes et moins coûteuses, au lieu de devoir repartir des sauvegardes distantes qui sont très souvent nettement plus anciennes, quelques cas plus rares de panne nécessitant parfois l'utilisation de la sauvegarde globale distante. La possibilité de récupérer les données locales du noeud de calcul 30 en panne permet de redémarrer dans la plupart des cas l'application à partir des sauvegardes locales les plus récentes. 11 De préférence, pour tout ou partie des noeuds du réseau effectuant un même calcul : le réseau comprend entre 1 et 5 noeuds de rechange pour 100 noeuds effectuant ledit même calcul. Ainsi, le surdimensionnement de la taille du réseau est minime, tandis 5 que la grande majorité des pannes ordinaires sera gérée de manière très efficace. De préférence, pour tout ou partie des noeuds du réseau effectuant un même calcul : ce procédé de gestion de panne ne comprend aucun autre type de sauvegarde locale de l'état de ces noeuds. 10 Ainsi, la simplicité et le faible coût de ce type de sauvegarde locale- intermédiaire proposée par l'invention est d'une simplicité similaire à celle d'une sauvegarde purement locale, pour une efficacité bien supérieure. De préférence, pour tout ou partie des noeuds du réseau effectuant un même calcul : les supports de stockage sont des mémoires flash. 15 Ainsi, les mémoires utilisées sont simples, rapides et permanentes. De préférence, ces mémoires flash sont des mémoires NVMe (« Non Volatile Memory express » en langue anglaise). Ainsi, les mémoires utilisées sont particulièrement bien adaptées pour communiquer avec un commutateur PCIe (« Peripheral Component 20 Interconnect express » en langue anglaise). De préférence, ce commutateur étant structuré et disposé pour changer au moins un rattachement entre un noeud défaillant et son support de stockage, sur commande extérieure au commutateur. Ainsi, c'est le commutateur qui effectue la redirection du lien entre le 25 support de stockage et son noeud défaillant, dès qu'un élément externe au commutateur a mis en évidence cette défaillance de noeud et l'a prévenu. De préférence, ladite pluralité de noeuds comprend entre 3 et 10 noeuds. Ainsi, le commutateur peut gérer facilement ce petit groupe de noeuds 30 pour lequel un seul noeud de rechange semble devoir être suffisant. De préférence, ce commutateur est un commutateur PCIe. 12 Ainsi, ce commutateur est particulièrement avantageux car il est particulièrement adapté à pouvoir faire communiquer entre eux des périphériques sans devoir passer par l'intermédiaire d'un microprocesseur. De préférence, les supports de stockage sont des mémoires flash, de 5 préférence des mémoires NVMe. Ainsi, les mémoires utilisées sont particulièrement bien adaptées pour communiquer avec un commutateur PCIe. Préférentiellement, le réseau de noeuds de calcul comprend au moins 1000 noeuds de calcul, avantageusement au moins 5000 noeuds de calcul, 10 encore plus avantageusement au moins 10000 noeuds de calcul, rendant d'autant plus intéressant le procédé de gestion de panne selon l'invention car la perte complète d'un calcul en cours devient alors d'autant plus critique que le réseau est grand. Le principe de tolérance aux pannes est d'autant plus important 15 qu'une application s'exécute sur un cluster qui est constitué d'un plus grand nombre de noeuds de calcul. Plus le nombre de processeurs, mémoires et autres périphériques, est important, plus la probabilité qu'une panne survienne avant la fin de l'exécution est grande. Les applications qui ont pour but de s'exécuter sur ce type de plateforme vont utiliser des librairies 20 de tolérance aux pannes qui leur permettent de sauvegarder (« checkpoint » en langue anglaise) les données nécessaires à un redémarrage (« restart » en langue anglaise) dans un état le plus proche possible de l'état qui existait juste avant la panne. Ainsi, ces applications ne sont pas contraintes de recommencer le calcul depuis le début. 25 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 l'invention, donnée à titre d'exemple et en référence aux dessins annexés. 13 BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement un exemple, d'une partie de 5 réseau incluant un groupe de noeuds et leurs supports de stockage reliés entre eux par un commutateur PCIe, selon un mode de réalisation de l'invention, au niveau de laquelle partie de réseau, un exemple de procédé de gestion de panne selon l'invention peut se dérouler. 10 DESCRIPTION DETAILLEE DE L'INVENTION La figure 1 représente schématiquement un exemple, d'une partie de réseau incluant un groupe de noeuds et leurs supports de stockage reliés entre eux par un commutateur PCIe, selon un mode de réalisation de 15 l'invention, au niveau de laquelle partie de réseau, un exemple de procédé de gestion de panne selon l'invention peut se dérouler. Cette partie de réseau comprend plusieurs noeuds de calcul 2, trois noeuds de calcul 21, 22 et 23, dans l'exemple de la figure 1, ainsi que plusieurs supports de stockage 3, trois supports de stockage 31, 32 et 33, 20 dans l'exemple de la figure 1. Ces noeuds de calcul 2 et leurs supports de stockage 3 forment un groupe de noeuds de calcul géré par un commutateur PCIe 1 reliant ces noeuds de calcul 2 à leurs supports de stockage 3 respectifs, par l'intermédiaire de connexions bidirectionnelles PCIe 7, 8 ou 9. Ces 25 connexions PCIe 7, 8 ou 9, peuvent être des connexions PCIe à plusieurs voies. La connexion 7 est une connexion à 4 voies. La connexion 8 est une connexion à 4 voies. La connexion 9 est une connexion à 2 voies, ici non encore utilisée, chaque connexion 9 étant d'un côté rattachée à l'un des ports 13, 16 ou 19 et restant libre de l'autre côté. Chaque connexion PCIe 7 30 relie respectivement l'un des noeuds de calcul 21 à 23 à l'un des ports 0, 2 ou 8 (numérotation du commutateur électronique PLX 8733, mais un autre 14 Switch PCIe peut être utilisé), respectivement référencés 11, 14 ou 17 sur la figure 1, du commutateur 1. Chaque connexion PCIe 8 relie respectivement l'un des supports de stockage 31 à 33 à l'un des ports 1, 3 ou 9, respectivement référencés 12, 15 ou 18 sur la figure 1, du commutateur 1. 5 La connexion 7, les ports 0 et 1, respectivement référencés 11 et 12 sur la figure 1, du commutateur 1, la connexion 8 forment ensemble un lien 4 reliant le noeud de calcul 23 à son support 33. La connexion 7, les ports 2 et 3, respectivement référencés 14 et 15 sur la figure 1, du commutateur 1, la connexion 8 forment ensemble un lien 5 reliant le noeud de calcul 22 à son 10 support 32. La connexion 7, les ports 8 et 9, respectivement référencés 17 et 18 sur la figure 1, du commutateur 1, la connexion 8 forment ensemble un lien 6 reliant le noeud de calcul 21 à son support 31. Les connexions PCIe 7, 8 ou 9, peuvent être regroupées sur un bus PCIe. Le noeud de calcul 23 est rattaché au port de gestion ou de 15 management par défaut, c'est-à-dire que c'est par lui que transite les envois vers l'extérieur du groupe de noeuds de calcul 2 et les réceptions en provenance de l'extérieur du groupe de noeuds de calcul 2. En cas de défaillance de ce noeud de calcul 23, celui-ci est remplacé par le noeud de calcul 22 qui est rattaché au port de gestion ou de management redondant, 20 lequel noeud de calcul 22 devient alors rattaché au nouveau port de gestion ou de management effectif. Lorsqu'un noeud de calcul tombe en panne physique, par exemple le noeud de calcul 21 ou le noeud de calcul 22, considérons ici le noeud de calcul 21, la dernière sauvegarde locale récente de son état de calcul est 25 stockée sur son support de stockage 31. Dans un système selon l'art antérieur, le support de stockage 31 n'étant accessible que par son noeud de calcul 21 et celui-ci étant en panne physique complète, cette sauvegarde locale récente deviendrait inaccessible, et il faudrait alors recourir à d'autres niveaux de sauvegarde plus complexes 30 et moins récents, d'où une perte importante d'efficacité globale pour le réseau informatique. 15 Dans le système selon un mode de réalisation de l'invention, présenté à la figure 1, le rattachement du support de stockage 31 est reconfiguré, c'est-à-dire que le support de stockage 31 va cesser d'être relié à son noeud de calcul 21 de rattachement par défaut, mais va devenir relié au noeud de 5 calcul 23, lequel étant rattaché au port de gestion par défaut, va pouvoir faire remonter la sauvegarde locale de l'état de calcul du noeud de calcul 21 défaillant, depuis le support de stockage 31, vers un autre noeud de calcul de rechange extérieur au groupe de noeuds de calcul 21 à 23, cet autre noeud de calcul reprenant alors à son compte la tâche de calcul interrompue au niveau 10 du noeud de calcul 21 défaillant, à partir de la sauvegarde locale de l'état de calcul du noeud de calcul 21 remontée depuis le support de stockage 31. Dans le commutateur 1, le port 9 (numérotation du commutateur électronique PLX8733, mais un autre Switch PCIe peut être utilisé) référencé 18 (sur la figure 1), au lieu de rester relié en permanence au port 8 15 référencé 17 comme avant la défaillance du noeud de calcul 21, va être, au moins temporairement relié au port 0 référencé 11, afin de permettre au noeud de calcul 23 de venir lire, dans le support de stockage 31, les données sauvegardées représentatives de l'état de calcul du noeud de calcul 21, juste avant ou peu de temps avant, sa défaillance. Ainsi, la sauvegarde locale, 20 dans le support de stockage 31, de l'état de calcul du noeud de calcul 21 avant sa défaillance, va pouvoir remonter jusqu'au noeud de calcul 23 et être ainsi exploitée pour relancer le calcul avec un très bon compromis entre simplicité de la sauvegarde et efficacité de la relance. Alternativement, si le noeud de calcul 23 est lui-même un noeud de 25 rechange, il peut reprendre à son compte la tâche de calcul interrompue par le noeud de calcul 21 défaillant. Si c'est le noeud 23 qui devient défaillant, il est d'abord remplacé par le noeud de calcul 22 comme rattaché au port de management, et le noeud de calcul 22, comme rattaché au nouveau port de management, réalise les 30 opérations auparavant réalisés par le noeud de calcul 23 si celui-ci n'était pas devenu défaillant. 16 La gestion du commutateur 1 est maintenant décrite par un scenario manuel clarifiant et expliquant les différentes opérations à effectuer, comme par exemple la migration du support de stockage 31 d'un noeud de calcul défaillant 21 à un noeud de calcul de rechange 23, le transfert des données, 5 le redémarrage de l'application. La gestion des données côté applicatif est abstraite par la librairie FTI. L'application exécutée est fournie dans les exemples de la librairie FTI : hdf.exe. Cette application est lancée sur deux noeuds de calcul. Elle va réaliser des sauvegardes locales, sur les disques de stockage NVMe reliés à 10 ces noeuds de calcul par le commutateur PCIe à intervalles réguliers ainsi qu'une sauvegarde globale sur un serveur NFS (« Network File System » en langue anglaise) de façon moins fréquente. Une fois l'application lancée, une panne est générée sur un des deux noeuds de calcul. La migration du disque de stockage NVMe du noeud défaillant vers un autre noeud va alors 15 permettre le transfert des données de la dernière sauvegarde locale de ce noeud défaillant vers le noeud de rechange. Une fois ce transfert réalisé, l'application peut être relancée et reprend le calcul à la dernière sauvegarde locale des deux noeuds de calcul au lieu de la dernière sauvegarde globale plus ancienne de la partie de réseau. 20 Dans ce contexte, une reprise sur panne est réalisée avec les données locales de sauvegarde d'une application MPI (« Message Passing Interface » en langue anglaise) d'un noeud de calcul tombant en panne. Les données sont récupérées grâce à la migration du support de stockage du noeud de calcul défaillant sur un noeud de calcul voisin de la même lame de calcul. 25 Ces données sont ensuite transmises à un second noeud de rechange qui reprendra le calcul. L'intérêt de cette reprise sur panne est qu'elle permet à l'application de redémarrer à partir des sauvegardes locales de tous les noeuds de calcul. Ces sauvegardes locales moins coûteuses sont également plus récentes la plupart du temps, et ne sont au pire qu'aussi récentes, que 30 les sauvegardes globales. De plus, la quantité de données transférées afin de 17 reprendre le calcul va être bien plus faible que dans le cas d'un redémarrage à partir d'une sauvegarde globale. Dans le développement qui suit, les parties de texte dans un encadré ou bien entre crochets concernent des lignes de code informatique. La configuration de la librairie FTI a été modifiée [« config.fti » dans le répertoire « examples »], afin d'autoriser l'exécution sur deux noeuds de calcul différents : [basic] head =0 node size = 1 ckpt dir = /localckpt/ glbl dir = /globalckpt/ meta dir = /home/user/.fti ckpt 11 = 1 ckpt 12 = 2 ckpt 13 = 3 ckpt 14 = 4 inline 12 = 1 inline 13 = 1 inline 14 = 1 keep last ckpt = 0 group size = 2 verbosity = 1 [restart] failure = 1 exec id = 2016-10-27_15-25-56 [injection] rank =0 number = 0 position = 0 frequency = O[advanced] block size = 1024 mpi tag = 2612 local test = 1 18 Sur chacun des deux noeuds de calcul, appelés ici Ni (référencé 21 sur la figure 1) et N2 (référencé 22 sur la figure 1), le répertoire de sauvegarde locale [« /localckpt/ »] est un montage du disque de stockage SSD (« Solid State Disk » en langue anglaise) disponible sur chaque noeud de calcul, le 5 disque de stockage SO (référencé 31 sur la figure 1) sur le noeud de calcul Ni et le disque de stockage Si (référencé 32 sur la figure 1) sur le noeud de calcul N2: 19 $ mpirun -host N1,N2 --mca pml obi --mca btl self,vader,tcp --mca coul Ahcoll,fca --mca oob tcp if include enpl2s0f0 --mca btl tcp if include enpl2s0f0 -n 2 hdf.exe [ FTI Information ] : Reading FTI configuration file (config.fti)... [ FTI Information ] : The execution ID is: 2016-ii-09_17-09-10 FTI Topo->nodeSize : 1 , FTI Topo->nbProc : 2 FTI Topo->nbNodes : 2 FTI Topo->nbNodes : 2 FTI Topo->groupSize : 2 , FTI Topo->nodeSize 1 FTI Topo->nodeSize : 1 , FTI Topo->nbProc : 2 FTI Topo->nbNodes : 2 FTI Topo->nbNodes : 2 FTI Topo->groupSize : 2 , FTI Topo->nodeSize 1 [ FTI Information ] : FTI has been initialized. Local data size is 2048 x 1027 = 32. MB ( 32). Target precision : 0.00500 [ FTI Information ] : Variable ID 0 to protect. Current ckpt. size per rank is 0.00MB. [ FTI Information ] : Variable ID 2 to protect. Current ckpt. size per rank is 16.05MB. [ FTI Information ] : Variable ID 1 to protect. Current ckpt. size per rank is 32.09MB. Step : 100, error = 0.25488 [ FTI Information ] : Post-checkpoint took 0.00 sec. (Ag:0.00s, Pt:0.00s, C1:0.00s) [ FTI Information ] : Ckpt. ID 1 (L1) (32.09 MB/proc) taken in 0.13 sec. (Wt:0.00s, Wr:0.12s, Ps:0.00s) Step : 200, error = 0.12412 [FTI Error - 000000] : Cannot rename local directory : No such file or directory [FTI Error - 000001] : Cannot rename local directory : No such file or directory [ FTI Information ] : Post-checkpoint took 0.12 sec. (Ag:0.00s, Pt:0.00s, C1:0.12s) [ FTI Information ] : Ckpt. ID 2 (L4) (32.09 MB/proc) taken in 0.48 sec. (Wt:0.00s, Wr:0.36s, Ps:0.12s) Step : 300, error = 0.08203 Step : 400, error = 0.06127 [ FTI Information ] : Post-checkpoint took 0.00 sec. (Ag:0.00s, Pt:0.00s, C1:0.00s) [ FTI Information ] : Ckpt. ID 3 (L1) (32.09 MB/proc) taken in 0.13 sec. (Wt:0.00s, Wr:0.12s, Ps:0.00s) 20 Une panne du noeud de calcul Ni est provoquée, causant alors une interruption du calcul de ce noeud de calcul Ni : [$. ipmitool -H bmc-Ni -Uuser -Ppass power off] 5 Dans la trace précédente, les sauvegardes locales de premier niveau Li sont différenciées des sauvegardes globales de quatrième niveau L4. Le calcul a été interrompu après avoir fait une sauvegarde globale de quatrième niveau L4 et une sauvegarde locale de premier niveau Li plus récente que la 10 sauvegarde globale de quatrième niveau L4, ce qui statistiquement correspondra à la grande majorité, pour ne pas dire à la quasi-totalité, des cas de survenue de panne en pratique. Le noeud de calcul Ni étant considéré en panne, le disque de stockage SO qui lui était attaché va être migré vers un autre noeud de calcul, ici le 15 noeud de calcul N3 (référencé 23 sur la figure 1). Le noeud de calcul N3 est le noeud qui possède le port d'administration du commutateur. La première étape est d'envoyer la commande qui permet de router à nouveau la remise à zéro PCI (« reset » en langue anglaise), le dernier argument étant le numéro du noeud fautif ou défaillant : 20 [$. ipmitool -Hpm-bmc-N3 -Usuper -Ppass raw Ox3a Oxcd 1] Cette commande peut être exécutée des noeuds voisins ou du noeud de management ou de gestion. 25 L'état des ports du commutateur (référencé 1 sur la figure 1) est vérifié : 5 10 15 20 21 $ bpsm info Active management port found @ 01:00:00 Management port control: Active mngt port: 0 (enabled) Redundant mngt port: 2 (enabled) Virtual switch enable: 00000007 VSO: Upstream port: 0 Downstream ports: 1 10 VS1: Upstream port: 2 Downstream ports: 3 11 VS2: Upstream port: 8 Downstream ports: 9 12 Le port 9 (référencé 18 sur la figure 1) du commutateur, sur lequel se trouve le disque de stockage SO du noeud de calcul fautif ou défaillant Ni au noeud de calcul courant N3 : 25 22 $ bpsm grab port 9 Suces sfully grabbed downstream port 9 $ bpsm info Active management port found @ 01:00:00 Management port control: Active mngt port: 0 (enabled) Redundant mngt port: 2 (enabled) Virtual switch enable: 00000007 VSO: Upstream port: 0 Downstream ports: 1 9 10 VS1: Upstream port: 2 Downstream ports: 3 11 VS2: Upstream port: 8 Downstream ports: 12 25 Il est demandé au système de scanner à nouveau le bus PCIe : $ echo 1 > /sys/bus/pci/devices/0000:00:00.0/rescan Le disque de stockage SO est désormais vu : $ lsblk NAME MAJ:MlN RM SIZE RO TYPE MOUNTPOINT loop() 7:0 0 1,1G 1 loop loopl 7:1 0 5G 1 loop 1-live-rw 253:0 0 5G 0 dm / I-live-base 253:1 0 5G 1 dm loop2 7:2 0 512M 0 loop I-live-rw 253:0 0 5G 0 dm / nvme0n1 259:0 0894,3G 0 disk nvmelnl 259:1 0 894,3G 0 disk 5 10 15 20 30 40 23 Une fois le disque de stockage SO migré, les données qui y sont sauvegardées peuvent être accédées en montant le système de fichiers : [$ mount /dev/nvmelnl /localckpt restorefl 5 Les données sauvegardées récupérées sont alors transmises au noeud de calcul de rechange en charge de remplacer le noeud de calcul Ni en panne. Il peut s'agir du même noeud que le noeud N3 en charge de la récupération des données sauvegardées sur le disque de stockage SO. 10 Les données sauvegardées puis récupérées étant alors transmises au noeud de calcul désigné de rechange (« spare » en langue anglaise), il ne reste alors plus qu'à relancer l'application en changeant le noeud de calcul Ni en panne par ce dernier noeud de calcul de rechange dans la commande « mpirun » : 15 $ mpirun -host N2,N3 --mca pml obi --mca btl self,vader,tcp --mca coll Ahcoll,fca --mca oob tcp if include enpl2s0f0 --mca btl tcp if include enpl2s0f0 -n 2 hdf.exe [ FTI Information ] : Reading FTI configuration file (config.fti)... 20 [ FTI Information ] : This is a restart. The execution ID is: 2016-11-09 17- 09-10 FTI Topo->nodeSize : 1 , FTI Topo->nbProc : 2 FTI Topo->nbNodes : 2 FTI Topo->nbNodes : 2 FTI Topo->groupSize : 2 , FTI Topo->nodeSize 1 25 FTI Topo->nodeSize : 1 , FTI Topo->nbProc : 2 FTI Topo->nbNodes : 2 FTI Topo->nbNodes : 2 FTI Topo->groupSize : 2 , FTI Topo->nodeSize 1 [ FTI Information ] : Recovering successfully from level 1. [ FTI Information ] : FTI has been initialized. 30 Local data size is 2048 x 1027 = 32. MB ( 32). Target precision : 0.00500 [ FTI Information ] : Variable ID 0 to protect. Current ckpt. size per rank is 0.00MB. [ FTI Information ] : Variable ID 2 to protect. Current ckpt. size per rank is 35 16.05MB. [ FTI Information ] : Variable ID 1 to protect. Current ckpt. size per rank is 32.09MB. Step : 500, error = 0.04888 24 Il peut être constaté que le calcul (qui détermine ici la valeur d'une erreur valant 0.04888) a donc bien repris à partir des sauvegardes locales de premier niveau Li. 5 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. Procédé de gestion de panne dans un réseau de noeuds (2), comprenant, pour chaque noeud considéré (2) de tout ou partie des noeuds (2) du réseau effectuant un même calcul : > d'abord, une étape de sauvegarde locale de l'état de ce noeud considéré (21), au niveau d'un support de stockage (31) de ce noeud considéré (21), le lien (6) entre ce support de stockage (31) et ce noeud considéré (21) pouvant être redirigé de ce support de stockage (31) vers un autre noeud (23), > ensuite, une étape de relance : o soit du noeud considéré (21) si celui-ci n'est pas défaillant, à partir de la sauvegarde locale de l'état de ce noeud considéré (21), o soit d'un noeud opérationnel (23) différent du noeud considéré (21), si le noeud considéré (21) est défaillant, à partir de la récupération de la sauvegarde locale de l'état de ce noeud considéré (21), en redirigeant ledit lien (6) entre le noeud considéré (21) et son support de stockage (31) de manière à relier ledit support de stockage (31) vers ledit noeud opérationnel (23), > les sauvegardes locales de ces noeuds considérés (2), utilisées pour les étapes de relance, sont cohérentes entre elles de sorte à correspondre à un même état de ce calcul. 2. Procédé de gestion de panne selon la revendication 1, caractérisé en ce que : > pour chaque noeud considéré non défaillant (22) : o il n'y a pas d'étape de récupération par un autre noeud (23), de la sauvegarde locale de l'état de ce noeud considéré non défaillant (22). 26 3. Procédé de gestion de panne selon la revendication 1 ou 2, caractérisé en ce que le noeud opérationnel (23) différent du noeud considéré (21) défaillant est un noeud de rechange (23). 5 4. Procédé de gestion de panne selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite redirection dudit lien (6) entre le noeud considéré (21) et son support de stockage (31) de manière à relier ledit support de stockage (31) vers ledit noeud opérationnel (23), 10 est réalisée par un changement d'aiguillage dans un commutateur (1) reliant plusieurs noeuds (21, 22, 23) à leurs supports de stockage (31, 32, 33). 5. Procédé de gestion de panne selon l'une quelconque des revendications 15 précédentes, caractérisé en ce que toutes les étapes de relance de noeuds (2) sont synchronisées entre elles, de manière à relancer tous lesdits noeuds (2) dans un même état de calcul. 6. Procédé de gestion de panne selon l'une quelconque des revendications 20 1 à 5, caractérisé en ce que : > l'étape de récupération comprenant une sous-étape de migration, vers le noeud opérationnel (23) ou vers le noeud de rechange (23), du support de stockage (31) de la sauvegarde locale de l'état du noeud défaillant (21), qui rattache, ce support de stockage (31) de 25 la sauvegarde locale de l'état du noeud défaillant (21), à un endroit prédéterminé de l'arborescence de fichiers de ce noeud opérationnel (23) ou de ce noeud de rechange (23), ce noeud opérationnel (23) ou ce noeud de rechange (23) venant ensuite lire, à cet endroit prédéterminé, le lien vers la sauvegarde locale de 30 l'état du noeud défaillant (21), lors de l'étape de relance de ce noeud opérationnel (23) ou de ce noeud de rechange (23), 27 > aucune copie, de la sauvegarde locale de l'état du noeud défaillant (21), n'étant réalisée, au niveau d'un autre noeud (23). 7. Procédé de gestion de panne selon la revendication 6, caractérisé en ce 5 que le noeud de rechange (23) et le noeud défaillant (21) qu'il remplace appartiennent tous les deux à la même lame de calcul. 8. Procédé de gestion de panne selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'étape de récupération comprend : 10 > d'abord, une sous-étape de migration, vers un noeud intermédiaire (23), du support de stockage (31) de la sauvegarde locale de l'état du noeud défaillant (21), qui rattache, ce support de stockage (31) de la sauvegarde locale de l'état du noeud défaillant (21), à un endroit prédéterminé de l'arborescence de fichiers de ce noeud 15 intermédiaire (23), > ensuite, une sous-étape de copie, de la sauvegarde locale de l'état du noeud défaillant (21), du support de stockage (31) rattaché au noeud intermédiaire (23) vers le support de stockage du noeud opérationnel ou du noeud de rechange, ce noeud opérationnel ou ce 20 noeud de rechange venant ensuite lire son support de stockage, lors de son étape de relance. 9. Procédé de gestion de panne dans un réseau de noeuds, selon la revendication 8, caractérisé en ce que, pour tout ou partie des noeuds (2) 25 du réseau effectuant un même calcul, le noeud de rechange (23) et le noeud défaillant (21) qu'il remplace appartiennent à des lames de calcul différentes. 10. Procédé de gestion de panne selon l'une quelconque des revendications 30 précédentes, caractérisé en ce que toutes ces étapes sont réalisées pour tous les noeuds (2) du réseau effectuant un même calcul. 28 11. Procédé de gestion de panne selon l'une quelconque des revendications 6 à 10, caractérisé en ce que la sous-étape de migration change le rattachement du support de stockage (31) de la sauvegarde locale de 5 l'état du noeud défaillant (21) en passant par l'intermédiaire d'un commutateur (1) auquel était rattaché le noeud défaillant (21) et son support de stockage (31) de la sauvegarde locale de l'état du noeud défaillant (21), mais sans passer par le noeud défaillant (21) lui-même. 10 12. Procédé de gestion de panne selon la revendication 11, caractérisé en ce que le changement de rattachement est réalisé par l'envoi d'une commande au commutateur (1), cette commande passant par l'un des noeuds (23) rattachés au commutateur (1) par un port de management (11). 15 13. Procédé de gestion de panne selon la revendication 11 ou 12, caractérisé en ce que ce commutateur (1) est un commutateur PCIe. 14. Procédé de gestion de panne selon l'une quelconque des revendications 20 11 à 13, caractérisé en ce que 3 à 10 noeuds (2) sont rattachés à un même commutateur (1). 15. Procédé de gestion de panne selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend aussi, pour tout ou partie 25 des noeuds du réseau effectuant un même calcul, une étape de sauvegarde globale de l'ensemble de ces noeuds (2), réalisée moins souvent que l'ensemble des étapes de sauvegarde locales de ces noeuds (2). 30 16. Procédé de gestion de panne selon l'une quelconque des revendications 3 à 15, caractérisé en ce que, pour tout ou partie des noeuds (2) du réseau 29 effectuant un même calcul, le réseau comprend entre 1 et 5 noeuds de rechange (23) pour 100 noeuds (2) effectuant ledit même calcul. 17. Procédé de gestion de panne selon l'une quelconque des revendications 5 précédentes, caractérisé en ce que, pour tout ou partie des noeuds (2) du réseau effectuant un même calcul, ce procédé de gestion de panne ne comprend aucun autre type de sauvegarde locale de l'état de ces noeuds (2). 10 18. Procédé de gestion de panne selon l'une quelconque des revendications précédentes, caractérisé en ce que, pour tout ou partie des noeuds (2) du réseau effectuant un même calcul, les supports de stockage (3) sont des mémoires flash. 15 19. Procédé de gestion de panne selon la revendication 18, caractérisé en ce que ces mémoires flash (3) sont des mémoires NVMe. 20. Partie d'un réseau de noeuds, comprenant : > un commutateur (1), 20 > une pluralité de noeuds (2) d'un groupe de noeuds effectuant un même calcul dans ce réseau de noeuds, > plusieurs supports de stockage (3) respectivement rattachés à ces noeuds (2) par l'intermédiaire du commutateur (1), > ces supports de stockage (3) étant structurés et disposés pour 25 sauvegarder localement l'état des noeuds (2) auxquels ils sont respectivement rattachés, > ce commutateur (1) étant structuré et disposé pour changer au moins un rattachement entre un noeud défaillant (21) et son support de stockage (31) lequel va alors devenir rattaché à un autre 30 noeud (23) de ladite pluralité de noeuds (2). 30 21. Partie d'un réseau de noeuds selon la revendication 20, caractérisée en ce que ce commutateur (1) étant structuré et disposé pour changer au moins un rattachement entre un noeud défaillant (21) et son support de stockage (31), sur commande extérieure au commutateur (1). 5 22. Partie d'un réseau de noeuds selon la revendication 20 ou 21, caractérisée en ce que ladite pluralité de noeuds (2) comprend entre 3 et 10 noeuds. 10 23. Partie d'un réseau de noeuds selon l'une quelconque des revendications 20 à 22, caractérisée en ce que ce commutateur (1) est un commutateur PC Te. 24. Partie d'un réseau de noeuds selon l'une quelconque des revendications 15 20 à 23, caractérisée en ce que les supports de stockage (3) sont des mémoires flash, de préférence des mémoires NVMe.