DIET_BLAST
•Descargar como PPT, PDF•
1 recomendación•751 vistas
Journée Calcul Intensif pour la biologie Lille 14/06/11. http://www.lifl.fr/~touzet/calculintensif11.html
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a DIET_BLAST
Similar a DIET_BLAST (20)
Más de Frederic Desprez
Más de Frederic Desprez (14)
DIET_BLAST
- 1. DIET_BLAST: Architecture logicielle et petits problèmes de recherche Frédéric Desprez LIP ENS Lyon/INRIA Grenoble Rhône-Alpes EPI GRAAL/Avalon 14/06/11
- 15. Using MCT A. Vernois
- 16. Using SRA A. Vernois
- 26. Putting everything together G. Le Mahec
- 34. Deployment example with Universities Sed = Server Daemon, installed on any server running Loadleveler. Note that we can define rescue SeD. MA = master agent, coordinates Jobs. We can define rescue or multiple Master Agent. WN = worker node http://www.decrypthon.fr/ ORSAY SeD LoadLeveler BORDEAUX Project Users SeD LoadLeveler SeD LoadLeveler SeD LoadLeveler Web Interface Orsay Decrypthon2 CRIHAN DB2 Orsay Decrypthon1 Master Agent DIET Décrypthon LILLE JUSSIEU BD AFM Cliniques Lyon IBM WII Data manager Interface
- 36. Data management Credits: H. N’Guyen, O. Poch, IGBMC Décrypthon Grid - Grid Resources Dedicated to Neuromuscular Disorders, Bard, N., Bolze, R., Caron, E., Desprez, F., Heymann, M., Friedrich, A., Moulinier, L., Nguyen, N.-H., Poch, O. and Toursel, T., 8th HealthGrid conference, Paris, France, June, 2010.
- 43. Des questions ?
Notas del editor
- En comparant deux séquences dont l’une à un r ôle connu, on espère, si elles se ressemblent, trouver le rôle de la nouvelle séquence dans une protèine ou dans un gène. Les bases de données utilisées sont simplement des fichiers plats qui contiennent des séquences accompagnées de leurs descriptions.
- Si la base n’est pas « installée » dans DAGD, l’utilisateur la transmet en paramètre, sinon on se sert du système d’identifiants partagés de DAGDA (alias sur les données qui évite de se servir d’un identifiant uuid pas pratique à partager/échanger) Rem : La division du fichier d’entrée et la fusion des résultats ont un co ût négligeable en regard du coût d’exécution des BLAST.
- Lorsqu’un job est envoyé sur un nœud qui n’a pas la donnée, il la télécharge, la met dans un cache sur lequel on utilise LRU pour sélectionner la donnée à effacer quand on a besoin de place. En attendant que la donnée soit effacée, elle est disponible pour les autres nœuds (c’est donc un replicat).
- 3 fois le meilleur résultat pour l’ordo où la donnée est présente, peu importe la manière dont elle a été repliquée (random ou least loaded)… On peut noter que lorsqu’on ne réplique pas, le meilleur temps de réponse est obtenu quand on exécute le job là où il a été soumis…
- 5 bases de tailles de 150 Mo à 5 Go. 5 algos : blastn, blastp, blastx, tblastn et tblastx (adn vs adn, protein vs protein, adn vs protein etc…) Le plus long est tblastx (environ 20 fois plus long que blastn) Le pic du début dans le graphique SRA : Les ensembles de jobs soumis sont petits, les replications finissent après la soumission du dernier job => Le temps moyen des jobs est important puisqu’ils sont tous ordonnancés sur les m êmes machines. Le temps d’attente décroit au fur et à mesure que les réplications se finissent, les derniers jobs soumis profitant pleinement des réplications. MCT envoie chaque job sur le nœud qui sera le plus rapide pour l’exécuter à l’instant de sa soumission : Il va souvent copier les bases sur le site le plus rapide, même s’il faut pour ça effacer une base très grande et donc longue à retransmettre ensuite. Ce qu’il fera quand même pour les jobs les plus longs (tblastx). Pour les jobs les plus rapides (blastn), il avantage les nœuds qui ont déjà la base même s’ils sont lents et même si ils sont très nombreux…
- Optorsim
- Explicite : L’utilisateur décide explicitement de répliquer les données. Implicite : Ce sont les appels aux services qui provoquent les réplications de données. Contrairement à DTM, les données sont répliquées et pas déplacées. Accès direct aux données stockées + Ajout direct d’une donnée dans DIET. Automatic data management : Quand on souhaite installer une donnée sur un nœud qui ne dispose plus assez d’espace, on efface une donnée en utilisant un algo choisi dans la configuration du nœud. Transfer optimization : On choisit la « meilleure » source pour une donnée en fonction de stats réalisées pendant les transferts précédents. Storage usage management : On peut choisir quelle quantité de mémoire et quel espace disque sont réservés aux données gérées par DAGDA. Data backup/restoration : On peut enregistrer l’état actuel des distributions de données et rétablir la situation au redémarrage de DIET. (Par exemple, on arrive à la fin d’une réservation, et on veut continuer une expèrience plus tard. Au redémarrage, les données sont remises comme elles étaient avant la coupure.)
- Contrairement à DTM, c’est le SeD qui télécharge les données et pas le client qui les envoies « d’autorité ». Seules les descriptions des données (type, taille etc.) sont envoyées pour les requ êtes. Si on a configuré la taille maximum des messages envoyés par DAGDA, les données trop grandes sont envoyées en plusieurs fois. Ca permet également de limiter la quantité de mémoire nécessaire pour les transferts. DTM charge tout en mémoire avant d’envoyer les données.
- Le « cœur » de DAGDA gère l’identification et la recherche des données ainsi que le choix des sources/destinations pour les transferts. Les éléments étendus de DAGDA gèrent les limitations de ressources fixées par les utilisateurs et la sauvegarde/restauration des données. L’API permet d’accéder/ajouter directement des données dans la plateforme ainsi que de lancer des réplications.
- Une requ ête est un ensemble de séquences à « BLASTER » sur une base donnée. Une sous-requête est un sous-ensemble de ces séquences à BLASTER sur la même base.
- Use of plugin schedulers
- Division maximum : Si le fichier requ ête de départ contient n séquences, on crée n fichiers de requête chacun d’entre eux ne contenant qu’une séquence. Division en n sous-requêtes : On a n nœuds dispos, on crée n sous-requêtes de taille identique. Chaque nœud n’a à traiter qu’une seule requête. Avec Random, MCT & Round-Robin, la multiplication des requêtes provoque de l’overhead qui n’est pas compensé par l’ordonnancement. Le mieux reste de découper les requêtes en le nombre de nœuds dispos. Avec SRA, plus on a de requêtes, plus les fréquences sont fiables, et donc, l’algo est plus efficace. On compense l’overhead par l’ordonnancement. Globalement Dynamic-SRA est meilleur, m ême en découpant la requêtes en n parties si on a suffisamment de nœuds (ici 300 SeDs) : Sur 300 fichiers, on arrive à avoir des fréquences à peu près convenables. Avec moins de nœuds, donc moins de requ êtes, les fréquences sont de plus en plus approximatives et comme on optimise le débit de la plateforme, SRA-dynamique devient de moins en moins bon.
- Les algos ont des complexité différentes : BLASTN est le plus rapide à faire (ADN => alphabet de 4 lettres Vs ADN). BLASTP : Protéine => alphabet de 20 lettres Vs Protéines. BLASTX : ADN traduit en protéine Vs Protéines (traduction ADN + BLASTP) TBLASTX : Le plus long => ADN traduit en Protéine Vs Une base ADN traduite en Protéines. (Traduction de toutes les séquences et BLASTP) Globalement, le changement des fréquences n’a pas beaucoup d’influence sur MCT.