Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

: Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20

Posté par Sytoka Modon (page perso, ). Modéré le 03 décembre 2007.
Kerrighed 2.2.0 est sortie le 8 novembre dernier. Pour rappel, Kerrighed est un SSI, c'est à dire un système à image unique sur un cluster. En gros, un cluster Kerrighed est vu comme une seule et même machine SMP.

Cette version est basée sur un noyau Linux 2.6.20 donc un noyau plutôt récent. Rappelons que l'un des objectifs de développement de Kerrighed est d'avoir des modules noyaux relativement autonome vis à vis du c½ur Linux et un patch minimaliste afin de simplifier la cohérence et la maintenance de l'ensemble. La principale avancée de cette version est le support des machines SMP, c'est à dire de toutes les machines modernes dont le processeur est multi-coeur. Même si celui-ci n'est pas encore parfaitement stable, il fonctionne bien. Par ailleurs, une version 64 bits est en cours de finalisation.

Cette version introduit également un support complet pour les communications IPC (segment de mémoire partagée, sémaphore, files d'attente de message).

Afin de montrer que cela fonctionne sur plus de deux machines, un cluster Kerrighed de 252 CPU a été monté. Celui-ci comporte 63 n½uds bi-processeur dual-c½ur ayant chacun 1 Go de mémoire. La machine SSI affiche alors une mémoire globale de 63 Go.

> Lire la dépêche (38 commentaires, moyenne: 3,2).  

Vous avez demandé le commentaire #886837.

Oui mais bon

Posté par Victor STINNER (page perso, ) le 03/12/2007 à 12:38. (lien). Évalué à 6.

Une machine de 252 noeuds donne combien d'images par seconde à Quake ?

Plus sérieusement : quels applications tournent là-dessus ? Vous avez des benchmarks comparatifs avec des gros calculateurs ? Est-ce prévu pour pouvoir faire tourner Apache et MySQL par exemple (faut-il des processus ou des threads) ?

  • [^]Re: Oui mais bon

    Posté par zeb () le 03/12/2007 à 13:08. (lien). Évalué à 2.

    Et aussi, comment ca se programme? Faut-il adapter les programmes pour utiliser le parallelisme (avec MPI par exemple?)

    • [^]Re: Oui mais bon

      Posté par ragoutoutou () le 03/12/2007 à 13:14. (lien). Évalué à 9.

      Et aussi, comment ca se programme? Faut-il adapter les programmes pour utiliser le parallelisme (avec MPI par exemple?)


      ça se programme comme du multithread classique, c'est tout l'intérêt de ce type de technologie. Si ça utilisait du MPI, ce serait juste du beowulf.

      • [^]Re: Oui mais bon

        Posté par 16aR () le 03/12/2007 à 13:45. (lien). Évalué à 0.

        C'est du bon ca :)

        [^]Re: Oui mais bon

        Posté par Nicolas Boulay () le 03/12/2007 à 14:42. (lien). Évalué à 5.

        Cela serait interressant de voir les perfs d'un serveur type apache par rapport au solution habituelles de load balacing super couteux.

        Est-ce que les disques dures sont aussi partagé l'est la RAM ?

        Bref par rapport au autres technos, ou cela se situe-t-il ?

        [^]Re: Oui mais bon

        Posté par lasher () le 03/12/2007 à 15:01. (lien). Évalué à 4.

        Oui, mais ça nécessite quand même de faire attention à la topologie. On a une « fausse » mémoire partagée, ce qui permet d'utiliser les threads, etc., mais pour des besoins de performance, il sera quand même nécessaire de faire attention à la localité des données, car même avec une interconnexion dédiée, la migration de threads, ou le partage de gros volumes de données peut coûter très cher (facteur NUMA, tout ça).

        Ça va aussi être le cas pour des machines bien plus modestes à l'avenir, avec l'HyperTransport d'AMD (déjà présent depuis un moment) et le CSI d'Intel d'une part, et l'utilisation sans doute de plus en plus massive de cartes de calcul dédiées (cartes graphiques et « GPU » en tous genres).

        [^]Re: Oui mais bon

        Posté par gentildemon () le 03/12/2007 à 15:46. (lien). Évalué à 2.

        C'est un peu plus complexe que ça pour la version actuelle de Kerrighed.

        Dans la branche 1.0, il était en effet possible d'utiliser du multi-thread classique. Cette branche, issue d'un projet de recherche, était très instable.

        Dans un souci de stabilisation, la branche 2.x a supprimé un certain nombres de fonctionnalité comme la possibilité d'avoir des threads répartis sur plusieurs machines du cluster. La migration d'application multi-threadé fonctionne encore cependant. Il est donc possible d'utiliser des applications multi-thread, celles-ci sont réparties sur le cluster afin d'équilibrer la charge, mais les threads d'une même application resteront sur la même machine.

        Comme c'est un cluster, il est toujours possible d'utiliser du MPI en conservant les performances classiques du MPI sur un cluster.

        Les fonctions supprimées entre la version 1.0 et 2.0 réapparaîtront petit à petit dans les mois/années à venir.