Cette section tente de donner un aperçu de ce qu'est le traitement parallèle en cluster sous Linux. Les clusters sont, actuellement, à la fois l'approche la plus populaire et la plus variée, en s'étendant du simple réseau de stations de travail (Network Of Workstations : NOW) aux machines en parallèle essentiellement construites sur mesure, et dans lesquelles il arrive que l'on trouve comme éléments des PC sous Linux. Il existe également un grand nombre de logiciels pouvant prendre en charge le calcul en parallèle dans des clusters de machines Linux.
Le traitement en parallèle au travers d'un cluster offre plusieurs avantages majeurs :
Chacune des machines d'un cluster peut être un système complet, utilisable avec une large gamme d'applications de calcul. Cela conduit beaucoup de gens à suggérer l'idée que ce type de cluster pourrait faire usage de tous les « cycles machine perdus » sur les ordinateurs tournant à ne rien faire dans les bureaux. Il n'est pas si facile de récupérer ces cycles, et cela risque de ralentir l'écran de veille de votre collègue, mais cela peut être fait.
L'explosion actuelle des systèmes en réseau signifie que la plupart du matériel nécessaire à la construction d'un cluster se vend déjà en grande quantité et aux prix réduits inhérents à la « grande distribution ». On peut encore augmenter les économies en partant du principe qu'une seule carte vidéo, un seul moniteur et un seul clavier soient nécessaires pour chaque cluster (bien qu'il vous faille tout de même les passer d'une machine à une autre pour faire l'installation initiale de Linux, une fois lancé, un PC sous Linux typique n'a pas besoin de « console »). En comparaison, les systèmes SMP et processeurs auxiliaires représentent des marchés plus réduits, tendant à proposer des prix plus élevés par performances à l'unité.
Les calculateurs en cluster peuvent évoluer en de très grands systèmes. Alors qu'il est actuellement difficile de trouver un ordinateur SMP à plus de quatre processeurs qui soit compatible avec Linux, la plupart du matériel réseau disponible permet de bâtir facilement un cluster incluant jusqu'à 16 machines. Avec un peu d'huile de coude, on peut mettre en réseau des centaines voire des milliers de machines. En fait, Internet tout entier pourrait être assimilé à un seul immense cluster.
Le fait que remplacer une « mauvaise machine » au sein d'un cluster soit une opération triviale comparé à la réparation d'un ordinateur SMP partiellement défaillant assure une disponibilité bien plus élevée aux configurations de cluster soignées. Cela devient important non seulement pour les applications qui ne peuvent tolérer des interruptions de service trop importantes, mais aussi dans l'utilisation en général de systèmes qui contiennent un nombre suffisant de processeurs pour que la panne d'une machine en particulier soit assez courante (par exemple, même si la durée moyenne avant la première panne d'un PC est environ deux ans, dans un cluster de 32 machines, la probabilité qu'au moins une machine tombe en panne dans les six premiers mois est assez élevée).
Très bien. Si les clusters sont gratuits ou très peu onéreux, peuvent devenir très grands et offrir une haute disponibilité… pourquoi tout le monde n'utilise pas un cluster ? Eh bien, parce qu'il y a aussi des problèmes :
À quelques exceptions près, le matériel réseau n'est pas conçu pour le traitement en parallèle. Typiquement, les temps de latence sont élevés et la bande passante réduite comparés aux systèmes SMP et processeurs auxiliaires. Par exemple, si les temps de latence d'un SMP n'excèdent généralement pas plus de quelques microsecondes, ils atteignent couramment des centaines, voire des milliers de microsecondes dans un cluster. La bande passante des communications dans un système SMP dépasse souvent 100 mégaoctets par seconde. Bien que le matériel réseau le plus rapide (c'est-à-dire le « Gigabit Ethernet ») présente une vitesse comparable, la plupart des réseaux sont de 10 à 1000 fois plus lents. La performance d'un matériel réseau est déjà suffisamment médiocre dans un cluster isolé. Si le réseau n'est pas isolé du reste du trafic, ce qui est souvent le cas lorsque l'on utilise des « machines qui sont en réseau » plutôt qu'un système conçu pour être un cluster, les performances peuvent être bien pires encore.
La gestion logicielle des clusters en
tant que système unique est très mince. Par exemple, la commande
ps
ne fait état que des processus s'exécutant sur un
seul système Linux, pas des processus s'exécutant à travers le
cluster Linux entier.
Moralité, les clusters ont un très grand potentiel, mais ce potentiel risque d'être très difficile à concrétiser pour la plupart des applications. La bonne nouvelle, c'est qu'il existe un soutien logiciel très développé pour vous aider à obtenir de bonnes performances avec les programmes adaptés à cet environnement, et qu'il existe également des réseaux conçus spécialement pour élargir la palette de programmes pouvant avoir de bonnes performances.
Les réseaux informatiques sont en pleine explosion… mais vous le savez déjà. Un nombre toujours grandissant de technologies et produits réseau a été développé, et la plupart d'entre eux sont disponibles sous une forme qui peut être utilisée pour faire d'un groupe de machines (des PC fonctionnant chacun sous Linux) un cluster de traitement en parallèle.
Malheureusement, aucune technologie réseau ne résout complètement tous les problèmes. À vrai dire, le nombre d'approches différentes, en coût et en performances, est à première vue assez difficile à croire. Par exemple, le coût par machine mise en réseau s'étend de moins de 5 dollars jusqu'à plus de 4000. La bande passante et les temps de latence varient aussi selon quatre ordres de grandeur.
Avant d'en apprendre plus sur les spécificités de certains réseaux, il est important de remarquer que ces choses évoluent très fréquemment (voir http://www.linux.org.uk/NetNews.html pour avoir des nouvelles fraîches concernant les réseaux sous Linux), et qu'il est très difficile d'obtenir des infos précises concernant certains réseaux.
J'ai placé un « ? » aux endroits
incertains. J'ai aussi passé beaucoup de temps à faire des recherches
sur ce sujet, mais je reste sûr que ce résumé est plein d'erreurs et
d'omissions importantes. Si vous avez des corrections ou des ajouts à y
apporter, merci de m'envoyer un courrier électronique en anglais à
l'adresse Hank Dietz <hankd CHEZ engr POINT uky POINT edu>
.
Les résumés comme le LAN Technology Scorecard[10] donnent les caractéristiques de nombreux et différents types de réseaux et de standards de réseaux locaux (LAN). Cependant, l'essentiel de ce guide pratique est centré sur les propriétés les plus indiquées à la construction d'un cluster Linux. Chaque section décrivant un type de réseau débute par une courte liste de caractéristiques. Ci dessous, la définition de chaque entrée.
Si la réponse est non, la signification est claire. Les autres réponses tentent de décrire l'interface de base utilisée pour accéder au réseau. La plupart du matériel réseau est interfacé via un pilote de périphérique du noyau, sachant typiquement gérer les communications TCP/UDP. D'autres réseaux utilisent des interfaces plus directes (par exemple des bibliothèques) pour réduire les temps de latence en évitant d'avoir à passer par le noyau.
Il y a quelques années, il était considéré comme parfaitement acceptable d'accéder au coprocesseur mathématique (« floating point unit ») par un appel système mais aujourd'hui, c'est clairement ridicule. A mon avis, nécessiter un appel système pour chaque communication entre les processeurs exécutant un programme en parallèle est peu commode. Le problème est que les ordinateurs n'ont pas encore intégré ces mécanismes de communication, et que les approches non « orientées noyau » tendent à présenter des problèmes de portabilité. Vous allez entendre beaucoup parler de ce sujet dans un avenir proche, principalement sous la forme de la nouvelle Virtual Interface (VI) Architecture (http://www.intel.com/intelpress/sum_via.htm) méthode standardisée pour les opérations des interfaces réseau et servant à contourner les couches des systèmes d'exploitation usuels. Le standard VI est appuyé par Compaq, Intel et Microsoft, et aura assurément un impact important sur la conception des SAN (System Area Network) dans les prochaines années.
C'est le chiffre dont tout le monde se soucie. J'ai généralement repris les débits maximum théoriques. Votre moyenne, elle, va varier.
A mon avis, c'est le chiffre dont tout le monde devrait se soucier, plus encore que de la bande passante. Là encore, j'ai utilisé les (irréalistes) valeurs théoriques idéales, mais au moins ces nombres prennent en compte toutes les sources de latence, tant logicielles que matérielles. Dans la plupart des cas, les temps de latence réseau ne durent que quelques microsecondes. Des nombres beaucoup plus grands reflètent les couches des matériels et logiciels inefficaces.
Reprise telle quelle, cette ligne décrit la forme sous laquelle vous pouvez acquérir ce type de matériel. Le matériel de la grande distribution est disponible largement et de plusieurs fabricants, le prix étant alors le premier critère de choix. Les choses proposées par « différents fabricants » sont disponibles chez plus d'un seul concurrent, mais il existe des différences significatives, et des problèmes potentiels d'interopérabilité. Les réseaux produits par un « fabricant exclusif » vous laissent à la merci de ce fournisseur, aussi bienveillant soit-il. « Domaine public » signifie que même si vous ne pouvez trouver quelqu'un pour vous vendre ce type de matériel, vous ou n'importe qui d'autre pouvez acheter les composants et en fabriquer un exemplaire. C'est typiquement le cas de prototypes de recherche. Ils ne sont en général ni prêts à être utilisés par le public, ni disponibles à celui-ci.
La manière dont on relie l'interface réseau à l'ordinateur. Les meilleures performances (et désormais les plus courantes) s'obtiennent avec le bus PCI. Il existe aussi des cartes pour bus EISA, VESA local bus (VLB), et ISA. ISA fut le premier, et il est toujours utilisé par les cartes aux basses performances. On trouve toujours l'EISA comme bus secondaire dans les machines PCI. Ces derniers temps, on ne trouve plus beaucoup de matériel à base de VLB (même si la Video Electronics Standards Association voit les choses autrement).
Bien sûr, toute interface que vous pouvez utiliser sans avoir à ouvrir le boîtier de votre PC est plus qu'attrayante. les interfaces IrDA (N.D.T. : port infrarouge) et USB font leur apparition de plus en plus fréquemment. Le Port Parallèle Standard (SPP) est longtemps resté « ce sur quoi vous branchiez votre imprimante », mais s'est avéré dernièrement être très utile comme extension du bus ISA. Cette nouvelle fonction est améliorée par le standard IEEE 1284, qui spécifie les optimisations EPP et ECP. Il y a aussi le bon vieux port série RS232, lent mais fiable. Je n'ai eu vent d'aucun témoignage concernant l'interconnexion de machines par le biais des connecteurs vidéo (VGA), clavier, souris ou joystick…
Un bus est un fil, un ensemble de fils, ou une fibre (optique). Un hub (« concentrateur » ou « plaque tournante ») est une petite boite qui peut recevoir différents types de fils ou de fibres. Les commutateurs (« switched hubs ») permettent à plusieurs connexions de transmettre activement et simultanément leurs données.
Voici comment lire ces nombres. Supposons que, en dehors des connexions réseau, acheter un PC comme unité de votre cluster vous coûte 2000 dollars. L'ajout de Fast Ethernet porte le prix à l'unité à environ 2400 dollars. L'ajout de Myrinet mène ce prix à 3800 dollars environ. Si vous avez 20 000 dollars à dépenser, vous pouvez alors avoir soit 8 machines reliées par du Fast Ethernet, soit 5 machines reliées par du Myrinet. Il est également très raisonnable d'utiliser plusieurs types de réseaux. Par exemple, avec 20 000 dollars, vous pouvez vous offrir 8 machines reliées entre elles par Fast Ethernet et TTL_PAPERS. Choisissez un réseau — ou un ensemble de réseaux — qui permettra à votre cluster d'exécuter votre application le plus rapidement possible.
Au moment où vous lirez ces lignes, ces chiffres seront faux… En fait, ils le sont sûrement déjà. Il peut aussi y avoir un grand nombre de réductions, d'offres spéciales, et cætera. Mais en tout cas, les prix cités ici ne seront jamais suffisamment erronés pour vous conduire à faire un choix totalement inapproprié. Nul besoin d'avoir un doctorat (même si c'est mon cas ;-) pour constater que l'utilisation de réseaux onéreux n'a de sens que si votre application a réellement besoin de leurs propriétés ou si les PC utilisés dans votre cluster sont eux aussi relativement chers.
Maintenant que vous êtes avertis, place au spectacle…
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : 2,5 Mbits/s
Temps de latence minimum : 1000 microsecondes ?
Disponibilité : différents fabricants
Port ou bus utilisé : ISA
Structure du réseau : Hub ou bus non commutés (anneau logique)
Coût par machine reliée : 200 dollars
ARCNET est un réseau local principalement destiné à être utilisé dans les systèmes de contrôle temps réel embarqués. Comme Ethernet, le réseau est physiquement organisé en prises le long d'un bus d'un ou plusieurs hubs. En revanche, et contrairement à Ethernet, il utilise un protocole à base de jetons qui structure de manière logique le réseau comme un anneau. Les entêtes des paquets sont réduites (3 ou 4 octets) et les messages peuvent être très courts (jusqu'à un seul octet). De fait, ARCNET est plus efficace qu'Ethernet. Malheureusement, il est aussi plus lent, et moins populaire ce qui le rend plus cher. Vous trouvez plus d'informations sur le site de l'ARCNET Trade Association.
Prise en charge par Linux : pilotes du noyau, bibliothèques AAL*
Bande passante maximum : 155 Mbits/s (bientôt, 1200 Mbits/s)
Temps de latence minimum : 120 microsecondes
Disponibilité : différents fabricants
Port ou bus utilisé : PCI
Structure du réseau : hubs commutés
Coût par machine reliée : 3000 dollars
A moins d'avoir été dans le coma ces dernières années, vous avez sûrement beaucoup entendu dire qu'ATM (« Asynchronous Transfer Mode ») est l'avenir… Eh bien, en quelque sorte. ATM est meilleur marché que HiPPI et plus rapide que Fast Ethernet, et il peut être utilisé sur de très longues distances, ce qui intéresse beaucoup les opérateurs téléphoniques. Le protocole du réseau ATM est également conçu pour fournir une interface logicielle aux temps d'accès réduits et gérant plus efficacement les messages courts et les communications en temps réel (c'est-à-dire les transmissions audio et vidéo numériques). C'est aussi l'un des réseaux aux plus hauts débits que Linux prenne actuellement en charge. La mauvaise nouvelle, c'est qu'ATM n'est pas vraiment bon marché, et qu'il demeure encore des problèmes de compatibilité entre fabricants. Un aperçu du développement ATM sous Linux est disponible sur http://linux-atm.sourceforge.net/.
Prise en charge par Linux : bibliothèque AFAPI
Bande passante maximum : 1,2 Mbit/s
Temps de latence maximum : 3 microsecondes
Disponibilité : grande distribution
Port ou bus utilisé : SPP (port parallèle)
Structure du réseau : câble entre 2 machines
Coût par machine reliée : 2 dollars
CAPERS (« Cable Adapter for Parallel Execution and Rapid Synchronisation » : « Adaptateur par Câble pour l'Exécution en Parallèle et la Synchronisation Rapide ») est un produit dérivé du projet PAPERS, de l'University School of Electrical and Computer Engineering de Purdue. En substance, ce projet définit un protocole logiciel permettant d'utiliser une simple liaison point-à-point par le port parallèle, type « LapLink », pour implémenter la bibliothèque PAPERS sur deux PC sous Linux. L'idée n'est exploitable à grande échelle, mais le prix est imbattable. Tout comme avec TTL_PAPERS, pour améliorer la sécurité du système, il est recommandé, mais pas nécessaire, d'appliquer un correctif mineur au noyau.
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : 10 Mbits/s
Latence minimum : 100 microsecondes
Disponibilité : grande distribution
Port ou bus utilisé : PCI
Structure du réseau : commutateurs ou concentrateurs, ou même bus simple
Coût par machine connectée : 100 dollars (sans concentrateur, 50 dollars)
Depuis plusieurs années maintenant, l'Ethernet à 10Mbits/s est le standard des technologies réseau. Une bonne carte Ethernet s'achète pour moins de 50 dollars, et bon nombre de PC en sont aujourd'hui équipés de série, l'interface étant intégrée à la carte-mère. Les réseaux à base Ethernet dont la charge n'est pas très élevée peuvent être organisés comme un long bus à prises multiples sans concentrateur (« hub »). Une telle configuration peut servir jusqu'à 200 machines pour un coût minimal, mais n'est pas appropriée au traitement en parallèle. Ajouter un concentrateur non commuté n'améliore pas beaucoup les performances. En revanche, les commutateurs (« switches »), qui peuvent offrir une bande passante maximum à plusieurs connexions simultanément ne coûtent qu'aux alentours de 100 dollars par port. Linux prend en charge un nombre impressionnant d'interfaces Ethernet différentes, mais il est important de garder à l'esprit que les variations entre ces matériels peuvent engendrer de grandes différences de performance. Consultez le Guide pratique de la compatibilité matérielle avec Linux (N.D.T. : version française du Hardware Compatibility HOWTO ) pour plus d'informations concernant les différents équipements fonctionnant sous Linux, et pour avoir une idée de leur qualité.
Le cluster Linux à 16 machines réalisé dans le cadre du projet « Beowulf » (initialement développé au CESDIS de la NASA) est une manière intéressante d'augmenter ses performances. C'est à Donald Becker, auteur de plusieurs pilotes de cartes Ethernet, que l'on doit la prise en charge de la répartition du trafic au travers de plusieurs cartes réseau s'éclipsant mutuellement (autrement dit, partageant les mêmes adresses réseau). Cette fonction est intégrée en standard dans Linux, et s'effectue de manière invisible en dessous du niveau des opérations sur les sockets. Le coût d'un hub n'étant pas négligeable, relier chaque machine à deux (ou plus) réseaux Ethernet, sans hubs ni switches, pour améliorer les performances peut s'avérer financièrement très rentable. D'une manière générale, dans les situations où une machine est le goulet d'étranglement d'un réseau, la répartition de charge à travers plusieurs réseaux (« shadow networks ») se révèle bien plus efficace que l'usage d'un réseau équipé d'un commutateur seul.
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : 100 Mbits/s
Temps de latence minimum : 80 microsecondes
Disponibilité : grande distribution
Port ou bus utilisé : PCI
Structure du réseau : concentrateurs ou commutateurs (hubs ou switches)
Coût par machine connectée : 400 dollars (?)
Bien qu'il existe un certain nombre de technologies différentes nommées « Fast Ethernet », elles se réfèrent souvent à un réseau Ethernet 100 Mbits/s en grande partie compatible avec les anciens câbles et périphériques 10 Mbits/s type « 10 BaseT ». Comme on peut s'y attendre, tout ce qui s'appelle Ethernet bénéficie des prix de la vente de masse, et ces interfaces ne coûtent généralement qu'une fraction du prix des cartes ATM à 155 Mbits/s. Le problème est qu'une collection de machines partageant tous le même « bus » à 100 Mbits/s (à l'aide d'un hub non commuté) peut présenter des performances n'atteignant en moyenne même pas celles d'un réseau 10 Mbits/s utilisant un commutateur fournissant à chaque machine une connexion 10 Mbits/s complète.
Les commutateurs pouvant fournir une connexion 100 Mbits à chaque machine simultanément sont chers, mais les prix chutent chaque jour, et ces commutateurs offrent une bande passante autrement plus élevée que de simples hubs non commutés. Ce qui rend les commutateurs ATM si onéreux est la nécessité de commuter chaque cellule ATM, cellule relativement courte. Certains commutateurs Ethernet parient sur une fréquence de commutation attendue relativement lente et en tirent profit en utilisant des techniques aux temps de latence réduits à l'intérieur du commutateur, mais nécessitant quelques millisecondes pour changer de voie. Si l'itinéraire de votre trafic réseau change fréquemment, évitez ce type d'équipement.
Notez aussi que, comme pour Ethernet, le projet Beowulf (http://www.beowulf.org) de la NASA développe des pilotes aux performances supérieures car utilisant la répartition de charge entre plusieurs cartes Fast Ethernet.
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : 1000 Mb/s
Temps de latence minimum : 300 microsecondes (?)
Disponibilité : différents fabricants
Port ou bus utilisé : PCI
Structure réseau : commutateurs ou FDR
Coût par machine connectée : 2500 dollars (?)
Je ne suis pas sûr que Gigabit Ethernet ait une raison technologique valable de s'appeler Ethernet… mais son nom inspire le fait que Gigabit Ethernet est conçu pour être une technologie réseau bon marché et de grande distribution, avec une prise en charge native de l'IP. En revanche, les prix actuels reflètent le fait que cela reste un produit difficile à fabriquer.
Contrairement aux autres technologies Ethernet, Gigabit Ethernet apporte un contrôle du flux, ce qui devrait en faire un réseau plus fiable. Les FDR, ou « Full-Duplex Repeaters » (« répéteurs bidirectionnels simultanés »), se contentent de multiplexer les lignes, en utilisant des mémoires tampons et des contrôles de flux localisés pour améliorer les performances. La plupart des commutateurs sont construits comme de nouveaux modules pour les différents modèles de commutateurs compatible Gigabit déjà existants. Les commutateurs ou FDR sont distribués ou annoncés par au moins Acacianet, Bay networks, Cabletron (désormais Enterasys. Page française : http://www.enterasys.com/fr/), Networks digital, Extreme networks, Foundry networks, Gigalabs.com, Packet engines. Plaintree systems, Prominet, Sun microsystems, et Xlnt.
Il existe un pilote pour Linux pour les « Yellowfin » G-NIC de Packet Engines[11]. Les premiers essais sous Linux ont fait état d'un taux de transfert environ 2,5 fois supérieur à la plus rapide des cartes Fast Ethernet à 100 Mbits/s. Avec les réseaux Gigabit, une configuration soigneuse du bus PCI est un facteur critique. Il reste toujours un doute quant à la poursuite des améliorations de ce pilote, et du développement des pilotes Linux des autres cartes réseau.
Prise en charge par Linux : non[12]
Bande passante maximum : 1062 Mbits/s
Temps de latence minimum : ?
Disponibilité : différents fabricants
Interface ou bus utilisé : PCI (?)
Structure du réseau : ?
Coût par machine connectée : ?
L'objectif du FC (« Fibre Channel ») est de fournir un médium d'entrée/sortie de type bloc aux performances élevées (une trame FC transporte un bloc de données d'une longueur forfaitaire de 2048 octets), particulièrement adapté aux partages de disques et autres périphériques de stockage, qui peuvent alors être reliés directement au réseau FC plutôt qu'à travers un ordinateur. Niveau bande passante, le FC est présenté comme étant relativement rapide, avec un taux s'étendant de 133 à 1062 Mbits/s. Si le FC tend à devenir populaire en tant que solution haut-de-gamme de remplacement du SCSI, il pourrait rapidement devenir une technologie très abordable. Pour le moment, ce n'est pas abordable, et ce n'est pas pris en charge par Linux. La Fibre Channel Association tient une importante collection de références au FC, sur http://www.fibrechannel.org[13].
Prise en charge par Linux : non[14]
Bande passante maximum : 196,608 Mbits/s (bientôt, 393,216 Mbits/s)
Temps de latence minimum : ?
Disponibilité : différents fabricants
Interface ou bus utilisé : PCI
Structure du réseau : aléatoire, sans cycles (auto-configuré)
Coût par machine connectée : 600 dollars
FireWire, ou standard IEEE 1394-1995, est voué à être le réseau numérique à grande vitesse et à prix réduit des appareils électroniques domestiques. Son application-phare est la connexion des caméscopes numériques aux ordinateurs, mais FireWire est destiné à être utilisé dans des domaines s'étendant de l'alternative au SCSI jusqu'à l'interconnexion des différents composants de votre « Home Cinéma ». Il vous permet de relier plus de 64000 périphériques dans une topologie utilisant des bus et des ponts mais ne formant pas de boucle, et détecte automatiquement la configuration des périphériques lorsqu'ils sont ajoutés ou retirés. Les messages courts (les « quadlets », longs de quatre octets) sont également pris en charge, de même que les transmissions isochrones sur le modèle de l'ATM (utilisées pour préserver le synchronisme des messages multimédia). Adaptec propose des produits FireWire permettant de relier jusqu'à 63 périphériques à une seule carte PCI, et tient aussi un bon site d'information générale concernant le FireWire sur http://www.adaptec.com.
Bien que le FireWire ne soit pas le réseau le plus rapide disponible actuellement, le marché de la grande distribution (qui tire les prix vers le bas) et les temps de latence réduits pourraient en faire d'ici l'an prochain la meilleure interface réseau pour le message passing dans un cluster de PC sous Linux.
Prise en charge par Linux : non[15]
Bande passante maximum : 1600 Mbits/s (1200 Mb/s pour Serial HiPPI)
Temps de latence minimum : ?
Disponibilité : différents fabricants
Interface ou bus utilisé : EISA, PCI
Structure du réseau : commutateurs
Coût par machine connectée : 3500 dollars (4,500 dollars pour Serial HiPPI)
HiPPI (« High Performance Parallel Interface », soit « Interface Parallèle aux Performances Élevées ») était initialement censée fournir un taux de transfert élevé pour l'échange d'immenses blocs de données entre un supercalculateur et une autre machine (un autre supercalculateur, un « frame buffer », une batterie de disques, et cætera), et est devenu le standard dominant dans le monde des supercalculateurs. Bien que ce soit un oxymoron, Serial HiPPI devient également très populaire en utilisant typiquement de la fibre optique à la place des câbles HiPPI standard de 32 bits de large (donc parallèles). Ces dernières années, les commutateurs HiPPI en croix sont devenus courants et les prix ont sérieusement chuté. Malheureusement, les équipement HiPPI Série, eux, sont encore très onéreux, et sont en général les seuls pris en charge par le bus PCI. Pire, Linux ne gère pas encore HiPPI. Le CERN tient une bonne présentation d'HiPPI sur http://www.cern.ch/HSI/hippi/. Ils tiennent aussi une liste assez longue de distributeurs proposant le HiPPI sur http://www.cern.ch/HSI/hippi/procintf/manufact.htm.
Prise en charge par Linux : non (?)[16]
Bande passante maximum : 1,15 Mbits/s et 4 Mbits/s
Temps de latence minimum : ?
Disponibilité : Différents fabricants
Interface ou bus utilisé : IrDA
Structure réseau : Air libre ;-)
Coût par machine connectée : 0
L'IrDA (« Infrared Data Association » ou « Association de Données par Infrarouges », sur http://www.irda.org), c'est ce petit appareil à infrarouges sur le coté des ordinateurs portables. Il reste assez difficile, par conception, de relier plus de deux ordinateurs par ce biais, aussi l'IrDA ne se prête-t-il guère à la « clusterisation », ou mise en parallèle massive de nombreuses machines. Don Becker est toutefois l'auteur de quelques travaux préliminaires sur l'IrDA.
Prise en charge par Linux : bibliothèques
Bande passante maximum : 1280 Mbits/s
Temps de latence minimum : 9 microsecondes
Disponibilité : matériel propriétaire.
Interface ou bus utilisés : PCI
Structure du réseau : commutateurs
Coût par machine connectée : 1800 dollars
Myrinet est un réseau local (LAN : « Local Area Network ») conçu pour servir également de réseau système [17]. Les versions LAN et SAN utilisent des médias physiques distincts et leur caractéristiques sont sensiblement différentes. La version SAN est généralement utilisée au sein d'un cluster.
La structure de Myrinet est très conventionnelle, mais a la réputation d'être très bien implémentée. Les pilotes pour Linux sont connus pour donner de très bons résultats, bien qu'il eût été fait état de frappantes différences de performances d'une implémentation du bus PCI à l'autre.
Actuellement, Myrinet est assurément le réseau favori des responsables de clusters n'étant pas trop sévèrement limité au niveau budgétaire. Si, pour vous, un PC Linux typique est un Pentium Pro dernier cri ou un Pentium II avec au moins 256 Mo de mémoire vive, et un disque RAID et SCSI, alors le coût de Myrinet apparaît raisonnable. En revanche, avec des machines plus conventionnelles, il vous faudra probablement choisir entre relier N machines avec Myrinet, ou 2N machines avec plusieurs équipements de type « Fast Ethernet » ou « TTL_PAPERS ». Tout cela dépend réellement de votre budget et du type de calcul qui vous importe le plus.
Prise en charge par Linux : couches d'abstraction (« HAL ») ou bibliothèques réseau
Bande passante maximum : 125 Mbits/s
Temps de latence minimum : 2 microsecondes
Disponibilité : fabricant exclusif
Interface ou bus utilisé : PCI
Structure du réseau : maillage, sans concentrateur
Coût par machine connectée : plus de 1000 dollars
Le projet ParaStation (http://wwwipd.ira.uka.de/parastation) de la section informatique de l'Université de Karlsruhe est en train de mettre sur pieds un réseau « maison » compatible PVM et aux temps de latence réduits. Ils ont d'abord construit un prototype de ParaPC biprocesseur en utilisant une carte EISA conçue sur mesure et des PC fonctionnant sous Unix BSD, puis ont bâti de plus grands clusters composés de machines Alpha DEC. Depuis Janvier 1997, Parastation est disponible sous Linux. Les cartes PCI sont produites en coopération avec une société nommée Hitex. Le matériel de Parastation implémente à la fois un système de transmission de messages rapide et fiable, et des barrières de synchronisation simples.
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : 1,2 Mbits/s
Temps de latence minimum : 1000 microsecondes ?
Disponibilité : grande distribution
Interface ou bus utilisé : SPP
Structure du réseau : câble entre 2 machines
Coût par machine connectée : 2 dollars
Pour le seul coût d'un câble « LapLink » (N.D.T. : câble parallèle croisé), PLIP (« Parallel Line Interface Protocol », soit « Protocole d'Interface par Ligne Parallèle ») permet à deux machines Linux de communiquer par le port parallèle en utilisant les couches logicielles standard basées sur la communication par « sockets ». En termes de bande passante, de temps de latence et d'évolutivité, il ne s'agit pas d'une technologie réseau sérieuse. En revanche, le coût de revient quasi-nul et la compatibilité logicielle s'avèrent être très utiles. Le pilote est partie intégrante du noyau Linux standard.
Prise en charge par Linux : non
Bande passante maximum : 4000 Mbit/s
Temps de latence minimum : 2,7 microsecondes
Disponibilité : différents fabricants.
Interface ou bus utilisé : PCI et propriétaire
Structure réseau : ?
Coût par machine connectée : + de 1000 dollars
L'objectif de SCI (Scalable Coherent Interconnect, ANSI/IEEE 1596-1992) consiste essentiellement à fournir un mécanisme de haute performance pouvant assurer des accès cohérents à la mémoire partagée au travers d'un grand nombre de machines. On peut dire sans se mouiller que la bande passante et les temps de latences de SCI sont « très impressionnants » comparés à la plupart des autres technologies réseau. Le problème est que SCI n'est pas très répandu et reste donc assez onéreux, et que ce matériel n'est pas pris en charge par Linux.
SCI est principalement utilisé dans diverses implémentations propriétaires pour des machines à mémoire partagée logiquement et distribuée physiquement, comme le HP/Convex Exemplar SPP et le Sequent NUMA-Q 2000 (voir http://www.sequent.com[18]). Ceci dit, SCI est disponible sous forme de carte PCI et de commutateurs quatre ports de Dolphin (on peut relier ainsi jusqu'à 16 machines en montant ces commutateurs en cascade), http://www.dolphinics.com, sous la série "Clustar". Le CERN tient à jour une bonne collection de liens concernant SCI sur http://www.cern.ch/HSI/sci/sci.html.
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : de 5 Mbits/s à plus de 20 Mbits/s
Temps de latence minimum : ?
Disponibilité : différents fabricants
Interface ou bus utilisé : cartes PCI, EISA ou ISA
Structure du réseau : bus inter-machines partageant des périphériques SCSI
Coût par machine connectée : ?
Le SCSI (Small Computer Systems Interconnect) consiste essentiellement en un bus d'entrée/sortie utilisé par les disques durs, les lecteurs de CD-ROM, les numériseurs (« scanners »), et cætera. Il existe trois standards distincts : SCSI-1, SCSI-2 et SCSI-3, en vitesses "Fast" et "Ultra" et en largeur de bus de 8, 16 ou 32 bits (avec compatibilité FireWire annoncée pour SCSI-3). Tout cela est plutôt confus, mais nous savons tous qu'un bon SCSI est bien plus rapide que l'EIDE, et peut gérer plus de périphériques, plus efficacement.
Ce que beaucoup de gens ne réalisent pas, c'est qu'il est très simple de partager le même bus SCSI entre deux ordinateurs. Ce type de configuration est très utile pour partager des disques entre deux machines et mettre en place un système de fail-over, de façon à ce qu'une machine prenne à sa charge les requêtes à une base de données lorsque l'autre machine tombe en panne. C'est actuellement le seul mécanisme reconnu par le cluster PC de Microsoft : WolfPack. En revanche, l'incapacité du SCSI à évoluer vers de plus grands systèmes le rend en général inintéressant pour le traitement en parallèle.
Prise en charge par Linux : non
Maximum bandwidth : 400 Mbits/s
Temps de latence minimum : 3 microsecondes
Disponibilité : fabricant exclusif
Interface ou bus utilisé : PCI
Structure du réseau : arbre hexagonal / concentrateurs en mailles tétraédriques
Coût par machine connectée : ?
ServerNet est la solution réseau de haute performance proposée par Tandem (http://www.tandem.com). Dans le monde du traitement des transactions en ligne (« OnLine Transation Processing », ou « OLTP ») en particulier, Tandem est réputé être l'un des premiers fabricants de systèmes de haute fiabilité, aussi n'est-il pas surprenant que leurs réseaux ne revendiquent pas simplement la haute performance, mais aussi la « haute fiabilité et intégrité des données ». Une autre facette intéressante de ServerNet : ce matériel serait capable de transférer des données directement de périphérique à périphérique, pas simplement entre processeurs, mais également entre disques durs, et cætera, dans un style unilatéral similaire à ce qui a été suggéré pour les mécanismes d'accès à distance à la mémoire du MPI, décrits dans la section 3.5. Un dernier mot à propos de Servernet : Bien qu'il n'y ait qu'un seul fabricant, celui-ci est suffisamment puissant pour faire établir potentiellement Servernet en tant que standard majeur : Tandem appartient à Compaq[19].
Prise en charge par Linux : interface utilisateur à mémoire mappée
Bande passante maximum : 180 Mbits/s
Temps de latence minimum : 5 microsecondes
Disponibilité : prototype expérimental
Interface ou bus utilisé : EISA
Structure du réseau : Fond de panier en maille (comme pour le Paragon d'Intel)
Coût par machine connectée : ?
Le projet SHRIMP de la section des sciences des ordinateurs de l'Université de Princeton, met sur pieds un ordinateur parallèle en utilisant dont les éléments de traitement sont des ordinateurs PC sous Linux. Le premier SHRIMP (« Scalable, High-Performance, Really Inexpensive Multi-Processor », soit « multiprocesseur évolutif et de hautes performances vraiment bon marché ») était un simple prototype biprocesseur utilisant une mémoire partagée sur une carte EISA développée pour l'occasion. Il existe désormais un prototype pouvant évoluer vers de plus larges configurations en utilisant une interface « maison » pour se connecter à une sorte de concentrateur, essentiellement conçu comme le réseau de routage en mailles utilisé dans le Paragon d'Intel. Des efforts considérables ont été faits pour développer une électronique de « communication mappée en mémoire virtuelle » aux overheads réduits, avec sa couche logicielle.
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : 0,1 Mbits/s
Temps de latence minimum : 1000 microsecondes ?
Disponibilité : grande distribution
Interface ou bus utilisé : RS232C
Structure du réseau : câble entre deux machines
Coût par machine connectée : 2 dollars
Même si SLIP (« Serial Line Interface Protocol ») se situe définitivement au pied de l'échelle des performances, ce protocole (tout comme CSLIP ou PPP) permet à deux machines de communiquer en utilisant les « sockets » et ce au travers d'un câble RS232 ordinaire. Les ports RS232 peuvent être reliés à l'aide d'un câble série type NULL-MODEM, ou même au travers d'une ligne téléphonique en utilisant des modems. Dans tous les cas, les temps de latence sont élevés, et la bande passante réduite. Aussi, SLIP ne devrait être utilisé qu'en dernier recours. En revanche, la plupart des PC sont dotés de deux ports RS232. Il doit donc être possible de relier un groupe de machines sous forme de réseau linéaire ou d'anneau. Il existe même un logiciel de répartition de la charge appelé EQL.
Prise en charge par Linux : bibliothèque AFAPI
Bande passante maximum : 1,6 Mbits/s
Temps de latence minimum : 3 microsecondes
Disponibilité : conception dans le domaine public, fabricant exclusif
Interface ou bus utilisé : SPP (port parallèle)
Structure du réseau : arbre de concentrateurs
Coût par machine connectée : 100 dollars
Le projet PAPERS (« Purdue's Adapter for Parallel Execution and Rapid Synchronization », soit « Adaptateur pour l'Exécution en Parallèle et la Synchronisation Rapide de l'université de Purdue »), mené par la Purdue University School of Electrical and Computer Engineering (« École Supérieure d'Électricité et d'Ingénierie en Informatique »), développe un ensemble logiciel et matériel évolutif et aux temps de latence réduits pour les communications des fonctions d'agrégation, permettant de mettre sur pieds un supercalculateur en parallèle utilisant comme nœuds des PC d'origine, non modifiés.
Plus d'une douzaine de versions de cartes « PAPERS », reliées au PC à la station de travail via le port parallèle standard (SPP : « Standard Parallel Port »), ont été construites, en suivant globalement deux grands axes. Les versions estampillées « PAPERS » visent les hautes performances, quelle que soit la technologie la plus indiquée, la version actuelle utilisant des FPGA (N.D.T. : famille de réseaux logiques programmables), et des modèles d'interfaces PCI à haut débit sont actuellement à l'étude. Par opposition, les versions nommées « TTL_PAPERS » sont conçues pour être facilement reproduites hors de l'université de Purdue, et s'appuient sur des modèles du domaine public remarquablement simples et qui peuvent être mis en place en utilisant de la logique TTL ordinaire. L'une de ces versions est produite commercialement.
Contrairement au matériel sur mesure conçu par d'autres universités, des clusters TTL_PAPERS ont été assemblés dans plusieurs écoles depuis les États-Unis jusqu'en Corée du Sud. La bande passante est sévèrement limitée par la connectivité du port parallèle, mais PAPERS met en œuvre des fonctions d'agrégation aux temps de latence très réduits. Même les systèmes orientés messages les plus rapides ne peuvent offrir de telles performances sur ces fonctions d'agrégation. Ainsi, PAPERS est particulièrement performant dans la synchronisation des différents écrans d'un mur vidéo (à débattre dans le Video-Wall-HOWTO actuellement en préparation), pour planifier les accès à un réseau à haut débit, pour évaluer les probabilités en recherche génétique, et cætera. Même si des clusters PAPERS ont été construits en utilisant AIX d'IBM sur PowerPC, des DEC Alpha OSF/1, ou HP-UX sur HP PA-RISC, le PC sous Linux reste la plate-forme la mieux prise en charge.
Les programmes utilisateur utilisant l'AFAPI de TTL_PAPERS attaquent
directement les registres matériels du port parallèle sous Linux, sans
effectuer d'appel système à chaque accès. Pour ce faire, l'AFAPI demande
d'abord les droits d'accès au port parallèle en utilisant soit
iopl()
, soit ioperm()
. Le problème
est que, l'un comme l'autre, ces appels obligent le programme appelant à
être privilégié, ce qui introduit une faille de sécurité potentielle. La
solution réside en un correctif optionnel à appliquer au noyau Linux et
permettant à un processus privilégié de contrôler les permissions
d'accès aux ports d'entrée/sortie pour n'importe quel autre processus.
Prise en charge par Linux : pilotes du noyau
Bande passante maximum : 12 Mbits/s
Temps de latence minimum : ?
Disponibilité : dans le commerce
Interface ou bus utilisé : USB
Structure du réseau : bus
Coût par machine connectée : 5 dollars
USB (« Universal Serial Bus », http://www.usb.org) est un bus fonctionnant à la vitesse de l'Ethernet conventionnel, dont les périphériques qui s'y rattachent peuvent être connectés à chaud (« Hot-Plug » : sans imposer la mise hors tension du bus) et pouvant accueillir simultanément jusqu'à 127 de ces périphériques pouvant s'étendre du clavier à la caméra de vidéo-conférence. La manière dont on relie plusieurs ordinateurs par le biais de l'USB n'est pas clairement définie. Quoi qu'il en soit, les ports USB sont en train de s'établir très rapidement en standard sur les cartes-mères, au même titre que le port série RS232 ou le port parallèle, aussi ne soyez pas surpris si vous voyez apparaître un ou deux ports USB [20] sur votre prochain PC.
D'une certaine manière, l'USB est pratiquement la version basse performance à prix nul du FireWire que l'on peut se procurer aujourd'hui.
Prise en charge par Linux : bibliothèque AFAPI
Bande passante maximum : 0,4 Mbits/s
Temps de latence : 3 microsecondes
Disponibilité : modèle dans le domaine public
Interface ou bus utilisé : SPP (Port Parallèle Standard)
Structure du réseau : modèle de câblage entre 2 à 64 machines
Coût par machine connectée : 5 dollars
WAPERS (« Wired-AND Adapter for Parallel Execution and Rapid Synchronization », soit « Adaptateur par ET Câblé pour l'Exécution en Parallèle et la Synchronisation Rapide ») est une des facettes du projet PAPERS, de la Purdue University School of Electrical and Computer Engineering (« École Supérieure d'Électricité et d'Ingénierie en Informatique »). S'il est construit proprement, le port parallèle possède quatre bits de sortie à collecteur ouvert qui peuvent être câblés entre eux pour former un ET câblé de 4 bits de large. Ce ET câblé est assez sensible électriquement, et le nombre maximum de machines qui peuvent y être reliées dépend de façon critique des propriétés analogiques des ports (les limites maximum des puits de courant et les valeurs des résistances de pull-up). On peut typiquement relier 7 à 8 machines en réseau de cette façon, avec WAPERS. Bien que les coûts et les temps de latences soient très réduits, la bande passante l'est aussi. WAPERS est donc bien plus indiqué comme réseau secondaire dédié aux fonctions d'agrégations que comme unique réseau d'un cluster. Comme pour TTL_PAPERS, il existe un correctif noyau visant à améliorer la sécurité, recommandé mais non requis.
Avant d'explorer les ressources logicielles existantes en matière de traitement en parallèle, il est utile de couvrir rapidement les bases de l'interface logicielle de bas niveau gérant l'électronique du réseau. Il n'existe en réalité que trois options de base : les sockets, les pilotes de périphériques et les bibliothèques utilisateur.
Le socket est de loin la plus courante des interfaces réseau de bas niveau. Les sockets sont partie intégrante d'Unix depuis plus d'une décennie et la plupart des standards dans le domaine du matériel électronique de réseau est conçue pour prendre en charge au moins deux types de protocoles de socket : TCP et UDP. Ces deux types de sockets vous permettent d'envoyer des blocs de données d'une longueur arbitraire d'une machine à l'autre, mais il existe plusieurs différences importantes. Typiquement, ils engendrent tous deux un temps de latence minimum d'environ 1000 microsecondes, même si les performances peuvent bien pires encore en fonction du trafic.
Ces types de sockets constituent l'interface logicielle réseau de base pour la majorité des logiciels de traitement en parallèle portables et de plus haut niveau. Par exemple, PVM utilise une combinaison de l'UDP et du TCP, aussi en connaître les différences vous aidera à affiner les performances de votre système. Ce qui suit n'est qu'un aperçu de TCP et UDP. Référez-vous aux pages du manuel et à un bon livre de programmation pour plus de détails.
UDP signifie « User Datagram Protocol » ou « Protocole de Datagrammes Utilisateur » mais il est plus facile de se souvenir des propriétés d'UDP en tant que « Unreliable Datagram Processing », ou « Traitement des Datagrammes Peu fiable ». En d'autres termes, UDP permet à chaque bloc d'être émis comme un message individuel, mais un message peut être perdu pendant la transmission. De fait, selon l'état du trafic sur le réseau, certains messages UDP peuvent être perdus, arriver plusieurs fois, ou arriver dans un ordre différent de celui dans lequel ils ont été émis. L'expéditeur d'un message UDP ne reçoit pas systématiquement d'accusé de réception, et c'est donc au programme écrit par l'utilisateur qu'il appartient de détecter et compenser ces problèmes. Heureusement, le protocole UDP garantit que si un message arrive, son contenu sera intact (c'est-à-dire que vous ne recevrez jamais un message incomplet).
Le bon coté de l'UDP est qu'il tend à être le plus rapide des protocoles des socket. En outre, UDP est « orienté hors connexion » (« connectionless »), ce qui signifie que chaque message est essentiellement indépendant des autres. On peut comparer chaque message à une lettre à La Poste. Vous pouvez envoyer plusieurs lettres à la même adresse, mais chacune d'entre elles est indépendante des autres, et vous n'êtes pas limité quant aux nombre de personnes à qui vous pouvez en envoyer.
Contrairement à l'UDP, le TCP est un protocole fiable et orienté connexion. Chaque bloc est considéré non pas comme un message, mais comme un bloc de données appartenant à un flot d'octets voyageant au travers d'une connexion établie entre l'expéditeur et le destinataire. Ce principe est très différent du système de messages de l'UDP car chaque bloc n'est qu'une partie du flot d'octets, et il appartient au programme utilisateur de trouver le moyen de les isoler car il n'y a aucune marque de séparation pour les distinguer. De plus, les connexions sont plus vulnérables aux perturbations du réseau, et seul un nombre limité de connexions simultanées peut exister au sein d'un même processus. Parce qu'il est fiable, le TCP engendre souvent des overheads plus importants que l'UDP.
Le TCP réserve en revanche quelques bonnes surprises. Par exemple, si
plusieurs messages sont envoyés à travers une connexion, TCP est capable
de les rassembler dans une mémoire tampon pour mieux correspondre aux
tailles standard des paquets de l'électronique du réseau, ce qui peut
donner de meilleurs résultats que l'UDP dans le cas de groupes de
messages courts ou de taille inhabituelle. Un autre avantage : Les
réseaux bâtis sur des connexions physiques directes entre deux machines
peuvent facilement et efficacement être assimilés à des connexions TCP.
Ce fut le cas pour la « Socket
Library » (« bibliothèque de gestion de
Sockets »), présentant une gestion
compatible TCP au niveau de l'utilisateur qui ne différait des appels
systèmes TCP standard que par le préfixe PSS
, que
l'on rajoutait au début du nom des fonctions à invoquer.
Lorsque l'on en arrive au stade où il faut effectivement injecter des
données sur le réseau ou les y en extraire, l'interface logicielle des
Unix standard fait partie du noyau et s'appelle « pilote »
(« driver »). UDP et TCP ne se
contentent pas de transporter des données, ils s'accompagnent également
d'importants overheads dûs à la gestion
des sockets. Par exemple, il faut que
quelque chose s'occupe du fait que plusieurs connexions TCP peuvent
partager la même interface réseau physique. Par opposition, un pilote de
périphérique dédié à une interface réseau n'a besoin de mettre en
œuvre qu'un petit nombre de fonctions de transport élémentaires.
Ces pilotes peuvent alors être invoqués à l'aide de l'appel
open()
pour identifier le périphérique adéquat, puis
en utilisant par exemple read()
et
write()
sur le « fichier » ouvert. Ainsi,
chaque opération peut transporter un bloc de données en coûtant à peine
plus cher qu'un appel système, ce qui permet d'atteindre des délais de
l'ordre de quelques dizaines de microsecondes.
Écrire un pilote de périphérique pour Linux n'est pas difficile… pourvu que vous sachiez parfaitement comme fonctionne votre périphérique. Si vous n'en êtes pas sûr, n'essayez pas de le deviner. Déboguer un pilote de périphérique n'est pas une chose amusante, et faire des erreurs peut coûter la vie à votre matériel. En revanche, si ces risques ne vous effraient pas, il est possible d'écrire un pilote pour, par exemple, utiliser des cartes Ethernet dédiées comme des connexions machine-vers-machine « bêtes » mais très rapides car exonérées du protocole Ethernet habituel. Pour être exact, c'est pratiquement la technique utilisée par les premiers supercalculateurs Intel. Référez-vous au Device-Driver-HOWTO pour plus d'informations.
Si vous avez pris des cours de programmation système, on a dù vous y apprendre qu'accéder directement aux registres matériels des périphériques à partir d'un programme utilisateur était l'exemple typique de ce qu'il ne faut pas faire, parce que l'un des principes même d'un système d'exploitation est de contrôler l'accès aux périphériques. Cependant, le simple fait de passer un appel système coûte au minimum quelques dizaines de microsecondes. Dans le cas d'interfaces réseau bâties sur mesure comme TTL_PAPERS, qui peut effectuer des opérations de base sur un réseau en seulement 3 microsecondes, un tel surcoût pour un appel système est intolérable. Le seul moyen d'éviter ce temps d'attente est de faire en sorte que du code s'exécutant au niveau de l'utilisateur, donc une « bibliothèque au niveau de l'utilisateur » [21], puisse accéder directement au matériel, mais sans remettre en cause la souveraineté du système d'exploitation sur la gestion des droits d'accès aux ressources matérielles.
Sur un système typique, les seuls moyens, pour une bibliothèque utilisateur, d'accéder directement aux registres du matériel sont les suivants :
Au lancement du programme utilisateur, faire un appel système pour
mapper l'espace d'adressage qui contient les registres du périphérique
dans le plan mémoire du processus utilisateur. Sur certains systèmes,
l'appel système mmap()
(traité pour la première fois
dans la section 2.6) peut être utilisé pour mapper un fichier spécial
représentant les adresses de la page de mémoire physique du
périphérique. Il est en même temps relativement simple d'écrire un
pilote de périphérique effectuant cette opération. De plus, ce pilote
peut obtenir l'accès en ne mappant que la ou les pages qui contiennent
les registres nécessaires, en maintenant ainsi le contrôle des droits
d'accès sous la coupe du système d'exploitation.
Accéder ensuite aux registres du périphérique sans passer par un appel
système en se contentant de charger ou de ranger des valeurs sur la
plage d'adressage mappée. Par exemple, un
*((char *) 0x1234) = 5;
déposera un octet de valeur 5 à l'adresse mémoire 1234 en hexadécimal.
Par bonheur, il se trouve que Linux pour Intel 386 et compatibles offre une solution meilleure encore :
En invoquant l'appel système ioperm()
depuis un processus privilégié, obtenir la permission d'accéder
aux ports d'entrée/sortie correspondant précisément aux registres
du périphérique. Parallèlement, ces permissions peuvent être gérées
par un processus utilisateur privilégié et indépendant (autrement
dit : un « méta-système d'exploitation ») en utilisant l'appel
système giveioperm(), disponible sous la
forme d'un correctif à appliquer au noyau
Linux.
Accéder aux registres du périphérique sans appel système en utilisant les instructions assembleur d'accès aux ports d'entrée/sortie du 386.
Cette seconde solution est préférable car il arrive souvent que les registres de plusieurs périphériques soient réunis sur une même page, auquel cas la première méthode ne pourrait offrir de protection contre l'accès aux autres registres résidant dans la même page que ceux appartenant au périphérique concerné. L'inconvénient est que ces instructions ne peuvent bien sûr pas être écrites en langage C. Il vous faudra à la place utiliser un peu d'assembleur. La fonction utilisant l'assembleur en ligne intégré à GCC (donc utilisable dans les programmes C) permettant de lire un octet depuis un port est la suivante :
extern inline unsigned char inb(unsigned short port) { unsigned char _v; __asm__ __volatile__ ("inb %w1,%b0" :"=a" (_v) :"d" (port), "0" (0)); return _v; }
La fonction symétrique permettant l'émission d'un octet est :
extern inline void outb(unsigned char value, unsigned short port) { __asm__ __volatile__ ("outb %b0,%w1" :/* pas de valeur retournée */ :"a" (value), "d" (port)); }
PVM (pour « Parallel Virtual Machine », soit « Machine Virtuelle en Parallèle ») est une bibliothèque de message-passing portable et disponible gratuitement, s'appuyant généralement directement sur les sockets. Cette bibliothèque s'est incontestablement établie comme le standard de facto dans le domaine du traitement en parallèle à l'aide de clusters à transmission de messages.
PVM prend en charge les machines Linux monoprocesseur et SMP, comme les clusters de machines Linux reliées entre elles à l'aide par des réseaux reconnaissant les sockets (donc SLIP, PLIP, Ethernet, ATM). En fait, PVM fonctionnera même à travers un groupe de machines utilisant différents types de processeurs, de configurations et de réseaux physiques — Un cluster hétérogène — même si l'envergure de ce cluster est de l'ordre de la mise en parallèle de machines en utilisant Internet pour les relier entre elles. PVM offre même des facilités de contrôles de tâches (« jobs ») en parallèle au travers d'un cluster. Cerise sur le gâteau, PVM est disponible gratuitement et depuis longtemps (actuellement sur http://www.epm.ornl.gov/pvm/pvm_home.html), ce qui a conduit bon nombre de langages de programmation, de compilateurs, et d'outils de débogage ou autres à l'adopter comme leur « bibliothèque cible portable de message-passing ». Il existe également un groupe de discussion : news:comp.parallel.pvm.
Il est important de remarquer, en revanche, que les appels PVM ajoutent généralement aux opérations socket un overhead non négligeable alors que les temps de latence de celles-ci sont déjà importants. En outre, les appels eux-mêmes ne sont pas aisés à manipuler.
Appliquée au même exemple de calcul de Pi décrit en section 1.3, la version PVM du programme en langage C est la suivante :
#include <stdlib.h> #include <stdio.h> #include <pvm3.h> #define NPROC 4 main(int argc, char **argv) { register double sommelocale, largeur; double somme; register int intervalles, i; int mytid, iproc, msgtag = 4; int tids[NPROC]; /* Tableau des numéros des tâches */ /* Début du traitement avec PVM */ mytid = pvm_mytid(); /* « Je rejoins le groupe et, si je suis la première instance, iproc=0, je crée plusieurs copies de moi-même. » */ iproc = pvm_joingroup("pi"); if (iproc == 0) { tids[0] = pvm_mytid(); pvm_spawn("pvm_pi", &argv[1], 0, NULL, NPROC-1, &tids[1]); } /* On s'assure que tous les processus sont prêts */ pvm_barrier("pi", NPROC); /* Récupère le nombre d'intervalles */ intervalles = atoi(argv[1]); largeur = 1.0 / intervalles; sommelocale = 0.0; for (i = iproc; i<intervalles; i+=NPROC) { register double x = (i + 0.5) * largeur; sommelocale += 4.0 / (1.0 + x * x); } /* On ajuste les résultats locaux en fonction de la largeur */ somme = sommlocale * largeur; pvm_reduce(PvmSum, &sum, 1, PVM_DOUBLE, msgtag, "pi", 0); /* Seul le processus rattaché à la console renvoie le résultat */ if (iproc == 0) { printf("Estimation de la valeur de pi: %f\n", somme); } /* On attend que le programme soit terminé, on quitte le groupe et on sort de PVM. */ pvm_barrier("pi", NPROC); pvm_lvgroup("pi"); pvm_exit(); return(0); }
Bien que PVM soit le standard de fait en matière de bibliothèque de message-passing, MPI (« Message Passing Interface ») tend à devenir le nouveau standard officiel. Le site du standard MPI se trouve sur http://www.mcs.anl.gov:80/mpi/ et le groupe de discussion correspondant sur news:comp.parallel.mpi.
En revanche, avant d'explorer MPI, je me sens obligé de parler rapidement de la guerre de religion qui oppose PVM à MPI et qui dure depuis quelques années. Je ne penche ni pour l'un ni pour l'autre. Voici un résumé aussi impartial que possible des différences entre les deux interfaces :
Pour faire simple, PVM en a un, et MPI ne précise pas s'il existe, ni comment il doit être implémenté. Cela signifie que certaines choses comme lancer l'exécution d'un programme PVM se fait de la même manière partout, alors que pour MPI, cela dépend de l'implémentation utilisée.
PVM a grandi dans le monde de la collecte des cycles machines inutilisés sur les stations de travail, et sait donc gérer donc directement les mélanges hétérogènes de machines et de systèmes d'exploitation. A contrario, MPI part du principe général que la cible est un MPP (« Massively Parallel Processor », soit « Processeur Massivement Parallèle ») ou un cluster dédié de stations de travail pratiquement toutes identiques.
PVM se révèle être conçu pour une catégorie d'utilisation bien définie, ce que MPI 2.0 ne fait pas. Le nouveau standard MPI 2.0 inclut une variété de fonctionnalités qui s'étendent bien au delà du simple modèle de message-passing, comme le RMA (« Remote Memory Access », soit « Accès Mémoire à Distance ») ou les opérations d'entrée/sortie en parallèle sur les fichiers. Toutes ces choses sont-elles bien utiles ? Assurément… mais assimiler MPI 2.0 est comparable à réapprendre depuis zéro un langage de programmation totalement nouveau.
MPI a été conçu après PVM, et en a incontestablement tiré les leçons. MPI offre une gestion des tampons plus simple et plus efficace et une couche d'abstraction de haut-niveau permettant de transmettre des données définies par l'utilisateur comme des messages.
Pour ce que j'ai pu en voir, il existe toujours plus d'applications conçues autour de PVM qu'autour de MPI. Néanmoins, porter celles-ci vers MPI est chose facile, et le fait que MPI soit soutenu par un standard formel très répandu signifie que MPI est, pour un certain nombre d'institutions, une question de vision des choses.
Conclusion ? Disons qu'il existe au moins trois versions de MPI développées de façon indépendante et disponibles gratuitement pouvant fonctionner sur des clusters de machines Linux (et j'ai écrit l'un d'eux) :
LAM (« Local Area Multicomputer », soit « MultiOrdinateur Local ») est une mise en œuvre complète du standard 1.1. Il permet aux programmes MPI de s'exécuter sur un système Linux individuel ou au travers d'un cluster de systèmes Linux communiquant par le biais de sockets TCP/UDP. Le système inclut des facilités de base de contrôle de l'exécution, ainsi que toute une gamme d'outils de développement et de débogage de programmes.
MPICH (« MPI CHameleon ») est conçu pour être une implémentation complète et hautement portable du standard MPI 1.1. Tout comme LAM, il permet aux programmes MPI d'être exécutés sur des systèmes Linux individuels ou en clusters via une communication par socket TCP/UDP. En revanche, l'accent est porté sur la promotion de MPI en fournissant une implémentation efficace et facilement repositionnable. Pour porter cette implémentation, il faut réimplémenter soit les cinq fonctions de la « channel interface », soit, pour de meilleures performances, la totalité de l'ADI (« Abstract Device Interface », soit « Interface Périphérique Abstraite »). MPICH, et beaucoup d'informations concernant ce sujet et la façon de le porter, sont disponibles sur http://www.mcs.anl.gov/mpi/mpich/.
AFMPI (« Aggregate Function MPI ») est une sous-implémentation du standard MPI 2.0. C'est celle que j'ai écrite. S'appuyant sur AFAPI, elle est conçue pour être la vitrine des RMA et des fonctions de communications collectives, et n'offre donc qu'un soutien minimal des types MPI, de ses systèmes de communication, et cætera. Elle permet à des programmes C utilisant MPI d'être exécutés sur un système Linux individuel ou au travers d'un cluster mis en réseau par du matériel pouvant prendre en charge l'AFAPI.
Quelque soit l'implémentation MPI utilisée, il est toujours très simple d'effectuer la plupart des types de communication.
En revanche, MPI 2.0 incorpore plusieurs paradigmes de communication suffisamment différents entre eux fondamentalement pour qu'un programmeur utilisant l'un d'entre eux puisse ne même pas reconnaître les autres comme étant des styles de programmation MPI. Aussi, plutôt que d'explorer un seul exemple de programme, il est utile de passer en revue un exemple de chacun des (différents) paradigmes de communication de MPI. Tous les programmes qui suivent emploient le même algorithme (celui de la section 1.3) utilisé pour calculer Pi.
Le premier programme MPI utilise les appels de message-passing MPI sur chaque processeur pour que celui-ci renvoie son résultat partiel au processeur 0, qui fait la somme de tous ces résultats et la renvoie à l'écran :
#include <stdlib.h> #include <stdio.h> #include <mpi.h> main(int argc, char **argv) { register double largeur; double somme, sommelocale; register int intervalles, i; int nproc, iproc; MPI_Status status; if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1); MPI_Comm_size(MPI_COMM_WORLD, &nproc); MPI_Comm_rank(MPI_COMM_WORLD, &iproc); intervalles = atoi(argv[1]); largeur = 1.0 / intervalles; sommelocale = 0; for (i=iproc; i<intervalles; i+=nproc) { register double x = (i + 0.5) * largeur; sommelocale += 4.0 / (1.0 + x * x); } sommelocale *= largeur; if (iproc != 0) { MPI_Send(&lbuf, 1, MPI_DOUBLE, 0, 0, MPI_COMM_WORLD); } else { somme = sommelocale; for (i=1; i<nproc; ++i) { MPI_Recv(&lbuf, 1, MPI_DOUBLE, MPI_ANY_SOURCE, MPI_ANY_TAG, MPI_COMM_WORLD, &status); somme += sommelocale; } printf("Estimation de la valeur de pi: %f\n", somme); } MPI_Finalize(); return(0); }
Le second programme MPI utilise les communications collectives (qui, pour ce cas précis, sont incontestablement les plus appropriées) :
#include <stdlib.h> #include <stdio.h> #include <mpi.h> main(int argc, char **argv) { register double largeur; double somme, sommelocale; register int intervalles, i; int nproc, iproc; if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1); MPI_Comm_size(MPI_COMM_WORLD, &nproc); MPI_Comm_rank(MPI_COMM_WORLD, &iproc); intervalles = atoi(argv[1]); largeur = 1.0 / intervalles; sommelocale = 0; for (i=iproc; i<intervalles; i+=nproc) { register double x = (i + 0.5) * largeur; sommelocale += 4.0 / (1.0 + x * x); } sommelocale *= largeur; MPI_Reduce(&sommelocale, &somme, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD); if (iproc == 0) { printf("Estimation de la valeur de pi: %f\n", somme); } MPI_Finalize(); return(0); }
La troisième version MPI utilise le mécanisme RMA de MPI 2.0 sur chaque processeur
pour ajouter la valeur locale de la variable sommelocale
de ce dernier
à la variable somme
du processeur 0 :
#include <stdlib.h> #include <stdio.h> #include <mpi.h> main(int argc, char **argv) { register double largeur; double somme = 0, sommelocale; register int intervalles, i; int nproc, iproc; MPI_Win somme_fen; if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1); MPI_Comm_size(MPI_COMM_WORLD, &nproc); MPI_Comm_rank(MPI_COMM_WORLD, &iproc); MPI_Win_create(&somme, sizeof(somme), sizeof(somme), 0, MPI_COMM_WORLD, &somme_fen); MPI_Win_fence(0, somme_fen); intervalles = atoi(argv[1]); largeur = 1.0 / intervalles; sommelocale = 0; for (i=iproc; i<intervalles; i+=nproc) { register double x = (i + 0.5) * largeur; sommelocale += 4.0 / (1.0 + x * x); } sommelocale *= largeur; MPI_Accumulate(&sommelocale, 1, MPI_DOUBLE, 0, 0, 1, MPI_DOUBLE, MPI_SUM, somme_fen); MPI_Win_fence(0, somme_fen); if (iproc == 0) { printf("Estimation de la valeur de pi: %f\n", somme); } MPI_Finalize(); return(0); }
Il est utile de préciser que le mécanisme RMA de MPI 2.0 prévient
de façon remarquable tout problème de structures de données se trouvant
à des adresses mémoires différentes selon les processeurs, en se référant
à une "fenêtre" incluant l'adresse de base, une protection contre les
accès mémoire hors de portée, et même le rééchelonnement d'adresse. À une
implémentation efficace, s'ajoute le fait qu'un traitement RMA peut-être
reporté jusqu'à la prochaine MPI__Win_fence
.
Pour faire simple, le mécanisme RMA est un étrange croisement entre
mémoire partagée distribuée et message passing,
mais reste une interface très propre pouvant générer des communications très efficaces.
Contrairement à PVM, MPI, et cætera, l'interface AFAPI (« Aggregate Function API », ou « Interface à Fonctions d'Agrégation ») n'a pas débuté sa vie en tant que couche d'abstraction portable s'appuyant sur un réseau matériel ou logiciel existant. AFAPI était plutôt la bibliothèque de gestion bas niveau d'un matériel spécifique pour PAPERS (« Purdue's Adapter for Parallel Execution and Rapid Synchronization », soit « Adaptateur pour l'Exécution en Parallèle et la Synchronisation Rapide de l'université de Purdue »).
PAPERS a été rapidement présenté dans la section 3.2. Il s'agit d'un réseau à fonction d'agrégations conçu sur mesure dont le modèle est dans domaine public et qui présente des temps de latence inférieurs à quelques microsecondes. Mais surtout, il s'agit de la tentative de construction d'un supercalculateur formant une meilleure cible pour la technologie des compilateurs que les supercalculateurs déjà existants. Il se distingue en qualité de la plupart des efforts en matière de clusters Linux et de PVM/MPI, qui s'attachent généralement à essayer d'exploiter les réseaux standard au profit des rares applications en parallèle présentant une granularité suffisante. Le fait que les éléments de PAPERS soient des machines PC sous Linux ne sert qu'à permettre l'implémentation de prototypes à des coûts les plus avantageux possibles.
La nécessité d'avoir une interface logicielle de bas niveau commune à plus d'une douzaine d'implémentations différentes d'un prototype a conduit la bibliothèque PAPERS à être standardisée sous le nom d'AFAPI. Mais le modèle utilisé par AFAPI est simple en lui-même et bien plus adapté aux interactions à la granularité plus fine, typiquement du code compilé par des compilateurs parallélisés, ou écrit pour des architectures SIMD. Non seulement la simplicité du modèle rend les machines PAPERS aisées à construire, mais elle apporte également une efficacité surprenante aux ports d'AFAPI sur différents types de système, tels que les SMP.
AFAPI fonctionne actuellement sur des clusters Linux utilisant TTL_PAPERS, CAPERS ou WAPERS. Elle fonctionne également (sans appel système ni même instruction de verrouillage de bus, voir la section 2.2) sur les machines SMP utilisant une bibliothèque de gestion de mémoire partagée type System V (« System V Shared Memory ») appelée SHMAPERS. Une version fonctionnant sur des clusters Linux utilisant la diffusion UDP sur des réseaux conventionnels (Ex : Ethernet) est en cours de développement. Toutes les versions d'AFAPI sont écrites pour être appelées à partir des langages C ou C++.
L'exemple suivant est la version AFAPI du programme de calcul de Pi décrit dans la section 1.3.
#include <stdlib.h> #include <stdio.h> #include "afapi.h" main(int argc, char **argv) { register double largeur, somme; register int intervalles, i; if (p_init()) exit(1); intervalles = atoi(argv[1]); largeur = 1.0 / intervalles; sum = 0; for (i=IPROC; i<intervalles; i+=NPROC) { register double x = (i + 0.5) * largeur; somme += 4.0 / (1.0 + x * x); } somme = p_reduceAdd64f(somme) * largeur; if (IPROC == CPROC) { printf("Estimation de la valeur de pi: %f\n", somme); } p_exit(); return(0); }
Outre PVM, MPI et AFAPI, les bibliothèques suivantes proposent des
services qui peuvent s'avérer utiles au travers de grappes de machines
Linux. Ces systèmes sont traités ici de manière moins approfondie
simplement parce que, contrairement à PVM, MPI et AFAPI, je n'ai que
peu, voire aucune expérience pratique de l'utilisation de ceux-ci sur
des clusters Linux. Si l'une de ces
bibliothèques (ou même d'autres) vous est particulièrement utile, merci
de m'envoyer un courrier électronique en anglais à
<hankd CHEZ engr POINT uky POINT edu>
en me détaillant vos découvertes. J'envisagerai alors d'ajouter une
section plus complète à son sujet.
Condor est un système de gestion de ressources distribuées qui peut diriger de vastes clusters de stations de travail hétérogènes. Sa conception a été motivée par les besoins des utilisateurs souhaitant utiliser la puissance inexploitée de tels clusters au profit de leurs tâches aux temps d'exécution prolongés et aux calculs intensifs. Condor reproduit dans une large mesure l'environnement de la machine initiale sur celle qui exécute le processus, même si ces deux machines ne partagent pas un système de fichier ou un mécanisme de mot de passe communs. Les tâches sous Condor qui se résument à un processus unique sont automatiquement interceptées et déplacées entre les différentes stations en fonctions des besoins pour les mener à terme.
Condor est disponible sur http://www.cs.wisc.edu/condor/.
Une version Linux existe également. Contactez l'administrateur du site,
<condor TIRET admin CHEZ cs POINT wisc POINT edu>
,
pour plus de détails.
Le DFN-RPC (un outil du Réseau Allemand de la Recherche — « Remote Procedure Call ») a été développé pour distribuer et paralléliser des applications d'intéret scientifique ou technique entre une station de travail et un serveur de calcul ou un cluster. L'interface est optimisée pour les applications écrites en Fortran, mais le DFN-RPC peut aussi être utilisé dans un environnement de langage C. Une version Linux a été écrite. Plus d'information sur ftp://ftp.uni-stuttgart.de/pub/rus/dfn_rpc/README_dfnrpc.html.
Pas vraiment une bibliothèque, DQS 3.0 (« Distributed Queueing System », soit « Système de Files d'attente Distribuées ») est un système de mise en file d'attente des tâches qui a été développé et testé sous Linux. Ce système a été conçu pour permettre à la fois l'utilisation et l'administration d'un cluster de machines hétérogènes comme une seule entité. Disponible sur http://www.scri.fsu.edu/~pasko/dqs.html.
Il existe aussi une version commerciale nommée CODINE 4.1.1 (« COmputing in DIstributed Network Environments », soit « CAlcul en Environnement Réseau Distribué »).
Les clusters peuvent être construits et utilisés de tellement de manières différentes que certains groupes ont apporté des contributions particulièrement intéressantes. Ce qui suit fait référence aux différents projets liés à la mise en place de clusters pouvant avoir un intérêt d'ordre général. Ceci inclut un mélange de références à des clusters spécifiques à Linux et à des clusters génériques. Cette liste est présentée dans l'ordre alphabétique.
Le projet Beowulf, se focalise sur la production de logiciels pour une utilisation de stations de travail immédiatement disponibles basée sur du matériel PC de grande distribution, un réseau à haut débit interne au cluster, et le système d'exploitation Linux.
Thomas Sterling a été le principal acteur de Beowulf, et continue d'être un promoteur franc et éloquent de l'utilisation de clusters Linux dans le domaine du calcul scientifique en général. À vrai dire, plusieurs groupes parlent à présent de leur cluster comme de système de « classe Beowulf », et ce même si la conception de ce cluster s'éloigne du modèle Beowulf officiel.
Don Becker, apportant son appui au projet Beowulf, a produit nombre des pilotes réseau utilisés par Linux en général. Plusieurs de ces pilotes ont même été adaptés pour être utilisés sous BSD. C'est également à Don que l'on doit la possibilité, pour certains pilotes, de répartir le trafic réseau à travers plusieurs connexions parallèles pour augmenter les taux de transfert sans utiliser d'onéreux commutateurs. Ce type de répartition de la charge réseau était le principal atout des clusters Beowulf.
Le projet Linux/AP+ ne concerne pas exactement le clustering sous Linux, mais s'attache à faire fonctionner Linux sur l'AP1000+ de Fujitsu, et à y apporter les améliorations appropriées en matière de traitement en parallèle. L'AP1000+ est une machine en parallèle à base de SPARC et disponible dans le commerce, utilisant un réseau spécifique avec une topologie en tore, un taux de transfert de 25Mo/s et un temps de latence de 10 microsecondes… Pour faire court, cela ressemble beaucoup à un cluster Linux SPARC.
Le projet Locust est en train de mettre au point un système de mémoire partagée virtuelle qui utilise les informations obtenues à la compilation pour masquer les temps de latence des messages et réduire le trafic réseau lors de l'exécution. « Pupa » forme la base du système de communication de Locust, et est implémenté à l'aide d'un réseau Ethernet reliant des machines PC 486 sous FreeBSD. Et Linux ?
Midway est une DSM (« Distributed Shared Memory », soit « Mémoire Partagée Distribuée ») logicielle, similaire à TreadMarks. Le bon coté réside en l'utilisation d'indications à la compilation plutôt que de relativement lents mécanismes d'erreur de page, et en sa gratuité. Le mauvais coté est cela ne fonctionne pas sur des clusters Linux.
MOSIX apporte des modifications au système d'exploitation BSD « BSDI » pour proposer une répartition de charge réseau (« load balancing ») dynamique et une migration de processus préemptive au travers d'un groupe de PC mis en réseau. C'est un système très utile non seulement pour le traitement en parallèle, mais d'une manière générale pour utiliser un cluster comme une machine SMP évolutive. Y aura-t-il une version Linux ? Voyez http://www.mosix.org pour plus d'informations[22].
Le projet NOW (« Network Of Workstations », ou « Réseau de Stations de Travail ») de l'université de Berkeley (http://now.cs.berkeley.edu) a conduit dans une large mesure l'effort pour le calcul en parallèle en utilisant des réseaux de stations de travail. Bon nombre de travaux sont menés là-bas, tous tournés vers la « démonstration en pratique d'un système à 100 processeurs dans les prochaines années ». Hélas, ils n'utilisent pas Linux.
Le site web du « Traitement en parallèle avec Linux » (« Parallel processing using Linux »), sur http://yara.ecn.purdue.edu/~pplinux>, est le site officiel de ce guide pratique et de plusieurs documents en rapport avec ce thème, y compris des présentations en ligne. Parallèlement aux travaux du projet PAPERS, l'École Supérieure d'Électricité et d'Informatique de Purdue (« Purdue University School of Electrical and Computer Engineering ») reste un leader en matière de traitement en parallèle. Ce site a été mis en place pour aider les autres à utiliser des PC sous Linux pour faire du traitement en parallèle.
Depuis l'assemblage du premier cluster de PC Linux en février 1994, bien d'autres furent également assemblés à Purdue, dont plusieurs équipés de murs vidéos. Bien que ces clusters s'appuyaient sur des machines à base de microprocesseurs 386, 486 ou Pentium (mais pas de Pentium Pro), Intel a récemment accordé à Purdue une donation qui lui permettra de construire plusieurs grands clusters de systèmes à Pentium II (avec pas moins de 165 machines par cluster). Même si tous ces clusters sont ou seront équipés de réseaux PAPERS, la plupart sont également dotés de réseaux conventionnels.
Les 10 et 11 avril 1997, le laboratoire AMES a tenu à Des Moines, dans l'état de l'Iowa aux États-Unis, le « Pentium Pro Cluster Workshop » (« Atelier de clusters Pentium Pro »). Le site web de cet atelier, http://www.scl.ameslab.gov, renferme une mine d'informations concernant les clusters PC, glanées auprès de tous les participants.
La DSM (« Distributed Shared
Memory », ou « Mémoire Partagée
Distribuée ») est une technique avec laquelle un système de
message-passing peut se présenter et agir
comme un SMP. Il existe quelques systèmes de ce genre, la plupart
utilisant les mécanismes d'erreur de page du système d'exploitation pour
déclencher la transmission des messages. TreadMarks
est l'un des plus efficaces, et fonctionne sur les
clusters Linux. La mauvaise nouvelle est
que « TreadMarks est distribué à un coût réduit aux universités et
organisations à but non lucratif ». Pour plus d'informations
concernant le logiciel, prenez contact (en anglais) avec
<tmk CHEZ cs POINT rice POINT edu>
.
Le projet U-Net (« User-level NETwork interface architecture », ou « Architecture d'interface Réseau au Niveau Utilisateur »), accessible sur http://www.eecs.harvard.edu/~mdw/proj/old/unet, tente d'apporter temps de latence réduits et taux de transfert élevés sur du matériel réseau du commerce en virtualisant les interfaces réseau de manière à ce que les applications puissent envoyer et recevoir des messages sans passer par un appel système. U-Net fonctionne sur des PC Linux en utilisant du matériel Fast Ethernet basé sur une puce DEC DC21140, ou une carte ATM Fore Systems PCA-200 (mais pas PCA-200E).
On trouve bon nombre de projets relatifs à l'utilisation de clusters dans le Wisconsin. Le projet WWT (« Wisconsin Wind Tunnel », ou « Soufflerie du Wisconsin »), sur http://www.cs.wisc.edu/~wwt/, mène toutes sortes de travaux orientés vers le développement d'une interface « standard » entre les compilateurs et le matériel réseau sur lequel ils s'appuient. Il existe le « Wisconsin COW » (pour « Cluster Of Workstation »), « Cooperative Shared Memory » et « Tempest », le « Paradyn Parallel Performance Tools », et cætera. Malheureusement, il n'y a pas grand chose concernant Linux.
[10] N.D.T. : il semble que ce panel ne soit plus mis à jour depuis un certain temps. Le site suggéré proposait à la date de rédaction de la version française le bulletin le plus récent, mais n'est pas officiel.
[11] N.D.T. : désormais intégré aux sources du noyau.
[12] N.D.T. : les pilotes FC pour le noyau Linux ont en fait été écrits en 1999.
[13] N.D.T. : La Fibre Channel Association (FCA) et la Fibre Channel Loop Community (FCLC) ont fusionné en 2000 pour former la Fibre Channel Industry Association.
[14] N.D.T. : les premiers pilotes FireWire pour Linux ont été écrits en 1999 mais, bien que disponibles en standard, sont toujours considérés comme expérimentaux.
[15] N.D.T. : HiPPI est aujourd'hui pris en charge par Linux, mais de façon restreinte et expérimentale.
[16] N.D.T. : l'IrDA est pris en charge par le noyau depuis 2000.
[17] SAN : « System Area Network ».
N.D.T. : à ne pas confondre avec « Storage Area Network », qui partage le même acronyme.
[18] N.D.T. : Sequent a été absorbé par IBM en septembre 1999.
[19] N.D.T. : et donc désormais à Hewlett-Packard.
[20] N.D.T. : les ports et le standard USB sont aujourd'hui parfaitement reconnus par Linux.
[21] N.D.T. : par opposition à un « appel système », donc sans franchir la barrière du passage en mode noyau.
[22] N.D.T. : MOSIX fonctionne aujourd'hui sous Linux.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:15