Oui, d'ailleurs à ce propos, la dernière fois que j'avais regardé (ça fait pas mal de temps), Kerrighed ne supportait UDP avec l'extérieur (ce qui est quelque peu gênant pour faire tourner des serveurs de jeu). Qu'en est-il aujourd'hui ?
La situation devrait s'être améliorée (je dis bien devrais car je n'ai pas testé la cas de l'UDP), mais ce n'est pas encore transcendant. En effet, la solution temporaire est une indirection systématique des flux IP vers le noeud à l'origine de ces flux. Du coup, cela crée une dépendance entres des noeuds qui n'est ni utile ni souhaitable. C'est une solution à ce problème que j'espère apporter d'ici le début 2008.
Le scénario que tu présentes correspond exactement à ce que nous imaginons et à ce sur quoi nous travaillons. Les manques de Kerrighed (en terme de fonctionnalité) ne sont plus si important que cela. Le principaux manques concernent les capacités (actuellement fonctionnelles mais limitées) de communication entre un processus s'exécutant au sein de Kerrighed et un client quelconque hors Kerrighed.
Concernant le problème du coût de migration, je serais tenté de dire que tout dépend de ton application ;). En effet, déplacer un processus est en soit une opération simple et (presque) en temps constant: seul les infos systèmes doivent être déplacé. Pour le reste (principalement la mémoire utilisé par l'application), le mécanisme peut être rapproché (en approximation très grossière) de ce qui se fait pour le swap. Lorsque l'application veut accéder à une zone mémoire qui n'a pas encore été rapatrié... et bien on le fait! Exactement pareil que lorsqu'un bout de la mémoire se trouve sur le disque sous forme de swap. Du coup, le coût du déplacement n'est pas tellement au moment du déplacement effectif du processus mais ultérieurement (au cas par cas) lorsque les pages mémoires sont accédées.
Cela permet en pratique d'avoir un temps d'interruption "limité" de l'application.
Je terminerais par une petite remarque concernant Kerrighed et les matériels de communication. La couche de comm de Kerrighed est principalement lié au système de communication de Linux (netdevice et plus récemment TIPC pour les intimes), par conséquent, si celui-ci supporte un matériel avec un niveau de perf donnée, Kerrighed supportera le même matériel avec sensiblement le même niveau de performance.
L'étude à laquelle tu fais référence est relativement ancienne. Kerrighed ainsi que les deux autres SSIs ont beaucoup évolué, et je pense qu'il serait hazardeux pour quiconque d'en extrapoler les résultats. Pour le moment, nous n'envisageons pas de refaire l'étude et nous restons concentré sur la stabilisation ainsi que des fonctionnalités majeures telles que le support du SMP.
Concernant le couple kerrighed/apache, il s'agit d'un sujet qui me tient particulièrement à coeur, exactement pour les raisons que tu suggères. Je pense qu'il y a un réel intérêt à faire coopérer ces 2 logiciels, mais actuellement Kerrighed n'offre pas encore toutes les fonctionnalités requises pour un fonctionnement simple et performant. C'est un des points sur lesquels nous allons probablement travailler dans les mois à venir. Je t'invite à reposer ta question d'ici à l'année prochaine ;).
Enfin, concernant les technologies d'interconnexion au sein d'un SSI, il est vrai que plus le réseau est performant mieux c'est (en particulier du point de vu des latences). Heureusement pour nous, le gigabit c'est largement démocratisé, et les technos au 10 GBits commencent à poindre à l'horizon.
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.
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: Performances
Posté par Pascal Gallard . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 1.
La situation devrait s'être améliorée (je dis bien devrais car je n'ai pas testé la cas de l'UDP), mais ce n'est pas encore transcendant. En effet, la solution temporaire est une indirection systématique des flux IP vers le noeud à l'origine de ces flux. Du coup, cela crée une dépendance entres des noeuds qui n'est ni utile ni souhaitable. C'est une solution à ce problème que j'espère apporter d'ici le début 2008.
[^] # Re: Performances
Posté par Pascal Gallard . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 3.
Concernant le problème du coût de migration, je serais tenté de dire que tout dépend de ton application ;). En effet, déplacer un processus est en soit une opération simple et (presque) en temps constant: seul les infos systèmes doivent être déplacé. Pour le reste (principalement la mémoire utilisé par l'application), le mécanisme peut être rapproché (en approximation très grossière) de ce qui se fait pour le swap. Lorsque l'application veut accéder à une zone mémoire qui n'a pas encore été rapatrié... et bien on le fait! Exactement pareil que lorsqu'un bout de la mémoire se trouve sur le disque sous forme de swap. Du coup, le coût du déplacement n'est pas tellement au moment du déplacement effectif du processus mais ultérieurement (au cas par cas) lorsque les pages mémoires sont accédées.
Cela permet en pratique d'avoir un temps d'interruption "limité" de l'application.
Je terminerais par une petite remarque concernant Kerrighed et les matériels de communication. La couche de comm de Kerrighed est principalement lié au système de communication de Linux (netdevice et plus récemment TIPC pour les intimes), par conséquent, si celui-ci supporte un matériel avec un niveau de perf donnée, Kerrighed supportera le même matériel avec sensiblement le même niveau de performance.
[^] # Re: Performances
Posté par Pascal Gallard . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 4.
Concernant le couple kerrighed/apache, il s'agit d'un sujet qui me tient particulièrement à coeur, exactement pour les raisons que tu suggères. Je pense qu'il y a un réel intérêt à faire coopérer ces 2 logiciels, mais actuellement Kerrighed n'offre pas encore toutes les fonctionnalités requises pour un fonctionnement simple et performant. C'est un des points sur lesquels nous allons probablement travailler dans les mois à venir. Je t'invite à reposer ta question d'ici à l'année prochaine ;).
Enfin, concernant les technologies d'interconnexion au sein d'un SSI, il est vrai que plus le réseau est performant mieux c'est (en particulier du point de vu des latences). Heureusement pour nous, le gigabit c'est largement démocratisé, et les technos au 10 GBits commencent à poindre à l'horizon.
[^] # Re: migration de flux
Posté par Pascal Gallard . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 3.
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.
[^] # Re: OS et machines hétérogènes
Posté par Pascal Gallard . En réponse à la dépêche Sortie de la version 1.0.0 de Kerrighed. Évalué à 5.
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).