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.
[^] # 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.