OSCAR sort en version 4.1

Posté par  . Édité par Benoît Sibaud. Modéré par Amaury.
Étiquettes :
0
28
avr.
2005
Linux
OSCAR (Open Source Cluster Application Resources), ensemble de composants logiciels nécessaires à l'installation, l'administration et l'utilisation de cluster, vient de passer en version 4.1.

L'une des principales caractéristiques de OSCAR est d'offrir un mécanisme de paquet (paquets OSCAR) qui étend la notion de gestion de paquets traditionnelle (par exemple la gestion de paquets RPM ou DEB) au niveau de la grappe, afin de faciliter l'installation et la maintenance des clusters.

OSCAR a pour objectif d'être multi-distributions et multi-architectures. Les distributions actuellement supportées sont RedHat 9, Fedora Core 2, Red Hat Entreprise Linux 3 et Mandrake 10. Un portage sur Debian/Sarge est en cours. Au niveau des architectures, les processeurs IA32 et IA64 sont actuellement supportés. A noter également que la version actuelle est fondée sur SIS (suite logicielle regroupant Systeminstaller, Systemconfigurator et Systemimager), une solution similaire à Clic, mécanisme d'installation de noeuds de cluster intégrés dans la distribution pour cluster de Mandriva. L'évolution d'OSCAR tend vers la modularité avec notamment à terme la possibilité d'utiliser différent systèmes d'installation (par exemple SIS, Clic, KickStart ou FAI).

Pour finir, OSCAR permet entre autre d'installer automatiquement MPI (mpich ou lam), Torque, ganglia, etc.

NdM: lien neutralisé en raison de la disparition des domaines

CLIC/Mandriva (7 clics) http://www.mandriva.com/clustering

Les principales nouveautés sont :
* le support de Mandrake 10.0 avec processeurs IA32.
* un meilleur support de Red Hat Enterprise Linux 3.
* un nouveau mécanisme pour le test de l'installation.
* la gestion des dépendances entre paquets RPM est maintenant gérée de manière transparente et automatique à la fois sur le serveur et sur les noeuds de calcul (grâce à l'outils DepMan/Packman).
* Bien sûr la correction de nombreux bugs.

Cette version est accompagnée d'un nouveau site web où il est possible d'enregistrer son cluster OSCAR.

OSCAR sert également d'élément de base à plusieurs autres projets :
* HA-OSCAR, version d'OSCAR offrant des mécanismes de haute disponibilité.
* OSCARonDebian, portage d'OSCAR sur Debian.
* SSI-OSCAR, version d'OSCAR permettant d'installer un système à image unique pour cluster, la version courante installant le système Kerrighed.
* SSS-OSCAR, version d'OSCAR pour les clusters de grande taille.

Aller plus loin

  • # Plus d'infos

    Posté par  . Évalué à 3.

    MPI : http://www-unix.mcs.anl.gov/mpi/(...)

    "MPI is a library specification for message-passing, proposed as a standard by a broadly based committee of vendors, implementors, and users."

    Torque : http://www.clusterresources.com/products/torque/(...)

    "TORQUE (Tera-scale Open-source Resource and QUEue manager) is a resource manager providing control over batch jobs and distributed compute nodes."

    ganglia : http://ganglia.sourceforge.net/(...)

    "Ganglia is a scalable distributed monitoring system for high-performance computing systems such as clusters and Grids."
  • # J'y connais rien mais je me soigne...

    Posté par  . Évalué à -4.

    Mandriva (prenons l'habitude) avait pas déjà un truc qui s'appelait "clic" comme ça pr faire la même chose?
    Quelles sont les plus et les moins d'oscar par rapport à clic? (en dehors du nombre de distribs supportées, évidemment)
    • [^] # Re: J'y connais rien mais je me soigne...

      Posté par  . Évalué à -5.

      oups, j'ai encore parcouru la news trop vite...
      Moinssez-moi, moinssez-moi, moinssez-moiiiiii
    • [^] # Re: J'y connais rien mais je me soigne...

      Posté par  . Évalué à 3.

      J'avais essaye la distrib Clic il y a 2 ans sur des machines d'une salle info et ca marchait plutot bien, le systeme de replication etait pratique, par contre aujourd'hui il faut acheter MandrivaClustering et finalement il existe plein d'utilitaires a installer sur une distrib classique pour une mise en cluster. Pour n'en citer que quelques uns : partimage, udpcast, oscar, c3tools, et hop il ne reste qu'a creer un serveur (avec dhcp, bootp, nis, nfs), un golden node et on lance la replication ;-) par boot pxe des machines sur le serveur.

      Au passage si vous desirez programmer des applis distribuees je vous recommande FlowVR (flowvr.sf.net rubrique Gallery) et c'est libre et francais messieurs (labo ID Grenoble + LIFO Orleans)...
    • [^] # Re: J'y connais rien mais je me soigne...

      Posté par  . Évalué à 1.

      J'ai testé les deux distributions dans le cadre de la mise en place d'un cluster d'une douzaine de machines il y a un an maintenant (je sais pas si une nouvelle mandriva clic est sortie depuis). Mais j'ai trouve l'installation d'oscar meilleure que celle de la mandrake à l'epoque.

      Il fallait obligatoirement des cartes PXE pour profiter pleinement du mécanisme d'installation automatique de la mandrake. Donc j'ai du brancher un clavier et un écran sur chaque noeud, pas terrible, vous en conviendrez... Alors qu'une fois passée la création de l'image système avec Oscar (probleme de dépendances entre les rpms a régler à la main) l'installation et la reinstallation des noeuds se fait grâce à une disquette (ou cd) de boot et il va tout seul comme un grand chercher ses parametres réseaux (dhcp) et l'image du système sur le noeud central. Et il est possible d'avoir plusieurs images si on a plusieurs noeuds avec des configs différentes.

      La mandrake Clic n'a pas évoluée depuis octobre 2003. Le lien pointe vers la Mandriva Linux Clustering qui, sauf erreur de ma part, n'est pas librement telechargeable. La Clic ne m'a pas donné l'impression d'être terminée (bug dans la reconstruction des fichiers de conf, interface graphique absente...) mais est la base de la Linux Clustering.
      • [^] # Re: J'y connais rien mais je me soigne...

        Posté par  . Évalué à 1.

        Je suis d'accord avec toi, mais franchement, quitte a avoir un cluster, autant avoir des cartes pxe (meme mon pc portable a une carte pxe) et installer un SSI.

        Oscar c'est bien mais ça fait un peu bricolage (moi-même qui administre un cluster d'une quinzaine de machines qui est le même que celui dont tu parles) que ce soit au niveau de la config réseau ou de la màj des softs.

        Et puis oscar ne supporte toujours pas l'x86_64, se base sur du rpm (on aime ou on aime pas, perso j'aime pas), oscarondebian a pas l'air d'avancer des masses, la doc oscar est légère..

        Franchement, vivement que kerrighed soit plus mâture.
        • [^] # Re: J'y connais rien mais je me soigne...

          Posté par  . Évalué à 1.

          Quelques précisions :
          * OSCARonDebian bouge depuis quelque temps, tout a été repris de zéro (http://ssi-oscar.irisa.fr/oscarondebian).(...) La version de développement permet maintenant d'installer une grappe (attention c'est malgré tout une version en développement, il y a toujours des problèmes!).
          * Pour un SSI, il existe SSI-OSCAR : OSCAR pour installer les systèmes de base de chaque machine et installer et configurer Kerrighed. Une nouvelle version bien meilleure est en préparation.
          * Le x86_64 sera certainement supporté avec l'intégration de nouveau SystemImage.

          Voilà voilà mes 2 cents :-)
        • [^] # Re: J'y connais rien mais je me soigne...

          Posté par  . Évalué à 1.

          En fait le SSI ne m'interesse pas vraiment, je bosse plutot sur des applis heterogenes temps-reelles et la migration de thread n'offre pas de modele de performance adequat, donc je programme avec FlowVR et MPI encapsule dedans, c'est propre et portable sur d'autres machines sans reecrire le code grace a FlowVR (je fais un peu de pub car je prends part au projet...). En fait la migration de thread n'est pas la solution retenue pour le calcul haute performance d'apres mon experience...
          • [^] # Re: J'y connais rien mais je me soigne...

            Posté par  . Évalué à 1.

            Je pense que la migration de thread n'est qu'un mécanisme et que c'est plutôt la politique de migration qui est importante. Mais effectivement je suis d'accord avec toi, de nombreux travaux de recherche ont montré que c'est le placement des threads qui est important pour le HPC (il existe également quelque cas particuliers d'usage de cluster, certains paterns d'usage des ressources pour lesquels la migration de threads est intéressante mais cela reste des cas particuliers).
            La migration de thread dans un SSI est tout de même intéressant pour l'ajout/retrait de noeud (migration d'applications sans arrêt de celle-ci, solution plus performante qu'un checkpoint puis un restart sur un autre noeud du cluster).
        • [^] # Re: J'y connais rien mais je me soigne...

          Posté par  . Évalué à 2.

          Je suis bien d'accord pour les cartes PXE, mais on maitrise pas toujours le materiel qu'on a à disposition. :)

          Moi aussi je prefere les .deb, mais l'utilisation des rpms n'est pas non plus trop rebutantes (a part la gestion des dependances, ce qui a l'air de s'etre largement améliorée). Et dans le cas d'oscar, je suis pas convaincu que l'utilisation des .deb apporte beaucoup d'améliorations.

          Concernant la doc, je pense que tu n'as pas regardé la doc de la clic qui est inexistante... Pour la gestion des x86_64, c'est pas encore supporté officiellement, mais avec un peu de recherche et un peu de modifs, on y arrive ;-)
          • [^] # Re: J'y connais rien mais je me soigne...

            Posté par  . Évalué à 1.

            L'utilisation des .deb dans OSCAR n'est pas fait pour apporter une réelle amélioration à OSCAR mais plus pour supporter une autre distribution et ainsi répondre aux besoins exprimés par les utilisateurs.

            De plus, comme je l'ai dis, OSCAR a pour but d'être multi-distributions. Avec le support de Debian, OSCAR n'est plus seulement multi-distributions utilisant le format de paquet RPM. :-)
      • [^] # Re: J'y connais rien mais je me soigne...

        Posté par  . Évalué à 1.

        Juste une petite remarque : le problème de dépendance ne devrait plus avoir lieu avec les versions récentes d'OSCAR, un composant (DepMan) a été créé pour cela.
  • # HA oscar ou openssi

    Posté par  . Évalué à 1.

    Je veux mettre en place une solution HA :
    2 Serveurs: 1 principal / 1 secours
    Si le principal tombe en panne le serveur de secours prend le relais et ceci sans perte de données.L'utilisateur ne peut seulement s'apercevoir que d'un léger ralentissement.
    Je lorgne actuellement sur OpenSSI qui étant une solution SSI me pemet de switcher automatiquement mes services sur le noeud cluster en cas de panne.Il me permet via DRBD de répliquer en temps réél mes données sur le noeud de secours .
    Si le serveur principal est out , le noeud de secours prend automatiquement le relais (sans intervention humaine)
    Je pense qu'HA-Oscar est basé sur le même principe (je parle ici uniquement de la partie HA) .La question que je me pose :
    Quelle réelle différence (le + ou le -) y a t il entre les deux solutions dans mon cas ?
    • [^] # Re: HA oscar ou openssi

      Posté par  . Évalué à 3.

      Je pense qu'avec HA-OSCAR tu auras par exemple le choix de configurer ton service de HA en active-active ou active-passive (je crois me souvenir que ce genre de configuration est maintenant possible avec la nouvelle version de HA-OSCAR, mais j'ai essayé sans succés d'en trouver la confirmation) alors qu'avec OpenSSI tu n'auras pas trop le choix.
      Bref, je pense que tu auras plus de souplesse/facilité de configuration avec HA-OSCAR qui est spécialisé pour le type de problème que tu as.

      Autre point : actuellement dans OpenSSI, si le serveur du cluster (headnode) tombe, le système n'est pas dans un état cohérent.

      J'espère que cela apportera un élément de réponse. :-)
      • [^] # Re: HA oscar ou openssi

        Posté par  (site web personnel) . Évalué à 2.

        Hello,

        Heartbeat (de Linux-HA) fait également du actif-passif ou du actif-actif. Tiens, je me demande si HA-Oscar ne l'utilise pas directement.

        Néanmoins, un problème se pose avec la réplication des données par DRBD: seul un serveur sur les deux peut monter les partitions sur les volumes DRBD. Dans ces conditions, un SGBD en HA ne peut être posé que sur un serveur. Par contre, on peut très bien envisager de panacher les services HA , tout dépend de la réplication des données.

        Ah les clusters (High Avaibility ou High Perfs) ! Une fois qu'on y a gouté, on ne peut plus s'en passer...
      • [^] # Re: HA oscar ou openssi

        Posté par  . Évalué à 1.

        Cohérent il sera : tu peux te permettre de cloner ton serveur maitre:
        1) tu boot le clone via pxe : il devient un simple noeud du cluster
        2) si tu as configurés les replis de données sur une (ou plusieurs) partition(s) non montées de ce noeud [partitions utlisées par le système cloné] lors de l'arret du serveur maitre, le noeud prend la relève :
        Pas de perte de datas , pas d'arret de services , un nouveau serveur maitre parfaitement disponible.
        Je ne vois pas d'incohérence un niveau du cluster ...
      • [^] # Re: HA oscar ou openssi

        Posté par  (site web personnel) . Évalué à 2.

        > Autre point : actuellement dans OpenSSI, si le serveur du cluster (headnode) tombe, le système n'est pas dans un état cohérent.

        Ayant une problématique similaire à la sienne, je profite de ton passage par ici pour te poser la question à propos d'OpenMosix. Esc-ce que la perte d'un noeud du cluster conduit aussi à un état incohérent? Si oui, quelle solution existe-t-il pour un SGBDR (au hasard PostgreSQL) en cluster?
        Merci d'avance pour ta réponse éclairée. ;)
        • [^] # Re: HA oscar ou openssi

          Posté par  . Évalué à 3.

          Pour openMosix, le cluster est définitivement dans un état incohérent si un noeud tombe (même un noeud de calcul). Ils ont un mécanisme de dépendance assez restrictif entre les noeuds qui ne permet pas le retrait d'un noeud.
          Il ne faut pas oublier que openMosix vise le HPC pur (ie la performance) et absolument pas la haute disponibilité (c'est pourquoi pas mal de gens ne concidèrent pas openMosix comme un vrai SSI).

          Pour le SGBDR, je ne pense pas qu'un SSI actuel offre une solution adéquate. Par contre, OpenSSI et Kerrighed travaillent clairement sur la problèmatique des systèmes de fichiers pour cluster et on peut donc espérer des solutions (au moins partielles) dans les prochaines versions.

          A noter qu'une nouvelle version de Kerrighed et de OpenSSI sont disponibles depuis quelques heures/jours (Kerrighed 1.0.2 et OpenSSI 1.9).
          Les liens :
          http://www.kerrighed.org/(...)
          http://www.openssi.org/(...)
          • [^] # Re: HA oscar ou openssi

            Posté par  (site web personnel) . Évalué à 3.

            > Pour le SGBDR, je ne pense pas qu'un SSI actuel offre une solution adéquate.

            C'est bien dommage parce que les SGBD en clusters coûtent très très cher, et le matériel haut de gamme aussi (octo proc par ex.) et que dans ce genre de config la HA implique de doubler le nombre de machines, ce qui en fait des solutions prohibitives dans bien des cas.

            > A noter qu'une nouvelle version de Kerrighed et de OpenSSI sont disponibles depuis quelques heures/jours

            Merci pour cette info, je vais aller y jeter un oeil.

            Bonne journée/semaine.
    • [^] # Re: HA oscar ou openssi

      Posté par  . Évalué à 3.

      J'ai utilise Heartbeat http://www.linux-ha.org(...) avec DRDB http://www.drbd.org(...) pour la replication de donnes et Monit http://www.tildeslash.com/monit/(...) pour controler les daemons, ca marche plutot bien et une fois qu'on a compris le principe c'est pas trop long a mettre en place.

      Si le serveur principal part en vrille le serveur de secours prens la releve quelque secondes apres. J'ai configure linux en lecture seule, seule la partition replique est en ecriture ainsi qu'un ramdisk pour /var donc comme ca je minimise les risque de corruption de l'OS en cas de reboot ou crash.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.