Nombre d'entre vous ont suivi la création d'un nouveau cluster supercalculateur à base de Power Mac G5 en septembre 2003 par l'université technologique de Virginie. J'imagine que ce projet a du faire de nombreux envieux. Effectivement les performances ont permis à Terascale (le nom de ce cluster) de se positionner à la troisième place du top 500 des supercalculateurs (voir le site Top500.org).
A son lancement ce supercalculateur fournissait la puissance de 7,6 Tflops réelle (7600 milliards d'opérations flottantes par seconde) et l'équipe espère atteindre 13 à 14 Tflops. En novembre 2003, Terascale affiche 10,28 Tflops et devient le troisième supercalculateur à passer au-dessus de 10 Tflops. Pour donner une idée de la puissance des supercalculateurs, un Power Mac G5 monoprocesseur à 2Ghz fournit la puissance théorique de 8 Gflops (0.008 Tflops), un Athlon 600Mhz fournit 1 Gflops [si vous avez des infos sur les processeurs plus récents vous pouvez nous en faire part, Attention je parle de puissance théorique].

Ces projets se développent car les technologies sont arrivées à maturité : le prix des réseaux grande vitesse sont 'abordables' et la programmation parallèle après plus de 40 ans de recherche est utilisable et largement utilisée (ce dernier point peut faire l'objet d'un article, je n'ai pas les compétences pour développer cette partie, si quelqu'un souhaite partager ses connaissances qu'il n'hésite pas). En effet de nombreux logiciels et librairies sont disponibles dans des versions stables.

Ce que je propose ici est de définir le concept de cluster ce qui nous permettra d'expliquer les différences avec les grilles de calculs, et ensuite de détailler les fonctionnements des clusters supercalculateurs, à répartition de charge (très proche des supercalculateurs) et à haute-disponibilité. Mais avant cela nous devons expliquer pourquoi la puissance est basée sur le nombre d'opérations flottantes.

Pourquoi les flops ?

La question n'est pas anodine, car après tout les utilisateurs ont plus besoin des calculs sur les nombres entiers, avec entre autre les jeux. Les supercalculateurs sont destinés aux calculs scientifiques, or ceux-ci se font essentiellement avec des nombres flottants. Voici quelques exemples d'applications (ne me demandez pas de les expliquer s'il vous plaît) : dynamique des fluides visqueux, turbulences des fluides, structures biologiques, prévisions météo, modélisation des superconducteurs, etc...
(flops en anglais est la contraction de 'floating operations per second' qui se traduit par opérations flottantes par seconde).

Pour bien comprendre ce qui suit, je vous invite à lire l'article 'qu'est ce qu'un réseau ? ' car un cluster se définit par rapport au réseau et donc certaines notions sont nécessaires.

Schéma d'un cluster

Un cluster est le regroupement logique de plusieurs machines (parfois appelées 'noeuds') qui possède un réseau isolé. Nous parlons de regroupement logique car nous allons donner une seule adresse réseau (qui ne correspondra pas à une adresse MAC) pour l'ensemble des machines du cluster : cela signifie que pour les autres réseaux et machines, le cluster est vue comme une seule entité (la signature réseau du cluster est identique à celle d'une simple machine). Pour les besoins du cluster et pour éviter toute interférence, les machines sont reliées par un réseau spécifique qui ne possède pas de routeur. Seules les machines qui appartiennent au cluster peuvent emmètre des messages sur ce réseau. Il y a encore un point qui caractérise les clusters, c'est la surveillance continue ; le cluster connaît l'état de chacune des machines qui le composent.

Vous verrez parfois une définition plus souple vis à vis des caractéristiques d'un cluster. Par choix il peut être décidé de se passer de la supervision. J'ai lu un cas qui ne nécessite pas un isolement du réseau, et je vais vous dire pourquoi une telle définition ne me convient pas : Un cluster doit être indépendant des machines qui ne le composent pas. Avec un réseau isolé, si une machine hors du cluster sature le réseau (défaillance de la carte réseau par exemple), l'accès ne sera plus possible, mais le cluster continuera ces calculs. Dans le cas d'un réseau d'entreprise, si une machine (même hors du cluster) sature le réseau, nous perdrons toutes les fonctionnalités du cluster.
Donc pour résumer un cluster est caractérisé par une adresse IP, un réseau spécifique et une supervision.

Le but poursuivi pour la création d'un cluster est de disposer de plusieurs machines pour effectuer les tâches que les utilisateurs vont soumettre au cluster. Nous allons voir dans les chapitres suivant que ces machines ne sont pas utilisées de la même manière en fonction du type de cluster.

La grille de calculs est un concept 'nouveau' (d'après ce qu'ils disent), poussé entre autre par Oracle et Apple. Mais ces derniers proposent d'offrir au niveau de l'entreprise ce que des associations ont réalisé à un niveau international : le calcul distribué. Le projet SETI qui, pour la journée du 19/01/2004, totalisait une puissance de 69.04 Tflops pour 4 844 193 machines (cliquez ici pour les statistiques récentes du projet SETI ), et le Décrypthon sont des projets de calcul distribué. L'idée d'une grille de calculs est d'utiliser la puissance de tous les postes qu'une entreprise peut posséder.

Comment fonctionnent ces projets ?

Les utilisateurs laissent tourner un programme sur leur machine (appelé client) qui va chercher sur un serveur les données pour les prochains calculs à effectuer, fait les calculs et renvoie les résultats et ainsi de suite jusqu'à épuisement des données à traiter. Le projet SETI est toujours en cours (en phase 2), et le Décrypthon a totalisé 75 000 machines sur une durée de 52 jours. Apple propose un fonctionnement similaire avec son serveur Xgrid et des agents qui tourneront sur les postes de l'entreprise. Qui a parlé d'engorgement du réseau ? :)

Schéma d'exécution de calculs distribués

Nous voyons ici qu'une grille de calculs n'a pas d'adresse IP, le réseau est global (pour SETI ou le Décrypthon c'est Internet, pour une entreprise ce sera l'ensemble de son réseau) et il n'y a bien sûr pas de supervision. La signature réseau d'une grille de calculs est l'ensemble des machines qui travaillent pour la grille. L'architecture mise en oeuvre est bien différente de celle des clusters. Ainsi pour les grilles nous parlons de calculs distribués, en revanche pour les clusters nous parlons de calculs parallèles.

Donc s'il vous plaît, ne confondons pas les grilles de calculs et les clusters.

Ce type de cluster a pour but de fournir un ou plusieurs services sans interruption d'aucune sorte. Nous n'avons jamais 100% de disponibilité, toutefois l'ordre de grandeur est tout de même supérieur à 99% (la partie décimale est très importante). Nous allons voir comment le cluster permet l'accès aux services proposés. Pour mieux me faire comprendre, je vais prendre un exemple concret : une base de données qui nécessite un accès continu.

En informatique si on prend 2 serveurs au matériel et aux paramétrages identiques les seules choses qui vont les différencier sont leur nom ou leur adresse réseau (les DNS permettent de passer de l'un à l'autre),et les données qui sont stockées sur les disques. Les adresses IP sont forcément différentes pour éviter les problèmes réseau.
Pour résoudre le problème des données, on pourrait jouer les requêtes des utilisateurs sur les deux serveurs, c'est-à-dire que les 2 serveurs pourraient répondre aux sollicitations des utilisateurs. Mais si un serveur se plante (bug logiciel par exemple), l'autre le fera aussi. On ne peut donc se satisfaire de cette solution.

La solution imaginée et proposée par de nombreux constructeurs est le cluster à haute disponibilité. Pour simplifier voyons la mise en place de ce cluster avec deux serveurs.

Schéma d'un cluster à haute disponibilité

Sur ce schéma vous pouvez voir que les disques des données sont externes, et sont accessibles par les deux serveurs (souvent par des liaisons en fibre optique). En effet la logique de déploiement de cette architecture suppose que l'on peut arrêter un des deux serveurs (pas forcément volontairement) sans que l'accès aux données ne soit perturbé. Nous ne pouvons donc pas confier les données à un serveur (les méthodes de recopie continue d'un serveur vers l'autre étant trop lourdes elles ne sont pas envisageables), celui-ci arrêté l'accès aux données se trouvant sur ses disques serait impossible.

Le cluster qui représente la couche logique de l'architecture se compose donc des deux serveurs S-a et S-b, des disques de données, et nous allons lui assigner une adresse réseau et un nom Cl-HD. Les utilisateurs pour accéder à la base s'adresseront à Cl-HD (et non aux serveurs S-a, S-b) ; pour les utilisateurs Cl-HD est une machine qui leur permet d'accéder aux données qu'ils désirent.

Et le fonctionnement dans tout ça ?

La théorie est assez simple : Au démarrage nous désignons un serveur, S-a par exemple, qui va prendre en charge les demandes accès à la base de données. Pour ce faire il va demander les disques de données, démarrer la base, et répondre aux messages réseau à destination du cluster.

Schéma d'exécution d'un cluster à haute disponibilité

Nous pourrions croire que le cluster tourne entièrement sur le serveur S-a, en fait la partie supervision du cluster s'exécute sur le serveur S-b : il surveille que le cluster est bien opérationnel. Pour cela des commandes permettent de tester les couches fonctionnelles du cluster (ici la base de données). La supervision par 'battement de coeur' (le serveur S-a envoie un signal régulièrement) peut être envisagée, mais ce système ne permet pas de valider toutes les couches fonctionnelles.
En cas de retour négatif de la supervision indiquant que le cluster n'est plus opérationnel sur le serveur S-a, le serveur S-b va tout d'abord émettre une alerte, puis réclamer les disques de données, démarrer la base, et répondre aux messages réseau à destination du cluster. Les administrateurs n'auront plus qu'à réparer le serveur S-a et le redémarrer en mode surveillance. Nous disons alors que le cluster a basculé sur le serveur S-b. Cette bascule automatique peut évidemment être réalisée à la demande pour une maintenance sur les serveurs.

Ce type de cluster est très utilisé pour les bases de données critiques.

Ici le cluster répond au besoin de puissance qu'une entreprise pourrait avoir, par exemple prenons une entreprise qui possède de nombreux clients et qui tous les mois doit fournir des factures. Le problème que rencontre l'entreprise est le temps d'exécution de la facturation mensuelle (calcul et génération du document pour l'impression), cette durée devant rester raisonnable. Comme les informations sont relatives à chaque client, la facturation est un problème facilement parallélisable pour des serveurs multiprocesseurs. Cependant, il arrive pour certaines entreprises qu'une seule machine ne suffise plus, le cluster à répartition de charge est alors une solution, l'idée étant assez simple : il suffit de répartir les calculs sur plusieurs machines (facile à dire).

Dans ce cas comme précédemment, nous limiterons à deux le nombre de noeuds du cluster, cela simplifiera les explications.

Schéma d'un cluster à répartition de charge

Cette solution nécessite encore des disques externes pour les données, et chacun des lots est accessible par les deux serveurs S-a et S-b. Le cluster est donc composé des deux serveurs S-a et S-b, des disques de données, et nous allons lui assigner une adresse réseau et un nom Cl-RC. Pour effectuer la facturation, nous demanderons à Cl- RC de l'exécuter.

Et le fonctionnement :

Pour chaque machine il y a deux modes de fonctionnement : maître ou esclave (de par le fonctionnement du cluster ces termes se sont imposés, je ne les ai pas choisis). En pratique un seul serveur est maître, tous les autres sont esclaves. Dans notre exemple, nous démarrerons le serveur S-a en tant que maître, S-b sera donc esclave. Pour ce faire, le serveur S-a réclamera une partie des données (les clients dont la première lettre est comprise entre 'A' et 'M'), démarrera la base de données associée, surveillera les serveurs esclaves (ici S-b), se chargera de répondre à tous les messages réseaux à destination du cluster. Jusque là il n'y a pas beaucoup de changement par rapport au cas précédent. Le serveur S-a devra de plus répartir les requêtes entre lui et S-b, en fonction du client concerné par la requête. Vous l'avez compris, le serveur S-b aura la charge des clients dont le nom commence par 'N' jusqu'à 'Z', il réclamera donc l'autre partie des données, attendra les ordres du serveur S-a et surveillera ce dernier. S-a peut être considéré comme un chef d'orchestre : chaque musicien a sa partition.

Schéma d'exécution d'un cluster à répartition de charge

La surveillance réciproque permet (comme pour les clusters à haute disponibilité) d'empêcher que l'arrêt d'un noeud du cluster ne le paralyse complètement. Le cluster va alors répartir les disques de données sur les serveurs restants, dans notre cas un seul serveur aura la charge du cluster dans sa totalité. Dans le cas ou le serveur maître tombe en panne, un serveur esclave prends sa place et son rôle (messages réseau et répartition du travail). Nous pourrions croire à de la haute disponibilité, mais le cluster mettra plus de temps pour effectuer les calculs demandés, nous parlons alors de fonctionnement en mode dégradé. Ce mode est aussi utilisé pour la maintenance en période de creux.

Ce n'est pas un calcul de ma part d'aborder en dernier le type de cluster qui intéresse le plus grand nombre d'entre vous, mais un souci de cohérence pour l'article. En effet un cluster supercalculateur est à une autre échelle un mélange des deux types précédemment vus dans cet article. Ces clusters ont pour but de fournir une puissance de calcul énorme aux projets scientifiques présents.
Tous les supercalculateurs sont qualifiés de systèmes fortement liés (tightly-coupled) en opposition avec les systèmes distribués, cela nous rappelle la différence que nous avons faite entre les grilles de calculs et les clusters. La liaison entre les machines peut aller jusqu'au partage de la mémoire vive. Les concepteurs du cluster Terascale ont choisi de créer un système fortement lié à mémoire distribuée (tightly- coupled distributed memory parallel system), c'est-à-dire que chaque machine gère sa mémoire indépendamment des autres. Voyons la technologie qui permet ce choix.

Le 'Message Passing Interface' ou MPI :

Nous allons juste présenter ce qu'est l'interface de passage des messages et non décortiquer cette librairie. Oui les programmeurs auront compris de quoi il s'agit, c'est un ensemble de méthodes permettant l'utilisation de plusieurs machine grâce à l'échange de messages qui prend la forme d'un fichier librairie (mpi.h). Ces méthodes sont intégrées dans le code source des applications qui doivent tourner sur le cluster.

Suivons donc les différentes étapes pour lancer un programme sur un cluster en utilisant le MPI. Tout d'abord les programmeurs doivent intégrer les méthodes fournit par le MPI dans le code du programme et le compiler sur une machine. L'exécutable issu de cette compilation est ensuite mis à disposition des machines (par envoie, ou par dépôt dans une zone partagée). Enfin le programme est lancé depuis la première machine à l'aide d'un outil fournit avec la librairie mpi qui va demander au travers des messages l'exécution du programme à toutes les machines. Nous avons là un fonctionnement maître Cette technique donne un rang (un numéro) à chaque machine, il est alors possible de distribuer les taches à accomplir en fonction du rang de la machine.

Je n'irai pas plus loin dans cette description, ce n'est pas le sujet de cet article, le but ici est de comprendre son mécanisme (je vous laisse parcourir le forum associé où mechizedek donne un exemple). Le cluster Terascale utilise l'écriture spécifique du MPI à la technologie Infiniband : MVAPICH.

Le cluster Terascale ou system X

Je n'ai pas trouvé de schémas du cluster Terascale, je vous propose donc de construire le schéma d'exécution avec les informations que nous donne l'université de Virginie. Il y a 1100 machines pour les calculs (ceux qui sont les esclaves, bases nodes en anglais), 4 machines maîtres (head nodes) et une machine pour la surveillance. De là à dire que chaque machine maître dirige 275 noeuds il n'y a qu'un pas que je ne ferai pas. En effet, l'université met en avant la grande adaptabilité de leur cluster, la possibilité d'avoir simultanément un environnement de production et du code en développement, mais aussi la possibilité de fournir une puissance de calcul en fonction du soutien (financier) du demandeur ; ces trois points permettent de dire que chacune des 4 machines maitres peut utiliser la totalité des machines esclaves, ainsi en fonction des projets le programme tournera sur un nombre de machines prédéfini (en se basant sur les rangs des machines). Je vous propose donc le schéma d'exécution suivant, l'exemple prend en compte cinq projets :

Schéma probable d'exécution du cluster Terascale

La gestion des données :

Cette partie n'est pas spécifique au cluster Terascale, d'ailleurs ils ne sont pas très loquaces sur cette question, la raison est sans doute que la solution va dépendre du projet. En effet La problématique est de fournir les données nécessaires pour les calculs (nous les qualifierons de données source), et d'enregistrer les résultats. Les choix de solutions peuvent dépendre de la granularité (fine ou grosse) des données source. Une granularité est dite fine si la taille de chaque donnée source est petite, et inversement elle sera qualifier de grosse si la taille de chaque donnée source est volumineuse.

• Dans le cas de petits paquets de données, la technologie de l'interface de passage des messages est très appropriée pour cela, nous pouvons très bien imaginer de passer les données sources avec l'ordre d'exécution du programme. La machine maître distribuera les ordres d'exécution et les données.

• Dans le cas de paquets de données volumineux, le MPI peut très bien s'en charger, mais d'autres configurations ont été imaginées. Qui dit données, dit aussi base de données. Le premier choix qui peut être fait c'est d'intégrer la base de données dans le cluster. Cela peut très bien être réalisé en dédiant quelques machines du cluster à cette tache (souvent architecturées en haute-disponibilité). Les autres machines du cluster (qui font de la répartition de charge) demanderont les données a ces machines. La seconde possibilité est de placer la base en dehors du cluster. Dans ce cas soit la machine maître redistribue les données, soit chaque machine esclave va réclamer sont lots de données.

• quelque soit la taille des paquets de données, la solution suivante est réalisable : une zone de stockage est partagée entre tous les noeuds du cluster. Cet espace est appelé quorum.

Pour l'enregistrement des résultats, le cluster peut très bien utiliser ces propres disques (Terascale dispose de 176 To par exemple), ou choisir une des solutions appliquées pour les données source.

Un exemple devrait nous être présenté cette année par l'entreprise CRAY qui a une longue expérience dans les supercalculateurs. Ils ont choisi pour le supercalculateur 'Red Storm' le MPI et l'intégration des bases de données dans le cluster. Voici le schéma de l'architecture :

Schéma du cluster Red Storm

A quand les clusters familiaux ?

Si vous avez la chance de posséder plusieurs machines, vous les avez sans doute déjà reliées en réseau et vous vous dites qu'il serait bon d'utiliser la puissance de toutes ces machines à l'image des supercalculateurs. C'est actuellement réalisable avec par exemple un cluster Beowulf tournant sur Linux. Ne vous précipitez pas trop, car ce type de solution est très dépendant de la qualité du réseau que vous possédez. Par exemple vous voulez compresser en Ogg vos disques personnels (pour les écouter avec votre baladeur pas pour les diffuser sur Internet bien sûr), vous vous dites que chaque machine peut compresser un morceau dans son coin, le problème est que les informations à fournir doivent passer sur votre réseau, et un fichier wav extrait d'un disque avant compression est assez lourd (80 Mo) et le transfert pourrait être aussi long que le compresser directement.

De plus, pour vraiment utiliser toutes les possibilités de vos machines, il faudra comme pour le cluster Terascale, développer spécifiquement les applications. Ce dernier point n'est évidemment pas à la portée de tout le monde.

Que dire de plus ? Si une précision à propos des techniques mises en oeuvre pour les clusters et les grilles de calculs : Ces techniques ont le même but, sont très proches et vont sans doute fusionner si ce n'est pas déjà fait. Je ne remets pas en cause le chapitre sur les grilles de calculs, je souhaite juste attirer votre attention sur le fait que la différence se fait plus sur la partie physique que la partie logique des architectures (essentiellement la partie réseau).
A la vue du prix pour le cluster Terascale (5,2 millions de dollars), des performances qu'il fournit et de la modularité affichée par les concepteurs, il est fort probable de voir arriver de nouveaux clusters d'ici peu.

Vous voilà arrivez à la fin de cet article, j'espère que vous avez eu plaisir à le lire. Merci de votre attention et si vous pensez que des précisions doivent être ajoutées, n'hésitez pas à utiliser le forum dédié à cet article.