Journal Quelles solutions adopter pour améliorer un parc existant ?

Posté par (page perso) .
Tags :
4
15
déc.
2009
Bonjour à tous,

Pour mon premier journal, j'aimerais titiller les neurones des admins systèmes qui moulent dans le coin :)

Pour donner ma situation, admin sys/réseau/bdd/dév/etc dans une toute petite PME, donc l'admin est parent (très) pauvre.
Je vous explique en gros notre parc actuel: (sachant qu'il a grossi machine par machine)

1 serveur NIS/NFS qui sert /home, qui fait aussi DNS interne et Samba.
1 serveur PostgreSQL/PostGIS
1 serveur Web
1 serveur ssh/ftp
1 machine de sauvegarde de /home
une dizaine de serveurs de calcul et stockage,
6 machines utilisateurs

Tout les serveurs sont en gbps (switchs compris), avec un dual/quad, 8go de ram, CentOS 5.4 x86_64, une 3ware et les disques qui vont avec (de 2 à 14to par machine - pour un total d'environ 70).

Ce que j'envisage de/aimerais faire:
1) Basculer NIS/NFS vers Centos Directory Server (389)
2) Virtualiser la machine de sauvegarde pour:
- faire une réplication 389 pour reprise d'activité à chaud (fonctionnalité fournie de base semble-t-il) + réplication des données /home (nfs toujours ?)
- faire une réplication PostgreSQL pour…reprise d'activité à chaud (Log Shipping ?)
- faire une réplication Apache (?) pour…
3) Enfin, idéalement, j'aimerais pouvoir transformer chaque machine de calcul et son stockage en une grappe/grille. Histoire que les utilisateurs ne voient plus qu'une machine et un espace de stockage. Et que les tâches soumises s'y répartissent comme des grandes. Actuellement, chaque serveur est « dédié » à un satellite, et bien sûr, petits moyens, y'a un peu de tout partout, donc des montages nfs dans tous les sens.

Les contraintes:
1) Ne pas empêcher les utilisateurs de bosser - ou un minimum.
2) L'espace disque dispo est rare, pas plus de 10To. Il n'est pas (ou difficilement) envisageable de devoir déplacer toutes les données. Au mieux, une machine peut être « nue » pour enclencher la création de la grille/grappe. Pas de budget.
3) Il est inenvisageable de devoir réécrire/ modifier lourdement les codes existants pour qu'ils fonctionnent normalement dans la grille/grappe
4) Le déploiement doit être relativement rapide.
5) Cela ne doit pas être trop compliqué, parce que je débute en matière de grilles/grappes. Et que je ne peux pas me consacrer à 100% à l'admin.
6) Idéalement, la notion de proximité des données est la bienvenue. Comme on traite des images satellite, on lit/écrit pas mal de Go. Si on peut éviter au mieux la latence/relative lenteur du réseau c'est un plus.

Je pensais éventuellement à XtreemOS et XtreemFS, hadoop est hors course du fait du travail nécessaire pour l'adaptation map/reduce. Mais j'avoue être un peu perdu dans tout ça, et il n'est pas simple de comparer les solutions existantes.

Pensez-vous que le plan d'évolution soit viable ? sain ? Faut-il utiliser autre chose que 389 qui semble-t-il fonctionne bien et est assez simple à administrer ?
Quels outils me conseilleriez-vous pour faire la grille/grappe ?

Bref, vos conseils, votre expérience m'intéressent.

Merci d'avance !
  • # Hadoop, pourquoi pas

    Posté par (page perso) . Évalué à 1.

    J'avais utilise leur module pour appeller des commandes unix.
    J'avais fait du transcodage de video distribue avec (vlc en ayant coupe la video
    au prealable).

    Sinon, si tu peux ecrire tes taches comme des commandes unix et qu'Hadoop
    ne convient pas, genre:
    ---
    traiter_image.exe image1 -o image1.out
    traiter_image.exe image2 -o image2.out
    traiter_image.exe image3 -o image3.out
    ...
    traiter_image.exe imageN -o imageN.out
    ---
    Tu peux jeter un oeil a mon projet:

    http://savannah.nongnu.org/projects/par/

    Amuse-toi bien!
    Francois.
    • [^] # Re: Hadoop, pourquoi pas

      Posté par (page perso) . Évalué à 2.

      Les codes que nous lançons sont souvent des gros bousins monothread (avec moults paramètres, lancés via des script bash/csh/python/etc), mélange de C et de Fortran, qui bouclent sur x fichiers à traiter. Il y'a bien sûr des cas différents, comme ouvrir plusieurs fichiers pour en générer un qui soit une synthèse du tout, et j'en passe.
      Je n'ai pas beaucoup approfondi hadoop, mais il semblerait que pour en tirer correctement parti, il faudrait modifier les algos (par exemple pour faire que le traitement se fasse sur des parties de l'image). Voire modifier les scripts de lancement pour lancer plusieurs traitements en même temps. J'ai peut-être tort, mais en tout cas, on a déjà bien assez de boulot sur la partie scientifique du code pour devoir s'amuser à le parralléliser d'une manière ou d'une autre.
      Sans compter qu'il faut qu'il reste portable afin que lorsque nous livrons le code il fonctionne sur une machine classique ou presque.
      Il serait effectivement possible de se baser sur ton soft, le problème principal étant la consommation mémoire…il n'est pas rare que nous swappions avec un seul process et 8 go de ram. Mais je vais tout de même m'y pencher un peu plus.
      Le but principal de la grille/grappe serait d'éviter à chacun de chercher (via munin pour l'instant) une machine « libre » pour y éxecuter du code, ou de chercher les machines dispos pour pouvoir lancer 20 ou 30 fois un code de type monte-carlo (qui lui ne prend quasiment rien en mémoire, mais qui bouffe du cpu comme pas permis).
      Sans parler d'arrêter les galères du type: « il me faut 2 To pour pouvoir stocker les résultats que vont générer les calculs, je peux les mettre sur quelle machine ? ». Et ils n'aiment pas la réponse « 1to là, et l'autre là », tu te doutes :)
      Bref, l'organisation d'origine était pas mal…avec 4/5 serveurs. Il est grand temps que nous passions à une solution plus évolutive, plus adaptée à nos besoins…et ce n'est guère évident de la trouver.

      Merci pour tes lumières en tout cas.
  • # Mon avis

    Posté par . Évalué à 3.

    - Oublies XtreemFS/OS, je doute que soit encore stable; et ça n'est pas vraiment fait pour tes besoins (tu veux vraiment deployer des certificats SSL dans tous les sens?!).

    - Tes replis a chaud, tu peux le faire au niveau FS avec DRBD

    - Je serais toi, j essaierais de grouper les disques sur quelques machines et mettre un maximum de chose en NFS.

    - De même pour les services, je doute que ssh/ftp aient besoin d'une machine à eux tout seul.

    - Si tu veux faire une grappe/ grille: Tu peux envisager du SSI ( -> kerrighed ?) ou du MPI, vu le type d'appli que tu utilises , je pense qu'il y a des binding. Regardes du coté de rockscluster.org si tu veux quelquechose de sympa ( people have built great things with rocks ;) )
    • [^] # Re: Mon avis

      Posté par (page perso) . Évalué à 2.

      ah oui, drdb, il faut que je me penche sur cette bête, ça a l'air très bien.
      Les machines sont déjà toutes pleines, il n'est pas possible de regrouper davantage les disques. Et les montages NFS en étoile, pour que chacun puisse accéder à tout depuis n'importe quelle machine, ça devient sale…
      pour le ssh/ftp, c'est une petite machine toute seule dans son coin, par précaution.
      Je vais regarder du côté de Rocks, merci bien !
  • # valeur ajouter ?

    Posté par . Évalué à 10.

    Juste une question bete:

    Quelle valeur a le SI dans cette entreprise ?
    car pour autre aussi dependant de la technique faire quand meme pas mal de traitement et avoir des serveur pour 6 poste final , c'est qu'il y a une raison ?

    L'admin ne devrais pas etre le parent pauvre dans l'entreprise, quelle part, le SI passe apres ?
    Alors si ca tombe en rade , je te dit pas la cata, l'entreprise ferme ?

    Question a conbien estime tu la valeur des données et des capacité de traitement de l'entreprise ? si c'est tout le capital de l'entreprise, faut penser peut etre a changer de facon de penser.

    Enfin, moi c'est pas mon probleme, mais quand meme , c'est triste !
    • [^] # Re: valeur ajouter ?

      Posté par (page perso) . Évalué à 2.

      Je suis également étonné par l'armada actuelle et encore plus par l'éventuelle armada 2.0. Il doit bien y avoir une/des raison(s) :D :

      - les calculs sont gourmands ;
      - les données sont précieuses ;
      - l'admin s'amuse ;
      - le chef de l'admin est Obi Wan Kenobe.

      Alexandre COLLIGNON

      • [^] # Re: valeur ajouter ?

        Posté par (page perso) . Évalué à 1.

        Les calculs sont (très) gourmands…de quelques minutes à plusieurs semaines fonction des cas. Ça se chiffre généralement en heures. On fait de la recherche en physique atmosphérique…entre autres.
        Les données sont relativement précieuses, mais relativement facilement récupérables, en tout cas les données d'origines.
        L'admin veut surtout mettre en place une solution qui lui permettra de faire évoluer le parc sans avoir des suées. Et tant mieux si ça l'amuse en plus :)
        Le chef de l'admin, ben, c'est moi™.
    • [^] # Re: valeur ajouter ?

      Posté par (page perso) . Évalué à 2.

      Oui, c'est triste, mais la part allouée au SI n'est pas une volonté, mais un problème de budget.
      Tu ne connais pas la joie des petites entreprises on dirait :)
      Le SI est important/vital, des efforts ont été/sont faits, mais je ne peux en demander plus…alors il faut faire avec…
  • # MOSIX ou OpenSSI

    Posté par . Évalué à 2.

    Ton besoin me fait penser à MOSIX (http://www.mosix.org/) qui est pseudo libre, ou alors à (http://openssi.org/) qui est libre.

    Dans le temps, j’ai utilisé MOSIX, mais je n’ai jamais utilisé OpenSSI. Le concept est de lancer un processus sur un nœud, celui-ci se balade ensuite de nœud en nœud en fonction de la charge du cluster, le parallélisme doit donc être implémenté à base de fork (le slogan de MOSIX étant « fork and forget »).
    • [^] # Re: MOSIX ou OpenSSI

      Posté par (page perso) . Évalué à 1.

      Hmmm on n'utilise jamais fork ou presque.
      Nous avons plutôt une palanquée d'images, sur lesquelles on éxécute un code ou plusieurs, ce qui résulte en d'autres images.
      Le fork and forget ne me semble pas adapté ou j'ai raté une marche ?
    • [^] # Kerrighed

      Posté par . Évalué à 2.

      Réponse à moi même.
      Ne connaissant que Mosix, j’ai parlé trop vite ; le projet OpenSSI semble mort.
      Néanmoins, on me souffle que le projet Kerrighed (http://www.kerrighed.org/) est une bonne alternative libre à MOSIX.
      • [^] # Re: Kerrighed

        Posté par . Évalué à 1.

        Et une alternative qui répondrais plutôt bien au besoin ;)
        • [^] # Re: Kerrighed

          Posté par (page perso) . Évalué à 2.

          Kerrighed ne semble nullement packagé (.deb cassé, visiblement pas d'autre paquets dispos).
          La maintenance, je pense notamment aux sauts de version doit être assez pénible/chronophage non ?
      • [^] # Re: Kerrighed

        Posté par (page perso) . Évalué à 1.

        Mais xtreemos n'est-il pas basé sur kerrighed ? Et d'après geb, ça ne serait pas très stable ?
        Qui a raison ? :)
    • [^] # Re: MOSIX ou OpenSSI

      Posté par (page perso) . Évalué à 3.

      Il y avait le projet openMosix (dérivé de mosix) aussi, mais celui-ci est arrêté depuis le mars 2008 (ce qui est bien dommage).
      Il fonctionne sur les noyaux 2.4 et n'a jamais été amené sur 2.6, on l'utilise encore ici pour du calcul génétique. Mais c'est vrai que le "fork and forget" est assez fantastique.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: MOSIX ou OpenSSI

        Posté par (page perso) . Évalué à 1.

        Je connaissais OpenMosix. L'idee est pas male du tout.
        Ca serait sympa de faire revivre ce projet.
        Tu as une idee de la taille du boulot que ca demande?

        Quand tu dis "on l'utilise encore ici", c'est ou ici? :)
        • [^] # Re: MOSIX ou OpenSSI

          Posté par (page perso) . Évalué à 2.

          Tu as une idee de la taille du boulot que ca demande?
          Je supposes des connaissances assez pointus sur le noyau Linux (scheduler principalement). Donc repartir de la beta pour le noyau 2.6.15 et arriver un truc stable 2.6.32, je sais pas combien de temps ça prend, mais je ne penses pas être compétent pour travailler sur le sujet.

          Quand tu dis "on l'utilise encore ici", c'est ou ici?

          Où je travaille : http://www.irovision.ch/

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # glusterFS

    Posté par . Évalué à 3.

    Pour ton problème d'espace disque à partager en utilisant au max les ressources de ton parc, tu peux regarder du côté de glusterFS.
    Pour faire court, c'est un système de fichiers en cluster : http://gluster.org

    Pour un exemple de mise en place, et vu que tu as le mauvais goût d'aimer les redhateries, je te propose de lire http://www.howtoforge.com/distributed-storage-across-four-st(...) histoire de te rééduquer un peu :-)

    En espérant que cela t'aide un peu, et en te souhaitant bon courage.
    • [^] # Re: glusterFS

      Posté par (page perso) . Évalué à 2.

      Merci du tuyau.

      Mais je vais quand même garder autant que possible mes redhateries qui-vont-bien, qui sont stables, et dont le support est long :)
      Avoir un parc non homogène, quelle horreur, j'ai déjà bien assez à faire pour valider les algos, alors si en plus il fallait tester avec pleins de versions (compilo etc), au secours !

      Mais je vais tout de même jeter un œil à gluster, merci :)
      • [^] # Re: glusterFS

        Posté par . Évalué à 1.

        GlusterFS existe bien sur sur RedHat, ce n'était qu'un clin d'oeil.
  • # OAR batch scheduler

    Posté par (page perso) . Évalué à 4.

    Pour les tâches de calcul, tu peux utiliser OAR:

    En gros tu lances ta tâche avec la commande "oarsub" avec les arguments qui vont bien (nombre de noeuds et processeurs voulus, éventuellement un seul proc si ton appli est monothread non distribué) et OAR va la lancer comme un grand sur une machine qui a encore des ressources disponibles, et sinon va la placer dans une file d'attente. Si ton appli demande plusieurs noeuds, elle ne sera lancée que lorsque le nombre de noeuds requis sera disponible. Ensuite la tâche est lancée dans un environnement SSH dans lequel un fichier hosts dynamique est créé pour faire du MPI (si nécessaire) sur les machines qui ont été effectivement réservées pour ce batch.

    Tu peux aussi réserver un ou plusieurs noeuds en direct pour jouer avec directement en ssh (commande "oarsh" qui te connecte directement en ssh sur l'un des noeuds réservés avec le fichier hosts qui va bien). Les machines sont libérées quand tu quittes le shell ou au bout d'un temps d'utilisation prédéfini lors de l'appel à oarsh.

    C'est le scheduler qui est utilisé sur la grille de calcul française Grid5000 : http://www.grid5000.fr/

    http://oar.imag.fr/
    • [^] # Re: OAR batch scheduler

      Posté par (page perso) . Évalué à 1.

      OAR a l'air tout à fait sympathique, je vais m'y pencher plus en profondeur.
      Cela ne semble pas régler le problème des différents volumes de données, mais je n'ai pas encore lu grand-chose.

      Merci !
  • # Il me semble

    Posté par (page perso) . Évalué à 1.

    Il me semble que dans ton post tu mélange backup et réplication.
    La pérennité des données et la continuité du service sont deux enjeux différents me semble-t-il ...

    Par exemple pour postgres, la réplication c'est bien mais si un user te vire des données un backup peut-être utile :)
    • [^] # Re: Il me semble

      Posté par (page perso) . Évalué à 1.

      Actuellement, la machine de backup des homes ne fait que ça. Les réplications sont des fonctionnalités que je veux lui ajouter, donc pas de mélange des genres :)

Suivre le flux des commentaires

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