Test de MOSIX (ferme de serveurs HTTP)

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
18
mar.
2002
Linux
MOSIX permet de créer facilement des clusters sous Linux, en effectuant un "load-balancing" des processus sur un ensemble de machines.

Ce rapport explique la manière dont opère MOSIX à différents niveaux du système.
De plus il présente un ensemble de tests permettant d'évaluer le gain apporté dans le cas d'une ferme de serveurs HTTP dont les requêtes sont coûteuses en temps de calcul.

MOSIX apparaît très intéressant de part sa facilité d'installation et le gain notable qu'il apporte.

Aller plus loin

  • # Justice ! Justice !

    Posté par  . Évalué à -10.

    Pour établir la justice social, il existe un impôt sur le capital que payent les possédants.
    Or, dans le calcul de cet impôt, un formidable capital n'est pas pris en compte : les diplômes.
    En effet, les diplôme sont un capital, un des plus important de notre époque, et ils ne sont injustement pas taxés. Or, ils permettent de gagner injustement de l'argent par rapport à ceux qui n'en ont pas. De plus, ceux qui ont un diplôme vivent plus longtemps et son moins au chômage que les travailleurs. Ils auront une meilleurs retraite. Et puis ils exploitent les travailleurs en s'appuyant sur leur diplôme.
    C'est donc UN VERITALE SCANDALE !
    J'exige donc que les pouvoir public prennent conscience de cette injustice, et impose les diplôme sur une base symbolique de 1000 FF de contribution par année d'étude supplémentaire après le bac.
    Ce n'est rien pour les possédants, c'est beaucoup pour ceux qui n'ont rien.
    Ces sommes servirons à financer un fond de solidarité qui donnera un peu d'humanisme dans ce monde implacable.

    Vive les travailleurs ! Vive le Progrés Social !

    • [^] # Re: Justice ! Justice !

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

      Haha t'as raison !...
      Je propose d'ajouter une taxe sur les neurones, et en particulier sur les neurones qui servent. Il faut que les patrons de neurones qui bossent paient plus cher que ceux dont les neurones sont au chomage.

    • [^] # Re: Justice ! Justice !

      Posté par  . Évalué à -10.

      personnellement, je suis pour mettre immédiatement au smig, tout responsable poilitique, tout membre du gouvernement et tout patron d'entreprise > pme.
      Et dans le mois qui suit, des solutions seront trouvées pour que le smic passe au moins à 10000frs par mois, et tous les incompétents auront mystérieusement émigrés vers des pays lointain. automagiquement.

      • [^] # Re: Justice ! Justice !

        Posté par  . Évalué à -4.

        par contre, si t'as une entreprise de BTP, c'est le genre de mesure qui va te couter cher en commissions
        -1, réduction des charges

    • [^] # Re: Justice ! Justice !

      Posté par  . Évalué à -1.

      Je crois qu'il faudrait ajouter un système pour empêcher les gens avec un XP négatif de poster des messages! ça limiterait ce type de polution!

      A moins que ce ne soit déjà fait!

      -1 parce que moi aussi je pollu (mais ça pour la bonne cause ;-)

      • [^] # Re: Justice ! Justice !

        Posté par  . Évalué à -2.

        Je crois que c'est déjà le cas. Mais la pluie de [-] qui met les XP en-dessous de 0 ne s'abat seulement qu'une fois que le commentaire est là et que le mal est fait.

        Il faudrait que les posts des XP négatifs soient systématiquement "repliés", comme s'ils étaient toujours sous le niveau de browsing. Un petit patch de rien du tout à faire dans daCode. Un volontaire ?

        • [^] # Re: Justice ! Justice !

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

          bah il faut naviguer à 0

          • [^] # Re: Justice ! Justice !

            Posté par  . Évalué à 3.

            Oui, mais vu que les gens/bots votent n'importe comment ou votent [-] systématiquement, ca me prive d'une partie des commentaires. par exemple le tien et le mien sont à -1 qu moment où je te réponds. Je ne vois pas vraiment pourquoi, mis à part qu'on est un peu en dehosrs du sujet de la news (mais quand même dans le sujet du thread, qui de toute façon part en couille).

            • [^] # Re: Justice ! Justice !

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

              Le mien c'était fait pour, justement parce que c'est hors sujet (tout comme celui-ci :)). Mais je te dirais que pour ma part, je trouve que le système de scorage fonctionne pas trop mal et permet déliminer le bruit sans trop de pertes (mais c'est vrai que parfois (rarement) tu rates quelque chose en ne voyant pas les scores à -1).

              • [^] # Re: Justice ! Justice !

                Posté par  . Évalué à -1.

                En fait je découvre le système et je trouve ça vraiment très intéressant! Je pense qu'on devrait lancer des débats genre philo ou politique en utilisant ce charmant système. Le résulat serait surement plus intéressant que ce que nous pondent les politiques de mes deux qui nous gouvernent!

                -1 parce que je post pour ne rien dire!

    • [^] # Re: Justice ! Justice !

      Posté par  . Évalué à 1.

      Hé espèce d'imbecile heureux... va jouer au staline ailleurs...
      c effrayant les idioties que l'on peut lire...

      Bon... désolé de poluer... mais franchement cela me démangeait...

      EviV Mosix...!

  • # autre lien

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

    y'a eu un fork dans le développement de MOSIX. OpenMOSIX est le "nouveau" projet.
    L'autre est ici ==> http://www.mosix.cs.huji.ac.il/(...)

    Voilà sinon MOSIX, c'est bien.

    • [^] # le pourquoi du fork

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

      ... dans la FAQ d'OpenMOSIX :


      Why did you split from the Mosix group?

      Because I could not agree with the loose application of the OpenSource license to Mosix and to secretive and erratic version release and bug fixing process.

      • [^] # Re: le pourquoi du fork

        Posté par  . Évalué à 5.

        C'est pourquoi l'URL vers le projet original n'a pas été mentionnée, d'autant plus qu' OpenMosix propose une solution au niveau utilisateur que MOSIX prévoit de commercialiser...

  • # après tests

    Posté par  . Évalué à 10.

    c'est quand même pas super genial sur un réseau local (10 ou 100mb). Mosix passe plus de temps a charger les contextes d'éxécutions (d'une machine a une autre), qu'a calculer, hein gatz ?

    • [^] # Re: après tests

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

      c'est sûr que c'est surtout intéressant pour faire des calculs : avec des process qui tournent pendant plusieurs heures, c'est nickel.

    • [^] # Re: après tests

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

      Bien d'accord sur le problème des performances de la répartition elle-même... MOSIX serait peut-être valable pour DLFP vu les temps de réponse ces temps ci...? ;-)

    • [^] # Re: après tests

      Posté par  . Évalué à 6.

      Avec un réseau 10Mb on ne peut pas faire tourner grand chose, mis à part des processus dont la tâche est purement calculatoire.
      En ce qui concerne le 100Mb il est possible de faire tourner de nombreux processus ne faisant pas un usage intensif des E/S.
      Mais avec un réseau Myrinet, c'est tout autre chose!

      A quand un réseau Myrinet à Polytech'Nantes ? ;)

      • [^] # Mosix et KLAT2

        Posté par  . Évalué à 10.

        Et est-ce qu'il ne serait pas possible de configurer le cluster Mosix avec plusieurs cartes réseaux dans chaque noeud, afin de bénéficier d'une meilleure bande passante.

        Je pense en particulier à une topologie de type KLAT2 (voir http://aggregate.org/KLAT2/(...) ). Il me semble que l'on doit pouvoir renseigner Mosix sur la topologie du réseau (mais je n'ai jamais pu tester, faute de temps et surtout de machines).

        Ou, encore plus simple, dans le cas de 4 noeuds : si on met 4 cartes 100 Mb par noeud, et qu'on les relie entre eux avec un réseau complet (besoin de 3 cartes par noeud et de 6 câbles croisés au total), la carte réseau supplémentaire servant à relier les noeuds à la machine frontend et à l'extérieur. Je me demande si ça ne permettrait pas d'améliorer les performances (et surtout, dans quelle mesure) pour pas trop cher, sans avoir besoin d'investir dans une solution Myrinet. L'intérêt est que la connexion entre 2 noeuds se fait via une interface dédiée, elle ne risque pas d'être pourrie par autre chose.

        • [^] # Re: Mosix et KLAT2

          Posté par  . Évalué à 2.

          Je ne pense pas que tu y gagne vraiment. Le probleme ici est lié au temp
          de latence de ta carte réseau. C'est à dire le temps qu'elle va mettre à
          démarrer l'envoi de tes données.

          Avec un réseau 100Mb, que tu envois 3 octets ou 30 Ko, le temps de latence
          reste prépondérant sur le temps d'envoi réel de la trame.
          Avec Myrinet, le temps de latence est minimisé. Le gain de performance est
          immédiat.

          J'ai fait des test avec des réseaux 10/100/1000 et a part quelques cas
          particulier, le Giga n'apporte pas grand chose.

          Pour 4 noeuds, un bon réseau 100Mb permet pas mal de choses. Multiplier les
          cartes permet peut-etre de limiter la latence du switch mais bonjour la table
          de routage qui de plus est différente sur chaque machine.

          PS. Si possible, désactiver le mode STORE&FORWARD sur le switch permet de gagner
          beaucoup...

      • [^] # Re: après tests

        Posté par  . Évalué à -1.

        A quand un réseau Myrinet à Polytech'Nantes ? ;)
        Je sais pas ... Il faudrait demander à Jeannine ;-)

        plop

  • # Résultats bizarres

    Posté par  . Évalué à 10.

    J'ai lu en diagonale le doc, et il y a des trucs qui me choquent un peu.

    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 ?

    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 ?

    Est-ce que les gains de performances ne peuvent-ils alors pas venir du fait des modifications de Mosix dans le scheduler du noyau ?

    Je suis quand même assez perplexe quant à l'utilité et aux résultats de cette solution sur une ferme de serveurs HTTP... la répartition de charge en amont (pas du dns roundrobin, mais de la vraie répartition) est déjà très efficace...

    Un détail qui me semble un peu mis sous silence : comment se comporte le cluster quand il perd un noeud. Je n'ai vu qu'une allusion au fait qu'on pouvait retirer volontairement un noeud du cluster, auquel cas, il le quitte proprement et ça ne pose pas de problème, ou que les processus sur une machine qu'on débranchait violemment restaient sur la machine, mais qu'advient-il du reste du cluster dans ce cas ? Bref, est-ce qu'un cluster Mosix est tolérant aux pannes ?

    • [^] # Re: Résultats bizarres

      Posté par  . Évalué à 10.

      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.

      En espérant avoir répondu à vos interrogations.

  • # I'm fond of you gads ...

    Posté par  . Évalué à -10.

    ;-)

Suivre le flux des commentaires

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