Quand ils font des requêtes sur un seul noeud du cluster Mosix, il y a une perte de 23%, alors qu'avec une répartition de charge en amont, il n'y a plus de perte ?
La machine qui reçoit les requêtes migre un grande partie de ses processus, il apparaît qu'il existe un problème de gestion des signaux en surcharge (cas de tous les tests). Ainsi un "killall -9 exe migré" pose problème. Le serveur qui a lancé le processus n'est donc pas informé de l'arrêt du processus migré, c'est pourquoi nous avons 23% des requêtes qui sont perdues. (J'ai été surpris aussi, et j'ai répété plusieurs fois le même test)
Quand la charge est répartie en amont, chaque noeud migre beaucoup moins de processus, le réseau n'est pas saturé, on constate que l'ensemble des processus migrés par chaque machine est correctement géré.
Comment ça se fait-ce-t-il ? Ça ne voudrait-il pas dire que la répartition de charge, dans ce cas, se passe surtout dans le procédé en amont plutôt que par Mosix ?
Il y a effectivement une double répartition des charges. En amont nous répartissons suivant une loi de poisson, afin de simuler des arrivées de requêtes approximant la réalité. Ainsi chaque machine ne reçoit pas le même nombre de requêtes à des instants réguliers. La deuxième répartition est effectuée par MOSIX, qui comme nous le montrons, permet d'obtenir un gain intéressant.
La répartition en amont peut donc être assimilée à celle effectuée par un dns tournant.
Est-ce que les gains de performances ne peuvent-ils alors pas venir du fait des modifications de Mosix dans le scheduler du noyau ?
Les modifications apportées par MOSIX au scheduler, ne changent pas la donne. Grossièrement, elles permettent juste de déterminer si un processus sera migré ou non. La répartition de la charge sur un noeud reste identique. Il aurait été intéressant de compiler un noyau avec le scheduler RealTime de RMS, mais je pense qu'il n'est pas fait pour des serveurs. (Il suffit de lancer 2 processus demandant des accés disque volumineux pour s'en rendre compte)
Bref, est-ce qu'un cluster Mosix est tolérant aux pannes ?
Pas totalement, il faut bien avouer qu'il faut un certain temps avant qu'un incident soit détecté (suivant le type des processus migrés). Mais un processus peut être relancé par la machine d'origine grâce à la partie "deputy" qu'elle conserve et avec laquelle l'application migrée converse.
[^] # Re: Résultats bizarres
Posté par Gads . En réponse à la dépêche Test de MOSIX (ferme de serveurs HTTP). Évalué à 10.
La machine qui reçoit les requêtes migre un grande partie de ses processus, il apparaît qu'il existe un problème de gestion des signaux en surcharge (cas de tous les tests). Ainsi un "killall -9 exe migré" pose problème. Le serveur qui a lancé le processus n'est donc pas informé de l'arrêt du processus migré, c'est pourquoi nous avons 23% des requêtes qui sont perdues. (J'ai été surpris aussi, et j'ai répété plusieurs fois le même test)
Quand la charge est répartie en amont, chaque noeud migre beaucoup moins de processus, le réseau n'est pas saturé, on constate que l'ensemble des processus migrés par chaque machine est correctement géré.
Il y a effectivement une double répartition des charges. En amont nous répartissons suivant une loi de poisson, afin de simuler des arrivées de requêtes approximant la réalité. Ainsi chaque machine ne reçoit pas le même nombre de requêtes à des instants réguliers. La deuxième répartition est effectuée par MOSIX, qui comme nous le montrons, permet d'obtenir un gain intéressant.
La répartition en amont peut donc être assimilée à celle effectuée par un dns tournant.
Les modifications apportées par MOSIX au scheduler, ne changent pas la donne. Grossièrement, elles permettent juste de déterminer si un processus sera migré ou non. La répartition de la charge sur un noeud reste identique. Il aurait été intéressant de compiler un noyau avec le scheduler RealTime de RMS, mais je pense qu'il n'est pas fait pour des serveurs. (Il suffit de lancer 2 processus demandant des accés disque volumineux pour s'en rendre compte)
Pas totalement, il faut bien avouer qu'il faut un certain temps avant qu'un incident soit détecté (suivant le type des processus migrés). Mais un processus peut être relancé par la machine d'origine grâce à la partie "deputy" qu'elle conserve et avec laquelle l'application migrée converse.
En espérant avoir répondu à vos interrogations.