La société Kerlabs a été fondée pour industrialiser et commercialiser Kerrighed. Kerrighed est un logiciel qui existe depuis longtemps au sein de l'INRIA mais qui n'a jamais réussit à atteindre une maturité suffisante pour être utilisé réellement en production. Le rôle d'un laboratoire comme l'INRIA n'étant pas de créer des produits mais de prouver des nouveaux concepts.
La mise au point pour atteindre une qualité industrielle est une tâche d'ingénierie, qui n'a pas sa place au sein d'un laboratoire de recherche. C'est pourquoi le projet est longtemps resté un prototype et c'est l'une des raisons de la création de la société : passer d'un prototype à un produit.
La création de la société n'est pas une réaction "hostile" envers l'INRIA mais bien une continuité. Kerlabs étant une "spin-off" de l'INRIA. L'INRIA continue d'ailleurs à travailler sur le projet.
Et en effet, la création de la société permet de générer un flux d'argent permettant de financer le développement du projet. Une autre raison de la création de la société.
Nous en sommes bien conscient, c'est pour cette raison que nous travaillons dans ce sens.
Cependant, ceci ne constitue pas un frein pour tout le monde. Certaines catégories d'utilisateurs n'ont pas besoin d'ajout/retrait et acceptent des défaillances occasionnelles (qui sont somme toute relativement peu fréquentes sur un cluster de taille modeste) en échange d'une plus grande facilité et souplesse d'utilisation.
Pour autant, afin de satisfaire la plus large gamme possible d'utilisateurs, nous travaillons à la mise en oeuvre des éléments d'ajout/retrait et de tolérance aux pannes, indispensables pour nombre d'utilisateurs.
Le tolérance aux pannes n'est toujours pas fonctionnelle. Le travail est toujours en cours et devrait déboucher l'année prochaine.
Concernant le hot-plug, une version très expérimentale est actuellement présente dans le code. Cette fonctionnalité devrait être disponible en version stable d'ici à la fin de cette année.
C'est pas faux. Plusieurs news ayant déjà été postées à propos de Kerrighed ([1] [2]) je n'ai pas jugé bon de rappeler l'objectif du projet, surtout pour un journal. Erreur de ma part...
Mais comme "Glaflemme", je te laisse aller lire les références citées ci-dessous ;)
L'expérience (Mosix, openMosix, openSSI et Bproc) montre que faire rentrer du code SSI dans le noyau est très difficile. Aucun des projets cité n'a réussit à faire entrer quoi que ce soit dans le main stream.
Néanmoins, nous allons animer un BOF au prochain Linux Symposium pour discuter de la potentielle inclusion d'une partie de Kerrighed. Il s'agit du mécanisme central de Kerrighed : les KDDM (anciennement connu sous le nom de conteneurs). Ce mécanisme est très peu intrusif, il ne nécessite que 2/3 lignes de patch au noyau, plus le code du mécanisme lui-même.
L'équipe de développement de Kerrighed n'a pas posté de news "officielle" ici pour la version 2.0.0 car il s'agit d'une version de transition. Le projet Kerrighed a connu des mutations importantes durant les 2 dernières années. Notamment, le projet est sorti du giron de l'INRIA. Il n'est plus développé par l'Université de Rennes, et l'INRIA n'est désormais plus qu'un contributeur comme les autres. Une société (Kerlabs) a vu le jour en Novembre 2006 avec pour objectif (entre autres) de poursuivre le développement communautaire de Kerrighed.
La version 2.0.0 est une version de transition entre le produit de recherche issus de l'INRIA et un produit communautaire qui a le soutient d'une société et qui vise à pouvoir être utilisé en production. Kerrighed a longtemps été un pur produit de recherche, un "démonstrateur" dont l'objectif était de mettre en avant des possibilités techniques. Beaucoup de fonctionnalités "flashies", mais une stabilité très incertaine.
La version 2.0.0 marque donc une première étape vers une nouvelle version avec moins de fonctionnalités, mais plus de stabilité. L'objectif est d'obtenir une version avec moins de fonctionnalités, mais plus solide et plus proche des réalités matérielles des clusters modernes (support SMP et 64 bits). Cette version est prévu pour cet été. Les fonctionnalités présentes dans la version "recherche" seront dès lors réintégrés progressivement dans les versions successives de Kerrighed.
Comme le fait justement remarquer ragoutoutou, les objectifs ne sont pas les fonctionnalités :) Voir la page current status du nouveau site Kerrigned pour avoir un aperçu des réelles fonctionnalités et de la roadmap de réintégration des fonctionnalités de recherche dans la version stable.
A noter enfin que le travail de portage en 2.6 n'a pas été si complexe que cela. Le très long délais entre la version 2.4 et cette version 2.6 est principalement dû à une réorganisation du développement sur Kerrighed et un énorme travail de refactoring sur le code. Dernière chose : l'accès au code et aux mailing-lists de développement est désormais totalement libre (https://gforge.inria.fr/projects/kerrighed/) et le code sera bientôt déplacé sur une forge communautaire.
Tout d'abord sur une architecture 32 bits, ce n'est pas possible. Tout simplement parce que le processeur ne peut adresser au maximum que 4Go (exception faite du PAE qui n'est pas supporté par Kerrighed). C'est une limite hard qu'on ne peut pas contourner. Ton malloc de 50 Go va donc échouer, même sur Kerrighed.
Sur une architecture 64 bits, le malloc de 50 Go va fonctionner et grâce à Kerrighed, tu auras accès au 50 Go du cluster, mais à travers la mémoire locale du noeud où tourne ton processus. La mémoire des autres noeuds sera vu comme un niveau supplémentaire de la hiérarchie mémoire, un peu comme le swap, mais en beaucoup plus performant si tu utilises un réseau à haut débit.
A noter que cette fonctionnalité fait partie des fonctionnalités débranchées dans la prochaine version.
Cette étude a été réalisé durant l'été 2004, il y a plus de 2 ans donc.
Même si les 3 systèmes n'ont pas radicalement changés depuis, il serait très hasardeux de considérer le contenu de ce document comme argent comptant. Mais dans les grandes lignes, je pense que les grandes tendances sont toujours d'actualité.
A ma connaissance, OpenMosix utilise toujours la députation, ce qui induit des problèmes de performance important pour les communications et l'accès aux fichiers.
OpenSSI ne bouge plus beaucoup et ne semble pas avoir modifié son architecture interne, ne changeant donc pas de manière significative les résultats de l'étude.
Enfin, Kerrighed conserve une architecture tournée vers la performance, même si la prochaine version verra ses performances diminuer sensiblement. Une forte réorganisation du code nous a conduit à débrancher temporairement certains modules destinés à assurer de meilleurs performances que les autres systèmes. Ces modules seront rebranchés dans les mois à venir.
Il y aura une version expérimentale de la gestion des défaillances. C'est un sujet sur lequel nous travaillons actuellement et qui reste très épineux. Cette version de la gestion des défaillances devrait cependant être relativement fonctionnelle.
En fait, nous pensons faire une dépêche plus globale avec la sortie d'une nouvelle version de Kerrighed, notre présence à Solutions Linux, le Kerrighed Summit et l'annonce officielle de la création de Kerlabs dans pas longtemps.
On attend pour cela que pouvoir sortir une version "présentable". C'est une question de 2/3 semaines. Juste avant Solutions Linux quoi :)
Il est vrai que le projet Kerrighed ne communique pas beaucoup depuis quelques temps. Mais il n'est pas mort, loin de là.
Les principaux développeurs du projet viennent de créer une entreprise, spin-off de l'Inria, dont l'objectif est de faire de Kerrighed un véritable produit de qualité industrielle, tout en gardant le code en open source.
D'autre part, un projet Européen de grande ampleur vient de démarrer (XtreemOS). Celui-ci utilise Kerrighed comme base pour certaines parties de son infrastructure.
Le portage en 2.6 n'est pas le point qui a réellement posé problème. L'année 2006 a été passée à faire un très gros travail de refactoring pour rationaliser le code, le rendre plus cohérent afin de poser les bases des futurs développements. C'est cette partie qui a demandé beaucoup de temps. Des versions devraient sortir beaucoup plus fréquemment durant l'année à venir.
Nous posterons bientôt (début janvier) une news ici même pour annoncer la sortie de la prochaine version et donner plus d'informations autour de ce projet.
De nombreuses animations ont souffert du "montage" des différents jeux de slides en un seul fichier. Principalement les flèches qui partent dans tous les sens.
Bon, c'est vrai, on a un peu pompé le style graphique du site KDE.
Faut dire qu'on est des hackers noyau, pas des artistes, alors voila, on fait ce qu'on peut pour faire un site pas trop moche :)
D'ailleurs, si une âme généreuse veut nous concevoir une charte graphique bien à nous, histoire qu'on ne plagie plus honteusement la charte graphique du site KDE, on acceptera avec plaisir !!!
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.
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.
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 :) )
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.
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.
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: Direction...
Posté par Renaud Lottiaux . En réponse au message 3 stages à pourvoir sur Kerrighed chez Kerlabs. Évalué à 2.
Pour être honnête, je ne fréquente jamais les forums de LinuxFR. Du coup, je ne connaissais pas cette rubrique.
Le journal a été déplacé et je le saurais pour la prochaine fois ;)
[^] # Re: De la nécessité de fonder la société Kerlabs ?
Posté par Renaud Lottiaux . En réponse au journal Stage sur Kerrighed chez Kerlabs. Évalué à 4.
La mise au point pour atteindre une qualité industrielle est une tâche d'ingénierie, qui n'a pas sa place au sein d'un laboratoire de recherche. C'est pourquoi le projet est longtemps resté un prototype et c'est l'une des raisons de la création de la société : passer d'un prototype à un produit.
La création de la société n'est pas une réaction "hostile" envers l'INRIA mais bien une continuité. Kerlabs étant une "spin-off" de l'INRIA. L'INRIA continue d'ailleurs à travailler sur le projet.
Et en effet, la création de la société permet de générer un flux d'argent permettant de financer le développement du projet. Une autre raison de la création de la société.
[^] # Re: Tolérance de panne, hot plug...
Posté par Renaud Lottiaux . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 2.
Cependant, ceci ne constitue pas un frein pour tout le monde. Certaines catégories d'utilisateurs n'ont pas besoin d'ajout/retrait et acceptent des défaillances occasionnelles (qui sont somme toute relativement peu fréquentes sur un cluster de taille modeste) en échange d'une plus grande facilité et souplesse d'utilisation.
Pour autant, afin de satisfaire la plus large gamme possible d'utilisateurs, nous travaillons à la mise en oeuvre des éléments d'ajout/retrait et de tolérance aux pannes, indispensables pour nombre d'utilisateurs.
[^] # Re: Tolérance de panne, hot plug...
Posté par Renaud Lottiaux . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 3.
Concernant le hot-plug, une version très expérimentale est actuellement présente dans le code. Cette fonctionnalité devrait être disponible en version stable d'ici à la fin de cette année.
[^] # Re: Sortie de Glaflemme d'expliquer en version 2.1 alpha M1
Posté par Renaud Lottiaux . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 2.
Mais comme "Glaflemme", je te laisse aller lire les références citées ci-dessous ;)
[1] http://linuxfr.org/2005/02/25/18383.html
[2] http://linuxfr.org/2007/04/17/22376.html
[^] # Re: 2.0.0 : une version de transition
Posté par Renaud Lottiaux . En réponse à la dépêche Avec Kerrighed 2.0.0, Linux a les deux pieds dans le SMP. Évalué à 3.
Néanmoins, nous allons animer un BOF au prochain Linux Symposium pour discuter de la potentielle inclusion d'une partie de Kerrighed. Il s'agit du mécanisme central de Kerrighed : les KDDM (anciennement connu sous le nom de conteneurs). Ce mécanisme est très peu intrusif, il ne nécessite que 2/3 lignes de patch au noyau, plus le code du mécanisme lui-même.
# 2.0.0 : une version de transition
Posté par Renaud Lottiaux . En réponse à la dépêche Avec Kerrighed 2.0.0, Linux a les deux pieds dans le SMP. Évalué à 10.
La version 2.0.0 est une version de transition entre le produit de recherche issus de l'INRIA et un produit communautaire qui a le soutient d'une société et qui vise à pouvoir être utilisé en production. Kerrighed a longtemps été un pur produit de recherche, un "démonstrateur" dont l'objectif était de mettre en avant des possibilités techniques. Beaucoup de fonctionnalités "flashies", mais une stabilité très incertaine.
La version 2.0.0 marque donc une première étape vers une nouvelle version avec moins de fonctionnalités, mais plus de stabilité. L'objectif est d'obtenir une version avec moins de fonctionnalités, mais plus solide et plus proche des réalités matérielles des clusters modernes (support SMP et 64 bits). Cette version est prévu pour cet été. Les fonctionnalités présentes dans la version "recherche" seront dès lors réintégrés progressivement dans les versions successives de Kerrighed.
Comme le fait justement remarquer ragoutoutou, les objectifs ne sont pas les fonctionnalités :) Voir la page current status du nouveau site Kerrigned pour avoir un aperçu des réelles fonctionnalités et de la roadmap de réintégration des fonctionnalités de recherche dans la version stable.
A noter enfin que le travail de portage en 2.6 n'a pas été si complexe que cela. Le très long délais entre la version 2.4 et cette version 2.6 est principalement dû à une réorganisation du développement sur Kerrighed et un énorme travail de refactoring sur le code. Dernière chose : l'accès au code et aux mailing-lists de développement est désormais totalement libre (https://gforge.inria.fr/projects/kerrighed/) et le code sera bientôt déplacé sur une forge communautaire.
[^] # Re: Question
Posté par Renaud Lottiaux . En réponse au journal Premier Kerrighed Summit le 2 Février. Évalué à 2.
Tout d'abord sur une architecture 32 bits, ce n'est pas possible. Tout simplement parce que le processeur ne peut adresser au maximum que 4Go (exception faite du PAE qui n'est pas supporté par Kerrighed). C'est une limite hard qu'on ne peut pas contourner. Ton malloc de 50 Go va donc échouer, même sur Kerrighed.
Sur une architecture 64 bits, le malloc de 50 Go va fonctionner et grâce à Kerrighed, tu auras accès au 50 Go du cluster, mais à travers la mémoire locale du noeud où tourne ton processus. La mémoire des autres noeuds sera vu comme un niveau supplémentaire de la hiérarchie mémoire, un peu comme le swap, mais en beaucoup plus performant si tu utilises un réseau à haut débit.
A noter que cette fonctionnalité fait partie des fonctionnalités débranchées dans la prochaine version.
[^] # Re: SSI
Posté par Renaud Lottiaux . En réponse au journal Premier Kerrighed Summit le 2 Février. Évalué à 4.
Même si les 3 systèmes n'ont pas radicalement changés depuis, il serait très hasardeux de considérer le contenu de ce document comme argent comptant. Mais dans les grandes lignes, je pense que les grandes tendances sont toujours d'actualité.
A ma connaissance, OpenMosix utilise toujours la députation, ce qui induit des problèmes de performance important pour les communications et l'accès aux fichiers.
OpenSSI ne bouge plus beaucoup et ne semble pas avoir modifié son architecture interne, ne changeant donc pas de manière significative les résultats de l'étude.
Enfin, Kerrighed conserve une architecture tournée vers la performance, même si la prochaine version verra ses performances diminuer sensiblement. Une forte réorganisation du code nous a conduit à débrancher temporairement certains modules destinés à assurer de meilleurs performances que les autres systèmes. Ces modules seront rebranchés dans les mois à venir.
[^] # Re: Dépêche ?
Posté par Renaud Lottiaux . En réponse au journal Premier Kerrighed Summit le 2 Février. Évalué à 1.
[^] # Re: Dépêche ?
Posté par Renaud Lottiaux . En réponse au journal Premier Kerrighed Summit le 2 Février. Évalué à 1.
On attend pour cela que pouvoir sortir une version "présentable". C'est une question de 2/3 semaines. Juste avant Solutions Linux quoi :)
[^] # Re: SSI-OSCAR
Posté par Renaud Lottiaux . En réponse à la dépêche OSCAR sort en version 5.0. Évalué à 6.
Les principaux développeurs du projet viennent de créer une entreprise, spin-off de l'Inria, dont l'objectif est de faire de Kerrighed un véritable produit de qualité industrielle, tout en gardant le code en open source.
D'autre part, un projet Européen de grande ampleur vient de démarrer (XtreemOS). Celui-ci utilise Kerrighed comme base pour certaines parties de son infrastructure.
Le portage en 2.6 n'est pas le point qui a réellement posé problème. L'année 2006 a été passée à faire un très gros travail de refactoring pour rationaliser le code, le rendre plus cohérent afin de poser les bases des futurs développements. C'est cette partie qui a demandé beaucoup de temps. Des versions devraient sortir beaucoup plus fréquemment durant l'année à venir.
Nous posterons bientôt (début janvier) une news ici même pour annoncer la sortie de la prochaine version et donner plus d'informations autour de ce projet.
[^] # Re: Slides atelier OS
Posté par Renaud Lottiaux . En réponse à la dépêche Vidéos des RMLL 2006. Évalué à 2.
Thomas a stocké les présentations avant montage ici : http://thomas.enix.org/pub/conf/rmll2006/original/
[^] # Re: Dépannage
Posté par Renaud Lottiaux . En réponse au journal Création d'une charte graphique pour le site web de Kerrighed. Évalué à 1.
Mais au point où on en est, je crois que l'on va attendre d'avoir une vraie charte graphique bien à nous avant de changer le look du site.
Pour ce qui est de VMWare, on a pas essayé.
[^] # Re: ressemblance
Posté par Renaud Lottiaux . En réponse au journal Nouveau Logo pour Kerrighed. Évalué à 4.
Bon, c'est vrai, on a un peu pompé le style graphique du site KDE.
Faut dire qu'on est des hackers noyau, pas des artistes, alors voila, on fait ce qu'on peut pour faire un site pas trop moche :)
D'ailleurs, si une âme généreuse veut nous concevoir une charte graphique bien à nous, histoire qu'on ne plagie plus honteusement la charte graphique du site KDE, on acceptera avec plaisir !!!
[^] # Re: Il y a une question que je me pose
Posté par Renaud Lottiaux . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 1.
http://www.cs.rice.edu/~willy/TreadMarks/overview.html(...)
[^] # Re: Il y a une question que je me pose
Posté par Renaud Lottiaux . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 1.
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.
[^] # Re: OS et machines hétérogènes
Posté par Renaud Lottiaux . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 1.
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: Il y a une question que je me pose
Posté par Renaud Lottiaux . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 1.
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: interrogations ...
Posté par Renaud Lottiaux . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 2.
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: Il y a une question que je me pose
Posté par Renaud Lottiaux . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 8.
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: interrogations ...
Posté par Renaud Lottiaux . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 5.
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.