La problématique

La course à la puissance de calcul est loin d'être terminée. Imagerie, météo, biochimie, simulations diverses sont aujourd'hui des thèmes consommateurs de ressources informatiques.

Chaque unité travaillant sur ces thèmes, à un moment ou à un autre, fera émerger la question de l'organisation d'une puissance de calcul suffisante pour arriver à ses fins.

Par ailleurs, l'informatique se démocratise. Partout, dans toutes les entreprises, les collectivités, les parcs informatiques augmentent, se modernisent. Les postes de travail mis actuellement sur le marché, à des prix que l'ont peut qualifier de très bas, sont, du point de vue de leurs capacités de calcul, de véritables bêtes de courses : des processeurs cadencés plus de 3 GHz, de la ram d'au minimum 512 Mo, si ce n'est 1024, des disques durs de plusieurs centaines de Gigaoctets.

Parallèlement, les capacités des réseaux augmentent également de manière spectaculaire. Au niveau des LAN, le gigabit/s est devenu une norme. Des dizaines de réseaux de transport en fibre optiques sont apparus un peu partout, permettant des débits du même ordre que ce que l'on trouve sur un LAN. Aujourd'hui, sans chercher fort longtemps, on peut trouver dans chaque département un point d'accès au réseau internet avec un débit dépassant la centaine de Mo par seconde.

En d'autre termes, la puissance offerte par un cluster de calcul traditionnel, c'est à dire un certain nombre d'ordinateurs, identiques, tous au même endroit, raccordés entre eux en gigabit par seconde, est plus que largement concurrençable par un système de mutualisation des puissances de calculs inutilisées.

Clusterotaxie : la fin du Gigaflop/s

Les clusters de calculs sont traditionnellement classifiés selon l'organisation du flux des données qu'ils proposent :

• clusters à mémoires partagées,
• Single System Image (openMosix, kerrighed),
• SIMD (Single Instruction, Multiple Data),
• MIMD (Multiple Instructions, Multiple Data).

Traditionnellement encore, on évalue la puissance d'un cluster au nombre d'instructions qu'il est capable d'effectuer par secondes exprimé en GFlop/s ou GFlops, Giga-FLoating-Operation-per-second.

La tradition n'a pas toujours que du bon.

Certes, il est des cas où le nombre d'instructions à la seconde peut être important (calcul temps réel, comme pour l'imagerie médicale en « réalité virtuelle augmentée »). Mais dans l'immense majorité des cas, ce qui compte, c'est le nombre d'instructions effectuées à la minute, à l'heure, voire à la journée. On parlera donc de Téra- ou PétaFlop par heure (Tfloph, Pfloph .....).

Condor HTC introduit une nouvelle espèce de cluster : les clusters à haut-débit de calcul (High Throughput Computing).

Ce qui importe à Condor, c'est le nombre d'opérations effectuées sur un intervalle de temps plus significatif que la seconde, partant du constat que les applications nécessitant des fermes de calcul tournent au moins plusieurs minutes avant de produire un résultat.

En considérant cela, on s'affranchit des architectures chères et potentiellement instables qui ont été la norme du calcul parallèle jusqu'ici.

Condor utilise donc un parc hétérogène (en processeurs, en systèmes d'exploitation, en puissances) de machines. Le ciment est effectué par des serveurs décentralisés en cascade qui distribuent les tâches aux postes de travail selon les besoins de l'application et les moyens des noeuds de calculs.

Le projet Omega

Omega est un culster de calcul distribué. Il mutualise actuellement les capacités de calcul de deux postes de l'université de Montpellier II, ainsi que trois serveurs de PraKsys. Le projet a été proposé à divers organismes, qu'ils soient organismes de recherches, aménageurs, responsables de pôles de compétitivité. Nous prévoyons une cinquantaine de processeurs d'ici fin 2006, et, vu d'aujourd'hui, rien ne s'oppose à ce que la barre des 1000 processeurs soit passées en 2007.

Subsidiarité et suppléance

Il importe que chacun dispose de sa propre puissance de calcul. Il importe également que si sa propre puissance n'est pas suffisante, il puisse faire appel aux autres.

Intégrité des résultats

Le cluster jauge de l'intégrité du résultat fourni par chacune des entités participantes : postes de travail, groupe, grappe de groupes ... Il élimine les résultats non intègre, quelle qu'en soit la raison. Le premier condor master de la hiérarchie tague la machine ou le groupe d'où provient le résultat non intègre. Une étude statistique peut alors conduire à l'exclure.

Architecture logicielle

• Systèmes d'exploitation Windows (95, 95, Me, 2000, XP-Pro, ...), MacOS X, Linux (Ubuntu, Debian, Fedora Core, CentOS, RedHat, SuSe, ...)
• Condor HTC
• Support des programmes fontionnant sous Windows, Linux et/ou MacOS-X

Architecture matérielle

• serveurs centraux de tout type, dont bien sûr le Tranquilinux Cargo
• les ordinateurs de bureau du parc existant : architectures x86, x86_64, PowerPC, ...
• clusters existants (beowulf, MPI, PVM, PBS/Open-PBS, openMOSIX, etc)
• Réseau (WAN) de réseaux (LAN) Ethernet 10, 100 ou 1000 Mb/s

Conclusion

Omega est un projet ambitieux, mais très léger. Il n'implique qu'un tout petit travail par machine raccordée. Il ne nécessite qu'une bonne gestion centralisée des configurations des noeuds et de leurs capacité d'échange. Les outils existent. Il ne demandent plus qu'à être mis en oeuvre !

Pour toute information complémentaire, vous pouvez nous écrire !