Desarrollo de una Plataforma de Almacenamiento y ...

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].
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.
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
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].
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.
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
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
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
• 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”
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.
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.
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

Desarrollo de una Plataforma de Almacenamiento y ...

Documents

Transcript of Desarrollo de una Plataforma de Almacenamiento y ...