Utilización de programación funcional distribuida y clusters Linux en el desarrollo de servidores de vídeo bajo demanda

Transcripción

1 Utilización de programación funcional distribuida y clusters Linux en el desarrollo de servidores de vídeo bajo demanda M. Barreiro, V. M. Gulías, J. Mosquera, J. J. Sánchez Universidade da Coruña Departamento de Computación Campus de Elviña A Coruña (SPAIN) {enano,gulias,mosky,juanjo}@lfcia.org Resumen El vídeo bajo demanda (VoD) es un servicio que permite al usuario solicitar cualquier contenido multimedia en cualquier momento, sin estar sujeto a programaciones preestablecidas. La mayoría de las soluciones actuales de este tipo poseen un coste elevado, además de poca flexibilidad y escalabilidad. El servidor que se describe en este artículo, diseñado con una arquitectura jerárquica, implementado mediante un lenguaje de programación funcional (Erlang) y construido sobre una arquitectura de clusters Linux de bajo coste (Beowulf), presenta características que permiten satisfacer la mayoría de los requisitos tradicionales que se le plantean a un servicio de este tipo. El sistema resultante se puede adaptar con flexibilidad a la topología de red subyacente y puede escalarse para soportar un número creciente de usuarios concurrentes, todo ello con una solución de bajo coste, utilizando ordenadores de consumo. Después un diseño inicial del sistema, donde la estructura jerárquica era estática y de tres capas especializadas (streaming, caché y almacenamiento masivo), y tras las primeras implementaciones y pruebas de rendimiento y adaptación, se ha ido evolucionando la arquitectura hacia un número variable de capas, compuestas por módulos con una interfaz conocida, dotando a la solución de una mayor capacidad de adaptación y versatilidad. Keywords: Programación Funcional, Programación Distribuida, Cluster, Linux, Erlang, Vídeo bajo Demanda. 1 Introducción Un servidor de Vídeo Bajo Demanda (Video On Demand, VoD) es un sistema que proporciona servicios de vídeo, en los cuales un usuario puede solicitar un VO (Video Object) en cualquier momento, sin restricciones temporales preestablecidas. Parcialmente financiado por FEDER TIC-1FD , Xunta de Galicia PGIDT99COM10502 y UDC

2 Los servicios de películas bajo demanda, herramientas de aprendizaje a distancia, o servicios informativos que permitan al usuario visualizar únicamente las noticias que le interesan, son algunos de los muchos ejemplos de aplicaciones multimedia que pueden hacer uso de este tipo de servidores. Los sistemas de vídeo bajo demanda deben satisfacer una serie de requisitos derivados de su funcionalidad, entre los cuales destacan: Gran capacidad de almacenamiento: en la mayoría de sus aplicaciones, el sistema deberá ser capaz de ofertar al usuario un amplio abanico de objetos multimedia, que serán almacenados de algún modo en la arquitectura del servidor. Gran ancho de banda: el hecho de que los contenidos multimedia se caracterizan por hacer uso de un elevado ancho de banda, unido a la necesidad de dar servicio a un número elevado de usuarios, hace necesario que el servidor sea capaz de aprovechar un gran ancho de banda. Tiempo de respuesta predecible: cuando un usuario solicite un objeto de vídeo, el sistema debe ser capaz de realizar, mediante estimaciones estadísticas que hagan uso del estado del sistema en ese momento, una aproximación del tiempo de espera. Además, el servidor debe tratar en todo momento de que el tiempo de espera sea el mínimo posible para todos los usuarios. Soportar a gran número de usuarios concurrentes: el sistema debe ser capaz de gestionar un número elevado de peticiones, que pueden realizarse al mismo tiempo. Tolerancia a fallos: un servidor de estas características, con un funcionamiento de 24 horas al día, necesita poseer mecanismos, tanto hardware como software, de reacción ante posibles fallos, cambio de código en caliente, etc. Además de los requisitos tradicionales en este tipo de servidores, a la solución presentada en este artículo se le han añadido otros tres, muy importantes, que condicionan las decisiones de diseño: Escalabilidad: el sistema debe ser capaz de dar servicio a un número reducido de usuarios en un contexto simple (escalabilidad hacia abajo), y de crecer mediante un incremento de los recursos utilizados en él, para dar soporte a un número cada vez mayor de usuarios concurrentes (escalabilidad hacia arriba). Adaptabilidad: se ha intentado diseñar un sistema que sea adaptable a la topología de red subyacente, haciendo un uso optimizado de las capacidades de dicha red. Bajo coste: se plantea el reto de satisfacer todos los requisitos anteriores con una arquitectura que permita reducir el coste de implementación y puesta en explotación de un sistema de estas características. En el presente artículo se plantea el diseño de un servidor de vídeo, su implementación, y las decisiones posteriores de rediseño y mejora, que permiten satisfacer de un modo óptimo todos los requisitos planteados con anterioridad. Para ello, se ha utilizado una arquitectura jerárquica y el paradigma funcional de programación, combinado con la programación paralela (Erlang). El artículo está estructurado del siguiente modo: en la sección 2 se hace un resumen del estado del arte relacionado con la implementación de servidores de VoD, en la sección 3 se hace una introducción al servidor de video propuesto, describiendo además el

3 cluster Beowulf utilizado para su implementación y las tecnologías clave usadas durante el desarrollo. Finalmente, en la sección 4, se exponen una serie de refinamientos a la idea original, encaminados a que el servidor cubra las necesidades en producción del sistema. 2 Estado del arte En los últimos años las empresas más importantes que comercializan productos multimedia han desarrollado sistemas relacionados con el vídeo bajo demanda. Algunas de las soluciones están más adaptadas a redes de bajo ancho de banda, como es el caso del RealVideo Server, de Real Networks, que hace uso de tecnologías de caché de los streams para optimizar el uso de una red con las características de Internet, o Microsoft Windows Media Server, que utiliza protocolos propietarios y puede ser utilizado en entornos de un mayor ancho de banda con un rendimiento menor. Otras soluciones se enfocan más a entornos LAN o MAN, con mayor disponibilidad de ancho de banda. Las más representativas son el Darwing Streaming Server [1], de Apple, que es la versión de código abierto del Quicktime Streaming Server, y sólo es un servidor de streaming RTP, sin incluir la gestión del almacenamiento distribuida como la que forma parte de la solución que se presenta; DB2 Digital Library Video Charger [19], de IBM; Oracle Video Server [13, 14], quizá el más utilizado de todos, con arquitectura cliente/servidor, pero con limitaciones de escalabilidad; Kassenna MediaBase, una evolución del WebForce MediaBase, de SGI, con características comunes al diseño presentado en este trabajo (modular, separación de funciones de adquisición, distribución y streaming, basado en sistemas UNIX), pero una menor flexibilidad y capacidad de adaptación; Philips WebCine Server [15], servidor de streaming MPEG4 basado en Linux; Cisco IP/TV [7], solución cerrada con herramientas orientadas al mercado de formación; y el sistema de SUN: StorEdge Media Central [17]. También existen soluciones de caja negra, que consisten en la combinación de un hardware especializado con alguno de los productos anteriores. En general, el análisis en detalle de estos productos, conduce a la conclusión de que la mayoría representan soluciones caras, cerradas, no escalables y no adaptables. En el contexto académico la mayoría de los proyectos poseen un carácter altamente experimental. En [4] se analiza una solución jerárquica para la construcción de servidores multimedia que ha sido tomada como fuente de inspiración para algunas de las ideas del servidor presentado en este proyecto. El Stony Brook Video Server Project [5, 6, 18] intenta crear un servidor distribuido que proporcione al usuario características de indexación, búsqueda y streaming de vídeos, y está desarrollada con una interesante arquitectura cliente servidor, adaptada para redes locales. En [8] se presenta una alternativa totalmente distinta a la expuesta en este artículo, utilizando una arquitectura de memoria compartida. Un estudio más detallado de algunas de estas soluciones se puede encontrar en [16]. 3 VoDKA: un servidor VoD funcional distribuido Para satisfacer todas las necesidades expuestas anteriormente, se propone una arquitectura innovadora, basada en un sistema de almacenamiento distribuido y jerárquico, construida sobre clusters Linux formados por componentes de consumo [3]: VoDKA (Video on Demand Kernel Architecture).

4 La arquitectura jerárquica permite dividir la funcionalidad del sistema entre los distintos niveles, dando lugar a una especialización mayor, que hace viable la satisfación de requisitos incompatibles a priori. Por ejemplo: la difícil convivencia entre un almacenamiento de alta capacidad y bajo coste y una elevada velocidad de respuesta tiene solución en la división en varias capas, que se describirá en detalle en la sección 3.1. Las conclusiones obtenidas tras la implementación del sistema con este primer planteamiento han permitido refinar el diseño de la arquitectura, dando lugar a una solución todavía más óptima, cuyas características se detallan en la sección 4. En las fases de análisis y diseño del sistema se han usado patrones de diseño [10], con sus correspondientes adaptaciones en el lenguaje de programación utilizado, y behaviours [9] (que representan la equivalencia a los patrones de diseño a más bajo nivel). El lenguaje de programación en el que se ha basado el desarrollo del sistema es Erlang/OTP [2], que presenta unas características ideales para la implementación de los subsistemas de monitorización, control y planificación. En algunos de los módulos de entrada salida, cuyo rendimiento es crítico para el funcionamiento óptimo del sistema, se ha utilizado C, tras una fase inicial de prototipado en Erlang/OTP. En todo momento se ha hecho énfasis en la reutilización, mediante el uso de herramientas de código abierto (Linux, Erlang/OTP), la adaptación de módulos de soluciones existentes para realizar adaptación de protocolos o formatos de fichero en nuestro servidor (Darwin), y la independización de subsistemas (OpenMonet [11], Inets mod xsl [12]). 3.1 Propuesta de diseño inicial La jerarquía de la arquitectura propuesta inicialmente (figura 1) se componía de tres niveles especializados, presentados ascendentemente en los párrafos siguientes: Nivel terciario (capa de almacenamiento masivo): el nivel del almacenamiento masivo no tiene los mismos requisitos en términos de tiempo de respuesta que los que se encuentran en los niveles superiores. Su objetivo es almacenar todos los objetos de vídeo disponibles en el servidor VoD por medio de cargadores de cintas, arrays de discos o cualquier otro medio de almacenamiento masivo. La vista abstracta de este nivel se reduce a un brazo mecánico con la tarea de cargar las cintas en una de las unidades lectoras, teniendo en cuenta que el número de estas unidades es limitado y no puede haber una unidad siempre disponible para cada cinta solicitada. El rendimiento del servidor depende a este nivel de factores de comportamiento tales como el tiempo de carga, latencia, cadencia (throughput), etc. Si bien es deseable optimizar estos parámetros cuantitativos, el nivel superior puede aliviar el peso que puedan tener en las medidas de rendimiento global, puesto que actúa como caché para los objetos de vídeo del nivel terciario. Nivel secundario (capa de caché): está compuesto por un conjunto de nodos, cada uno de ellos con capacidad de almacenamiento suficiente para albergar al menos un objeto de vídeo completo. El objeto, leído del nivel terciario, es almacenado temporalmente en un nodo antes de ser rebanado (proceso de striping) en el nivel primario. Una política de planificación apropiada se encargará de decidir cuáles son los vídeos que deben ser mantenidos en caché, y durante cuánto tiempo, para atender las peticiones futuras y limitar en lo posible los accesos al nivel de almacenamiento masivo. Nivel primario (capa de streaming): está compuesto por un conjunto de nodos encargados de hacer la adaptación de protocolos y de enviar al cliente final el

5 Tape loaders, jukeboxes... Tertiary level (massive storage) Cluster nodes with local storage Secondary level (large scale cache) Cluster heads Primary level (buffering and protocol adaptation) Output streams Figura 1: Estructura jerárquica inicial stream de vídeo en el formato adecuado. El interés de colocar un número sufiente de nodos en este nivel radica en la capacidad de cubrir el posible fallo de uno de los nodos asignando dinámicamente las tareas afectadas a otro nodo, limitando así la pérdida de calidad del servicio. Este nivel tiene requisitos importantes tanto en ancho de banda como en tiempo de respuesta Borg, el cluster Beowulf del LFCIA El cluster Borg (figura 2), utilizado para la implementación del sistema, está compuesto por 23 nodos más un nodo destacado como frontal. Cada uno de los nodos consta de un procesador AMD K6 300, 96MB de memoria, disco IDE de 4.2GB y 2 tarjetas de red Fast Ethernet. Por otro lado, el frontal es un Pentium II dual, 384MB de memoria, con tres tarjetas Fast Ethernet, una de ellas dedicada a la conexión con el exterior, siendo labor del frontal actuar como pasarela con las estaciones externas al cluster. Adicionalmente, el frontal actúa de servidor NFS para los nodos (dos discos SCSI de 4GB cada uno con RAID 0). La comunicación entre procesadores en el Beowulf se lleva a cabo mediante el uso de los protocolos de red estándar UNIX, en nuestro ejemplo particular sobre adaptadores Fast Ethernet. Por tanto, el rendimiento (throughput) y la latencia de la comunicación quedan establecidos por el adaptador Fast Ethernet así como por la sobrecarga introducida por el protocolo de comunicación. Sin embargo, Beowulf es capaz de mejorar el ancho de banda de la comunicación mediante el encaminado de paquetes a través de múltiples redes Ethernet (channel bonding). En Borg, la interconexión de los nodos se realiza mediante 4 switches de 24 puertos (3Com SuperStack II 3300) unidos en grupos de dos mediante un enlace de 1Gbit/s, definiendo de este modo dos redes independientes. De esta forma se puede emplear la técnica de channel bonding para aumentar el ancho de banda de la red, o bien se puede dedicar una red a labores administrativas como NFS utilizando TCP/IP, mientras que la otra utiliza un protocolo más ligero para la comunicación de procesos que colaboran

6 6 7 4 CPU 5 CPU... CPU CPU CPU... CPU frontend FORERUNNER 3810 (External world) 2 10 Mb Ethernet link 3 Dual Pentium II 350Mhz 384MB RAM 8GB HD SCSI 4 AMD K6 300Mhz 96MB RAM 4GB HD IDE (23, up to 47) Mb Fast Ethernet link (2 per node) 6 3COM SuperStack II Switch 3300 (4, 24 ports per switch) 7 1 Gb link (2 independent networks) Figura 2: Borg, el cluster Beowulf del LFCIA en un cálculo. La reconfiguración de la arquitectura genérica del Borg para adaptarse a la estructura jerárquica de tres niveles, se puede observar en la figura 3. Como nivel terciario se utiliza un nodo especializado con acceso a un robot de cintas; en el secundario, funcionando como caché de objetos de vídeo, se han colocado los 23 nodos del cluster; y como primario se ha colocado otro nodo especializado con mayores requisitos de memoria, como se puede ver en la figura. Las conexiones entre capas se realizan a través de los switches, y el frontend del cluster actúa de nodo de administración. 3.2 Tecnologías clave Además de la arquitectura innovadora presentada, dos de las más importantes características diferenciadoras de la solución propuesta son la utilización de un lenguaje funcional y la adaptación a una arquitectura basada en clusters Linux Erlang/OTP El lenguaje utilizado, Erlang, ha sido diseñado y utilizado en el laboratorio de computación (CSLab) de Ericsson para la programación de sus sistemas de control distribuidos. La combinación del paradigma funcional y la computación paralela dan lugar a un lenguaje declarativo, sin efectos colaterales, y con un alto nivel de expresividad, abstracción y facilidad para el prototipado. Erlang es especialmente adecuado para sistemas de tiempo real blandos (soft real time) distribuidos y tolerantes a fallos. Se trata de un lenguaje basado en paso de mensajes asíncrono, transporte transparente de valores y comunicaciones de orden superior, que posee capacidad para dar soporte a un número elevado de procesos concurrentes. El lenguaje es adecuado para el desarrollo de sistemas distribuidos y permite la ubicación transparente de procesos en distintos nodos. Incluye además primitivas para el soporte de tolerancia a fallos y proporciona facilidades para el reemplazamiento en caliente de código, sin necesidad de detener el sistema para ello. A mayores del lenguaje, la solución propuesta utiliza ampliamente las bibliotecas y los patrones de diseño distribuido de la Open Telecom Platform (OTP), que incluye

7 K MB Bus 32 bits Alpha Server DS20 Buses 64 bits borg24 ( ) 3COM Superstack II 3300 Borg0 borg0 1 ( ) borg borg23 1 ( ) borg0 0 ( ) borg borg23 0 ( ) AutoPAK VXA Tape Charger (~8.000) 3 SCSI: 2 cabezas, 1 brazo mecánico 15 slots para cintas de 33GB * ~100 películas de dos horas a 300Kb/s * ~15 películas de dos horas a 2Mb/s Cada cabeza: 5 Mb/s Figura 3: Adaptación del Borg a la estructura jerárquica del servidor servidores genéricos, mecanismos de supervisión, una base de datos distribuida (Mnesia) con transparencia de ubicación, fragmentación, replicación, e integración con el lenguaje, y numerosas bibliotecas de integración: SNMP, ASN.1, Interfaz C, Corba, Java,. Todas las características citadas hacen de Erlang un lenguaje muy adecuado para el desarrollo del sistema propuesto Cluster Linux La utilización en la solución que se plantea en este trabajo de clusters Beowulf (arquitectura distribuida de bajo coste basada en Linux) ha sido otra de las claves que hacen del servidor propuesto una arquitectura innovadora, además de diferenciarlo de la mayoría de las soluciones comerciales existentes. La arquitectura de memoria distribuida se complementa a la perfección con la filosofía de paso de mensajes del lenguaje utilizado. Algunas de las ventajas derivadas de la utilización de esta tecnología se detallan a continuación: La existencia de una amplia experiencia en la comunidad OpenSource en el trabajo con redes de alta velocidad, sistemas distribuidos y clustering sobre linux es un factor importante a la hora de escoger esta arquitectura. La disponibilidad de código fuente: posibilidad de modificar cualquier parte del software para adaptarlo, corregirlo, localizar problemas o instrumentarlo. Licencia homogénea (GPL): simplicidad de tratamiento legal (vs. por ejemplo situación actual MPEG4, donde cada componente tiene una licencia distinta y su interacción a veces es incómoda y hasta contradictoria).

8 VODKA Monitor Monitor Monitor Stream Streaming n cache levels RTP H.263 Frontend Frontend Streamer (TAPE) () Figura 4: Servidor VoDKA con n niveles de caché Compatibilidad: código desarrollado en Linux se portará sin problemas a Solaris, AIX, Tru64, IRIX, etc. Respeto de estándares (POSIX 1003.*, SVID, 4.xBSD). Buen rendimiento. Amplia disponibilidad de herramientas de desarrollo. Extensivo soporte de diferentes plataformas hardware (x86, Alpha, SPARC, ARM, S/390 (zseries), IA64, SH3, MIPS...). 4 Refinamiento del diseño Las ideas del diseño original deben ser ligeramente modificadas para cubrir las necesidades en producción del sistema. En particular, resulta necesaria una flexibilización del diseño, toda vez que la arquitectura jerárquica en tres niveles (streaming, caché y almacenamiento) puede ser excesivamente sofisticada en instalaciones pequeñas y demasiado rígida en redes con una topología compleja como una red de interconexión de redes metropolitanas. Esta redefinición de la arquitectura jerárquica da lugar a una arquitectura en múltiples niveles especializados, compartiendo cada uno de los niveles una misma interfaz (figura 4). De esta forma, por ejemplo, puede suprimirse el nivel de caché, implementar una jerarquía de múltiples niveles de caché adaptando la propia topología de la red subyacente (figura 5) o disponer de múltiples niveles de almacenamiento distribuidos físicamente. Incluso cabe la posibilidad de que un servidor utilice como soporte de almacenamiento otro servidor VoD dando lugar a un metaservidor VoD. Además de la flexibilidad en cuanto a la distribución física del sistema, resulta necesario que el sistema sea capaz, dentro de cada nivel y entre cada par de niveles, interaccionar utilizando protocolos de almacenamiento y transferencia heterogéneos. Esta flexibilización pasa por identificar los patrones de comunicación entre los distintos niveles factorizándolos como abstracciones funcionales (pipe, para las transferencias dentro de un nodo, y transfer, para transferencias entre nodos) parametrizadas por cierres funcionales que encapsulan las particularidades de los protocolos utilizados y que son establecidos

9 Grupo de Almacenamiento Almacenamiento (réplica) Caché en nodo de red primario Caché en nodo de red secundario Streamer en nodo final Usuarios finales RED TRONCAL PRIMARIA Caché en nodo de red primario Caché en nodo de red secundario Streamer en nodo final Almacenamiento (principal) Streamer en nodo final Usuarios finales Almacenamiento Caché N2 Caché N1 Streaming Figura 5: Despliegue del servidor VoD sobre una topología compleja por los planificadores que colaboran en la realización de un determinado servicio. Esta generalidad de los controladores de cada nivel obliga a la utilización de mecanismos genéricos de monitorización y de programación reflexiva para descubrir las características de cada nivel. Merece la pena comentar la importancia de mantener el sistema independiente respecto a formatos de distribución de contenidos multimedia digitales, actualmente en constante cambio, hasta la parte final de distribución de los contenidos (streamer) en el cual se efectúa laa adaptación de protocolos requerida: frontal de http progresivo, frontal RTP, etc. La primera separación lógica en el servicio de vídeo bajo demanda es la que diferencia el servidor de vídeo, núcleo implementado fundamentalmente con tecnología funcional distribuida y desplegada sobre clusters tipo Beowulf, y los distintos servidores de aplicaciones que, utilizando la distribución de vídeo ofertada por el servidor VoD, definen servicios de usuario final (figura 6). Las aplicaciones, desarrolladas utilizando tecnología convencional, interaccionan con el servidor de vídeo redirigiendo a éste peticiones de objetos multimedia determinados; además, las aplicaciones se nutren de la información recolectada por los elementos de monitorización de VoD. Las aplicaciones típicas comprenden cine y televisión a la carta, teleformación, comercio electrónico, noticiario, etc. La figura 7 muestra un ejemplo de cómo se produce la transferencia de información desde los niveles de almacenamiento hasta el streaming del objeto en un sistema simplificado en el que se eliminan los niveles de caché. En este caso, la solicitud del cliente es recogida por un frontal ( frontend) que define la adaptación de protocolo requerida para una distribución progressive download sobre de un objeto multimedia MO. Este interacciona con su planificador (Streaming ) a través del agrupador de adaptadores en el que está integrado ( ) decidiendo la forma en que se distribuirá finalmente el stream de vídeo (DD1, en este caso instanciado a una adaptación en un puerto negociado con el cliente). El planificador del nivel de streaming propaga la solicitud de MO a su sucesor en la cadena de responsabilidad [10] incorporando el protocolo que debe utilizar el almacenamiento para su transferencia (DD2, en este caso una

10 Video On Demand Kernel Architecture Smirnoff SERVER VODKA Relevant Data Observer Request1 Request2(MO) Response1 SERVLETS XSLT Consults Consults Management Data (MO) Agent Management Subsystem Figura 6: Separación entre servidor VoD y una aplicación Web comunicación TCP/IP). El sucesor, el planificador de almacenamiento ( ), propaga la petición hacia un multiplexor de almacenamientos ( ), al que a su vez se conectan distintos dispositivos de almacenamiento: un sistema de ficheros montado (File ), un robot de cintas (Tape ) e incluso un servidor web ( ). La labor del planificador es decidir la fuente que utilizará para obtener el objeto MO (en el ejemplo el File ), construyendo un proceso pipe que conecta dicha fuente de datos con el protocolo de transferencia sugerido por el planificador de streaming, el cual crea una nueva pipe para recoger la transferencia de almacenamiento y enviarla a través del destino sugerido por el adaptador. Como muestra de la flexibilidad en la configuración del servidor VoDKA, la figura 8 presenta un esquema de cómo se distribuyen las responsabilidades entre los distintos nodos del cluster Borg. En el nodo borg25 reside el almacenamiento masivo, alojando un planificador de almacenamiento asociado con dos controladores de almacenamiento (unidad de CD y robot de cinta con 0.5 TB de capacidad). El planificador de almacenamiento es el sucesor en la cadena de responsabilidad de un planificador de caché que reside en el nodo borg24 y que utiliza como caché el ancho de banda agregado de controladores de caché locales en los nodos borg1...borg23. El propio nodo borg24 hospeda un planificador de streaming cuyo sucesor es el planificador de caché, soportando un adaptador de progressive download utilizando que sirve al laboratorio utilizando la red departamental conmutada a 10Mbps. El servidor covas aloja un planificador de caché, cuyo sucesor es el planificador de caché de borg24 (dos niveles de caché), y un controlador de caché local. Además, el servidor contiene un planificador de streaming alimentado por el planificador de caché y soportando un adaptador de progressive download utilizando, utilizando el adaptador ATM conectado directamente a la red troncal de la Universidad. borg0, el frontal del cluster Borg, se utiliza para monitorización del sistema.

11 VODKA Monitor Monitor RTP Stream MO DD2 Streaming MO DD2 lookup lookup lookup MO lookupans(a) lookupans(a) lookupans(a,b,c) DD1 lookup f(state,mo)={ds1,dd2} lookup lookup lookupans(a) f(state,mo)=ds2 lookupans(a) lookupans(b) lookup lookupans(c) H.263 MO Frontend Frontend Streamer transfer (TAPE) PIPE TCP DD1 DS1 Video Stream TCP PIPE FILE DD2 DS2 () STREAM I/O STORAGE I/O Figura 7: Ejemplo de transferencia en un sistema sin caché borg24 borg25 Streaming 100Mb/s 10Mb/s Frontend Streamer 10Mb/s Streaming 100Mb/s 100Mb/s 100Mb/s (TAPE) Streamer ATM Frontend covas borg1 borg22 borg23 Figura 8: Configuración de Borg en el campus universitario

12 5 Conclusiones Se ha desarrollado un servidor de vídeo bajo demanda que cumple con los requisitos básicos que han de tener este tipo de sistemas: gran capacidad de almacenamiento, gran ancho de banda, tiempo de respuesta predecible, gran número de usuarios concurrentes y tolerancia a fallos. A partir de un servidor de estas características, se ha evolucionado para que cumpla satisfactoriamente otras no menos importantes: escalabilidad tanto hacia arriba como hacia abajo, adaptabilidad a distintas topologías de red de distribución y bajo coste. Esto ha sido posible en gran medida gracias al uso de tecnologías clave como el lenguaje Erlang, aplicando sobre el conocidos patrones de diseño, y los clusters Beowulf. En la actualidad el sistema está pendiente de refinamiento de las fases de planificación y de añadir nuevos módulos para el soporte de diferentes formatos y protocolos de distribución de los objetos multimedia. Así mismo, es necesario implementar una completa serie de aplicaciones externas, que interactuen entre los usuarios y el servidor, antes de que se ponga finalmente en explotación a través de un operador de cable y llegue a los hogares del público. Referencias [1] Apple Computer Inc. About Darwin Streaming Server en [2] J. Armstrong, R. Virding, C. Wikström, M. Williams. Concurrent Programming in Erlang. Second Edition, Prentice-Hall [3] M. Barreiro, V. M. Gulías, Cluster setup and its administration. In Rajkumar Buyya, editor, High Performance Cluster Computing, Vol. I. Prentice Hall, [4] S. G. Chan and F. Tobagi Hierarchical storage systems for interactive Video-ondemand Technical Report, Stanford University, Computer Systems Laboratory, Number CSL-TR , p [5] T. Chiueh, C. Venkatramani, M. Vernick, Design and Implementation of the Stony Brook Video Server. Software Practice and Experience [6] T. Chiueh, M. Vernick, C. Venkatramani, Performance Evaluation of Stony Brook Video Server. ECSL-TR [7] Cisco Systems, Inc. A Distributed Video Server Architecture for Flexible Enterprise- Wide Video Delivery en wp.htm, White Paper, [8] D. Du, J. Hsieh, J. Liu, Building Video-on-Demand servers Using Shared-Memory Multiprocessors. Distributed Multimedia Research Center and Computer Science Department, University of Minnesota, and Ronald J. Vetter, Computer Science Department, North Dakota State University [9] U. Ekström, Design Patterns for simulation en ERLANG/OTP. Master Thesis, Universidad de Upsala, Suecia, 2000

13 [10] E. Gamma, R. Helm, R. Johnson, and J.Vlissides. Design Patterns: Elements of Reusable Object-oriented Software. Addison Wesley, Reading, [11] LFCIA, OpenMonet Project. en [12] LFCIA, Erlatron Project. [13] Oracle, Oracle Video Server Administrators Guide and Command Reference Release 3.0 for UNIX, [14] Oracle, Oracle Video Server System Technical Overview Release 3.0 for UNIX. Oracle White Paper, [15] Philips, WebCine Server en [16] J.J. Sánchez, V.M. Gulías, A. Valderruten, J. Mosquera. State of the Art and Design of VOD Systems. Proceedings of the International Conference on Information Systems Analysis, SCI 00-ISAS 00. ISBN , Orlando, USA, July [17] Sun Microsystems Inc. Sun StorEdge Media Central Streaming Server en [18] M. Vernick, C. Venkatramani, T. Chiueh, Adventures in Building The Stony Brook Video Server. Proceedings of ACM Multimedia 96, Boston, MA [19] P. Wilkinson, M. DeSisto, H. Rother, Y. Wong. IBM VideoCharger 101. IBM Redbook. International Technical Support Organization