jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Articles

Liens connexes

La news originale (865 hits)
Naissance d'un mammouth (2694 hits)
Kernel Summit (891 hits)
NUMA (748 hits)
Communiqué de presse SGI : "NCSA to Expand its High-Performance Computing Environment" (326 hits)

Dépêche modérée par

Nimbus80

Dépêche éditée par

Articles : Linux devient massivement multiprocesseurs

Posté par Christophe Merlet (page perso, ). Modéré le 19 juillet 2004.

Après être devenu incontournable dans le domaine des gros clusters (plusieurs centaines de noeuds), voici que Linux devient une référence sur les systèmes massivement multi-processeurs.

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...

La news originale (865 hits)
Naissance d'un mammouth (2694 hits)
Kernel Summit (891 hits)
NUMA (748 hits)
Communiqué de presse SGI : "NCSA to Expand its High-Performance Computing Environment" (326 hits)

> Lire la dépêche (71 commentaires, moyenne: 3,6).

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.

Petite question

Posté par xahlexx (page perso, ) le 19/07/2004 à 08:07. (lien). Évalué à 2.

Une machine comme cela, vous avez une idée du prix que cela doit couter ? C'est énorme comme machine, un "top" la dedans doit être impressionnant :)

[^]Re: Petite question

Posté par phenix (page perso, ) le 19/07/2004 à 08:21. (lien). Évalué à 5.
Moi aussi j'ai une petite question. Comment les developeurs du noyeau font pour savoir que leur code fonctione ?

Ont t'il un fabriquant qui leur donne accés a une telle machine pour faire leur developement ?
- [^]Re: Petite question
  
  Posté par Jean-Max Reymond (page perso, ) le 19/07/2004 à 08:27. (lien). Évalué à 9.
  Les développeurs sont des salariés du constructeur SGI et donc un accès privilégié à la machine.
  Maintenant, cas classique, le hardware est toujours en retard ;-) alors tu valides ton code sur une machine qui a beaucoup moins de processeurs, de mémoire et quand le proto devient un petit peu opérationnel, tu testes (et debogues !!!) ton code et aussi le proto !!!
  
  --
  CKR Solutions Open Source
  - [^]Re: Petite question
    
    Posté par 007 () le 19/07/2004 à 08:31. (lien). Évalué à 1.
    Et réciproquement, on ne fait pas de hardware aussi cher s'il n'y a pas d'OS déjà développé (sur de petites configs) pour tourner dessus.
  - [^]Pas toujours
    
    Posté par vsin () le 19/07/2004 à 09:09. (lien). Évalué à 8.
    > le hardware est toujours en retard ;-)
    
    J'ai bien note ton smiley, mais ce n'est pas toujours le cas. Les OS mettent souvent du temps a exploiter les possibilites offertes par le Hardware.
    
    Un exemple : Pratiquement tous les serveurs (on est bien d'accord, pas les PC boostes) archi Intel supportent l'installation et l'extraction des cartes I/O a chaud. Quid des OS ? Et combien de temps apres la mise a dispos de la fonctionnalite ?
    
    Contre-reflection : Les utilisateurs en avaient reellement besoin ?
    
    Cordialement
    
    Vsin
    - [^]Re: Pas toujours
      
      Posté par o°Oo°Oo°o°O°Oo° o°Oo°Oo°o°O°Oo° () le 19/07/2004 à 15:42. (lien). Évalué à 4.
      Si je ne me trompe pas, le hot-plug (branchement à chaud) PCI a été introduit par Compaq et fonctionnait déjà sous Windows NT4 à l'aide d'un logiciel Compaq. Ensuite, la chose a été supporté d'office par Windows 2000.
      
      Côté fonctionnalité, c'est impressionnant de changer une carte alors que le serveur tourne encore, juste en précisant avant au système qu'il faut arrêter de l'alimenter. Tout le reste du système tourne encore, donc il n'est plus nécessaire de procéder à un redémarrage en pleine période d'exploitation pour changer une carte réseau d'un teaming ou autre ! :-)
      
      Pour info, les serveurs Compaq sont remarquablement bien faits côté hot-plug et redondance (ventilos, alims, processeurs, banques mémoires, etc.)
  - [^]Re: Petite question
    
    Posté par Guillaume Knispel () le 19/07/2004 à 14:02. (lien). Évalué à 2.
    Ouai, si le code marche avec 4, 8, et 16 procs, il y a des chances qu'il fonctionne aussi avec 1024 :p (y a que microsoft pour vouloir faire croire le contraire ;)
    
    Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
    - [^]Re: Petite question
      
      Posté par Guillaume POIRIER (page perso, ) le 19/07/2004 à 15:07. (lien). Évalué à 6.
      Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
      En effet, le code fonctionne, mais les problèmes d'échelles font qu'il est nécessaire de repenser certains mécanismes, améliorer la granularité, etc... et tout cela demande beaucoup, beaucoup de temps, et des gens très brillants pour trouver des solutions élégantes à ces problèmes de changement d'échelle.
      C'est ce qui fait que Solaris se vend encore très bien dans les domaines de serveur de multi-processeur pour applications de types transactionnelles (SGDB typiquement) (cf. http://www.sun.com/servers/highend/(...) )
      ... enfin, en voyant cette news, je me demande combien de temps tiendront encore les gros Unix... il ne leur restera pour se démarquer les uns des autres d'axer leur offre sur le hard super fiable (et encore!)
    - [^]Re: Petite question
      
      Posté par mdlh () le 19/07/2004 à 16:44. (lien). Évalué à 2.
      Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
      
      L'une des subtilites est de gerer des informations sur des champs de bits. Forcement a 2 bits par processeurs sur un mot de 32 bits, 1024 processeurs, ca tient pas.
      
      Les developeurs de SGI ont ecrit un patch pour lever cette limite.
    - [^]Re: Petite question
      
      Posté par Matthieu Moy (page perso, ) le 19/07/2004 à 18:26. (lien). Évalué à 16.
      > Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
      
      Ouais, quelques subtilités, comme tu dis ;-)
      
      Pour des applications fesant du calcul pur, effectivement, la question est relativement facile à régler au niveau de l'OS. C'est au niveau applicatif qu'il faut paralléliser les algos.
      
      Maintenant, si tu prends une application comme un gros SGBD, ou quelque chose qui utilise beaucoup d'appels systèmes, tu passes facilement 20% du temps dans les couches noyau. Maintenant, tu imagines bien que si deux processeurs executent en parallèle deux bouts de code qui touchent au mêmes données, ou au même périphérique, tu as 99% de chances d'avoir un truc déconnant. Il faut donc placer des verrou pour assurer l'exclusion mutuelle de certaines portions de code dans le noyau. L'approche la plus simple (c'est en gros comme ça que ça se passait dans les premiers Linux SMP), c'est de mettre un gros verrou sur l'ensemble du noyau, ce qui fait que deux processeurs ne peuvent pas executer du code en mode noyau en même temps. Ca marche assez bien sur 2 processeurs, parce que pendant qu'un processeur execute du code dans le noyau, l'autre processeur a en général un processus à executer. Mais évidement, si tu passes 20% du temps dans le noyau, et que tu as plus de 5 processeurs, alors tu as toujours plusieurs processeurs qui n'ont rien à faire. C'est (entre autres) pour ça qu'un Linux 2.2 a du mal sur une machine quadri-proc, et n'arrive vraiment pas à utiliser correctement 8 procs.
      
      Pour utiliser correctement un grand nombre de processeurs, il faut donc que les verroux d'exclusion mutuelle dans le noyau soient le plus fins possibles. Qu'un processeur puisse écrire sur un disque dur pendant qu'un autre écrit sur un autre disque par exemple. Il y a déjà eu beaucoup de progrès dans ce domaine depuis Linux 2.2, mais avant d'exploiter correctement 1024 processeurs, il y a encore du boulot !
      
      Ce n'est bien sur pas le seul problème. Par exemple, quand le noyau doit choisir entre 5 ou 10 processus éligibles (ce qui correspond déjà à une machine très chargée pour un mono ou bi-processeur), tu t'en fout pas mal que l'algo de scheduling soit en O(n), O(log(n)) ou en O(1). Sur une machine 1024 procs, tu as au moins 1024 taches éligibles à chaque instant quand ta machine est chargée, et la, la finesse des algos fait la différence.
      
      Bref, avoir un systeme qui tourne sur 1024 procs, c'est assez facile, mais avoir un des perfs acceptables sur un tel système (avoir un système qui n'est pas trop loin d'être 1024 fois plus rapide qu'un système mono-processeur), c'est une autre paire de manches !
- [^]Re: Petite question
  
  Posté par capicapio () le 20/07/2004 à 08:46. (lien). Évalué à 1.
  A mon avis, ils utilisent des modules qui simulent le fonctionnement d'un grand nombre de CPU.

Scheduling domains

Posté par 007 () le 19/07/2004 à 08:22. (lien). Évalué à 18.

Il y a eu des travaux récents dans Linux 2.6 . Le 2.6.0 n'était pas très satisfesant.
Le 2.6.6 (ou 7?) a introduit "scheduling domains" dont il y a ici une excellente présentation :
http://lwn.net/Articles/80911/(...)

La difficulté n'est pas d'avoir plein de CPU mais de les faires travailler en même temps.

[^]Re: Scheduling domains

Posté par phenix (page perso, ) le 19/07/2004 à 10:25. (lien). Évalué à 2.
Sous linux seul un procesus par CPU ne tourne a l'instant T.

Donc pour les faire travailler en même temps, je pense qu'il faut qu'il y est autant de procesus ouvert que de CPU.

Peut etre que je me trompe, je pense que c'est pour ca que la commande "ps aux " donne par exemple apache ouvert plusieurs fois
- [^]Re: Scheduling domains
  
  Posté par 007 () le 19/07/2004 à 11:26. (lien). Évalué à 2.
  > Sous linux seul un procesus par CPU ne tourne a l'instant T.
  
  Ou thread (du moins avec NPTL, linuxthread fesait des équivalents de fork()).
  - [^]Re: Scheduling domains
    
    Posté par Florian Fainelli (page perso, ) le 19/07/2004 à 11:37. (lien). Évalué à 6.
    Le fait que apache lance plusieurs démons n'a rien avoir avec le nombre de processeurs. Ce sont juste des processus fils qui permettent d'accélerer le service web, c'est transparent pour le navigateur.
    
    --
    Au début, j'avais pensé à bande de chacals, vous allez tous crever comme des chacals, mais ça faisait deux fois chacals.
    - [^]Re: Scheduling domains
      
      Posté par 007 () le 19/07/2004 à 11:48. (lien). Évalué à 2.
      Je vois pas de quoi tu parles.
      Apache 2 mixe les threads et les processus. Du moins lorsqu'il est compilé avec les bonnes options.
      Puis le mode "processus" ne manque pas d'intérêt (typiquement lorqu'un module plante).
      btw : apache augmente le nombre de processus/thread en fonction de la demande. C'est configurable via httpd.conf.
      - [^]Re: Scheduling domains
        
        Posté par Matthieu Moy (page perso, ) le 19/07/2004 à 13:18. (lien). Évalué à 5.
        Apache 2, je sais pas, mais si mes souvenirs sont bons, le 1 gère un "pool" de processus : Partant du principe que le fork() est une opération couteuse, il en fait quelques uns d'avance, mais les processus créés sont suspendus jusqu'à une réception de requête HTTP. D'ou les multiples httpd, même quand le serveur ne fait rien.
        
        [^]Re: Scheduling domains
        
        Posté par ham () le 19/07/2004 à 15:13. (lien). Évalué à 1.
        C'est une vielle astuce, le pool de ressource:
        
        memoire, threads, processus, etc...
        
        Les caches memoire sant dans la ligne des pools:
        
        tu rapatrie plus que necessaire, en te basant sur le fait que tu as de forte probabilite d'en avoir besoin.
    - [+] [^]Re: Scheduling domains
      
      Posté par 007 () le 19/07/2004 à 11:58. (lien). Évalué à -2.
      > Le fait que apache lance plusieurs démons n'a rien avoir avec le nombre de processeurs.
      
      Ooops. Je viens de comprendre (rapport au début du thread).
      Quoiqu'il en soit une connexion est faite avec ip:port:processus (si mes souvenirs sont bons car c'est vieux). Donc par moment que les thread (même pid) ça peut être insuffisant (rien à voir avec le nombre de processeurs).
- [^]Re: Scheduling domains
  
  Posté par David () le 19/07/2004 à 11:40. (lien). Évalué à 2.
  Exactement apache forke à chaque nouvelle connection. Autant de processus que de connections.
  - [^]Re: Scheduling domains
    
    Posté par KiKouN (Jabber id, ) le 19/07/2004 à 11:47. (lien). Évalué à 1.
    Plus exactement, il fork en prévision de nouvelles connexions.
    
    --
    KiKouN, Bucheron-Geek
- [^]Re: Scheduling domains
  
  Posté par capicapio () le 20/07/2004 à 08:50. (lien). Évalué à 1.
  Sous Linux comme sous n'importe quel OS multiprocesseur!
  Ou alors il faudra qu'on m'explique comment il peut y avoir plus de processus qui tournent que de processeurs à un instant T.
  - [^]Re: Scheduling domains
    
    Posté par briaeros007 () le 23/07/2004 à 20:46. (lien). Évalué à 1.
    sur des archi hyper scalaire?
    en utilisant des processeurs vectoriel et faires des calculs lineaires avec une surcouche?
    
    pas la peine de m'indiquer la sortie ---> [-]
    
    --
    Subete ga wakatta toki…watashi ga anta wo korosu.

virtualisation

Posté par calvin0c7 () le 19/07/2004 à 08:24. (lien). Évalué à 5.

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

Posté par Christophe Merlet (page perso, ) le 19/07/2004 à 08:32. (lien). Évalué à 16.
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
  
  Posté par Ludovic Desfontaines (page perso, ) le 19/07/2004 à 08:47. (lien). Évalué à 11.
  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

Posté par Ludovic Desfontaines (page perso, ) le 19/07/2004 à 08:40. (lien). Évalué à 4.
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
  
  Posté par calvin0c7 () le 19/07/2004 à 09:09. (lien). Évalué à 8.
  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
    
    Posté par rarcel (page perso, ) le 19/07/2004 à 10:12. (lien). Évalué à 3.
    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
      
      Posté par Christophe Lucas (page perso, ) le 19/07/2004 à 11:46. (lien). Évalué à 5.
      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
        
        Posté par mdlh () le 20/07/2004 à 09:10. (lien). Évalué à 3.
        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
        
        Posté par Christophe Lucas (page perso, ) le 20/07/2004 à 15:28. (lien). Évalué à 1.
        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
        
        Posté par cykl (Jabber id, ) le 21/07/2004 à 22:25. (lien). Évalué à 2.
        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
        
        Posté par Christophe Lucas (page perso, ) le 24/07/2004 à 08:44. (lien). Évalué à 1.
        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
        
        Posté par Christophe Lucas (page perso, ) le 25/07/2004 à 10:49. (lien). Évalué à 1.
        Enfin la configuration normale du noyau officiel ;-) concernant cet aspect de la segmentation de ma mémoire :-)
        
        --
        Christophe
        
        --
        - Christophe -
  - [^]Re: virtualisation
    
    Posté par Ludovic Desfontaines (page perso, ) le 19/07/2004 à 10:47. (lien). Évalué à 2.
    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
      
      Posté par calvin0c7 () le 19/07/2004 à 12:27. (lien). Évalué à 3.
      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
        
        Posté par 007 () le 19/07/2004 à 12:48. (lien). Évalué à 3.
        > 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

Posté par GP Le (page perso, ) le 19/07/2004 à 09:21. (lien). Évalué à 10.
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

Posté par Temsa (Jabber id, page perso, ) le 19/07/2004 à 11:21. (lien). Évalué à 1.
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
  
  Posté par Florian Fainelli (page perso, ) le 19/07/2004 à 11:40. (lien). Évalué à 2.
  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
    
    Posté par cykl (Jabber id, ) le 19/07/2004 à 12:33. (lien). Évalué à 14.
    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
      
      Posté par Antoine J. (Jabber id, ) le 19/07/2004 à 17:56. (lien). Évalué à 1.
      Et xen ( http://www.cl.cam.ac.uk/Research/SRG/netos/xen/(...) ) dans tout ça ? Ça se situe où ?
- [^]Re: virtualisation
  
  Posté par gebura () le 19/07/2004 à 16:06. (lien). Évalué à 1.
  >>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
    
    Posté par cykl (Jabber id, ) le 19/07/2004 à 16:52. (lien). Évalué à 4.
    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
      
      Posté par gebura () le 19/07/2004 à 19:08. (lien). Évalué à 5.
      >> 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
  
  Posté par vsin () le 20/07/2004 à 07:37. (lien). Évalué à 4.
  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

Documentations ?

Posté par xahlexx (page perso, ) le 19/07/2004 à 08:31. (lien). Évalué à 3.

Existe-t-il des documentations sur l'utilisation de deux noyaux en même temps, pour plusieurs CPU ?

Oui bon....

Posté par Psylo (page perso, ) le 19/07/2004 à 08:36. (lien). Évalué à 6.

Combien de FPS à Doom 3 avec tout ça ?

[+] [^]Re: Oui bon....

Posté par Olivier Serve (Jabber id, page perso, ) le 19/07/2004 à 08:56. (lien). Évalué à -2.
Ah, mais faut d'abord installer le driver nvidia ...

Quoique, non, c'est SGI donc C pas du nVidia
Lynchez-moi lynchez-moi lynchez-moi ....
- [^]Re: Oui bon....
  
  Posté par Bobyl - Le nounours () le 19/07/2004 à 13:01. (lien). Évalué à 1.
  > Quoique, non, c'est SGI donc C pas du nVidia
  
  Vous m'arrêtez si je me trompe mais il me semblait qu'aux premières heures, SGI et nVidia avaient travaillé ensemble sur les drivers Linux (à l'époque des GeForce). Il me semble que c'était parce que SGI voulait utiliser des GeForce à la place de leurs cartes (plus chères et finalement aussi puissantes).
  
  Mais bon, je dis ptet une ânerie là...
  - [^]Re: Oui bon....
    
    Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 19/07/2004 à 13:48. (lien). Évalué à 2.
    SGI c'est eux qui sont responsables de OpenGL, donc forcément, ça a un lien avec les drivers Nvidia qui sont des drivers OpenGL... :-)

2 noyaux !?

Posté par Pinaraf (Jabber id, ) le 19/07/2004 à 09:07. (lien). Évalué à 2.

Comment ça marche avec 2 noyaux ? Comment ils font au boot, comment les tâches se partagent... ?

[^]Re: 2 noyaux !?

Posté par Dalton joe (page perso, ) le 19/07/2004 à 09:17. (lien). Évalué à 4.
Et avec acpi, longrun, swsusp, et laptop-mode il vont pouvoir économiser pas mal d'énergie.

[^]Re: 2 noyaux !?

Posté par Ben A. (page perso, ) le 19/07/2004 à 17:59. (lien). Évalué à 1.
Avec ce type de becanes avec plein de processeurs, il est souvent (voire toujours) possible de répartir les ressources et de les grouper sur plusieurs machines.
En gros, tu peux jouer au lego virtuel et créer plusieurs machines plus petites qui seront vues comme des machines autonomes (meme si, physiquement, elles sont dans le meme boitier)

Par exemple, les grosses SUN (style E6500 & co) font ca depuis des temps immemoriaux.

Evidemment, l'archi hardware est developpé spécifiquement pour ca.
- [^]Re: 2 noyaux !?
  
  Posté par Jérôme Fenal (page perso, ) le 20/07/2004 à 08:07. (lien). Évalué à 1.
  C'est même ce qu'on appelle de la virtualisation.
  
  Ce qui existe effectivement sur les gros Sun (E10k, SF15k et petits frères), mais aussi HP (Superdome), Alpha (Galaxy), IBM (p690 Regatta et p670), IBM zSeries (virtualisation matérielle et logicielle), etc.
  
  Tu peux même le faire sur ton PC (virtualisation logicielle) avec VMWare ou les Vserver (http://www.linux-vserver.org/(...)).
  
  Et mon petit doigt me dit que ça va arriver en matériel sur les serveurs PC d'ici peu de temps.

ça tombe bien

Posté par titititi () le 19/07/2004 à 12:08. (lien). Évalué à 0.

avec la sortie de Doom3...!

[^]Re: ça tombe bien

Posté par earxtacy (Jabber id, ) le 19/07/2004 à 13:13. (lien). Évalué à 4.
Non ils vont le preter a la SNCF ^^

Plus d'infos sur Altix

Posté par Christophe Merlet (page perso, ) le 19/07/2004 à 13:13. (lien). Évalué à 8.

La lecture du communiqué de presse de SGI http://www.sgi.com/newsroom/press_releases/2004/july/ncsa.html(...) apporte plus d'infos sur la bête.
Entre autres elle aura une capacité de stockage de masse de 370 To.

Ce monstre devrait servir à faire des simulations sur l'évolution de l'univers. Moi qui pensais naïvement que tout le monde connaissait déjà la réponse...

[^]Re: Plus d'infos sur Altix

Posté par Gart Algar (Jabber id, ) le 19/07/2004 à 14:36. (lien). Évalué à 4.
Ils veulent surement trouver d'abord _la question_

--
Ubuntu is an ancient african word meaning : "I can't configure Debian"
- [^]Re: Plus d'infos sur Altix
  
  Posté par Simon Huet () le 19/07/2004 à 16:49. (lien). Évalué à 2.
  Je te rappelle que la question, tu es assis dessus :)
  
  --
  In this world of a million religions
  everyone prays the same way

et le cpu MIPS ?

Posté par Thierry Boudet (page perso, ) le 19/07/2004 à 16:52. (lien). Évalué à 2.

Je me pose une petite et futile question: pourquoi on-t-ils choisi le processeur Itanium plutôt qu'un MIPS ? Demande du client, supériorité technologique, meilleur support du multiproc ?

--
( Zzzzzzzzz... )

[^]Re: et le cpu MIPS ?

Posté par mdlh () le 19/07/2004 à 17:03. (lien). Évalué à 2.
Le NCSA n'en est pas a son premier Itanium. Ils ont deja un cluster et pour avoir parle avec certain d'entre eux, ils ont l'air d'en etre assez content.

Apres il me semble qu'effectivement que l'Itanium se debrouille assez bien dans un environment multi-proc.

[^]Re: et le cpu MIPS ?

Posté par gallenza () le 19/07/2004 à 17:27. (lien). Évalué à 3.
Fait un tout sur spec.org et tu comprendras très vite !!!
Le meilleur MIPS est actuellement 4 fois moins performant que le meilleur Itanium, et toute la statégie de SGI, qui est en situation financière relativement difficile et n'a pas les moyens de supporter les frais astronomique de R&D pour un CPU performant, est de lentement mais sûrement switcher sa gamme des MIPS aux Itanium....et de Irix à Linux !!!

CPU dans les Mainframes

Posté par gallenza () le 19/07/2004 à 17:29. (lien). Évalué à 0.

Quelqu'un pourrait-il m'éclairer sur l'architecture processeurs des Mainframes...et ou il serait possible de trouver de la doc dessus...

[^]Re: CPU dans les Mainframes

Posté par calvin0c7 () le 19/07/2004 à 19:47. (lien). Évalué à 3.
Quelques éléments de réponse :

Grand système IBM :
http://solutions.journaldunet.com/0403/040330_mainframe.shtml(...)

MVS :
http://fr.wikipedia.org/wiki/MVS(...)

Plus technique :
http://www-1.ibm.com/servers/eserver/zseries/library/literature/ref(...)

Qques photos :
http://www.ericom.com/images/wbt5.gif(...)
http://images.google.fr/imgres?imgurl=http://www.sfrisch.com/images(...)
3270 powaaa
http://www.bomara.com/FTP/products/hostlink97/3270.gif(...)
http://www.dn-computing.com/images/Screen2.JPG(...)
- [^]Re: CPU dans les Mainframes
  
  Posté par gallenza () le 20/07/2004 à 00:19. (lien). Évalué à 0.
  Je ne trouve aucune doc sur l'architecture des CPU des mainframes...mais cette doc est-elle public????
  - [^]Re: CPU dans les Mainframes
    
    Posté par KDYY4RF () le 20/07/2004 à 13:27. (lien). Évalué à 1.
    Tu devrais trouver ton bonheur dans les redbooks, notamment celui la :
    
    http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246(...)
    - [^]Re: CPU dans les Mainframes
      
      Posté par gallenza () le 20/07/2004 à 20:54. (lien). Évalué à 0.
      Merci beaucoup

Du plus petit au plus gros

Posté par Jérôme Fenal (page perso, ) le 19/07/2004 à 17:32. (lien). Évalué à 2.

il est rigolo de constater que la machine s'appelle Cobalt, du même que les plus petits systèmes linux (en leur temps)...

Petite erreur

Posté par bill236 () le 29/07/2004 à 07:57. (lien). Évalué à 1.

D'après l'autre article, je crois que c'est 1024 et pas 10240.
De toutes façons, ça me parait plus réaliste.
Quoique 10240, ça le ferait surement! :)

A+

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Linux devient massivement multiprocesseurs

Petite question

[^]Re: Petite question

[^]Re: Petite question

[^]Re: Petite question

[^]Pas toujours

[^]Re: Pas toujours

[^]Re: Petite question

[^]Re: Petite question

[^]Re: Petite question

[^]Re: Petite question

[^]Re: Petite question

Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

[+] [^]Re: Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

[^]Re: Scheduling domains

virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

[^]Re: virtualisation

Documentations ?

Oui bon....

[+] [^]Re: Oui bon....

[^]Re: Oui bon....

[^]Re: Oui bon....

2 noyaux !?

[^]Re: 2 noyaux !?

[^]Re: 2 noyaux !?

[^]Re: 2 noyaux !?

ça tombe bien

[^]Re: ça tombe bien

Plus d'infos sur Altix

[^]Re: Plus d'infos sur Altix

[^]Re: Plus d'infos sur Altix

et le cpu MIPS ?

[^]Re: et le cpu MIPS ?

[^]Re: et le cpu MIPS ?

CPU dans les Mainframes

[^]Re: CPU dans les Mainframes

[^]Re: CPU dans les Mainframes

[^]Re: CPU dans les Mainframes

[^]Re: CPU dans les Mainframes

Du plus petit au plus gros

Petite erreur