Erwan Velu a écrit 10 commentaires

  • [^] # Re: Equivalent de Symantec Ghost

    Posté par  . En réponse au journal Equivalent de Symantec Ghost. Évalué à 2.

    utilises grub, il est moins con que lilo :)
  • [^] # Re: Equivalent de Symantec Ghost

    Posté par  . En réponse au journal Equivalent de Symantec Ghost. Évalué à 2.

    utilises grub, il est moins con que lilo :)
  • # Re: Equivalent de Symantec Ghost

    Posté par  . En réponse au journal Equivalent de Symantec Ghost. Évalué à 2.

    Dans le projet CLIC (http://clic.mandrakesoft.com(...)) & MandrakeClustering (http://www.mandrakeclustering.com(...)) on utilise un melange de ka tools (http://ka-tools.sf.net(...)) et de urpmi parallel qui permettent d'installer en parallel des machines puis de les maintenir au niveau RPM (maj, etc..)

    Les ka tools permettent une diffusion plus performante que le multicast/broadcast sur un parc !
    Avec le melange KA + PXE + MDK, on arrive a installer une serie de machine a partir d'une machine source en ~3minutes ! Le déploiement s'effectue a 10-11MB/sec sur un reseau 100Mb switche. Le systeme autoadapte ensuite le modules.conf de chaque machine pour obtenir une machine viable, puis relances lilo :o)

    "Urpmi parallel" permet apres d'assurer la maintenance des versions de RPM sur tous les machines d'un parc. La diffusion des RPM est alors ultra rapide car basée sur la techno KA.

    Voili,

    PS:Tout est déjà intégré & configurer dans CLIC &MandrakeClustering.
  • # Re: Filesystem

    Posté par  . En réponse au journal Filesystem. Évalué à 2.

    Tu peux regarder du coté des systèmes fichiers utilisés dans le monde du cluster, tu y trouveras peut etre ton bonheur.

    OpenGFS (http://opengfs.sourceforge.net/index.php(...)),
    Lustre (http://www.lustre.org/index.html(...)),
    PVFS (http://www.parl.clemson.edu/pvfs/index.html(...)),
    NFSP (http://www-id.imag.fr/Laboratoire/Membres/Lombard_Pierre/nfsp/(...))
  • [^] # Re: Lecteur DivX des platines Kiss sous licence GPL

    Posté par  . En réponse à la dépêche Lecteur DivX des platines Kiss sous licence GPL. Évalué à 2.

    Cette version de busybox & uClinux a l'air un peu modifiée pour leur matériel. C'est deja un bon début mais c'est pas suffisant. (Voir mon message plus loin)
  • # Re: Lecteur DivX des platines Kiss sous licence GPL

    Posté par  . En réponse à la dépêche Lecteur DivX des platines Kiss sous licence GPL. Évalué à 7.

    Pour avoir regarder le contenu de ce zip, je trouve que l'annonce CLUBIC est un peu pompeuse.
    Ce Zip contient "juste" un busybox & le kernel uClinux : juste le minimum. A moins que j'ai raté quelquechose il n'y a pas le lecteur multimedia en tant que tel et pas non plus les scripts & Makefile pour generer un firmware complet pour upgrader sa machine. Il faudra aussi le bon compilo pour faire une cross compilation correcte pour ARM. ;o)
    Je reste donc sceptique sur les possibilités brutes offerte par ce KIT. Il va falloir encore pas mal de taf de la part de la communauté pour en faire quelquechose de facilement utilisable. Ca me rappelle quelquechose...
  • [^] # Re: CLIC 2 est disponible !

    Posté par  . En réponse à la dépêche CLIC 2 est disponible !. Évalué à 2.

    Le but de CLIC est de permettre l'installation rapide d'un cluster complet depuis rien. CLIC autoconfigure donc tout un réseau et prépare les services suivants:
    DNS, DHCP, NIS, AUTOFS, NFS, NTP, PXE, TFTP
    et configure aussi les applications
    ScalablePBS, MAUI, MPICH, LAM/MPI, PVM

    Plus toutes les petites astuces pour avoir un ssh root sur les noeuds depuis le serveur, ou un ssh/rsh disponible pour les utilisateurs du réseau, etc...

    Bref, faire simple et rapide. :o)
  • [^] # Re: CLIC 2 est disponible !

    Posté par  . En réponse à la dépêche CLIC 2 est disponible !. Évalué à 2.

    CLIC 2 fonctionne sur le même principe aujourd'hui comme CLIC 1, un système d'exploitation par machine et stocké sur le disque dur de celle-ci.
    CLIC ne permet pas aujourd'hui de faire de clusters "diskless" mais je ne vois pas cela comme un handicap pour le produit. Ce sont des concepts un peu differents. Certes cela coute un peu plus cher d'avoir des disques dur dans un cluster dédié mais la maintenance et la fléxiblité de configuration sont nettement supérieures à celle d'un cluster diskless.

    Si cela était pour transformer un parc de machine WinXX en cluster la nuit par un simple reboot PXE, il est clair que cela à de l'interet de ne pas modifier les disques locaux. Mais aujourd'hui, CLIC ne peut pas encore tout faire :o)...
  • [^] # Re: CLIC 2 est disponible !

    Posté par  . En réponse à la dépêche CLIC 2 est disponible !. Évalué à 3.

    Nous y pensons, nous avons beaucoup travaillé sur le moteur de configuration pour la version de CLIC2 (réécriture complète en PERL & simplifciation des méthodes d'auto-installation). Maintenant que CLIC 2 est sortie, il est temps de regarder vers l'avant : que doit on ajouter à CLIC/MandrakeClustering ?
    Globus en fera partie.
  • # Re: Migrer 8000 postes ?

    Posté par  . En réponse au journal Migrer 8000 postes ?. Évalué à 5.

    En tout cas une solution peut-être de considérer ce parc de machines comme un cluster. J'entends par cluster, un groupe de machines et pas plus.
    Typiquement, c'est le genre de problème auquel on essaye de répondre avec des projets comme CLIC ou même MandrakeClustering.

    Par exemple, on utilise la technologie KA (http://ka-tools.sourceforge.net/(...)) que l'on melange à l'installeur DrakX pour permettre la copie de disques de manière simultanée. Aujourd'hui on sait dupliquer et adapter (reecrire le module.conf, refaire le lilo, adapter le hostname, etc...) une machine sur 200 autres (vierge de tout OS) en moins de 5 minutes !

    Il suffit pour cela d'installer une machine comme on le souhaite puis d'en faire une copie à la volée sur ses voisines. On pourrait utiliser cette techno pour installer des groupes de machines qui represente par exemple une service complet.

    Ensuite, urpmi possède un mode parallèle meconnu qui permet de faire une installation parallèle des packages sur un ensemble de machine !
    apt par exemple ne possède pas ce mode
    Le nombre de machine (en tout cas testé jusqu'à 200) ne modifie pas le temps de copie et permet par exemple de copier 16Mo sur 200 machines en 2,8 sec ! La seule contrainte est de rester sur un groupe de switches relativement proche pour conserver la performance. On pourrait traiter les 8000 machines comme un parc de cluster ou chaque cluster représente un service.

    Bref, je pense qu'une partie de la solution d'installation / maintenance pourrait se trouver dans les distribution orientées cluster qui ont déjà traité une partie de la problématique.