Articles : Linux devient massivement multiprocesseurs
Posté par Christophe Merlet (page perso, ). Modéré le 19 juillet 2004.
En effet, SGI construit un super-ordinateur de 1024 Itanium 2 avec 3 To de mémoire partagée pour le NCSA (National Center for Supercomputing Applications) qui sera exploité par Linux.
Dans un premier temps il y aura 2 noyaux gérant chacun 512 CPU puis rapidement 1 seul noyau pour gérer les 1024 CPU.
Toutes les améliorations apportées au noyau 2.6 concernant le support des architectures NUMA et multi-processeurs dépassent finalement toutes les espérances et sont adoptées très rapidement par les constructeurs.
Il se pourrait que la virtualisation, le futur chantier planifié pour le noyau 2.8, fasse son apparition bien plus vite que prévu. Le Kernel Summit, le Congrès des développeurs du noyau, qui commence demain devrait nous apporter des réponses et planifier les axes de développement pour l'année à venir...
![[en]](../images/en.png)
La news originale (877 hits)![[fr]](../images/fr.png)
Naissance d'un mammouth (2711 hits)-
Kernel Summit (904 hits)
-
NUMA (762 hits)
-
Communiqué de presse SGI : "NCSA to Expand its High-Performance Computing Environment" (336 hits)
> Lire la dépêche (71 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #448878.
Run by 
Cette page a été générée par Templeet en 0.0961s (dont 0.0097 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
virtualisation
La virtualisation serait surtout un coup dur pour HP et ses superdôme et aussi pour IBM avec ses mainframe, c'était jusque ici leur chasse gardée.
Encore que.
Quand j'y pense, une entreprise ayant des besoins en environnement de travail possède déjà les machines ad hoc (et donc les progs qui viennent avec + compétences etc...).
Alors quel marché pour de telle machines ?
Quelle complexité d'administration ? quel seront les outils qui viendront avec ?
[^]Re: virtualisation
Il existe plusieurs solutions de virtualisation. Celle à laquelle j'ai pensé en écrivant cette news est vserver
http://www.solucorp.qc.ca/miscprj/s_context.hc(...)
http://www.linux-vserver.org/(...)
Cette solution de virtualisation surpasse tous ce qui se fait par ailleurs. Elle est super facile à administrer et nul doute que meme les serveurs de base l'utiliseront.
Il suffit d'assister à une présentation de vserver pour être définitivement convaincu de l'utilité du concept.
Il y a plein de serveurs en prod qui utilise déjà cette technologie dont...... linuxfr !
[^]Re: virtualisation
Perso, j'utilise aussi les vserver et franchement, c'est super simple à faire.
De plus, le gain de sécurité est impressionant. Un apache qui se fait avoir, seul le vserver pourra être rootkiter.
En plus, j'ai des potes qui se connecte à ma machine (IRC and co), bah genre, en cas de quelconque problème, seul ce vserver pourra se être utilisé. L'intégrité de la machine est toujours préservé.
En plus, dans le cadre de développement de logiciel (libre de préférence ;) ), on peut avoir des machines dans différentes versions. Exemple avec Debian : on peut avoir une machine hôte stable, et avoir une station de développement unstable. On a accès à la dernière version de toutes les librairies et on ne risque pas de mettre en péril l'intégrité de la machine hôte.
Bref, le pied ;)
++
Ludo
[^]Re: virtualisation
Certes, lorsque tu as un mainframe qui fonctionne, tu n'auras pas envie de le changer.
Ceci étant dit, dans le cadre du recyclage, il est évident que tu choisiras la solution la plus adaptée à ton problème.
Or, lorsque tu regardes à l'heure actuelle les évolutions, tu te rends compte, que certes le mainframe présente des avantages en termes d'administration. Mais dès lors que tu veux des performances supérieurs et [surtout] de l'évolutivité pour ton matériel/ton OS, la virtualisation est pour toi une/LA solution. Il faut évidemment une structure adaptée à ce changement (la machine citée dans l'article est d'ailleurs l'ancêtre de ces solutions).
Je crois que la virtualisation pourra et sera adoptée par les entreprises, dans le but de gagner en performance et en évolutivité.
Ceci étant dit, le principal problème que tu as cité sera bien évidemment, de faire comprendre aux entreprises, lors du renouvellement, que c'est ce genre de machine (enfin, peut-être pas non plus, celle là, car là c'est du spécifique), qui sera l'avenir.
Enfin bon, c'est mon avis.
[^]Re: virtualisation
Je ne connaissait pas vserver (mais chroot oui).
Il me semble que ce n'est pas tout à fait la même chose. Dessous, c'est toujours le même kernel qui tourne, avec le même espace mémoire etc...
Mais est ce qu'on peut avoir 2 kernels qui tournent en même temps (et de version différentes) comme cela est permis sur mainframe ? Est ce qu'on peut arrêter (rebooter) un des environnements sans toucher à l'autre ?
Sinon, à mon sens ce qu'il manque encore à linux (valable pour tout les unix à mon sens) c'est encore la stabilité. En 6 ans de boulot sur mainframe, j'ai du connaitre 3 ipl (redémarrage) et à chaque fois pour une monté en version de certaines parties de l'OS. Tout le reste est upgradé à chaud, en arrêtant seulement la partie concernée. Et puis il y a le pb des compétences. Quand tu as une armée de dev, d 'ingé système et pupitreur formé au mainframe, pas facile de prendre un virage technologique trop brusque pour une entreprise.
Ca marche, ça a couté cher et on connait bien. Quel décideur prendrai le risque de tout foutre en l'air ? Pour mémoire, les superdôme n'ont pas fait un malheur vu leur prix (3 Millions d'euro la bêbete, je parle pour des systèmes de puissance équivalente à un gros mainframe).
[^]Re: virtualisation
User Mode Linux permet justement de faire tourner un noyau différent de la machine hote (par contre au niveau de l'addressage mémoire, ca doit etre confondu)
[^]Re: virtualisation
Euh pas vraiment, l'espace d'adressage du noyau et celui de l'utilisateur sont différents. Et comme dit le nom de ce projet user-mode-linux: le noyau fonctionne en mode utilisateur. Donc techniquement, ceux sont deux espaces d'adressage différents :-)
--
Christophe
- Christophe -
[^]Re: virtualisation
Sur IA-64, le noyau et l'application sont dans le meme espace d'adressage. Par contre l'application ne peut pas acceder "facilement" aux valeurs de l'espace d'adressage du noyau.
Il y a plusieurs niveaux de privilege mais l'espace d'adressage est bien le meme.
[^]Re: virtualisation
Si on parle d'adressage virtuel alors non, sous Linux l'espace d'adressage virtuel d'un processus utilisateur va de 0 à 3Go et l'espace d'adressage virtuel du noyau de 3 à 4Go (4Go == 2^32 , donc sur ia32).
Mais sinon en effet, mais nous n'avions pas trop spécifié de quoi nous parlions :-)
--
Christophe
- Christophe -
[^]Re: virtualisation
s/sous Linux/sous Linux x86 vanilla/
Genre sur un noyau fedora tu as 4:4 d'activé (oui c'est tres con)
[root@loutre]~# cat /proc/self/maps ~
002c7000-002dc000 r-xp 00000000 fd:00 1441971 /lib/ld-2.3.3.so
002dc000-002dd000 r--p 00014000 fd:00 1441971 /lib/ld-2.3.3.so
002dd000-002de000 rw-p 00015000 fd:00 1441971 /lib/ld-2.3.3.so
002e0000-003f5000 r-xp 00000000 fd:00 1441973 /lib/tls/libc-2.3.3.so
003f5000-003f7000 r--p 00115000 fd:00 1441973 /lib/tls/libc-2.3.3.so
003f7000-003f9000 rw-p 00117000 fd:00 1441973 /lib/tls/libc-2.3.3.so
003f9000-003fb000 rw-p 003f9000 00:00 0
0079f000-007a0000 r-xp 0079f000 00:00 0
08048000-0804c000 r-xp 00000000 fd:00 950317 /bin/cat
0804c000-0804d000 rw-p 00003000 fd:00 950317 /bin/cat
08f34000-08f55000 rw-p 08f34000 00:00 0
f6e42000-f6e7f000 r--p 00aa5000 fd:00 200223 /usr/lib/locale/locale-archive
f6e7f000-f707f000 r--p 00000000 fd:00 200223 /usr/lib/locale/locale-archive
f707f000-f7080000 rw-p f707f000 00:00 0
fef77000-ff000000 rw-p fef77000 00:00 0
ffffd000-ffffe000 ---p 00000000 00:00 0
Tu peux aussi couper de pas mal d'autres manières et sur les archis 64 bits ca serait tres con de limiter l'espace d'adressage d'un processus a 3Go...
http://fxr.watson.org/fxr/source/include/asm-alpha/page.h?v=linux-2(...) 82 ou par exemple
[^]Re: virtualisation
Bien sûr que je parle du noyau officiel et non des divers patches que l'on peut appliquer. Il me semble logique de parler ce ce qu'il y a de plus commun en ce qui concerne cela.
Pour ceux que cela intéresse :
http://kerneltrap.org/node/view/2450?PHPSESSID=64f7f951d3e846fc9388(...)
Bonne journée.
--
Christophe
- Christophe -
[^]Re: virtualisation
Enfin la configuration normale du noyau officiel ;-) concernant cet aspect de la segmentation de ma mémoire :-)
--
Christophe
- Christophe -
[^]Re: virtualisation
Personnellement, en matière de stabilité, j'ai quelques serveurs UNIX sous ma garde.
J'en ai, mais bon, c'est de la triche, y'a pas souvent d'upgrade, mais, j'en ai avec plus de 2 ans d'uptime. Bref, mo'j'dis, honorable.
Bref, tout ça pour dire, que les seuls reboot qui sont effectués sont pour des changement de version. Dans le cas présents, je te parle d'OS genre : Digital UNIX, Sun et Linux (entre autres, ...).
Non, vraiment, je ne comprends pas ce que tu reproches en matière de stabilité aux machines UNIX.
[^]Re: virtualisation
Non non, je ne reproche rien à unix.
Je te crois tout à fait quand tu me parle d'uptime de 2 ans. Mais ça c'est un peu l'exception. J'ai travaillé sur des 10-proc sous HP-UX (des espèce de grosse machine à laver) et ça arrivait tout les 6 mois que la machine plante. Mais bon, faut voir l'utilisation qui en était faite. Cette machine servait de serveur de tests pour une multitudes d'appli en dev, de test avec des 10aines d'utilisateurs etc... 6 Mois d'uptime dans ces conditions c'est tout à fait honorable. Et sur une machine peu sollicité (tout est relatif, peu utilisé pour un serveur unix j'entend), 2 ans c'est tout à fait plausible et même plus. Mais sur mainframe, tu as un environnement de dev, d'integ et de prod (ou plus) sur une seule CPU (voire 2) avec des milliers d'utilisateurs 24h/24h (il ya l'exploitation la nuit qui mouline), et un uptime de 2 ans n'a rien, mais alors rien du tout d'exceptionnel.
Alors si la disponibilité d'un serveur unix est de 99%, celle d'un mainframe est 99.99% (dans mes souvenirs, IBM garantissait moins de 2 heures d'indisponiblité par an sur ses machines).
[^]Re: virtualisation
> Mais bon, faut voir l'utilisation qui en était faite. Cette machine servait de serveur de tests pour une multitudes d'appli en dev, de test avec des 10aines d'utilisateurs etc...
Le type d'utilisation est très important. Le hard aussi :-)
J'ai utilisé du Digital Unix avec 8 proc et la fiabilité était impressionnante alors que l'utilisation était "massive" (développeurs/utilisateurs/serveurs).
Dernier uptime connu (avant de quitter la boite) : 450 jours. Plusieur disques dures ont été changés durant cette période (merci raid5).
upload en journée était de 6 à 15 !
Un serveur Web qui tient 2 ans n'est vraiment pas impressionnant pour moi maintenant. Et c'est souvent le signe d'une machine peu entretenue (genre mise à jour noyau non appliquée).
[^]Re: virtualisation
En fait, toutes les machines IBM (hors grand public) utilise la virtualisation. Sur mainframe (ca fait deja pas mal de temps), les AS400 et maintenant les regatta (sucesseur des R6k) par ex le p690 qui permet d'allouer de la ressource a chaud a des "LPAR" (partition materiel virtuel). Tu aller jusqu'a attribuer des pouilleme de cpu/ram a un LPAR. C'est un peu moin souple pour attribuer des extension (un port PCI n'est pas partageable), mais une machine de base doit en autour d'une trentaine alors qu'elle est limitée a 3 LPAR.
Donc, y'a encore un peu de temps avant qu'un simple noyau concurrence une machine completement pense pour faire ca.
Pour info, la virtualisation interesse directement IBM, car les regatta sont livrable en AIX ou en Linux. Sauf que sous Linux, tu peux pas attribuer les elements a chaud...
[^]Re: virtualisation
quelqu'un pourrait m'expliquer brievement le concept de virtualisation?
ça permet de faire tourner plusieurs serveurs dans des sortes d'environnements chrooté (mais en mieu je suppose)c'est ça?
est-ce qu'on peux faire tourner 2 noyaux en même temps (avec usemod linux en plus peut-être ?)
Si oui, est-ce possible de changer un noyau a chaud (on lance un noyau, on en compile plus tard un autre, on le démarre et on coupe l'ancien...)? Ca permettrais de faire des jolis uptime :)
Archetype Javascript Framework : Faites le côté client!
[^]Re: virtualisation
C'est pas aussi FreeBSD qui sait faire de très bonne machines virtuelles à l'aide de la commande jail ?
Le but est sécuritaire, mais pas uniquement. On peut par exemple créer un jail pour apache, puis le chrooter dans sa prison. Ainsi il n'est pas possible d'attaquer l'OS lui même.
Linux ne possède pas d'équivalent aussi souple / flexible et facile à manipuler de jail qui n'existe que sur les BSD.
Au début, j'avais pensé à bande de chacals, vous allez tous crever comme des chacals, mais ça faisait deux fois chacals.
[^]Re: virtualisation
Non non on confond un peu tout dans ce thread. Je vais essayer de faire le point vite fait :
chroot : changement de la racine pour un processus (et donc tout ses fils). Ca ne fait rien d'autre. Avantage en sécurité si le chroot est bien pensé et avec un noyau prévu pour (grsec au hasard pour linux).
jail : concept de chroot plus poussé. la on ne touche plus uniquement au FS mais aussi aussi au pas mal de structures du noyau. Notament avec des restriction au niveau du reseau, process etc. Ainsi autant un processus dans un chroot peu faire n'importe quoi du point de vue syscall, FreeBSDverifie non pas l'uid 0 mais l'uid 0 et si le process est dans une jail. Avantage : sécurité, et souplesse d'administration (on peut laisser une jail a un client qui a un root sur la machine). Inconveniant : ce n'est pas de la virtualisation, le DoS est tres facile etc.
user mode linux: permet de faire tourner un linux dans un linux dans un linux. En gros ceci permet a un noyau d'utiliser comme architecture non pas le hardware mais un noyau. Tres couteux en performance et utile uniquement pour le debug. Ca n'apporte rien dans la virtualisation ou tres peu pratique. Aucun controle, impossibilite de toucher au noyau qui s'addresse au materiel. Bref ce n'est pas sont but.
vserver : je connais mal, mais le principe est dans l'idee des jails. Un seul noyau, que plusieurs sous environements utilisent. Par contre le controle des ressources a l'air d'etre plus abouti (inexistant avec les jails actuelles) avec notament des limites sur les processus, la memoire, le disque, le temps CPU. Reste a voir si c'est correctement implémenté on a souvent des surprises :-)
On reste bien loin des UNIX proprio avec toutes ces solutions. Mais c'est un axe de developpement interessant. D'ailleur FreeBSD a toujours la network stack virtualization de marco Zec dans les cartons qui ne demande qu'a etre developpe :-)
Note : Ainsi il n'est pas possible d'attaquer l'OS lui même.
Tout ne repose que sur un seul noyau (comme toutes les solutions presentés ici) donc une faille dans le noyau compromet la machine en entier. Vu le nombre de faille locale trouvées et trouvables... De plus les jails ne sont pas faciles a manipuler il s'agit d'ailleur d'un axe de developpement et de reecriture. Dans l'etat actuel des choses c'est trop ou trop peu. Avec une meilleure integration de MAC la dedans on pourrait faire de jolies choses amha.
[^]Re: virtualisation
Et xen ( http://www.cl.cam.ac.uk/Research/SRG/netos/xen/(...) ) dans tout ça ? Ça se situe où ?
[^]Re: virtualisation
>>Si oui, est-ce possible de changer un noyau a chaud (on lance un noyau, on en compile plus tard un autre, on le démarre et on coupe l'ancien...)? Ca permettrais de faire des jolis uptime :)
Ca kexec permet de le faire, ou du moins de s en approcher, par contre pour ton uptime...
- article d ibm developerWorks: http://www-106.ibm.com/developerworks/linux/library/l-kexec.html(...)
- depeche (assez recente) sur linuxfr: http://linuxfr.org/2004/05/18/16263.html(...)
voila voila...
[^]Re: virtualisation
Comme indiqué dans les precedentes depeches kexec ne permet pas de changer son noyau a chaud. Ca permet d'eviter le reboot materiel et d'attendre longtemps... Tout l'executif lui est perdu le terme ne s'applique donc pas amha.
Dans un article sur DTrace les mecs de SUN parlent de 2h pour booter un SunFire 15k y'aurait un gain appreciable.
[^]Re: virtualisation
>> Comme indiqué dans les precedentes depeches kexec ne permet pas de changer son noyau a chaud.
pour ca que j avais dit "ou de s en approcher"
>> Tout l'executif lui est perdu
je n ai pas testé kexec, je donais juste ces liens a titre informatifs,en d autre termes j essayais juste de donner des pistes pour un truc que je connais a peine donc fallait s attendre a quelques coquilles :) Peut etre qu une utilisation couplé au suspend to RAM permettrait conserver cet executif, theoriquement ca a l air fesable (avec peut etre quelques bidouilles), apres je peux pas t en dir plus...
[^]Re: virtualisation
Tres brievement et schematiquement :
Un serveur est compose en gros de CPUs, RAMs et cartes I/Os.
Une partition hardware consiste chez HP (je ne connais pas les IBMs :( ), a affecter un certain nombre de ces elements materiels a un serveur virtuel. Cette nPar (partition hardware chez HP), virtualise une machine. Si il te reste des composants encore disponibles, tu peux les affecter a d'autres nPar. Attention, il y a un certain nombre de regles a respecter qui decoulent de l'architecture hardware de la machine (ce n'est pas le sujet ici). Pour realiser ceci, tu utilises une interface type RS232 sur terminal passif qui te permet d'acceder a un genre de BIOS, et de configurer ton serveur.
Une fois ta machine decoupee en nPar, tu peux installer au sein de chacune des partitions hardware, un outil appele vPar (partitions virtuelles). Cela consiste en l'utilisation d'un noyau specifique (VPMON au lieu de HPUX) qui te permettra de constituer de nouvelles partitions (machines) mais cette fois ci se partageant les ressources materielles de ta partition hardware. Dans le meme esprit que precedemment, tu vas pouvoir utiliser des outils (commandes UNIX agissant a travers le noyau VPMON) pour definir des partitions virtuelles et leurs affecter des ressources materielles mises a dispo au sein de la partition virtuelle.
Voila schematiquement comment tu decoupes ta boiboite en serveurs independants materiellements (nPar) et serveurs partageant le meme hardware (vPar).
Les interets sont nombreux, pour moi, je vois :
- En nPar, separation stricte des serveurs, donc avec une boiboite j'ai l'equivalent de plusieurs serveurs. Je gagne en espace, alime electriques, infrastructure quoi.
- J'ai sous la main un environnement configurable a volonte. T'as besoin de 2 machines suplementaires pour faire un test, pas de problemes, je cree 2 vPar.
- Le serveur d'applis turbine la journee, ok, je lui met un max de CPUs, et la nuit je les lui retire pour les affecter au serveur de BD afin de turbiner les batchs.....
Voila, j'espere t'avoir eclairer, depuis que je bosse dans le hardware informatique (mini etc...) c'est je pense le developpement le plus innovant.
Cordialement