Utilizacion de programacion 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. Sanchez

Universidade da Coruna

Departamento de Computacion

Campus de Elvina – 15071 A Coruna (SPAIN)

e-mail: {enano,gulias,mosky,juanjo}@lfcia.org

Resumen

El vıdeo bajo demanda (VoD) es un servicio que permite al usuario solicitar cual-quier contenido multimedia en cualquier momento, sin estar sujeto a programacionespreestablecidas. La mayorıa de las soluciones actuales de este tipo poseen un costeelevado, ademas de poca flexibilidad y escalabilidad.

El servidor que se describe en este artıculo, disenado con una arquitecturajerarquica, implementado mediante un lenguaje de programacion funcional (Er-lang) y construido sobre una arquitectura de clusters Linux de bajo coste (Beo-wulf), presenta caracterısticas que permiten satisfacer la mayorıa de los requisitostradicionales que se le plantean a un servicio de este tipo.

El sistema resultante se puede adaptar con flexibilidad a la topologıa de redsubyacente y puede escalarse para soportar un numero creciente de usuarios concu-rrentes, todo ello con una solucion de bajo coste, utilizando ordenadores de consumo.

Despues un diseno inicial del sistema, donde la estructura jerarquica era estaticay de tres capas especializadas (streaming, cache y almacenamiento masivo), y traslas primeras implementaciones y pruebas de rendimiento y adaptacion, se ha idoevolucionando la arquitectura hacia un numero variable de capas, compuestas pormodulos con una interfaz conocida, dotando a la solucion de una mayor capacidadde adaptacion y versatilidad.

Keywords: Programacion Funcional, Programacion Distribuida, Cluster, Linux,Erlang, Vıdeo bajo Demanda.

1 Introduccion

Un servidor de Vıdeo Bajo Demanda (Video On Demand, VoD) es un sistema que pro-porciona 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-1FD97-1759, Xunta de Galicia PGIDT99COM10502 yUDC 2000-5050252026

Los servicios de pelıculas bajo demanda, herramientas de aprendizaje a distancia, oservicios informativos que permitan al usuario visualizar unicamente las noticias que leinteresan, son algunos de los muchos ejemplos de aplicaciones multimedia que puedenhacer uso de este tipo de servidores.

Los sistemas de vıdeo bajo demanda deben satisfacer una serie de requisitos derivadosde su funcionalidad, entre los cuales destacan:

• Gran capacidad de almacenamiento: en la mayorıa de sus aplicaciones, el sistemadebera ser capaz de ofertar al usuario un amplio abanico de objetos multimedia,que seran almacenados de algun modo en la arquitectura del servidor.

• Gran ancho de banda: el hecho de que los contenidos multimedia se caracterizan porhacer uso de un elevado ancho de banda, unido a la necesidad de dar servicio a unnumero elevado de usuarios, hace necesario que el servidor sea capaz de aprovecharun gran ancho de banda.

• Tiempo de respuesta predecible: cuando un usuario solicite un objeto de vıdeo, elsistema debe ser capaz de realizar, mediante estimaciones estadısticas que haganuso del estado del sistema en ese momento, una aproximacion del tiempo de espera.Ademas, el servidor debe tratar en todo momento de que el tiempo de espera seael mınimo posible para todos los usuarios.

• Soportar a gran numero de usuarios concurrentes: el sistema debe ser capaz degestionar un numero elevado de peticiones, que pueden realizarse al mismo tiempo.

• Tolerancia a fallos: un servidor de estas caracterısticas, con un funcionamiento de24 horas al dıa, necesita poseer mecanismos, tanto hardware como software, dereaccion ante posibles fallos, cambio de codigo en caliente, etc.

Ademas de los requisitos tradicionales en este tipo de servidores, a la solucion pre-sentada en este artıculo se le han anadido otros tres, muy importantes, que condicionanlas decisiones de diseno:

• Escalabilidad: el sistema debe ser capaz de dar servicio a un numero reducido deusuarios en un contexto simple (escalabilidad hacia abajo), y de crecer medianteun incremento de los recursos utilizados en el, para dar soporte a un numero cadavez mayor de usuarios concurrentes (escalabilidad hacia arriba).

• Adaptabilidad: se ha intentado disenar un sistema que sea adaptable a la topologıade 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 ar-quitectura que permita reducir el coste de implementacion y puesta en explotacionde un sistema de estas caracterısticas.

En el presente artıculo se plantea el diseno de un servidor de vıdeo, su implementacion,y las decisiones posteriores de rediseno y mejora, que permiten satisfacer de un modooptimo todos los requisitos planteados con anterioridad. Para ello, se ha utilizado unaarquitectura jerarquica y el paradigma funcional de programacion, combinado con laprogramacion paralela (Erlang).

El artıculo esta estructurado del siguiente modo: en la seccion 2 se hace un resumendel estado del arte relacionado con la implementacion de servidores de VoD, en la sec-cion 3 se hace una introduccion al servidor de video propuesto, describiendo ademas el

cluster Beowulf utilizado para su implementacion y las tecnologıas clave usadas duranteel desarrollo. Finalmente, en la seccion 4, se exponen una serie de refinamientos a la ideaoriginal, encaminados a que el servidor cubra las necesidades en produccion del sistema.

2 Estado del arte

En los ultimos anos las empresas mas importantes que comercializan productos multi-media han desarrollado sistemas relacionados con el vıdeo bajo demanda.

Algunas de las soluciones estan mas adaptadas a redes de bajo ancho de banda,como es el caso del RealVideo Server, de Real Networks, que hace uso de tecnologıas decache de los streams para optimizar el uso de una red con las caracterısticas de Internet, oMicrosoft Windows Media Server, que utiliza protocolos propietarios y puede ser utilizadoen entornos de un mayor ancho de banda con un rendimiento menor.

Otras soluciones se enfocan mas a entornos LAN o MAN, con mayor disponibilidadde ancho de banda. Las mas representativas son el Darwing Streaming Server [1], deApple, que es la version de codigo abierto del Quicktime Streaming Server, y solo es unservidor de streaming RTP, sin incluir la gestion del almacenamiento distribuida como laque forma parte de la solucion que se presenta; DB2 Digital Library Video Charger [19],de IBM; Oracle Video Server [13, 14], quiza el mas utilizado de todos, con arquitec-tura cliente/servidor, pero con limitaciones de escalabilidad; Kassenna MediaBase, unaevolucion del WebForce MediaBase, de SGI, con caracterısticas comunes al diseno pre-sentado en este trabajo (modular, separacion de funciones de adquisicion, distribucion ystreaming, basado en sistemas UNIX), pero una menor flexibilidad y capacidad de adap-tacion; Philips WebCine Server [15], servidor de streaming MPEG4 basado en Linux;Cisco IP/TV [7], solucion cerrada con herramientas orientadas al mercado de formacion;y el sistema de SUN: StorEdge Media Central [17]. Tambien existen soluciones de cajanegra, que consisten en la combinacion de un hardware especializado con alguno de losproductos anteriores.

En general, el analisis en detalle de estos productos, conduce a la conclusion de quela mayorıa representan soluciones caras, cerradas, no escalables y no adaptables.

En el contexto academico la mayorıa de los proyectos poseen un caracter altamenteexperimental. En [4] se analiza una solucion jerarquica para la construccion de servidoresmultimedia que ha sido tomada como fuente de inspiracion para algunas de las ideas delservidor presentado en este proyecto. El Stony Brook Video Server Project [5, 6, 18] inten-ta crear un servidor distribuido que proporcione al usuario caracterısticas de indexacion,busqueda y streaming de vıdeos, y esta desarrollada con una interesante arquitecturacliente servidor, adaptada para redes locales. En [8] se presenta una alternativa total-mente distinta a la expuesta en este artıculo, utilizando una arquitectura de memoriacompartida.

Un estudio mas 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 arqui-tectura innovadora, basada en un sistema de almacenamiento distribuido y jerarquico,construida sobre clusters Linux formados por componentes de consumo [3]: VoDKA(Video on Demand Kernel Architecture).

La arquitectura jerarquica permite dividir la funcionalidad del sistema entre los dis-tintos niveles, dando lugar a una especializacion mayor, que hace viable la satisfacionde requisitos incompatibles a priori. Por ejemplo: la difıcil convivencia entre un alma-cenamiento de alta capacidad y bajo coste y una elevada velocidad de respuesta tienesolucion en la division en varias capas, que se describira en detalle en la seccion 3.1.

Las conclusiones obtenidas tras la implementacion del sistema con este primer plan-teamiento han permitido refinar el diseno de la arquitectura, dando lugar a una soluciontodavıa mas optima, cuyas caracterısticas se detallan en la seccion 4.

En las fases de analisis y diseno del sistema se han usado patrones de diseno [10],con sus correspondientes adaptaciones en el lenguaje de programacion utilizado, y beha-viours [9] (que representan la equivalencia a los patrones de diseno a mas bajo nivel).

El lenguaje de programacion en el que se ha basado el desarrollo del sistema esErlang/OTP [2], que presenta unas caracterısticas ideales para la implementacion de lossubsistemas de monitorizacion, control y planificacion. En algunos de los modulos deentrada salida, cuyo rendimiento es crıtico para el funcionamiento optimo del sistema, seha utilizado C, tras una fase inicial de prototipado en Erlang/OTP.

En todo momento se ha hecho enfasis en la reutilizacion, mediante el uso de herra-mientas de codigo abierto (Linux, Erlang/OTP), la adaptacion de modulos de solucionesexistentes para realizar adaptacion de protocolos o formatos de fichero en nuestro servidor(Darwin), y la independizacion de subsistemas (OpenMonet [11], Inets mod xsl [12]).

3.1 Propuesta de diseno inicial

La jerarquıa de la arquitectura propuesta inicialmente (figura 1) se componıa de tresniveles especializados, presentados ascendentemente en los parrafos siguientes:

• Nivel terciario (capa de almacenamiento masivo): el nivel del almacenamiento ma-sivo no tiene los mismos requisitos en terminos de tiempo de respuesta que los quese encuentran en los niveles superiores. Su objetivo es almacenar todos los objetosde vıdeo disponibles en el servidor VoD por medio de cargadores de cintas, arraysde discos o cualquier otro medio de almacenamiento masivo. La vista abstracta deeste nivel se reduce a un brazo mecanico con la tarea de cargar las cintas en una delas unidades lectoras, teniendo en cuenta que el numero de estas unidades es limita-do y no puede haber una unidad siempre disponible para cada cinta solicitada. Elrendimiento del servidor depende a este nivel de factores de comportamiento talescomo el tiempo de carga, latencia, cadencia (throughput), etc. Si bien es deseableoptimizar estos parametros cuantitativos, el nivel superior puede aliviar el peso quepuedan tener en las medidas de rendimiento global, puesto que actua como cachepara los objetos de vıdeo del nivel terciario.

• Nivel secundario (capa de cache): esta compuesto por un conjunto de nodos, cadauno de ellos con capacidad de almacenamiento suficiente para albergar al menosun objeto de vıdeo completo. El objeto, leıdo del nivel terciario, es almacenadotemporalmente en un nodo antes de ser “rebanado” (proceso de striping) en elnivel primario. Una polıtica de planificacion apropiada se encargara de decidircuales son los vıdeos que deben ser mantenidos en cache, y durante cuanto tiempo,para atender las peticiones futuras y limitar en lo posible los accesos al nivel dealmacenamiento masivo.

• Nivel primario (capa de streaming): esta compuesto por un conjunto de nodosencargados de hacer la adaptacion de protocolos y de enviar al cliente final el

Tertiary level(massive storage)

Secondary level(large scale cache)

Primary level(buffering andprotocol adaptation)

Output streams

Tape loaders, jukeboxes...

Cluster nodes withlocal storage

Cluster heads

Figura 1: Estructura jerarquica inicial

stream de vıdeo en el formato adecuado. El interes de colocar un numero sufientede nodos en este nivel radica en la capacidad de cubrir el posible fallo de uno delos nodos asignando dinamicamente las tareas afectadas a otro nodo, limitando asıla perdida de calidad del servicio. Este nivel tiene requisitos importantes tanto enancho de banda como en tiempo de respuesta.

3.1.1 Borg, el cluster Beowulf del LFCIA

El cluster Borg (figura 2), utilizado para la implementacion del sistema, esta compuestopor 23 nodos mas un nodo destacado como frontal. Cada uno de los nodos consta de unprocesador AMD K6 300, 96MB de memoria, disco IDE de 4.2GB y 2 tarjetas de red FastEthernet. Por otro lado, el frontal es un Pentium II dual, 384MB de memoria, con trestarjetas Fast Ethernet, una de ellas dedicada a la conexion con el exterior, siendo labordel frontal actuar como pasarela con las estaciones externas al cluster. Adicionalmente,el frontal actua de servidor NFS para los nodos (dos discos SCSI de 4GB cada uno conRAID 0).

La comunicacion entre procesadores en el Beowulf se lleva a cabo mediante el uso delos protocolos de red estandar UNIX, en nuestro ejemplo particular sobre adaptadoresFast Ethernet. Por tanto, el rendimiento (throughput) y la latencia de la comunicacionquedan establecidos por el adaptador Fast Ethernet ası como por la sobrecarga introduci-da por el protocolo de comunicacion. Sin embargo, Beowulf es capaz de mejorar el anchode banda de la comunicacion mediante el encaminado de paquetes a traves de multiplesredes Ethernet (channel bonding).

En Borg, la interconexion 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 latecnica de channel bonding para aumentar el ancho de banda de la red, o bien se puedededicar una red a labores administrativas como NFS utilizando TCP/IP, mientras quela otra utiliza un protocolo mas ligero para la comunicacion de procesos que colaboran

6 7

CPUCPU CPU ...CPUCPUCPU4

5

...

3

frontend1

2

1

2

3

4

5

6

7

6

5

4

1 Gb link (2 independent networks)

FORERUNNER 3810 (External world)

Dual Pentium II 350Mhz 384MB RAM 8GB HD SCSI10 Mb Ethernet link

3COM SuperStack II Switch 3300 (4, 24 ports per switch) 100 Mb Fast Ethernet link (2 per node)AMD K6 300Mhz 96MB RAM 4GB HD IDE (23, up to 47)

Figura 2: Borg, el cluster Beowulf del LFCIA

en un calculo.La reconfiguracion de la arquitectura generica del Borg para adaptarse a la estructura

jerarquica de tres niveles, se puede observar en la figura 3. Como nivel terciario se utilizaun nodo especializado con acceso a un robot de cintas; en el secundario, funcionando comocache de objetos de vıdeo, se han colocado los 23 nodos del cluster; y como primario seha colocado otro nodo especializado con mayores requisitos de memoria, como se puedever en la figura. Las conexiones entre capas se realizan a traves de los switches, y elfrontend del cluster actua de nodo de administracion.

3.2 Tecnologıas clave

Ademas de la arquitectura innovadora presentada, dos de las mas importantes carac-terısticas diferenciadoras de la solucion propuesta son la utilizacion de un lenguaje fun-cional y la adaptacion a una arquitectura basada en clusters Linux.

3.2.1 Erlang/OTP

El lenguaje utilizado, Erlang, ha sido disenado y utilizado en el laboratorio de computa-cion (CSLab) de Ericsson para la programacion de sus sistemas de control distribuidos.La combinacion del paradigma funcional y la computacion paralela dan lugar a un len-guaje declarativo, sin efectos colaterales, y con un alto nivel de expresividad, abstracciony facilidad para el prototipado.

Erlang es especialmente adecuado para sistemas de tiempo real “blandos” (soft realtime) distribuidos y tolerantes a fallos. Se trata de un lenguaje basado en paso de men-sajes asıncrono, transporte transparente de valores y comunicaciones de orden superior,que posee capacidad para dar soporte a un numero elevado de procesos concurrentes. Ellenguaje es adecuado para el desarrollo de sistemas distribuidos y permite la ubicaciontransparente de procesos en distintos nodos. Incluye ademas primitivas para el soportede tolerancia a fallos y proporciona facilidades para el reemplazamiento “en caliente” decodigo, sin necesidad de detener el sistema para ello.

A mayores del lenguaje, la solucion propuesta utiliza ampliamente las bibliotecasy los patrones de diseno distribuido de la Open Telecom Platform (OTP), que incluye

Borg0

borg1−1 ... borg23−1 (192.168.155.1...23)

borg1−0 ... borg23−0 (192.168.154.1...23)

borg24 (192.168.155.24)

borg0−0 (192.168.154.254)

borg0−1 (192.168.155.254)

3COM Superstack II 3300

3 SCSI: 2 cabezas, 1 brazo mecánico15 slots para cintas de 33GB * ~100 películas de dos horas a 300Kb/s

* ~15 películas de dos horas a 2Mb/sCada cabeza: 5 Mb/s

AutoPAK VXA Tape Charger (~8.000)

Alpha Server DS20 Buses 64 bitsK7 500 128MB Bus 32 bits

Figura 3: Adaptacion del Borg a la estructura jerarquica del servidor

servidores genericos, mecanismos de supervision, una base de datos distribuida (Mnesia)con transparencia de ubicacion, fragmentacion, replicacion, e integracion con el lenguaje,y numerosas bibliotecas de integracion: SNMP, ASN.1, Interfaz C, Corba, Java, HTTP.

Todas las caracterısticas citadas hacen de Erlang un lenguaje muy adecuado para eldesarrollo del sistema propuesto.

3.2.2 Cluster Linux

La utilizacion en la solucion que se plantea en este trabajo de clusters Beowulf (arqui-tectura distribuida de bajo coste basada en Linux) ha sido otra de las claves que hacendel servidor propuesto una arquitectura innovadora, ademas de diferenciarlo de la ma-yorıa de las soluciones comerciales existentes. La arquitectura de memoria distribuida secomplementa a la perfeccion con la filosofıa de paso de mensajes del lenguaje utilizado.

Algunas de las ventajas derivadas de la utilizacion de esta tecnologıa se detallan acontinuacion:

• La existencia de una amplia experiencia en la comunidad OpenSource en el trabajocon redes de alta velocidad, sistemas distribuidos y clustering sobre linux es unfactor importante a la hora de escoger esta arquitectura.

• La disponibilidad de codigo fuente: posibilidad de modificar cualquier parte delsoftware para adaptarlo, corregirlo, localizar problemas o instrumentarlo.

• Licencia homogenea (GPL): simplicidad de tratamiento legal (vs. por ejemplosituacion actual MPEG4, donde cada componente tiene una licencia distinta y suinteraccion a veces es incomoda y hasta contradictoria).

levelsn cache

Storage

(TAPE)Driver

Storage Driver(File)

StorageGroup

(HTTP)Driver

StorageDriver(File)

Cache Cache Driver(File)

FrontendHTTP

FrontendHTTP

StreamerHTTP

H.263

RTP

GroupStream Streaming

SchedStorageGroup

StorageSchedSched

Cache

GroupCache

Monitor Monitor

Monitor

VODKA_slave VODKA_slaveVODKA_slave

VODKA

Figura 4: Servidor VoDKA con n niveles de cache

• Compatibilidad: codigo desarrollado en Linux se portara sin problemas a Solaris,AIX, Tru64, IRIX, etc. Respeto de estandares (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 diseno

Las ideas del diseno original deben ser ligeramente modificadas para cubrir las necesi-dades en produccion del sistema. En particular, resulta necesaria una flexibilizacion deldiseno, toda vez que la arquitectura jerarquica en tres niveles (streaming, cache y alma-cenamiento) puede ser excesivamente sofisticada en instalaciones pequenas y demasiadorıgida en redes con una topologıa compleja como una red de interconexion de redes me-tropolitanas. Esta redefinicion de la arquitectura jerarquica da lugar a una arquitecturaen multiples niveles especializados, compartiendo cada uno de los niveles una mismainterfaz (figura 4). De esta forma, por ejemplo, puede suprimirse el nivel de cache, im-plementar una jerarquıa de multiples niveles de cache adaptando la propia topologıa dela red subyacente (figura 5) o disponer de multiples niveles de almacenamiento distribui-dos fısicamente. Incluso cabe la posibilidad de que un servidor utilice como soporte dealmacenamiento otro servidor VoD dando lugar a un metaservidor VoD.

Ademas de la flexibilidad en cuanto a la distribucion fısica del sistema, resulta ne-cesario que el sistema sea capaz, dentro de cada nivel y entre cada par de niveles, in-teraccionar utilizando protocolos de almacenamiento y transferencia heterogeneos. Estaflexibilizacion pasa por identificar los patrones de comunicacion entre los distintos nivelesfactorizandolos como abstracciones funcionales (pipe, para las transferencias dentro de unnodo, y transfer, para transferencias entre nodos) parametrizadas por cierres funcionalesque encapsulan las particularidades de los protocolos utilizados y que son establecidos

Grupo deAlmacenamiento

Caché ennodo de redprimario

Caché ennodo de redprimario

Caché ennodo de redsecundario

Caché ennodo de redsecundario

Streamer ennodo final

Streamer ennodo final

Streamer ennodo final

Almacenamiento

Almacenamiento(réplica)

(principal)

RED TRONCAL PRIMARIA

Usuarios finales

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 realizacion de un determinado servicio. Es-ta generalidad de los controladores de cada nivel obliga a la utilizacion de mecanismosgenericos de monitorizacion y de programacion reflexiva para descubrir las caracterısticasde cada nivel.

Merece la pena comentar la importancia de mantener el sistema independienterespecto a formatos de distribucion de contenidos multimedia digitales, actualmenteen constante cambio, hasta la parte final de distribucion de los contenidos (streamer)en el cual se efectua laa adaptacion de protocolos requerida: frontal de http progresivo,frontal RTP, etc.

La primera separacion logica en el servicio de vıdeo bajo demanda es la que diferenciael servidor de vıdeo, nucleo implementado fundamentalmente con tecnologıa funcionaldistribuida y desplegada sobre clusters tipo Beowulf, y los distintos servidores de apli-caciones que, utilizando la distribucion de vıdeo ofertada por el servidor VoD, definenservicios de usuario final (figura 6). Las aplicaciones, desarrolladas utilizando tecno-logıa convencional, interaccionan con el servidor de vıdeo redirigiendo a este peticionesde objetos multimedia determinados; ademas, las aplicaciones se nutren de la informa-cion recolectada por los elementos de monitorizacion de VoD. Las aplicaciones tıpicascomprenden cine y television a la carta, teleformacion, comercio electronico, noticiario,etc.

La figura 7 muestra un ejemplo de como se produce la transferencia de informaciondesde los niveles de almacenamiento hasta el streaming del objeto en un sistema simpli-ficado en el que se eliminan los niveles de cache. En este caso, la solicitud del cliente esrecogida por un frontal HTTP (HTTP frontend) que define la adaptacion de protocolorequerida para una distribucion progressive download sobre HTTP de un objeto multi-media MO. Este interacciona con su planificador (Streaming Sched) a traves del agrupadorde adaptadores en el que esta integrado (Sched Group) decidiendo la forma en que sedistribuira finalmente el stream de vıdeo (DD1, en este caso instanciado a una adaptacionHTTP en un puerto negociado con el cliente). El planificador del nivel de streaming pro-paga la solicitud de MO a su sucesor en la cadena de responsabilidad [10] incorporando elprotocolo que debe utilizar el almacenamiento para su transferencia (DD2, en este caso una

Video On Demand Kernel Architecture

Smirnoff

Management Subsystem

Request2(MO)

Response1

Consults

Consults

Request1

Agent

Management Data (MO)

VODKA Relevant DataObserver

XSLT

SERVLETS

HTTP SERVER

HTTP

Figura 6: Separacion entre servidor VoD y una aplicacion Web

comunicacion TCP/IP). El sucesor, el planificador de almacenamiento (Storage Sched),propaga la peticion hacia un multiplexor de almacenamientos (Storage Group), al quea su vez se conectan distintos dispositivos de almacenamiento: un sistema de ficherosmontado (File Storage Driver), un robot de cintas (Tape Storage Driver) e incluso unservidor web (HTTP Storage Driver). La labor del planificador es decidir la fuente queutilizara para obtener el objeto MO (en el ejemplo el File Storage Driver), construyendo unproceso pipe que conecta dicha fuente de datos con el protocolo de transferencia sugeridopor el planificador de streaming, el cual crea una nueva pipe para recoger la transferenciade almacenamiento y enviarla a traves del destino sugerido por el adaptador HTTP.

Como muestra de la flexibilidad en la configuracion del servidor VoDKA, la figura 8presenta un esquema de como se distribuyen las responsabilidades entre los distintosnodos del cluster Borg.

• En el nodo borg25 reside el almacenamiento masivo, alojando un planificador dealmacenamiento asociado con dos controladores de almacenamiento (unidad de CDy robot de cinta con 0.5 TB de capacidad).

• El planificador de almacenamiento es el sucesor en la cadena de responsabilidadde un planificador de cache que reside en el nodo borg24 y que utiliza comocache el ancho de banda agregado de controladores de cache locales en los nodosborg1...borg23.

• El propio nodo borg24 hospeda un planificador de streaming cuyo sucesor es elplanificador de cache, soportando un adaptador de progressive download utilizan-do HTTP que sirve al laboratorio utilizando la red departamental conmutada a10Mbps.

• El servidor covas aloja un planificador de cache, cuyo sucesor es el planificador decache de borg24 (dos niveles de cache), y un controlador de cache local. Ademas,el servidor contiene un planificador de streaming alimentado por el planificadorde cache y soportando un adaptador de progressive download utilizando HTTP,utilizando el adaptador ATM conectado directamente a la red troncal de la Uni-versidad.

• borg0, el frontal del cluster Borg, se utiliza para monitorizacion del sistema.

f(State,MO)={DS1,DD2}

MODD1

MODD2

MODD2

f(State,MO)=DS2

STORAGE I/OSTREAM I/O

Video StreamHTTP PIPE TCP

DD1 DS1

TCP PIPE FILE

DD2 DS2

transfer

lookupAns(A)

lookupAns(A) lookupAns(A) lookupAns(A,B,C)

lookupAns(B)

lookupAns(C)

lookupAns(A)

lookup

lookuplookup

lookuplookuplookup

lookup

MO

Storage

(TAPE)Driver

Storage Driver(File)

StorageGroup

(HTTP)Driver

Storage

FrontendHTTP

FrontendHTTP

StreamerHTTP

H.263

RTP

GroupStream Streaming Storage Storage

GroupSched Sched

Monitor MonitorVODKA_slaveVODKA_slave

VODKA

Figura 7: Ejemplo de transferencia en un sistema sin cache

covas

borg24 borg25

borg1 borg22 borg23

100Mb/s

100Mb/s

100Mb/s

10Mb/s

100Mb/s

10Mb/s

ATM

Storage Driver(File)

Storage

(TAPE)Driver

Driver(File)

Cache Driver(File)

Cache Driver Driver

(File)

Cache

StreamerHTTP

FrontendHTTP

StreamerHTTP

FrontendHTTP

StorageGroup

StorageSched

StreamingSched

Cache

CacheSched

Group

StreamingSched

CacheSched

Cache

VODKA_slaveVODKA_slave

VODKA_slave

VODKA_slaveVODKA_slave VODKA_slave

Figura 8: Configuracion de Borg en el campus universitario

5 Conclusiones

Se ha desarrollado un servidor de vıdeo bajo demanda que cumple con los requisitosbasicos que han de tener este tipo de sistemas: gran capacidad de almacenamiento, granancho de banda, tiempo de respuesta predecible, gran numero de usuarios concurrentesy tolerancia a fallos.

A partir de un servidor de estas caracterısticas, se ha evolucionado para que cumplasatisfactoriamente otras no menos importantes: escalabilidad tanto hacia arriba comohacia abajo, adaptabilidad a distintas topologıas de red de distribucion y bajo coste.Esto ha sido posible en gran medida gracias al uso de tecnologıas clave como el lenguajeErlang, aplicando sobre el conocidos patrones de diseno, y los clusters Beowulf.

En la actualidad el sistema esta pendiente de refinamiento de las fases de planificaciony de anadir nuevos modulos para el soporte de diferentes formatos y protocolos de dis-tribucion de los objetos multimedia. Ası mismo, es necesario implementar una completaserie de aplicaciones externas, que interactuen entre los usuarios y el servidor, antes deque se ponga finalmente en explotacion a traves de un operador de cable y llegue a loshogares del publico.

Referencias

[1] Apple Computer Inc. About Darwin Streaming Server enhttp://www.publicsource.apple.com/projects/streaming/

[2] J. Armstrong, R. Virding, C. Wikstrom, M. Williams. Concurrent Programming inErlang. Second Edition, Prentice-Hall. 1996.

[3] M. Barreiro, V. M. Gulıas, Cluster setup and its administration. In RajkumarBuyya, editor, High Performance Cluster Computing, Vol. I. Prentice Hall, 1999.

[4] S. G. Chan and F. Tobagi Hierarchical storage systems for interactive Video-on-demand Technical Report, Stanford University, Computer Systems Laboratory,Number CSL-TR-97-723, p. 84. 1997

[5] T. Chiueh, C. Venkatramani, M. Vernick, Design and Implementation of the StonyBrook Video Server. Software – Practice and Experience. 1997.

[6] T. Chiueh, M. Vernick, C. Venkatramani, Performance Evaluation of Stony BrookVideo Server. ECSL-TR-24. 1997.

[7] Cisco Systems, Inc. A Distributed Video Server Architecture for Flexible Enterprise-Wide Video Delivery enhttp://www.cisco.com/warp/public/cc/pd/mxsv/iptv3400/tech/dvsa wp.htm,White Paper, 2000.

[8] D. Du, J. Hsieh, J. Liu, Building Video-on-Demand servers Using Shared-MemoryMultiprocessors. Distributed Multimedia Research Center and Computer ScienceDepartment, University of Minnesota, and Ronald J. Vetter, Computer Science De-partment, North Dakota State University. 1996.

[9] U. Ekstrom, Design Patterns for simulation en ERLANG/OTP. Master Thesis,Universidad de Upsala, Suecia, 2000

[10] E. Gamma, R. Helm, R. Johnson, and J.Vlissides. Design Patterns: Elements ofReusable Object-oriented Software. Addison Wesley, Reading, 1996.

[11] LFCIA, OpenMonet Project. en http://sourceforge.net/projects/openmonet

[12] LFCIA, Erlatron Project. http://sourceforge.net/projects/modxsl

[13] Oracle, Oracle Video Server Administrators Guide and Command Reference” Re-lease 3.0 for UNIX, 1998.

[14] Oracle, Oracle Video Server System Technical Overview Release 3.0 for UNIX.Oracle White Paper, 1998.

[15] Philips, WebCine Server enhttp://www.mpeg-4player.com/products/server/index.asp

[16] J.J. Sanchez, V.M. Gulıas, A. Valderruten, J. Mosquera. State of the Art and De-sign of VOD Systems. Proceedings of the International Conference on InformationSystems Analysis, SCI’00-ISAS’00. ISBN 980-07-6694-4, Orlando, USA, July 2000.

[17] Sun Microsystems Inc. Sun StorEdge Media Central Streaming Server enhttp://www.sun.com/storage/media-central/

[18] M. Vernick, C. Venkatramani, T. Chiueh, Adventures in Building The Stony BrookVideo Server. Proceedings of ACM Multimedia ’96, Boston, MA. 1996

[19] P. Wilkinson, M. DeSisto, H. Rother, Y. Wong. IBM VideoCharger 101. IBM Red-book. International Technical Support Organization. 1999.