FR3055716A1

FR3055716A1 - Echange de messages pendant l'execution parallele de processus dans un calculateur haute performance

Info

Publication number: FR3055716A1
Application number: FR1658347A
Authority: FR
Inventors: Guillaume PAPAURE; Jean Vincent Ficet; Jean Olivier GERPHAGNON
Original assignee: Bull SA
Current assignee: Bull Sas Fr; Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date: 2016-09-08
Filing date: 2016-09-08
Publication date: 2018-03-09
Anticipated expiration: 2036-09-08
Also published as: US10917357B2; IL254397A0; US20180069803A1; FR3055716B1

Abstract

Des processus en cours d'exécution sur des nœuds de calcul respectifs (N1-Nn ) d'une grappe d'un calculateur HPC distribué peuvent communiquer entre eux par échange de messages à travers une fabrique d'interconnexion. Pour l'échange de messages entre processus, il est proposé une méthode d'identification des cartes physiques associées aux nœuds de calcul directement à partir du nom d'hôte desdits nœuds de calcul tels qu'ils sont utilisés dans le programme utilisateur. Cette identification directe est effectuée à partir d'au moins une table de correspondance (MT1) associant de manière bijective le nom d'hôte de chaque nœud de calcul de la grappe à l'adresse logique unique de la carte physique associée. Cette table de correspondance est entretenue dans un composant du calculateur en charge de la gestion de la fabrique, à savoir le gestionnaire de fabrique (FM1). Différents modes de réalisation permettent d'assurer le passage à l'échelle pour l'implémentation de la méthode d'échange de message entre processus.

Description

Domaine Technique

La présente invention se rapporte de manière générale aux calculateurs haute performance aussi connus sous le nom de calculateurs HPC (« HighPerformance Computing » selon la terminologie anglo-saxonne).

Elle concerne en particulier l’identification d’une carte réseau correspondant à un nœud de calcul utilisé pendant l’exécution d’un travail dans un calculateur HPC du type à mémoire distribuée, et vise plus particulièrement un procédé d’échange de messages pendant l’exécution de processus réalisant des opérations parallèles d’un programme utilisateur en cours d’exécution dans un calculateur haute performance.

L’invention trouve des applications, notamment, dans les calculateurs haute performance qui sont utilisés par exemple dans le domaine du calcul scientifique ou financier. L’invention peut aussi s’appliquer à des environnements de type grille de calcul (ou « Cloud-Computing » en anglais), c’est-à-dire dont les éléments sont distants les uns des autres, éventuellement sur des sites différents.

Arrière-plan Technologique

Une grappe (ou cluster) de serveurs est un groupe de serveurs indépendants fonctionnant comme un seul et même système de traitement de données. Un client utilise une grappe comme s'il s'agissait d'une machine unique. Les grappes sont habituellement constitués de nœuds, un nœud comprenant au minimum un processeur et de la mémoire. Communément, ces nœuds comprennent des nœuds de calcul et/ou de stockage, et un ou plusieurs nœuds de service comme des nœuds frontaux qui permettent d’assurer l’administration du cluster. Dans certaines applications, des nœuds de service supplémentaires peuvent en outre être dédiés au suivi (« monitoring », en anglais) de l’activité, par exemple. Les nœuds du cluster peuvent être reliés entre eux par un ou plusieurs réseaux technologiquement similaires ou différents.

Ainsi, un réseau avec un débit relativement lent, d’une part, est généralement dédié aux tâches d'administration (chargement des systèmes sur les nœuds, suivi d’activité, mesure de charge, etc.). Sur ce réseau d’administration, chaque nœud est identifié de manière unique, par exemple une adresse IP (« Internet Protocol» dans la terminologie anglo-saxonne) pour un réseau d’administration de type Ethernet à laquelle correspond également un nom.

Ce nom de la machine associé au nœud de calcul, ou nom-machine ou encore nom d'hôte (« hostname » dans la terminologie anglo-saxonne), est une correspondance permettant d’identifier une machine sur le réseau d’interconnexion. Ce nom d’hôte peut être utilisé dans le code d’un programme contenant des instructions ou des routines qui font appel à la machine correspondante. Dans le contexte du HPC, une telle machine est typiquement un nœud de calcul du cluster. Ce pseudonyme de la machine est associé de manière bijective à son identifiant sur le réseau d’administration, par exemple son adresse IP.

À ce réseau d’administration s’ajoute, d’autre part, un second réseau ou réseau d’interconnexion (ou fabrique d’interconnexion), avec un débit beaucoup plus important et une faible latence. Ce réseau peut utiliser des technologies de type InfiniBand™ ou Intel OmniPath™. Le débit unitaire peut atteindre plusieurs dizaines de gigabits par seconde, par exemple.

Dans un modèle de programmation parallèle par échange de messages, le programme à exécuter est dupliqué en plusieurs processus. Chaque processus exécute un exemplaire du programme sur un nœud de calcul respectif du cluster, et a accès à sa mémoire propre sur ce nœud dans la cas d’un calculateur à mémoire distribuée. De ce fait, les variables du programme deviennent des variables locales au niveau de chaque processus. De plus, un processus ne peut pas accéder à la mémoire des processus voisins. Un processus (processus émetteur) peut toutefois envoyer des informations à d’autres processus (processus récepteurs). A cet effet, les processus récepteurs doivent avoir été informés de ce qu’ils devaient recevoir ces informations du processus émetteur. La communication entre processus se fait par passage de messages, c’est-à-dire par envoi/réception de messages entre processus.

A cet effet, les programmes exécutés sur ce genre de machine peuvent se servir d'une API standard comme par exemple MPI (« Message Passing Interface »), qui utilise la communication avec des messages échangés entre les divers processus répartis sur les nœuds. Techniquement, cette communication se fait via des fonctions de la bibliothèque MPI appelées dans le programme. L’environnement MPI permet de gérer et d’interpréter ces messages.

Dans un tel contexte, le nombre d’éléments communicants (processus) peut être très élevé, par exemple plusieurs milliers. Et ce nombre ne cesse d’augmenter, notamment avec le passage à l’ère Exaflopique.

Art Antérieur

Lors de la soumission d’un travail sur un calculateur distribué du type précité, un nombre donné de ressources est précisé par l’utilisateur. En général, il est exprimé en nombre de nœuds ou en nombre de cœurs de processeurs qui sont nécessaires pour exécuter le travail.

De ce fait, lors de l’allocation des ressources, le travail va s’exécuter sur un nombre défini de nœuds identifiés chacun par leur nom d’hôte ou «hostname». Ces noms sont en fait des alias permettant de déterminer l’adresse IP correspondant à chaque nœud. Cette détermination, ou traduction, se fait en règle générale par l’intermédiaire d’un service de type DNS (« Domain Name Service » dans la terminologie anglo-saxonne) ou à travers un fichier de correspondance (/etc/hosts) local.

Ensuite, il est nécessaire d’identifier les cartes physiques (ou cartes réseau) associées du réseau haut débit (InfiniBand™ ou IB, OmniPath™ ou OPA, ...) qui serviront durant les communications (échanges de message), lors de l’exécution du travail. Il convient donc de déterminer l’identifiant unique, sur le réseau d’interconnexion, de chaque carte physique de chaque nœud utilisé pour réaliser le travail soumis. Cet identifiant unique de nœud sur le réseau d’interconnexion est appelé « Node ID » dans la terminologie anglo-saxonne.

En résumé, il existe trois niveaux d’identification d’une ressource utilisée pour exécuter un travail correspondant à une partie du calcul :

- le nom d’hôte ou Hostname qui est son pseudonyme utilisé dans le programme exécuté,

- l’adresse IP qui est son identifiant sur le réseau d’administration, et

- le Node ID qui est l’identifiant sur le réseau d’interconnexion de la carte réseau correspondante.

Et il convient de réaliser les deux étapes de traduction suivantes, notées ® et © respectivement, pour aboutir à l’élément physique souhaité lors des échanges durant l’exécution du travail :

Hostname —-®—-> Adresse IP — -®—-> Node ID (IB, OPA...)

Cette méthode d’identification est standard dans MPI et sur tous les supercalculateurs.

Cependant elle est loin d’être optimale car elle nécessite plusieurs étapes chacune pouvant engendrer différents problèmes :

- Problème de passage à l’échelle (« Scalability », en anglais), notamment car le serveur DNS est unique, et peut ne pas tenir la charge pour réaliser un grand nombre de traductions ® ;

- Problème de cohérence des informations nécessaires pour les deux traductions ® et ©, car les fichiers /etc/hosts peuvent ne pas être tenus à jour sur certains nœuds ;

- Multiplication des opérations de traduction nécessitant chacune du temps de calcul, qui est donc perdu pour le calcul en lui-même (temps d’initialisation) ;

- Nécessité de demander à chaque nœud son Node ID une fois la résolution IP obtenue, entraînant un grand nombre d’échanges sur le réseau d’interconnexion pour les traductions ©.

L’invention vise à permettre d’obtenir plus rapidement et plus efficacement les Node ID des cartes réseau haut débit (IB, OPA...) correspondant aux nœuds utilisés pendant un calcul exécuté en faisant appel à la parallélisation de processus sur un supercalculateur à mémoire distribuée, à partir du nom d’un nœud (hostname) tel qu’utilisé dans le programme d’application. Notamment, l’une des contraintes d’efficacité prises en compte est de pouvoir passer à l’échelle pour des clusters à très grand nombre de nœuds (par exemple plusieurs dizaines de milliers).

Résumé de l'Invention

A cette fin, des modes de réalisation de l’invention proposent d’obtenir directement, par l’intermédiaire d’une ou plusieurs entités tierces, le Node ID d’un nœud de calcul utilisé pendant le calcul à partir de son hostname. L'invention permet donc de supprimer, ou du moins atténuer, tout ou partie des inconvénients de l'art antérieur précités puisqu’elle évite les deux traductions (T) et © explicitées en introduction.

Selon des modes de réalisation de l’invention, des processus en cours d’exécution sur des nœuds de calcul respectifs peuvent communiquer entre eux par échange de messages à travers la fabrique d’interconnexion. Pour l’échange de messages entre processus, l’identification d’une carte physique (HCA) associée à un nœud de calcul est réalisée directement à partir du nom d’hôte dudit nœud qui est utilisé dans le programme utilisateur. Cette identification directe est effectuée à partir d’au moins une table de correspondance associant de manière bijective le nom de chaque nœud de calcul de la grappe à l’adresse logique unique de la carte physique associée. Cette table de correspondance est entretenue dans un composant logiciel du calculateur en charge de la gestion de la fabrique, à savoir le gestionnaire de fabrique (« fabric manager» selon la terminologie anglo-saxone). Cette table, qui existe déjà au sein d’un serveur de service qui opère comme nœud de tête du cluster, associe bijectivement les identificateurs de chaque carte physique présente dans les nœuds de la grappe aux noms d’hôte des nœuds correspondants tels qu’ils apparaissent au niveau logique dans le programme utilisateur.

Plus particulièrement, un premier aspect de l’invention propose un procédé d’échange de messages pendant l’exécution de processus réalisant des opérations parallèles d’un programme utilisateur en cours d’exécution dans un calculateur haute performance distribué comprenant, d’une part, une grappe de nœuds de calcul au sein de laquelle chaque nœud de calcul est connu dans le programme utilisateur par un nom d’hôte (ou pseudonyme, ou « alias ») et est associé à une carte physique ayant des ressources physiques déterminées (e.g. des cœurs de processeurs, mémoire de stockage) pour l’exécution d’un processus et ayant une adresse logique unique (identifiant Node ID) et, d’autre part, une fabrique d’interconnexion (e.g. à haut débit et faible latence) interconnectant les nœuds de calcul entre eux. Pour l’échange de messages entre processus pouvant communiquer entre eux par échange de messages à travers la fabrique d’interconnexion, l’identification d’une carte physique associée à un nœud de calcul directement sur la base du nom d’hôte dudit nœud de calcul utilisé dans le programme utilisateur, à partir d’au moins une table de correspondance associant de manière bijective le nom d’hôte de chaque nœud de calcul de la grappe à l’adresse logique unique de la carte physique associée, ladite table de correspondance étant entretenue dans un composant du calculateur en charge de la gestion de la fabrique d’interconnexion.

Dans des modes de réalisation, la grappe de nœuds de calcul peut être organisée en une pluralité de sous-grappes de nœuds de calcul respectivement associées à une pluralité de gestionnaires de fabrique dédiés chacun à l’une des sous grappes et contenant chacun une table de correspondance associant de manière bijective le nom d’hôte de chaque nœud de calcul de la grappe (/.e., de l’ensemble des sous-grappes) à l’adresse logique unique de la carte physique associée.

Dans ce cas, la pluralité de gestionnaires de fabrique peut en outre être organisée selon une architecture de serveurs maître/esclaves avec un serveur maître contenant la table de correspondance et des serveur esclaves contenant une réplication de cette table de correspondance, ledit serveur maître étant configuré pour assurer la cohérence desdites tables de correspondance et pour se synchroniser avec l’ensemble des serveurs esclaves.

En variante, tout ou partie des informations de la table de correspondance peuvent être extraites en temps réel du gestionnaire de la fabrique et être répliquées dans une base de données répartie sur une pluralité de serveurs de service intermédiaires, l’identification de la carte physique associée à chaque nœud de calcul utilisé pendant l’exécution du travail étant réalisée directement à partir du nom d’hôte dudit nœud par l’intermédiaire de l’une des répliques de la table de correspondance du gestionnaire de la fabrique respectivement stockées dans lesdits serveurs de service intermédiaires.

Dans cette variante, la pluralité de serveurs de service intermédiaires peut être organisée selon une architecture maître/esclaves avec un serveur de service intermédiaire maître configuré pour assurer la cohérence des informations et se synchroniser avec l’ensemble des serveurs de service intermédiaires esclaves.

Dans une autre variante encore, la relation entre le nom de tous les nœuds de calcul à utiliser pour l’exécution du travail d’une part, et les adresses logiques uniques des cartes physiques qui leur sont respectivement associées, d’autre part, peut être réalisée une seule fois préalablement à l’exécution du travail, et être stockée dans une mémoire cache pour réemploi pendant l’exécution du travail.

Dans des exemples de mises en œuvre du procédé, l’échange de messages entre processus peut être effectué en faisant appel à la bibliothèque MPI, ou toute autre bibliothèque ou procédé fonctionnant sur le même principe que MPI.

Dans un second aspect, l’invention concerne également un produit programme d'ordinateur comprenant un jeu d'instructions qui, lorsqu'il est exécuté par des moyens de traitement, est propre à mettre en œuvre le procédé selon le premier aspect ci-dessus pour l’échange de messages entre des processus réalisant des opérations parallèles du programme au sein d'un calculateur haute performance.

Un troisième aspect de l’invention concerne un calculateur haute performance distribué comportant une grappe de nœuds de calcul ayant des ressources physiques pour exécuter chacun un processus d’un travail de manière indépendante d’autres processus exécutés en parallèle par d’autres nœuds de calcul du calculateur, et des moyens aptes à gérer l’échange de messages entre lesdits processus selon le procédé selon le premier aspect cidessus.

Le programme d’ordinateur et le calculateur haute performance présentent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect de l’invention.

Brève Description des Dessins

D’autres caractéristiques et avantages de l’invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels :

- la Figure 1 est un schéma simplifié d’un calculateur haute performance à mémoire distribuée montrant les principaux éléments fonctionnels du calculateur selon des modes de réalisation de l’invention ;

- la Figure 2 montre les identifiants logiques (hostname, adresse IP, node ID) des nœuds de calcul du schéma de la Figure 1 ;

- la Figure 3 est un schéma fonctionnel d’un calculateur HPC selon un premier mode de réalisation ;

- la Figure 4 est un schéma fonctionnel d’un calculateur HPC selon un deuxième mode de réalisation.

Description détaillée de modes de réalisation

Dans la description de modes de réalisation qui va suivre et dans les Figures des dessins annexés, les mêmes éléments ou des éléments similaires portent les mêmes références numériques aux dessins.

Le calcul haute performance (ou HPC, de l’anglais « High Performance Computing ») se réfère à une branche de l'informatique appliquée, portant essentiellement sur la résolution de problèmes nécessitant une grande capacité de calculs. De nombreux problèmes demandant en principe des machines très puissantes, peuvent être décomposés et résolus en effectuant des calculs en parallèle. Les travaux complexes peuvent en effet tirer parti du parallélisme entre plusieurs machines plus petites (ou nœuds de calcul), qui sont regroupées en systèmes appelés grappes (ou clusters) de calcul. Les grappes de calcul permettent en effet d'utiliser la puissance de plusieurs machines pour réaliser des calculs lourds. Une grappe de calcul est un ensemble de machines homogènes et localisées, qui est mis en œuvre selon le principe de la programmation parallèle. Typiquement, les nœuds de calcul sont compris dans des serveurs ou baies informatiques.

Ce type de calculateur est utilisé, par exemple, dans les centres de recherche scientifique (météorologie, simulation nucléaire, etc.). L’intérêt de faire de la programmation parallèle est notamment de réduire le temps de restitution, d’effectuer de plus gros calculs, d’exploiter le parallélisme des processeurs modernes (multi-cœurs, multithreading), etc.

Le parallélisme de tâches fait référence au cas où ce sont les tâches à réaliser qui sont parallélisées, plutôt que les données ou paramètres d'entrée. Le parallélisme découle de la réalisation simultanée de différents traitements sur les données. Il existe deux types d’implémentation permettant de paralléliser une tâche : en utilisant plusieurs fils d'exécutions (ou « threads » selon la terminologie anglo-saxonne), ou en utilisant plusieurs processus exécutés en parallèle.

Dans les implémentations du premier type ci-dessus, les fils d'exécution ont accès à un espace de mémoire vive commun, ou mémoire partagée. Ils peuvent ainsi opérer sur les mêmes données. Cela offre l'avantage qu'il n'est pas nécessaire de copier de la mémoire entre deux unités de calcul, et cela élimine pratiquement la communication entre les unités de calcul. Par contre, les fils d'exécution sont aussi limités à s'exécuter sur un seul et même nœud de calcul. Le gain obtenu par cette technique de parallélisme est ainsi limité par le nombre de fils d'exécution, qui sera typiquement égal ou inférieur au nombre de cœurs de calcul disponibles sur le nœud. Ainsi, par exemple, OpenMP est une surcouche du « multithreading » dans le sens où elle permet de paralléliser des boucles très simplement via des pragmas ajoutés au code source. OpenMP est clairement orienté programmation à mémoire partagée (c'est-à-dire que la mémoire doit être accessible aux différents fils d’exécution du programme compilé avec OpenMP), ce qui cantonne le programme à une machine isolée.

La parallélisation par processus selon des implémentations du second type précité permet au contraire d'utiliser une quantité de ressources beaucoup plus élevée. En effet, les différents processus peuvent être exécutés aussi bien sur le même nœud de calcul que sur des nœuds différents, et la mémoire est distribuée sur les différents nœuds. Contrairement aux fils d'exécution, les processus ne partagent donc aucun espace mémoire. Cela a pour avantage qu'il est plus facile de s'assurer de l'intégrité des données en mémoire. En effet, un processus ne peut pas, même par accident, modifier l'espace mémoire d'un autre processus. La contrepartie de cet avantage est qu'il devient nécessaire de faire des opérations explicites de communication pour copier des données entre deux processus. En effet, pour travailler à plusieurs processus en parallèle sur les mêmes données, une coordination entre processus est nécessaire. On utilise généralement pour ce faire la bibliothèque de passage de messages MPI (« Message Passing Interface », selon la terminologie anglo-saxonne).

MPI est une bibliothèque permettant de coordonner des processus en utilisant le paradigme de l’échange de messages. En effet, MPI permet une communication entre deux processus, peu importe leur interconnexion (par exemple par réseau Ethernet ou InfiniBand™ (IB) ou encore OmniPath™ (OPA), ou par mémoire partagée au sein d’un même nœud le cas échéant). C’est l’une des librairies de communication les plus utilisées dans un environnement HPC. Cette librairie permet de réaliser des programmes exécutant des opérations parallèles sur les nœuds respectifs du cluster, et pouvant communiquer à travers le réseau d’interconnexion.

Dans un modèle de programmation parallèle par échange de messages tel que MPI, le programme utilisateur est dupliqué sur plusieurs processus. Chaque processus exécute un exemplaire du programme utilisateur et a accès à sa mémoire propre. De ce fait, les variables du programme deviennent des variables locales au niveau de chaque processus. De plus un processus ne peut pas accéder à la mémoire des processus voisins. Il peut toutefois envoyer des informations à d’autres processus à condition que ces derniers (processus récepteurs) soient au courant qu’ils devaient recevoir ces informations du processus émetteur. La communication entre processus se fait uniquement par passage de messages entre processus, c’est-à-dire par envoi et réception de messages. Techniquement, cette communication se fait via des fonctions de la bibliothèque MPI appelées dans le programme utilisateur. L’environnement MPI permet de gérer et d’interpréter ces messages.

Les ressources physiques du cluster (processeurs, cœurs, mémoires) qui exécutent les processus réalisant des opérations parallèles d’un travail donné, communiquent au sein d’un nœud, et également d'un nœud à l'autre. A cet effet, les nœuds sont reliés par un réseau d'interconnexion ultra-rapide et avec un temps de latence faible pour échanger des messages en vue de coordonner le traitement du travail en cours. Au minimum, chaque nœud de calcul et le nœud de tête doivent donc être connectés sur le réseau d’interconnexion. Le nom donné de manière standard dans l’état de l’art pour désigner ce réseau d’interconnexion est «fabrique». La fabrique d’un calculateur H PC est donc un réseau physique rapide, par exemple InfiniBand™, OmniPath™, etc., permettant de relier ensemble les nœuds de calcul du cluster.

Les systèmes interconnectés à grand nombre de nœuds de calcul travaillant ensemble à résoudre des problèmes complexes ont également besoin d’être administrés. Des processus et outils adaptés à la mise en service, au contrôle, à la gestion et à la maintenance de centaines ou de milliers de nœuds permettent ainsi de garantir un environnement stable et cohérent. Ainsi, par exemple, et par opposition à OpenMP, OpenMPI peut être utilisé pour l’administration des infrastructures à mémoire distribuée. OpenMPI crée une infrastructure de communication au-dessus du réseau physique d’interconnexion, qui abstrait ce réseau physique au niveau du programmeur. On parle ainsi de réseau d’administration du cluster de nœuds de calcul. Ce réseau d’administration peut alors déployer des processus MPI un peu partout sur l'infrastructure sans se soucier du placement ou de la gestion des connexions entre les différentes machines de son infrastructure.

Pour la réalisation d’un travail déterminé, un planificateur s’exécute qui permet de coordonner les affectations de tâches des différents processus entre les nœuds nécessaires. Le planificateur s'exécute par exemple sur un nœud de tête du cluster. Il identifie les ressources disponibles, attribue et distribue les tâches, et contrôle l’état global des nœuds. Il s'agit du coordinateur de ressources au sein de la grappe. Les utilisateurs et les administrateurs soumettent à ce nœud de tête les travaux à traiter par le système ou cluster.

En référence au schéma de la Figure 1, une architecture de calculateur HPC de type cluster comprend notamment une grappe 10 de nœuds de calculs (à savoir le cluster de nœuds de calcul), des moyens d’administration 20 et une fabrique d’interconnexion 20.

Le cluster 10 tel que représenté à la Figure 1 comprend un nombre nde nœuds de calculs, respectivement N1, N2, ..., Nn. En pratique, le nombre nde nœuds peut être très élevé, par exemple égal à plusieurs centaines ou milliers. La présente invention n’est pas limitée par le nombre de nœud de calcul.

Les nœuds de calcul sont implémentés, au niveau physique, sous la forme de machines ou serveurs reliés entre eux par la fabrique d’interconnexion 20. Ces serveurs hébergent chacun une ou plusieurs cartes physiques (ou

HCA), qui correspondent aux ressources physiques du calculateur HPC distribué. Chaque serveur comprend en effet, sur ces cartes HCA, des ressources de calcul et des ressources mémoire. Comme le sait l’Homme du métier, les cartes HCA assurent la connexion entre un port d'un système géré et d'autres unités. Ce port peut être connecté à une autre carte HCA, à une unité cible ou à un commutateur qui réachemine les données provenant de l'un de ses ports vers une unité connectée à un autre de ses ports.

Les ressources de calcul d’un nœud de calcul comprennent un ou plusieurs processeurs, avec un ou plusieurs cœurs chacun.

Chacun des nœuds forme ainsi une entité de calcul indépendante avec au minimum un cœur de processeur et de la mémoire propre associée. Il peut ainsi exécuter de manière totalement indépendante un processus déterminé d’un travail assuré par le calculateur sous la forme d’une pluralité de processus exécutés en parallèle, avec de la mémoire propre à chaque processus

En d’autres termes, chaque processus dispose de ses propres données et n’a pas d’accès direct aux données des autres processus. Les données du programme sont stockées dans la mémoire du processeur sur lequel s’exécute le processus. Une donnée est échangée entre deux ou plusieurs processus via un appel à des routines particulières et spécialisées, de la bibliothèque MPI.

Les moyens d’administration 20 du calculateur comprennent un ou plusieurs serveurs d’administration, aussi appelés nœuds de service. Un serveur d’administration est responsable, notamment, de l'authentification des utilisateurs, du lancement des tâches de calcul, de l’accès aux fichiers, ainsi que de la surveillance de l'ensemble du calculateur.

Lorsqu’il y en a plusieurs, les serveurs d’administration obéissent par exemple à une organisation de type maître/esclave. On compte par exemple deux tels serveurs SN1 et SN2 dans le calculateur HPC tel que représenté à la Figure 1. Le serveur SN1, aussi appelé nœud de tête, étant le serveur maître et le serveur SN2 étant un serveur esclave. Ce nombre n’est qu’un exemple non limitatif. Un seul et unique serveur d’administration, ou au contraire plus de deux serveurs d’administration sont d’autre exemples envisageables.

La fabrique d’interconnexion 30 comprend notamment un ensemble de commutateurs de réseau (ou « switches », selon la terminologie anglo-saxonne), des câbles formant les liens d’interconnexion entre les serveurs, et du logiciel associé.

Ce logiciel associé comprend notamment un composant de réseau connu de l’Homme de l’art sous le nom de gestionnaire de la fabrique. Selon la terminologie anglo-saxonne, ce gestionnaire de fabrique peut s’appeler « fabric manager», «subnet manager», etc., selon la technologie du calculateur concerné). Ce gestionnaire de fabrique est un composant logiciel adapté pour entretenir une table de correspondance associant de manière bijective le nom de chaque nœud de calcul de la grappe 10 à l’adresse logique unique de la carte physique associée.

C’est pourquoi, selon des modes de réalisation de la présente invention, le gestionnaire de fabrique joue le rôle d’une tierce entité à laquelle il est fait appel, au cours de l’exécution d’un programme, pour obtenir, à partir du nom d’hôte d’un nœud de calcul de la grappe sur lequel s’exécute un processus déterminé, l’adresse logique unique de la carte physique associée à ce nœud. Cette utilisation est originale et avantageuse dans le cadre de l’échange de messages entre processus, utilisant la bibliothèque MPI par exemple. Ceci sera détaillé plus loin en référence au schéma de la Figure 2.

Dans l’exemple représenté à la Figure 1, la fabrique a une topologie hiérarchique à trois étages, par exemple de type « fattree » selon la terminologie anglo-saxonne : un premier étage avec deux commutateurs S11 et S2 servis par le serveur d’administration SN1 et le serveur d’administration SN2, respectivement ; puis un deuxième niveau avec deux autres commutateurs S21 et S22 entrelacés avec les commutateurs du premier niveau ; et enfin un troisième et dernier niveau avec trois autres commutateurs S31, S32 et S33 entrelacés avec les commutateurs du second niveau. Cet exemple est purement illustratif et n’est nullement limitatif des modes de réalisation de l’invention.

Le schéma de la Figure 2 correspond à celui de la Figure 1 dans lequel, en ce qui concerne la grappe 10, il a été ajouté les éléments logiques d’identification des différents nœuds de calcul, en bas de la Figure. Ces éléments logiques d’identification comprennent, pour chaque nœud de calcul N1 à Nn :

le nom d’hôte ou Hostname qui est le pseudonyme du nœud de calcul utilisé dans le programme utilisateur en cours d’exécution ; dans l’exemple représenté, Hostl est le nom d’hôte du nœud N1, Host2 est le nom d’hôte du nœud N2, etc., et HostNest le nom d’hôte du nœud Nn ;

l’adresse IP (ou « @IP ») qui est l’identifiant sur le réseau d’administration ; dans l’exemple représenté, 10.0.0.1 est l’adresse IP du nœud N1, 10.0.0.2 est l’adresse IP du nœud N2, etc., et 10.0.0.N est l’adresse IP du nœud Nn ; et, le Node ID qui est l’identifiant du nœud de calcul sur le réseau d’interconnexion (i.e., la fabrique) de la carte réseau correspondante ; dans l’exemple représenté, cet identifiant est codé par un nombre à quatre chiffres, par exemple 0024 pour le nœud N1,0010 pour le nœud N2, 0201 pour le nœud N2, 0211 pour le nœud N4, etc. Il s’agit bien entendu d’exemples arbitraires, non limitatifs de l’invention.

Par ailleurs, la Figure 2 montre que le gestionnaire de fabrique FM1 maintient une table de correspondance MT1 (ou table de « mapping » selon la terminologie anglo-saxonne) qui associe de manière bijective le nom d’hôte Hostnamede chaque nœud de calcul de la grappe 10 à l’adresse logique unique Node ID de la carte physique associée. Cette table MT1 est gérée par le gestionnaire de fabrique maître FM1. Lorsqu’il existe un (ou plusieurs) gestionnaire(s) de fabrique esclave(s) comme le gestionnaire FM2 de l’exemple de la Figure 2, la table MT1 est répliquée sur le nœud de service correspondant, à savoir le serveur SN2 à la Figure 2, en tant que table MT2.

Des modes de réalisation de l’invention comprennent, pour l’échange de messages MPI entre processus, l’identification d’une carte physique (carte HCA) associée à un nœud de calcul utilisé pendant l’exécution du travail, directement à partir du nom d’hôte dudit nœud tel qu’il est utilisé dans le programme utilisateur. Cette identification directe est réalisée par l’intermédiaire d’un moins une tierce entité logique contenant tout ou partie de la table de correspondance précitée. Dans le mode de réalisation de la Figure 2, cette tierce entité est le gestionnaire de fabrique FM1, en coopération avec le(s) gestionnaire(s) de fabrique esclaves comme FM1, le cas échéant.

L’Homme du métier appréciera que le gestionnaire de fabrique est un composant logiciel en charge de la gestion des identificateurs de chaque carte physique (HCA) présente dans les nœuds de la grappe. La table de correspondance MT1 existe donc déjà dans un calculateur de l’art antérieur. Toutefois, elle n’est pas utilisée, dans l’état de l’art, lors de l’initialisation de l’échange de messages entre processus par une librairie telle que MPI.

Or, son utilisation conformément à des modes de réalisation de l’invention permet d’éviter les inconvénients qui découlent des deux traductions ® et © selon l’art antérieur, qui ont été présentés en introduction.

Dans le mode de réalisation de la Figure 3, la grappe de nœuds de calcul est organisée en une pluralité de sous-grappes de nœuds de calcul 11,12 et 13. Dans l’exemple représenté, les nœuds N1, N2 et N3 appartiennent ainsi à la sous-grappe 11, les nœuds N4, N5 et N6 appartiennent à la sous-grappe 12, et les nœuds N7 à Nn appartiennent ainsi à la sous-grappe 13. On appréciera que l’invention n’est pas limitée par le nombre de sous-grappes, ni par la distribution des nœuds de calcul de la grappe au sein de ces sous-grappes.

Les sous-grappes 11, 12 et 13 montrées à la Figure 3 sont associées chacune à un gestionnaire de fabrique dédié FM11, FM12 et FM13, respectivement. Chacun des gestionnaires de fabrique contient une table de correspondance MT11, MT12 et MT13, respectivement, qui sont comparables à la table de correspondance MT 1 de la Figure 2. Ces tables MT11, MT12 et MT13 associent de manière bijective le nom d’hôte Hostname de chaque nœud de calcul de la grappe 10 à l’adresse logique unique Node ID de la carte physique associée.

La pluralité de gestionnaires de fabrique FM11, FM12 et FM13 peut être organisée au sein d’une architecture de serveurs de service de type maître/esclaves, avec par exemple un serveur maître SN11 contenant le gestionnaire de fabrique FM11, et des serveur esclaves SN12 et SN13 contenant les gestionnaires de fabrique FM12 et FM13, respectivement. Le gestionnaire de sous-fabrique maître FM11 est configuré pour assurer la cohérence des informations et pour synchroniser l’ensemble des gestionnaires de sous-fabrique esclaves FM12 et FM13. Ceci est illustré à la Figure 3 par les flèches 120 et 130, respectivement.

Dit autrement, dans ce mode de réalisation on découpe le cluster de nœuds de calcul 10 de la Figure 2 en sous-parties 11, 12 et 13 avec un gestionnaire de fabrique FM11, FM12 et FM13, respectivement, dédié à chaque sous-partie, et ces gestionnaires sont synchronisés entre eux. Chaque groupe de nœuds communique ainsi avec un gestionnaire de fabrique qui lui est dédié. On facilite ainsi le passage à l’échelle dans le cas des calculateurs avec un nombre important de nœuds de calcul.

Un autre mode de réalisation va maintenant être présenté en référence au schéma de la Figure 4, qui permet d’assurer le passage à l’échelle d’une autre manière. Dans ce mode de réalisation, tout ou partie des informations de la table de correspondance MT sont extraites en temps réel du gestionnaire de la fabrique FM et sont répliquées dans une base de données qui est répartie sur une pluralité de serveurs de service intermédiaires IS1, IS2, et IS3 afin d’éviter la formation d’un point de congestion (« bottleneck » dans la terminologie anglosaxonne) pour les échanges de messages dans les clusters à grand nombre de nœuds de calcul.

Dans ce mode de réalisation, l’identification de la carte physique associée à chaque nœud de calcul utilisé pendant l’exécution du travail est réalisée, pour l’échange de messages, directement à partir du nom d’hôte dudit nœud par l’intermédiaire de l’une des répliques MT 1, MT2 et MT3 de la table de correspondance du gestionnaire de la fabrique stockée chacune dans l’un des serveurs de service intermédiaires IS1, IS2, et IS3, respectivement.

Dans l’exemple représenté à la Figure 4, le serveur intermédiaire IS1 sert un premier groupe 11 des nœuds de la grappe 10 comprenant les nœuds N1, N2 et N3, le serveur intermédiaire IS2 sert un deuxième groupe 12 des nœuds de la grappe 10 comprenant les nœuds N4, N5 et N6, et le serveur intermédiaire IS3 sert un troisième groupe 13 des nœuds de la grappe 10 comprenant les nœuds N7 à Nn. Ainsi, les serveurs de service intermédiaires se partagent la charge de l’identification des cartes physiques des nœuds de calcul destinataires des messages, en fonction du nœud émetteur des messages. On passe ainsi facilement à l’échelle, dans le cas des calculateurs HPC avec une grappe comprenant un nombre important de nœuds de calcul.

Dans un mode de réalisation, la pluralité de serveurs de service intermédiaires IS1, IS2, et IS3 peut être organisée selon une architecture maître/esclaves. Le serveur de service intermédiaire maître IS1 peut être configuré pour assurer la cohérence des informations de la table de traductions et se synchroniser avec l’ensemble des serveurs de service intermédiaires esclaves, à savoir IS2 et IS3 dans l’exemple représenté.

La présente invention a été décrite et illustrée dans la présente description détaillée et dans les Figures. La présente invention ne se limite pas aux formes de réalisation présentées. D’autres variantes et modes de réalisation peuvent être déduits et mis en œuvre par la personne du métier à la lecture de la présente description et des Figures annexées.

Par exemple, dans d’autres modes de réalisation, la relation bijective entre le nom d’hôte de tous les nœuds de calcul à utiliser pour l’exécution du travail d’une part, et les adresses logiques uniques des cartes physiques qui leur sont respectivement associées, d’autre part, peut être réalisée une seule fois préalablement à l’exécution du travail, et être stockée dans une mémoire cache pour réemploi pendant l’exécution du travail.

Dans les revendications, le terme “comporter” n’exclut pas d’autres éléments ou d’autres étapes. L’article indéfini « un » n’exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en œuvre l’invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n’excluent pas cette possibilité. Les signes de référence ne sauraient être compris comme limitant la portée de l’invention.

Claims

REVENDICATIONS

1. Procédé d’échange de messages pendant l’exécution de processus réalisant des opérations parallèles d’un programme utilisateur en cours d’exécution dans un calculateur haute performance distribué comprenant, d’une part, une grappe de nœuds de calcul au sein de laquelle chaque nœud de calcul est connu dans le programme utilisateur par un nom d’hôte (ou pseudonyme ou « alias ») et est associé à une carte physique (HCA) ayant des ressources physiques déterminées (cœurs de processeurs, mémoire de stockage) pour l’exécution d’un processus et ayant une adresse logique unique (identifiant Node ID) et, d’autre part, une fabrique d’interconnexion (à haut débit et faible latence) interconnectant les nœuds de calcul entre eux, le procédé étant caractérisé en ce qu’il comprend, pour l’échange de messages entre processus pouvant communiquer entre eux par échange de messages à travers la fabrique d’interconnexion, l’identification d’une carte physique (HCA) associée à un nœud de calcul directement sur la base du nom d’hôte dudit nœud de calcul utilisé dans le programme utilisateur, à partir d’au moins une table de correspondance associant de manière bijective le nom d’hôte de chaque nœud de calcul de la grappe à l’adresse logique unique de la carte physique associée, ladite table de correspondance étant entretenue dans un composant du calculateur en charge de la gestion de la fabrique d’interconnexion.
2. Procédé selon la revendication 1, dans lequel la grappe de nœuds de calcul est organisée en une pluralité de sous-grappes de nœuds de calcul (11,12,13) respectivement associées à une pluralité de gestionnaires de fabrique (FM11 ,FM12,FM13) dédiés chacun à l’une des sous grappes et contenant chacun une table de correspondance (MT 11 ,MT 12,MT 13) associant de manière bijective le nom d’hôte de chaque nœud de calcul de la grappe à l’adresse logique unique de la carte physique associée.
3. Procédé selon la revendication 2 dans lequel la pluralité de gestionnaires de fabrique est organisée selon une architecture de serveurs maître/esclaves avec un serveur maître (FM1) contenant une première des tables de correspondance et des serveur esclaves (FM2,FM3) contenant les autres tables de correspondance, ledit serveur maître étant configuré pour assurer la cohérence desdites tables de correspondance et pour se synchroniser avec l’ensemble des serveurs esclaves.
4. Procédé selon la revendication 1, dans lequel tout ou partie des informations de la table de correspondance (MT) sont extraites en temps réel du gestionnaire de la fabrique (FM) et sont répliquées dans une base de données répartie sur une pluralité de serveurs de service intermédiaires (IS1 ,IS2,IS3), l’identification de la carte physique associée à chaque nœud de calcul utilisé pendant l’exécution du travail étant réalisée directement à partir du nom d’hôte dudit nœud par l’intermédiaire de l’une des répliques (MT 1 ,MT2,MT3) de la table de correspondance du gestionnaire de la fabrique respectivement stockées dans lesdits serveurs de service intermédiaires.
5. Procédé selon la revendication 4, dans lequel la pluralité de serveurs de service intermédiaires est organisée selon une architecture maître/esclaves avec un serveur de service intermédiaire maître (IS1) configuré pour assurer la cohérence des informations et se synchroniser avec l’ensemble des serveurs de service intermédiaires esclaves (IS2,IS3).
6. Procédé selon la revendication 1, dans lequel la relation entre le nom de tous les nœuds de calcul à utiliser pour l’exécution du travail d’une part, et les adresses logiques uniques des cartes physiques qui leur sont respectivement associées, d’autre part, est réalisée une seule fois préalablement à l’exécution du travail, et est stockée dans une mémoire cache pour réemploi pendant l’exécution du travail.
7. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’échange de messages entre processus est effectué en faisant appel à la bibliothèque MPI, de l’anglais « Message Passing Interface ».
8. Produit programme d'ordinateur comprenant un jeu d'instructions qui, lorsqu'il est exécuté par des moyens de traitement, est propre à mettre en œuvre le procédé selon l'une des revendications précédentes pour l’échange de messages entre des processus réalisant des opérations parallèles du

5 programme au sein d'un calculateur haute performance.
9. Calculateur haute performance distribué comportant une grappe de nœuds de calcul (10) ayant des ressources physiques pour exécuter chacun un processus d’un travail de manière indépendante d’autres processus exécutés en parallèle par d’autres nœuds de calcul du calculateur, et des moyens aptes à
10 gérer l’échange de messages entre lesdits processus selon le procédé de l’une quelconque des revendications 1 à 7.

1/4 ^---- J l

J l

J l