Bonjour à tous,
je souhaite avoir quelques retours sur l'utilisation des technos HPC. Je me permets de vous lister mon besoin, peut-être que l'HPC n'est pas la bonne solution.
Aujourd'hui, nous avons de nombreux calculs réalisés sur déférentes machines physiques. Un calcul spécifique est associé à une machine. Nous rencontrons des problèmes de mutualisation de ressources concernant l'espace et la puissance de calcul.
Dans un premier temps je suis dirigé vers la virtualisation. Sachant que mes machines physiques possèdent 64 procs et que les VM 32, les ressources sont très vite utilisées, et la virtualisation me provoque des ralentissements des calculs. J'aurai besoin de "fusionner" les ressources physiques. Idéalement de faire tourner un traitement sur plusieurs machines. Il me semble que mon besoin serait plus du "High Performance Computing". Je pense que vous êtes beaucoup à avoir ce besoin.
J'ai trouvé MPI qui pourrait correspondre à mon besoin : http://www.open-mpi.org/
Qu'en pensez-vous ? Avez-vous d'autres solutions (sans externalisation) ?
OVH avait racheté une boite en 2012 qui faisait ca, Oxalya
Alex.
Le mer 21 mai 14 à 16:42:31 +0200, Alexandre infos@opendoc.net écrivait :
Bonjour à tous,
Salut,
J'ai trouvé MPI qui pourrait correspondre à mon besoin : http://www.open-mpi.org/
Qu'en pensez-vous ? Avez-vous d'autres solutions (sans externalisation) ?
MPI est un protocole, et il y a plusieurs implémentations. J'ai l'impression que MPICH http://www.mpich.org/ est plus répandu.
Ça correspond tout à fait au besoin, mais attention : les programmes applicatifs utilisés doivent être adaptés et compilés avec les bibliothàques MPI.
Ceci dit, je ne sais pas de quels calculs il s'agit, mais les principaux logiciels de calcul libres ont déjà des options de compilation pour MPI.
Il y avait aussi SGE (Sun Grid Engine) qui était libre, mais je ne sais pas trop ce que ça devient depuis le rachat d'Oracle...
OVH avait racheté une boite en 2012 qui faisait ca, Oxalya
Aucune idée...
Bonjour,
SGE (_Sun_ Grid Engine) est devenu OGE (_Oracle_ Grid Engine) quand Oracle a racheté Sun et changé la licence pour passer d'une licence libre Sun SISSL à une licence propriétaire. Puis Oracle a délaissé OGE et l'a revendu à Univa en 2013 (http://www.univa.com/products/grid-engine). Face à ces changements, la communauté a forké SGE en partant de la dernière version libre, 6.2u5. Deux forks ont vu le jour : - Son of Grid Engine, que je ne connais pas du tout : https://arc.liv.ac.uk/trac/SGE - Open Grid Scheduler, qui est totalement compatible avec [OS]GE 6.2u5 au point de pouvoir mélanger dans une même grille des noeuds installés avec l'un ou l'autre : http://sourceforge.net/projects/gridscheduler/ Selon les besoins et contraintes, il faut choisir entre une version payante et supportée par une entreprise (Univa), ou une version libre avec tout ce que ça sous-entend (support par la communauté, pérennité, accès aux sources, ...).
Il faut bien comprendre que ni MPI ni [OS]GE/OGS ne va résoudre tes problèmes seul : le code doit être adapté pour utiliser MPI, et la grille de calcul ne sait rien faire d'autre que distribuer des tâches sur des noeuds de calcul (mais le fait bien !). Je n'ai jamais utilisé MPI, je ne pourrai pas en dire beaucoup plus. Je connais beaucoup mieux [OS]GE/OGS et ses contraintes. ll faut découper les données en chunks cohérents qu'une tâche va pouvoir traiter, le traitement devient alors : 1. génération des chunks : cette étape peut être inutile si le découpage consiste à prendre les données de l'octet 0 à 999, puis 1000 à 1999, ... Une tâche à partir de son numéro d'ordre est alors capable toute seule d'accéder à ses données, mais ça peut être plus compliqué si les données résultent de l'agrégation de plusieurs sources. 2. donner à la grille les n tâches à exécuter, le moteur de grille va alors les répartir sur les différents noeuds de calcul. Chaque tâche génère une fraction du résultat final. 3. agréger les résultats partiels pour aboutir au résultat final. Là-encore cette étape peut ne pas exister si les résultats partiels sont auto-suffisants. La grille impose de plus la mise en place d'une infrastructure matérielle et de services : noeuds maîtres et de calcul, partage NFS entre les noeuds (obligatoire pour [OS]GE/OGS/Son of GE), ... et qu'il faudra exploiter.
Par expérience SGE/OGE/OGS fonctionnent parfaitement, c'est robuste, simple à mettre en place et à exploiter.
Dernière chose : une autre alternative est Hadoop, plus complexe à mettre en oeuvre et qui demande du développement adapté, mais très efficace. A regarder attentivement.
Les liens qui vont bien (merci Wikipédia !) : SGE : http://en.wikipedia.org/wiki/Oracle_Grid_Engine Hadoop : http://en.wikipedia.org/wiki/Hadoop
Patrice
"FRsAG" frsag-bounces@frsag.org a écrit sur 21/05/2014 19:58:38 :
Thierry Thomas thierry@FreeBSD.org Envoyé par : "FRsAG" frsag-bounces@frsag.org
21/05/2014 19:58
A
frsag@frsag.org
cc
Objet
Re: [FRsAG] [TECH] HPC Open Source.
Le mer 21 mai 14 à 16:42:31 +0200, Alexandre infos@opendoc.net écrivait :
Bonjour à tous,
Salut,
J'ai trouvé MPI qui pourrait correspondre à mon besoin : http://www.open-mpi.org/
Qu'en pensez-vous ? Avez-vous d'autres solutions (sans
externalisation) ?
MPI est un protocole, et il y a plusieurs implémentations. J'ai l'impression que MPICH http://www.mpich.org/ est plus répandu.
Ça correspond tout à fait au besoin, mais attention : les programmes applicatifs utilisés doivent être adaptés et compilés avec les bibliothàques MPI.
Ceci dit, je ne sais pas de quels calculs il s'agit, mais les principaux logiciels de calcul libres ont déjà des options de compilation pour MPI.
Il y avait aussi SGE (Sun Grid Engine) qui était libre, mais je ne sais pas trop ce que ça devient depuis le rachat d'Oracle...
OVH avait racheté une boite en 2012 qui faisait ca, Oxalya
Aucune idée...
Th. Thomas. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Accédez aux meilleurs tarifs Air France, gérez vos réservations et enregistrez-vous en ligne sur http://www.airfrance.com Find best Air France fares, manage your reservations and check in online at http://www.airfrance.com Les données et renseignements contenus dans ce message peuvent être de nature confidentielle et soumis au secret professionnel et sont destinés à l'usage exclusif du destinataire dont les coordonnées figurent ci-dessus. Si vous recevez cette communication par erreur, nous vous demandons de ne pas la copier, l'utiliser ou la divulguer. Nous vous prions de notifier cette erreur à l'expéditeur et d'effacer immédiatement cette communication de votre système. Société Air France - Société anonyme au capital de 126 748 775 euros - RCS Bobigny (France) 420 495 178 - 45, rue de Paris, Tremblay-en-France, 95747 Roissy Charles de Gaulle CEDEX The data and information contained in this message may be confidential and subject to professional secrecy and are intended for the exclusive use of the recipient at the address shown above. If you receive this message by mistake, we ask you not to copy, use or disclose it. Please notify this error to the sender immediately and delete this message from your system. Société Air France - Limited company with capital of 126,748,775 euros - Bobigny register of companies (France) 420 495 178 - 45, rue de Paris, Tremblay-en-France, 95747 Roissy Charles de Gaulle CEDEX Pensez à l'environnement avant d'imprimer ce message. Think of the environment before printing this mail.
Salut,
Si vous faites du calcul, peut etre pouvez vous etre aussi dans le creneau de la recherche ? Alors le groupe calcul est la pour partager http://calcul.math.cnrs.fr/spip.php?rubrique3
A defaut, l'evidence est de ne jamais mettre de surcouche(VM), laisser les CPU plein pot (vilain les speedstep, turbo machin et autre IDLE mode, alors un hyperviseur !!!).
Avant tout faut savoir si les ressources par noeud sont "adaptables" au probleme. Si la // du calcul est intelligemment faite, mettre de la communication inter-noeud quand on est capable de faire le bouzin localement a un cout economiquement supportable n'a pas de sens. Les latences sur un reseau sont toujours invraisemblablemenent plus fortes que sur un bus CPU/RAM, donc penalisantes pour la mutualisation du calcul sur une grappe de machine. Le local sur le materiel : <<tout le monde>> sait faire communiquer les process.
Apres, pour certains calculs dans certains contexts avec des ing. pour maintenir le calculateur, former les developpeurs et verifier le code, pourquoi pas mais alors en general, c'est que l'on ne calcul plus alors sur le prix du materiel.
Or si vous calculez sur le materiel et regardez des VM, j'imagine qu'il n'y a pas toutes la ressource pour payer l'humain. Si vous voulez essayer la com inter-noeud pendant le calcul ou apprenez a coder/utiliser avec une infra de type amazone qui sait faire du HPC.
Si vous en etiez a seulement reflechir a l'ordemencement des jobs, et aviez deja achete des noeuds avec 64 coeurs, oubliez ce que je viens d'ecrire SVP.
Cordialement, Sylvain MAURIN
On Wed, 2014-05-21 at 16:42 +0200, Alexandre wrote:
Bonjour à tous,
je souhaite avoir quelques retours sur l'utilisation des technos HPC. Je me permets de vous lister mon besoin, peut-être que l'HPC n'est pas la bonne solution.
Aujourd'hui, nous avons de nombreux calculs réalisés sur déférentes machines physiques. Un calcul spécifique est associé à une machine. Nous rencontrons des problèmes de mutualisation de ressources concernant l'espace et la puissance de calcul.
Dans un premier temps je suis dirigé vers la virtualisation. Sachant que mes machines physiques possèdent 64 procs et que les VM 32, les ressources sont très vite utilisées, et la virtualisation me provoque des ralentissements des calculs. J'aurai besoin de "fusionner" les ressources physiques. Idéalement de faire tourner un traitement sur plusieurs machines. Il me semble que mon besoin serait plus du "High Performance Computing". Je pense que vous êtes beaucoup à avoir ce besoin.
J'ai trouvé MPI qui pourrait correspondre à mon besoin : http://www.open-mpi.org/
Qu'en pensez-vous ? Avez-vous d'autres solutions (sans externalisation) ?
OVH avait racheté une boite en 2012 qui faisait ca, Oxalya
Alex. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Alexandre -
Patrice Guerlais -
Sylvain MAURIN -
Thierry Thomas