Evaluación de un Sistema de Almacenamiento Distribuido para un entorno no controlado.

Transcripción

1 TCA Evaluación de un Sistema de Almacenamiento Distribuido para un entorno no controlado. Autores: Ing. Mónica T. Llorente Quesada, Msc. Longendri Aguilera Mendoza & Ing. Alberto Hernández Herrera Resumen El crecimiento del universo digital supera la capacidad de almacenamiento disponible, este fenómeno afecta muchas ramas de la Ciencia, dada la necesidad de almacenar enormes cantidades de datos. La utilización del Almacenamiento Distribuido es una solución viable y económica que ha adquirido popularidad en los últimos años. Los discos duros, las computadoras, la red y las aplicaciones que forman parte del sistema pueden colapsar con mayor probabilidad en un entorno no controlado y el principal reto es garantizar la escalabilidad y tolerancia a fallos que posibiliten una alta disponibilidad. Utilizando las Redes de Petri Coloreadas, CPN Tools y basado en el software Hadoop se obtiene una representación de un Sistema de Almacenamiento Distribuido. Se evalúa el comportamiento y se comparan diferentes alternativas de configuración para seleccionar la más adecuada. Mediante el modelado y simulación, se prueban alteraciones al modelo y el estudio de futuras modificaciones antes de implementarlas y validarlas. Palabras Clave Hadoop, modelado, simulación, Sistema de Almacenamiento Distribuido, Redes de Petri Coloreadas. I. INTRODUCCIÓN Desde los inicios de la evolución del hombre, la humanidad ha reconocido el valor de la información y la importancia de hacerla perdurable en el tiempo. Para ello, se comenzaron a utilizar numerosas formas para almacenar y conservar de forma segura lo que representara datos y conocimiento. Se tallaron las paredes y las piedras, luego se escribe en el papel y así se fueron perfeccionando los mecanismos hasta la era digital, en la que se comenzaron a utilizar los circuitos electrónicos para el almacenamiento. El mundo de la informática enfrenta una eminente preocupación con el crecimiento acelerado del universo digital. Estudios realizados [1] revelan que en los últimos años la información digital ha crecido 10 veces más y la cantidad de información supera en gran medida a los medios de almacenamiento disponibles. Las consecuencias de la gran demanda de almacenamiento son disímiles y se incrementan cada año debido a: la complejidad de las investigaciones científicas [2], el aumento de la resolución de cámaras digitales, grabaciones de cámaras de vigilancia, conversión de materiales a formato digital, teléfonos móviles con avanzados servicios multimedia y los sistemas de televisión digital quetoman auge en los países desarrollados, por solo citar algunos ejemplos. La práctica ha demostrado que no es posible conservar todo lo que se crea en materia de ceros y unos. Los discos duros por sí solos y otros medios de almacenamiento por muy grandes que sean en materia de capacidad, no son suficientes por sí solos y han surgido nuevas tecnologías que combinan hardware y software para persistir los datos. Entre las existentes, se encuentran los sistemas de tipo Redundant Array of Independent Disks (RAID), que dispone de varios discos duros para formar una única unidad lógica de almacenamiento y que combinados con redes de interconexión especializadas dieron lugar a las Storage Area Network (SAN). Los precios de los componentes de una SAN son elevados al compararlos con el hardware de las computadoras personales (PCs por sus siglas en inglés) y los dispositivos típicos de una red local. Por este motivo principalmente, varias instituciones de países del tercer mundo y en vías de desarrollo no cuentan con el dinero suficiente para adquirir esta tecnología. Una alternativa mucho más económica que está tomando auge, luego del impacto global de las redes de computadoras, consiste en utilizar el espacio disponible de las PCs (conectadas a través de la red) para almacenar los datos. De esta forma surgen los Sistemas de Almacenamiento Distribuido (SAD) [3]. Los SAD no son más que un grupo de computadoras conectadas entre sí con el fin de almacenar, de manera transparente a los usuarios, archivos de cualquier índole en el espacio libre de los equipos. Brindando la posibilidad de obtener acceso mediante la red a archivos almacenados en nodos remotos, con un desempeño y fiabilidad casi del mismo modo que si fueran locales. A continuación se mencionan las principales características que deben tener los SAD para lograr un buen desempeño. Lo primero es la disponibilidad, ya que el sistema debe ser capaz de responder a las peticiones de los usuarios en todo momento. Sin embargo, los disco duros fallan, las estaciones de trabajos se rompen, las redes sufren pérdida de conectividad y las aplicaciones se detienen. Por lo tanto, la tolerancia a fallas debe incorporarse para gestionar estas fallas y mantener la disponibilidad de los datos. Una manera de enfrentar las fallas es haciendo réplicas, varias estrategias de replicación existen para replicar los datos en distintos nodos del sistema. De esta manera, si algún nodo falla se puedan recuperar los datos a partir de las réplicas que existen en otros nodos. Por último, el sistema debe cumplir con la escalabilidad para poder aumentar su capacidad de almacenamiento agregando nuevos equipos sin que afecte su rendimiento.

2 TCA Con lo planteado anteriormente, pensar en aprovechar el espacio libre en el disco duro de las estaciones de trabajo presentes una institución para el desarrollo de un sistema de almacenamiento distribuido es una solución útil y económica; pero nada sencillo. Siendo el diseño del sistema uno de los principales retos para garantizar la escalabilidad y la tolerancia a fallas que posibilite mantener una alta disponibilidad de los datos almacenados. Razón por la cual, en el presente trabajo se pretende construir un modelo que permita evaluar el diseño de un sistema de almacenamiento distribuido mediante simulaciones, sin necesidad de realizar un despliegue y pruebas reales que impliquen interrumpir el funcionamiento de la institución y cargar la red de datos innecesariamente. Además de facilitar el estudio del sistema permitiendo realizar alteraciones al modelo para explorar varias alternativas, antes de implementarlas, y seleccionar la más adecuada. Redes de Petri Coloreadas II. MATERIALES Y MÉTODOS Las Redes de Petri Coloreadas (en lo adelante RdPC) fueron desarrolladas en la década de los 80 por Kurt Jensen, profesor y jefe del Departamento de Ciencias de la Computación en la Universidad de Aarhus, Dinamarca [4]. Las RdPC son un formalismo para el modelado analítico de sistemas que presentan concurrencia, sincronización y recursos compartidos [5][6][7][8]. Permitiendo representar gráficamente comportamientos de sistemas simples o complejos que facilitan a los analistas tomar decisiones oportunas y eficientes sobre el sistema modelado. CPN Tools En el Departamento de Computación de la Universidad de Aarhus, bajo la guía de Kurt Jensen, nace CPN Tools, una herramienta para el modelado y simulación de sistemas y procesos [10]. Dado que CPN Tools cumple además por ser un software de licencia libre, se escogió esta herramienta para la construcción del modelo y simulación del SAD. CPN Tools es una herramienta gráfica para la edición, simulación y análisis de RdPC[11][12]. Dispone de un simulador (tanto interactivo como automático) para poder inspeccionar el sistema modelado con las RdPC. Se encuentra bien documentado y pueden consultarse manuales en la web [13][14]. CPN ML El lenguaje de programación funcional CPN ML [15] [16], es una extensión del Standard ML, permite programar las expresiones de arco y guardas en las RdPC usando la herramienta CPN Tools. A través de este lenguaje se puede enriquecer la lógica del modelo para representar el SAD. Almacenamiento Distribuido de Datos El framework Hadoop [17] de la Fundación de Software Apache es una biblioteca de software que permite desarrollar aplicaciones y servicios en el ámbito de la computación distribuida. A tal punto, que ha llegado a convertirse en una de las principales herramientas para el procesamiento y almacenamiento de grandes volúmenes de datos. Como prueba de ello, se puede citar que en abril del 2008 rompió el récord de ordenar un terabyte de datos en 209 segundos, siendo esta la primera vez que un programa de código abierto gana este tipo de competencia. Uno de los componentes esenciales de Hadoop lo constituye el Hadoop Distributed File System (HDFS) que posibilita la puesta en marcha de un SAD. Al ser este sistema, bajo licencia de código abierto, el de mayor prestigio en la actualidad, altamente tolerante a fallas y no demandar de hardware con altas prestaciones, es que se decide utilizarlo como referencia para la construcción del modelo. HDFS tiene una arquitectura maestro-esclavo y ofrece un modelo idóneo para aquellas aplicaciones que necesitan escribir una vez y leer muchas veces (write-once-read-many). HDFS está diseñado para almacenar archivos de gran tamaño a través de todas las estaciones de trabajo. Para esto cada archivo es fraccionado en una secuencia de bloques; todos los bloques de un archivo tienen el mismo tamaño, excepto el último que puede ser menor. El tamaño por defecto de los bloques es de 64 MB y son estos fragmentos los que se almacenan, se recuperan para conformar el archivo original y se replican para garantizar la tolerancia a fallas. Basado en el funcionamiento de Hadoop, es que se realiza la escritura, lectura y replicación en el modelo del SAD que se presenta en este trabajo, pero para un entorno donde no se tiene la disponibilidad de las máquinas. El sistema está compuesto por tres tipos de componentes: DataNodes, NameNode y ClientNodes (ver figura 1). A continuación se describe el flujo de datos entre estos componentes para el proceso de escritura. Los Client Nodes son los encargados de iniciar el flujo de datos en el sistema, solicitan la escritura de un archivo y de esa manera comienzan a interactuar los diferentes componentes. Una vez respondida la solicitud, ya sea exitosa o errónea llega al Client Node la respuesta. Una misma máquina, en momentos diferentes puede comportarse como Client Node o Data Node. El Client Node es el encargado de mandar a crear en el Name Node un nuevo registro para el almacenamiento de un

3 TCA archivo mediante el llamado de la función create(). En ese instante se realiza la creación en el Name Node de un espacio para el fichero pero sin ningún bloque de datos asociado. El Name Node realiza varias comprobaciones para asegurarse de que el archivo no existe, si es así, se hace un registro del nuevo archivo, de lo contrario, la creación de archivos fallará y el cliente se le notifica la existencia del mismo. determinados Data Nodes que realicen copias de los bloques a otros para completar el número de réplicas necesarias. Cuando las réplicas se han copiado satisfactoriamente en todos los Data Nodes, entonces se procede a registrar un nuevo paquete y así hasta que todos los paquetes de cada archivo sean replicados tantas veces como el factor de replicación indique. Luego se cierra el fichero en el Name Node y se le envía al usuario un mensaje que notifica que su archivo fue almacenado satisfactoriamente. La localización de las réplicas es fundamental para el buen rendimiento del SAD y la estrategia de replicación a la hora de ubicarlas distingue a HDFS sobre otros sistemas para este fin. Para hablar de la estrategia de replicación tenemos que mencionar que los Data Nodes van a estar agrupados en Racks y uno o varios Racks forman a su vez un Data Center. Ambos conceptos, Data Center y Racks, pueden ser vistos como redes y sub-redes aisladas pero a la vez conectadas entre sí. Figura 1: Flujo de almacenamiento distribuido de datos basado en el HDFS de Hadoop. Para que el cliente comience a escribir datos el fichero se divide en paquetes, que escribe a una cola interna. Para cada paquete de la cola interna se le solicita al Name Node adicionar un bloque al fichero creado. El Name Node retorna el bloque con un identificador único y una lista de Data Nodes en los cuales debe ser copiado dicho bloque. La gestión de las réplicas (dónde, cuándo y cómo) es responsabilidad del Name Node, que se mantiene informado del estado del sistema por los reportes periódicos que hacen los Data Nodes. El conjunto de Data Nodes destinado para las réplicas pasa al Pipeline y a modo de tubería el primer DataNode le envía al segundo, el segundo al tercero y así hasta tener el número de réplicas determinada por la estrategia de replicación. El proceso de escritura no comienza hasta el Client Node no se conecta a todo el Pipeline. De manera similar se reciben los ACK que informan que los datos fueron copiados satisfactoriamente. En el cliente también existe una cola de ACK que está formada por los paquetes en espera de ser replicados. Un paquete se elimina de la cola de ACK solo cuando ha sido reconocido por todos los Data Nodes del Pipeline. Si un Data Node falla mientras se escriben los datos, se interrumpen las siguientes acciones, pero de forma transparentes para el cliente. El Data Node que falla se elimina del Pipeline y se continúa copiando en los siguientes. Si el próximo vuelve a fallar se elimina y así sucesivamente mientras exista algún Data Node. En caso de que un bloque quede por debajo del número de réplicas especificadas en el fichero de configuración, entonces el Name Node indica a Para el caso de estudio en el que el factor de réplicas es tres, se toma como destino de la primera y segunda réplica dosdata Nodes del mismo Rack que el nodo que solicita la escritura. Si ese nodo es un Data Node y tiene espacio disponible, entonces en ese mismo nodo se realiza la primera réplica. Para el destino de la tercera réplica se toma un Data Node de otro Rack. La ventaja de esta estrategia radica en que el ancho de banda entre Data Nodes del mismo Rack (sub-red) generalmente es mayor que el ancho de banda entre distintos Racks o Data Centers. Mejorando el rendimiento del proceso de escritura y garantizando la disponibilidad de los datos en caso de que falle un nodo o un Rack. Modelado y Simulación. Modelar y simular hace posible establecer una valoración final antes de que los sistemas sean construidos, y pueden aliviar la necesidad de experimentos caros y dar soporte a todas las etapas de un proyecto desde el diseño conceptual, pasando por el montaje hasta llegar a su funcionamiento. Se hace necesario el modelado primeramente para hacer una aproximación al sistema real y poder observarlo, controlarlo, modificarlo. El modelo permite además abstraernos de elementos que no aportan relevancia en el trabajo, así como enfatizar y llevar a parámetros críticos los que si son de interés. La construcción del modelo, incluye lo que se conoce como especificación o modelo conceptual del sistema. Es el modelo con el cual se realiza la primera aproximación y se especifica la estructura y procesos, del sistema real, que se tendrán en cuenta para la investigación. Finalmente se realiza la simulación donde se observa la ejecución y cambio del modelo. Con varias simulaciones se determina que condiciones pueden mejorar su comportamiento.

4 TCA III. RESULTADOS Y DISCUSIÓN En esta sección se presenta el diseño del SAD usando las RdPC y la herramienta CPN Tools. Este diseño se realizó de forma jerárquica y a partir de la página principal Top (ver Figura 2) se fueron desarrollando las sub-páginas que representan los procesos que se realizan en el sistema. Solo se mostrarán algunas páginas de un total de 48. del SAD. Todas las solicitudes pasan a la Red y en dependencia del destino, una vez en la Red las consume el Data Node o el Name Node. Una vez dentro de la página Write, se pueden observar los procesos explicados anteriormente como son crear un espacio en el Name Node, inicializar las colas, de los paquetes y de los ACK, dividir un fichero en paquetes, y el proceso de consumir los paquetes y enviarlos a los Data Nodes. Todos estos procesos tienen sus subpáginas donde se implementan. Parámetros del Sistema Los parámetros en el presente trabajo son fundamentales, se pueden modificar y tras varias simulaciones, comparar bajo qué circunstancias el sistema modelado funciona mejor. Los parámetros no son más que variables de valor constante que serán utilizadas a lo largo del diseño. Estos valores serán los criterios modificables y puntos de comparación para futuros estudios, en los que se pueden encontrar los mejores parámetros para el funcionamiento del SAD. Se observa además que son utilizados en diferentes ámbitos dentro del modelo. Son útiles para inicializar nodos lugar con valores determinados, en este caso rigen el número de solicitudes de escritura y lectura que puede enviar el cliente. Figura 2: Componentes principales del SAD y estructura jerárquica de la páginas. La Figura 2 muestra los principales componentes del SAD ya mencionados en secciones anteriores, así como la manera en que ellos se comunican a través de la Red. Las tres páginas que jerárquicamente le siguen a la página Top, especifican las principales acciones que desarrollan cada uno de los componentes Name Node, Client Node y Data Node. A la izquierda de la imagen se muestra una parte de la estructura jerárquica de las páginas diseñadas. Figura 3: Procesos que lleva a cabo el Client Node En la Figura 3 se observa que el Client Node es el encargado de solicitar la escritura o lectura de un archivo. Todas las solicitudes salen y llegan de UI (User Interface), sub-página que muestra cómo se generan de manera aleatoria las solicitudes. Este comportamiento imita a un cliente usuario Se pueden incluir en la declaración de nuevos Colores (tipos de datos). En este caso el Token que modela el identificador de las máquinas (MachinID) está formado por una combinación de estos dos valores: el número de rack y el número de la máquina dentro del rack. También son utilizados en la creación de guardas para una transición, determinada como valor de comparación y en la implementación de funciones, como es el caso de checkblkreplication(), en la cual se determina si un bloque está por debajo del mínimo valor de replicación. Implementación de la estrategia de replicación. Para implementar la estrategia descrita en la sección anterior se tuvo en cuenta: el factor de replicación, este valor coincide con el número de Data Nodes que se devolverá en el Pipeline una vez llamada la función. El identificador del Client Node del que se está realizando la solicitud de almacenamiento, los bloques en los que ya está replicado y en los que no se pueden replicar. Además se tiene en cuenta la distancia entre nodos, calculada por la función Net'getDistance(), para devolver el Pipeline de una manera ordenada con el fin de que el recorrido por los nodos sea de costo mínimo. Proceso de Almacenamiento de Datos El proceso de almacenamiento de datos se evidencia principalmente en la página ReceivingAnswer del Client Node, y en DataNodeCore del Data Node.

5 TCA Al finalizar la simulación las Solicitudes de Escritura quedan respondidas con el mensaje OK y quedan almacenamos los archivos en el nodo lugar File Copied y se muestran como Archivos Copiados. Como los tamaños de los archivos son mayores que 64 MB estos son divididos en paquetes que luego forman los bloques y se almacenan en los Data Nodes correspondientes. En el Name Node se evidencia como, una vez terminada la simulación, en cada uno de los Data Nodes se encuentran la lista de bloques almacenados con el siguiente formato blocks = [(blk(identificador), tamaño), ]. Cada bloque se encuentra replicado en tres Data Nodes, pues tres es el factor de replicación. En el SAD está simulado también el estado de los Data Nodes, se evidencia que todos los Data Nodes tienen el estado habilitado (status = On). Esto no ocurre en la totalidad de los casos, pero como se planteó anteriormente el proceso es transparente al usuario. Mediante una transición el estado de los Data Nodes cambia constantemente (On/Off), pero el sistema se recupera y si trata de acceder a alguno que tiene el status = Off, vuelve a solicitar un nuevo Data Node hasta encontrar uno disponible. Además de estar habilitado, el espacio libre (freemb), que también se muestra en la descripción de los Data Nodes debe ser mayor que el tamaño del bloque que se desea guardar. Por otra parte, el Name Node va guardando de cada archivo los bloques que le pertenecen y de cada bloque la lista de Data Nodes en los que ha sido almacenado y replicado. De esta manera se puede recuperar el archivo gracias al proceso inverso, mediante la solicitud de lectura. Para la recogida de los datos de la simulación se implementaron los monitores que brinda la herramienta CPN Tools, se utilizan para observar, inspeccionar, controlar o modificar una simulación. Muchos monitores diferentes pueden definirse para una red, pueden inspeccionar tanto las marcas de los lugares y los elementos de unión que se producen durante una simulación. En la Figura 4 se muestra la cantidad de intentos (eje y) que se realizaron por bloques para ser almacenados en función del tiempo. Mientras algunos bloques se logran almacenar desde la primera vez, otros tuvieron que ser enviado 2 y 3 veces. En la Figura 5 se puede aprecia como solamente dos bloques causaron el error de escritura mostrado en la Figura 4. Figura 4: Intentos de ubicación de bloques. Figura 5: Respuestas a solicitudes de escritura. En la Figura 5 se muestran las respuestas a las solicitudes de escritura (eje y) en función del tiempo (eje x). Si la solicitud fue satisfactoria el monitor guarda 1 y si no -1. De las 100 solicitudes dos no se lograron, las 98 restantes fueron satisfactorias a pesar de los fallos ocurridos durante la simulación. Se identificó un problema que dificulta el almacenamiento de los archivos. En el proceso de escritura, antes de comenzar a almacenarse todos los paquetes de un archivo el Pipeline o Data Nodes recomendados por el Name Node debe ser conectado o recorrido de inicio a fin. Todos los Data Nodes deben estar encendidos. En un entorno no controlado, donde las computadoras se encienden, apagan o reinician a voluntad de los usuarios es más difícil que se cumpla esta condición que en un entorno controlado o dedicado como normalmente sucede. Por este motivo se propone que en este Pipeline se realicen tantas replicas como Data Nodes estén disponibles y que por uno que esté fuera de servicio no se deseche todo el Pipeline. El sistema cuando no se puede conectar a uno de los Data Nodes los desecha por completo sin tener en cuenta que pudiera tener al menos dos réplicas del bloque en vez de ninguna. Esto puede traer como consecuencia que los archivos no cuenten con las tres réplicas necesarias en este caso. Pero la tolerancia a fallos del sistema se encarga de completarlas. IV. CONCLUSIONES Al igual que todo software, un Sistema de Almacenamiento Distribuido (SAD) como el Hadoop Distributed File System (HDFS) desarrollado por Apache, debe estar sujeto a constantes cambios y mejoras a medida que se pruebe en nuevas situaciones y escenarios. En el presente trabajo se obtuvo como principal resultado un modelo de un SAD, basado en el HDFS, usando las Redes de Petri Coloreadas y la herramienta CPN Tools que permiten la edición del modelo para explorar, mediante simulaciones, nuevas estrategias de replicación y experimentar con nuevos valores en los parámetros de configuración. El modelo construido para el

6 TCA SAD puede servir de referencia para realizar una validación previa y detectar errores de futuros cambios antes de implementarlos, sin necesidad de desplegar el sistema y realizar pruebas en un escenario real que generen un tráfico adicional de datos en la red. REFERENCIAS [1] F GANTZ, Jhon; CHUTE, Christopher; MANFREDIZ, Alex; MINTON, Stephen; REINSEL, David. The Expanding Digital Universe: A Forecast of Worldwide Information Growth Through. IDC, March 2008, pp [2] HEY, Tony; TANSLEY Stewart; TOLLE, Kristin. The Fourth Paradigm: Data-Intensive Scientific Discovery. Washington: Microsoft Research, pp. ISBN [3] DOAN THANH, Tran; MOHAN, Subaji; CHOI, Eunmi; KIM, SangBum; KIM, Pilsung. Taxonomy and Survey on Distributed File Systems. Fourth International Conference on Networked Computing and Advanced Information Management, [4] JENSEN, Kurt. Colored Petri Nets: Basic concepts, Analysis Methods and Practical Use. New York: Springer Verlag pp. ISBN [5] KRISTENSEN, Lars Michael; BEAK JORGENSEN, Jens; JENSEN, Kurt. Application of Coloured Petri Nets in System Development. Department of Computer Science, University of Aarhus, 2004, In Lecture on Concurrency and Petri Nets, pp [6] CANUL-NOVELO, Grelty; LEÓN RAMÍREZ, Adda. Modelado de Sistemas Concurrentes y Distribuidos con Redes de Petri.. Departamento de Sistemas Computacionales. Instituto Tecnológico de Mérida, Yucatán, México [7] BRATOSIN, Carmen; VAN DER AALST, Wil; SIDOROVA, Natalia; TRČKA, Nikola. A Reference Model For Grid Architectures and Its Analysis. Department of Mathematics and Computer Science Eindhoven University of Technology, [8] TRČKA, Nikola; VAN DER AALST, Wil; BRATOSIN, Carmen; SIDOROVA, Natalia. Evaluating a Data Removal Strategy for Grid Environments Using Colored Petri Nets. Department of Mathematics and Computer Science Eindhoven University of Technology, 2008 [12] STÖRRLE, Harald. An Evaluation of High-end Tools for Petri-nets. Universität München, Univ.Inst. für Informatik, pp. [ aluierung.pdf] [13] KURT, Jensen; KRISTENSEN, Lars; WELLS, Lisa. Coloured Petri Nets and {CPN} Tools for modelling and validation of concurrent systems. International Journal on Software Tools for Technology Transfer (STTT), 2007, vol 9, núm 3, pp [14] CPN Tools Homepage. [ [15] MILNER Robin; TOFTE Mads; HARPER, Robert; MACQUEEN, David. The definition of Standar ML. Library of Congress Cataloging in Publication Data pp. ISBN [16] CHRISTENSEN, Soren; BISGAARD HAAGH, Torben. Design/CPN Overview of CPN ML Syntax. University o f Aarhus Computer Science Department [17] Hadoop Distributed File System; Consultado en Enero de [ Sobre los autores Mónica Teresa Llorente Quesada: Es graduada de Ingeniero en Ciencias Informáticas en el 2007, por la Universidad de Ciencias Informáticas. Se desempeña como profesora (Instructor) de Programación en dicha institución. Tiene la categoría docente de Instructor. Longendri Aguilera Mendoza: Es graduado de Lic. Ciencias de la Computación en el 2004, por la Universidad de La Habana. Se desempeña como profesor (Asistente) de Programación en la Universidad de las Ciencias Informáticas. Tiene la categoría docente de Asistente y es Máster en Bioinformática. Alberto Hernández Herrera: Es graduado de Ingeniero en Ciencias Informáticas en el 2011, por la Universidad de Ciencias Informáticas. Se desempeña como Ingeniero Recién graduado vinculado a la producción en el Dpto de Bioinformática del Centro de Tecnologías y Gestión de Datos. [9] KRISTENSEN, Lars Michael; CHRISTENSEN, Soren; JENSEN, Kurt. The practitioner's guide to coloured Petri nets. CPN Group, Department of Computer Science, University of Aarhus, Denmark, [10] BEAUDOUIN-LAFON, Michel; MACKAY, Wendy; ANDERSEN, Peter; JANECEK, Paul; JENSEN, Mads; LASSEN, Henry; LUND, Kasper; MORTENSEN, Kjeld; MUNCK, Stephanie; RATZER, Anne V; RAVN, Katrine; CHRISTENSEN, Soren; JENSEN, Kurt. CPN/Tools: A Post-WIMP Interface for Editing and Simulating Coloured Petri Nets. Proceedings of the 22nd International Conference on Application and Theory of Petri Nets, ISBN pp [11]