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 !
Journal Quelles solutions adopter pour améliorer un parc existant ?
15
déc.
2009
# Hadoop, pourquoi pas
Posté par zaurus (site web personnel) . Évalué à 1.
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 laurent wandrebeck (site web personnel) . Évalué à 2.
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 geb . Évalué à 3.
- 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 laurent wandrebeck (site web personnel) . Évalué à 2.
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 Sébastien TeRMiToR . Évalué à 10.
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 Alexandre COLLIGNON (site web personnel) . Évalué à 2.
- 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 laurent wandrebeck (site web personnel) . Évalué à 1.
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 Mr Kapouik (site web personnel) . Évalué à 4.
C'est facile de dire c'est moi mais au final on ne connait pas ta deuxième identité cachée.
[^] # Re: valeur ajouter ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
[^] # Re: valeur ajouter ?
Posté par hervé Couvelard . Évalué à 4.
[^] # Re: valeur ajouter ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
[^] # Re: valeur ajouter ?
Posté par zebra3 . Évalué à 10.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: valeur ajouter ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
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 Benoit . Évalué à 2.
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 laurent wandrebeck (site web personnel) . Évalué à 1.
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 Benoit . Évalué à 2.
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 Alexandre . Évalué à 1.
[^] # Re: Kerrighed
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
La maintenance, je pense notamment aux sauts de version doit être assez pénible/chronophage non ?
[^] # Re: Kerrighed
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Qui a raison ? :)
[^] # Re: MOSIX ou OpenSSI
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
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 zaurus (site web personnel) . Évalué à 1.
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 Etienne Bagnoud (site web personnel) . Évalué à 2.
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 Dreammm . Évalué à 3.
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 laurent wandrebeck (site web personnel) . Évalué à 2.
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 Dreammm . Évalué à 1.
# OAR batch scheduler
Posté par zerkman (site web personnel) . Évalué à 4.
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 laurent wandrebeck (site web personnel) . Évalué à 1.
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 Joris Dedieu (site web personnel) . Évalué à 1.
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 laurent wandrebeck (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.