rapport technique prÉsentÉ À l’École de technologie...
TRANSCRIPT
RAPPORT TECHNIQUE
PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
DANS LE CADRE DU COURS GTI792 PROJET DE FIN D’ÉTUDES EN GÉNIE DES TI
ADAMCLOUD
UNE INFRASTRUCTURE PORTABLE
POUR LE TRAITEMENT DE DONNÉES GÉNOMIQUES
SÉBASTIEN BONAMI
BONS22049000
DÉPARTEMENT DE GÉNIE LOGICIEL ET DES TI
Professeur-superviseur
Alain April
MONTRÉAL, 15 DÉCEMBRE 2014
AUTOMNE 2014
REMERCIEMENTS
Tout d’abord, je remercie mon professeur-superviseur, Alain April, pour l’encadrement qu’il y a
offert tout au long du projet. J’ai beaucoup apprécié son enthousiasme et sa complicité dès notre
première rencontre.
Je remercie également David Lauzon pour sa grande collaboration qui a permis de tenir un
avancement continu du projet chaque semaine. Son implication dans le projet a été très précieuse et
ses efforts consacrés furent très appréciés. Il était très disponible pour m’aider dans la réalisation des
tâches et pour répondre à de nombreuses interrogations.
Ensuite, je remercie Patrice Dion, technicien à l’ÉTS, qui a fait les démarches pour l’emprunt de
matériel et pour son temps accordé à la fin du projet concernant l’implantation sur un serveur de
l’ÉTS. Il fut ouvert et disponible aux moments cruciaux.
Aussi, je veux mentionner Tony Bussières, un entrepreneur, que j’ai rencontré lors de l’évènement
« Big Data Montréal » [1] et qui m’a donné un coup de pouce à quelques reprises pour apporter son
expertise.
Enfin, je donne une petite mention à Abdoulaye Mbaye, étudiant à la maitrise, qui a participé aux
discussions lors des réunions. Il fait un projet d’études en lien avec ma réalisation et je lui souhaite
bon succès.
ADAMCLOUD
UNE INFRASTRUCTURE PORTABLE
POUR LE TRAITEMENT DE DONNÉES GÉNOMIQUES
SÉBASTIEN BONAMI
BONS22049000
RÉSUMÉ
Ce rapport regroupe la documentation se rattachant au projet de fin d’études réalisé dans le cadre du
programme génie des technologies de l’information à l’ÉTS. Le nom du projet AdamCloud fait
référence à deux éléments qui sont au cœur du projet. Adam est l’outil au centre de la chaîne de
traitement de génomes. Cloud veut signifier que le projet envisage de se reposer sur un ensemble de
processus utilisant des serveurs informatiques accessibles à distance. Le but de ce projet est de
conceptualiser une infrastructure portable en big data incluant des outils performants en génomique.
Les hôpitaux, notamment au Québec, utilisent une procédure fastidieuse pour faire le traitement de
données génomiques chez leurs patients. Une amélioration envisageable est d’accélérer cette
procédure avec de nouvelles technologies.
En plus d’Adam, il y a aussi deux autres outils qui font partie de la chaîne de traitement étudiée :
Snap et Avocado. Ces trois outils combinés permettent justement un traitement complet de données
génomiques. Ce sont des logiciels qui sont en plein développement voulant innover par rapport à
d’anciennes technologies.
Afin d’automatiser le déploiement des applications, l’outil principal utilisé pour arriver à une solution
apportant portabilité est Docker. Docker ne fait pas de virtualisation, mais amène une approche
différente. Docker peut construire automatiquement des images en lisant les instructions d'un
Dockerfile qui ressemble à un script. Un Dockerfile est un document texte qui contient toutes les
commandes qu’un utilisateur devrait entrer pour installer et configurer manuellement un logiciel. Un
conteneur Linux peut alors être exécuté à partir de cette image et un nouvel environnement est mis à
disposition rapidement.
La solution se récapitule en la création de plusieurs images Docker notamment pour les technologies
Snap, Adam, Avocado, Spark et Hadoop (HDFS). Aussi, l’utilisation d’images déjà existantes soit
Weave et cAdvisor pour ajouter des fonctionnalités externes à Docker. Aussi, une mise en place de
trois environnements fonctionnels qui se distinguent.
Enfin, il reste des itérations intéressantes dans les mois et années à avenir qui pourraient amener une
continuation à ce projet comme un approfondissement des tests de performance et une vérification de
la qualité des résultats pour éventuellement amener la solution en production.
TABLE DES MATIÈRES
Page
INTRODUCTION .....................................................................................................................1
CHAPITRE 1 MISE EN CONTEXTE ......................................................................................2 1.1 Big data ..........................................................................................................................2 1.2 Génomique .....................................................................................................................2 1.3 Problématique ................................................................................................................3 1.4 Objectifs .........................................................................................................................4
CHAPITRE 2 ANALYSE ET MÉTHODOLOGIE ..................................................................5
2.1 Analyse ..........................................................................................................................5 2.2 Méthodologie .................................................................................................................6
CHAPITRE 3 TECHNOLOGIES UTILISÉES .........................................................................7 3.1 Ubuntu Server ................................................................................................................7 3.2 Big data ..........................................................................................................................7
3.2.1 Spark ................................................................................................................7 3.2.2 HDFS ...............................................................................................................8
3.3 Génomique .....................................................................................................................9 3.3.1 Snap..................................................................................................................9
3.3.2 Adam ................................................................................................................9 3.3.3 Avocado .........................................................................................................10
3.4 Docker ..........................................................................................................................10 3.4.1 Weave ............................................................................................................11 3.4.2 cAdvisor .........................................................................................................12
3.5 Autres ...........................................................................................................................13
CHAPITRE 4 TECHNOLOGIES ENVISAGÉES ..................................................................14
4.1 CoreOS .........................................................................................................................14 4.2 Packer ...........................................................................................................................14
4.3 Vagrant .........................................................................................................................14 4.4 Eucalyptus ....................................................................................................................15
4.5 YARN ..........................................................................................................................15 4.6 Mesos ...........................................................................................................................15 4.7 InfluxDB ......................................................................................................................15
CHAPITRE 5 ARCHITECTURE............................................................................................16 5.1 Équipement mis à disposition ......................................................................................16
5.2 Environnements ...........................................................................................................18 5.2.1 Autonome .......................................................................................................18 5.2.2 Pseudo-distribué .............................................................................................19
5.2.3 Distribué .........................................................................................................20
CHAPITRE 6 INSTALLATION ET CONFIGURATION .....................................................21 6.1 Installation....................................................................................................................21 6.2 Configuration ...............................................................................................................22
6.2.1 Environnement autonome ..............................................................................24
6.2.2 Environnement pseudo-distribué ...................................................................24 6.2.3 Environnement distribué ................................................................................25
6.2.3.1 Étapes sur l’hôte maître ...................................................................25 6.2.3.2 Étapes sur un hôte esclave ...............................................................26
CHAPITRE 7 TESTS ..............................................................................................................27
7.1 Données........................................................................................................................27 7.2 Instructions ...................................................................................................................28
7.2.1 Environnement autonome ..............................................................................28
7.2.2 Environnement pseudo-distribué ...................................................................29 7.2.3 Environnement distribué ................................................................................30
7.3 Versions utilisées .........................................................................................................31
7.4 Exécutions ....................................................................................................................31 7.5 Résultats .......................................................................................................................32
CHAPITRE 8 LIMITATIONS ET PROBLÈMES ..................................................................35 8.1 Limitations des technologies........................................................................................35 8.2 Problèmes techniques...................................................................................................36
8.3 Problèmes organisationnels .........................................................................................36
CHAPITRE 9 TRAVAUX FUTURS ......................................................................................37 9.1 À court terme ...............................................................................................................37 9.2 À moyen terme .............................................................................................................37
9.3 À long terme ................................................................................................................38
CONCLUSION ........................................................................................................................39
LISTE DE RÉFÉRENCES ......................................................................................................40
BIBLIOGRAPHIE ...................................................................................................................43
ANNEXE I PROCESSUS D’ETL AU CHUSJ .......................................................................45
ANNEXE II COMPTES RENDUS HEBDOMADAIRES .....................................................46
ANNEXE III DOCKERFILE POUR SNAP ........................................................................52
ANNEXE IV DOCKERFILE POUR ADAM ......................................................................53
ANNEXE V DOCKERFILE POUR AVOCADO ...................................................................54
ANNEXE VI DOCKERFILE POUR SNAP, ADAM ET AVOCADO ...............................55
ANNEXE VII DOCKERFILE POUR ORACLE JDK .........................................................56
ANNEXE VIII DOCKERFILE POUR SPARK ...................................................................57
ANNEXE IX DOCKERFILE POUR HADOOP ..................................................................58
ANNEXE X SCRIPT POUR IMAGES – MAÎTRE – PSEUDO-DISTRIBUÉ...................59
ANNEXE XI SCRIPT POUR CONTENEURS – MAÎTRE – PSEUDO-DISTRIBUÉ .........60
ANNEXE XII SCRIPT POUR IMAGES – MAÎTRE – DISTRIBUÉ ....................................61
ANNEXE XIII SCRIPT POUR CONTENEURS – MAÎTRE – DISTRIBUÉ .......................62
ANNEXE XIV SCRIPT POUR IMAGES – ESCLAVE – DISTRIBUÉ ...............................63
ANNEXE XV SCRIPT POUR CONTENEURS – ESCLAVE – DISTRIBUÉ ......................64
ANNEXE XVI EXEMPLE DE SORTIE DE LA COMMANDE TIME ................................65
ANNEXE XVII DÉTAILS DE PROBLÈMES RENCONTRÉS ............................................66
LISTE DES TABLEAUX
Page
Tableau 1 Nouvelle chaîne de traitement d’un génome ...............................................5
Tableau 2 Détails des images Docker .........................................................................23
Tableau 3 Détails des scripts bash ..............................................................................23
Tableau 4 Tests avec un chromosome ........................................................................32
Tableau 5 Tests avec un génome ................................................................................33
Tableau 6 Tests avec un génome déjà aligné ..............................................................33
LISTE DES FIGURES
Page
Figure 1 Étapes de la méthodologie appliquée ...........................................................6
Figure 2 Composants de Spark ...................................................................................7
Figure 3 Composants de HDFS ..................................................................................8
Figure 4 Déploiement d’un réseau avec Weave .......................................................11
Figure 5 Capture d’écran de l’interface de cAdvisor ...............................................12
Figure 6 Topologie physique de l’équipement .........................................................17
Figure 7 Environnement autonome ..........................................................................18
Figure 8 Environnement pseudo-distribué ...............................................................19
Figure 9 Environnement distribué ............................................................................20
LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES
ADN Acide désoxyribonucléique
API Application programming interface
AWS Amazon Web Services
BAM Binary Alignment/Map format
CHUSJ Centre hospitalier universitaire Sainte-Justine
CLI Command-line interface
CPU Central processing unit
CSV Comma-Separated Values
EBI European Bioinformatics Institute
EECS Electrical Engineering and Computer Sciences
ERA EBI Sequence Read Archive
ERR ERA run accession
ETL Extract Transform Load
ÉTS École de technologie supérieure
FTP File Transfer Protocol
HDFS Hadoop Distributed File System
IP Internet Protocol
LTS Long Term Support
LXC Linux Containers
NCBI National Center for Biotechnology Information
RAM Random-access memory
SAM Sequence Alignment/Map format
SFTP SSH File Transfer Protocol
SNP Single-nucleotide polymorphism
SRA NCBI Sequence Read Archive
SRR SRA run accession
SSH Secure Shell
TI Technologies de l’information
UC University of California
UID User identifier
VPN Virtual private network
YARN Yet Another Resource Negotiator
LISTE DES SYMBOLES ET UNITÉS DE MESURE
Ko Kilooctet
Mo Mégaoctet
Go Gigaoctet
To Téraoctet
1
INTRODUCTION
La génomique œuvre dans l’étude du génome afin d’en décerner ses caractéristiques. C’est un
domaine en pleine effervescence qui vise le séquençage de génomes afin d’aider à la recherche sur les
caractéristiques génétiques. Ce qui nous intéresse pour ce projet est les génomes humains. Par
exemple, des chercheurs peuvent vouloir étudier l’évolution d’une tumeur ou un cancer auprès d’un
patient.
Le développement de nouvelles technologies en génomique veut offrir de nouvelles opportunités de
recherche pour arriver à élaborer des soins pour, par exemple, identifier des maladies, ce qui fait de la
génomique un enjeu très important dans le monde.
Le projet illustré par ce rapport est un projet en technologies de l’information. Il présente des
techniques pour le traitement d'ensembles de données vastes et complexes, ce qu’on appelle le big
data.
Le présent rapport comporte plusieurs chapitres. Tout d’abord, une mise en contexte est présentée
afin de bien comprendre les concepts du projet et leurs raisons d’être. Ensuite, une phase d’analyse
est créée afin de bien saisir les cas d’utilisations existants et futurs. Nous entrons ensuite dans le vif
du sujet en parlant des technologies utilisées et envisagées, de l’architecture démontrant différents
environnements, de l’installation et la configuration de ceux-ci et des tests effectués avec leurs
résultats. Enfin, des limitations et problèmes rencontrés sont discutés et des travaux futurs sont
suggérés.
2
CHAPITRE 1
MISE EN CONTEXTE
1.1 Big data
Le big data se veut comme un concept décrivant un volume massif de données à la fois structurées et
non structurées qui est difficile de traiter en utilisant des techniques traditionnels de traitement. Une
donnée est une description codée d’un élément quelconque. Par exemple, il peut être question de
données simples comme les nombres, mais aussi de données complexes comme les vidéos.
En industrie, la quantité de données gérées peut dans certains cas devenir très grande ou ces données
se déplacent fréquemment, ce qui peut engendrer des problèmes de performance. Le big data a le
potentiel d'aider les entreprises à améliorer leurs opérations en proposant de nouvelles techniques
pour le traitement de données justement. Plus précisément, le big data se rapporte à la création, le
stockage, la récupération et l'analyse de données. Ce n’est pas seulement qu’une question de volume,
mais aussi de vélocité et de variété.
1.2 Génomique
La génomique est l'étude du matériel génétique complet, aussi appelé génome. Un génome se veut
comme l’ensemble des gènes présents dans une cellule ou un organisme. Ce qui est pertinent de nos
jours est de déterminer la séquence d'ADN complète d’êtres humains individuels afin de
cartographier et d'analyser les gènes et leurs interactions. L'objectif principal qui anime ces efforts est
de comprendre la base génétique des caractères héréditaires et comprendre comment les gènes
fonctionnent pour prévenir ou guérir des maladies.
Le génome varie d’un être humain à l’autre et ces variations génétiques permettent de justement
distinguer un individu d’un autre. Par contre, un génome humain est identique dans les 90% avec tous
les autres êtres humains et même d’autres espèces comme les chimpanzés [2]. Les informations
intéressantes à conserver sont donc les quelque 10% restants.
3
1.3 Problématique
La manipulation des données génomiques peut être très lourde à gérer dans une infrastructure. Les
données produites par les séquenceurs modernes propulsent la génomique dans le domaine du big
data, car ils peuvent facilement surpasser 100 Go. Le séquençage de nombreux génomes humains
peut alors rapidement atteindre plusieurs centaines de To de données et les systèmes de gestion de
base de données classiques ne conviennent pas.
Des chercheurs en maladies génétiques utilisent des logiciels pour analyser de grands volumes de
données génomiques. Ils veulent faire le traitement efficace de données massives produites par un
génome humain. Les formats connus actuellement n’ont pas été conçus pour être traités de façon
distribuée et bien évoluer avec de grands ensembles de données. Une base de données HBase sous
Hadoop a déjà été étudiée dans le cadre d’un autre projet étudiant comme solution potentielle [3]. Par
contre, de nouvelles approches promettant d’être plus efficaces sont arrivées sur le marché.
Un projet en cours dans des hôpitaux veut permettre la transformation de génomes pour trouver une
solution aux maladies musculo-squelettiques. Il est souhaitable que ce processus devienne plus rapide
qu’il l’est actuellement.
4
1.4 Objectifs
Le but général du projet est de mettre en place une plateforme qui permet le traitement complet de
génomes dans une infrastructure portable en tenant compte que les ressources peuvent varier dans le
temps. Les outils suggérés sont Snap, Adam et Avocado et ils sont décrits dans le chapitre sur les
technologies utilisées.
Le premier objectif est de mettre en place la plateforme génomique sur un petit cluster, un ensemble
de quelques serveurs, pour pouvoir faire des tests sur les différents outils à l’aide de données
génomiques. Il faut arriver au final avec un benchmark démontrant la faisabilité de la plateforme. Il
faudra préalablement envisager quels équipements (matériels et logiciels) sont nécessaires.
Le second objectif est de permettre une portabilité simplifiée en tentant le déploiement de la
plateforme sur d’autres matériels. Le système doit donc être facilement déplaçable d’un équipement à
un autre. En d’autres mots, il faut envisager une méthode appropriée pour déployer la solution en
conservant une configuration fonctionnelle en cas de transfert. Un développeur ne devrait pas trop se
soucier de l’infrastructure, mais plutôt se concentrer sur la partie logicielle à maintenir. Une mise à
l’échelle rapide est aussi un atout.
5
CHAPITRE 2
ANALYSE ET MÉTHODOLOGIE
2.1 Analyse
Présentement, la procédure utilisée dans une grande majorité des hôpitaux suit les étapes suivantes :
1. Prise d’un échantillon pour le génome d’un patient.
2. Séquençage par un technicien de laboratoire à l’aide d’une machine spécialisée (comme un
modèle de marque Illumina [4]).
3. Diverses manipulations effectuées par un bio-informaticien pour produire des résultats sous
forme d’un fichier CSV.
4. Validation des résultats par un généticien.
5. Recherche sur les résultats par des chercheurs.
Remarque : ces étapes ont été énumérées à partir du diagramme dans l’Annexe I.
La durée de l’ensemble de ces étapes est de 2 à 3 semaines. L’éventuel but est précisément
d’améliorer l’étape 3 en utilisant des outils informatiques évolués permettant de réduire les délais
pour en arriver à la dernière étape.
Voici un aperçu de la nouvelle chaîne de traitement d’un génome avec les nouveaux outils
considérés :
Étape Nom Logiciel Entrée(s) Sortie
A Indexation d'une référence Snap Fichier FASTA Dossier SNAP
B Alignement Snap
Dossier SNAP
Fichier(s) FASTQ Fichier SAM
C Transformation Adam Fichier SAM Dossier ADAM
D Appel de variations Avocado
Dossier ADAM
Fichier FASTA Dossier ADAM
Tableau 1 Nouvelle chaîne de traitement d’un génome
6
2.2 Méthodologie
L’approche utilisée est itérative. Une première ébauche de la solution est élaborée pour en arriver à
une deuxième ébauche et ainsi de suite. Vaut mieux commencer par une petite implantation et aller
vers une plus grande. Cela diminue le risque de rencontrer des problèmes et obtenir des erreurs. Une
analyse a été effectuée avant tout pour bien comprendre les besoins. Ensuite, différents équipements
sont mis en place en installant différents matériels et logiciels afin d’en arriver à faire des tests. À
l’aide de tests effectués, des résultats démontrons si le système est fonctionnel et à quel point.
La première étape consiste en une simple machine virtuelle qui est installée et configurée sur mon
ordinateur personnel afin de se familiariser avec la nouvelle plateforme. Donc, se documenter sur les
différents outils en question c’est-à-dire Snap, Adam et Avocado et faire différentes installations et
configurations.
La deuxième étape est de faire l’étude d’outils existants sur le marché pour avoir une infrastructure
portable. Donc, se documenter et tester des technologies existantes. Il faudra en trouver au moins une
à mettre en place.
La troisième et quatrième étape est de faire des tests pratiques avec différents environnements afin de
déterminer comment le système fonctionne en termes de réactivité et de stabilité sous une charge de
travail particulière et selon le matériel mis à disposition.
Enfin, la rédaction de la documentation se rattachant aux progrès du projet s’avère importante pour la
poursuite par d’autres étudiants.
Figure 1 Étapes de la méthodologie appliquée
Afin d’effectuer un suivi de la progression du projet, un compte rendu était rédigé chaque semaine.
Voir l’Annexe II pour voir tous les comptes rendus du projet.
7
CHAPITRE 3
TECHNOLOGIES UTILISÉES
3.1 Ubuntu Server
Ubuntu Server est un système d’exploitation qui fait partie des distributions Linux orientées pour les
serveurs. Il est très populaire sur le marché grâce tout d’abord à sa gratuité et sa convivialité. La
version LTS offre aux utilisateurs des mises à jour de dépôts officiels pour cinq ans après la date de
sortie, ce qui est très important pour amener une tranquillité d'esprit. Il est utilisé dans tous les
environnements du projet.
3.2 Big data
3.2.1 Spark
Spark est un logiciel open source [5] publié sous la licence Apache. C’est un moteur d’analyse
multifonction adapté au traitement rapide. Spark combine l'analyse des données stockées avec
l'analyse de données entrantes dans un système en temps réel. Il atteint une vitesse de traitement
supérieure à d’autres méthodes comme MapReduce en utilisant la mémoire de manière plus
intelligente et il est aussi beaucoup plus léger en termes de lignes de code.
Il y a deux principaux composants dans Spark :
Master Node (Driver Program) : Il orchestre l’application à exécuter en créant un contexte.
Worker Node : Il lance des exécuteurs chargés de l'exécution d’une partie du travail.
Figure 2 Composants de Spark
(Source : http://spark.apache.org/docs/1.1.0/img/cluster-overview.png)
8
Le développement de Spark est actuellement en pleine expansion. À l'heure actuelle, la majorité des
implémentations Spark sont attachées à Hadoop, soit en utilisant HDFS comme système de fichiers
ou en exécutant Spark en même temps que d'autres applications au sein d'un cluster Hadoop.
Pour suivre le développement : https://github.com/apache/spark
3.2.2 HDFS
HDFS fait partie de la famille Hadoop et il est un système de fichiers qui permet le stockage de
données de manière évolutive. Les données peuvent être séparées entre différentes machines qui sont
reliées les unes aux autres à travers un réseau. Ce type de gestion stockant des données en vrac est
connu sous le nom de système de fichiers distribué.
Il y a trois principaux composants dans HDFS :
NameNode : Il stocke essentiellement le nom et l'adresse des DataNodes. Il est responsable
de connaitre l’emplacement des données répliquées à travers les nœuds.
SecondaryNameNode : Il est optionnel et permet de lire périodiquement les changements au
log et mettre à jour le fichier « fsimage » qui représente un instantané des métadonnées du
système de fichiers. Il permet au NameNode de démarrer plus rapidement.
DataNode : Il est utilisé pour stocker les données sous forme de blocs. C’est essentiel d’en
avoir plusieurs dans le système.
Figure 3 Composants de HDFS
(Source : http://hadoop.apache.org/docs/r1.2.1/images/hdfsarchitecture.gif)
Pour suivre le développement : https://github.com/apache/hadoop/tree/trunk/hadoop-hdfs-project
9
3.3 Génomique
Il y a de nouveaux outils prometteurs introduits au département de génie électrique et informatique
(EECS) à l’université de Californie (UC) à Berkeley. Ces outils open source se nomment Snap, Adam
et Avocado et fournit chacun une interface de programmation (API) et une interface en ligne de
commande (CLI). AMPLab est l’équipe au sein de ces technologies qui démontrent un effort de
collaboration de plusieurs années impliquant des étudiants, des chercheurs et des professeurs.
3.3.1 Snap
SNAP est un nouvel outil qui se veut comme beaucoup plus rapide et tout aussi précis que les outils
existants (comme BWA [6], Bowtie [7] et NovoAlign [8]). Il obtient aussi moins de taux d'erreur que
d’autres outils sur le marché et permet même d’obtenir des données supplémentaires. Il s’occupe de
faire deux tâches soit l’indexation d’une référence et l’alignement de séquences avec cette référence
indexée.
Pour suivre le développement : https://github.com/amplab/snap
3.3.2 Adam
Adam permet, entres autres, de prendre en entrée un fichier en format BAM ou SAM et le transformer
en son propre format s’orientant pour les environnements informatiques distribués. Adam est basé sur
les outils Avro, Parquet et Spark. Avro fournit un schéma de données et Parquet permet l'accès par
des systèmes de base de données. Aussi, Adam optimise les en-têtes de fichier des données
génomiques. Bref, Adam promet un traitement rapide de données génomiques.
Pour suivre le développement : https://github.com/bigdatagenomics/adam
10
3.3.3 Avocado
Avocado est basé sur Adam et permet de faire principalement l’appel de variation de données
génomiques. Pour ce faire, il utilise une assemblée locale d’un part. Dans ce cas, le nombre de
lectures effectuées est seulement une fraction des séquences totales disponibles. Il utilise aussi le
polymorphisme nucléotidique (SNP) d’une autre part pour identifier l'emplacement des gènes sur les
chromosomes d’un génome. Ceci aide les scientifiques à construire des cartes chromosomiques.
Pour suivre le développement : https://github.com/bigdatagenomics/avocado
3.4 Docker
Les machines virtuelles ont prouvé leur efficacité, mais ils utilisent beaucoup de ressources. Plusieurs
copies de systèmes d’exploitation roulent sur la même machine et cela a un impact sur les
performances. Docker apporte une autre approche permettant d’empaqueter des applications sans
avoir un système exploitation pour chacune.
Habituellement, lorsque qu’il faut déployer une application quelconque sur un serveur, il est
nécessaire d'abord d’installer les prérequis afin de permettre le fonctionnement de l’éventuelle
application. Ceci est bien beau jusqu'à ce qu’il est souhaité de déployer une deuxième application sur
le même serveur. Peut-être que cette deuxième application nécessite une version différente d’un
certain prérequis. Il peut y avoir des façons d’exécuter plusieurs versions d'un environnement
particulier sur le même hôte, mais ce n’est souvent pas tâche facile. Une solution qui existe depuis
plusieurs années est l’utilisation de machines virtuelles, mais Docker propose plutôt une alternative à
la virtualisation.
Il y a trois composants principaux dans Docker :
Conteneur : Il détient ce qui est nécessaire pour une ou des applications. Il peut être exécuté,
démarré, arrêté, déplacé et supprimé.
Image : Elle est utilisée comme modèle pour permettre l’exécution d’un conteneur.
Registre : C’est l’emplacement à partir duquel il est possible de télécharger des images
privées ou publiques à partir du Web. Son nom spécifique est Docker Hub [9].
11
Docker est une technologie qui étend le principe des conteneurs Linux (LXC). Ceux-ci utilisent des
groupes de contrôle et des espaces de noms pour isoler les ressources du système. Chaque conteneur
partage le même noyau Linux que l'hôte.
Essentiellement parlant, le système d'exploitation donne l'illusion aux applications de s’exécuter sur
une machine séparée tout en partageant les ressources sous-jacentes. Docker est assez facile à utiliser
avec une interface en ligne de commande intuitive.
Docker utilise une architecture client-serveur. Les clients Docker communiquent avec le daemon de
Docker qui s’occupe de construire, exécuter et distribuer les conteneurs. Il est possible de se
connecter avec un client Docker à un daemon distant.
Pour suivre le développement : https://github.com/docker/docker
3.4.1 Weave
Docker peut très bien faire communiquer des conteneurs au sein d’une même machine, mais
n’apporte pas de solution pour faire communiquer des conteneurs sur des machines distinctes. Weave
permet de créer un réseau virtuel avec des routeurs virtuels qui relie des conteneurs Docker déployés
sur plusieurs hôtes. C’est un outil créé spécifiquement pour fonctionner avec Docker.
Figure 4 Déploiement d’un réseau avec Weave
(Source : https://github.com/zettio/weave/raw/master/docs/deployment.png)
Pour suivre le développement : https://github.com/zettio/weave
12
3.4.2 cAdvisor
cAdvisor est un outil permettant d’analyser l'utilisation des ressources de conteneurs en cours
d'exécution. Il est compatible avec Docker. Plusieurs métriques peuvent être captées comme
l’utilisation du processeur (CPU), la mémoire vive (RAM) et la bande passante sur le réseau. Il
ressort ces métriques pour chaque conteneur actif sur un hôte. Ces métriques peuvent être visualisées
grâce à des graphiques sur une interface Web offerte.
Figure 5 Capture d’écran de l’interface de cAdvisor
Pour suivre le développement : https://github.com/google/cadvisor
13
3.5 Autres
Microsoft Word : logiciel de traitement de texte pour la rédaction de documents
Microsoft Visio : logiciel de synoptique pour la création de diagrammes
Microsoft PowerPoint : logiciel de présentation pour la création du support pour l’oral
Notepad++ : éditeur de texte pour la création de fichiers textes
PuTTY : émulateur de terminal pour se connecter en SSH aux serveurs
WinSCP : client SFTP pour transférer des fichiers entre serveurs
Google Drive : service de stockage en ligne pour le partage des documents
GitHub : service d'hébergement en ligne pour le suivi de l’évolution des fichiers
14
CHAPITRE 4
TECHNOLOGIES ENVISAGÉES
Les outils suivants sont des logiciels que j’ai explorés pendant le projet, mais qui ne font pas partie de
la solution finale. Ce sont des outils intéressants qui valent la peine d’être pris en compte pour
d’éventuelles suites au projet.
4.1 CoreOS
CoreOS est un système d'exploitation open source basé sur le noyau Linux. Il est léger pour fournir
que les fonctionnalités minimales requises pour le déploiement d'applications à l'intérieur de
conteneurs logiciels grâce à Docker. Il offre aussi des mécanismes intégrés pour la découverte de
services. Enfin, CoreOS a récemment annoncé le développement en cours d’un nouvel outil pour la
gestion de conteneurs : Rocket [10].
4.2 Packer
Packer est un outil conçu pour la construction d'images afin d’avoir des machines identiques. Il
permet concrètement de créer de nouvelles images de machines virtuelles avec une configuration
prédéfinie.
Pour suivre le développement : https://github.com/mitchellh/packer
4.3 Vagrant
Vagrant est un outil pour gérer les environnements de machines virtuelles. Il permet de configurer et
d'utiliser des environnements de travail reproductibles sur le dessus de diverses plates-formes de
virtualisation et de cloud computing.
Pour suivre le développement : https://github.com/mitchellh/vagrant
15
4.4 Eucalyptus
Eucalyptus est une plateforme pour permettre notamment de configurer des clouds privés. Il peut
prendre l'infrastructure informatique existante et y ajouter une couche logicielle de virtualisation. Il
est spécialisé pour être utilisé avec les services Web d’Amazon (AWS).
Pour suivre le développement : https://github.com/eucalyptus/eucalyptus
4.5 YARN
YARN permet d’orchestrer la gestion des calculs dans un cluster et d’utiliser les ressources
disponibles pour planifier les applications soumises. D’ailleurs, Spark peut être déployé sur un cluster
YARN existant [11].
Pour suivre le développement : https://github.com/apache/hadoop/tree/trunk/hadoop-yarn-project
4.6 Mesos
Mesos a sensiblement le même but que YARN, mais se différencie en utilisant des groupes de
conteneurs Linux contrairement à de simples processus Unix. Ceci amène une isolation plus forte,
mais peut apporter une certaine surcharge supplémentaire. Aussi, Spark peut être déployé sur un
cluster Mesos existant [12].
Pour suivre le développement : https://github.com/apache/mesos
4.7 InfluxDB
InfluxDB est un système de base de données pour enregistrer des données chronologiques. Il est
particulièrement intéressant, car il supporte cAdvisor utilisé pendant le projet. Pour ce, il faut passer
des options supplémentaires lors de l’instanciation du conteneur pour cAdvisor [13].
Pour suivre le développement : https://github.com/influxdb/influxdb
16
CHAPITRE 5
ARCHITECTURE
5.1 Équipement mis à disposition
Pendant le projet, j’ai utilisé mon ordinateur personnel pour faire des manipulations locales ou pour
me connecter sur différents serveurs.
En cours de route, le matériel ci-dessous a été emprunté à l’ÉTS :
Un cluster de 5 Mac mini
o Processeur : Intel Core 2 Duo P8700 (3 Mo cache, 2.53 GHz)
o Mémoire : 4 Go (DDR3, 1066 Mhz)
o Stockage : 1 x 320 Go
Un commutateur Netgear GS108Tv1 Gigabit 8 ports
Suite à certains tests effectués avec ces machines, des problèmes de performance sont survenus. J’ai
pu ainsi emprunter un Mac mini de nouvelle génération avec la collaboration de mon professeur-
superviseur :
Processeur : Intel Core i7 3720QM (6 Mo cache, 2.6 GHz)
Mémoire : 16 Go (DDR3, 1600 Mhz)
Stockage : 2 x 256 Go SSD
Enfin, un serveur de l’ÉTS parmi deux existants a été disponible en fin de projet pour faire des tests
de plus haut calibre :
Processeur : Intel Xeon E5-2650 (20 Mo cache, 2 GHz)
Mémoire : 128 Go
Stockage : 2 x 4 To
Pour y avoir accès, je me connectais à distance via un accès VPN disponible grâce à mon compte
utilisateur étudiant.
Avec le matériel emprunté, j’ai branché tout l’équipement chez moi en le reliant à mon routeur
maison. Depuis mon ordinateur personnel, SSH fut utilisé pour établir des connexions directes aux
machines.
17
Nouveau Mac miniAdams-Mac-mini-Ubuntu
Internet
Mac miniUBUNTU-MAC-2
Mac miniUBUNTU-MAC-3
Mac miniUBUNTU-MAC-4
Mac mini UBUNTU-MAC-5
Mac miniUBUNTU-MAC-1
Commutateur
Serveur Big data 2
Serveur Big data 1
OrdinateurRouteur
ClavierMoniteur
ÉTS
Domicile
Figure 6 Topologie physique de l’équipement
18
5.2 Environnements
Différents environnements ont été modélisés pour répondre à des besoins distincts. Cela suit
l’approche itérative envisagée en début de projet.
5.2.1 Autonome
Tout d’abord, un environnement simple d’un seul nœud comprenant un conteneur avec tous les
services utiles à la chaîne de traitement, en excluant cAdvisor qui crée un conteneur pour fonctionner.
La technologie HDFS n’est pas présente dans cet environnement étant donné qu’il n’y a qu’une seule
machine. Le système local de fichiers standard est utilisé c’est-à-dire qu’il y a un répertoire sur le
disque interne du serveur stockant les données génomiques. Lors de l'exécution d'un travail à partir
d'Adam ou Avocado, Spark a la capacité d’être lancé mode local, ce qui démarre automatiquement un
planificateur et un exécuteur en un seul processus en utilisant les binaires de Spark (Spark binaries).
Image : snap-adam-avocado-sparkConteneur : client-genomics
Snap Adam Avocado Spark binaries
HÔTE MAÎTRE
cAdvisor
Image : google/cadvisorConteneur : cadvisor
Figure 7 Environnement autonome
19
5.2.2 Pseudo-distribué
Un autre environnement qui ressemble beaucoup à celui autonome avec un seul nœud, mais apportant
une séparation cette fois-ci des services de Spark c’est-à-dire le Master et le Worker. Il est donc plus
propice à une meilleure maintenance du système.
Image : snap-adam-avocado-sparkConteneur : client-genomics
Snap Adam Avocado Spark binaries
HÔTE MAÎTRE
cAdvisor
Image : google/cadvisorConteneur : cadvisor
Image : spark_1.1.0-prebuilthadoop2.3Conteneur : spark
Spark Master Spark Worker
Figure 8 Environnement pseudo-distribué
20
5.2.3 Distribué
Un dernier environnement plus complexe a été conceptualisé. Il comporte plusieurs nœuds et chaque
conteneur possède un seul service. Il pourrait y avoir autant d’hôtes esclaves souhaités pour autant de
machines disponibles. Étant donné la multitude de machines qui s’occupent du traitement, un système
de fichiers distribué HDFS est présent. L'utilisateur peut exécuter des tâches arbitraires Spark sur des
données HDFS.
Figure 9 Environnement distribué
Un cluster représente en quelque sorte la réalité d’une implémentation en entreprise et cet
environnement est propice à ce type de situation. L’utilisation maximale des ressources disponibles
est souhaitée. Si un problème survient avec un service, la maintenance en sera simplifiée étant donné
la séparation de chaque service dans l’environnement.
Image : zettio/weaveConteneur : weave
Weave
HÔTE MAÎTRE
cAdvisor
Image : google/cadvisorConteneur : cadvisor
Image : snapConteneur : client-snap
Snap
Image : adamConteneur : client-adam
Adam Spark binaries
Image : avocadoConteneur : client-avocado
Avocado Spark binaries
Image : spark_1.1.0-prebuilthadoop2.3Conteneur : master-spark
Spark Master
Image : hadoop_2.3.0Conteneur : namenode-hdfs
HDFS NameNode
Image : hadoop_2.3.0Conteneur : secnamenode-hdfs
HDFS Secondary
NameNode
HÔTE ESCLAVE X
Image : zettio/weaveConteneur : weave
Weave cAdvisor
Image : google/cadvisorConteneur : cadvisor
Image : spark_1.1.0-prebuilthadoop2.3Conteneur : workerX-spark
Spark Worker
Image : hadoop_2.3.0Conteneur : datanodeX-hdfs
HDFS DataNode
21
CHAPITRE 6
INSTALLATION ET CONFIGURATION
6.1 Installation
L’approche fut d’utiliser l’outil Docker pour automatiser l’installation des diverses composantes
nécessaires à la chaîne de traitement. Docker est compatible avec de nombreuses distributions Linux
incluant Ubuntu Server choisi pour ce projet.
Pour installer la dernière version de Docker pour Ubuntu, il faut exécuter les commandes suivantes :
sudo sh -c "echo deb https://get.docker.com/ubuntu docker main >
/etc/apt/sources.list.d/docker.list"
sudo apt-get update && sudo apt-get install -y --force-yes lxc-docker
Pour l’installation sur Windows ou Mac OS X, il y a une solution nommée Boot2Docker qui est en
fait une machine virtuelle très légère (basée sur la distribution Tiny Core Linux [14]) roulant
complètement en mémoire vive. À première vue, l’utilisation en production de Boot2Docker semble
assez prématurée et il est sans aucun doute plus approprié d’utiliser Docker sous Linux.
Pour tester que Docker fonctionne bien, un court test peut être effectué qui permet de simplement
lancer un conteneur Ubuntu :
sudo docker run -ti ubuntu
Dans cet exemple, Docker vérifie si une image avec le nom « ubuntu » est présente sur la machine
locale. Si oui, il crée directement un conteneur avec cette image. Sinon, il télécharge
automatiquement l’image sur Docker Hub et crée ensuite le conteneur.
Le fait d’entrer « sudo » avant chaque commande Docker peut être évité en ajoutant l’utilisateur sur la
machine dans le groupe Unix « docker ». Ceci simplifie la gestion. Pour ce faire, il faut exécuter la
commande suivante :
sudo usermod -a -G docker UTILISATEUR
Ensuite, il faut se reconnecter avec l’utilisateur pour appliquer le changement.
22
Pour Weave, il faut récupérer le code sur GitHub. Il y a aussi ethtool comme outil recommandé pour
afficher ou modifier les paramètres du réseau.
Pour installer la dernière version de Weave et ethtool, il faut exécuter les commandes suivantes :
sudo wget -O /usr/local/bin/weave
https://raw.githubusercontent.com/zettio/weave/master/weave
sudo chmod a+x /usr/local/bin/weave
sudo apt-get update && sudo apt-get install -y ethtool
Remarque : Weave a besoin de privilèges administrateur pour exécuter ses composants.
6.2 Configuration
Les Dockerfiles créés sont comme des scripts, mais au lieu d’installer les outils, ils créent des images
Docker qui peuvent ensuite instanciées des conteneurs Docker. En d’autres mots, un Dockerfile est un
fichier permettant de construire une image Docker à l’aide d’instructions.
L’approche a été de rouler des conteneurs basés sur Ubuntu (version 14.04) et de faire des tests
d’installation en notant les commandes effectuées. Ce qui est intéressant avec les conteneurs Docker,
c’est qu’on peut facilement supprimer un conteneur et en refaire un autre.
Aussi, pour automatiser le déploiement, j’ai créé des scripts bash permettant de construire
automatiquement un environnement en démarrant les conteneurs nécessaires.
Les tableaux de la page suivante détaillent les images créées à partir des Dockerfiles et les conteneurs
exécutés à partir des scripts. La colonne Annexe réfère au code du Dockerfile ou du script en
question.
Tous les Dockerfiles et les scripts créés pour le projet sont présents dans un dépôt Git à l’adresse
suivante : https://github.com/GELOG/genomic-projects/tree/master/adamcloud/trunk.
23
Tableau 2 Détails des images Docker
Annexe Nom Description
X
singlehost_images.sh Fait un pull des images google/cadvisor et ubuntu:14.04. Construit aussi les images snap-adam-avocado-spark, oracle_jdk7 et spark_1.1.0-prebuilthadoop2.3.
XI singlehost_containers.sh Exécute des conteneurs pour cAdvisor, Snap-Adam-Avocado, Spark Master et Spark Worker.
XII
multihosts_pri_images.sh Fait un pull des images google/cadvisor, zettio/weave et ubuntu:14.04. Construit aussi les images snap, adam, avocado, oracle_jdk7, spark_1.1.0-prebuilthadoop2.3 et hadoop_2.3.0.
XIII
multihosts_pri_containers.sh Exécute des conteneurs pour cAdvisor, Weave, Snap, Adam, Avocado, Spark Master, HDFS NameNode et HDFS SecondaryNameNode.
XIV
multihosts_sec_images.sh Fait un pull des images google/cadvisor, zettio/weave et ubuntu:14.04. Construis aussi les images oracle_jdk7, spark_1.1.0-prebuilthadoop2.3 et hadoop_2.3.0.
XV multihosts_sec_containers.sh Exécute des conteneurs pour cAdvisor, Weave, Spark Worker et HDFS DataNode.
Tableau 3 Détails des scripts bash
Remarque : certains de ces scripts utilisent la nouvelle commande « exec » existante depuis la version 1.3.0 de Docker [15].
Aussi, il faut avoir un utilisateur avec les privilèges administrateur et qui soit présent le groupe « docker ».
Annexe Image
Image
parente Service Description Taille
- google/cadvisor - Interface Web
Téléchargée à partir de Docker Hub, il peut
surveiller les conteneurs. 17.56 Mo
- zettio/weave - Routage virtuel
Téléchargée à partir de Docker Hub, il peut créer
des liens de réseau entre des conteneurs sur des
machines physiques distinctes. 10.83 Mo
- ubuntu:14.04 - -
Téléchargée à partir de Docker Hub, c’est Ubuntu
Server 14.04 LTS 64-bit. 192.7 Mo
III snap ubuntu:14.04 - Snap dernière version. Démarré à la demande. 446.9 Mo
IV adam ubuntu:14.04 -
Adam dernière version avec les binaires Spark 1.1.0
précompilés pour Hadoop 2.3. Démarré à la
demande. 1.732 Go
V avocado ubuntu:14.04 -
Avocado dernière version avec les binaires Spark
1.1.0 précompilés pour Hadoop 2.3. Démarré à la
demande. 1.87 Go
VI
snap-adam-
avocado-spark ubuntu:14.04 -
Snap, Adam et Avocado dernières versions avec les
binaires Spark 1.1.0 précompilés pour Hadoop 2.3.
Démarrés à la demande. 2.39 Go
VII oraclejdk_7 ubuntu:14.04 Java Oracle JDK version 7. 735.6 Mo
VIII
spark_1.1.0-
prebuilthadoop2.3 oraclejdk_7
Spark Master /
Spark Worker Binaires Spark 1.1.0 précompilés pour Hadoop 2.3. 1.349 Go
IX hadoop_2.3.0 oraclejdk_7
NameNode /
SecondaryNameNode /
DataNode
Hadoop version 2.3.0 configurée pour YARN et
HDFS (utile pour HDFS dans ce projet). 1.323 Go
24
6.2.1 Environnement autonome
Pour la création de l’environnement autonome, c’est relativement simple d’y procéder manuellement
étant donné la complexité réduite. Comme préalable, il faut uniquement avoir Docker d’installé.
1. Téléchargement du seul Dockerfile présent dans le chemin « Dockerfiles/snap-adam-avocado-
spark ».
2. Faire un pull et construction des images nécessaires avec les commandes suivantes :
docker pull google/cadvisor
docker pull ubuntu:14.04
docker build --rm=true -t snap-adam-avocado-spark Dockerfiles/snap-adam-avocado-
spark
3. Exécution des conteneurs avec les commandes suivantes :
cAdvisor docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --
volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8079:8080 --
detach=true --name=cadvisor google/cadvisor:latest
Client génomique docker run -d -ti --name client-genomics -h client-genomics -v
/docker-volume:/docker-volume snap-adam-avocado-spark
6.2.2 Environnement pseudo-distribué
Ces étapes sont réalisées sur un seul hôte que nous appelons le maître. Il n'y a donc pas d'autres hôtes.
Comme préalable, il faut uniquement avoir Docker d’installé.
1. Téléchargement des Dockerfiles et des scripts suivants :
Dockerfiles/snap-adam-avocado-spark
Dockerfiles/oraclejdk_7
Dockerfiles/spark_1.1.0-prebuilthadoop2.3
singlehost_images.sh
singlehost_containers.sh
2. Exécution du script pour obtenir les images nécessaires. Préalablement, il faut donner la
permission d'exécution avec la commande suivante :
sudo chmod +x singlehost_images.sh
25
Ensuite, le script peut être exécuté avec la commande suivante :
sudo ./singlehost_images.sh
Remarque : cette étape prend environ 35 minutes sur un Mac mini avec une vitesse de téléchargement de 30 Mbit/s.
3. Exécution du script pour exécuter les conteneurs. Préalablement, il faut donner la permission
d'exécution avec la commande suivante :
sudo chmod +x singlehost_containers.sh
Ensuite, le script peut être exécuté avec la commande suivante :
sudo ./singlehost_containers.sh
6.2.3 Environnement distribué
6.2.3.1 Étapes sur l’hôte maître
Ces étapes sont réalisées sur l’hôte que nous appelons le maître. Comme préalables, il faut avoir
Docker et Weave d’installés.
1. Téléchargement des Dockerfiles et des scripts suivants :
Dockerfiles/snap
Dockerfiles/adam
Dockerfiles/avocado
Dockerfiles/oraclejdk_7
Dockerfiles/spark_1.1.0-prebuilthadoop2.3
Dockerfiles/hadoop_2.3.0
multihosts_pri_images.sh
multihosts_pri_containers.sh
2. Exécution du script pour obtenir les images nécessaires. Préalablement, il faut donner la
permission d'exécution avec la commande suivante :
sudo chmod +x multihosts_pri_images.sh
Ensuite, le script peut être exécuté avec la commande suivante :
sudo ./multihosts_pri_images.sh
Remarque : cette étape prend environ 45 minutes sur un Mac mini avec une vitesse de téléchargement de 30 Mbit/s.
26
3. Exécution du script pour exécuter les conteneurs. Préalablement, il faut donner la permission
d'exécution avec la commande suivante :
sudo chmod +x multihosts_pri_containers.sh
Ensuite, le script peut être exécuté avec la commande suivante :
sudo ./ multihosts_pri_containers.sh
6.2.3.2 Étapes sur un hôte esclave
Ces étapes sont réalisées sur un hôte que nous appelons un esclave. Il peut y en avoir plusieurs.
1. Téléchargement des Dockerfiles et des scripts suivants :
Dockerfiles/oraclejdk_7
Dockerfiles/spark_1.1.0-prebuilthadoop2.3
Dockerfiles/hadoop_2.3.0
multihosts_sec_images.sh
multihosts_sec_containers.sh
2. Exécution du script pour obtenir les images nécessaires. Préalablement, il faut donner la
permission d'exécution avec la commande suivante :
sudo chmod +x multihosts_sec_images.sh
Ensuite, le script peut être exécuté avec la commande suivante :
sudo ./multihosts_sec_images.sh
Remarque : cette étape prend environ 7 minutes sur un Mac mini avec une vitesse de téléchargement de 30 Mbit/s.
3. Exécution du script pour exécuter les conteneurs. Préalablement, il faut donner la permission
d'exécution avec la commande suivante :
sudo chmod +x multihosts_sec_containers.sh
Ensuite, le script peut être exécuté avec la commande suivante :
sudo ./ multihosts_sec_containers.sh
Remarque : le sous-réseau utilisé dans ces scripts est 192.168.0.0/24. Les adresses IP sont configurées avec Weave.
27
CHAPITRE 7
TESTS
7.1 Données
Les données suivantes utilisées pour faire les tests sont pour la plupart tirées du site FTP public de
« 1000 Genomes » [16].
Chromosome de référence GRCh37 (1 fichier FASTA compressé de 70 Mo) : o http://hgdownload.cse.ucsc.edu/goldenPath/hg19/chromosomes/chr1.fa.gz
Génome de référence GRCh37 (1 fichier FASTA compressé de 851 Mo) : o ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/technical/reference/human_g1k_v37.fasta.gz
Unique séquence du génome HG00096 (1 fichier FASTQ compressé de 24.1 Mo) : o ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/data/HG00096/sequence_read/SRR062634.filt.fastq.gz
Paire de séquences du génome HG00096 (2 fichiers FASTQ compressés de 1.8 Go chaque) : o ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/data/HG00096/sequence_read/SRR062634_1.filt.fastq.gz
o ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/data/HG00096/sequence_read/SRR062634_2.filt.fastq.gz
Génome déjà aligné HG00096 (1 fichier BAM de 14.5 Go) : o ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/data/HG00096/alignment/HG00096.mapped.ILLUMINA
.bwa.GBR.low_coverage.20120522.bam
Les informations relatives à ces données se trouvent, entre autres, dans les fichiers commençant par
« README » au lien suivant : ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp.
Ces données doivent être placées dans le répertoire « /docker-volume » qui sert en tant que point de
montage à l'exécution des scripts de conteneurs.
La plupart des données sont compressées avec un taux de compression d'environ 3:1. Pour
décompresser un fichier, l’outil Gzip est nécessaire [17].
Voici la commande pour simplement décompresser un fichier :
gzip -d FICHIER
Remarque : Snap ne peut pas effectuer une indexation avec un fichier FASTA compressé, mais il peut effectuer un
alignement avec des fichiers FASTQ compressés.
28
7.2 Instructions
7.2.1 Environnement autonome
Les instructions suivantes permettent d’effectuer toutes les étapes pour le traitement sur un
environnement autonome.
1. Décompression d’une référence
gzip -d /docker-volume/FASTA
2. Indexation d’une référence
docker exec client-genomics snap index /docker-volume/FASTA /docker-volume/INDEX
3. Alignement
docker exec client-genomics snap single /docker-volume/INDEX /docker-volume/FASTQ -o
/docker-volume/SAM
OU
docker exec client-genomics snap paired /docker-volume/INDEX /docker-volume/FASTQ_1
/docker-volume/FASTQ_2 -o /docker-volume/SAM
4. Transformation
docker exec client-genomics adam-submit transform /docker-volume/SAM /docker-
volume/ADAM
5. Configuration pour l’appel de variations
Il faut éditer le fichier « /usr/local/avocado/bin/avocado-submit » du conteneur « client-avocado »
pour y modifier ou supprimer les lignes suivantes dans les options de Spark :
o --conf spark.executor.memory=${AVOCADO_EXECUTOR_MEMORY:-4g} \
o --driver-memory ${AVOCADO_DRIVER_MEMORY:-4g} \
Remarque : voir ce lien pour des renseignements sur les options : https://spark.apache.org/docs/1.1.0/configuration.html
6. Appel de variations
docker exec client-genomics avocado-submit /docker-volume/ADAM /docker-volume/FASTA
/docker-volume/AVOCADO /usr/local/avocado/avocado-sample-configs/basic.properties
29
7.2.2 Environnement pseudo-distribué
Les instructions suivantes permettent d’effectuer toutes les étapes pour le traitement sur un
environnement pseudo-distribué.
1. Décompression d’une référence
C’est la même instruction que l’étape 1 de l’environnement autonome.
2. Indexation d’une référence
C’est la même instruction que l’étape 2 de l’environnement autonome.
3. Alignement
C’est la même instruction que l’étape 3 de l’environnement autonome.
4. Transformation
docker exec client-genomics adam-submit --master spark://192.168.0.9:7077 transform /docker-
volume/SAM /docker-volume/ADAM
5. Configuration pour l’appel de variations
C’est la même instruction que l’étape 5 de l’environnement autonome.
En plus, il faut aussi ajouter la ligne « --master spark://192.168.0.9:7077 \ » dans les options de
Spark. Par exemple, l’ajouter avant la ligne « --jars "$AVOCADO_JARS" \ ».
6. Appel de variations
docker exec client-genomics avocado-submit /docker-volume/ADAM /docker-volume/FASTA
/docker-volume/AVOCADO /usr/local/avocado/avocado-sample-configs/basic.properties
30
7.2.3 Environnement distribué
Les instructions suivantes permettent d’effectuer toutes les étapes pour le traitement sur un
environnement distribué.
1. Décompression d’une référence
C’est la même instruction que l’étape 1 de l’environnement autonome.
2. Indexation d’une référence
C’est la même instruction que l’étape 2 de l’environnement autonome, mais il faut remplacer
« client-genomics » par « client-snap ».
3. Alignement
C’est la même instruction que l’étape 3 de l’environnement autonome, mais il faut remplacer
« client-genomics » par « client-snap ».
4. Transfert du fichier SAM vers HDFS pour la transformation
docker exec namenode-hdfs hadoop fs -put /docker-volume/SAM hdfs://192.168.0.19:9000/
5. Transformation
docker exec client-adam adam-submit --master spark://192.168.0.9:7077 transform
hdfs://192.168.0.19:9000/SAM hdfs://192.168.0.19:9000/ADAM
6. Configuration pour l’appel de variations
C’est la même instruction que l’étape 5 de l’environnement pseudo-distribué.
7. Transfert du fichier FASTA vers HDFS pour l’appel de variations
docker exec namenode-hdfs hadoop fs -put /docker-volume/FASTA hdfs://192.168.0.19:9000/
8. Appel de variations
docker exec client-avocado avocado-submit hdfs://192.168.0.19:9000/ADAM
hdfs://192.168.0.19:9000/FASTA hdfs://192.168.0.19:9000/AVOCADO
/usr/local/avocado/avocado-sample-configs/basic.properties
31
7.3 Versions utilisées
Snap 1.0beta.17
Adam 0.15.0
Avocado code à partir du commit effectué le 17 novembre 2014 [18]
7.4 Exécutions
Cette section a pour but de documenter les tests effectués avec Snap, Adam et Avocado. La portée
concerne quelques tests de performance effectués avec différents environnements. Suite à la réussite
ou l’échec des tests sur des données génomiques, un bilan est dressé.
Il n’est pas question de vérifier l’authenticité des données, mais plutôt la faisabilité de chaque étape
du processus avec des ressources informatiques limitées.
Une estimation de l’espace disque nécessaire afin de faire les tests a été faite avec l’aide de David
Lauzon. Ceci fut particulièrement important lorsqu’est venu le temps de faire une demande d’accès à
un serveur de l’ÉTS. Le technicien devait connaitre l’espace disque nécessaire pour la réserver.
La durée et la mémoire vive ont été considérées comme les deux métriques les plus pertinentes à
vérifier. Cela est particulièrement vrai lorsqu'il s’agit d’énormes ensembles de données qui sortent des
séquenceurs. Pour capter ces métriques, la commande « time » a été utilisée. Certains interpréteurs
comme bash ont cette commande intégrée qui offre moins de fonctionnalités que la commande
complète. Pour ce, il faut l’installer avec la commande suivante :
sudo apt-get install -y time
Ensuite, elle peut être utilisée comme suit :
/usr/bin/time -v COMMANDE
Voir un exemple de sortie dans l’Annexe XVI. Le paramètre « -v » permet de sortir toutes les
métriques que le programme connait incluant celles-ci qui nous intéresse :
« Elapsed (wall clock) time (h:mm:ss or m:ss) » la durée réelle
« Maximum resident set size (kbytes) » le sommet de la mémoire vive utilisée que j’ai
converti de Ko en Go au besoin.
32
7.5 Résultats
Lors de la constitution de la chaîne de traitement d'analyse, une petite fraction des données a été prise
et chaque étape a été effectuée séparément afin de bien tester chacun des outils.
Pour la plupart des tests effectués, même sur le serveur de l’ÉTS, j’ai remarqué en visualisant
l’interface de cAdvisor que l’utilisation du processeur et de la mémoire vive atteignaient
régulièrement 100% pendant certaines étapes du traitement.
Snap ne fonctionnant pas en mode distribué, il fut inutile de refaire les tests sur un cluster de plusieurs
serveurs étant donné qu’un seul serveur effectue la tâche.
Il y a eu quatre différents environnements mis en place pour faire les tests :
1 Mac mini avec 4 Go environnement autonome
5 Mac mini avec 4 Go environnement distribué
1 Mac mini avec 16 Go environnement autonome
1 serveur ÉTS avec 128 Go environnement autonome
Les tableaux suivants démontrent des exemples effectués selon différents équipements. À noter que la
quantité de Go inscrits dans les en-têtes est la quantité de mémoire vive par machine.
Étape Entrée(s) Sortie(s)
Durée (hh:mm:ss) 1 Mac mini avec 4 Go
Durée (hh:mm:ss) 5 Mac mini avec 4 Go
Durée (hh:mm:ss) 1 Mac mini avec 16 Go
Durée (hh:mm:ss)
1 serveur ÉTS avec 128 Go
A chr1.fa (243 Mo) chr1.snap (2.3 Go) 00:01:58.99 00:00:29.56 00:00:59.33
B chr1.snap (2.3 Go)
SRR062634.filt.fastq.gz (25 Mo) SRR062634_single.filt.sam (91 Mo) 00:02:55.76 00:00:06.88 00:00:28.23
C SRR062634_single.filt.sam (91 Mo) SRR062634_single.filt.adam (22 Mo) 00:00:40.49 00:00:48.88 00:00:14.91 00:00:19.06
D SRR062634_single.filt.adam (22 Mo)
chr1.fa (243 Mo) SRR062634_single.filt.avoc (62 Mo) 00:48:43.65 00:41:59.64 00:15:30.39 00:14:35.80
Sommet RAM
1 Mac mini avec 4 Go
Sommet RAM
5 Mac mini avec 4 Go
Sommet RAM
1 Mac mini avec 16 Go
Sommet RAM
1 serveur ÉTS avec 128 Go
2.71 Go 2.72 Go 2.84 Go
2.49 Go 2.66 Go 3.12 Go
1.46 Go ? 0.65 Go 1.51 Go
3.23 Go ? 15.11 Go 75.31 Go
Tableau 4 Tests avec un chromosome
33
Étape Entrée(s) Sortie(s)
Durée (hh:mm:ss) 1 Mac mini avec 4 Go
Durée (hh:mm:ss) 5 Mac mini avec 4 Go
Durée (hh:mm:ss) 1 Mac mini avec 16 Go
Durée (hh:mm:ss)
1 serveur ÉTS avec 128 Go
A human_g1k_v37.fasta (3.0 Go) human_g1k_v37.snap (28 Go) Échec Échec Échec 00:13:16.82
B
human_g1k_v37.snap (28 Go) SRR062634_1.filt.fastq.gz (1.9 Go) SRR062634_2.filt.fastq.gz (1.8 Go) SRR062634_paired_gen.filt.sam (17 Go) 00:03:02.31
C SRR062634_paired_gen.filt.sam (17 Go) SRR062634_paired_gen.filt.adam (3.6 Go) 00:09:43.80
D SRR062634_paired_gen.filt.adam (3.6 Go)
human_g1k_v37.fasta (3.0 Go) SRR062634_paired_gen.filt.avoc (? Go) Échec
Étape Entrée(s) Sortie(s)
Durée (hh:mm:ss)
1 serveur ÉTS avec 128 Go
C HG00096.mapped.ILLUMINA.bwa.GBR. low_coverage.20120522.bam (15 Go)
HG00096.mapped.ILLUMINA.bwa.GBR. low_coverage.20120522.adam (12 Go) 00:38:19.59
D
HG00096.mapped.ILLUMINA.bwa.GBR. low_coverage.20120522.adam (12 Go)
human_g1k_v37.fasta (3.0 Go) HG00096.mapped.ILLUMINA.bwa.GBR. low_coverage.20120522.avoc (33 GB) 21:21:55.00
Tableau 6 Tests avec un génome déjà aligné
Sommet RAM
1 Mac mini avec 4 Go
Sommet RAM
5 Mac mini avec 4 Go
Sommet RAM
1 Mac mini avec 16 Go
Sommet RAM
1 serveur ÉTS avec 128 Go
Échec Échec Échec 35.39 Go
39.26 Go
92.13 Go
Échec
Tableau 5 Tests avec un génome
Sommet RAM
1 serveur ÉTS avec 128 Go
121.95 Go
122.44 Go
34
Concernant les tests avec un chromosome, le Mac mini avec 16 Go a été plus rapide pour effectuer les
étapes A, B et C comparativement au serveur de l’ÉTS avec 128 Go. Une hypothèse est que le SSD
présent dans ce nouveau modèle de Mac mini explique cette amélioration. Aussi, les étapes A et B
n’utilisent pas plus qu’environ 3 Go de mémoire vive, peu importe la quantité disponible. Ceci
s’explique par le fait que Snap met entièrement l'index de 2.3 Go du chromosome en mémoire vive et
utilise un peu plus de mémoire pour effectuer le processus. Pour l’étape D, une amélioration de
performance est perçue sur le Mac mini avec 16 Go et le serveur de l’ÉTS avec 128 Go qui utilise
justement plus de mémoire vive pour accomplir la tâche.
Aussi, les étapes C et D qui se sont effectuées sur les 5 Mac mini de 4 Go ont obtenu une
performance proche au seul Mac mini de 4 Go. L’étape C fut même moins rapide sur l’environnement
distribué. Une hypothèse serait un certain goulot d’étranglement qui est présent sur le réseau. Les
données doivent justement prendre le temps de se transférer entre les hôtes. Vaut peut-être mieux
avoir un hôte plus puissant qui contient les données que plusieurs hôtes moins puissants qui se
partagent les données.
Concernant les tests avec un génome, il y a eu échec de l’étape A avec les différents Mac mini. Je n’ai
pas été en mesure de certifier la quantité de mémoire vive nécessaire, mais je savais que c’était dû à
un manque à ce niveau. Après avoir eu accès à un serveur de l’ÉTS avec 128 Go, cette étape a réussi
et la quantité précise requise afin de l’effectuer fut de 35.39 Go. Comme avec le chromosome, Snap
met entièrement l'index de 28 Go du génome en mémoire vive, ce qui prouve qu’il faut minimum
cette quantité disponible (voir plus).
Suite au succès de l’étape A avec un génome sur le serveur de l’ÉTS avec 128 Go, j’ai effectué les
autres étapes. Les étapes B et C ont réussi, mais pas l’étape D. Après plus de 24 heures sans résultat,
j’ai annulé le processus. Le fichier log était de presque 100 Go, ce qui ne paraissait pas normal. Un
message « Had alleles observed, but no reference » se répétait sans arrêt. Je n’ai pas diagnostiqué
davantage et j’ai décidé de réessayer les étapes C et D, mais avec un génome déjà aligné.
Les estimations faites avant d’effectuer les tests sur le serveur de l’ÉTS furent assez réalistes, sauf
pour l’étape D. 21 heures se sont écoulées pour donner un résultat de 33 Go à partir d'un dossier
Adam de 12 Go. Il était envisagé d’obtenir environ 10% du format Adam en entrée, mais le résultat
donne aux alentours de 275%, ce qui est très surprenant. Je n’ai aussi pas diagnostiqué davantage.
35
CHAPITRE 8
LIMITATIONS ET PROBLÈMES
8.1 Limitations des technologies
Docker inclus des méthodes pour surveiller les conteneurs, mais de façon très basique [19].
Une autre limitation de Docker est le fait que les conteneurs partagent le noyau du système
d’exploitation. Dans le cas de mises à jour, des problèmes de compatibilité pourraient potentiellement
survenir.
Aussi, Docker permet une isolation entre les conteneurs, mais celle-ci est quand même limitée. À ce
jour, Docker ne fournit pas un espace de noms propre à chaque conteneur, donc l’identifiant de
l’utilisateur n’est pas isolé. Par exemple, un processus qui s’exécute dans le conteneur avec un certain
UID aura les privilèges de cet UID sur l'hôte sous-jacent aussi.
Concernant Weave, il fonctionne par-dessus Docker. Si un conteneur est arrêté avec la commande
« docker stop » au lieu de « weave stop », le conteneur n’aura plus d’adresse IP valide à son
redémarrage. Il inclut aussi un outil pour avoir un serveur DNS, WeaveDNS, mais cet outil est limité
et semble ne pas faire la résolution inverse adéquatement.
Enfin, cAdvisor est un outil pertinent qui apporte une interface visuelle intéressante pour visualiser
les ressources utilisées, mais il ne conserve que les 60 dernières métriques en mémoire et ceci n’est
pas configurable. Il serait utile d’avoir la possibilité de lire, par exemple, les données sur plusieurs
jours et pouvoir visualiser les graphiques selon des laps de temps déterminés.
36
8.2 Problèmes techniques
Dû à l’évolution constante des technologies dans le monde logiciel, les versions des applications
changent continuellement, ce qui peut fréquemment causer des problèmes techniques. La majorité des
outils utilisés dans ce projet existent depuis seulement quelques années voir quelques mois et n’ont
pas atteint un niveau élevé de stabilité. J’ai eu des problèmes de compatibilité de versions de certains
prérequis. Aussi, j’ai eu des problèmes avec la validité des données produites lors des tests comme je
le mentionne dans la partie résultats.
Voir dans l’Annexe XVII les détails de certains problèmes rencontrés lors du projet.
8.3 Problèmes organisationnels
Le travail à domicile peut apporter des pièges. Une planification complète doit se faire en début de
projet et il ne faut pas s’y prendre trop tard pour trouver un rythme et créer une routine de travail. La
majorité du temps consacré à la réalisation concrète du projet s’est effectué dans le dernier mois.
Par exemple, l’apprentissage d’une nouvelle technologie comme Docker m’a pris un certain temps
avant d’en avoir une maitrise appropriée.
37
CHAPITRE 9
TRAVAUX FUTURS
9.1 À court terme
Je suggère tout d’abord d’aller plus loin avec les tests. C’est une phase importante à poursuivre afin
d’avoir une meilleure vue d’ensemble des performances selon les environnements.
Aussi, aller plus en profondeur avec la surveillance des ressources serait utile. Par exemple, il serait
intéressant de connaitre l’utilisation moyenne et maximale du processeur pendant les phases d’un
traitement. Une suggestion est de connecter une base de données avec InfluxDB sur cAdvisor et faire
du data mining [20].
Sinon, il y a plusieurs autres systèmes qui peuvent apporter solution :
1. Agencement de collectd et Graphite [21]
2. sFlow [22]
3. Datadog [23]
Une autre idée pertinente serait de déployer la solution dans un environnement cloud. Il serait alors
possible de louer autant de puissance de calcul voulue. Par exemple, Docker documente l’exécution
de conteneurs dans différents environnements cloud comme Amazon EC2 [24].
9.2 À moyen terme
Il serait important de vérifier l’authenticité des résultats obtenus par la chaîne de traitement pour
s’assurer de l’efficacité des nouveaux outils en développement par l’équipe AMPLab.
Aussi, des tests pourraient être effectués sur un grand échantillon de génomes en lien avec la
recherche internationale « 1000 Genomes » visant à améliorer la carte du génome humain. Aussi, des
démonstrations ou des conférences pourraient être faites dans des hôpitaux.
38
9.3 À long terme
Le projet en question pourrait être relié au CHUSJ et être amené en production. L’éventualité d’une
mise en exploitation future dans les hôpitaux est très pertinente. Avant, il est important d’avoir fait
une preuve de concept complète afin de déterminer si la solution en question répond bien aux besoins
déterminés. Il serait approprié de rencontrer les chercheurs impliqués pour comprendre leur
fonctionnement et améliorer leur manière de travailler. Des cas réels pourraient alors être étudiés.
39
CONCLUSION
Le projet se présente comme une phase parmi un projet de plus grande envergure qui s’étalera sur une
plus longue période. Des tests ont été effectués pour reconnaitre la faisabilité de la plateforme, mais
plusieurs autres tests sont à faire pour vraiment en arriver à une preuve de concept complète. Par
exemple, traiter un plus grand volume de données que simplement quelques échantillons.
La solution conçue dans ce projet a pu être hébergée avec succès sur différents serveurs à domicile et
aussi sur un serveur à l’ÉTS, ce qui prouve une portabilité efficiente sur différents environnements.
La plateforme mise en place avec Docker permet de rapidement mettre en œuvre un environnement
qui comprend les outils nécessaires afin de traiter des données génomiques. Spark et HDFS ont des
rôles importants dans le projet permettant de favoriser une mise à l’échelle.
La montée des nouvelles technologies crée la nécessité de la gérer, l'inspecter et la rendre meilleure.
L’équipe AMPLab donne un sens au monde qui nous entoure en transformant les données en
informations. Snap, Adam et Avocado permettent un traitement qui se veut efficace.
L'informatique est maintenant dans une nouvelle ère concernant l'analyse de données en raison de
plusieurs développements récents. Dû à une meilleure accessibilité afin d’obtenir de la puissance de
calcul, il est souhaitable que les technologies étudiées entrent dans le domaine de la pratique clinique
courante. Comme le prix du séquençage diminue, nous devons être en mesure de traiter des sommes
plus en plus grandes de données génomiques.
40
LISTE DE RÉFÉRENCES
[1] Big Data Montreal
Internet, consulté le 3 octobre 2014.
http://www.bigdatamontreal.org/
[2] Sandwalk, What’s the Difference Between a Human and Chimpanzee?
Internet, consulté le 20 septembre 2014.
http://sandwalk.blogspot.ca/2012/01/whats-difference-between-human-and.html
[3] ÉTS : Publications, Conception d’une base de données de génomique en HBase
Internet, consulté le 12 septembre 2014.
http://publicationslist.org/data/a.april/ref-449/Rudeen-Michael_LOG792_H14.pdf
[4] Illumina | Sequencing and array-based solutions for genetic research
Internet, consulté le 20 septembre 2014.
http://www.illumina.com/
[5] Wikipedia, Open source
Internet, consulté le 26 septembre 2014.
http://en.wikipedia.org/wiki/Open_source
[6] Burrows-Wheeler Aligner
Internet, consulté le 20 septembre 2014.
http://bio-bwa.sourceforge.net/
[7] Bowtie, An ultrafast, memory-efficient short read aligner
Internet, consulté le 20 septembre 2014.
http://bowtie-bio.sourceforge.net/index.shtml
[8] Novocraft, NovoAlign
Internet, consulté le 20 septembre 2014.
http://www.novocraft.com/products/novoalign/
[9] Docker Hub Registry, Repositories of Docker Images
Internet, consulté le 26 septembre 2014.
https://registry.hub.docker.com/
[10] CoreOS, CoreOS is building a container runtime, Rocket
Internet, consulté le 4 décembre 2014.
https://coreos.com/blog/rocket/
41
[11] Spark 1.1.0 Documentation, Running Spark on YARN
Internet, consulté le 24 septembre 2014.
https://spark.apache.org/docs/1.1.0/running-on-yarn.html
[12] Spark 1.1.0 Documentation, Running Spark on Mesos
Internet, consulté le 24 septembre 2014.
https://spark.apache.org/docs/1.1.0/running-on-mesos.html
[13] GitHub, Exporting cAdvisor Stats to InfluxDB
Internet, consulté le 26 novembre 2014.
https://github.com/google/cadvisor/blob/master/docs/influxdb.md
[14] Tiny Core Linux
Internet, consulté le 29 septembre 2014.
http://tinycorelinux.net/
[15] Docker Documentation, Release Notes (Version 1.3.0)
Internet, consulté le 13 novembre 2014.
https://docs.docker.com/release-notes/#version-130
[16] 1000 Genomes, Home
Internet, consulté le 15 septembre 2014.
http://www.1000genomes.org/
[17] GNU Gzip
Internet, consulté le 3 octobre 2014.
http://www.gnu.org/software/gzip/manual/gzip.html
[18] GitHub, bigdatagenomics/avocado at 5126cf6e1811cdeca4b3d7f5457f77838da8d267
Internet, consulté le 20 novembre 2014.
https://github.com/bigdatagenomics/avocado/tree/5126cf6e1811cdeca4b3d7f5457f77838da8d267
[19] Docker Blog, Gathering LXC and Docker containers metrics
Internet, consulté le 1er décembre 2014.
http://blog.docker.com/2013/10/gathering-lxc-docker-containers-metrics/
[20] Wikipedia, Data mining
Internet, consulté le 3 décembre 2014.
http://en.wikipedia.org/wiki/Data_mining
[21] Docker Blog, Effortless monitoring with collectd, Graphite and Docker
Internet, consulté le 3 décembre 2014.
https://blog.docker.com/2013/07/effortless-monitoring-with-collectd-graphite-and-docker/
42
[22] sFlow, Docker performance monitoring
Internet, consulté le 3 décembre 2014.
http://blog.sflow.com/2014/06/docker-performance-monitoring.html
[23] Datadog, Docker Monitoring
Internet, consulté le 3 décembre 2014.
https://www.datadoghq.com/2014/06/monitor-docker-datadog/
[24] Docker Documentation, Amazon EC2
Internet, consulté le 18 octobre 2014.
https://docs.docker.com/installation/amazon/
43
BIBLIOGRAPHIE
EECS at UC Berkeley, ADAM: Genomics Formats and Processing Patterns for Cloud Scale Computing
Internet, consulté le 12 septembre 2014.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2013/EECS-2013-207.html
Big Data Genomics
Internet, consulté le 12 septembre 2014.
http://bdgenomics.org/
AMPLab – UC Berkeley, DNA Processing Pipeline
Internet, consulté le 12 septembre 2014.
https://amplab.cs.berkeley.edu/projects/dna-processing-pipeline/
Wikipedia, Big data
Internet, consulté le 15 octobre 2014.
http://en.wikipedia.org/wiki/Big_data
Wikipedia, Genomics
Internet, consulté le 15 octobre 2014.
http://en.wikipedia.org/wiki/Genomics
Ubuntu, Ubuntu Server - for scale-out computing
Internet, consulté le 17 septembre 2014.
http://www.ubuntu.com/server
Apache Spark™ - Lightning-Fast Cluster Computing
Internet, consulté le 12 septembre 2014.
https://spark.apache.org/
Rohit Menon, Introducing Hadoop – Part II
Internet, consulté le 18 octobre 2014.
http://www.rohitmenon.com/index.php/introducing-hadoop-part-ii/
Docker, What is Docker?
Internet, consulté le 17 septembre 2014.
https://www.docker.com/whatisdocker/
HiddenTao, Automated deployment with Docker – lessons learnt
Internet, consulté le 8 ocotobre 2014.
http://www.hiddentao.com/archives/2013/12/26/automated-deployment-with-docker-lessons-learnt/
44
SlideShare, LXC, Docker, security: is it safe to run applications in Linux Containers?
Internet, consulté le 10 octobre 2014.
http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applications-in-linux-containers
all about Weave
Internet, consulté le 13 novembre 2014.
http://weaveblog.com/
Tutum Blog, Using cAdvisor to Monitor Docker Containers
Internet, consulté le 13 novembre 2014.
http://blog.tutum.co/2014/08/07/using-cadvisor-to-monitor-docker-containers/
AMPLab – UC Berkeley, DNA Sequence Alignment with SNAP
Internet, consulté le 12 septembre 2014.
https://amplab.cs.berkeley.edu/projects/snap/
Spark Summit, ADAM: Fast, Scalable Genomic Analysis
Internet, consulté le 12 septembre 2014.
http://spark-summit.org/2014/talk/adam-fast-scalable-genomic-analysis
avocado: A Variant Caller, Distributed
Internet, consulté le 12 septembre 2014.
http://www.cs.berkeley.edu/~kubitron/courses/cs262a-F13/projects/reports/project8_report.pdf
CoreOS is Linux for Massive Server Deployments
Internet, consulté le 15 octobre 2014.
https://coreos.com/
Packer by HashiCorp
Internet, consulté le 15 octobre 2014.
https://packer.io/
Vagrant
Internet, consulté le 3 octobre 2014.
https://www.vagrantup.com/
Eucalyptus | Open Source Private Cloud Software
Internet, consulté le 24 septembre 2014.
https://www.eucalyptus.com/
time(1), Linux manual page
Internet, consulté le 17 novembre 2014.
http://man7.org/linux/man-pages/man1/time.1.html
45
ANNEXE I
PROCESSUS D’ETL AU CHUSJ
Voici un diagramme qui a été créé par David Lauzon suite à un entretien avec le docteur Moreau au
CHUSJ. Il illustre un aperçu du processus actuellement utilisé pour le traitement complet d’un
génome en milieu hospitalier.
46
ANNEXE II
COMPTES RENDUS HEBDOMADAIRES
Voici les comptes rendus qui ont été rédigés chaque semaine. Ils sont inspirés de la méthode Scrum
pour aider dans l’organisation du projet.
Lundi 22 septembre 2014
Ce qui a été fait :
Rédaction de la fiche de renseignements.
Analyse des besoins et rédaction de la proposition de projet.
Début de la première itération : se familiariser avec les concepts de base de Docker avec une
machine virtuelle Ubuntu.
Élément(s) bloquant(s) :
Matériel Mac requis pour tester Docker sur OS X. Idéalement compatible avec Thunderbolt
pour faire l’essai d’un disque Thunderbolt.
Plan d'action :
Progression sur la première itération : continuer d’expérimenter Docker.
Lundi 29 septembre 2014
Ce qui a été fait :
Continuer d’expérimenter Docker.
Se documenter sur Eucalyptus et Mesos.
Élément(s) bloquant(s) :
Aucun
Plan d'action :
Installer le mini-cluster de Mac mini chez moi.
Tester des outils pouvant permettre de faciliter la mise en place d’une infrastructure portable.
47
Lundi 6 octobre 2014
Ce qui a été fait :
Installer le mini-cluster de Mac mini chez moi.
Récupérer les fichiers (principalement le code du backend) de Michael Rudeen sur le node1
et node2.
Tester l’outil Vagrant : intéressant, mais reste basé sur des VM qui possèdent un overhead
important. Je le garde tout de même en tête.
Tester l’outil Docker avec le cas d’utilisation suivant :
o Installer Adam sur un VM Ubuntu dans VirtualBox.
o Écrire les instructions nécessaires dans un Dockerfile.
o Créer une image à l’aide de ce Dockerfile.
o Exécuter l’image dans un conteneur et constater le résultat.
o Pousser l’image sur Docker Hub.
o Configurer une nouvelle VM et essayer l’image sur celle-ci.
Élément(s) bloquant(s) :
Switch Netgear pour le mini-cluster qui est défectueuse.
Plan d'action :
Passer voir Patrice Dion pour la switch défectueuse.
Progresser pour faire fonctionner tout le pipeline génomique sur 1 seule machine physique
dans 1 seul conteneur et plusieurs.
Lundi 13 octobre 2014
Ce qui a été fait :
Échanger l’adaptateur défectueux de la switch Netgear.
Présenter le projet à l’évènement Big Data Montréal.
Installer Snap et Avocado. Comme pour Adam, créer un Dockerfile pour chacun des deux.
Avec un exemple d’un fichier « fasta » et « fastq », construire un index et aligner un
chromosome avec succès. Faire des tests de performance.
Tenter de faire une conversion d’un fichier « sam » vers le format d’Adam.
Élément(s) bloquant(s) :
Voir les problèmes 1 et 2 dans l’Annexe XVII.
Plan d'action :
Réussir le traitement complet d’un chromosome sur une machine.
Étudier la faisabilité de faire le traitement complet d’un génome sur une machine avec peu de
RAM entre autres.
48
Lundi 20 octobre 2014
Ce qui a été fait :
Commencer la rédaction du rapport d’étape.
Réussir apparemment (sans erreur) le traitement complet d’un chromosome En entrée, un
fichier « fasta » pour la référence et « fastq » pour le chromosome d’exemple. Ceci crée un
fichier « sam » avec Snap. Ensuite, passer au format « Adam » (« parquet ») avec Adam et
Avocado.
Avec Snap, tester une construction d’index d’un génome complet de référence (fichier de 3
Go pour GRCh37/hg19).
Élément(s) bloquant(s) :
Voir le problème 3 dans l’Annexe XVII. Une fois construit, l’index devrait prendre environ
28 Go sur le disque et Snap met les données en RAM pendant le processus. Une table de
hachage très performante est utilisée comparativement à d’autres solutions (comme l’outil
BWA).
Plan d'action :
Se documenter sur Packer.
Analyser la possibilité de distribuer les étapes du traitement.
Lundi 27 octobre 2014
Ce qui a été fait :
Se documenter sur Packer.
Analyser la possibilité de distribuer les étapes du traitement. CDH 5 semble être la meilleure
solution avec soit YARN ou Mesos. J’ai testé avec YARN pour l’instant.
Demander à l’équipe de « 1000 Genomes » des informations sur les données des échantillons
de génomes.
Élément(s) bloquant(s) :
Aucun
Plan d'action :
Déterminer si l’outil Packer est utile au projet.
Tenter d’avoir le pipeline génomique fonctionnant de façon distribuée sur un node.
49
Lundi 3 novembre 2014
Ce qui a été fait :
Déterminer si l’outil Packer est utile au projet. Je crois que oui, car il pourrait faciliter un
déploiement sur un environnement différent comme Amazon EC2 (qu’on veut faire à l’étape
5 du projet).
Tenter d’avoir le pipeline génomique fonctionnant de façon distribuée sur un node. J’ai
essayé différentes installations de Spark pour me familiariser.
Élément(s) bloquant(s) :
Avoir un fichier FASTQ représentant un seul chromosome. J’ai essayé l’outil EMBOSS avec
la commande « seqretsplit », mais cela a donné plusieurs milliers de fichiers.
Voir le problème 4 dans l’Annexe XVII.
Plan d'action :
Avoir le pipeline génomique fonctionnant de façon distribuée sur un node.
Commencer à envisager sur plusieurs nodes.
Lundi 10 novembre 2014
Ce qui a été fait :
Avoir le pipeline génomique fonctionnant de façon distribuée sur un node.
Commencer à envisager sur plusieurs nodes.
Élément(s) bloquant(s) :
Aucun
Plan d'action :
Avoir le pipeline génomique fonctionnant de façon distribuée sur plusieurs nodes (en utilisant
tous les Mac mini empruntés).
50
Lundi 17 novembre 2014
Ce qui a été fait :
Avoir le pipeline génomique fonctionnant de façon distribuée sur plusieurs nodes (en utilisant
tous les Mac mini empruntés). L’outil Weave a été utilisé. (Référence :
https://github.com/zettio/weave)
Élément(s) bloquant(s) :
Aucun
Plan d'action :
Inclure HDFS dans le système.
Commencer les démarches afin d’avoir accès aux serveurs de l’ÉTS et planifier le
déploiement du système.
Lundi 24 novembre 2014
Ce qui a été fait :
Inclure HDFS dans le système.
Commencer les démarches afin d’avoir accès aux serveurs de l’ÉTS et planifier le
déploiement du système.
Élément(s) bloquant(s) :
Voir le problème 5 dans l’Annexe XVII. Je reste avec OpenJDK pour l’instant.
Plan d'action :
Compléter la documentation concernant l’infrastructure.
Fournir les instructions à Patrice Dion pour le déploiement sur les serveurs de l’ÉTS.
51
Lundi 1er décembre 2014
Ce qui a été fait :
Faire fonctionner HDFS de façon distribuée.
Produire des scripts pour automatiser un exemple de déploiement.
Compléter la documentation concernant l’infrastructure.
Élément(s) bloquant(s) :
Voir le problème 6 dans l’Annexe XVII.
Plan d'action :
Fournir les instructions à Patrice Dion pour le déploiement sur les serveurs de l’ÉTS.
Faire des tests sur le(s) serveur(s) de l’ÉTS mis à disposition.
Lundi 8 décembre 2014
Ce qui a été fait :
Fournir les instructions à Patrice Dion pour le déploiement sur les serveurs de l’ÉTS.
Faire des tests sur un premier serveur de l’ÉTS.
Élément(s) bloquant(s) :
Voir le problème 7 dans l’Annexe XVII. J’ai décidé d’utiliser un autre génome pour
remplacer celui choisi.
Plan d'action :
Continuer les tests en utilisant aussi un deuxième serveur de l’ÉTS (distribué).
Préparer la présentation orale.
Terminer la rédaction du rapport final.
52
ANNEXE III
DOCKERFILE POUR SNAP
# Building the image using UBUNTU 14.04 FROM ubuntu:14.04 # Naming me as the maintainer MAINTAINER Sebastien Bonami # Installing GIT, MAKE and G++ RUN sudo apt-get update && sudo apt-get install -y git make g++ # Installing ZLIB 1.2.8 ADD http://zlib.net/zlib-1.2.8.tar.gz / RUN sudo tar -xf /zlib-1.2.8.tar.gz RUN sudo rm /zlib-1.2.8.tar.gz RUN sudo mv /zlib-1.2.8 /usr/local RUN sudo ln -s /usr/local/zlib-1.2.8 /usr/local/zlib RUN cd /usr/local/zlib-1.2.8 && sudo ./configure && sudo make && sudo make install # Installing SNAP RUN sudo git clone https://github.com/amplab/snap RUN sudo mv /snap /usr/local RUN cd /usr/local/snap && sudo make ENV SNAP_HOME /usr/local/snap # Adding the home directory to system variable to make SNAP run easier ENV PATH $PATH:$SNAP_HOME # Autostarting SNAP to show available commands RUN bash -c 'echo "snap" >> ~/.bashrc'
53
ANNEXE IV
DOCKERFILE POUR ADAM
# Building the image using UBUNTU 14.04 FROM ubuntu:14.04 # Naming me as the maintainer MAINTAINER Sebastien Bonami # Getting SPARK 1.1.0 binaries pre-built for HADOOP 2.3 ADD http://d3kbcqa49mib13.cloudfront.net/spark-1.1.0-bin-hadoop2.3.tgz / RUN sudo tar -zxf /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo rm /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo mv /spark-1.1.0-bin-hadoop2.3 /usr/local RUN sudo ln -s /usr/local/spark-1.1.0-bin-hadoop2.3 /usr/local/spark ENV SPARK_HOME /usr/local/spark # Installing GIT and JDK RUN sudo apt-get update && sudo apt-get install -y git default-jdk # Getting MAVEN 3.2.3 ADD http://mirror.its.dal.ca/apache/maven/maven-3/3.2.3/binaries/apache-maven-3.2.3-bin.tar.gz / RUN sudo tar -zxf /apache-maven-3.2.3-bin.tar.gz RUN sudo rm /apache-maven-3.2.3-bin.tar.gz RUN sudo mv /apache-maven-3.2.3 /usr/local RUN sudo ln -s /usr/local/apache-maven-3.2.3/bin/mvn /usr/bin/mvn # Giving more memory for MAVEN ENV MAVEN_OPTS -Xmx512m -XX:MaxPermSize=128m # Installing ADAM RUN git clone https://github.com/bigdatagenomics/adam RUN sudo mv /adam /usr/local RUN sed -i /usr/local/adam/pom.xml -e '27s!2.2!2.3!' RUN cd /usr/local/adam && sudo mvn clean package -DskipTestexp ENV ADAM_HOME /usr/local/adam # Adding the home directory to system variable to make ADAM run easier ENV PATH $PATH:$ADAM_HOME/bin # Autostarting ADAM to show available commands RUN bash -c 'echo "adam-submit" >> ~/.bashrc'
54
ANNEXE V
DOCKERFILE POUR AVOCADO
# Building the image using UBUNTU 14.04 FROM ubuntu:14.04 # Naming me as the maintainer MAINTAINER Sebastien Bonami # Getting SPARK 1.1.0 binaries pre-built for HADOOP 2.3 ADD http://d3kbcqa49mib13.cloudfront.net/spark-1.1.0-bin-hadoop2.3.tgz / RUN sudo tar -zxf /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo rm /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo mv /spark-1.1.0-bin-hadoop2.3 /usr/local RUN sudo ln -s /usr/local/spark-1.1.0-bin-hadoop2.3 /usr/local/spark ENV SPARK_HOME /usr/local/spark # Installing GIT and JDK RUN sudo apt-get update && sudo apt-get install -y git default-jdk
# Getting MAVEN 3.2.3 ADD http://mirror.its.dal.ca/apache/maven/maven-3/3.2.3/binaries/apache-maven-3.2.3-bin.tar.gz / RUN sudo tar -zxf /apache-maven-3.2.3-bin.tar.gz RUN sudo rm /apache-maven-3.2.3-bin.tar.gz RUN sudo mv /apache-maven-3.2.3 /usr/local RUN sudo ln -s /usr/local/apache-maven-3.2.3/bin/mvn /usr/bin/mvn # Giving more memory for MAVEN ENV MAVEN_OPTS -Xmx512m -XX:MaxPermSize=128m # Installing AVOCADO RUN git clone https://github.com/bigdatagenomics/avocado RUN sudo mv /avocado /usr/local RUN cd /usr/local/avocado && sudo mvn package ENV AVOCADO_HOME /usr/local/avocado # Adding the home directory to system variable to make AVOCADO run easier ENV PATH $PATH:$AVOCADO_HOME/bin # Autostarting AVOCADO to show available commands RUN bash -c 'echo "avocado-submit" >> ~/.bashrc'
55
ANNEXE VI
DOCKERFILE POUR SNAP, ADAM ET AVOCADO
# Building the image using UBUNTU 14.04 FROM ubuntu:14.04 # Naming me as the maintainer MAINTAINER Sebastien Bonami # Getting SPARK 1.1.0 binaries pre-built for HADOOP 2.3 ADD http://d3kbcqa49mib13.cloudfront.net/spark-1.1.0-bin-hadoop2.3.tgz / RUN sudo tar -zxf /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo rm /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo mv /spark-1.1.0-bin-hadoop2.3 /usr/local RUN sudo ln -s /usr/local/spark-1.1.0-bin-hadoop2.3 /usr/local/spark ENV SPARK_HOME /usr/local/spark # Installing GIT, MAKE, G++ and JDK RUN sudo apt-get update && sudo apt-get install -y git make g++ default-jdk # Installing ZLIB 1.2.8 (for SNAP) ADD http://zlib.net/zlib-1.2.8.tar.gz / RUN sudo tar -xf /zlib-1.2.8.tar.gz RUN sudo rm /zlib-1.2.8.tar.gz RUN sudo mv /zlib-1.2.8 /usr/local RUN sudo ln -s /usr/local/zlib-1.2.8 /usr/local/zlib RUN cd /usr/local/zlib-1.2.8 && sudo ./configure && sudo make && sudo make install # Installing SNAP RUN sudo git clone https://github.com/amplab/snap RUN sudo mv /snap /usr/local RUN cd /usr/local/snap && sudo make ENV SNAP_HOME /usr/local/snap # Getting MAVEN 3.2.3 (for ADAM and AVOCADO) ADD http://mirror.its.dal.ca/apache/maven/maven-3/3.2.3/binaries/apache-maven-3.2.3-bin.tar.gz / RUN sudo tar -zxf /apache-maven-3.2.3-bin.tar.gz RUN sudo rm /apache-maven-3.2.3-bin.tar.gz RUN sudo mv /apache-maven-3.2.3 /usr/local RUN sudo ln -s /usr/local/apache-maven-3.2.3/bin/mvn /usr/bin/mvn # Giving more memory for MAVEN ENV MAVEN_OPTS -Xmx512m -XX:MaxPermSize=128m # Installing ADAM RUN git clone https://github.com/bigdatagenomics/adam RUN sudo mv /adam /usr/local RUN sed -i /usr/local/adam/pom.xml -e '27s!2.2!2.3!' RUN cd /usr/local/adam && sudo mvn clean package -DskipTestexp ENV ADAM_HOME /usr/local/adam # Installing AVOCADO RUN git clone https://github.com/bigdatagenomics/avocado RUN sudo mv /avocado /usr/local RUN cd /usr/local/avocado && sudo mvn package ENV AVOCADO_HOME /usr/local/avocado # Adding the home directories to system variable to make SNAP, ADAM and AVOCADO run easier ENV PATH $PATH:$SNAP_HOME:$ADAM_HOME/bin:$AVOCADO_HOME/bin
56
ANNEXE VII
DOCKERFILE POUR ORACLE JDK
# Building the image using UBUNTU 14.04 FROM ubuntu:14.04 # Naming me as the maintainer MAINTAINER Sebastien Bonami # Installing Oracle JDK 7 RUN sudo apt-get update && sudo apt-get install -y software-properties-common RUN sudo add-apt-repository ppa:webupd8team/java -y RUN sudo apt-get update && sudo echo oracle-java7-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections && sudo apt-get install -y oracle-java7-installer RUN ln -s /usr/lib/jvm/java-7-oracle /usr/lib/jvm/jdk ENV JAVA_HOME /usr/lib/jvm/jdk
57
ANNEXE VIII
DOCKERFILE POUR SPARK
# Building the image using my Oracle JDK 7 FROM oraclejdk_7 # Naming me as the maintainer MAINTAINER Sebastien Bonami # Getting SPARK 1.1.0 binaries pre-built for HADOOP 2.3 ADD http://d3kbcqa49mib13.cloudfront.net/spark-1.1.0-bin-hadoop2.3.tgz / RUN sudo tar -zxf /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo rm /spark-1.1.0-bin-hadoop2.3.tgz RUN sudo mv /spark-1.1.0-bin-hadoop2.3 /usr/local RUN sudo ln -s /usr/local/spark-1.1.0-bin-hadoop2.3 /usr/local/spark ENV SPARK_HOME /usr/local/spark # Adding the home directory to system variable to make SPARK run easier ENV PATH $PATH:$SPARK_HOME/bin # Autostarting SPARK to show available commands RUN bash -c 'echo "spark-submit" >> ~/.bashrc'
58
ANNEXE IX
DOCKERFILE POUR HADOOP
# Building the image using my Oracle JDK 7 FROM oraclejdk_7 # Naming me as the maintainer MAINTAINER Sebastien Bonami # Installing HADOOP 2.3.0 ADD http://archive.apache.org/dist/hadoop/core/hadoop-2.3.0/hadoop-2.3.0.tar.gz / RUN sudo tar -zxf /hadoop-2.3.0.tar.gz RUN sudo rm /hadoop-2.3.0.tar.gz RUN sudo mv /hadoop-2.3.0 /usr/local RUN sudo ln -s /usr/local/hadoop-2.3.0 /usr/local/hadoop # Setting HADOOP environment variables ENV HADOOP_INSTALL /usr/local/hadoop ENV PATH $PATH:$HADOOP_INSTALL/bin ENV PATH $PATH:$HADOOP_INSTALL/sbin ENV HADOOP_MAPRED_HOME $HADOOP_INSTALL ENV HADOOP_COMMON_HOME $HADOOP_INSTALL ENV HADOOP_HDFS_HOME $HADOOP_INSTALL ENV HADOOP_COMMON_LIB_NATIVE_DIR $HADOOP_INSTALL/lib/native ENV YARN_HOME $HADOOP_INSTALL # Setting JAVA_HOME environment variable for HADOOP RUN sed -i 's/JAVA_HOME=${JAVA_HOME}/JAVA_HOME=\/usr\/lib\/jvm\/jdk/g' /usr/local/hadoop/etc/hadoop/hadoop-env.sh # Creating HDFS directories RUN mkdir -p /hdfs-volume/namenode RUN mkdir -p /hdfs-volume/datanode # Copying HADOOP configuration files ADD core-site.xml $HADOOP_INSTALL/etc/hadoop/core-site.xml ADD yarn-site.xml $HADOOP_INSTALL/etc/hadoop/yarn-site.xml ADD mapred-site.xml $HADOOP_INSTALL/etc/hadoop/mapred-site.xml ADD hdfs-site.xml $HADOOP_INSTALL/etc/hadoop/hdfs-site.xml
59
ANNEXE X
SCRIPT POUR IMAGES – MAÎTRE – PSEUDO-DISTRIBUÉ
#!/bin/bash #Pulling and building Docker images docker pull google/cadvisor docker pull ubuntu:14.04 docker build --rm=true -t snap-adam-avocado-spark Dockerfiles/snap-adam-avocado-spark docker build --rm=true -t oraclejdk_7 Dockerfiles/oraclejdk_7 docker build --rm=true -t spark_1.1.0-prebuilthadoop2.3 Dockerfiles/spark_1.1.0-prebuilthadoop2.3
60
ANNEXE XI
SCRIPT POUR CONTENEURS – MAÎTRE – PSEUDO-DISTRIBUÉ
#!/bin/bash #Running cAdvisor with web interface on port 8079 docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8079:8080 --detach=true --name=cadvisor google/cadvisor:latest
#Running the client (SNAP, ADAM and AVOCADO) docker run -d -ti --name client-genomics -h client-genomics -v /docker-volume:/docker-volume snap-adam-avocado-spark
#Running the Spark Master and Worker with web interfaces on ports 8080 and 8081 docker run -d -ti --name spark -h spark -p 8080:8080 -p 8081:8081 --link client-genomics:client-genomics -v /docker-volume:/docker-volume spark_1.1.0-prebuilthadoop2.3 docker exec -d spark /usr/local/spark/bin/spark-class org.apache.spark.deploy.master.Master docker exec -d spark /usr/local/spark/bin/spark-class org.apache.spark.deploy.worker.Worker spark://spark:7077
#Add hosts entry for Spark IP Address in the client SPARK_IP=`eval "docker inspect --format '{{ .NetworkSettings.IPAddress }}' spark"` docker exec client-genomics sudo -- sh -c "echo $SPARK_IP spark >> /etc/hosts"
61
ANNEXE XII
SCRIPT POUR IMAGES – MAÎTRE – DISTRIBUÉ
#!/bin/bash #Pulling and building Docker images docker pull google/cadvisor docker pull zettio/weave docker pull ubuntu:14.04 docker build --rm=true -t snap Dockerfiles/snap docker build --rm=true -t adam Dockerfiles/adam docker build --rm=true -t avocado Dockerfiles/avocado docker build --rm=true -t oraclejdk_7 Dockerfiles/oraclejdk_7 docker build --rm=true -t spark_1.1.0-prebuilthadoop2.3 Dockerfiles/spark_1.1.0-prebuilthadoop2.3 docker build --rm=true -t hadoop_2.3.0 Dockerfiles/hadoop_2.3.0
62
ANNEXE XIII
SCRIPT POUR CONTENEURS – MAÎTRE – DISTRIBUÉ
#!/bin/bash #Running cAdvisor with web interface on port 8079 docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8079:8080 --detach=true --name=cadvisor google/cadvisor:latest #Launching Weave sudo weave launch #Running the clients (SNAP, ADAM and AVOCADO) sudo weave run 192.168.0.1/24 -ti --name client-snap -h client-snap -v /docker-volume:/docker-volume snap sudo weave run 192.168.0.2/24 -e SPARK_LOCAL_IP=192.168.0.2 -ti --name client-adam -h client-adam adam sudo weave run 192.168.0.3/24 -e SPARK_LOCAL_IP=192.168.0.3 -ti --name client-avocado -h client-avocado avocado #Running the Spark Master with web interface on port 8080 sudo weave run 192.168.0.9/24 -ti --name master-spark -h master-spark -p 8080:8080 spark_1.1.0-prebuilthadoop2.3 /usr/local/spark/bin/spark-class org.apache.spark.deploy.master.Master --ip 192.168.0.9 #Running the HDFS NameNode with web interface on port 50070 sudo weave run 192.168.0.19/24 -ti --name namenode-hdfs -h namenode-hdfs -p 50070:50070 -v /docker-volume:/docker-volume hadoop_2.3.0 docker exec namenode-hdfs hdfs namenode -format docker exec namenode-hdfs mkdir /usr/local/hadoop-2.3.0/logs docker exec namenode-hdfs /usr/local/hadoop/sbin/hadoop-daemon.sh start namenode #Running the HDFS SecondaryNameNode with web interface on port 50090 sudo weave run 192.168.0.20/24 -ti --name secnamenode-hdfs -h secnamenode-hdfs -p 50090:50090 hadoop_2.3.0 docker exec secnamenode-hdfs mkdir /usr/local/hadoop-2.3.0/logs docker exec secnamenode-hdfs /usr/local/hadoop/sbin/hadoop-daemon.sh start secondarynamenode
63
ANNEXE XIV
SCRIPT POUR IMAGES – ESCLAVE – DISTRIBUÉ
#!/bin/bash #Pulling and building Docker images docker pull google/cadvisor docker pull zettio/weave docker pull ubuntu:14.04 docker build --rm=true -t oraclejdk_7 Dockerfiles/oraclejdk_7 docker build --rm=true -t spark_1.1.0-prebuilthadoop2.3 Dockerfiles/spark_1.1.0-prebuilthadoop2.3 docker build --rm=true -t hadoop_2.3.0 Dockerfiles/hadoop_2.3.0
64
ANNEXE XV
SCRIPT POUR CONTENEURS – ESCLAVE – DISTRIBUÉ
#!/bin/bash #Choosing an IP or Hostname to peer to for Weave echo "Please enter the IP or Hostname of the primary node." read input_hostname #Asking if it's the first (1), second (2), ... secondary node on the cluster echo "Please enter the rank number. Example, enter 1 if it's the first secondary node on the cluster." read input_number if [ "$input_number" -lt 1 ] || [ "$input_number" -gt 8 ]; then echo "Invalid number ($input_number). Must be between 1 and 8." else echo "Number ($input_number) is valid." #Running cAdvisor with web interface on port 8079
docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro -- volume=/var/lib/docker/:/var/lib/docker:ro --publish=8079:8080 --detach=true --name=cadvisor google/cadvisor:latest
#Launching Weave sudo weave launch $input_hostname #Running the Spark Worker with web interface on port 8081
sudo weave run 192.168.0.1$input_number/24 -ti --name worker$input_number-spark -h worker$input_number-spark -p 8081:8081 spark_1.1.0-prebuilthadoop2.3 docker exec -d worker$input_number-spark /usr/local/spark/bin/spark-class org.apache.spark.deploy.worker.Worker --ip 192.168.0.1$input_number spark://192.168.0.9:7077
#Running the HDFS DataNode with web interface on port 50075
sudo weave run 192.168.0.2$input_number/24 -ti --name datanode$input_number-hdfs -h datanode$input_number-hdfs -p 50075:50075 hadoop_2.3.0
docker exec datanode$input_number-hdfs mkdir /usr/local/hadoop-2.3.0/logs docker exec datanode$input_number-hdfs /usr/local/hadoop/sbin/hadoop-daemon.sh start datanode fi
65
ANNEXE XVI
EXEMPLE DE SORTIE DE LA COMMANDE TIME
Command being timed: "snap index chr1.fa chr1.snap" User time (seconds): 132.95 System time (seconds): 5.31 Percent of CPU this job got: 116% Elapsed (wall clock) time (h:mm:ss or m:ss): 1:58.99 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 2844944 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 4 Minor (reclaiming a frame) page faults: 580700 Voluntary context switches: 3804 Involuntary context switches: 32455 Swaps: 0 File system inputs: 497272 File system outputs: 4760464 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0
66
ANNEXE XVII
DÉTAILS DE PROBLÈMES RENCONTRÉS
Voici certains des problèmes techniques rencontrés en cours de route lors d’installations, de
configurations ou de tests sur les différents logiciels utilisés.
1. Erreur empêchant d’exécuter Adam.
Description
Erreur lors de l’exécution de n’importe quelle commande d’Adam :
Error: Unrecognized option '--conf'.
Solution
Installer la version 1.1.0 (ou plus récente) de Spark. Le flag « --conf » est seulement
disponible depuis cette version et la nouvelle version d’Adam l’utilise lorsqu’il appelle spark-
submit et spark-shell.
(Référence : https://github.com/bigdatagenomics/Adam/pull/396)
2. Librairie manquante pour l’enregistrement de logs en exécutant Adam.
Description
Erreur lors de l’exécution de n’importe quelle commande d’Adam :
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Solution
Placer la librairie correspondante dans le class path ou dans le dossier « lib » d’Hadoop
devrait régler le problème. Par contre, dans mon cas je ne trouve pas cet endroit. J’utilise
Spark de façon pre-built pour Hadoop.
67
3. Mémoire insuffisante lors de la construction d’index d’un génome avec Snap.
Description
Erreur lors de l’exécution de la commande « index » de Snap :
Allocating memory for hash tables...[ 6427.537246] Out of memory: Kill process 28786
(Snap) score 962 or sacrifice child
[ 6427.540005] Killed process 28786 (Snap) total-vm:8340184kB, anon-rss:3750416kB, file-
rss:8kB
Killed
Solution
Ajouter de la RAM à la machine (minimum 32 Go voir plus). Reste à voir si c’est possible de
distribuer le processus sur plusieurs machines.
4. Master de Spark qui ne répond pas à une requête Adam
Description
Une erreur se produit lors de l’exécution de la commande « transform » d’Adam en spécifiant
l’URL d’un master de Spark (avec des workers actifs) étant sur un autre conteneur :
ERROR SparkDeploySchedulerBackend:75 - Application has been killed. Reason: All
masters are unresponsive! Giving up.
Solution
Utiliser un alias au lieu d’un IP pour se connecter au master en effectuant une commande
Adam-submit (spark-submit). Par exemple, spark://spark-master:7077 au lieu de
spark://172.17.1.20:7077.
68
5. Build d’Adam qui plante avec Oracle JDK
Description
Avant, j’utilisais OpenJDK pour builder Adam avec la même version de Maven (3.2.3) et
cela se déroulait bien. Par contre, avec Oracle JDK il y a l’erreur suivante :
java.lang.OutOfMemoryError: PermGen space
Solution
Apparemment, il faudrait augmenter la valeur -XX:MaxPermSize pour la variable
l'environnement MAVEN_OPTS, ce que j’ai essayé, mais sans succès.
6. DataNode distant qui ne se connecte pas au NameNode
Description
Le DataNode tente de résoudre le hostname du NameNode, mais il ne le connait pas. Il
faudrait plutôt qu’il communique avec l’adresse IP du NameNode.
Solution
Dans le fichier de configuration hdfs-site.xml, on peut ajouter le paramètre suivant :
<property>
<name>dfs.namenode.datanode.registration.ip-hostname-check</name>
<value>false</value>
</property>
69
7. Génome qui ne produit pas un fichier SAM valide
Description
Pour faire des tests, j’ai décidé de prendre les fichiers suivants qui représentent des séquences
d’un génome :
ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/data/HG00306/sequence_read/ERR013119_1.filt.fastq.gz
ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/data/HG00306/sequence_read/ERR013119_2.filt.fastq.gz
Lors de l’exécution d’Adam, l’erreur suivante survient :
ERROR Executor:96 - Exception in task 22.0 in stage 0.0 (TID 22)
htsjdk.samtools.SAMFormatException: SAM validation error: ERROR: Read name ERR013119.698751, No real
operator (M|I|D|N) in CIGAR
at htsjdk.samtools.SAMUtils.processValidationErrors(SAMUtils.java:452)
at htsjdk.samtools.SAMRecord.getCigar(SAMRecord.java:584)
at htsjdk.samtools.SAMRecord.getCigarLength(SAMRecord.java:595)
at htsjdk.samtools.SAMRecord.isValid(SAMRecord.java:1536)
at htsjdk.samtools.SAMLineParser.parseLine(SAMLineParser.java:328)
at htsjdk.samtools.SAMTextReader$RecordIterator.parseLine(SAMTextReader.java:247)
at htsjdk.samtools.SAMTextReader$RecordIterator.next(SAMTextReader.java:235)
at htsjdk.samtools.SAMTextReader$RecordIterator.next(SAMTextReader.java:211)
at htsjdk.samtools.SamReader$AssertingIterator.next(SamReader.java:514)
at htsjdk.samtools.SamReader$AssertingIterator.next(SamReader.java:488)
at org.seqdoop.hadoop_bam.SAMRecordReader.nextKeyValue(SAMRecordReader.java:175)
at org.apache.spark.rdd.NewHadoopRDD$$anon$1.hasNext(NewHadoopRDD.scala:138)
at org.apache.spark.InterruptibleIterator.hasNext(InterruptibleIterator.scala:39)
at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327)
at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327)
at org.apache.spark.rdd.PairRDDFunctions$$anonfun$12.apply(PairRDDFunctions.scala:920)
at org.apache.spark.rdd.PairRDDFunctions$$anonfun$12.apply(PairRDDFunctions.scala:903)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:62)
at org.apache.spark.scheduler.Task.run(Task.scala:54)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:177)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Solution
Il y a peut-être moyen avec Snap de rendre le fichier SAM valide en utilisant des paramètres
spécifiques lors de l’alignement. C’est une hypothèse à vérifier.