DISEÑO DE UNA ARQUITECTURA QUE FACILITE LA TRANSMISION DE DATOS POR MEDIO DE STREAMING
JAVIER ARMANDO DAVILA ROMERO
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN GRUPO DE MANEJO DE DATOS
BOGOTÁ D.C. JULIO DE 2007
DISEÑO DE UNA ARQUITECTURA QUE FACILITE LA TRANSMISION DE DATOS POR MEDIO DE STREAMING
JAVIER ARMANDO DAVILA ROMERO
Tesis para optar al título de Ingeniero de Sistemas y Computación
Profesores Asesores Claudia Jiménez, Ph.D.
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN GRUPO DE MANEJO DE DATOS
BOGOTÁ D.C. JULIO DE 2007
Tabla de contenidos
1. INTRODUCCIÓN ... 2
2. OBJETIVOS ... 6
2.1 Objetivos Generales: ... 6
2.2 Objetivos Específicos ... 6
3. ANTECEDENTES Y CONTEXTO ... 7
3.1 Propuesta Globus [FOS2006] ... 7
3.1.1 GridFTP [GL2006] ... 9
3.2 JAVA MEDIA FRAMEWORK ... 9
3.3 Streaming y Protocolo RTP ... 11
3.3.1 Sesiones RTP ... 12
3.4 Video On Demand y P2P... 13
4. ESTRATEGIA DE LA SOLUCIÓN. ... 15
4.1 Descripción de la aplicación piloto: ... 15
Requerimientos Funcionales:... 16
Requerimientos No Funcionales: ... 16
4.1.2 Definiciones: ... 17
4.2 Iteraciones... 17
4.2.1 Iteración 1: un cliente un servidor ... 17
4.2.2 Iteración 2: muchos clientes, un servidor. ... 18
4.2.3 Iteración 3: Muchos Clientes, Muchos Servidores... 19
5. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA EN LA ITERACIÓN 3. ... 23
5.1 Descripción del ambiente de desarrollo: ... 23
5.2 Análisis: ... 23
5.2.1 Casos de Uso: ... 23
5.2.2 Diagrama de casos de uso:... 26
5.3 Diseño... 26
5.3.1 Arquitectura General ... 26
5.3.2 Arquitectura en Detalle (Diagrama de Componentes) ... 28
5.3.3 Diagrama de clases: ... 30
5.3.4 Presentación clases ... 31
5.3.4.1 Clases del mundo dataGrid ... 32
5.3.4.2 Clases de Cliente ... 38
5.3.5 Diagramas de secuencia... 41
6. ANALISIS DE RESULTADOS ... 45
6.1 Infraestructura de desarrollo ... 45
6.2 Utilización Promedio de las Maquinas... 46
6.3 Tiempo de respuesta al pedir un servidor... 47
7. TRABAJO FUTURO... 49
8. CONCLUSIONES ... 51
BIBLIOGRAFIA ... 53
1. INTRODUCCIÓN
Desde hace algunos años se inició una revolución de información en la que cada vez se genera un mayor número de datos, y en la que las comunicaciones son el principal responsable de este hecho. Desde la aparición de Internet, la generación de datos en el mundo ha ido incrementando en cantidades inimaginables, especialmente en datos de tipo multimedia, los cuales pueden ir desde una simple foto para identificar un empleado de una compañía, video clips con manuales de instrucción, imágenes médicas para detección y revisión de progreso de enfermedades, hasta cursos completos dados en tiempo real, con interacción de personas en diferentes partes del mundo.
Con la aparición de estos nuevos datos se han desarrollado nuevas y más grandes necesidades de almacenamiento y procesamiento, obligando a la creación constante de soluciones que muchas veces quedan obsoletas rápidamente debido a los cambios tan dinámicos de estos requerimientos. Soluciones clásicas de servidores centralizados son descartadas de primera mano, debido a que ante un acceso continuo las probabilidades de respuesta se minimizan y los tiempos de respuesta incrementan, y en el momento de que se llegue a la capacidad máxima de almacenamiento, la única solución que existe es incrementarla[SD2003].
Estas necesidades de almacenamiento y procesamiento se viven actualmente en varios países del mundo, por ejemplo en Suiza, el CERN (Consejo Europeo Para la Investigación Nuclear) tiene su proyecto bandera llamado LHC, el acelerador de partículas más grande del mundo, capaz de generar 10 Petabytes de información por año, equivalente al 10% de la información producida por año en el mundo [SOT2006]. Este desafió es afrontado por
medio de una propuesta de sistemas distribuidos, llamada GridComputing definida como:”un sistema que coordina recursos que no están sujetos a control centralizado, usando protocolos e interfaces estándares, abiertas y de propósito general, para entregar servicios de calidad no triviales.”[FOS2006]
Una vertiente de GridComputing, es el datagrid el cual propone una arquitectura para el almacenamiento, distribución y consulta de datos, a partir de grandes grupos de clusters de maquinas distribuidos geográficamente. Para las organizaciones con este tipo de distribución, es de vital importancia lograr almacenar el conocimiento generado en sus actividades diarias para su posterior consulta, utilizando medios físicos y digitales llamados repositorios de conocimiento en los que se almacenan documentos y videos. Este último es usado cada vez más seguido por las facilidades que conlleva a la hora describir y enseñar una acción [KM2003].
Para la transmisión de este tipo de información se ve la necesidad de utilizar una tecnología que permita su transferencia, manejo y despliegue correcto de información de video y audio, además de un control durante el tiempo en que los datos se obtienen de su fuente, se transmiten y se entregan al usuario final. Esta tecnología es conocida como streaming y es el caso de estudio de este trabajo, se enfoca su uso dentro de un datagrid [STR2004], en el que se encuentren aplicaciones que usan datos heterogéneos, que tengan la posibilidad de cooperar entre si. Este datagrid se basa en la arquitectura propuesta en el proyecto Magos de la Universidad de los Andes, la cual ofrece al implementador servicios de instalación de aplicaciones, asignación recursos y un workflow para el uso de todas las aplicaciones previamente instaladas.
Con este trabajo se busca evidenciar y documentar los problemas más comunes encontrados durante la implementación de servicios Magos en los que haya transmisión de información a través de streaming, proponiendo soluciones genéricas que permitan al desarrollador tener una base sólida a la hora de la implementación de un sistema de este tipo. Temas de vital importancia, como por ejemplo, seguridad e integridad de los datos, no son tomados en cuenta en este trabajo.
Este tema ha sido caso de estudio en varios proyectos tanto libres como comerciales entre los que se destaca AccessGrid [AG2004], el cual es un modelo creado para video conferencias, en el que se utiliza un grupo de recursos multimedia incluyendo presentaciones, ambientes interactivos, interfaces a middleware de grid y ambientes de visualización para mejorar la comunicación y colaboración entre grandes grupos de trabajo distribuidos geográficamente. Este proyecto es utilizado principalmente durante conferencias altamente distribuidas, seminarios, tutoriales, etc.
Otro proyecto interesante es el realizado por el Computing Centre University en Stuttgart y financiado por Telefonica de España. Este proyecto llamado Akogrimo el cuál incluye dispositivos móviles como usuarios de un datagrid y establece comunicaciones en tiempo real con los diferentes usuarios de los servicios ofrecidos a través de video conferencias. Una aplicación de este proyecto, presentada por sus desarrolladores, es la de mantener un monitoreo constante sobre diferentes tipos de pacientes a partir de sensores que ellos llevan. Transmitiendo la información recaudada por estos sensores a los doctores encargados de cada paciente, dándoles la posibilidad de comentar sobre la situación actual del paciente a partir de video conferencias [AK2007].
Proyectos como los mencionados anteriormente son cada vez más comunes tanto en el ámbito comercial, cómo en el educativo. La mayoría de estos proyectos buscan facilitar el aprendizaje a través de repositorios de conocimiento. Entre estos proyectos se encuentran: SIMDAT el cuál utiliza la tecnología grid para el desarrollo de procesos y el diseño de productos a través de la búsqueda de conocimiento distribuido [SIM2007]. PIONIER, financiado por el comité polaco para la investigación científica y diseñado para interconectar mas de 15 universidades alrededor de Polonia, creando laboratorios virtuales en los que existen grupos de colaboración que interactúan en tiempo real [GT2007]. GRIDCAST, creado por GridNetworks provee una plataforma para desplegar video de calidad DVD, conectando clientes a nivel mundial [GT20072].
En el capitulo tres se contextualiza el problema frente a la tecnología básica para su correcta implementación, además se realizan comparaciones con tecnologías similares. En el capitulo cuarto se describe la estrategia elegida para solucionar el problema presentado en este trabajo y se define la arquitectura base para la solución de este tipo de problemas. El capitulo cinco explica detalladamente esta arquitectura y muestra una implementación de la misma realizada en java.
2. OBJETIVOS
2.1 Objetivos Generales:
1. Diseñar una arquitectura datagrid, que permita el almacenamiento, la consulta y el despliegue de tipos de datos multimedia de manera eficiente en un contexto multiusuario.
2. Realizar una implementación básica de un datagrid en un prototipo funcional de fácil instalación que utilice tecnología estándar, permitiendo evidenciar y documentar dificultades y generalidades de este tipo de implementaciones
3. Proponer soluciones generales que sirvan como base, para la implementación de este tipo de sistemas.
2.2 Objetivos Específicos
1. Documentar el uso de tecnologías Globus Toolkit 4 y OGSA-DAI con datos multimedia.
2. Documentar las dificultades y virtudes de usar Java Media Framework (JMF) sobre un datagrid, como motor de despliegue y control de aplicaciones multimedia.
3. Plantear una arquitectura datagrid específica para las necesidades de manejo de información multimedia.
4. Establecer protocolos que permitan la correcta implementación de aplicaciones que usen streaming sobre un grid.
3. ANTECEDENTES Y CONTEXTO
3.1 Propuesta Globus [FOS2006]
Globus es una comunidad de usuarios y desarrolladores de todo el mundo que a partir de un producto open-source para computación distribuida, logran compartir poder computacional, de procesamiento, bases de datos y otras herramientas comunicándose con seguridad en línea.
Este producto open-source es llamado Globus toolkit, el cual es un grupo de librerías y servicios para facilitar la labor del desarrollador, en el que se destacan servicios de monitoreo, descubrimiento y manejo de recursos compartidos en el grid.
En su cuarta versión, globus toolkit propone una solución a los problemas mencionados anteriormente, mediante el desarrollo de web services, los cuales utilizan una comunicación orientada a documentos, permitiendo tener bajo acoplamiento, facilitando el mantenimiento de los servicios independientemente de con quien interactué.
Los web services utilizados en GridComputing son conocidos como grid services. Estos servicios tienen como principal característica el hecho de que
pueden tener un estado asociado, permitiendo que recuerden invocaciones anteriores.
Globus define dos tipos de patrones para facilitar la implementación de los grid services. El primero de estos patrones se conoce como patrón
singleton, en el cual el estado del servicio es compartido por todos los usuarios que lo accedan.
El segundo patrón es conocido como factory. Este patrón difiere del anterior por el hecho de poder asociar un estado a cada uno de los usuarios que lo acceden y de tener un estado compartido por todos los usuarios [SOT2006].
Figura 1 Patrón Factory para grid services [SOT2006]
En la figura 1 se muestra como es la interacción entre el cliente y un servicio implementado con base al patrón factory en donde primero se crea un recurso y luego es accesado directamente desde la instancia. Entender esta interacción es de vital importancia para el desarrollo de este trabajo, ya que al tratarse de recursos de video, es necesario que cada uno de ellos pueda ser accesado de manera independiente aun estando en el mismo servidor. Este acceso independiente implica que los clientes pueden estar viendo videos diferentes al mismo tiempo, o el mismo video pero con tiempos de despliegue diferentes.
3.1.1 GridFTP [GL2006]
GridFTP busca ser un protocolo seguro, robusto, rápido y eficiente para la transferencia de grandes cantidades de datos (Terabytes o Petabytes) desde y hacia grandes sistemas de almacenamiento altamente distribuidos geográficamente. La transmisión de estos datos es hecha a través de varios canales en forma paralela, ya sea hacia un solo nodo, o hacia varios, incrementando la eficiencia del envió, pero obligando a la reconstrucción de los datos una vez recibidos. Esta reconstrucción es realizada en forma obligatoria por el implementador del protocolo, quitándole esa responsabilidad a la aplicación que lo utilice, de igual manera el implementador del protocolo es el encargado de manejar el control de los canales de transmisión minimizando la responsabilidad de los nodos participantes.
Globus Alliance desarrolló una implementación para este protocolo, la cual esta hecha para ser usada únicamente por medio de línea de comandos ( globus-url-copy), sin crear un API para su uso por medio de aplicaciones java, que permita al usuario tener la oportunidad de realizar monitoreo y tener un mayor control sobre la transmisión. El uso de esta tecnología facilita el transporte de videos de gran tamaño a través de los nodos del grid, ya sea a la hora de almacenarlos por primera vez, o al incrementar las replicas del mismo copiándolo a diferentes nodos.
3.2 JAVA MEDIA FRAMEWORK
Java Media Framework (JMF) es la solución propuesta por Sun Microsystems para el manejo de información multimedia, otorgando al programador una herramienta que le permita reproducir, manejar, capturar y almacenar, datos dependientes del tiempo.
Todo esto es logrado a partir de una arquitectura fácilmente comprensible diseñada para ser fácilmente programable, soportar captura a partir de medios, permitir a los desarrolladores generar soluciones a partir de un API existente y fácilmente extensible [JMF2003].
Figura 2 Funciones de JMF [JMF2003]
JMF al ser un API no propietario, está diseñado para soportar solo tipos de medios estándares, tales como AIFF, AU, AVI, GSM, MIDI, MPEG, RMF y WAV. Gracias a que es desarrollado en java lo hace muy interesante al tener la posibilidad ser usado en aplicaciones multiplataforma.
Como se dijo anteriormente, la función de JMF es realizar parte de los procesos presentados en la Figura1, esto se logra a partir de un modelo básico que podría ser representado de la siguiente manera:
1. Un objeto de captura encargado de generar los datos a almacenar y mostrar.
2. Un objeto que contiene la información anteriormente capturada
3. Un objeto de procesamiento encargado de modificar, leer o realizar operaciones de rendering sobre esta información
4. Un objeto de despliegue, encargado de presentar la información procesada en el paso anterior
5. Un objeto de compresión y guardado, encargado de encapsular la información y generar persistencia.
3.3 Streaming y Protocolo RTP
La tecnología de streaming permite visualizar contenido multimedia como video y audio durante la descarga sin la necesidad de completarla. De hecho, es posible que se desconozca de antemano su duración, como en el caso de transmisiones en tiempo real, usadas en video conferencias y programas radiales por Internet.
Para esta tecnología no es tan importante evitar la pérdida de información ya que puede ser fácilmente compensable [JMF20031]. En cambio, se busca realizar una transmisión fluida, es por esto que protocolos tradicionales como HTTP o FTP, no son eficientes, ya que están basados en el protocolo TCP (Transmission Control Protocol), diseñado para ser confiable (Todo la información llega, así sea necesario reenviarla.), generando sobre carga del canal de transmisión. Tenemos también su contrario, un protocolo que permita mantener baja la utilización del canal, pero sacrificando confiabilidad, este Protocolo es UDP (User Datagram Protocol) [CN2005].
Los dos protocolos mencionados anteriormente funcionan muy bien en datos de acceso estático, pero es necesario considerar uno diferente para la transmisión de datos dependientes del tiempo, para este propósito se reunió el grupo de trabajo AVT definiendo en el RFC 1889 de IETF (el cual en estos momentos es obsoleto) y posteriormente en el RFC 3350 el protocolo RTP (Real-time Transport Protocol) [RFC2003].
Este Protocolo esta situado sobre la capa de transporte independientemente de que sea UDP o TCP, dándole flexibilidad al desarrollador dependiendo de sus necesidades, aunque normalmente es utilizado sobre UDP [RFC3350].
Las principales características de este protocolo, son el permitir identificar el tipo de datos que están siendo transportados, determinar el orden en que los paquetes deben ser presentados, lograr la sincronización de datos de diferentes fuentes, identificar del remitente y realizar el control de la transmisión.
Este protocolo es importante en un ambiente grid cuando se busca la interacción final de dos nodos para la transmisión de un dato multimedia, sobre todo cuando existe un gran número de flujos llegando a un mismo nodo. En este caso el protocolo permite agrupar por remitente para diferenciar las transmisiones.
3.3.1 Sesiones RTP
“Es una asociación de un conjunto de aplicaciones comunicándose por medio de RTP. Cada sesión es representada por una dirección IP y 2 puertos, por el primero se reciben los datos, y el segundo es utilizado para control. En sesiones multimedia, cada tipo de datos es transmitido por diferentes flujos de datos, agrupados por el CNAME o nombre del transmisor” [RFC2003]. Este CNAME es utilizado por JMF para lograr la sincronización de las diferentes transmisiones a partir del tiempo de despliegue del primer flujo recibido, permitiendo al desarrollador olvidarse de la responsabilidad de mantener la sincronización.
Estas sesiones son utilizadas a lo largo de este trabajo para facilitar las transmisiones nodo a nodo, en cuanto a control de los flujos y su posterior sincronización.
3.4 Video On Demand y P2P
Video on demand es un sistema que permite al usuario solicitar y ver un video ya sea película o programa en el momento que el lo desee, ofreciendo funciones de control de despliegue como retroceder, pausar y adelantar la presentación. Al estar en la obligación de prestar estas funciones, este sistema no puede ofrecer transmisiones en tiempo real, ya que en ellas estas funciones no son naturales y por ende no puede ser utilizado en ambientes colaborativos [VOD2006].
Por otro lado se encuentra la tecnología peer to peer, nacida a partir de la necesidad transmitir video a un número reducido de clientes por un canal de transmisión de baja calidad. Dadas estas condiciones el uso de un servidor centralizado dedicado a la transmisión es impensable tanto por costos como por utilización, es por esto que se planteo una solución que permite a los usuarios redistribuir la transmisión a otras maquinas [P2P2003]. Este sistema es perfecto para transmisiones en tiempo real de bajo costo, pero no funciona tan bien para transmisiones de archivos de video, cuando el número de clientes aumenta y cada uno quiere ver un video diferente, como es el caso considerado en este trabajo.
Estas dos tecnologías pueden ser fácilmente integradas a un ambiente grid, simplemente proporcionándolas como un servicio más del datagrid, ya que su uso final es independiente del ambiente en que se presente. Un ejemplo de
esta integración fue realizado por la compañía Kontiki, quien usa video on demand para mejorar la eficiencia del entrenamiento de sus empleados alrededor del mundo a partir de cursos en video almacenados en el datagrid [GRT2003].
Por otro lado la tecnología P2P entra a suplir la deficiencia de video on demand en ambientes colaborativos, proporcionando la posibilidad de realizar transmisiones en tiempo real de bajo costo.
4. ESTRATEGIA DE LA SOLUCIÓN.
Con el fin de solucionar el problema y cumplir con los objetivos tanto generales como específicos abordos en este trabajo, se realiza una aplicación prototipo que permita descubrir las necesidades especificas en cuanto arquitectura y protocolos de comunicación. Para lograr esto se escoge como metodología el uso de iteraciones incrementales, definiendo como aplicación piloto un servidor de videos.
4.1 Descripción de la aplicación piloto:
Se quiere ofrecer un prototipo completamente funcional al grupo Comit de la Universidad de los Andes de un datagrid que permita el almacenamiento y despliegue de videos a uno o muchos servidores distribuidos a través del grid.
Para estos servidores un video tiene las siguientes características:
• Nombre del archivo
• Ruta absoluta en la maquina que provee el servicio de almacenamiento
• Categoría (Música, Comedia, Trailers) definidas por el cliente que quiere almacenar el video, a partir de la interfaz de la aplicación.
• Tamaño que ocupa el video en Megas
• Puntaje entre 1 y 5 definido por los usuarios que ven el video.
Se requiere que el servidor transmita un video, localizándolo ya sea por medio de una búsqueda por nombre o por categoría. Se debe responder al cliente con el nombre del video que encontró o con un mensaje de error en caso de que el video buscado no exista o que por cuestiones de carga no este disponible.
Este trabajo se centra en el uso de datos de video con audio incluido, buscando una arquitectura que funcione cuando se trate de solo datos de audio o de video.
Requerimientos Funcionales:
Æ Almacenar un video en el datagrid
Æ Desplegar un video buscándolo por nombre
Æ Desplegar un video buscándolo por categoría
Æ Registrar un nuevo servidor
Requerimientos No Funcionales:
Æ La aplicación debe funcionar en un ambiente en donde muchos clientes estén agregando y consultando videos al mismo tiempo en múltiples servidores.
Æ La aplicación debe maximizar la probabilidad de respuesta, trasladando videos entre servidores con mayor capacidad de procesamiento y tamaño de memoria disponible.
Æ La arquitectura usa OGSA-DAI y Globus Toolkit 4 como tecnología base para el desarrollo en grid.
Æ La aplicación debe ser de fácil instalación utilizando un Wizard o un manual de instalación rigurosamente especificado.
Æ La aplicación debe tener una interfaz gráfica sencilla e intuitiva, que muestre el proceso de gestión de videos en el grid.
La aplicación es desarrollada en tres iteraciones. En la primera un cliente interactúa con un solo servidor, en la segunda iteración, muchos clientes
interactúan con un solo servidor, y por ultimo muchos clientes interactúan con muchos servidores.
4.1.2 Definiciones:
Para continuar con la descripción de la solución, es necesario realizar una serie de definiciones que faciliten la lectura y entendimiento de la misma.
Servidor apto para transmisión: servidor con una utilización de cpu y memoria menor a las cotas máximas establecidas por el administrador.
Mejor servidor: servidor con la menor utilización de memoria y cpu.
Scheduling: distribuir los procesos a diferentes nodos en el grid, para evitar sobrecarga de un servidor.
4.2 Iteraciones
4.2.1 Iteración 1: un cliente un servidor
En esta iteración se desarrollo un DataService en OGSA-DAI denominado VideoDataService, el cual es el encargado de hacer el acceso a la base de datos del servidor, más específicamente a la tabla video, la cual tiene los campos mencionados en la sección 4.1.
Este punto de acceso es utilizado por dos servicios encargados del almacenamiento y transmisión de los datos. El primero de ellos es denominado AgregarVideoService, encargado de insertar la información a la base de datos y guardar el video en el sistema de archivos del nodo. La transferencia de este archivo se hace a través de GridFTP.
El segundo es denominado TransmitirVideoService, encargado de interactuar con el cliente siguiendo el protocolo especificado en el diagrama de secuencias de la sección 5.3.2
Figura 3 Arquitectura iteración 1
La figura 3 muestra la arquitectura base, para lograr una interacción adecuada entre un cliente y un único servidor. En la que se destaca el uso de dos
servicios separados para el almacenamiento y la transmisión para lograr un menor acoplamiento.
4.2.2 Iteración 2: muchos clientes, un servidor.
Al tener más clientes, es necesario hacer algunos cambios al modelo presentado en la iteración anterior, específicamente en el servicio de transmisión. Es necesario cambiar la estructura de TransmitirVideoService de un patrón singleton, a un patrón factory,
ya que si se mantuviera el primero todos los clientes tendrían que ver el mismo video al mismo tiempo.
Por otro lado si se utiliza un patrón factory es posible asociarle un recurso diferente, de tal manera que cada uno de ellos pueda estar viendo un video diferente al mismo tiempo y esto solo es logrado utilizando un patrón factory.
Figura 4 Arquitectura iteración 2
Gracias a la decisión independizar los servicios, no fue necesario modificar el servicio de almacenamiento. Aun con los cambios realizados en el servicio de transmisión la interacción entre cliente servidor sigue siendo la misma.
4.2.3 Iteración 3: Muchos Clientes, Muchos Servidores
Al incluir más servidores de video en el grid se hace necesario darle a un nodo la responsabilidad de conocer, ubicar, administrar y distribuir la carga estos servidores. Para lograr satisfacer estos requerimientos es necesario crear un nuevo servicio llamado NewLocator. Este servicio logra la administración de los servidores utilizando una base de datos específica para este propósito. Para el alcance de este proyecto sólo tiene las direcciones IP de los servidores, pero al incluir seguridad o varios tipos de servicios, la información contenida en esta base de datos probablemente será mayor.
Para evitar problemas de concurrencia, desinformación y sobrecarga del nodo en el que se encuentra NewLocator, debido al acceso directo de muchos clientes, es necesario crear un nuevo servicio que actúa como una cola de peticiones, establecida como único punto de acceso a este servicio del datagrid. Este servicio es llamado QueueService, y aunque soluciona los problemas mencionados anteriormente, tiene como defecto él ser un cuello de botella del sistema.
NewLocator, como administrador de los servidores, tiene como responsabilidad distribuir las peticiones de los clientes entre los ellos. Por tratarse de datos de tipo multimedia se tomó la decisión de elegir el mejor servidor para cada tarea. Para conocer al mejor servidor es necesario conocer sus niveles de utilización, es por esto que NewLocator instancia en cada uno de los servidores disponibles un nuevo servicio llamado Monitoreo3. Este servicio actúa como representante de los recursos del nodo ante el datagrid, ofreciendo servicios de consulta sobre puertos disponibles, capacidad de disco disponible y niveles de utilización actuales de memoria y cpu.
Si, durante la búsqueda del mejor servidor, se descubre que este no es un servidor apto, es necesario que este envíe la información solicitada al mejor servidor apto encontrado en esta misma búsqueda, de tal manera que se maximice la probabilidad de respuesta a costa de replicación de la información.
Finalmente al encontrar un servidor disponible, toda la comunicación se hace directamente entre el cliente y el servidor hasta que se haga un nuevo pedido, en ese momento el proceso vuelve a comenzar. Este reinicio del proceso se realiza bajo el supuesto de que un servidor no tiene que tener toda la información que un cliente necesite.
Figura 5 Arquitectura iteración 3.
La arquitectura mostrada en el figura 5 permite la replicación de datos incrementando así la probabilidad de respuesta de una petición y al mismo tiempo disminuyendo la carga de cada maquina distribuida por NewLocator. Se destaca la necesidad de tener un representante de cada nodo de servicio (Monitoreo3), cuya principal responsabilidad es manejar la información correspondiente a los puertos que establecen la comunicación directa entre el nodo cliente y el nodo de servicio.
Con la creación QueueService se sacrifica eficiencia en la obtención de respuesta, al ser este servicio un cuello de botella de la arquitectura. Pero se considera que este sacrificio es aceptable, considerando de mayor importancia los problemas que este soluciona.
5. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA EN LA ITERACIÓN 3.
5.1 Descripción del ambiente de desarrollo:
La aplicación está realizada en el lenguaje de programación Java, esta decisión es tomada, en primer lugar por las características que tienen tanto OGSA-DAI como Globus Client Toolkit, el primero sólo permite al usuario desarrollar en este lenguaje, y el segundo permite desarrollar en Java, Python y C. Por otro lado, al haber elegido como motor para este desarrollo Java Media Framework, obliga al uso de este lenguaje, que como ventajas nos ofrece portabilidad entre diferentes plataformas, y facilidad de desarrollo.
5.2 Análisis:
5.2.1 Casos de Uso:
Existen tres tipos de usuarios que interactúan en este datagrid, el primero de ellos es el administrador encargado de elegir los nodos que sirven como servidores, el segundo es el cliente que almacena sus videos en el datagrid, y el ultimo de ellos es el que solo desea ver los videos almacenados.
CU1: Almacenar un video en el datagrid.
El cliente del datagrid define la categoría a la que pertenece el video, su tamaño en megas y su nombre, enviando esta información al servidor. El servidor ingresa esta información a la base de datos, escogiendo como path,
una carpeta fija dentro del nodo (Para este caso es “/usr/local/globus4/servidorVideos”). El servidor retorna un mensaje de éxito o error si logra o no ingresar esta información. Si el mensaje es de error se muestra al cliente, si es de éxito, el cliente hace el traspaso real del archivo, a través de GridFTP, que a su vez puede retornar un mensaje de éxito o error, si llegase a ser un error, el servidor elimina del video de la base de datos.
CU2: Ver Video Por Nombre.
El cliente del datagrid especifica el nombre de un video que quiere ver. El video es buscado en todos los servidores, si no existe se retorna un mensaje al cliente especificándolo. Si existe puede retornar la dirección IP del mejor servidor en que se encuentra para comenzar la comunicación entre el cliente y ese servidor, esto solo ocurre en el caso en que el servidor sea apto. De no ser así, el video es transmitido a otro servidor que si tenga capacidad disponible. En el caso que no haya ningún servidor apto para la transmisión, el cliente es notificado con un mensaje de error.
Si existe algún servidor apto capaz de responder a la petición, se inicia el protocolo especificado en el caso de uso 2.1
CU2.1 Preparar Transmisión
Al recibir la dirección IP de un servidor, el cliente le pide reserve recursos para lograr la interacción, para luego establecer la información del video a transmitir. El servidor establece los puertos por donde va a comenzar la transmisión y por donde el cliente tiene que comenzar a escuchar, esta información es obtenida preguntando al servicio Monitoreo3 de cada nodo. Después de establecer los
puertos, el servidor comienza la transmisión y el cliente comienza la recepción y el despliegue del video.
CU3: Ver Video Por Categoría.
El cliente del datagrid especifica la categoría de un video que quiere ver. Un video con esta categoría es buscado en todos los servidores, si no existe se retorna un mensaje al cliente especificándolo.
Si existe puede retornar la dirección IP del mejor nodo en que se encuentra (mejor implica menor utilización de cpu y/o de memoria), para comenzar la comunicación entre el cliente y ese servidor, esto solo ocurre si el servidor cumple con los requisitos de memoria y/o cpu, en caso contrario un video con esa categoría es transmitido a otro servidor que si tenga capacidad disponible, si no existe ninguno con suficiente capacidad, el cliente es notificado.
En caso contrario comienza el caso de uso 2.1
CU4: Configurar el datagrid.
En el nodo servidor se definen cuales nodos proveen los servicios de almacenamiento y transmisión, registrándolos en su base de datos. También se definen los nodos que proveen los servicios NewLocator y QueueService, y los valores máximos de utilización tanto en memoria, como en cpu para determinar que es un servidor apto. No es indispensable que estos servicios se encuentren en el mismo nodo.
5.2.2 Diagrama de casos de uso:
5.3 Diseño
5.3.1 Arquitectura General
Figura 6 Arquitectura general de la solución.
La arquitectura general de la aplicación se resume en las 3 capas mostradas en la figura 6.
Mirando de abajo hacia arriba, la primera capa, es en donde se encuentran los recursos y servicios proporcionados por cada nodo, estos recursos se dividen en 2, el recurso de bases de datos, accesado por medio de las interfaces de OGSA-DAI, y el segundo es el de almacenamiento directo en el disco duro, ambos controlados por dos web services implementados por el desarrollador (AgregarVideoService y TransmitirFactory), encapsulado la manipulación de estos recursos, y el procesamiento propios a la aplicación.
Encima de estos dos servicios, existe otro servicio globus llamado Monitoreo3 el cual es encargado de la comunicación de cada nodo con la capa superior acerca de la información que este contiene.
La única comunicación que hay entre los nodos en esta capa, es cuando es necesario copiar información de un servidor a otro, de tal manera que el único canal que existe entre ellos es el servidor GridFTP.
En la capa intermedia se presentan dos servicios, el primero de ellos es un mecanismo de control para el segundo, con el que se busca evitar situaciones de acceso concurrente, siendo este una cola para todas las peticiones hechas por lo clientes.
El segundo servicio, es el encargado de la localización de servidores, y la especificación de los límites máximos de utilización para especificar que servidores están o no disponibles.
En la última capa se encuentra el cliente del datagrid que se encarga de invocar los servicios de las dos capas anteriores, para solucionar sus necesidades de almacenamiento y consulta.
5.3.2 Arquitectura en Detalle (Diagrama de Componentes)
Figura 7. Diagrama de componentes en detalle.
En la figura 7, se ve la interacción entre las unidades de cada una de las capas, mostradas en el la sección 5.3.1.
El cliente está en la capacidad de interactuar tanto con QueueService, como con los servicios finales (AgregarVideoService y TransmitirFactory). La interacción comienza con el cliente haciéndole un pedido al QueueService, cuya única función es mantener estos pedidos en cola, para luego mandarlos al NewLocator y al recibir respuesta devolverla al cliente. El NewLocator se comunica con todos los servidores, buscando el mejor servidor que pueda responder a la petición del cliente. Para conocer esta información es necesario preguntarle directamente al nodo, y la responsabilidad de esta tarea la tiene Monitoreo3, este servicio sabe responder cual es la capacidad restante del disco duro, descontando la que esta por ser ocupada por cualquier nuevo video que estén agregando, también
responde la utilización actual tanto de memoria como de cpu, y si en su base de datos, existe un video de un nombre o una categoría dada.
El cliente al recibir la dirección IP del servidor que lo va a atender establece una comunicación directa con el. Dado todo esto, podemos decir que la arquitectura funciona como un grid para localización de recursos, pero para la comunicación final trabaja como una arquitectura P2P sin tener en cuenta la propiedad de redireccionamiento de la información de esta arquitectura.
5.3.3 Diagrama de clases:
.
En el lado derecho de la figura 8 se muestran las clases pertenecientes a al datagrid, encargadas de prestar los servicios de almacenamiento y
transmisión. Mientras que en la parte izquierda se muestran las clases que componen al cliente, entre las que se destacan, PanelVerVideo, AgregarVideoServiceThread y AdminVideoReciever, las dos ultimas son las encargadas de la comunicación con los servicios prestados por el datagrid, y la primera de ellas es la encargada de mostrar la información que están reciban, ya sea mensajes, o realizar la reproducción del video.
5.3.4 Presentación clases
A continuación se presentan en forma detallada las clases más importantes de la aplicación piloto, de tal manera que se puedan ver como entidades separadas con responsabilidades propias. Si se quiere ver más detalladamente la información favor remitirse a la documentación javadoc de la versión electrónica de este trabajo.
5.3.4.1 Clases del mundo dataGrid
Monitoreo3:
Figura 9. Clase del servicio Monitoreo 3
El servicio completo tiene 3 clases, pero dos de ellas no se muestran ya que no tienen ninguna importancia, en cuanto a funcionalidad. Estas clases fueron creadas solamente para mostrar una interfaz grafica amigable al usuario, para ver la utilización de la memoria, cpu y disco duro.
La clase principal de este servicio, tiene como función ser el representante del nodo ante el grid, no solo en cuanto a utilización, sino en cuanto a acceso a la base de datos, y manejo de puertos.
Este servicio tiene dos recursos principales: el primero de ellos es un atributo de pendiente, utilizado cuando ya hay un cliente intentando ingresar un video al servidor, pero todavía no ha comenzado a enviar la información, de tal manera que cuando el resto de clientes que pregunten por la capacidad del servidor, se
debe contestar como si el video ya hubiera sido ingresado, evitando así se intenten ingresar más datos de los que realmente caben.
El segundo recurso es el que representa el siguiente puerto a utilizar, esto es necesario ya que en un nodo pude haber un cliente y un servidor funcionando al mismo tiempo. Si cada uno tuviera esta información por aparte podrían intentar utilizar los mismos puertos, pero con la información unificada, ese problema desaparece.
También provee servicios de consulta sobre la información en la base de datos, en cuanto a la existencia o no de un video, ya sea por nombre, o categoría, y tiene la capacidad de preguntar por el tamaño de un video dado su nombre.
AgregarVideoService:
Esta clase provee los servicios principales de almacenamiento, tanto en la base de datos para registrar la información que contiene el nodo, como el almacenamiento directo al disco duro del archivo de video.
Estos servicios son representados por cinco métodos públicos, dos de ellos se comunican con el representante del nodo ante el grid (Monitoreo3) para incrementar o reducir la capacidad pendiente mencionada anteriormente (incrementarCarga y terminarVideo).
EnviarVideoGFTP, está encargado de enviar el archivo físico desde este nodo, a otro nodo del grid, para maximizar la probabilidad de atención de un cliente.
TransmitirFactory
Este servicio, por seguir un patrón factory, se divide en dos clases importantes: la que representa los servicios en sí, llamada transmitirService, y la que representa los recursos transmitirResource.
En este caso la primera de ejerce funciones de broker, al ser el punto de comunicación entre clientes y servicios. Entre sus responsabilidades se encuentra el manejo del ciclo de vida de los recursos (creación, eliminación y almacenamiento) y la distribución de las peticiones de los clientes a su recurso asociado.
La clase transmitirResource es la encargada de representar la petición del cliente, a partir de una serie de atributos y servicios que permiten la transmisión puerto a puerto de un video. Para conocer estos puertos esta clase puede instanciar al servicio de monitoreo de las maquinas con las que se comunica y con el suyo.
Durante el desarrollo de este servicio se presento una dificultad a la hora de entrar en comunicación directamente con el recurso. Esta comunicación se logra a partir de un ResourceKey con dos atributos (un nombre y una llave) generada por la instancia al crear cada recurso. Esta llave debe ir inmersa en cada llamado a la instancia del servicio, de tal manera que se pueda instanciar un recurso específico. Pero por alguna razón desconocida, esta llave no llegaba en ninguno de los llamados. Es por esto que se tomó la decisión de enviar estos dos atributos de forma explicita en cada llamado en que necesite comunicarse con un recurso específico.
Pero esto no fue suficiente para que la instancia reconociera la llave especificada, debido a que la implementación usada del patrón factory tiene su propia manera de comparar estas llaves sin dar la posibilidad de
redefinición. Por esta razón se creó una función encargada de encontrar el ResourceKey que contenga los atributos que enviados por el cliente.
Teniendo esta llave, ya es posible comunicarse directamente con el recurso, para comenzar la transmisión.
NewLocator
Figura 12. Clases del servicio NewLocator
NewLocator cumple la función de scheduler del servicio de video, ya que es el encargado de escoger cuál es el mejor servidor en capacidad de atender un cliente, intentando distribuir la carga equitativamente entre todos los servidores del grid. Este servicio tiene como atributos las cotas máximas de utilización de cpu y memoria definidas a partir de un archivo de propiedades, las cuales son 75% por defecto.
Si el mejor servidor encontrado para atender a un cliente resulta ser un servidor no apto, es necesario que este envíe la información solicitada al mejor servidor apto, para que sea este quien responda la petición del cliente, incrementando así el número de replicas de un video y la probabilidad de respuesta ante una
nueva petición. La responsabilidad de este envío es del servicio AgregarVideoService y es realizada por medio de gridFTP.
Para poder mantener la información de cada servidor es necesario crear un objeto que sea capaz de representarlo. Esta es la responsabilidad de la clase ServidorVO mostrada en la figura 12, la cual al ser un value object sólo provee servicios de modificación y consulta sobre sus atributos de memoria, cpu y capacidad de almacenamiento.
QueueService
Figura 13. Clases del servicio QueueService
QueueService cumple la función de control sobre las peticiones hechas por los clientes hacia el grid, evitando que exista concurrencia en el NewLocator. La decisión de crear este servicio se tomó con base en dos aspectos: El primero de ellos es evitar problemas de desinformación, ya que si todos los clientes hacen una petición a NewLocator al mismo tiempo, todos recibirían la misma respuesta sobrecargando el servidor. El segundo aspecto tomado en cuenta para esta decisión es la necesidad ante cada petición, se alcance a ver
el efecto de las peticiones anteriores, para asegurar efectividad de la distribución de la carga. Esto se logra mediante el uso de una cola sin prioridades (LinkedBlokingQueue), que siempre está dormida hasta que llegue una nueva petición, y no continúa hasta que la cabeza de la fila sea completamente atendida, esperando un cuarto de segundo adicional para atender la siguiente petición.
Se crea la clase ClienteVO, como represente de los clientes. Esta representación incluye su dirección IP, el tipo de petición que esta presentando, y los datos necesarios para realizarlo como son el tamaño de los datos, el nombre o categoría del video que se quiere ver.
5.3.4.2 Clases de Cliente
AdminVideoSender
Figura 14. Detalle de AdminVideoSenderThread
AdminVideoSenderThread es la encargada de realizar el almacenamiento de los videos, comunicándose con la cola de servicios para que le sea asignado un servidor con suficiente capacidad en el disco duro. Toda esta
comunicación se realiza en un hilo de ejecución diferente al de la aplicación cliente con el propósito de no bloquear al cliente durante este tiempo, y permitir que se envíen varios videos al tiempo.
AdminVideoReciever
Las clases miSesion y la clase Contenido, son las representaciones de las
sesiones RTP y de los flujos de datos recibidos respectivamente. La primera es usada como monitoreo, sobre el servidor con el cual se esta hablando y el puerto de comunicación utilizando, y la segunda contiene el flujo de datos recibido, el player encargado de reproducirlo y componentes visuales que este player produce.
La clase principal de este grupo es AdminVideoReciever, encargado de conseguir un servidor que este disponible, y realizar el protocolo para comenzar la transmisión, protocolo especificado con mayor precisión en el siguiente capitulo. Como se explicó en TransmitirFactory, el cliente pide específicamente el recurso que quiere utilizar. Obtener y mantener esta información también es responsabilidad de esta clase.
5.3.5 Diagramas de secuencia.
5.3.5.1 Agregar Video
Figura 16. Diagrama de secuencias de agregar video.
En la figura 16, se observa el flujo de mensajes entre las clases presentadas en el capitulo anterior, para lograr ingresar un nuevo video al grid.
Comenzando desde la interfaz, creando e iniciando un nuevo AdminVideoService, el cual invoca al método localizarServidor enviando como parámetro el tamaño del video que se quiere ingresar; llamando
al método servir de QueueService ingresando su dirección, el tamaño del video y el tipo de búsqueda que quiere, en este caso es 3 para indicar que es de inserción.
Servir ingresa una representación de la petición del cliente a la cola de espera. Al llegar a la cabeza de la cola y ser atendido, esta información es enviada a NewLocator, quien consulta en todos los servidores su capacidad de disco duro, utilizando el método getHardDriveCapacity del servicio Monitoreo3.
Al encontrar el mejor servidor, se envía la dirección IP del servidor al cliente para que este comience la interacción directamente con él.
Esta interacción comienza incrementando el tamaño pendiente de los datos a ingresar, para que ante alguna consulta posterior de NewLocator, se retorne la capacidad después de completado el almacenamiento. Este incremento se realiza para evitar que se responda espacio disponible existente, cuando en realidad no va a haber después del almacenamiento y para hacer más efectiva función de scheduling sobre el grid. Luego se envía la metadata del video, como lo es el nombre, la categoría y el tamaño para ser ingresados a la base de datos del nodo, si este ingreso es exitoso comienza la transmisión del video vía gridFTP. En el caso de que haya error en la transferencia, no se pueda ingresar la información a la base de datos o un envío exitoso, es necesario remover el tamaño pendiente del servidor, para no mostrar sobrecarga del disco duro.
5.3.5.2 Buscar Video Por Nombre
Figura 17. Diagrama de secuencias de transmisión de video.
Para este caso la primera parte del flujo de mensajes es igual a la del servicio anterior, hasta llegar al localizador. En este punto se busca el mejor servidor que contenga el video buscado, si el mejor servidor no cumple con las restricciones de utilización, envía el video al mejor servidor que no lo tenga siempre y cuando este si cumpla esta condición, enviando al cliente la dirección IP del servidor que lo va a atender, de lo contrario se envía un mensaje de error.
Si el cliente recibe una dirección, envía sus datos al servidor por medio del método establecer cliente, de tal manera que el recurso sea capaz de establecer los puertos de comunicación, enviados al cliente cuando este
ejecute el método prepararTransmision, cuando ambos tiene establecidos los puertos de conexión el cliente pide que comience la transmisión utilizando el método comenzarTransmision.
5.3.5.3 Buscar video por categoría
El diagrama de secuencia para este servicio es idéntico al anterior con la excepción del paso 6, el cual cambia a localizar por categoría, y en el paso 7 por estaVideoCategoria.
6. ANALISIS DE RESULTADOS
Con el fin de evaluar la arquitectura construida se diseñaron dos pruebas sencillas para verificar los impactos que tiene la arquitectura elegida en cuanto a utilización promedio de las maquinas y tiempo de respuesta al pedir un servidor.
Sólo se realizaron estas dos pruebas ya que el resto de efectos e interacciones realizadas en el trabajo son independientes a la arquitectura y no son controlables por el administrador.
6.2 Utilización Promedio de las Maquinas
Utilizacion promedio del nodo
40 45 50 55 60 65 70
1 2 3 4 5 6 7 8
Numero de clientes
por c e nt a je de U ti li z a c ion [u ti li z aci o n a c tu al /u ti li z a ci o n di s poni bl e
]% 1 servidor
2 servidores
3 servidores
4 servidores
Figura 18 Utilización promedio del nodo
El gráfico anterior muestra cómo aumenta la utilización promedio de los servidores, al aumentar el número de clientes dentro del datagrid.
Como lo indica la intuición al tener un solo servidor la utilización de la maquina tiende a incrementar linealmente, pero al aumentar el número de servidores disponibles esta utilización se mantiene mínima.
Una utilización como la mostrada anteriormente permite asegurar el buen funcionamiento del servicio NewLocator, quien ejerce labores de scheduling distribuyendo las solicitudes de transmisión entre los servidores disponibles de manera uniforme.
6.3 Tiempo de respuesta al pedir un servidor
Tiempo de respuesta
0 1000 2000 3000 4000 5000 6000 7000
1 2 3 4 5 6 7 8
Numero de Clientes
Ti e m po e n m il is e
gundos 1 servidor
2 servidores
3 servidores
4 servidores
Figura 19. Tiempo de respuesta de NewLocator
Como se ve en la gráfica anterior, el tiempo de respuesta aumenta en línea recta dependiendo del número de servidores que se tenga. Esto se da por la política utilizada de escoger el mejor servidor apto para la transmisión, lo que nos obliga a recorrer toda la lista de servidores. Adicionalmente, al incrementar el número de de clientes que realizan este acceso, estos tiempos también aumentan de manera exponencial ya que por cada uno de los clientes es necesario recorrer toda la lista, creciendo cada vez más con el número de clientes. Para esta prueba el video seleccionado se encontraba replicado en todos los servidores, para solamente tener en cuenta el efecto de la búsqueda del mejor servidor. De no ser así se estaría agregando una mayor incertidumbre al análisis al no tener control de cuándo se copia el video hacia otros servidores.
A partir de las pruebas realizadas se evidencia la efectividad del servicio NewLocator, cumpliendo sus funciones de distribución de carga, mostrando que la decisión de crearlo fue la correcta, aun cuando se sacrifique el tiempo de respuesta al pedir un servidor. Si se quiere reducir este tiempo de respuesta la arquitectura permite crear dos o más particiones del grid y replicar el servicio de localización en este mismo número, haciendo a cada replica responsable de una partición y por ende reduciendo el número de clientes y de servidores que cada uno maneja.
7. TRABAJO FUTURO
Este trabajo muestra una solución al problema de elaborar una arquitectura utilizando tecnología estándar, que le permita a un usuario de un datagrid, la inserción de datos complejos dependientes del tiempo y su posterior consulta utilizando streaming.
Al realizar esta arquitectura se logro crear un servicio de scheduling efectivo, solo utilizado durante peticiones de servidores. Esta efectividad se logra a partir de la posibilidad que da la arquitectura de replicación de datos, no solo en momento de almacenamiento inicial, sino también a partir de la demanda de esta información.
El anterior problema no toma en cuenta los factores de seguridad, en cuanto a los permisos de ejecución, aseguramiento de la integridad de los datos y confidencialidad agregando un requerimiento de propiedad de los datos y autorización de los mismos.
Para la utilización de este tipo de aplicaciones a problemas más cotidianos, es necesario expandir esta aplicación de tal manera que sea capaz de realizar captura en tiempo real, creando la posibilidad de comunicación entre los clientes del datagrid.
Como se explicó en este trabajo fue necesario establecer una tabla con información relevante para poder consultar los videos. Para evitar que sea necesario generar toda esta metadata si se descubre la necesidad de mantener nueva información, es necesario lograr hacer las consultas no sobre un descriptor externo, sino sobre los datos directamente utilizando MPEG 7. Es necesario aclarar que este formato no es soportado por JMF, pero gracias a
que este motor puede ser extendido, existe la posibilidad de generar los codecs y plugins necesarios para la lograr su visualización y consulta.
8. CONCLUSIONES
Para entender las necesidades que tiene la transmisión de información multimedia sobre un datagrid a partir del uso de streaming se desarrollo este proyecto solamente considerando los problemas de transmisión en si, sin tener en cuenta problemas de seguridad o de integridad de información.
A través de este trabajo, se reconoció la necesidad de crear para cada nodo un representante, con la responsabilidad de controlar el manejo de puertos del nodo, y las consultas tanto al sistema como a los recursos que este nodo ofrezca al grid.
Para evitar problemas de entrega de información errónea, se vio la necesidad de crear una infraestructura externa, a partir de colas, que garantice la no existencia de concurrencia, de tal manera que se evite el desbordamiento de un servidor.
Se reconoce la necesidad de crear un servicio que cumpla con funciones de scheduling, de tal manera que se minimice la carga de todos y cada uno de
los servidores de video del datagrid, sacrificando eficiencia en el tiempo de respuesta a cualquier petición.
Se comprobó la efectividad y eficiencia de las tecnologías OGSA-DAI y Globus Toolkit 4 como middleware de alta calidad, que facilitan la creación de servicios independientes con posibilidad de colaborar entre si, economizando tiempo y asegurando eficacia.
Por decisiones de implementación el tipo de datos multimedia utilizados son los soportados por JMF, pero se asume que cualquier otro tipo de dato funciona si se lo logra extender este motor.
Dado que la transmisión de datos multimedia por medio de streaming se realiza por un canal a parte para cada componente del dato, la arquitectura presentada en este trabajo funciona para cualquier dato que pueda ser transmitido por este medio.
No se logro realizar el despliegue de sonido, al transmitir un video con audio, ni al transmitir un archivo de audio, cuando el servidor se encuentra en un nodo diferente al cliente, no se conoce la naturaleza del problema. Es posible que el responsable sea JMF o del sistema operacional en si. Este aspecto debe ser solucionado en trabajos posteriores
BIBLIOGRAFIA
[JMF2003] SUN MICROSYSTEMS, Java Media FrameWork API guide.
http://java.sun.com/products/java-media/jmf/2.1.1/guide/JMFPreface.html#999106
Visitado el 3 de Mayo de 2007
[JMF20031] SUN MICROSYSTEMS, Java Media FrameWork working with time-based media.
http://java.sun.com/products/javamedia/jmf/2.1.1/guide/JMFTBM.html Visitado el 3 de Mayo de 2007.
[RFC2003] NETWORK WORKING GROUG. RTP: a transport protocol for real time aplications
http://tools.ietf.org/html/rfc3550
Visitado el 6 de Mayo de 2007.
[SOT2006] SOTOMAYOR, Borja. CHILDERS Lisa. GLOBUS TOOLKIT 4, PROGRAMMING JAVA SERVICES. Editorial Elsevier. 2006
[FOS2006] FOSTER, Ian. Globus Toolkit 4. software for service oriented systems. Computation Institute, Argonne National Laboratory & University of Chicago, Argonne IL 60439 USA Accedido 11 de Mayo de 2007
[Ed20071] University of Edinburgh (2002). The OGSA-DAI project. Recuperado el 10 de Mayo de 2007 del sitio web de ogsadai: http://www.ogsadai.org
[Ed20072] University of Edinburgh (2002). OGSA-DAI Architecture. Recuperado el 10 de Mayo de 2007 del sitio web de ogsadai:
http://www.ogsadai.org/documentation/ogsadai-wsrf-2.2/doc/background/architecture.html
[JFS2007] SARAY, JOSE FRANCISCO.(2007) Diseño y validación de una arquitectura datagrid para inserción y consulta de una base de datos.
[GL2006] ALLCOCK, BILL GridFTP: protocol extension to FTP for the Grid. http://www.ggf.org/documents/GWD-R/GFD-R.020.pdf.
Consultado el 14 de mayo de 2007.
[VOD2006] Anabella Costa, Video on Demand, recuperado de
http://www.monografias.com/trabajos36/video-on-demand/video-on-demand.shtml el 18 de mayo de 2007.
[KM2003] DONELLA, BRIAN, Developing Systems to Support Organisational Learning in Product Development Organisations.
[P2P2003] Peer to peer internet video broadcasting
http://ezinearticles.com/?Peer-to-Peer-Internet-Video-Broadcasting&id=60862
Recuperado el 18 de mayo de 2007.
[SD2003] Introducción a los sistemas distribuidos. http://www.augcyl.org/?q=glol-intro-sistemas-distribuidos
Recuperado el 24 de mayo de 2007
[STR2004] Que es streaming
Recuperado el 24 de mayo de 2007
[CN2005] KOROSE, JAMES, Computer networking, a top-down approach featuring the internet
[GRT2003] GRID TODAY, Grid delivery enables full screen video on demand upgrade
[AK2007] COMPUTING CENTRE UNIVERSITY, Akogrimo proyect
http://www.akogrimo.org/download/White_Papers_and_Publications/Akogrimo_
WhitePaper_Overview.pdf
Recuperado el 25 de mayo de 2007.
[SIM2007] Grids for Industrial Product Development http://www.scai.fraunhofer.de/simdat.html
Recuperado el 25 de mayo de 2007
[GT2007] Grid Today Magazine
http://www.gridtoday.com/grid/1330929.html
Recuperado el 26 de Mayo de 2007.
[GT20072] Grid Today Magazine
http://www.gridtoday.com/grid/1050946.html
MANUAL DE INSTALACIÓN
En este capitulo se muestra al lector una guía paso por paso de la instalación del producto mostrado a lo largo de este trabajo, facilitando la demostración de este producto, y dando la posibilidad de incrementar el número de servidores o de clientes, para pruebas de otro tipo.
7.1 Prerrequisitos:
Para poder configurar el demo, se requiere tener un datagrid funcionando con los middleware Globus Toolkit 4.1 y OGSA-DAI WSRF 2.2 debidamente instalados en cada una de las máquinas que lo conforman.
Adicionalmente, cada uno de los computadores que harán parte de nuestro datagrid deberán tener el motor de bases de datos de MySQL versión para Linux x86 5.0.27, sobre el cual es necesario crear un nueva cuenta para “root” cuya clave debe ser “tesis2006” y una base de datos llamada mydatabase. También se requiere que en cada una de estas maquinas este instalado Java Media FrameWork versión para Linux 2.1.1e, al terminar esta instalación es necesario asegurarse de mover los archivos jmf.jar, sound.jar, mediaplayer.jar y multiplayer.jar encontrados en la carpeta lib de la instalación previa, y pasarlos a toda instalación de la maquina virtual de java específicamente en la carpeta lib/ext, si no se realiza esta operación la maquina virtual no reconocerá la instalación de JMF.
El siguiente procedimiento debe ser realizado ingresando a la maquina como el súper usuario ROOT:
Copie la carpeta instaladores en la maquina en el Escritorio de la en que desea instalar esta aplicación.
Dentro de esta carpeta se encuentran en la carpeta configuración/sqlScripts, los scripts de creación de las tablas servidores y video.
Entre a la cuenta MySQL como root e inicie la base de datos mydatabase utilizando el comando USE. En todas las maquinas que serán servidores cree la tabla video, ejecutando el archivo crear_video.sql encargada de contener los videos disponibles en cada servidor.
Solamente en la maquina que contendrá el servicio NewLocator, ejecute el archivo crear_servidor.sql encontrado en la carpeta mencionada anteriormente, creando la tabla servidores la cual es la encargada de mantener las direcciones IP de las maquinas que prestaran los servicios especificados en este trabajo.
Abra una terminal en Linux y vaya a la carpeta de Instaladores.
Ejecute el script “deployogsa.sh”, el cual instalara toda la infraestructura OGSA-DAI (DataService y DataResource) para el acceso a la base de datos mydatabase. Este debe ser ejecutado en todas las maquinas pertenecientes al datagrid.
Dentro de la carpeta globus4, crear una nueva carpeta llamada servidorVideos y en ella copie el archivo de propiedades “video.properties”, en el que se encuentran las direcciones IP de la cola y el localizador, y las cotas máximas de utilización.
De ahora en adelante es necesario trabajar ingresando a la maquina como usuario GLOBUS, esto es necesario no solo por seguridad, si no también
porque los certificados necesarios para la ejecución de GridFTP solo son generados para usuarios GLOBUS.
En la maquina en que se ubicara la cola correr el script “deployCola.sh” ubicado en la carpeta Instaladores/Cola, haciendo deploy al servicio QueueService.
De igual manera en la maquina en que se encontrara el servicio de localización, correr el script “deployLocator.sh” ubicado en la carpeta Instaladores/Locator, haciendo deploy al servicio NewLocator.
En las maquinas pertenecientes al datagrid, que tendrán funciones de servidor, correr el script “deploygars.sh” ubicado en la carpeta Instaladores/Servicios, haciendo deploy a los servicios Monitoreo3, AgregarVideoService y TransmitirFactory.
Por último encienda el contenedor de Globus en esta máquina: globus-start-container -nosec
En cada una de las maquinas que ejercerán la función de servidor, iniciar la aplicación cliente, y oprima el botón registrarServidor en la barra de menú, de tal forma que su dirección IP sea ingresada a la tabla servidores en la maquina donde esta ubicado el servicio NewLocator.
