Articles précédents : Logiciel
- [9] Un nouveau rescuedisk moderne
- [21] Raytraçons, il en restera toujours quelque chose
- [0] OpenOffice snapshot 627 dans les bacs
- [17] Blender vit!
- [25] wmx 6 est sorti
- [27] Alan Cox et ses patchs du jour
- [6] GPP (GNOME Packaging Project)
- [10] PHP 4.0.5 disponible
- [33] Systèmes de Fichiers Journalisés : du nouveau
- [70] Kernel 2.4.4
Liens connexes
- Site Mosix (785 hits)
- Telechargement (378 hits)
- Solutions de clusters (677 hits)
Dépêche modérée par
Logiciel : MOSIX pour noyau 2.4.4 disponible
Posté par FRLinux (page perso, ). Modéré le 06 mai 2001.La nouvelle version vous permet d'intégrer Mosix au sein des noyaux 2.4.4 (et cela ne marche d'ailleurs qu'avec cette version). Les gars de Mosix ont également des versions disponibless pour les 2.2 tels : 2.2.19 / 18 et des RPMs pour les différents types de Red Hat et SuSE 6.x.
Site Mosix (785 hits)
Telechargement (378 hits)
Solutions de clusters (677 hits)
> Lire les commentaires (5 commentaires, moyenne: 0,8).
burp!
Question idiote: y a-t-il moyen de faire en sorte d'avoir plein de pc (rempli avec des slots bourrés de carte et tout plein de périphériques) qui agissent comme extension d'un ordi "master", le tout contrôlé par un seul kernel, celui du master?
(en gros: faire en sorte que tout ce qui a dans 4 ordi différents apparaisse comme venant d'un seul)
parce que 7 slot, c'est pas beaucoup...
Quelqu'un?
-
[^]Re: burp!
Posté par Benoît Sibaud (Jabber id, page perso, ) le 06/05/2001 à 12:06. (lien). Évalué à 1.Faudrait demander à un spécialiste du hard style Jak par exemple, mais à mon avis :
* il est difficile/impossible de partager totalement la RAM de toutes les machines
* il faudrait que les différents bus (PCI, ISA, etc) soient communs pour que les cartes filles puissent se trouver sur d'autres machines
* la solution que tu proposes peut plus facilement se remplacer par un boîtier XXXXXL: plusieurs alims, plein d'emplacements, tous les slots utilisables, etc. Reste le problème que les ressources restent quand même limitées (disons à 15 interruptions, 4 contrôleurs IDE, etc). Avec du partage d'interruptions, peut-être ?-
[^]Re: burp!
Posté par Jak () le 06/05/2001 à 13:57. (lien). Évalué à 1.Spécialiste, tu y vas un peu fort, quand même :)
Cependant, avec Mosix, justement, on doit pouvoir arriver à quelque chose d'approchant l'idée de Croweye. Déjà, un noyau Mosix permet la migration de processus en fonction des ressources disponibles sur les différents noeuds du cluster (Processeur, mémoire).
De toute façon, c'est une solution plus raisonnable et plus extensible qu'une machine tout intégrée. Là, on est limité par l'architecture matérielle des systèmes x86. Les gros Sparc, IBM, ou Compaq (Alpha) ont déjà prévu des bus spécifiques pour permettre l'interconnexion rapide entre les différents noeuds d'un cluster. Par exemple, il y a des options possibles pour True64 sur architecture Alpha qui autorisent déjà la migration de processus et d'autres choses possibles dans ce genre d'environnement distribué.
J'ai l'intention prochainement (mais bon, 'faut le temps, aussi) de monter un petit cluster. Je suis justement en train de lire les docs de chez Mosix pour voir ce que l'on peut partager, comment les données peuvent être réparties sur la mémoire de masse, ce que l'on peut attendre comme amélioration de performances, etc... Un bi-pro Duron avant la sortie du 760MP, quoi :)
Ah, aussi, Oumph : mais qu'est-ce que tu fous à glander sur Linuxfr un Dimanche? T'as pas le temps en semaine? :)--
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
-
-
[^]Re: burp!
Posté par Anonyme () le 06/05/2001 à 16:42. (lien). Évalué à 0.http://plan9.bell-labs.com/sys/doc/9.html(...)
Bon, il n'y a pas vraiment de "master" là mais l'utilisateur vois un unique système : transparence.
Bonne lecture.




Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.