Le projet Kerrighed vient de sortir sa version 2.1.0 : http://www.kerrighed.org/wiki/index.php/Download
Les principaux changements sont :
- Portage sur le noyau 2.6.20
- Ré-écriture de la couche de communication au dessus de TIPC
- Correction de très nombreux bogues.
Cette version est toujours considérée comme instable. La stabilité a cependant été grandement renforcée depuis la version 2.0.0 et le travail de déboguage continue.
Le portable en SMP est désormais bien avancé ! La prochaine version (2.2.0 prévu pour cet été) intégrera ce portage en SMP.
Journal Sortie de la version 2.1.0 de Kerrighed
5
juin
2007
# Sortie de Glaflemme d'expliquer en version 2.1 alpha M1
Posté par Damien Metzler . Évalué à 10.
Même en allant sur le site, on comprend vraiment pas tout tout de suite. Alors de ce que j'ai compris :
C'est un module du noyau qui permet à un poste sous Linux de joindre un cluster de machine et du coup de contribuer à ce même cluster, c'est ce qui doit s'appeler un "Single System Image operating system for clusters" (ça fait mal à la tête !)
Un petit conseil, même pour un journal, ça serait bien d'être un peu plus clair.
[^] # Re: Sortie de Glaflemme d'expliquer en version 2.1 alpha M1
Posté par Renaud Lottiaux . Évalué à 2.
Mais comme "Glaflemme", je te laisse aller lire les références citées ci-dessous ;)
[1] http://linuxfr.org/2005/02/25/18383.html
[2] http://linuxfr.org/2007/04/17/22376.html
# Performances
Posté par e-t172 (site web personnel) . Évalué à 2.
J'ai lu une étude qui affirmait que Kerrighed est de loin le plus performant SSI existant. J'aimerais savoir si il serait intéressant, du point de vue des performances et de la fiabilité, d'utiliser un tel système en lieu et place d'une grappe de serveurs "classique" (à savoir plusieurs machines faisant tourner Apache avec un système de load balancing, par exemple).
Je m'y intéresse car cela me paraît très alléchant, du point de vue de la maintenance et du temps dépensé, d'avoir à administrer un seul système logique au lieu de plusieurs systèmes physiques... qui plus est, on pourrait faire tourner plusieurs daemons (HTTP, SMTP, FTP, etc.) sur un seul système Kerrighed qui équilibrerait de manière automatique et transparente la charge entre les différentes machines.
Je n'ai jamais administré de cluster donc je propose est peut être une immense connerie, mais je suis curieux de savoir ce que ça donnerait. Je me demande notamment si un tel système serait adapté à des applications où le temps de réponse a une certaine importance : pour pouvoir transférer des pages mémoire d'une machine physique à une autre avec très peu de latence, il faut un réseau extrêmement rapide entre les éléments du SSI, non ? (Ethernet 1 Gbps ?)
[^] # Re: Performances
Posté par Pascal Gallard . É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: Performances
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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.
Au boulot, on a un cluster de calcul géré par lsf. Si on avait juste à se loguer dessus, cela serait plus simple. Idem, pour se connecter à "un linux" depuis un serveur X sous windows, pas besoin de chercher une machine libre (non chargé).
Concernant les réseaux, avez-vous essayer les systèmes à plusieurs liens ?
Habituellement un réseau est connecté en arbre à des switchs, et souvent les switchs son cascadé si le nombre de machines est grand. (imaginé que 32 machines en gigabit doivent partager un seul giga pour parler à un voisin sur un autre switch!)
J'avais vu un projet de cluster à 256 machines. Il avait gagné beaucoup de performance réelles en ne reliant pas entre eux les switchs. En fait, il avait plusieurs cartes réseaux par machines et utilisait la règles suivantes : un seul switch à traverser pour aller d'une machine à l'autre (le top étant les liaison n à n ou encore l'utilisation de carte réseau qui font aussi switch mais cela devient énorme).
Les problèmes à régler sont multiples : la topologie du réseau est complexe à produire (nombre de carte par noeud, connections à quel switch,...). Et surtout, j'ai du mal à imaginer la gestion des adresses IP et le routage que cela implique (gestion des tables, trouver le lien direct à tous les coups, etc...). Bref, pour que cela soit pleinement fonctionnelle, il y a encore du soft à écrire.
Mais au final, on a des performances notamment par diminution des latences (on parallélise les connections) à un cout bien inférieur à un réseau rapide spécial.
"La première sécurité est la liberté"
[^] # Re: Performances
Posté par Jak . Évalué à 2.
http://aggregate.org/FNN/
http://aggregate.org/KASY0/
Ils utilisent les instructions 3DNow! des processeurs AMD pour les calculs de routage. KLAT2 était le cluster ayant le plus faible coût au GFlop, et KASY0 est encore meilleur de ce point de vue.
L'idée, si je me souviens bien, est en effet de diminuer le temps de latence entre divers noeuds en n'utilisant du matériel peu coûteux (Ethernet 100M) en lieu et place de Gigabit-Ethernet ou de Myrinet.
[^] # Re: Performances
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Performances
Posté par e-t172 (site web personnel) . É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 ?
[^] # Re: Performances
Posté par Pascal Gallard . É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 e-t172 (site web personnel) . Évalué à 2.
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 ?
Si on peut effectivement communiquer en UDP, alors utiliser Kerrighed serait très alléchant dans le scénario que j'ai décrit !
[^] # Re: Performances
Posté par Pascal Gallard . É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 e-t172 (site web personnel) . Évalué à 1.
Si ce n'est que ça, alors c'est tout à fait utilisable : le trafic occasionné par un serveur de jeu n'a rien d'exceptionnel (moins de 500 ko/s en général, pics à 2,5 mo/s grand maximum). Comme solution temporaire, c'est donc tout à fait gérable (même si, en effet, c'est techniquement aberrant). Quant à la dépendance entre les noeuds, c'est du domaine de la tolérance de pannes, qui est nettement moins importante dans les serveurs de jeu que dans d'autres domaines.
[^] # Re: Performances
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La solution la plus propre au problème serait que le serveur de jeu inclus le load balancer (au niveau du serveur de jeu, cela reviendrait presque uniquement à proposer une nouvelle ip, non ?).
"La première sécurité est la liberté"
[^] # Re: Performances
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Cependant, te fixer comme contrainte 50 ms de temps de migration me parait exagéré compte tenu de l'avantage de représente la possibiltié de migrer en live vers un serveur plus puissant.
[^] # Re: Performances
Posté par e-t172 (site web personnel) . Évalué à 1.
Sur le principe, d'accord, mais en pratique :
- Verygames héberge des dizaines de milliers de serveurs de jeu. Donc en virtualisant tout ça, ça résulte en des dizaines de milliers de machines virtuelles ? Difficilement gérable... Ou alors, on regroupe plusieurs serveurs de jeu en une machine virtuelle, mais ça réduit alors d'autant l'efficacité de la solution...
- La ressource la plus précieuse quand on héberge des serveurs de jeu c'est le CPU. Dans ces conditions, l'overhead qu'implique une machine virtuelle est à prendre en compte. Je ne connais pas Xen/KVM, mais de ce que j'en ai vu de la virtualisation, les performances d'une machine virtuelle sont tout de même un cran en dessous de celles de la machine physique. En pratique, je ne sais pas si ça fait une grosse différence car je ne connais pas les performances de Xen/KVM, mais je suis pessimiste.
Je ne peux pas tester comme tu le suggères, parce que je n'ai pas de grappes de serveurs de jeu sous la main, j'ai juste eu l'occasion de travailler dans ce milieu.
Tout dépend de la fréquence de ces interruptions et de la qualité de service que tu veux assurer. Si il y a deux ou trois interruptions de 1 seconde dans une soirée, ça passe si tu n'es pas trop exigeant sur la qualité. Par contre, si tu loues des serveurs de jeu de haute qualité destinés à du haut niveau, alors il ne faut pas la moindre anicroche.
[^] # Re: Performances
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Les nouveaux CPU ont des instructions de virtualisations intégrés.
Je trouve surprenant que tu n'ai pas quelques machines de coté pour faire ce genre de tests.
A toi de choisir entre un overhead qui te permets d'exploiter a mieux tes ressources CPU ou pas d'overhead mais l'impossibilité de charger tes machines si un serveur est peu utilisé...
[^] # Re: Performances
Posté par e-t172 (site web personnel) . Évalué à 1.
Comme je l'ai dit plus haut, il m'est arrivé de travailler dans ce milieu, c'est pour cette raison que ça m'intéresse. Je n'héberge pas moi même de serveurs de jeu.
Ou un SSI comme Kerrighed, qui n'aura aucun overhead, et qui rassemble tout en une seule machine logique donc beaucoup, beaucoup plus facile à administrer. Reste à savoir si c'est une solution assez stable pour être mise en application.
[^] # Re: Performances
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
L'avantage avec XEN est que si la machine virtualisé n'a rien à faire, la charge système est à zéro... J'ai vraiment l'impression qu'un système paravirtualisé descend plus facilement à zéro de charge qu'un système réel. Il doit y avoir moins d'interruptions matérielles.
# Tolérance de panne, hot plug...
Posté par ragoutoutou . Évalué à 2.
En dehors de ça, le hot plug est-il déjà implémenté?
[^] # Re: Tolérance de panne, hot plug...
Posté par Renaud Lottiaux . Évalué à 3.
Concernant le hot-plug, une version très expérimentale est actuellement présente dans le code. Cette fonctionnalité devrait être disponible en version stable d'ici à la fin de cette année.
[^] # Re: Tolérance de panne, hot plug...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Bref, c'est fondamental si on veut voir plein de Kerrighed partout ;-)
[^] # Re: Tolérance de panne, hot plug...
Posté par ragoutoutou . Évalué à 2.
sans une tolérance de panne minimale, on ne peut pas commencer à mettre des dizaines ou des centaines de machines en cluster car cela réduit le fiabilité de l'ensemble au lieu de l'augmenter comme un cluster classique.
Et sans Hotplug/Hotunplug, on ne peut pas aborder une gestion grid des machines avec gestion d'allocation des ressources selon tranche horaire, SLA, ...
[^] # Re: Tolérance de panne, hot plug...
Posté par Renaud Lottiaux . Évalué à 2.
Cependant, ceci ne constitue pas un frein pour tout le monde. Certaines catégories d'utilisateurs n'ont pas besoin d'ajout/retrait et acceptent des défaillances occasionnelles (qui sont somme toute relativement peu fréquentes sur un cluster de taille modeste) en échange d'une plus grande facilité et souplesse d'utilisation.
Pour autant, afin de satisfaire la plus large gamme possible d'utilisateurs, nous travaillons à la mise en oeuvre des éléments d'ajout/retrait et de tolérance aux pannes, indispensables pour nombre d'utilisateurs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.