UNACLOUD
Opportunistic cloud computing platform

Arquitectura

UnaCloud es una infraestructura IaaS oportunista que permite aprovechar los ciclos computacionales ociosos de los computadores de escritorio para el desarrollo de diversos proyectos de e-Ciencia. Para lograrlo, UnaCloud permite el despliegue de instancias de ejecución o procesos de forma individual o en clústeres sobre estos equipos.

Un CVP se conforma mediante el almacenamiento y ejecución de una imagen pre configurada en cada uno de los computadores de escritorio de un laboratorio de cómputo. Todas las instancias de ejecución actúan como esclavas del CVP y son ejecutadas como procesos en background y de baja prioridad, en forma paralela al desarrollo de las actividades informáticas de los usuarios. Este mecanismo de ejecución garantiza un impacto despreciable en el rendimiento percibido por el usuario actual del computador de escritorio. En forma adicional, un servidor dedicado ejecuta una instancia que actúa como maestra del CVP, a la cual acceden los investigadores para ejecutar sus tareas. La ejecución de estas instancias, conforman un CVP que tiene todas las configuraciones requeridas por el grupo de investigación que lo utilizará, emulando los ambientes nativos de múltiples aplicaciones de e-Ciencia.

UnaCloud esta soportada sobre la siguiente arquitectura.


Vista de información

La vista de información describe como la arquitectura guarda y administra la información del sistema. Para esta vista se hace uso de un modelo de entidades, donde se representan los elementos conceptuales del negocio por medio de entidades y sus relaciones.

Modelo de dominio UnaCloud

A continuación se presenta la descripción de cada entidad. Para un mayor detalle de los campos y sus relaciones, favor revisar la documentación de código de la aplicación.

  • HardwareProfile:Entidad que representa un conjunto de recursos de computo de una instancia en ejecución. El perfil de hardware define cuanta memoria RAM, y cuantos núcleos de procesamiento son configurados en una instancia de ejecución. Los valores predefinidos por la aplicación para esta entidad, se basan en los estándares que manejan proveedores de computación en la nube.
  • Execution: Entidad que representa una instancia de una imagen proceso que es puesta en ejecución sobre la infraestructura disponible de UnaCloud.
  • ExecutionRequest: Entidad que representa el estado de una ejecución en un momento en el tiempo.
  • Plataforma: Entidad que representa una aplicación para ejecución de procesos o máquinas virtuales. Por ejemplo el hipervisor Tipo 2.
  • ServerVariable: Entidad que representa una variable que puede ser utilizada por el servidor y/o los agentes para configuración o comunicación.
  • Image: Entidad que representa los que fueron previamente configurados por un usuario y subidos al sistema para posteriormente ser ejecutados sobre la infraestructura de UnaCloud.
  • DeployedImage: Entidad que representa una imagen que fue seleccionada para ser ubicada y ejecutada sobre en la infraestructura de UnaCloud.
  • Repository: Entidad que representa un sistema de archivos donde se almacenan los archivos de las imágenes.
  • Deployment: Entidad que representa un conjunto de instancias de ejecución en el sistema configuradas por un usuario.
  • Cluster: Entidad que representa un conjunto de imágenes que un usuario requiere sean puestas en ejecución juntas.
  • User: Entidad que representa a un usuario que requiere privilegios para entrar al sistema, subir imágenes y desplegar ejecuciones sobre la infraestructura.
  • UserGroup: Entidad que representa un conjunto de usuarios. Esta entidad busca facilitar la labor administrativa para la configuración de restricciones sobres los usuarios.
  • OperatingSystem: Entidad que representa un tipo de sistema operativo que es soportado por la plataforma para albergar instancias de ejecución.
  • PhysicalMachine: Entidad que representa un host o máquina física que hace parte de la infraestructura de UnaCloud y donde corren las ejecuciones.
  • Laboratory: Conjunto de host o máquinas físicas ubicadas geográficamente en un mismo sitio o enlazadas por un mismo segmento de red.
  • NetInterface: Entidad que representa una interfaz de red configurada en una instancia de ejecución.
  • PhysicalIP: Representa una dirección IP que está asociada a una máquina física.
  • ExecutionIP: Entidad que representa una dirección IP que ha sido asignada a una instancia de ejecución.
  • IP: Entidad que representa una dirección IP registrada en el sistema.
  • IPPool: Representa un conjunto de direcciones IP que comparten una máscara de red y una puerta de enlace. También puede entenderse como un segmento de red.
  • UserRestriction: Entidad que representa una restricción de usuario que es configurada a un usuario o grupo de usuarios para limitar privilegios de usuarios al realizar despliegues en el sistema. Entre las restricciones que maneja el sistema en el momento se encuentran: laboratorios permitidos para hacer despliegues, perfiles de hardware que puede utilizar un usuario y el algoritmo de ubicación de instancias de ejecución que aplicará para un usuario.

Dentro de la vista de información también se especifica los diferentes estados de la entidad Execution. Los estados de esta entidad toman especial relevancia para la plataforma, dado que controlan las instancias de ejecución sobre la infraestructura y permiten medir la confiabilidad del sistema en cuanto a la correcta ejecución de despliegues solicitados por los usuarios. El siguiente diagrama de estados representa el ciclo de vida de una instancia de ejecución de una instancia.

Modelo de estados de las ejecuciones

Los estados y su comportamiento son tratados en el manual de usuario, pero para un mayor entendimiento de la plataforma son especificados a continuación:

  • FAILED: estado de fallo. Una ejecución cae en este estado en el caso que exista un fallo en el proceso de ejecución o se superen los tiempos de vida de cada estado.
  • QUEUED: encolado. Primer estado de una ejecución en el cual un usuario ha realizado la solicitud de despliegue y ejecución de un clúster. Este estado tiene un tiempo de vida de máximo 2 minutos, en caso de alcanzar el tiempo máximo de vida la ejecución cambiará su estado a FAILED de lo contrario cambiara a CONFIGURING.
  • CONFIGURING: configurando. Segundo estado de la ejecución, en esta parte del proceso el agente solicita al servidor los archivos correspondientes para hacer el despliegue y configura la imagen en la plataforma que la ejecuta. El tiempo de vida máximo de este estado es de 30 minutos, en caso de alcanzar el tiempo de vida máximo la ejecución cambiará a estado FAILED, de lo contrario cambiara a DEPLOYING.
  • DEPLOYING: desplegando. Tercer estado del proceso de ejecución, en esta parte del proceso el agente ha puesto en ejecución la instancia y se encuentra configurando la red para que pueda ser accedida remotamente. El tiempo de vida máximo en este estado es de 8 minutos, en caso de alcanzar el tiempo de vida máximo la ejecución cambiará a estado FAILED, de lo contrario cambiara a DEPLOYED.
  • DEPLOYED: desplegado. Estado en que una instancia está en ejecución y correctamente configurada. Este estado tiene un tiempo N el cual es el tiempo de ejecución solicitado por el usuario. En caso de presentar un error en la plataforma durante la ejecución se presentará el estado FAILED, en caso de perderse la comunicación con la ejecución cambiará a estado RECONNECTING. Por otro lado puede que por solicitud del usuario cambie de estado por ejemplo cuando un usuario decide apagar la ejecución (FINISHING) o cuando se solicita sea enviada al servidor (REQUEST_COPY).
  • RECONNECTING: reconectando. Una ejecución presentará este estado en el caso en que el servidor pierda comunicación con la instancia de ejecución. El tiempo máximo de vida en este estado es de 10 minutos, en caso de cumplirse cambiará a estado FAILED o en caso de restablecerse la comunicación cambiará a estado DEPLOYED.
  • REQUEST_COPY: enviar copia a servidor. En este estado un usuario solicitó que la instancia de ejecución guarde su estado y sea enviada al servidor. Este proceso tiene como tiempo máximo 4 minutos, en caso que el agente procese la tarea cambiará a estado COPYING de lo contrario cambiará a DEPLOYED.
  • COPYING: copiando a servidor. En este estado un agente se encuentra enviado los archivos de la instancia de ejecución al servidor para su almacenamiento. Este estado tiene un tiempo de vida de 30 minutos como máximo. En caso de falla en el proceso, el estado de la ejecución pasará a FAILED de lo contrario a FINISHED.
  • FINISHING: finalizando. En este estado un usuario solicita que la ejecución sea detenida. Este estado tiene un tiempo de 8 minutos.
  • FINISHED: finalizado. Este estado representa que la ejecución ha sido finalizada. Para llegar a este estado puede llegar por solicitud del usuario, porque el tiempo de ejecución ha concluido o por error en algún paso del proceso.

Estos estados son controlados por el componente web de la aplicación.


Vista Funcional

Para representar cómo se comporta el sistema en ejecución se hace uso de un modelo de componentes. En este se presentan los componentes del sistema y la forma en que interactúan.

Modelo de componentes

Los componentes del sistema se pueden ver divididos en dos grupos, los que se ejecutan en el ambiente del servidor y los que se ejecutan en el ambiente del cliente.

  • Web Browser: Este componente permite la interacción de los usuarios con la plataforma. En este componente se ubica la interfaz de usuario final la cual interactúa con los componentes web y de gestión de archivos, el primero para la ejecución de tareas, y el segundo para la recepción y procesamiento de archivos de imágenes.

Componentes del ambiente del servidor

  • Web App: Componente donde se procesan las solicitudes de los usuarios. Este componente ofrece una serie de servicios web para que sean consumidos desde el componente Web Browser.
  • File Repository: Componente donde se almacenarán los archivos de las imágenes que son subidas por los usuarios, típicamente representado por una carpeta en un servidor. Solo el componente de gestión de archivos puede tener acceso a este componente.
  • File Manager: Componente para la gestión de archivos, se encarga de recibir y entregar archivos de imágenes desde el repositorio de archivos. Este componente procesa tareas que se encuentran almacenadas en una cola de tareas, y que detallan los procedimientos que debe ejecutar con los archivos. Al mismo tiempo, este componente ofrece una serie de servicios que son utilizados por los agentes para la descarga y subida de archivos.
  • File Message Queue: Componente que representa un repositorio de mensajes con solicitudes para la gestión de archivos. En este repositorio el componente web almacena de forma ordenada las solicitudes del usuario, que son procesadas posteriormente por el componente de gestión de archivos.
  • Transactional Data: Componente donde se almacena el modelo de datos de la aplicación. Esta base de datos sirve al tiempo como un medio de comunicación entre los componentes web, gestión de archivos y control de agentes.
  • Control Message Queue: Componente que representa un repositorio de mensajes con solicitudes para los clientes. En este repositorio el componente web almacena de forma ordenada las solicitudes del usuario, que son procesadas posteriormente por el componente de control de clientes.
  • Client Control: Componente encargado de gestionar el estado de los clientes en el sistema. Procesa las solicitudes del usuario para la gestión de los agentes y los mensajes de los agentes con información de su estado y de las ejecuciones que están ubicadas en su infraestructura.

Componentes del ambiente del cliente.

  • Updater: Componente encargado de gestionar la versión del agente que se ejecuta en las máquinas físicas. Este componente se conecta al componente de gestión de archivos para validar la versión del agente.
  • Agent: Componente encargado gestionar la comunicación con las plataformas para la ejecución de las imágenes. Este componente mantiene actualizada una base de datos local con la información que describe el estado de las ejecuciones, y accede al repositorio local para almacenar y ejecutar las imágenes.
  • Local File Repository: Componente que representa un repositorio de archivos local que funciona como cache en el cliente, y el cual tiene como propósito almacenar los archivos de las imágenes.
  • Local Data: Componente donde se almacena información que describe el estado de las ejecuciones, e información de configuración de las imágenes almacenadas en el cliente.

Vista de Despliegue

En la vista de despliegue se presenta un modelo de despliegue, en el que se observa como son asignados los componentes de la vista funcional en una infraestructura. Cabe aclarar que el modelo presenta una infraestructura distribuida en varios nodos de ejecución como un ideal para el despliegue pero como se observa en el Manual de instalación y configuración varios componentes pueden estar ubicados sobre el mismo nodo.

Modelo de despliegue

UnaCloud recomienda el uso de los puertos en el rango 10025 al 10035 para su configuración. La especificación de los nodos donde se ejecutan o residen nuestros componentes de la aplicación son:

Nodos de ejecución en el ambiente del servidor

  • La distribución de los componentes busca aprovecha el desacoplamiento de los mismos para dar mayor desempeño y permitir la escalabilidad del sistema en términos de hardware.
  • El componente Web Browser requiere de un navegador Chrome, Firefox, Explorer, o Safari que soporte JQuery 2.0.2 o superior, CSS3 y HTML5. Para el uso en móviles Android 4+, IOS 4+.
  • El nodo de ejecución del componente Web App requiere un sistema operativo Ubuntu Server 12+, Tomcat 8 y Java 7. Este nodo debe permitir el acceso http por el puerto 8080.
  • El nodo de ejecución para las colas de mensajes es un RabbitMQ 3.6+ sobre un sistema operativo Ubuntu Server. Este nodo debe permitir el acceso tcp por el puerto 5672 por defecto.
  • El nodo de ejecución donde se ubica la data transaccional puede ser un Ubuntu Server o Windows Server con una versión de MySQL 5+. Este nodo debe permitir el acceso tcp por el puerto 3306 por defecto.
  • Para el componente Client Control, encargado de la comunicación con los agentes, se requiere un sistema operativo Ubuntu 12+ y Java 7. Este nodo debe permitir el acceso udp por los puertos 10026 y 10027 (o los puertos configurados en su ambiente).
  • Los componentes File Manager y File Repository se encuentran en el mismo nodo de ejecución el cual requiere un sistema operativo Ubuntu 12+ y Java 7. Para este nodo en particular se requiere al menos 60 GB para almacenamiento de archivos y debe permitir el acceso tcp por los puertos 10028 y 10029 (o los puertos configurados en su ambiente).

Nodo de ejecución ambiente del cliente

En el cliente todos los componentes deben estar ubicados sobre el mismo nodo de ejecución. Este nodo de ejecución puede ser una máquina configurada con sistema operativo Windows 7 – 8, con Java 7 y con hipervisores VirtualBox 4.3 y/o Workstation 10. El cliente debe permitir el acceso TCP por el puerto 10030 (o el puerto configurado en su ambiente).


Vista de Desarrollo

Para la vista de desarrollo se utiliza un diagrama de paquetes donde se presentan los diferentes paquetes de UnaCloud y la dependencia entre ellos, así como las librerías externas que son requeridas por la aplicación.

Espacio de trabajo

Diagrama de paquetes

El código de la aplicación se divide en un total de 7 paquetes de software, 5 de ellos desarrollados en Java y 2 desarrollados con el framework de desarrollo web Groovy on Grails. A continuación, se resume la descripción de cada paquete y las librerías que requiere.

  • AgentCloud: proyecto que contiene el código del agente. Requiere el paquete CommonShares para la comunicación con el servidor.
  • AgentUpdater: proyecto que contiene el código del programa que actualiza el agente. Requiere el paquete CommonShares para la comunicación con el servidor.
  • CommonShares: código que es compartido por los proyectos del agente y los del servidor. Contiene paquetes para estandarizar la comunicación entre componentes y constantes utilizadas en ambos ambientes, entre otros.
  • ServerShares: paquetes de código que son compartidos por los proyectos del servidor; UnaCloudControl, UnaCloudFileManager y UnaCloudWeb. Contiene paquetes para comunicación por medio de cola de mensajes, conexión a base de datos, manejo de archivos, entre otros.
  • UnaCloudControl: proyecto con el código de la aplicación de gestión de agentes. Este proyecto contiene paquetes que permiten la comunicación con los agentes para el intercambio de mensajes de control. Requiere librerías apache commons para realizar pool de conexiones a la base de datos así como conexión a la cola de mensajes de RabbitMQ.
  • UnaCloudFileManager: proyecto con el código de la aplicación de gestión de archivos. Este proyecto contiene paquetes que permiten la comunicación con los agentes para el intercambio de archivos. Ofrece servicios web para que los usuarios puedan subir archivos al servidor. Requiere librerías apache commons para realizar pool de conexiones a la base de datos así como conexión a la cola de mensajes de RabbitMQ. El paquete grails-app requiere de una serie de librerías comunes, o plugins en grails, que permitan ofrecer los servicios web.
  • UnaCloudWeb: proyecto con el código de la aplicación web, que permite la interacción del usuario con el sistema. Este proyecto contiene el modelo de datos y funciona en una arquitectura MVC. Requiere librerías para la conexión a la cola de mensajes de RabbitMQ, así como una serie de librerías comunes, o plugins en grails, que permitan la creación de servicios y la conexión a la base de datos. La interfaz de usuario de la aplicación requiere de una serie de librerías en Javascript que garantizan una mejor usabilidad y estética para el usuario.