Sortie de la version 1.0.0 de Kerrighed

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
25
fév.
2005
Noyau
La version 1.0.0 de Kerrighed est sortie, après 5 années de développement.

Kerrighed est un système d'exploitation pour grappe de PCs de type "système à image unique" (Single Systeme Image -- SSI). Kerrighed fournit à l'utilisateur la vision d'une machine unique de type SMP au dessus d'une grappe de PCs. Kerrighed est conçu comme une extension du système d'exploitation Linux (patch
noyau ainsi qu'un ensemble de modules).

Les principales caractéristiques de Kerrighed sont:

  • Le système à image unique pour l'ensemble de la grappe : espace de nommage des processus global à la grappe. Toutes les fonctions UNIX de manipulation de processus (top, ps, kill, etc) fonctionnent à travers les noeuds de la grappe.

  • Gestion globale des processus : mécanisme configurable de placement/déplacement des processus au niveau de la grappe, point de reprise de processus, équilibrage de charge processeur.

  • Gestion globale de la mémoire assurant le partage mémoire entre processus ou threads s'exécutant sur des n½uds différents de la grappe.

  • Mécanisme de migration efficace de flux assurant la meilleure performance possible des flux de communication après la migration
    d'un processus communiquant.

  • Système de fichiers parallèle et distribué.


Kerrighed se démarque de projets similaires tel que OpenSSI et openMosix par une volonté de créer un système d'exploitation distribué factorisant un maximum de mécanismes, sans sacrifier aux performances ou à l'architecture logicielle.

Kerrighed est un logiciel développé au sein de l'IRISA/INRIA Rennes en partenariat avec EDF R&D. Kerrighed est sous licence GPL. Bien que Kerrighed soit développé depuis près de 5 ans, il reste jeune pour une utilisation en "production".

Une présentation du système Kerrighed aura lieu lors du Fosdem 2005,
le dimanche 27 Février à 11h.

Aller plus loin

  • # comparaison avec OpenSSI et OpenMosix

    Posté par  . Évalué à 10.

    Une etude comparative est disponible dans le forum:
    http://kerrighed.org/forum/viewtopic.php?t=40(...)

    • [^] # Re: comparaison avec OpenSSI et OpenMosix

      Posté par  (site web personnel) . Évalué à 4.

      Merci. D'ailleurs beaucoup de ceux qui se posent des questions au sujet de Korrigan Kerrighed devraient aller le lire:

      Kerrighed does not yet offers the ability to add or remove a node to a running cluster. If a node fails, the remaining nodes are likely to be affected resulting in a whole cluster dead-lock or crash.

      Ce n'est pas pour rien que la dépêche mentionne qu'il est un peu jeune pour une utilisation en production. Malgré celà ça reste un très beau sujet d'étude.

  • # il neige par-dessus le toit

    Posté par  . Évalué à 6.

    La doc - que j'ai lu - ne répond pâââââs à une question essentielle, une question de geek acharné et gourmand:
    si je le lance sur mon p'tit réseau, mon assemblage hétéroclite de machines dépassées de pièce de collections, est ce que ça marche ? Et si ça marche, (accroche toi au fauteuil), je peux ouvrir des sessions XWindow en XDMCP ? sur chaque noeud? et ils profitent tous de la puissance accrue, des disque partagés et de la ram?

    Riez, riez, mais laissez-moi rêver.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: il neige par-dessus le toit

      Posté par  . Évalué à 10.

      A priori, ca marche. Par contre ton code doit pouvoir être executé sur tout les noeuds, donc tu dois mettre les CFLAGS correspondants (cad pas de -march=athlon-xp si t'as aussi des pentium II). Sinon c'est le boulot du scheduler de décider si il fait migrer les taches (avec kerrighed ca se fait meme au niveau du thread).

  • # Bravo !!!

    Posté par  (site web personnel) . Évalué à 5.

    Bravo les gars, beau boulot !

    Au fait, vous avez oublié de préciser que vous serez aussi à l'événement du printemps en région parisienne... j'ai nommé Libr'east !!!

    Oui, d'ailleurs, on me chuchote dans l'oreille que les dates sont confirmées : 22,23 et 24 avril à Marne-la-Vallée !

    Incessamment sous peu, le programme sera disponible à l'adresse habituelle : http://www.idile.org/libreast/(...)

    Encore bravo pour Kerrighed, j'attends avec impatience votre demo à Marne ;o)

  • # Bravo !

    Posté par  . Évalué à 0.

    Enfin l'annonce publique ;)
    Bravo bravo !
    j'espère que cela va attirer un grand nombre des testeurs & développeurs !

    Encore bravo, et merci ;)

  • # Quelques interrogations

    Posté par  . Évalué à 5.

    Kerrighed semble être un logiciel exceptionnel, mais je me pose quelques questions.

    En effet, sur le papier il a tout de ce que permettent déjà les grands applicatifs de virtualisation de serveurs, tels que VMWare ESX Server et Microsoft Virtual Server, avec en plus l'avantage de permettre cela au dessus d'une grappe de machines.

    Les logiciels de virtualisation de serveur permettent en effet de rendre le système d'exploitation et les données de l'entreprise totalement indépendants du matériel sur lequel l'ensemble tourne. Ainsi, en cas de panne matérielle et de remplacement du serveur, même si le matériel n'est pas identique (ce qui arrive souvent, ne serait-ce que par l'évolution technologique, ou la gestion du dépanage dans l'urgence), l'entreprise a l'assurance de retrouver exactement le même système, fonctionnel, avec toutes ses données.

    À ce sujet, avec VMWare ESX Server, il suffit de sauvegarder 2 fichiers (un pour le système, et un autre pour les données), ce qui simplifie grandement le processus d'administration et diminue d'autant les problèmes potentiels de sauvegarde/restauration.

    Je connais moins Microsoft Virtual Server (je sais qu'il est moins cher, ~500 à 600 ¤, contre ~3500 à 4000 ¤ pour ESX Server), mais j'en ai eu de bons échos également.

    Mes interrogations concerne surtout la partie virtualisation de Kerrighed. Est-il possible -aisément- (et il semble que cela soit le cas) de faire une virtualisation de serveur ?

    Auquel cas, le fait que cela soit possible sur une grappe de serveurs, cela augure d'un futur succès commercial, car contrairement à ESX ou Virtual Server, il devient du coup possible d'augmenter la puissance de calcul et les ressources du serveur virtualisé à la volée, juste en rajoutant des machines sur la grappe !

    Si Kerrighed pouvait de surcroît intégrer un module de sauvegarde/restauration simplifiées du système ET des données, on aurait là un produit qui a toutes les chances de monopoliser un marché à l'avenir prometteur, tel Apache sur les serveurs web, en tout cas un produit dont je connais un paquet de sociétés prêtes à acheter une licence fort cher :-)

    • [^] # Re: Quelques interrogations

      Posté par  . Évalué à 6.

      Dans mon empressement, j'ai oublié de préciser les avantages de la virtualisation de serveur :

      - Il est possible de réaliser un serveur disposant de ressources et de fonctionnalités de haute disponibilité dignes d'équipement haut de gamme, le tout à partir de petits serveurs ordinaires, de type x86.
      - il est possible de changer du matériel en hot-plug à la volée, sans que les utilisateurs du serveur virtualisé ne s'en rendent compte ou soient incommodés par la panne.
      - il est possible de virtualiser plusieurs serveurs à partir des mêmes ressources (et donc potentiellement d'un seul et unique serveur matériel).
      - comme expliqué au-dessus, la grande souplesse et la grande sécurité permises dans les sauvegardes et les restaurations.

      Après m'être renseigné, il apparaît que VMWare ESX Server permet déjà de faire de la virtualisation sur grappes de serveurs, tandis que Microsoft Virtual Server ne le permettrait à priori pas, et souffrirait à priori d'une interface de gestion inadaptée, ainsi que d'une impossibilité de partage dynamique des entrées-sorties, du cache processeur et de la mémoire (d'où certainement son prix beaucoup moins élevé).

      • [^] # Re: Quelques interrogations

        Posté par  . Évalué à 9.

        Je vais tenter de répondre en fonction de ce que j'ai compris de tes interrogations.

        Kerrighed ne virtualise pas le système, il l'étend.
        Ce que je veux dire, c'est que des systèmes tels que VmWare et Xen font tourner un OS dans un OS (typiquement plusieurs machines virtuelles sur une seule machine). Les performances sont donc souvent moins bonnes ; les ressources sous jacentes étant toujours les mêmes le système qui accueille les machines virtuelles a toujours les mêmes limitations en terme de ressources disponibles (quoique Xen annonce des perfs excellentes et que les premiers tests que j'ai fais semblent le confirmer).
        Dans le cas de Kerrighed, c'est les fonctionnalités du noyau qui sont directement étendus au niveau de la grappe par des systèmes distribués. Kerrighed ne cherche pas à créer virtuellement des machines sur ou plusieurs machines dans le sens des systèmes tels que Xen, il vise à gérer globalement l'ensemble des ressources. Ainsi depuis un noeud de la grappe, il est possible d'utiliser les ressources des autres noeuds de manière transparente pour les applications.

        Je ne suis pas sûr d'avoir parfaitement compris tes questions, je ne suis donc pas certain d'y répondre. :-)

        • [^] # Re: Quelques interrogations

          Posté par  . Évalué à 5.

          Disons aussi que Xen peut faire tourner plusieurs OS qui peuvent être différent (noyau/prog/etc) et Kerrighed ne fait tourner qu'un OS (si j'ai bien compris).

          Je connais peu les cluster mais Kerrighed à l'aire très intéressant.

          NB : Xen peut aussi passer des OS virtualisés d'une machine (physique) à une autre :
          http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.ht(...)

          • [^] # Re: Quelques interrogations

            Posté par  . Évalué à 5.

            Exact.

            Pour résumer, je crois qu'on peut dire que des systèmes comme Xen visent à faire tourner X OS sur une machine physique, alors que l'approche SSI comme le système Kerrighed vise à faire tourner 1 OS sur X machines.

            Pour Xen, leur système de domaine est assez évolué et interessant, on peut effectivement faire l'équivalent d'un "checkpoint" de machine virtuelle.

    • [^] # Re: Quelques interrogations

      Posté par  (site web personnel) . Évalué à 7.

      Je crois qu'il ne faut pas penser à Kerrighed avec l'idée de la virtualisation. C'est plutôt à comparer avec OpenMosix ou OpenSSI.

      L'objectif est de faire un cluster (grappe), c'est à dire de prendre les ressources de n machines et de les mettre en commun. Le cluster se débrouille avec la mémoire et gère le déplacement des processus d'un noeud du cluster à un autre.

      Je remet le lien ci-dessus où il y a un comparatif entre Kerrighed, OpenMosix et OpenSSI.

      http://kerrighed.org/forum/viewtopic.php?t=40

      Personnellement, je ne connaissais pas Kerrighed et je vais le tester rapidement histoire de voir. OpenMosix m'a un peu laisser sur ma faim.

      http://openmosix.sourceforge.net/
      http://openssi.org/cgi-bin/view?page=openssi.html

      • [^] # Re: Quelques interrogations

        Posté par  . Évalué à 3.

        Impressionnant pour moi pauvre geek qui voudrais bien essayer ESX mais qui ne sait par quel bout le prendre, en effet, deux cartes reseaux intel dans le serveur, une freebox, mais je ne sais pas comment amener internet à mes serveurs virtuels .
        je vais quand meme essayer de comprendre ce truc impressionnant qu'est Kerrighed

        • [^] # Re: Quelques interrogations

          Posté par  . Évalué à 5.

          Je pense qu'une façon simple de tester Kerrighed est d'attendre la prochaine version de SSI-OSCAR (SSI-OSCAR 2.0) qui intègrera Kerrighed 1.0.0 et qui sera fondée sur OSCAR 4.0.

          http://ssi-oscar.irisa.fr/(...)
          http://www.openclustergroup.org/software.php(...)

          Pour résumer, OSCAR est une suite logicielle qui permet d'installer une grappe sans connaissances particulière en adminitration de grappe.
          SSI-OSCAR est l'intégration d'un SSI (en l'occurence Kerrighed pour le moment) dans OSCAR. SSI-OSCAR est un projet de l'INRIA, d'EDF R&D et de l'Oak Ridge National Laboratory.

          Avec SSI-OSCAR, l'installation est rapide et simple. A la fin de l'installation de la grappe, Kerrighed est configuré et prêt à être lancé.

  • # interrogations ...

    Posté par  (site web personnel) . Évalué à 3.

    le projet me semble assez interessant, le seul truc me chiffonnant est cette lacune sur la gestion de panne d'un noeud. n'ayant pas encore fait de test, je ne sais que penser. mais des qq informations sybilinnes sur le sujet, cela m'inquiete.

    qq1 a des infos sur le sujet ?

    • [^] # Re: interrogations ...

      Posté par  . Évalué à 2.

      Comme dit la news, c'est un projet encore en cours de développement. Les petits désagréments seront corrigés.

    • [^] # Re: interrogations ...

      Posté par  (site web personnel) . Évalué à 2.

      La "roadmap" annonce l'ajout et la suppression d'un noeud à chaud pour le mois d'avril (version 1.2)

      http://www.kerrighed.org/roadmap.html

      Ce qui un peu surprenant dans cette "roadmap", c'est la soudaine accélération du projet. 5 ans pour avoir une version 1.0 et ils annoncent la 1.2 pour avril, la 1.3 pour mai et la 1.4 pour juillet !

      J'ai pas été regarder les sources et je ne suis pas sur d'être capable d'y comprendre grand chose mais à mon avis, soit cette "roadmap" est irréaliste, soit tout est déjà quasiment fait et il s'agit plus de mise au point.

      Connaissant un peu le milieu universitaire, je pencherais plutôt pour la seconde solution.

      • [^] # Re: interrogations ...

        Posté par  . Évalué à 5.

        Ta seconde hypothèse est en effet le bonne :)

        Les fonctionnalités qui donnent l'illusion d'une machine unique ont été écrites "from scratch" au dessus d'un noyau Linux. Ce genre de développement est long et complexe.

        Aujourd'hui, la plupart des mécanismes ont été mit en oeuvre. Il nous reste principalement à stabiliser, porter sur certaines architectures (64bits, SMP) et offrir quelques nouvelles fonctionnalités.

        Des travaux plus complexes sont en cours et ne verront pas le jours avant au moins l'année prochaine. C'est principalement le cas pour la tolérance à la défaillance d'un noeud.

    • [^] # Re: interrogations ...

      Posté par  . Évalué à 2.

      En effet, Kerrighed ne supporte pas la défaillance d'un noeud. Lorsqu'un noeud tombe, le reste de la grappe est dans un état instable.

      Les projets concurrents comme openMosix ou OpenSSI n'ont pas de bonnes solutions à ce problème. Lorsqu'un noeud tombe, le reste de la grappe tourne plus ou moins bien suivant les cas.

      L'équipe Kerrighed travaille à la gestion des défaillances des noeuds. C'est un travaille long et complexe qui ne débouchera pas avant 2006.

      • [^] # Re: interrogations ...

        Posté par  (site web personnel) . Évalué à 3.

        Ce genre de gestion fait penser à de la HA qui pourrait interresser Linux même sans Kerrighed.

        Il me semblait que les fonctionnalités genre je sauvegardes complètement le contenu d'un process pour le remonter plus tard (genre au reboot par kde ou sur un autre noeud car le précédent à planté) était une des pistes pour le noyau 2.7.

        Bref, cela serait bien de regarder sur la lkml si des gens ne bossent pas déjà dessus pour des besoins similaires.

        "La première sécurité est la liberté"

      • [^] # Re: interrogations ...

        Posté par  (site web personnel) . Évalué à 3.

        oki :'(

        pour OpenMOSIX je suis entierement d'accord ( je n'ai pas testé OpenSSI ).

        actuellement, je torture des noyaux sur des histoires d'integration OpenMOSIX+SKAS pour faire tourner du user-mode-linux par dessus. et j'ai qq galere du à l'infra de OpenMOSIX.

        c pour cela que Kerrighed m'a plu quand j'ai vu passé la depeche. mais cette histoire d'instabilité me fait un peu peur, puisque j'aurais par dessus plein d'UML ( sinon ca sert a rien d'avoir le patch SKAS ;) ).

        une idee a la con pour les histoires de replication de processus et de gestion de defaillance ... à une époque le swap contenait une copie de la RAM ... si la RAM globale etait juste dumpé sur chacune des machines dans un swap les agregeant toutes ? et faire des snapshots en swap des etats stables ( genre toutes les n commutations de contextes ) ce qui fait que si un noeud tombe, la swap totale etant repliqué ... pas de soucis pour reprendre au dernier point d'arret.

        je dis ca, sans avoir vu le code de kerrighed et sans donc evaluer la complexite du "yaka" :|

        • [^] # Re: interrogations ...

          Posté par  . Évalué à 2.

          c'est drôle, j'avais en tête de faire le contraire, essayer de faire tourner Kerrighed au dessus de plein d'UML dispersés.

          L'idée est de mutualiser les ressources inutilisées de machines bureautiques (ou de toute autre machine qui n'est pas dédiée au cluster) au sein d'une seule machine virtuelle, sans avoir à patcher le noyau "du bas", et encore mieux, sans avoir les droits root pour lancer l'uml.

          Quelqu'un a des retours sur ce type d'expérience ?

  • # Il y a une question que je me pose

    Posté par  . Évalué à 3.

    A ma connaissance la difference entre un tread et un processus (fork) c'est que plusieur thread partage le meme espace memoire alors que les processus non.

    Donc la question est simple ,comment peuvent-ils faire migré les thread ? ne faut il pas qu'ils ai accés au meme espace memoire phisique ?

    • [^] # Re: Il y a une question que je me pose

      Posté par  . Évalué à 8.

      En effet, des threads partagent leur espace mémoire. Cependant ce partage ce fait au niveau de la mémoire virtuelle : ils partagent le même espace de mémoire virtuelle qui est associée à des pages en mémoire physique.

      Dans le système Kerrighed, un mécanisme de partage de mémoire globale permet de connecter leurs mémoires virtuelles. Les données utilisées par les threads situés sur des noeuds différents sont recopiées automatiquement dans la mémoire physique des noeuds et donc utilisablent par les threads.

      Plusieurs copies des données pouvant donc exister sur différents noeuds, un mécanisme de gestion de cohérence est utilisé. Il est comparable aux mécanismes de cohérence de caches dans les machines multi-processeur.

      • [^] # Re: Il y a une question que je me pose

        Posté par  (site web personnel) . Évalué à 3.

        Quel algo de distributions de mémoire est utilisé ?

        "La première sécurité est la liberté"

        • [^] # Re: Il y a une question que je me pose

          Posté par  (site web personnel) . Évalué à 3.

          Bon, j'ai trouvé ma réponse dans le manuel de référence (il est crade le pdf à l'écran, il semble que c'est une option habituelle qui manque à latex2pdf).

          C'est une architecture read replication/ write invalidation. C'est utilisé par SUN dans ses machines sous le nom "COMA" (cache only memory architecture).

          Je voulais savoir ce qui a amener à ce choix.

          "La première sécurité est la liberté"

          • [^] # Re: Il y a une question que je me pose

            Posté par  . Évalué à 1.

            Ce qui nous a ammené à ce choix est simplement qu'il s'agit à notre avis de la seule méthode permettant d'obtenir des performances correctes lorsque l'on veut faire du partage de mémoire automatique sur une grappe de PCs. Dans ce cas, le médium de communication n'est pas un bus à haut débit mais un réseau.

            D'autres méthodes existent, comme par exemple :

            - La mise à jour distante : chaque modification d'une donnée est répercutée sur toutes les copies existantes. Cette solution est extrémement couteuse en terme de débit réseau.

            - Ecritures multiples avec synchronisation des copies lors des points de synchronisation de l'application : solution très efficace mais très difficile à mettre en oeuvre et très gourmande en terme de consommation mémoire. Irréaliste à mettre en oeuvre dans un noyau d'OS (à notre avis).

            - Remote Direct Memory Access : la mémoire est partagée par des mécanismes hardware de certains types de réseaux (SCI, Infiniband, ...). Cette solution demande du matériel spécifique.

            - Etc...

            (Pour le PDF, je vais regénerer un version plus propre :) )

            • [^] # Re: Il y a une question que je me pose

              Posté par  (site web personnel) . Évalué à 2.

              Donc ton cas 1) c'est le write propagation.

              Le 2) est une sorte de merge style cvs ?

              Pour le 3) tu repose sur un réseau spécial.

              De ce que j'avais appris en DEA, il n'y avait pas d'algo plus interrescant que d'autres. Cela dépendait totalement du mode d'acces à la donnée.

              Si on prend un système de fichier comme exemple. Il y a le /home qui n'est utilisé à l'échelle de temps d'une machine que sur l'une d'elles. Les algo de migration seront ici les plus efficaces.
              Le /usr en lecture seul sera bien évidement plus efficace en read replication.

              Enfin bref, je croyais que un consensus était de pouvoir mixer les algo selon le comportement des applications sur les données. Mais j'imagines que cela doit devenir très complexe.

              "La première sécurité est la liberté"

              • [^] # Re: Il y a une question que je me pose

                Posté par  . Évalué à 1.

                Tu as totallement raison, il n'y a pas de meilleur algorithme de gestion de cohérence dans l'absolue. Cela dépend réellement du type d'accès aux données.

                Nous avons pour l'instant choisi l'algorithme d'invalidation sur écriture car c'est celui qui répondait le mieux à nos besoins. Nous envisageons d'intégrer d'autres mécanismes de gestion de cohérence. La manière dont nous avons conçu notre gestion globale des données permet de pouvoir changer le modèle de cohérence en fonction des besoins. Cependant, la finalisation de cette fonctionnalité est assez complexe et nous ne prévoyons pas d'y travailler avant quelques mois.

  • # Sous une emulation

    Posté par  . Évalué à 2.

    Voila je me posais la question suivante :
    Est ce que cela fonctionnerait sous un colinux ou un qemu ? L'interet
    serait d'utiliser les stations d'un park sans en changer le systeme d'exploitation. Sur un grand nombre de machine ca pourrait etre interressant je pense.

    Merci pour la reponse,

    • [^] # Re: Sous une emulation

      Posté par  . Évalué à 2.

      On retombe alors sur un problème à la virtualisation (xen, vmware, ...etc.). Actuellement, il n'y a pas de support "officiel" d'un système de virtualisation pour Kerrighed.
      Je commence à regarder Kerrighed sur Xen mais je ne sais pas actuellement ce que cela va donner et je ne sais pas combien de temps je vais pouvoir passer sur le sujet (ca ne fait pas parti de mes priorités).

      Pour Qemu et colinux, nous n'avons jamais regardé.

  • # OS et machines hétérogènes

    Posté par  . Évalué à 1.

    J'ai 2 machines:

    Duron 700 avec une Debian.
    Athlon 1500 avec une Gentoo.

    Est-ce que je peux installer ce système (ou OpenMosix ou autre), sachant que les machines auront des éxécutables différents?

    • [^] # Re: OS et machines hétérogènes

      Posté par  . Évalué à 5.

      La reponse rapide est non.

      Kerrighed est un système d'exploitation distribué. Il est essentiel pour le fonctionnement de Kerrighed d'avoir, sur chacun des noeuds, le meme binaire pour le système d'exploitation. En effet, des adresses mémoire distantes sont utilisées au sein meme de Kerrighed.

      Par ailleur, il est aussi nécessaire de disposer des memes versions binaires des logiciels (applications + bibliotheques dynamiques) sinon, c'est le segfault garantie.

      Je dirais que pour faire fonctionner Kerrighed sur ces machines, il faut disposer de la meme distrib sur l'ensemble des noeuds et compiler son noyau à partir d'une architecture commune (par i386).

      • [^] # Re: OS et machines hétérogènes

        Posté par  . Évalué à 2.

        Complétons la réponse :
        sous openssi par exemple, tu peux disposer de plusieurs "distributions" si tu veux. L'essentiel est que tu ais utilisé le même noyau patché openssi sur toutes les machines.

        Problème, relevé au commentaire plus haut : ton application devra faire des appels à des bibliothèques. Elles doivent être identiques (même version binaire...).

        A l'arrivée, tes différentes distributions, pour faire marcher tout ça de façon hétérogène, ça va être galère. Autant tout passer à une seule distribution, tu t'éviteras beaucoup de segfault et autres saloperies.

        • [^] # Re: OS et machines hétérogènes

          Posté par  . Évalué à 1.

          Est-ce qu'il existe un moyen de maintenir deux installations identiques sur mes deux machines?

          Par exemple avec debian, il faudrait apt-get installe tout sur les deux machines. Sauf pour certains logiciels comme les jeux ou les lecteurs audio/video qui seraient exclus de la repartition de charge et compilés de façon spécifique.

          Ce serait bien aussi de n'avoir qu'un seul /home et un seul /etc pour ne pas avoir à faire deux fois les configs, bref voir les deux machines comme une seule. Et si l'une d'entre elle tombe en panne, avoir tout en miroir pour continuer à l'utiliser comme si de rien n'était.

          J'en demande trop?

          • [^] # Re: OS et machines hétérogènes

            Posté par  . Évalué à 1.

            Non, tu n'en demande pas trop :)

            C'est bien là l'objectif de KerFS (Kerrighed File System). Kerrighed inclue en effet un système de fichiers dédié, qui vise à faire exactement ce que tu décris. Cependant, ce file system est encore en version Alpha, je recommande donc vivement de ne l'utiliser que pour expérimentation.

            • [^] # Re: OS et machines hétérogènes

              Posté par  . Évalué à 1.

              Ok j'attendrais un peu alors!

              Sinon je n'arrive pas à voir comment cela se passe au niveau des adresses IP. Si je démarre un serveur web sur une machine, est-ce que si je le fais migrer vers la deuxième et que j'éteins la première, mon serveur web va continuer à tourner?

              • [^] # Re: OS et machines hétérogènes

                Posté par  . Évalué à 1.

                Je précise que j'ai boucler il y a un mois mon projet de fin d'étude, un moteur de recherche distribué en Erlang, et par curiosité j'essaie de comparer les deux solutions.

            • [^] # Re: OS et machines hétérogènes

              Posté par  . Évalué à 2.

              Plutot que d'imposer de maintenir des distribs identiques sur chaque machine, ou de développer votre propre FS, est-ce que ça ne serait pas plus simple d'utiliser une système de fichier centralisé externe unique, qui utiliserait un FS distribué style GFS (maintenant redevenu libre) ?

              • [^] # Re: OS et machines hétérogènes

                Posté par  . Évalué à 1.

                Intégrer des solutions déjà existantes est l'approche de OpenSSI et le problème est alors de trouver une solution pour que cette intégration soit efficace, c'est-à-dire que les différents systèmes prennent des décisions qui ne soient pas contradictoires et qui soient globalement homogènes. Dans la pratique, cela est très difficile à faire. Les développements sont donc plus rapides en intégrant des solutions existantes, mais il est alors très difficile d'obtenir de bonnes performances (cf comparaison Kerrighed contre OpenSSI).
                Par contre, cela n'empêche pas de regarder ce qui se fait dans les autres systèmes pour de notre côté mettre en oeuvre des solutions intéressantes et pertinantes.

  • # migration de flux

    Posté par  . Évalué à 1.

    Le descriptif de Kerrighed parle de "migration efficace de flux". Est-ce que cela sous-entend que les états TCP migrent (d'un noeud à l'autre) avec les processus communicants ? Ou bien un noeud particulier (celui où la connexion a été initialement établie) joue le rôle de "proxy TCP" ?

    • [^] # Re: migration de flux

      Posté par  . Évalué à 2.

      En effet, avec kerrighed les processus migrent vraiment avec les sockets (tubes, sockets unix, tcp) qu'ils avaient ouverts. Les flux ne passent pas par un proxy intermédiaire (comme avec OpenMosix).

      • [^] # Re: migration de flux

        Posté par  . Évalué à 3.

        Un socket (TCP) n'est pas propre à un processus (ou à un thread) - plusieurs processus (ou threads) peuvent partager un même socket. Dans ce cas comment gérer la situation ou deux processus partageant le même socket s'exécutent sur deux noeuds différents ? Merci pour vos réponses.

        • [^] # Re: migration de flux

          Posté par  . Évalué à 1.

          Pour les questions techniques de ce genre, il ne faut pas hésitez à poster des messages sur le forum de Kerrighed :
          http://kerrighed.org/forum/(...)
          Nous ne sommes pas tous en même temps sur linuxfr.org mais en postant sur le forum de Kerrighed, tu es sûr que la personne concernée de l'équipe lira le message. :-)

          • [^] # Re: migration de flux

            Posté par  . Évalué à 2.

            Ok j'ai poursuivi la discussion sur Kerrighed Forum Forum Index -> Kerrighed Discussion. Merci.

        • [^] # Re: migration de flux

          Posté par  . Évalué à 3.

          Les différents flux au sein de Kerrighed reposent sur la notion de flux dynamique.

          Un flux dynamique se caractérise par un ensemble d'extrémités distribuées (deux dans le cas d'un flux de type tcp). La notion d'extrémité distribuée veut simplement dire que des références à une même extrémité peuvent exister sur des noeuds différents. La mécanique des flux dynamiques assurent la gestion et le déplacement des références au sein de la grappe: à partir d'une référence d'une extrémité distribuée, ce mécanisme fournit l'adresse physique de son interlocuteur au sein de l'extrémité "opposée".

          A partir de ce mécanisme générique, les interfaces de communication classique (notamment socket inet, socket unix, pipe) sont (partiellement) re-implementé.

          Donc si l'on prend l'exemple de plusieurs processus partageant une meme socket: en pratique chacun des processus va disposer de sa propre socket qui seront chacune liée à une référence de la même extrémité distribuée. Lors d'une communication interne à Kerrighed, le message est transmit à partir de la socket initial par la flux dynamique au destinataire.

          J'espère avoir (au moin partiellement) répondu à la question.

  • # Dans linux ?

    Posté par  (site web personnel) . Évalué à 2.

    Est-ce que Kerrigued est prévu à terme pour être inclus dans Linux de base ?

    "La première sécurité est la liberté"

    • [^] # Re: Dans linux ?

      Posté par  . Évalué à 2.

      Par le passé, il a clairement été dit qu'aucun hook noyau ne serait intégré directement dans le noyau Linux si ce hook était spécifique à un système pour clusters.
      Il faudrait donc faire une proposition commune avec d'autres systèmes pour le clustering. Les choses bougent à ce sujet mais rien n'est encore fait.

      • [^] # Re: Dans linux ?

        Posté par  (site web personnel) . Évalué à 3.

        Je pose la question car kerrighed commence à devenir bien gros et les dev linux ont horreur des gros patchs.

        Mais j'imagine que certaines parties ne sont pas spécifique au SSI. Cela pourrait être interrescant de tenter l'inclusion de ses parties en douceur.

        Je pense notament à votre gestion de reprise d'erreur qui doit forcement interresser tout ceux qui font du HA.

        "La première sécurité est la liberté"

  • # Conférence sur Kerrighed aux RMLL

    Posté par  (site web personnel) . Évalué à 2.

    Salut,

    L'équipe de Kerrighed sera aux Rencontres Mondiales du Logiciel Libre cette année, et réalisera deux conférences. La première sera un tour d'horizon des systèmes à image unique, avec un état de l'art, la seconde portera plus spécifiquement sur Kerrighed.

    Voir http://www.rencontresmondiales.org/sections/conference/noyau_et_sys(...) pour plus d'informations.

    Il est possible que Moshe Bar, du projet OpenMosix soit également présent pour parler de son projet.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.