OpenSSI est une solution de clustering de type "Single System Image" basée sur des technologies libres et la technologie "NonStop Clusters for Unixware", sponsorisé par HP.
"Single System Image" ? Oui, en gros peu importe la machine sur laquelle vous serez, vous accéderez de manière transparente aux ressources CPU/mémoire/disque des autres machines. Toutes les machines de la grappe verront la même chose, et peuvent être vues indépendamment.
Concrètement, OpenSSI se compose de patchs noyau et de scripts utilisateurs qui permettent de faire autant une grappe haute disponibilité qu'une grappe de calcul à migration de processus (manuelle ou automatique, à la OpenMosix). Son installation est quasiment entièrement automatisée sous RedHat 9 (et pourra aussi fonctionner moyennant un retour au noyau 2.4 OpenSSI sur Fedora core2), et est également possible sur une distribution Debian.
Actuellement le projet travaille au portage vers le noyau 2.6, et certains imaginent déjà l'incorporation d'une partie d'OpenSSI dans le futur noyau 2.8 ou 3.0...
NdM : Pour connaître la définition d'une grappe et d'une grille, voici deux liens: article sur dataswift et l'autre sur vnunet.
Aller plus loin
- OpenSSI (28 clics)
- Un article a propos de OpenSSI dans Sys Admin Magazine (8 clics)
- Une définition de "Single System Image" (8 clics)
# Calcul partage...
Posté par fanfan . Évalué à 2.
[^] # Re: Calcul partage...
Posté par iznogoud . Évalué à 3.
Bon, juste pour dire que c'est rare de voir un projet sur le sujet qui soit libre. Je veux dire, jusque là je connaissais ultramonkey (http://www.ultramonkey.org(...) mais allez-y doucement leur serveur est merdique et pourrait crasher facilement), qui est vieux, mal voire pas documenté, et ne fait pas le quart de la moitié de celui-ci.
J'avais justement besoin de ce genre de projet, je saute dessus tout de suite !
Merci pour la news, ça me redonne quelques espoirs quand au développement de ma distribution pour serveur mail, qui devait inclure ce genre de possibilité, mais je n'avais pas trouvé encore de projet fiable pour clusterizer tout ça. Je suis ravi.
[^] # Re: Calcul partage...
Posté par Alexandre Boeglin . Évalué à 10.
- les seti@home, folding@home et autre distributed.net ou décrypton, c'est je crois ce qu'on appelle du grid computing : pleins d'ordinateurs répartis un peu partout qui font la même chose. en simplifiant, y'a un seul algo qui tourne chez tout le monde sur des données différentes.
- openssi et openmosix ca permet de faire un gros système virtuel multiprocesseur à partie de plusieurs systèmes physiquement uniprocesseurs (ou multiprocesseurs) : tu as la possibilité ensuite de faire voyager un processus vers un des noeuds pour qu'il s'y exécute, et i ly a load balancing pour que tous les noeuds bossent, mais tu ne fais voyager que des processus, pas des threads, et c'est très vite couteux niveau réseau (faut faire voyager l'environnement du processus avec), donc pas envisageable sur un réseau comme internet (imagine un système qui attend à chaque fois une à deux minutes dans le vent avant de te rendre la main quand un processus commence ou termine son exécution). et pareillement, si tu as une tâche qui ne spawne qu'un processus à la fois, un seul noeud de ta supermachine sera utilisé...
- ultramonkey et linuxvirtualserver, c'est une machine en front-end qui distribue le travail aux noeuds qui lui signalent leur présence. ca sert simplement à répartir un flot de requêtes entre plusieurs systèmes distincts.
@++
[^] # Re: Calcul partage...
Posté par iznogoud . Évalué à 2.
- tout à fait, c'est pas moi qui vait te contredire.
- chose que fait également openSSI mais à sa manière, si j'ai bien lu. C'est vrai que ma phrase pouvait se lire "OpenSSI et LVS/Ultramonkey c'est pareil", c'est pas dans ce sens que je le disais. Simplement pour l'instant je m'étais orienté vers Ultramonkey parce qu'il permet la haute disponibilité que ne proposait pas OpenMosix par exemple et c'est un point sur lequel le cahier des charges est clair. Maintenant, le fonctionnement entre les deux est différent.
C'est vrai que mon point de vue est réducteur : je le réduis à l'usage que je veux : avoir un ensemble de machines travaillant avec haute disponibilité pour une même tâche : proposer un serveur mail complet. Et à ce titre, OpenSSI et Ultramonkey me permettraient tous les deux d'arriver à mes fins. Sauf que voilà, Ultramonkey, si on va voir sur leur page, ça a l'air assez mort, le support est mauvais, aucune documentation digne de ce nom, on ne sait pas ce qu'il en est du support pour les noyaux 2.6.X et j'en passe.
[^] # Re: Calcul partage...
Posté par Alexandre Boeglin . Évalué à 3.
pour ce que tu recherches à faire, openssi/openmosix sera performant uniquement si ton serveur/cluster fait tourner plusieurs processus en même temps. sinon, ca n'a aucun intérêt (en termes de performances, hein, pas de disponibilité).
et à ce moment là, si il est possible de faire bosser ensemble plusieurs serveurs indépendants, un http://www.linuxvirtualserver.org/(...) peut s'avérer suffisant pour répondre au besoin.
[^] # Re: Calcul partage...
Posté par Gilles Mocellin . Évalué à 3.
Ultramonkey ne fait qu'agréger des produits tierces, pas morts.
Pour la haute dispo, on vient de monter un cluster de 2 noeuds (au hasard, notre serveur de messagerie ;)).
Le package hertbeat fait le gros du travail, on a pas de LVS, donc, c'est vraiment que hertbeat que l'on utilise, ça permet d'avoir des services qui peuvent passer d'une machine à l'autre en cas d'arrêt.
En fonctionnement normal, on a
- serveur 1
-- service 1
le serveur smtp (postfix)
le serveur web avec l'apli d'admin (aliamin d'aliacom) qui modifie postfix
une base mysql pour l'appli d'admin
-- service 2
le serveur ldap
-serveur 2
--service 3
le serveur imap (cyrus)
Chacun des service peuvent tourner sur chaque serveur.
On a une baie partagée pour le stockage des fichiers de donnée (bases ldap, boites de messagerie, base mysql), pour qu'ils puissent être vus de chaque serveur (je sais, c'est un spof, single point of failure).
[^] # Re: Calcul partage...
Posté par zorel . Évalué à 1.
http://www.lustre.org(...)
# OpenMosix vs OpenSSI
Posté par chl (site web personnel) . Évalué à 5.
J'ai ete sur les pages d'OpenSSI et d'OpenMosix, et je n'ai rien vu a ce sujet.
Merci a celui qui eclairera ma lanterne ! :)
[^] # Re: OpenMosix vs OpenSSI
Posté par grmbl . Évalué à 5.
[^] # Re: OpenMosix vs OpenSSI
Posté par Maxime Ritter (site web personnel) . Évalué à 3.
Mais en fait la philosophie des 2 projets est différente. Avec OpenSSI toutes les machines sont vu comme étant équivalentes dans le cluster, alors qu'avec OpenMOSIX toutes les machines peuvent être vu et configurés différemment, les utilisateurs différents, etc....
Lorsqu'un processus OpenMosix migré a besoin de faire un appel système, il est fait sur le noeud d'origine. Pour avoir la date par exemple, c'est pompe-ressources. Mais du coup, toutes les machines d'un cluster OpenMosix peuvent avoir des dates différentes.
Avec OpenSSI, on suppose toutes les machines équivalentes, et on ne se souvient meme pas du noeud d'origine. La date est réputée la même sur toutes les machines, les fichiers aussi, les utilisateurs, etc... Du coup OpenSSI doit gérer une mémoire partagée globale sur tout le cluster si tu fait de tels appels, les sémaphores, etc... C'est donc bien plus complexe qu'OpenMosix. Et pas trivial du tout, le sponsoring de HP et l'héritage de "non-stop cluster' fait du bien !
Cela se ressent particulièrement quand tu fait un test de compil via make -j 20 (bon, c'est pas le meilleur test qui soit, hein) : avec OpenMosix, les applis pour forker doivent revenir sur le noeud d'origine, forker, et remigrer les 2 process ailleurs... Avec OpenSSI, on fork sur la machine où on se trouve, et éventuellement on migre l'un des process. D'où pas mal de gain sur ce cas (très extrème, certes).
Sinon, effectivement OpenMosix est plus mature point de vue migration de process, mais OpenSSI fait bien plus... et avec la sortie de la 1.0 il commence a être assez stable pour espérer bientôt remplacer OpenMosix. En tout cas, point de vue facilité d'administration, il a déjà battu OpenMosix, vu que tout est fait pour rajouter des noeuds en diskless via netboot. Et en plus, il peut faire de la haute disponibilité, si c'est pas merveilleux !
# Où sont les sources multi-plateforme ?
Posté par yoho (site web personnel) . Évalué à -2.
[^] # Re: Où sont les sources multi-plateforme ?
Posté par djano . Évalué à 3.
Est-ce qu'ils n'ont pas simplement developpes seulement sur ces distributions, et que, du coup, ils ne se sont pas amuses a tester sur d'autres?
[^] # Re: Où sont les sources multi-plateforme ?
Posté par SoWhat . Évalué à 5.
[^] # Re: Où sont les sources multi-plateforme ?
Posté par djano . Évalué à -1.
Oui je sais! Je me fais l'avocat du diable.
[^] # Re: Où sont les sources multi-plateforme ?
Posté par kilian . Évalué à 5.
Cette limitation s'explique par le fait que de nombreux utilitaires système sont modifiés pour prendre en compte les fonctionnalités liées au système de fichier spécifique au cluster (CFS) ou au fait que les processes/messages/objets sont globaux. Le mode de boot est également spécifique, et utilise nécessairement une image initrd, dont le contenu varie suivant la distribution. Enfin, un certain nombre de scripts de démarrage sont modifiés pour prendre en compte la couche cluster.
Tout ceci contribue donc à rendre OpenSSI dépendant de la distribution. Compte tenu du fait que les développeurs se concentrent plus sur les fonctionnalités que sur l'emballage (une seule personne s'occupe du portage Debian), je pense qu'ils accueilleront à bras ouverts toutes les bonnes volontés. :)
[^] # Re: Où sont les sources multi-plateforme ?
Posté par yoho (site web personnel) . Évalué à 2.
Juste une idée (j'y connais rien) : ce ne serait pas possible de scinder le code en deux : une partie indépendante de la distri et une autre partie dépendante ? Il doit quand même y avoir de grosse parties communes entre la version debian et la version redhat. Du coup, comme la partie dépendante de la distri est plus petite, il y aurait peut-être des contributeurs pour la porter, et vous pourriez améliorer la partie "purement" SSI.
[^] # Re: Où sont les sources multi-plateforme ?
Posté par Maxime Ritter (site web personnel) . Évalué à 0.
Bon, en fait elles sont sur le CVS, sur la page web, et partout...
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ssic-linux/(...)
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ci-linux/(...)
Mais autant te prévenir : tu vas galérer pour le porter a une autre distrib....
# différence avec Xgrid de apple
Posté par thaodalf . Évalué à 2.
car si j'ai bien compris Xgrid permet la detection de ressource via un reseau et le calcul d'une tache sur une ou plusieurs machines distante. on retrouve la dedans ce que la news appelle "migration de processus" je pense. si je me souviens bien apple est tres ouvert sur le protocole Xgrid.
les deux projets sont t'il differents dans leurs applications ? y aura t'il un lien entre les deux ?
[^] # Re: différence avec Xgrid de apple
Posté par Alexandre Boeglin . Évalué à 4.
en gros, dans xgrid, un noeud recoit (demande, en général, plutôt) un binaire et des données via le réseau, puis il exécute le binaire sur les données. tous les noeuds sont indépendants...
dans un openssi/openmosix, il recoit un "processus", "un environement d'exécution" via le réseau, qui est plus à voir comme un bus entre tous les noeuds, une couche intermédiaire entre le hardware et le software qui s'occupe de balancer le software vers un hardware disponible.
# Kerrighed
Posté par pini . Évalué à 7.
http://kerrighed.org(...)
[^] # Re: Kerrighed
Posté par kilian . Évalué à 5.
De ce que j'en ai lu, une des fonctionnalités les plus intéressantes de ce projet est (sera) l'agrégation de la mémoire physique des noeuds du cluster, via un système de 'container' tout à fait original.
Mais pour l'instant, le fait qu'il ne supporte pas le SMP m'a un peu freiné, mais je suppose que ça viendra
[^] # Re: Kerrighed
Posté par ribwund . Évalué à 5.
- point de reprise (on sauvegarde l'état d'un processus a un moment donné, on peut ensuite le relancer a partir de l'état sauvegardé)
- mémoire partagée globale (migration des applications utilisant la mémoire partagée, migration des threads d'une application multithreadé)
La 1.0 de Kerrighed devrait être pour la rentrée.
# mettre un label significatif aux liens
Posté par Olivier Jeannet . Évalué à 9.
Je suis un peu hors sujet car ça concerne la façon dont les liens ont été qualifiés, mais je pense que ça peut servir à d'autre. Une des bonnes pratiques du Web consiste à ne pas mettre des liens sur des mots comme "cliquer ici" ou "ici". Non seulement c'est moins pratique car le lien n'a pas de titre explicite, mais si tout le monde faisait comme ça, google par exemple aurait du mal à établir la nature des pages pointées, et ça mettrait un peu par terre le système de "ranking" des pages.
Il vaut mieux procéder comme ceci (suggestion) :
« Voici des liens pour la définition d'une grappe et d'une grille de calcul. »
[^] # Re: mettre un label significatif aux liens
Posté par rootix . Évalué à -2.
Donc, tu peux te le mettre DTC :)
[^] # Re: mettre un label significatif aux liens
Posté par titi toto . Évalué à 2.
# Et pour s'amuser ??
Posté par KiKouN . Évalué à 1.
Je me demander donc si ça valait le coup de racheter ou récupérer trois ou quatre "vieux" ordi (genre Pentium II ou équivalent et juste CM, CPU, MEM et peut-être DD) ??
Est-ce que c'est suffisant pour faire tourner cela ??
[^] # Re: Et pour s'amuser ??
Posté par Denis Montjoie (site web personnel) . Évalué à 2.
Javais fait un exposé la dessus avec une démonstration.
Avec 3 PC tu peux "voir" la migration de process en fesant par exemple une compil de kernel (migration des compilation). (MAKE -j8)
tu prend ton pc principal en moniteur (openmosixview) et les autres en node de base.
Dans toutes les bonnes puces tu dois pouvoir trouver des vieux pc pas cher (Montreuil (pour paris), Nimes, Mornas (ca cest chez moi) ).
[^] # Re: Et pour s'amuser ??
Posté par ceituna (site web personnel) . Évalué à 1.
Ca, c'est la théorie...
En pratique, quand tu as besoin de recompiler le noyau pour supporter tout cela, vu que tu n'as pas "encore" de mutualisation des ressource, c'est long... Très long... surtout sur un P75...
je m'étais pour ma part amusé à faire ces tests il y a queqles années (2 ou 3), avec des cartes 10Mbps... Bof Bof... Et puis, j'ai eu l'occasion de le faire avec des 100Mbps... Ca change bcp...
Donc, si je peux te donner un conseil, commence tout de suite sur un réseau 100Mbps, et essaye de "pré-cimpiler" ton noyau modifié, sur la plus puissante des machines (avec make-kpgk, par exemple)...
Autre info pour ceux qui veulent essayer OpenMosix. Il y a un certain temps, un projet de LiveCD est apparu, pour pouvoir faire cela très rapidement : PlumpOS. Quand je l'avais essayé (début 2003), il y avait pas mal de "hacks" nécessaires pour le faire marcher. Je ne sais pas où ca en est aujourd'hui.
Mes 0,02
[^] # Re: Et pour s'amuser ??
Posté par CoinKoin . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.