Je vois bien l'intérêt de manager moins de machines, mais pour l'utilisation de apache, à part si on peut se passer d'un load balancer, je voix difficilement l'intérêt. Surtout que niveau performance, cela doit être plus lent (puisque qu'il y a de la gestion à faire qui n'existe pas avec les systèmes actuels).
Un tel système doit être sympa sur des applications qui peuvent utiliser plein de processeurs mais qui nécessite tout de même une image unique. C'est pas courant (notamment car il n'existe pas vraiment de machine pour:). Je pense aux simulations.
Un cas qui me vient particulièrement à l'esprit : imaginons un hébergeur de serveurs de jeu (type Verygames par exemple). Ici, on a un grand nombre de serveurs de jeu, et des machines fournissant la puissance de calcul nécéssaire, qui est loin d'être faible : un serveur de jeu prend pas mal de mémoire vive et on sent passer sa consommation CPU, même sur les processeurs les plus récents.
La problématique est la suivante : les serveurs de jeu ne sont pas remplis de joueurs en permanence. En fait, ils passent la plupart de leur temps vides, et donc sans consommer de puissance de calcul. Par contre, une fois que des joueurs commencent à arriver, la puissance de calcul nécéssaire augmente très vite.
Or, il est impossible de prévoir à l'avance (enfin, en tout cas, pas pour l'hébergeur) si un serveur de jeu sera utilisé ou pas à tel ou tel moment.
La solution actuelle, imparfaite, est de placer X serveurs de jeu par machine. Inconvénient principal : si, à un instant, il se trouve que personne ne joue sur aucun des serveurs de jeu hébergés par une machine particulière, alors ses ressources sont gaspillées. A l'inverse, si on est malchanceux et qu'une horde de joueurs se rameute sur les serveurs de jeu hébergés par une machine, celle-ci n'arrive pas à tenir la charge et la qualité du jeu se dégrade. En effet, pour maintenir des prix bas, les hébergeurs de serveurs de jeu ne peuvent pas "peupler" leurs machines en partant du principe qu'elles doivent tenir la charge avec tous les serveurs de jeu pleins (sinon ça coûterait beaucoup, beaucoup plus cher), à la place, ils font un compromis en se basant sur le fait que le "worst case scenario" (à savoir tous les serveurs de jeu remplis en même temps sur une machine) a statistiquement peu de chances d'arriver.
Sur le papier, Kerrighed serait la solution miracle dans ce genre de situation : on rassemble toutes les machines dans un SSI avec Kerrighed, et on fait tourner les serveurs de jeu dessus - Kerrighed s'occupera alors d'optimiser la répartition des serveurs de jeu pour qu'il n'y ait pas des machines à genoux alors que d'autres se tournent les pouces.
Problème principal : les serveurs de jeu sont des processus lourds, fortement consommateurs de mémoire (environ 250 mo) et qui ne peuvent être arrêtés que pour un temps extrêmement court (50 ms grand maximum) sous peine de dégrader la qualité du service.
Transférer 250 mo en 50 ms nécéssite, après rapide calcul, 5 go/s... ce qui est faisable avec du 10 gigabit, mais est-ce que Kerrighed et les autres éléments (hardware et software) seraient capables de tenir de telles exigences ?
[^] # Re: Performances
Posté par e-t172 . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 2.
Un cas qui me vient particulièrement à l'esprit : imaginons un hébergeur de serveurs de jeu (type Verygames par exemple). Ici, on a un grand nombre de serveurs de jeu, et des machines fournissant la puissance de calcul nécéssaire, qui est loin d'être faible : un serveur de jeu prend pas mal de mémoire vive et on sent passer sa consommation CPU, même sur les processeurs les plus récents.
La problématique est la suivante : les serveurs de jeu ne sont pas remplis de joueurs en permanence. En fait, ils passent la plupart de leur temps vides, et donc sans consommer de puissance de calcul. Par contre, une fois que des joueurs commencent à arriver, la puissance de calcul nécéssaire augmente très vite.
Or, il est impossible de prévoir à l'avance (enfin, en tout cas, pas pour l'hébergeur) si un serveur de jeu sera utilisé ou pas à tel ou tel moment.
La solution actuelle, imparfaite, est de placer X serveurs de jeu par machine. Inconvénient principal : si, à un instant, il se trouve que personne ne joue sur aucun des serveurs de jeu hébergés par une machine particulière, alors ses ressources sont gaspillées. A l'inverse, si on est malchanceux et qu'une horde de joueurs se rameute sur les serveurs de jeu hébergés par une machine, celle-ci n'arrive pas à tenir la charge et la qualité du jeu se dégrade. En effet, pour maintenir des prix bas, les hébergeurs de serveurs de jeu ne peuvent pas "peupler" leurs machines en partant du principe qu'elles doivent tenir la charge avec tous les serveurs de jeu pleins (sinon ça coûterait beaucoup, beaucoup plus cher), à la place, ils font un compromis en se basant sur le fait que le "worst case scenario" (à savoir tous les serveurs de jeu remplis en même temps sur une machine) a statistiquement peu de chances d'arriver.
Sur le papier, Kerrighed serait la solution miracle dans ce genre de situation : on rassemble toutes les machines dans un SSI avec Kerrighed, et on fait tourner les serveurs de jeu dessus - Kerrighed s'occupera alors d'optimiser la répartition des serveurs de jeu pour qu'il n'y ait pas des machines à genoux alors que d'autres se tournent les pouces.
Problème principal : les serveurs de jeu sont des processus lourds, fortement consommateurs de mémoire (environ 250 mo) et qui ne peuvent être arrêtés que pour un temps extrêmement court (50 ms grand maximum) sous peine de dégrader la qualité du service.
Transférer 250 mo en 50 ms nécéssite, après rapide calcul, 5 go/s... ce qui est faisable avec du 10 gigabit, mais est-ce que Kerrighed et les autres éléments (hardware et software) seraient capables de tenir de telles exigences ?