Citation preview
Desarrollo de una Plataforma de Almacenamiento y Procesamiento
Distribuido para Analisis de Datos
Biologicos
Bogota, Colombia
Desarrollo de una Plataforma de Almacenamiento y Procesamiento
Distribuido para Analisis de Datos
Biologicos
Jonathan Freddy Narvaez Prieto
Tesis o trabajo de grado presentada(o) como requisito parcial para
optar al ttulo de:
Magister en Telecomunicaciones
Lnea de Investigacion:
Grupo de Investigacion:
Universidad Nacional de Colombia
Bogota, Colombia
de la vida y a ±por hacerme ver que
la vida siempre es joven y que siempre
existe un espacio para cada sueno.
Agradecimientos
Al profesor Luis Fernando Nino Vasquez, PhD por su valioso apoyo,
paciencia y gua para el
desarrollo del proyecto de maestra. Al grupo de investigacion LISI
por guiarme, y realizar
aportes y criticas sobre el trabajo para poder mejorarlo.
A Carlos Manuel Estevez por incitarme a comenzar este viaje
academico y Daniel Restrepo
por guiarme en el lado biologico por que si no, no lo logro.
A Beto, Polkis , Kathy que estuvieron ah pendientes y Gladys por
estar ah dandome moral
y gua.
Y a todos los que me preguntaron cada rato ¿y la tesis?.
vii
Resumen
Este proyecto propone una plataforma para el procesamiento de datos
biologicos, imple-
mentando una estrategia para la ejecucion de flujos de
procesamiento de informacion de
forma distribuida. Esta plataforma implementa una estrategia de
contenedores para el aisla-
miento y portabilidad del software de bioinformatica, aprovecha las
caractersticas de control
que esta tecnologa prove; as mismo, el almacenamiento distribuido
es una parte central de
esta plataforma, lo que permite controlar el acceso de la
informacion a cada uno de los nodos
de forma eficiente implementando una estrategia de metadatos que
permite una facil ubica-
cion de los experimentos que quieren ser procesados por cada uno de
los nodos del sistema
distribuido. Se implemento un modelo de control de recursos llamado
Dominant Resource
Fairness (DRF) y de distribucion de procesos para sistemas
distribuidos llamado de Hete-
rogeneous Earliest Finish Time (HEFT).
Ademas, se realizo una prueba con un flujo de procesamiento de
datos de RNA-Seq usando
datos clnicos de Mycobacterium Tuberculosis. La prueba mostro que
fue posible abordar una
estrategia distribuida para obtener un mejor rendimiento y tiempos
de ejecucion a la hora
de realizar este tipo de analisis sobre datos biologicos. Se
observo que las aplicaciones que
no son paralelizables afectan en gran medida el rendimiento, y
algunas aplicaciones dentro
de la prueba no hacen uso eficiente del almacenamiento, generando
grandes bloques de in-
formacion sobre el sistema de archivos causando algunos
problemas.
Palabras clave: Flujo de Datos, Sistemas Distribuidos,
Almacenamiento Distribuido,
Contenedores, Bioinformatica.
viii
Abstract
This project proposes a platform for processing biological data,
implementing a strategy
for the execution of distributed information processing flows. This
platform implements a
strategy of containers for the isolation and portability of
bioinformatics software and also
takes advantage of the control features that this technology
provides; in addition, distribu-
ted storage is a central part of the platform that allows to
control access to the information
in each of the nodes efficiently by implementing a metadata
strategy that allows an easy
location of the experiments that want to be analyzed by each of the
nodes corresponding to
the distributed system. A resource control model called Dominant
Resource Fairness (DRF)
and process distribution model for distributed systems called
Heterogeneous Earliest Finish
Time (HEFT) were implemented.
Additionally, a test was performed with a data processing flow for
RNA-Seq using clinical
data related to Mycobacterium Tuberculosis. The test indicates that
it is possible to develop
a distributed strategy to obtain better performance and execution
times when performing
this type of analysis on biological data with a clear information
processing flow for the data
coming from the information sequencing. It was noted that
non-parallelizable applications
affect performance to a significant extent, and some applications
within the test do not make
efficient use of storage by generating large blocks of information
about the file system causing
some problems.
matics.
Lista de Figuras
2-1. Cuadro de comparacion del costo generado por genoma, comparado
por la ley
de Moore. Fuente de [1] . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 6
2-2. Cuadro Comparativo de las diferentes tecnologas de
secuenciacion. Fuente [2] 8
2-3. Descripcion del proceso de secuenciacion y analisis
bioinformatico. Fuente [2] 10
2-4. Modelo para aplicaciones de software distribuidas. Fuente [3]
. . . . . . . . 11
2-5. Capas de un modelo de computacion distribuida. Fuente [3] . .
. . . . . . . . 14
2-6. Representacion de los procesos y su distribucion por eventos.
Fuente [4] . . . 16
3-1. Diagrama de Condor y su ubicacion en la capa media de la
arquitectura.
Fuente [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 22
3-2. Modelo ejecucion PBS FIFO y MAUI. Fuente [6] . . . . . . . . .
. . . . . . . 24
3-3. Modelo del servicio ofrecido por Zookeeper. Fuente [7] . . . .
. . . . . . . . . 26
3-4. Arquitectura de procesamiento de Mesos. Fuente [8] . . . . . .
. . . . . . . . 27
3-5. Arquitectua de Ceph y distribucion de datos y Meta-datos.
Fuente [9] . . . . 28
3-6. Arquitectura de Lustre. Fuente [10] . . . . . . . . . . . . .
. . . . . . . . . . 30
6-1. Arquitectura de la Plataforma. Elaboracion Propia . . . . . .
. . . . . . . . 43
7-1. Modelo de Clases. Elaboracion Propia . . . . . . . . . . . . .
. . . . . . . . . 46
7-2. Modelo de Despliegue. Elaboracion Propia . . . . . . . . . . .
. . . . . . . . 47
7-3. Modelo de procesamiento de datos de RNASeq propuesto por
SPARTA. Fuen-
te [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 49
7-4. Tiempo de ejecucion por experimento en horas y las fases que
cada conjunto
de datos tarda en ejecutarlo. . . . . . . . . . . . . . . . . . . .
. . . . . . . . 54
x Lista de Figuras
7-5. Cantidad de horas usadas por nodo. Elaboracion Propia . . . .
. . . . . . . 55
7-6. Trafico de Red generado por nodo y da. . . . . . . . . . . . .
. . . . . . . . 56
7-7. Porcentaje de memoria usada por Nodo y Da. Elaboracion Propia
. . . . . . 57
7-8. Porcentaje de procesamiento por nodo y da. . . . . . . . . . .
. . . . . . . . 58
7-9. Utilizacion del almacenamiento por da. . . . . . . . . . . . .
. . . . . . . . . 59
Lista de Tablas
5-2. Tabla comparativa para el procesamiento distribuido.
Elaboracion propia . . 37
7-1. Descripcion de los datos usado para la prueba. . . . . . . . .
. . . . . . . . . 50
Contenido
2.3. Bioinformatica . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 9
2.4.1. Capa de Aplicacion . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 13
2.4.2. Capa Media . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 13
2.5. Ejecucion Distribuida de Procesos . . . . . . . . . . . . . .
. . . . . . . . . . 15
2.6. Modelo de Comunicacion Distribuida . . . . . . . . . . . . . .
. . . . . . . . 16
2.7. Estado Global de un Sistema Distribuido . . . . . . . . . . .
. . . . . . . . . 17
2.8. Modelo del Proceso de Comunicacion . . . . . . . . . . . . . .
. . . . . . . . 18
2.9. Algoritmos de Ejecucion Distribuida . . . . . . . . . . . . .
. . . . . . . . . 18
2.9.1. Algoritmo Asimetrico . . . . . . . . . . . . . . . . . . . .
. . . . . . . 19
3. Estado del Arte y Trabajo Previo 21
3.1. Condor . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 21
3.3. Zookeeper . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 25
3.4. Mesos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 26
3.5. Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 27
3.6. Lustre . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 29
4.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 31
5.1. Almacenamiento Distribuido . . . . . . . . . . . . . . . . . .
. . . . . . . . . 34
5.2. Procesamiento Distribuido . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 36
6.2. Ubicacion de Recursos . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 38
6.3. Aislamiento . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 39
6.4. Contenedores . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 39
6.6. Modelo Computacional . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 40
Contenido 1
7. Construccion de un Prototipo Para la Distribucion de Procesos
44
7.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 44
7.5. Descripcion de los Datos . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 50
7.6. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 51
7.7. Recoleccion de los Datos . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 52
7.7.1. Herramientas . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 52
7.8. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 53
7.8.2. Tiempo de Ejecucion Total . . . . . . . . . . . . . . . . .
. . . . . . . 54
7.8.3. Trafico de Red Generado . . . . . . . . . . . . . . . . . .
. . . . . . . 55
7.8.4. Uso de la Memoria Promedio . . . . . . . . . . . . . . . . .
. . . . . 56
7.8.5. Uso del Procesamiento Promedio . . . . . . . . . . . . . . .
. . . . . 57
7.8.6. Uso del Almacenamiento Promedio . . . . . . . . . . . . . .
. . . . . 58
8. Conclusiones y Recomendaciones 60
8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 60
8.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 61
Bibliografa 64
1. Introduccion
Las plataformas de computacion distribuida se destacan por su
capacidad de resolucion de
problemas con alto nivel de complejidad, ya que estos problemas
requieren una gran canti-
dad de recursos de procesamiento y almacenamiento para ser
solucionados; en contraste, los
sistemas centralizados tienen un grupo de limitantes basadas en el
hardware en que estan
construidos, pero son los equipos de computo mas comunes.
Las nuevas tecnologas de aislamiento de procesos y la
implementacion de estrategias de
distribucion de los mismos permite usar de manera mas eficiente los
recursos que componen
un sistema distribuido, y lograr mejorar los tiempos de ejecucion y
analisis de las tareas
que componen la estrategia de procesamiento de datos,
particularmente, los datos de tipo
biologico.
Las tecnologas de secuenciamiento de alto rendimiento basadas en
biologa molecular han
puesto nuevos retos a nivel del procesamiento y almacenamiento de
informacion, debido a la
rapida generacion de dato. Esto hace que el procesar este tipo de
informacion se convierta en
una tarea compleja, as como clasificarla y reestructurarla para
posteriores analisis. Ademas,
los analisis de datos se caracterizan por diversos flujos de
procesamiento y la ejecucion de
multiples pasos.
La plataforma que se propone para el desarrollo de esta propuesta
es el analisis de datos
biologicos implementando una estrategia distribuida de procesos
inspirada en los modelos de
gestion de recursos DRF y HEFT integrando multiples tecnologas que
permitan abordar el
3
procesamiento de datos biologicos de forma practica, utilizando
contenedores y imagenes del
proyecto BioContainer para facilitar la portabilidad de las
herramientas bioinformaticas a lo
largo del sistema distribuido, Master Distribution Task Integra e
implementa una estrategia
para el procesamiento de datos biologicos proponiendo una
estrategia para el procesamiento
de datos biologicos.
La computacion distribuida para el procesamiento de datos
biologicos establece un campos
de investigacion para la gestion de tareas mas eficiente a traves
del desarrollo de multiples
flujos de procesamiento, y implementacion de nuevas tecnologas
complementarias al analisis
de datos permitiendo usar nuevas arquitecturas de hardware para
procesamiento y estrate-
gias de almacenamiento distribuido.
2. Marco Teorico
El avance y aparicion de nuevas tecnologas de computacion ha
permitido abarcar los pro-
blemas de procesamiento de datos de diferentes formas usando
recursos de computo que se
ajustan a las necesidades, ofreciendo multiples alternativas a
soluciones de calculo matemati-
co, entre otro tipo de operaciones. El ser humano siempre ha tenido
la necesidad de resolver
sus problemas de alguna forma, y los acercamientos que ha realizado
para el entendimiento
de protenas, clima y analisis de datos, entre otros, los ha hecho
con base en la utilizacion
de sistemas distribuidos . Los sistemas distribuidos se han
convertido en una de las herra-
mientas que permiten buscar soluciones a problemas complejos por
medio de la computacion.
El uso de las nuevas tecnologas de secuenciamiento de alto
rendimiento hace posible la ob-
tencion de datos biologicos de forma rapida; la obtencion de este
tipo de informacion hacen
que la organizacion y procesamiento de informacion sean tareas
complejas con los recur-
sos computacionales que se tienen a disposicion en la actualidad.
Por otro lado, el uso de
herramientas computacionales para el procesamiento de los datos, ya
sea para el trabajo
colaborativo o de manera individual, de forma distribuida es un
proceso complejo. Esto se
debe a que se requiere el uso de recursos de computacion
heterogeneos para facilitar este
proceso. Particularmente, esto involucra la organizacion y
distribucion de datos biologicos,
uso de bases de datos biologicas, herramientas bioinformaticas y el
uso de diferentes modelos
de computacion en paralelo. A continuacion se describen los
principales conceptos sobre la
manipulacion de datos biologicos aplicados en este proyecto
[12].
La biologa computacional describe como los metodos mediados por el
computador ayudan
5
a responder preguntas biologicas. Estos metodos computacionales son
implementaciones de
algoritmos que se utilizan para analizar diferentes tipos de datos
provenientes de experimen-
tos realizados en laboratorio: la secuenciacion de genes y genomas,
los niveles de expresion
genica, e imagenes de protenas y sus estructuras. La genomica
comparativa busca compren-
der la funcion de los genomas, mediante el analisis de estas
secuencias se puede obtener
clasificacion de homologos, similitudes funcionales, filogenia o
proximidad genetica. Todos
los analisis comparativos, o relacionados al analisis de datos
provenientes de secuenciacion,
requieren soluciones de escalamiento, que permitan manejar grandes
volumenes de datos y
poder analizar correlaciones entre los datos de diferentes genomas
o transcriptomas secuen-
ciados [13, 14].
Los costos asociados a la secuenciacion han venido decreciendo en
los ultimos anos, ahora
es mas facil obtener genomas o transcriptomas de un organismo, algo
que con la tecnologa
Sanger era mas complicado de obtener. El volumen de este tipo de
datos generados por ano
se han venido incrementando exponencialmente, GenBank reporta que
su base de datos de
genomas microbianos se duplica aproximadamente cada 17 meses. El
proyecto 1000 Genomas
1 tiene mas de 200 terabytes de genomas humanos en su base datos.
Los volumenes de datos
secuenciados crece mas rapido que la ley de Moore, por lo cual se
considera que el hardware
no va a poder abordar eficientemente los nuevos problemas y retos
generados por este tipo
de datos. En la Figura 2-1 se puede observar como la secuenciacion
es mas economica y
progresa mas rapido que la ley de Moore[15] [1].
1”http://www.internationalgenome.org”
6 2 Marco Teorico
Figura 2-1.: Cuadro de comparacion del costo generado por genoma,
comparado por la ley
de Moore. Fuente de [1]
2.1. Organizacion y Distribucion de Datos Biologicos
Los datos biologicos son usualmente organizados usando bases de
datos relacionales o de
ontologas, en algunas ocasiones, a traves de sistemas que combinan
las caractersticas de los
dos tipos. Ademas, las bases de datos biologicas [16] han tenido un
incremento exponencial
en la ultimos anos. La organizacion de estos datos hace necesario
que las consultas de infor-
macion sean mas eficaces y eficientes, garantizando la integridad
de la informacion que se
tiene almacenada. Tambien, todos estos datos se pueden enriquecer
con el uso de anotacio-
nes, graficos y otra informacion asociada, relacionandolos, por
ejemplo, con informacion de
genes u otros datos existentes en otras bases de datos, o
adicionando elementos importantes
para la integracion con bases de datos externas [17].
2.2 Tecnologa de Secuenciacion de Alto Rendimiento 7
2.2. Tecnologa de Secuenciacion de Alto Rendimiento
La secuenciacion del alto rendimiento o de ultima generacion (Next
Generation Sequencing,
NGS) [2] [12] se establece como una tecnologa revolucionaria que
permite una mayor carac-
terizacion de genomas y transcriptomas, la cual permite catalogar y
observar miles de datos
acerca de los organismos secuenciados. De igual forma, permite
generar grandes volumenes
de datos para ser procesados y analizados
La secuenciacion con tecnicas moleculares de alto rendimiento ha
permitido un crecimiento
exponencial en la cantidad de datos generados. As mismo, todos
estos datos han originado
grandes retos a la hora de almacenarlos y procesarlos, debido a que
estos datos tambien son
enriquecidos adicionando elementos a la informacion original, tales
como notas, diagramas o
relaciones con otras secuencias [18]. Las secuencias que son
ensambladas, alineadas o anali-
zadas pueden convertirse en un punto de referencia para un genoma.
Toda esta informacion
de gran utilidad puede ser copiada e intercambiada entre
investigadores [19].
En la Figura 2-2 se pueden observar las diferentes tecnologas de
NGS, cada una de sus
aplicaciones puede variar de acuerdo a numero de factores y de
objetivos planteados para
realizar con los datos secuenciados.
8 2 Marco Teorico
2.3 Bioinformatica 9
Los datos biologicos provenientes de secuenciacion se establecen
como un elemento impor-
tante de la biologa y de la investigacion medica; esto, entre otras
cosas, ha dado lugar a
una nueva disciplina llamada Bioinformatica, la cual combina los
campos de la computacion,
las matematicas, la estadstica y la biologa. En la bioinformatica
aparecen como campos de
investigacion la administracion de datos biologicos y el
descubrimiento de conocimiento a
partir de los datos biologicos.
Para la bioinformatica se establece una gran necesidad, la cual es
el procesamiento y analisis
de los datos provenientes de tecnicas moleculares de alto
rendimiento. El aumento exponen-
cial de los datos provenientes de estas tecnicas hace que cada vez
se requieren mas herramien-
tas bioinformaticas, pero estas a su vez son construidas con un
factor de procesamiento muy
alto, y se requiere un alto poder de computo para obtener
resultados de forma rapida.[20] [21].
En el analisis bioinformatico de los datos provenientes de las
tecnicas de NGS, se inclu-
yen fases de preprocesamiento, ensamblaje, en algunos casos se
requiere la eliminacion del
huesped para poder identificar patogenos, realizar una
clasificacion taxonomica y realizar un
representacion de los resultados obtenidos con base a informacion
reportada en la literatura
o bases de datos. En la Figura 2-4 se puede observar un flujo de
generacion y procesamiento
de datos biologicos contemplando las fases de laboratorio y
analisis de datos bioinformaticos
[22].
2.4 Computacion Distribuida y en Paralelo 11
2.4. Computacion Distribuida y en Paralelo
La computacion en malla, cuando fue disenada, establecio un
objetivo primordial, el cual
es distribuir los recursos de computo para que procesen
determinadas tareas de forma mas
eficaz, inicialmente estos sistemas, estaban ubicados en un solo
centro de datos. Para nombrar
un ejemplo, se conoce que el centro de computacion en malla mas
grande que existe es el
del CERN 2, tecnologa que fue apropiada e inventada por CERN en
1989; en los centros
de datos de CERN pasan cada segundo 10Gb de informacion, la cual es
almacenada en 30
petabytes con 90.000 nucleos de procesamiento, lo que se traduce en
aproximadamente 6000
registros a una base de datos cada segundo. La computacion en malla
establece un reto para
los costos de operacion de un centro de investigacion que hospede
este tipo de infraestructura
[21].
Estos sistemas proveen un sistema lleno de caractersticas como
multiples usuarios accediendo
a los recursos de computo y la construccion de recursos
especializados como clusters de
multiples nucleos de procesamiento para el desarrollo de tareas que
requieran alto poder de
computo [22].
Figura 2-4.: Modelo para aplicaciones de software distribuidas.
Fuente [3]
2”http://cern.ch”
Los sistemas distribuidos consisten en un conjunto de procesadores
conectados por medio de
una red de datos, as mismo esta red provee la facilidad de
intercambiar informacion entre
los nodos que se encuentran asociados al sistema distribuido. El
modelo de comunicacion
es uno de los elementos es donde se pueden implementar diferentes
estrategias para la dis-
tribucion y comunicacion entre nodos, as mismo, la relacion entre
procesadores y memoria
debe esta comprendida en un modelo eficiente de comunicacion en
donde la memoria o el
procesador se conviertan en un cuello de botella para la
realizacion de tareas. Cuando todos
estos elementos se unen conforman un sistema distribuido,
procesadores, memoria, alma-
cenamiento y red. Definida la estrategia de comunicacion, se
establece que solamente los
mensajes pueden pasar por medio de la red para realizar la gestion
de las diferentes tareas.
La estrategia de comunicacion se convierte en un factor importante
para la realizacion de las
tareas, esta estrategia puede ser por medio de mensajes que se
procesan de forma sncrona
o asncrona, pero adicional a la estrategia de comunicacion, se debe
tener en cuenta que los
recursos asociados al sistema operativo pueden fallar, tales como
procesadores, memorias,
almacenamiento y los enlaces de comunicacion. Por esto, los
sistemas distribuidos cuentan
con una caracterstica que es la tolerancia a fallos, mas adelante
se abordara este tema [4].
Un programa distribuido esta compuesto por n procesos asncronos
(p1, p2, ...., pn) y la co-
municacion de estos mensajes se hace sobre una red de
comunicaciones. La estrategia asume
que cada uno de los procesos debe debe ser asumido por cada uno de
los procesadores que
tiene el sistema distribuido. Estos procesos, por lo general, no
estan sincronizados por medio
de un reloj global, esto sucede para que se puedan acceder de forma
instantanea a todos los
procesos. El proceso de ejecucion y envio de mensajes se realiza de
forma asncrona para
poder aprovechar la no correspondencia temporal de los estados
actuales [23] [4].
El estado global de un sistema distribuido esta compuesto por los
estados de los procesos y
los canales de comunicacion [4]. El estado de los procesos se
caracteriza porque es un estado
de la memoria local y este informa acerca del contexto de los
procesos. Ademas, el estado
del canal de comunicacion es caracterizado por el conjunto de
mensajes que transitan por
2.4 Computacion Distribuida y en Paralelo 13
el informando acerca de los nodos y los procesos que estan siendo
ejecutados en el sistema
distribuido.
A continuacion se identifican las capas que componen los sistemas
distribuidos.
2.4.1. Capa de Aplicacion
La capa de aplicacion se enfoca en los usuarios que, por lo
general, corresponden a areas
como la ciencia, negocio, ingeniera o finanzas. Para esta capa se
destaca el desarrollo de
aplicaciones que gestionen de forma eficiente los recursos de
computo y que no afecten el
rendimiento del sistema. En el diseno de aplicaciones se debe tener
en cuenta los recursos de
almacenamiento y de gestion de la memoria ya que estos dos tienen
un factor de correlacion
y tienen relacion con el tiempo de finalizacion de la tarea.
2.4.2. Capa Media
La capa media es un enlace entre la capa de aplicacion y de
recursos, proporcionando un
servicio de comunicacion, que analiza las tareas, programa las
tareas, y establece los parame-
tros de seguridad para acceso a los diferentes nodos. As mismo, se
establecen las estrategias
de procesamiento de informacion que son gestionadas en la capa
media, construyendo una
mejor gestion de los procesos de comunicacion entre las diferentes
capas.
2.4.3. Capa de Recursos
La capa de recursos establece la interaccion de los dispositivos de
hardware y el sistema ope-
rativo, es la capa responsable de controlar todos los recursos de
computo dentro del sistema
de computacion distribuida. Tambien, implementa mecanismos para un
mejor aprovecha-
miento de los recursos con los que cuenta cada uno de los nodos que
compone un sistema
distribuido.
14 2 Marco Teorico
2.4.4. Capa de Red
La capa de red es la encargada del enrutamiento y transferencia de
paquetes La red tiene
caractersticas para medir e identificar lo que esta pasando a los
largo de los equipos que tiene
conectados, los diferentes elementos activos que componen la
transferencia de informacion y
de procesos en un sistema distribuido.
En la figura 2-5 se presenta un grafico que ilustra las diferentes
capas de un sistema distri-
buido.
Figura 2-5.: Capas de un modelo de computacion distribuida. Fuente
[3]
2.5 Ejecucion Distribuida de Procesos 15
2.5. Ejecucion Distribuida de Procesos
En la ejecucion secuencial de acciones, donde estas acciones son
procesos que han sido mo-
delados, se pueden identificar tres tipos de eventos: eventos
internos, mensajes recibidos de
eventos y mensajes enviados de eventos. Los cambios de estado con
respecto a los procesos
y canales, causan una transicion en los estados globales del
sistema. En donde un evento
interno puede cambiar los estados de los procesos. Un envo de un
evento o recepcion, cambia
los estados de los procesos a enviado o recibido el mensaje y el
estado del canal queda con
el mensaje si es enviado o recibido. Adicional a esto se debe tener
en cuenta que en la ejecu-
cion de los procesos un evento interno solo afecta que los procesos
que actualmente ocurre[4].
Los procesos ocurren en orden de forma lineal, y en orden de
ocurrencia. Toda ejecucion de
procesos P produce una secuencia de eventos ei1, ei2, eix. . .
eix+1. Para el envo y recepcion
de eventos es necesario establecer un flujo de informacion entre
los procesos que establecen
la dependencia desde aquel que enva los procesos y el que recibe
los procesos. La relacion
es causal de la dependencia, debido a los intercambios de mensajes,
para cada uno de los
mensajes que se intercambian entre dos procesos o mas, se tiene una
dependencia entre los
eventos relacionados al envo y recepcion de mensajes [23].
La evolucion de la ejecucion de procesos distribuidos se hace en
tres fases, la primera donde
se van a representar os procesos, la segunda donde se establece la
indicacion de cada uno de
los eventos, y los eventos que son accionados por los mensajes. La
ejecucion de un proceso de-
terminado despliega eventos que toman un tiempo finito, como se
puede ver en la Figura 2-6.
16 2 Marco Teorico
Figura 2-6.: Representacion de los procesos y su distribucion por
eventos. Fuente [4]
En la computacion distribuida, dos eventos son concurrentes solo si
no se afectan entre s.
La concurrencia fsica es otra connotacion de eventos que ocurren en
un mismo instante de
tiempo. Entonces dos o mas eventos pueden ser concurrentes
localmente, pero esto no ocurre
en un mismo instante de tiempo fsico. El tiempo de ejecucion de los
mensajes puede tener
retardos debido a diferencia de velocidades del procesador o
cuellos de botella que aparecen
en el sistema distribuido. La logica concurrente de eventos no
ocurre en un mismo espacio
de tiempo fsico, para todas las practicas y propuestas teoricas, se
supone que los eventos
asociados a procesos ocurren en los mismos instantes de tiempo
fsico [3].
2.6. Modelo de Comunicacion Distribuida
Existen varios modelos acerca del servicio que se provee en las
redes de comunicacion, FIFO
(First-in, First-out), Non-FIFO, ordenamiento causal. Para el
modelo FIFO, el mensaje que
ingresa al canal es ordenado y preservado por el. En el Non-FIFO,
el canal actua como un
proceso que enva mensajes, y el receptor va almacenando los
mensajes y los va eliminando
de forma aleatoria.
El “Orden Causal” es un modelo basado en la relacion de Lamport
[4]. Un sistema que
soporta un orden causal debe satisfacer la siguiente propiedad:la
relacion de mensajes re-
lacionados con el destino se deben entregar en un orden consistente
con su relacion con la
2.7 Estado Global de un Sistema Distribuido 17
causalidad. El modelo de ordenamiento causal es util para el
desarrollo de algoritmos de
sistemas distribuidos, la simplificacion del diseno del algoritmos
distribuido permite proveer
una sincronizacion.
2.7. Estado Global de un Sistema Distribuido
El estado global de un sistema distribuido es el conjunto de
estados locales de los componentes
de un sistema, y de los procesos que se encuentran en los canales
de comunicacion. El
estado de los procesos esta definido por un tiempo que estan
contenidos en los registros
de un procesador y en la memoria local, entre otros. Este estado
depende del contexto de
la aplicacion distribuida, donde el estado del canal de transmision
se da de acuerdo a los
mensajes que transitan por el.
Los cambios en los estados de los eventos de los respectivos
procesos y canales, causan tran-
siciones a un estado global del sistema. Para la determinacion del
estado global es necesario
establecer la estrategia para determinar cada uno de los procesos
de los estados locales y
el estado de los canales de comunicacion. Los estados de todos los
componentes del sistema
distribuido son registrados en un mismo instante, esto se puede
realizar por medio de los
relojes locales, que tienen los procesos sincronizados con el
sistema global. La estrategia de
registrar cada uno de los envos determina que no todos se pueden
registrar al mismo tiempo
debido a que cada mensaje que es recibido debe ser procesado y
colocado en una cola de
mensajes. Los estados que componen un sistema distribuido se
comprenden como el estado
global consistente y se entiende como el significado global de los
estados [4].
El registro global de los estados es un problema importante en los
sistemas distribuidos,
por el analisis, monitoreo, pruebas o verificacion de las
aplicaciones distribuidas, sistemas
y algoritmos. Un diseno eficiente de los metodos de registro de
estados es una parte muy
importante de un sistema distribuido.
18 2 Marco Teorico
2.8. Modelo del Proceso de Comunicacion
Dentro de computacion distribuida existen dos modelos basicos para
el proceso de comunica-
cion [24][4], sncrono y asncrono. La comunicacion sncrona es un
modelo en donde el envo
de los mensajes se realiza por bloques hacia el receptor que
realiza los procesos. El emisor
inicia los procesos de ejecucion solo despues de recibir los
procesos con el mensaje aceptado.
As el transmisor recibe los procesos y debe sincronizar los
mensajes de intercambio.
La comunicacion asncrona es un modelo sin bloqueo donde el
transmisor y el receptor no
sincronizan el intercambio de mensajes, el proceso del transmisor
no espera que el mensaje
sea enviado para recibir los procesos. El mensaje queda en espera
por el sistema y es enviado
cuando el receptor esta disponible para aceptar el mensaje. Si la
cola de mensajes se llena,
ocurre que se los mensajes se pueden distribuir en rafaga a otro
proceso.
Los modelos de comunicacion distribuida se acomodan a la necesidad
que se desee solventar,
para el caso del modelo asncrono provee una estrategia para el
desarrollo de paralelismo,
debido a que el transmisor puede ejecutar eventos mientras que el
mensaje esta en transito
al receptor. Una de las complicaciones de la implementacion de una
comunicacion asncrona
es el requerimiento de una administracion compleja de la cola de
mensajes [4].
2.9. Algoritmos de Ejecucion Distribuida
La ejecucion distribuida de procesos se encuentra comprometida por
los procesos de co-
municacion. Estas estructuras de control se encuentran ubicadas en
la memoria, pero esta
implementacion no interfiere con la ejecucion de las tareas. Esta
ejecucion controla los even-
tos y la recepcion de los mensajes que permiten la ejecucion de la
aplicacion de algoritmos
distribuidos. As la ejecucion establece un rol equitativo para cada
procesador. El estado
local de los nodos de un sistema distribuido permite disenar una
estrategia y topologa que
permita usar cada uno de los recursos para solucionar determinados
procesos. A continuacion
se describen las estrategias utilizadas.
2.10 Sistema de Archivos Distribuido 19
2.9.1. Algoritmo Asimetrico
Un algoritmo asimetrico es el que permite ejecutar diferentes
tareas en procesadores diferen-
tes. Este tipo de algoritmo no es completamente distribuido,
establece una implementacion
cliente/servidor donde se establece una configuracion de arbol y
ejecucion de funciones o
tareas para cada uno de sus nodos. La cooperacion y los roles hace
que cada uno de ellos sea
necesario para la coordinacion de cada uno de sus nodos [25].
2.9.2. Algoritmos Anonimos
Los algoritmos anonimos son estrategias que no establecen
identificadores para sus procesos,
ni sus nodos, para poder tomar decisiones acerca de la ejecucion de
procesos de forma
distribuida. La identificacion del coordinador o lder se hace
compleja, por lo que se propone
una estructura de anillo debido a su carencia de identificadores.
Estos algoritmos tambien
se conocen como exclusion mutua en un sistema de memoria compartida
[25].
2.9.3. Algoritmos Uniformes
Estos algoritmos permiten la escalabilidad; los procesos asociados
a los nodos se pueden
unir o salir de la ejecucion sin comprometer otros procesos y son
capaces de acomodar la
topologa de forma inmediata. Esta estrategia tiene un modelo de
comunicacion con sus
vecinos de manera uniforme en forma de anillo logico que permita la
eleccion del lder [25].
2.10. Sistema de Archivos Distribuido
Un sistema de archivos distribuido se define como sistema de
archivos que se transmite
por red, esta es una abstraccion de un unico sistema de ficheros
que utilizando recursos
heterogeneos o homogeneas construyen un sistema de archivos
distribuido, logrando como
objetivo principal la escalabilidad y balanceo de la carga. Esto es
una parte importante
debido a que depende de la red, y con el uso de NFS (Network File
System) se convierte en
un cuello de botella cuando muchos nodos intentan acceder a muchos
archivos pertenecientes
al sistema de archivos distribuido [21].
20 2 Marco Teorico
El acceso paralelo a datos y sistemas altamente escalables
establecen una solucion optima
para la distribucion de informacion cuyo resultado es obtener un
muy alto rendimiento para
el procesos de grandes volumenes de datos. Los sistemas
centralizados son una opcion pero
su escalabilidad afecta el rendimiento de los sistemas de archivos,
ya que depende de un
unico punto para la distribucion de informacion.
3. Estado del Arte y Trabajo Previo
3.1. Condor
Condor es un sistema de computacion distribuida por lotes de alto
rendimiento que contem-
pla un conjunto de caractersticas basicas que cumplen los sistemas
que procesan basado en
lotes, tales como administracion de trabajos, polticas de
programacion de trabajos, esque-
ma de propiedades, monitor de recursos y administracion de recursos
[26]. Condor establece
como objetivo para los entornos de computacion de alto rendimiento,
una arquitectura de
computacion oportunista y de alto rendimiento, que permita utilizar
todos los recursos que
se encuentran a lo largo de la red de forma y usarlos en todos los
momentos que esten dis-
ponibles, sin establecer una regla de disponibilidad absoluta para
poder realizar el trabajo.
La estrategia de Condor divide en tres herramientas que implementan
las caractersticas
explicadas a continuacion [5]:
ClassAds: Es un lenguaje que provee Condor para la gestion de sus
recursos y sus trabajos.
Este lenguaje permite identificar los recursos, polticas y adicion
de nuevos nodos de compu-
to. Este ofrece gran flexibilidad para la gestion de los diferentes
componentes que propone
la arquitectura de Condor.
Job Checkpoint and Migration: Condor registra los diferentes puntos
de control, pa-
ra que estos puedan ser retomados por diferentes nodos. Esta
aplicacion toma puntos de
control de forma periodica, proporcionando una tolerancia a fallos
y guardando los tiempos
de calculo ejecutados. As mismo, permite que guardar puntos de
control y que estos sean
22 3 Estado del Arte y Trabajo Previo
migrados de una maquina a otra.
Remote System Calls: La ejecucion de procesos remotos permite
dirigir los procesos a
nodos externos, y permitir la redireccion de los trabajos E/S
(Entradas y Salidas) y, as
mismo, permitir el cambio de trabajos entre nodos, y realizarlos
con los archivos que esten
disponibles en las estaciones de trabajo.
La tecnologa de Condor y su arquitectura permite desplegarse en
cualquiera de las diferen-
tes aplicaciones de administracion de sistemas de computacion de
alto rendimiento, como se
puede observar en la Figura 3-1, los diferentes servicios que
ofrece Condor para los procesos
de computacion, su relacion con las caractersticas de los nodos y
el usuario con las aplica-
ciones [5].
Figura 3-1.: Diagrama de Condor y su ubicacion en la capa media de
la arquitectura.
Fuente [5]
3.2. Portable Batch System
Proporcionar un sistema que permita que permita administrar de
manera eficiente el hard-
ware y sistemas operativos. Para esto se desarrolla un sistema que
presenta un conjunto de
herramientas MAUI Scheduler y Portable Batch System (PBS). La
planificacion de proce-
sos basado en las polticas, en grandes sistemas de computo de
estable caractersticas como
reservas de recursos, establecer prioridades de los procesos,
seguimiento al envo de tareas
planificadas y aplicacion a polticas de seguridad.
PBS es un sistema desarrollado por la NASA para la administracion
de grandes multiples
procesos en paralelo, es compatible con arquitecturas de hardware
heterogeneas cuyo objetivo
es desarrollar el procesamiento de datos de forma paralela y
masiva. PBS tiene implementado
un metodo FIFO para la ejecucion de sus tareas permitiendo as mismo
la maxima utilizacion
de CPU, tambien permitiendo la asignacion de tareas a nodos que
sean compatibles con sus
recursos.
MAUI es un sistema de reserva de recursos de computo basado en el
tiempo, El sistema
ordena los trabajos basandose en la prioridad de los mismos, y se
inician basandose en los
trabajos que pueden ejecutar. El modelo basado en las prioridades
permite una ejecucion
temprana para una mejor asignacion de los tiempos de ejecucion y
proporcionando una me-
jor distribucion de los recursos de los trabajos con menor
prioridad. En la Figura 3-2 se
describe la diferencia entre PBS y MAUI [6].
24 3 Estado del Arte y Trabajo Previo
Figura 3-2.: Modelo ejecucion PBS FIFO y MAUI. Fuente [6]
3.3 Zookeeper 25
Las aplicaciones distribuidas a gran escala requieren diferentes
formas de coordinacion de re-
cursos, las diferentes asociaciones para nuevos miembros y lderes
de grupo de procesamiento
para la gestion de los mismos procesos. Para esto se establece la
necesidad de saber cuales
de sus procesos estan activos y en que estado se encuentran.
Zookeeper implementa la estra-
tegia que implementa un acceso mutuamente excluyente sobre las
fuentes de los recursos, la
coordinacion de se basa en la eleccion de los lderes y su
configuracion, en donde se expone
una API (Application Programming Interface) para la implementacion
de coordinacion de
tareas y establecer la coordinacion como nucleo de servicio y este
no requiera cambios de la
configuracion o sean facilmente desplegables de forma centralizada
[7].
La alta disponibilidad y replicacion de los datos propuesto por
Zookeeper establece que cada
nodo esta compuesto por un servicio, suponiendo que cuando un nodo
falle este servicio
pueda ser remplazado por un nuevo nodo. La solicitud de un nuevo
procesador o nodo se
establece cuando se realiza una solicitud para el procesamiento de
una nueva tarea identifi-
cando el estado de la tarea y calculando los recursos que deben ser
asignados para poderla
procesar. Para la identificacion y propagacion de los estados, se
identifican los nodos activos
entregando a cada uno de ellos informacion acerca de los procesos
que deben realizar esta-
bleciendo un quorum, que les permita coordinar y desarrollar su
proposito. Adicional a esto,
Zookeeper implementa una base de datos que es un mecanismo para
establecer puntos de
recuperacion en caso de tener algun dano a los largo del proceso.
Esta estrategia de servicio
se describe en la Figura 3-3.
26 3 Estado del Arte y Trabajo Previo
Figura 3-3.: Modelo del servicio ofrecido por Zookeeper. Fuente
[7]
3.4. Mesos
Mesos es una estrategia de intercambio de recursos que ofrece una
compatibilidad con multi-
ples frameworks de procesamiento masivo de datos, como Hadoop 1 o
MPI (Message Passing
Interface). El intercambio de estos recursos permite ubicar los
datos de forma local y que
estos sean almacenados en cada maquina para que sean procesados. El
diseno de Mesos pro-
pone un sistema escalable que soporte la concurrencia de diferentes
modelos de ejecucion
ofrecidos por frameworks de procesamiento masivo de datos. Mesos es
un administrador de
procesos centralizado que organiza las politicas de gestion de
recursos, y administra las ta-
reas de computo de forma global.
Mesos se compone de un nodo maestro que administra los recursos y
el intercambio entre
cada uno de los frameworks, as mismo identifica cada uno de los
nodos esclavos que existen
en el sistema y permite establecer la poltica de gestion de
recursos o prioridades para cada
uno de los nodos y ejecucion de tareas. En la arquitectura general
de Mesos se establecen
dos componentes: Scheduler, que administra la oferta de recursos y
Executor, que ejecuta
1”http://http://hadoop.apache.org”
3.5 Ceph 27
el lanzamiento de los procesos en los nodos esclavos. Para mas
detalle en la Figura 3-4 se
puede observar la arquitectura de Mesos [8].
Figura 3-4.: Arquitectura de procesamiento de Mesos. Fuente
[8]
3.5. Ceph
Ceph es un sistema de almacenamiento distribuido, el cual ofrece
una arquitectura dinamica
para el crecimiento y alta disponibilidad de la informacion.
Tambien, se aprovecha la separa-
cion entre los datos y los metadatos para realizar la reubicacion
implementando una funcion
de distribucion de datos pseudo-aleatoria disenada para clusters
heterogeneos, y presentan
sus datos por medio de objetos que se pueden consumir a lo largo de
la red. Adicionalmente,
se implementan estrategias como la replicacion de los datos,
deteccion de fallos, recuperacion
de sistemas semiautonomos y proponen un sistema de almacenamiento
distribuido especia-
lizado.
El diseno de una interfaz compatible con sistemas operativos POSIX
establece una relacion
entre el rendimiento y la comunicacion con el sistema operativo de
forma nativa. El objetivo
28 3 Estado del Arte y Trabajo Previo
principal de la arquitectura propuesta por Ceph es la alta
escalabilidad y el rendimiento
al acceso de datos para los clientes; las cargas de trabajo
asociadas al almacenamiento y
distribucion de informacion se acomodan a los diferentes procesos
de computacion cientfi-
ca, a procesos totalmente dinamicos. Esto significa una variacion
entre el acceso de datos y
meta-datos aplicados a lo largo del tiempo de ejecucion. En la
Figura 3-5 se puede observar
la arquitectura [27].
Las estrategias implementadas para el almacenamiento de datos se
dividen en tres partes,
Desacople de Datos y Meta-datos - Delegacion al bajo nivel del
almacenamiento para deter-
minar la ubicacion de los datos en dispositivos individuales,
Distribucion y Administracion
Dinamica de Meta-datos - La utilizacion de una arquitectura basada
en la particion dinamica
de subarboles permite distribuir de forma inteligente los
directorios, mejorando as la carga
de trabajo de los diferentes nodos; Confianza para la Distribucion
y Almacenamiento de Ob-
jetos - Sistemas extensos compuestos por miles de dispositivos
incrementan la posibilidad de
fallo, la distribucion de meta-datos permite ejecutar migracion de
datos, deteccion de fallos
y recuperacion de los objetos en caso de fallo [9].
Figura 3-5.: Arquitectua de Ceph y distribucion de datos y
Meta-datos. Fuente [9]
3.6 Lustre 29
Lustre como sistema de archivos distribuido ofrece una arquitectura
distribuida que faci-
lita la administracion y las operaciones generales de un
almacenamiento. Lustre funciona
en sistemas heterogeneos de almacenamiento propone multiples
servidores que almacenen la
meta-data y servidores de almacenamiento de objetos que permiten
integrarse con sistemas
POSIX e implementacion de niveles de seguridad usando el protocolo
LDAP (Lightweight
Directory Access Protocol) para la gestion de acceso a los
datos.
La arquitectura de Lustre establece un diseno entre el rendimiento
y la disponibilidad de los
datos, Lustre ofrece un sistema de archivos que soporta todas las
operaciones tradicionales de
busqueda, creacion y manipulacion de archivos, Lustre implementa un
modelo de extraccion
de meta-datos y de distribucion de almacenamiento de objetos.
Lustre tambien ofrece una
API para el procesamiento de datos y la comunicacion con la capa de
abstraccion de red
que integra con los dispositivos de comunicacion. En la Figura 3-6
se puede ver en detalle
la arquitectura que ofrece Lustre [10].
30 3 Estado del Arte y Trabajo Previo
Figura 3-6.: Arquitectura de Lustre. Fuente [10]
4. Identificacion del Problema
4.1. Planteamiento del problema
Las herramientas que existen para procesamiento y almacenamiento de
informacion de for-
ma distribuida enfrentan un reto a la hora de ser integradas,
incorporando cada una de las
caractersticas como son: la distribucion eficiente de los datos en
los diferentes centros de
investigacion, as como la integracion de los multiples recursos de
procesamiento y almace-
namiento heterogeneos que poseen dichos centros. Para estos
elementos no existen modelos
de integracion optimos para el procesamiento o el envo de datos
hacia diferentes puntos de
procesamiento de informacion.
Desarrollar una plataforma para la distribucion y procesamiento
distribuido de datos biologi-
cos a partir de la integracion de herramientas disponibles.
4.2.2. Objetivos Especficos
Comparar y evaluar las diferentes tecnologas de distribucion y
procesamiento de in-
formacion distribuida.
Disenar una estrategia para la ejecucion de flujos de procesamiento
distribuido.
32 4 Identificacion del Problema
4.3. Metodologa
Se debe realizar la integracion de herramientas para el desarrollo
de una plataforma que reali-
ce el almacenamiento y el procesamiento distribuido para
desarrollar tareas de procesamiento
de datos biologicos, generando as una mejor utilizacion de los
recursos y la integracion de
herramientas de procesamiento y distribucion de datos de tipo
biologico.
1. Para contextualizar y conocer el estado del arte, es necesario
identificar las diferentes
tecnologas de distribucion y procesamiento de informacion
distribuida en analisis de
datos biologicos, que comprenden la programacion de servicios y
programacion distri-
buida tales como Mesos, Apache Zookeeper y PBS.
Entregables: un analisis de herramientas de distribucion y
procesamiento de infor-
macion distribuida, que permitan ser integrados a herramientas
bioinformaticas y al
analisis de datos biologicos.
Desarrollo de la fase: Desarrollo del estado del arte,
actualizacion bibliografica de lite-
ratura de referencia consultada, y usada para el desarrollo del
proyecto.
2. Evaluar cada una de las caractersticas de un sistema de
computacion distribuido para
el almacenamiento de datos de tipo biologico, contemplando
herramientas como Ceph,
Lustre.
Hipotesis: Se debe determinar un conjunto de datos biologicos que
permita realizar la
evaluacion de modelos de almacenamiento de datos de acuerdo al
analisis realizado.
Experimentos: Evaluar un grupo de tecnologas de distribucion de
datos contrastando-
los con las caractersticas de los datos provenientes de
secuenciacion para determinar
cual ofrece mejor interaccion con elementos de computacion y
almacenamiento de in-
formacion para sistemas distribuida.
Desarrollo de la fase: Analizar y contrastar las diferentes
herramientas que permite
establecer los procedimientos para la distribucion de datos e
implementar la solucion
seleccionando la mejor opcion para los datos provenientes de
secuenciacion.
3. Analizar las tecnologas de procesamiento de informacion sobre
herramientas de anali-
4.3 Metodologa 33
caciones para usarse como herramientas de procesamiento de la
informacion.
Experimentos: Identificar las posibles aplicaciones y/o estrategias
que permitan solu-
cionar los problemas de procesamiento de informacion y su
aplicacion en entornos de
computacion distribuida.
Desarrollo de la fase: solucion de computo que permita analizar
datos biologicos para
realizar analisis de datos de tipo biologicos con herramientas
bioinformaticas.
4. Desarrollo de una plataforma de almacenamiento y procesamiento
distribuido para
analisis de datos biologicos. Esta se desarrollara para datos de
genomica y trans-
criptomica.
Desarrollo de la fase: Desarrollar e integrar herramientas para le
implementacion de la
plataforma de analisis y distribucion de datos.
Metodologa. La metodologa se presenta para la validacion de cada
una de las partes pro-
puestas. Iniciando desde las capa de almacenamiento de informacion,
seguido por la capa de
procesamiento y de comunicacion de cada uno de los elementos, y
interconexion de cada una
de las tecnologia involucradas.
Plataforma Propuesta
tualmente en el despliegue de soluciones de almacenamiento
distribuido ofrecen multiples
caractersticas y se evaluan de acuerdo a los siguientes criterios
[28] [23]:
Compatibilidad con POSIX: La compatibilidad con sistemas POSIX
ofrece una integra-
cion con los diferentes sistemas operativos basados en el estandar
POSIX, implemen-
tado cada una de las caractersticas del sistema operativo y
ofreciendo una integracion
nativa.
Sistema de Archivos y/o limitacion del tamano de archivos: El
sistema de archivos
para los sistemas de archivos distribuidos establece la capacidad
de poder acceder
a un mismo archivo desde diferentes nodos y que este no afecte la
integridad de la
informacion, el lmite de tamano establece la capacidad para la
creacion y la gestion
de archivos.
Separacion de Metadatos: Todos los datos que son almacenados en el
sistema distri-
buido deben ser clasificados basado en la extraccion de
meta-datos
Almacenamiento de Objetos basado en sistemas de almacenamiento de
bloques: Siste-
ma de distribucion de archivos a alto nivel para proveer la
informacion acerca de los
objetos almacenados y su relacion con los meta-datos, implementado
una estrategia
5.1 Almacenamiento Distribuido 35
de distribucion de datos para aumentar la disponibilidad de los
objetos con una escala
lineal.
Replicacion de Datos: La distribucion de los datos permite mejorar
la confiabilidad
y disponibilidad de la informacion, de la misma forma el
rendimiento y velocidad de
acceso a la informacion se ve optimizado por la estrategia de
replicacion y entrega de
datos.
Tolerancia a Fallos: En caso que las unidades de almacenamiento
fallen, los datos deben
ser reubicados en nuevos dispositivos, sin que la disponibilidad y
confiabilidad de la
informacion se vea afectada.
Administracion del particionamiento dinamico de sub arboles: Los
metadatos repre-
sentan un papel importante en el rendimiento y almacenamiento
masivo; el particio-
namiento dinamicos de subarboles propone un modelo de equilibrio en
la distribucion
de los metadatos, y una estrategia dinamica para la administracion
de los sub-arboles.
Los sistemas de almacenamiento distribuido (Distributed File
Systems - DFS) son altamente
escalables, confiables y ofrecen un excelente rendimiento. Las
nuevas estrategias de almacena-
miento demandan que soporten grandes tamanos de datos y que
permitan un acceso paralelo
a la informacion desde multiples clientes. La arquitectura del
sistema distribuido debe pro-
veer un conjunto de elementos que promuevan el uso intensivo, la
fiabilidad y disponibilidad
de los datos evaluando los criterios descritos en la tabla
5-1:
36 5 Evaluacion de Tecnologas para la Plataforma Propuesta
Tabla 5-1.: Tabla comparativa para almacenamiento
distribuido.
CEPH Lustre
Sistema de Archivos y/o
Cumple Con
Almacenamiento de Objetos basado en
sistemas de almacenamiento de bloques Cumple Cumple
Replicacion de Datos Cumple Cumple
Tolerancia a fallos Cumple Cumple
Administracion del particionamiento
dinamico de sub-arboles Cumple No Cumple
Del analisis se puede concluir que las dos herramientas son muy
competitivas y ofrecen
caractersticas similares. Para la implementacion de un
almacenamiento distribuido se opta
por el uso de Ceph por su modelo centralizado para la gestion de
sistema de archivos.
5.2. Procesamiento Distribuido
Para la evaluacion de las diferentes herramientas de procesamiento
distribuido se seleccio-
naron las que actualmente ofrecen multiples caractersticas del
procesamiento de datos y se
evaluan de acuerdo a los siguientes criterios [24] [29]:
Reubicacion de Recursos: Las aplicaciones deben aplicar estrategias
de reubicacion de
recursos que permitan la ejecucion de las tareas evitando la
perdida de informacion y
generando puntos de retorno.
Aislamiento de Procesos: Cada proceso que es ejecutado puede ser
aislado para lograr
un mejor control de la cantidad de procesadores asignados para la
ejecucion de una
5.2 Procesamiento Distribuido 37
tarea, la cantidad de memoria RAM asignada, gestionar el acceso a
la red, y administrar
las caractersticas de almacenamiento.
Escalabilidad: La adicion de nuevos nodos a la arquitectura de
computacion distribuida
es una de las cualidades de un sistema distribuido, permitiendo el
incremento de los
recursos disponibles para el desarrollo de las tareas.
Tolerancia a Fallos: En caso que los nodos fallen, las tareas deben
ser reasignadas a
nuevos nodos sin que estas se vean afectadas o interrumpidas.
Administrador de Tareas: La estrategia de administrar las multiples
tareas que se
envan a un sistema distribuido asignando las prioridades de
ejecucion y controlando
las entradas y salidas de cada uno de los procesos, para que estos
de la misma forma
puedan ser ejecutados de forma paralela a lo largo de la
arquitectura del sistema.
A continuacion se presenta en la Tabla 5-1 la comparacion de
diferentes estrategias de
procesamiento distribuido.
PBS Mesos Condor Zookeeper
Escalabilidad Cumple Cumple Cumple Cumple
Tolerancia a Fallos Cumple Cumple Cumple Cumple
Administrador de Tareas Cumple Cumple Parcialmente Cumple
Cumple
De acuerdo a la evaluacion realizada de los diferentes modelos de
procesamiento distribuido,
el que se considero mas innovador fue Mesos que incluye procesos
que facilitan la integracion
con herramientas de software, y su orientacion a los servicios
permite la ejecucion de tareas
con contenedores facilitando un sistema distribuido altamente
dinamico y que aprovecha de
mejor manera los recursos de computo que se tienen a
disposicion.
6. Construccion de la Plataforma
6.1. Arquitectura de la Plataforma
La arquitectura de Master Distribution Task (MDT) busca establecer
una forma de contro-
lar los procesos que son ejecutados por un flujo de procesamiento
computacional (workflow)
utilizando los recursos de computo que se tienen en cada uno de los
nodos que hacen parte
de un sistema distribuido, o que este sea capaz de resolver el
flujo de procesamiento en un
unico nodo buscando que el tiempo de ejecucion sea el menor posible
[30]. La utilizacion
de caractersticas de los sistemas operativos para que realicen
operaciones en BATCH o de
procesamiento por lotes que no requieren de un seguimiento por
parte del usuario permite,
asmismo, reducir la cantidad de operaciones que son necesarias para
realizar una accion
sobre un programa especifico. De igual manera, permiten disenar un
conjunto de funciones
que faciliten la implementacion de funciones del sistema
distribuido como asignacion de re-
cursos, aislamiento de tareas, y tolerar fallos o permitir el
monitoreo de los recursos y los
trabajos que se encuentran en ejecucion [31]. La adaptacion de
recursos de computo que se
tienen en la computacion distribuida con MDT permite trasladar este
modelo a la nube [22],
proporcionando una arquitectura flexible que esta caracterizada por
la ubicacion de recursos,
aislamiento, contenedores y la tolerancia a fallos, los cuales se
describen a continuacion.
6.2. Ubicacion de Recursos
La organizacion y la ubicacion se da de acuerdo a las necesidades
del flujo de procesamiento
o del programa que se desea ejecutar. Se propone usar el modelo DRF
(Dominant Resources
6.3 Aislamiento 39
Fairness) [29] que en un inicio esta basado en la ejecucion de
tareas MapReduce, un modelo
basado en la ejecucion de tareas Hadoop [8]. Con este algoritmo se
priorizan los recursos que
se pueden utilizar, pero al utilizar programas para el
procesamiento de informacion que no
estan optimizados para la ejecucion de entornos en paralelo estas
aplicaciones no paraleliza-
das no aprovecha las caractersticas de DRF. La variacion de los
tiempos se da porque no es
posible intercambiar los recursos de computo durante la ejecucion
del flujo de procesamiento
de datos. El objetivo del algoritmo es lograr una mejor asignacion
de los recursos disponibles,
como factor importante cada uno de los recursos de los nodos pueden
ser heterogeneos y las
demandas de los mismos pueden ser heterogeneas debido a los
trabajos que se deben realizar
[32] [8] [29].
6.3. Aislamiento
El aislamiento de los recursos de los recursos de computo sin
necesidad de recurrir a la
virtualizacion por medio de contenedores, permite trasladar
caractersticas de los programas
en cada uno de los nodos y lograr el aislamiento con mecanismos
nativos que existen desde la
capa del sistema operativo. Con la tecnologa de aislamiento de
recursos es posible controlar
la CPU,la memoria RAM, el ancho de banda y el acceso a dispositivos
de almacenamiento
[33]. El emplear esta tecnologa hace posible una mejor gestion de
los recursos de cada uno
de los nodos, as mismo la creacion de multiples contenedores para
la ejecucion de multiples
tareas en un solo nodo es una solucion pensada de un solo
contenedor a muchos por nodo.
6.4. Contenedores
En este caso, un contenedor se usara como un espacio que facilita
el desarrollo y distribucion
de la imagen que contienen los recursos necesarios como
herramientas, datos, o parte de la
estructura del flujo de procesamiento. El facilitar el uso de los
recursos de computo basado en
la creacion de contenedores permite la gestion de las herramientas
necesarias y controlar ca-
da una de las versiones que facilite la ejecucion de las diferentes
tareas de procesamiento. La
40 6 Construccion de la Plataforma
utilizacion de contenedores facilita la reproduccion de los
entornos de ejecucion que se tienen
localmente y facilitar el movimiento hacia el sistema distribuido
para que MDT tenga lis-
tas las herramientas que permiten la ejecucion de los procesos del
flujo de procesamiento [33].
6.5. Tolerancia a Fallos
Para MDT dependiendo el estado en que se encuentre el nodo se puede
establecer la ejecucion
de las tareas asignadas al sistema distribuido, el nodo maestro a
administrador determina los
estados y la cantidad de recursos que se tienen disponibles y si es
capaz de gestionar nuevas
tareas [32] [34]; solo existe un nodo maestro que es aquel que
puede gobernar a los demas
y decidir que procesos deben estar ejecutandose, si este llega a
fallar los nodos esclavos
terminan los trabajos, pero no pueden continuar con la ejecucion de
las tareas siguientes
debido a que no se pudo informar acerca del nuevo estado del nodo.
El modelo de asignacion
aislado para cada una de las tareas permite una facil aplicacion de
las mismas cuando un
nodo falle, permitiendo al nodo maestro un rebalanceo de cargas. De
la misma forma en la
que el modo de recuperacion de fallos, la adicion de un nuevo nodo
al sistema permitiendo
crecer de forma dinamica y transparente.
6.6. Modelo Computacional
Para el modelo computacional propuesto se aborda una estrategia
para asignar los nodos y
los recursos cuando un mismo programa debe ser ejecutado al mismo
tiempo o se puedan
ejecutar varios programas en un mismo instante, recogiendo los
resultados de los procesos
para que puedan ser presentados al usuario final. La estrategia de
MDT es una combinacion
entre el algoritmo de programacion de tareas de P-HEFT [35, 36], el
cual esta implementado
en el uso de grafos dirigidos [37] [38] y la administracion de
recursos con DRF [29] [39], las
cuales se utilizaron como elementos de inspiracion para el
desarrollo de MDT. A continuacion
se presenta el algoritmo:
6.6 Modelo Computacional 41
Set StateNodes
Set VectorTask
Set ComputeTask
CalculateCapacity(DistributedSystems)
ReedAllStates(Nodes)
SendDataStatus(Monitor)
Task ←AssignTask(Node)
6.7. Modelos de Estados
Los estados que incluyen MDT establecen la disponibilidad de cada
uno de los nodos y
permite una nueva asignacion de las tareas que deben ser asignadas
a cada uno de los nodos;
estos estados permiten controlar cada unos los procesos que deben
estar funcionando en cada
uno de los nodos [32]. A continuacion se describen los estados que
se encuentran en MDT:
Available: para indicar que el nodo esta disponible para que nuevas
tareas puedan ser
asignadas.
Error: Indica cuando el nodo no pudo terminar la tarea que le fue
asignada y esta
pendiente de revision por parte del usuario para que pueda
verificar y realizar las
acciones pertinentes.
Running: Actualmente se encuentra funcionando una tarea en el nodo
y este se en-
cuentra ocupado y no puede procesar una tarea nueva, a menos que el
informe de la
maquina permite establecer que debido al aislamiento de procesos se
tienen recursos
disponibles.
Success: este estado permite determinar que una de las tareas del
nodo a cabo sin
errores, y dara paso a la siguiente tarea o a la finalizacion del
flujo del procesamiento
de datos.
Figura 6-1.: Arquitectura de la Plataforma. Elaboracion
Propia
El administrador de mensajes permite conocer los estados de los
nodos y permite desarrollar
la estrategia de computacion distribuida la cual permite la
ejecucion de flujos de informacion
[40]. En la Figura 6-1 se puede observar como el administrador de
mensajes es el elemento
que tiene la capacidad de conectarse a los nodos y de asignar cada
una de las nuevas tareas,
de acuerdo al estado de los nodos. Los estados de los nodos
permiten desarrollar la estrategia
que MDT propone y a su vez permite controlar en cada una de las
capas antes descritas en
la arquitectura.
Distribucion de Procesos
7.1. Arquitectura
La arquitectura propuesta para el desarrollo de la solucion es
centralizada compuesta por
un modelo cliente-servidor, de tal manera que permita la conexion
de los diferentes nodos
que se esten asociados al sistema distribuido, con un
almacenamiento centralizado y comun
para todo el sistema, asociado a los nodos que van a realizar todas
las operaciones del
procesamiento de informacion.
El lenguaje de programacion para el desarrollo del proyecto es
Python y las siguientes he-
rramientas tecnologicas que apoyan la implementacion de la solucion
:
ZeroMQ: Librera de mensajera asncrona para interconectar servicios
de alto ren-
dimiento destinada para el uso de aplicaciones distribuidas,
ademas, proporciona un
manejo para la cola de mensajes generadas por los sistemas
[41].
Docker: Herramienta para la distribucion de contenedores, y
orquestacion de las tareas
que se proporcionan.[33]
Python-Docker: Librera de python para la gestion y control de los
procesos de Docker.1
Python-Diamond: Librera de python la captura de informacion sobre
la cantidad y
uso de los recursos de los nodos 2.
1”https://github.com/docker/docker-py”
2”https://github.com/python-diamond/Diamond”
BioContainer: Directorio de codigo abierto orientado a proporcionar
contenedores es-
pecializados con software bioinformatico [42].
Ceph: Herramienta para la implementacion de almacenamiento
distribuido implemen-
tando almacenamiento de objetos y estrategia de replicacion de
datos [9].
Python-Rados: Librera de python para la gestion y control del
almacenamiento con
Ceph 3.
7.2. Modelo de Clases
El modelo de clases disenado para el proyecto esta definido por un
conjunto de clases que
construyen el servidor del sistema distribuido el que administra a
los otros nodos, y las clases
pertenecientes a los componentes de los nodos clientes. Se
desarrollo el siguiente modelo de
clases que identifica los servicios en la arquitectura para el
servidor y para cliente en la
Figura 7-1:
3”https://pypi.org/project/cradox/”
46 7 Construccion de un Prototipo Para la Distribucion de
Procesos
Figura 7-1.: Modelo de Clases. Elaboracion Propia
7.3 Modelo de Despliegue 47
7.3. Modelo de Despliegue
El modelo de despliegue describe los componentes de infraestructura
definida para la imple-
mentacion del prototipo, indicando el servidor, los nodos clientes,
y el almacenamiento. Para
este caso, del desarrollo de una plataforma de procesamiento de
datos biologicos.
Los componentes tecnologicos utilizados para la implementacion de
la plataforma son:
Figura 7-2.: Modelo de Despliegue. Elaboracion Propia
Nodo Servidor: que tiene la capacidad de conectarse a los clientes
a realizar consultas
acerca de los procesos que se estan ejecutando, administra los
trabajos y cuantifica los
recursos que tiene disponibles.
Nodo Cliente: Administra los procesos y los asocia a los
contenedores, construyendo los
contenedores y consumiendo la informacion del sistema de
almacenamiento distribuido.
48 7 Construccion de un Prototipo Para la Distribucion de
Procesos
7.4. Modelo de Prueba
Para validar el modelo propuesto se propone utilizar un flujo de
procesamiento computacio-
nal basado en un analisis bioinformatico para datos de ARN, el cual
incluye varias estapas
del analisis de datos bioinformaticos y herramientas
bioinformaticas. Este analisis contem-
pla los pasos desde el ensamblaje de un transcriptoma hasta obtener
el analisis de expresion
diferencial del conjunto de experimentos.
Para la prueba se propone un modelo publicado nombrado SPARTA [11],
el cual se compone
por un conjunto de fases que realiza el preprocesamiento de los
datos de transcriptomica, el
ensamblaje del transcriptomica, y el analisis del transcriptoma.
con un conjunto de datos de
alrededor de 20 muestras [43]. En la Figura 7-3 se presenta el
modelo descrito por SPARTA
para la realizacion de analisis de RNA-Seq.
7.4 Modelo de Prueba 49
Figura 7-3.: Modelo de procesamiento de datos de RNASeq propuesto
por SPARTA. Fuente
[11]
Las herramientas utilizadas para el procesamiento de analisis
bioinformatico para RNASeq:
FastQC: Herramienta para realizar control de calidad a los datos
provenientes de se-
cuenciamiento como paso previo a los analisis bioinformaticos
[44].
Trimmomatic: Es una herramienta para limpiar y recortar datos
provenientes de illu-
mina en formato FASTQ, y eliminar adaptadores que quedan
resultantes del proceso
de secuenciamiento [45].
Bowtie: Herramienta para el alineamiento de genomas con capacidad
de procesamiento
50 7 Construccion de un Prototipo Para la Distribucion de
Procesos
multihilo para aumentar el rendimiento de la herramienta
[46].
HTSeq: Herramienta para el analisis de datos provenientes de
tecnologas de secuencia-
miento de organismos, obteniendo estadsticas sobre la calidad de
los datos, asignacion
de lecturas para experimentos de RNA-Seq [47].
edgeR: Herramienta construida en R para el analisis de expresion
diferencial en datos
de RNA-Seq.[48]
7.5. Descripcion de los Datos
Los datos utilizados para el experimento pertenecen a un conjunto
de muestras clnicas rea-
lizadas a personas diagnosticadas con tuberculosis, enfermedad
causada por la infeccion con
Mycobacterium tuberculosis. Estos datos de la muestra se encuentran
en estado de latencia y
de virulencia. Ademas, este conjunto de datos permite evaluar el
desarrollo de la propuesta
por las caractersticas de su tamano, y se ajustan al flujo de
procesamiento seleccionado. En
la tabla 7-1 se muestra la descripcion de los datos.
Tabla 7-1.: Descripcion de los datos usado para la prueba.
Codigo ENA Nombre de
Estrategia de
la Librera
Cantidad de
ERS205794 N0153 2 Illumina HiSeq 2000 RNA-Seq 115,985,479
ERS205796 N0145 Illumina HiSeq 2000 RNA-Seq 94,603,410
ERS205791 N0145 2 Illumina HiSeq 2000 RNA-Seq 32,446,204
ERS205795 N0031 Illumina HiSeq 2000 RNA-Seq 75,462,206
ERS205787 N0031 2 Illumina HiSeq 2000 RNA-Seq 30,072,101
ERS205799 N0052 Illumina HiSeq 2000 RNA-Seq 285,676,121
7.6 Desarrollo 51
7.6. Desarrollo
La Universidad Nacional de Colombia en la sede Bogota cuenta con
equipos de computo que
se utilizan para la ejecucion de simulaciones y de diferentes
procesos de computo asociados a
las investigaciones de sus estudiantes. Estos equipos conforman un
poder de procesamiento
de computo que unidos todos sus nodos mediante sistemas
distribuidos se puede construir
una unidad de procesamiento y almacenamiento distribuido de
informacion eficiente para
dar solucion a diferentes problemas de investigacion.
Se desarrolla un ambiente para realizar las pruebas compuesto por 6
nodos de computo,
todos ellos conectados por una de red de 1Gb/s, un espacio de
almacenamiento por red de
4 TeraBytes conectado a la red de datos a 4 Gb/s, conformado por
cuatro enlaces de un 1
Gb/s por medio de agregacion.
7.6.1. Desccripcion del Hardware Usado Para la Prueba
Nodo Maestro:
• Core: 8
• Disco Duro: 70 GigaBytes
Software Desplegado en el nodo maestro:
• MDT Servidor
• Servidor Ceph
Nodos Esclavos:
• Cores:8
52 7 Construccion de un Prototipo Para la Distribucion de
Procesos
• Memoria: 32 GB de Ram
• Almacenamiento 7 TeraBytes
Software Desplegado en los nodos esclavos:
• MDT Cliente
7.7. Recoleccion de los Datos
Como mecanismo de recoleccion de datos se implementaron dos
herramientas que permi-
ten realizar registro al uso de los recursos de los diferentes
sistemas operativos analizando,
recolectando la siguiente informacion:
Informacion de la CPU
Informacion de la memoria
7.7.1. Herramientas
Nmon4: Esta es una herramienta que permite capturar informacion
acerca del rendimiento
del sistema, y ofrece elementos de referencia para la extraccion de
informacion, as como
programar tiempos de recoleccion de datos.
4”http://nmon.sourceforge.net/pmwiki.php”
7.8 Resultados 53
Sysstat5: Es una solucion de software que contiene varias
utilidades que permite supervisar
el rendimiento del sistema y la actividad de uso del sistema, y
tambien guardar informacipon
historica de las actividades y rendimientos del mismo.
7.8. Resultados
Se realiza el despliegue de MDT, se ejecuta el flujo de
procesamiento SPARTA bajo el modelo
distribuido propuesto que permita la distribucion de los procesos,
en donde se evaluaron los
componentes de Red, eficiencia de uso del almacenamiento y uso del
procesamiento, de cada
uno de los nodos que se destinaron para la prueba.
Del comportamiento se pudo observar que cada uno de los nodos a
nivel de procesamiento
se aprovecha en un gran porcentaje la disponibilidad del procesador
que tiene cada nodo.
Por parte del almacenamiento distribuido se logra observar como el
uso eficiente de los objetos
presentados por Ceph para el consumo de cada uno de los nodos y
comportamiento de la
red para la entrega de informacion y capacidad de escritura de cada
uno de los procesos. Los
contenedores permiten desplegar y controlar las herramientas de
analisis de forma estandar,
ofreciendo portabilidad para un facil despliegue del software a lo
largo del sistema distribuido.
Los resultados obtenidos con base en la ejecucion del proceso se
presentan a continuacion:
5”https://github.com/sysstat/sysstat”
54 7 Construccion de un Prototipo Para la Distribucion de
Procesos
7.8.1. Tiempo de Ejecucion por Experimento
El tiempo de ejecucion de las diferentes fases del flujo de
procesamiento de informacion para
RNA-Seq permite identificar que a mayor tamano de los datos aumenta
la complejidad del
proceso y volumen de los datos. Esto establece una oportunidad para
la distribucion de
procesos en un sistema distribuido y aprovechar el diseno de
diferentes fases para mejorar el
proceso de analisis de datos y obtener de forma mas rapida los
resultados.
Figura 7-4.: Tiempo de ejecucion por experimento en horas y las
fases que cada conjunto
de datos tarda en ejecutarlo.
7.8.2. Tiempo de Ejecucion Total
Los tiempos de ejecucion se midieron en 6 nodos que se dispusieron
para realizar la validacion
de la plataforma. Se obtuvieron los tiempos totales de
procesamiento invertidos por nodo
para el procesamiento de la informacion. Se observa que el Nodo 1
tiene mas carga debido
a que se le asignaron tareas mas largas del conjunto de datos del
grupo de transcriptomas
N0052.
Figura 7-5.: Cantidad de horas usadas por nodo. Elaboracion
Propia
7.8.3. Trafico de Red Generado
Para la medicion del trafico de red se contemplo la transferencia
de informacion entre el
almacenamiento distribuido y los nodos durante los das de la prueba
de la plataforma,
evidenciando el alto consumo de la red, esto es debido al acceso a
los datos y los objetos
que se realiza de forma constate al almacenamiento distribuido,
para la realizacion de las
diferentes fases de analisis de datos.
56 7 Construccion de un Prototipo Para la Distribucion de
Procesos
Figura 7-6.: Trafico de Red generado por nodo y da.
7.8.4. Uso de la Memoria Promedio
La medicion de memoria se realiza para establecer el estado de la
misma a lo largo de los
procesos durante los das de la prueba, se observa un uso constante
del recurso de memoria,
y una sobre carga en el Nodo 1, esto debido a la asignacion de
algunas de las tareas de los
datos secuenciados del set N0052, dado que tiene la mayor cantidad
de lecturas, y lo vuelve
un proceso complejo a la hora de realizar un analisis sobre ese
conjunto de datos.
7.8 Resultados 57
Figura 7-7.: Porcentaje de memoria usada por Nodo y Da. Elaboracion
Propia
7.8.5. Uso del Procesamiento Promedio
La medicion de consumo de procesamiento se realiza con medicion de
porcentaje de uso
del procesador, contrastando con los das que estuvo activo el
proceso de analisis de datos
provenientes de secuenciamiento. Se observa que el nodo 1 fue el
que obtuvo mas tiempo
con carga de procesos, debido a que la fase de cuantificacion de
niveles de expresion lleva un
proceso mas complejo.
58 7 Construccion de un Prototipo Para la Distribucion de
Procesos
Figura 7-8.: Porcentaje de procesamiento por nodo y da.
7.8.6. Uso del Almacenamiento Promedio
El almacenamiento de los datos se contempla desde el estado
inicial, con los datos en crudo,
provenientes del repositorio de Array Express del EBI 6. Despues
del analisis bionformatico,
estos datos comienzan a ocupar mas espacio, resultado de las
diferentes fases del procesa-
miento de informacion. As mismo, se generan grandes bloques de
informacion que afectan
al rendimiento y generan latencia en el transporte de
informacion.
6”https://www.ebi.ac.uk/arrayexpress/experiments/E-MTAB-1446/samples/”
8. Conclusiones y Recomendaciones
8.1. Conclusiones
En este trabajo se desarrollo una plataforma distribuida, la cual
se demostro que era ade-
cuada para el procesamiento de datos, debido a la portabilidad de
software que ofrecen los
contenedores y las caractersticas de gestion y control de recursos
de que se obtiene con esta
tecnologa, logrando usar de manera mas eficiente los recursos de
computo que se tienen a
disposicion.
En la implementacion del almacenamiento distribuido se observa la
alta generacion de trafico
debido a la centralizacion del almacenamiento, pero los objetos
permite un balanceo de la
informacion y as mismo las conexiones de 1 Gbp/s tienen un
comportamiento estable con
Ceph.
En las pruebas realizadas con el flujo de procesamiento de
informacion de RNA-Seq se pudo
observar una mayor eficiencia en el tiempo de procesamiento de
informacion debido a la
distribucion de tareas que se propuso en la plataforma.
La plataforma propuesta para procesamiento distribuido mostro ser
confiable a la hora de
trabajar con datos biologicos, la plataforma propuesta tiene un
comportamiento estable y
eficiente en las pruebas. Esto se evidencion a traves de las
diferentes pruebas que se reali-
zaron y por la evaluacion de componentes del sistema a nivel de
hardware y sistema operativo.
8.2 Alcances y Limitaciones 61
Las tecnologas de almacenamiento distribuido y estrategias para el
procesamiento de infor-
macion distribuida ofrecen una alternativa de herramientas de
software para el procesamiento
de datos provenientes del secuenciamiento de informacion de
organismos, se requiere para
esto de una adaptacion de las herramientas y una estrategia de
centralizacion de informacion.
8.2. Alcances y Limitaciones
La plataforma MDT debe mejorar en cuanto a su capacidad de
adicionar nuevos nodos al sis-
tema distribuido permitiendo facilidad a la hora de crecer el
sistema. Ademas, la evaluacion
de la arquitectura centralizada tiene un punto falla, para esto una
estrategia de coordina-
dores delegados en caso de fallo permitira establecer un nuevo
coordinador y mitigar este
punto de falla que tiene el sistema distribuido.
uBioContainer es un proyecto nuevo y aun no ofrece un gran catalogo
de herramientas para
bioinformatica, solo ofrece las mas populare. Al tratar de realizar
pruebas con otras herra-
mientas, es necesario realizar la portabilidad de las herramientas
causando demoras en la
implementacion, y no todas las herramientas pueden ser portadas a
arquitecturas de conte-
nedores, causando problemas para herramientas bioinformaticas
antiguas que actualmente
no cuentan con mantenimiento en su codigo.
Para las pruebas realizadas, las herramientas de software que se
usaron no tuvieron problemas
para paralelizar su ejecucion. En algunos casos la literatura
reporta que existen herramientas
que no se pueden ejecutar de forma paralela, generando demoras en
el tiempo de ejecucion
de las tareas para el analisis de datos.
8.3. Trabajo Futuro
Se sugiere continuar con el trabajo en proponer nuevos modelos de
comunicacion por API
para poder integrar la plataforma con otros sitios que puedan estar
geograficamente distantes.
62 8 Conclusiones y Recomendaciones
Evaluar el rendimiento del almacenamiento con tecnologas de
conexiones de red a 10 Gbp/s
para mejorar aun mas el transporte de la informacion a lo largo de
los sistemas distribuidos
donde se encuentra implementado.
Probar con nuevos elementos de hardware y arquitecturas que
permitan aumentar las posibi-
lidades de procesamiento de informacion por ejemplo: GPU, o
arquitecturas de computacion
como ARM, RISC, PowerPC y, asi mismo, evaluar difenrentes sistemas
operativos.
Crear una solucion grafica que facilite el uso de la plataforma, y
monitoreo de las tareas que
son enviadas, facilitando el uso de la herramienta y realizando un
acercamiento a usuarios
finales para promover su uso.
A. Anexo: Anexo: Codigo fuente
desarrollado
Ver el repositorio de archivos en Github
https://github.com/jnarvaezp/MDT
DVD entregado con el libro de tesis.
Bibliografa
(https://www.genome.gov/sequencingcosts/ Accessed on
03/03/2018).
fied Medicine, pp. 125–145, 2014.
[3] K. Hwang and G. C. F. J. J. Dongarra, Distributed and Cloud
Computing. 2012.
[4] A. D. U. o. I. a. C. C. Kshemkalyani and M. U. o. K. L.
Singhal, Distributed Computing
Principles, Algorithms, and Systems Distributed. 2008.
[5] D. Thain, T. Tannenbaum, and L. Miron, “Distributed computing
in practive: the
condor experience,” Concurrency and computation: practice and
experience, vol. 17,
no. 2, pp. 325–356, 2005.
[6] Brett Bode, David M. Halstead, Ricky Kendall and Z. Lei, “The
Portable Batch Sche-
duler and the Maui Scheduler on Linux Clusters,” October,
2000.
[7] D. C. Service, D. Applications, D. Goals, S. Api, and T. Z.
Project, “ZooKeeper,”
pp. 1–10, 2008.
[8] M. Z. Benjamin Hindman, Andy Konwinski, S. S. Ali Ghodsi,
Anthony D. Joseph,
Randy Katz, and I. Stoica, “Mesos: A Platform for Fine-Grained
Resource Sharing in
the Data Center,” 2010.
[9] S. a. Weil, “Ceph: Reliable, Scalable, and High-Performance
Distributed Storage,” An-
nals of Physics, vol. 129, p. 239, 2007.
Bibliografa 65
[10] Cluster File Systems Inc., “Lustre: A Scalable,
High-Performance File System,” Lustre,
pp. 1–13, 2002.
[11] B. K. Johnson, M. B. Scholz, T. K. Teal, and R. B.
Abramovitch, “SPARTA: Simple
Program for Automated reference-based bacterial RNA-seq
Transcriptome Analysis,”
BMC Bioinformatics, vol. 17, no. 1, pp. 4–7, 2016.
[12] J. S. Reis-Filho, “Next-generation sequencing,” Breast Cancer
Research, vol. 11,
no. SUPPL. 3, pp. 1–7, 2009.
[13] D. B. Searls, “Data integration: Challenges for drug
discovery,” Nature Reviews Drug
Discovery, vol. 4, no. 1, pp. 45–58, 2005.
[14] B. Coessens, S. Christiaens, R. Verlinden, Y. Moreau, R.
Meersman, and B. De Moor,
“Ontology guided data integration for computational prioritization
of disease genes,”
On the Move to Meaningful Internet Systems 2006: OTM 2006
Workshops, Pt 1, Pro-
ceedings, vol. 4277, pp. 689–698, 2006.
[15] Z. D. Stephens, S. Y. Lee, F. Faghri, R. H. Campbell, C. Zhai,
M. J. Efron, R. Iyer,
M. C. Schatz, S. Sinha, and G. E. Robinson, “Big data: Astronomical
or genomical?,”
PLoS Biology, vol. 13, no. 7, pp. 1–11, 2015.
[16] D. J. Rigden and X. M. Fernandez, “The 2018 Nucleic Acids
Research database issue
and the online molecular biology database collection,” Nucleic
Acids Research, vol. 46,
no. D1, pp. D1–D7, 2018.
[17] X. Gong, K. Nakamura, H. Yu, K. Yura, and N. Go, “BAAQ: An
infrastructure for
application integration and knowledge discovery in bioinformatics,”
IEEE Transactions
on Information Technology in Biomedicine, vol. 11, no. 4, pp.
428–434, 2007.
[18] E. Pennisi, “Will computers crash genomics?,” Science, vol.
331, no. 6018, pp. 666–668,
2011.
[19] E. Ullman, “The Case for Cloud Computing in K12,” IT
professional, vol. 11, no. 2,
pp. 23–27, 2013.
66 Bibliografa
[20] M. C. Schatz, “CloudBurst: Highly sensitive read mapping with
MapReduce,” Bioin-
formatics, vol. 25, no. 11, pp. 1363–1369, 2009.
[21] E.-g. Talbi and A. Y. Zomaya, Grid computing for
bioinformatics and computational
biology. 2008.
[22] J. Ekanayake, T. Gunarathne, and J. Qiu, “Cloud Technologies
for Bioinformatics Appli-
cations,” IEEE Transactions on Parallel and Distributed Systems,
vol. 22, pp. 998–1011,
jun 2011.
[23] J. Z. Emmanuel Jeannot, High-Performance Computing on Complex
Environments [E.
Jeannot J. Zilinskas]. 2014.
[24] Y. Brun, J. Y. Bang, G. Edwards, and N. Medvidovic,
“Self-adapting reliability in
distributed software systems,” IEEE Transactions on Software
Engineering, vol. 41,
no. 8, pp. 764–780, 2015.
[25] A. S. Tanenbaum and M. van Steen, “Distributed Systems
Principles and Paradigms
Prentice,” 2002.
[26] T. Tannenbaum, D. Wright, K. Miller, and M. Livny, “Condor: A
Distributed Job
Scheduler,” Beowulf Cluster Computing with Linux, pp. 307–350, 200