Utilización de programación funcional distribuida y

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 – 15071 A Coruña (SPAIN)
e-mail: {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-1FD97-1759, Xunta de Galicia PGIDT99COM10502 y
UDC 2000-5050252026
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
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).
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
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.
3.1.1
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
7
6
6
5
4
CPU
CPU
...
CPU
CPU
CPU
...
CPU
5
4
3
frontend
2
1
1 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)
5 100 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.
3.2.1
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
K7 500 128MB Bus 32 bits
Alpha Server DS20 Buses 64 bits
borg24 (192.168.155.24)
3COM Superstack II 3300
Borg0
borg0−1 (192.168.155.254)
borg1−1 ... borg23−1 (192.168.155.1...23)
borg0−0 (192.168.154.254)
borg1−0 ... borg23−0 (192.168.154.1...23)
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, HTTP.
Todas las caracterı́sticas citadas hacen de Erlang un lenguaje muy adecuado para el
desarrollo del sistema propuesto.
3.2.2
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).
VODKA
Monitor
Monitor
VODKA_slave
Stream
Group
VODKA_slave
Streaming
Sched
Cache
Sched
VODKA_slave
n cache
levels
Storage
Sched
Monitor
Storage
Group
RTP
H.263
HTTP
Frontend
Cache
Group
Storage
Driver
(File)
HTTP
Streamer
HTTP
Frontend
Cache
Driver
(File)
Storage
Driver
(TAPE)
Cache
Driver
(File)
Storage
Group
Storage
Driver
(HTTP)
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
Grupo de
Almacenamiento
Caché en
nodo de red
secundario
Almacenamiento
(réplica)
Caché en
nodo de red
primario
RED TRONCAL PRIMARIA
Caché en
nodo de red
primario
Usuarios finales
Streamer en
nodo final
Caché en
nodo de red
secundario
Almacenamiento
(principal)
Almacenamiento
Streamer en
nodo final
Streamer en
nodo final
Caché N2
Caché N1
Usuarios finales
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 HTTP (HTTP frontend ) que define la adaptación de protocolo
requerida para una distribución progressive download sobre HTTP de un objeto multimedia MO. Este interacciona con su planificador (Streaming Sched ) a través del agrupador
de adaptadores en el que está integrado (Sched Group) decidiendo la forma en que se
distribuirá finalmente el stream de vı́deo (DD1, en este caso instanciado a una adaptación
HTTP 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
Video On Demand Kernel Architecture
Smirnoff
HTTP SERVER
VODKA Relevant Data
Observer
Consults
Request1
Request2(MO)
SERVLETS
HTTP
Consults
Agent
XSLT
Response1
Management Data (MO)
Management Subsystem
Figura 6: Separación entre servidor VoD y una aplicación Web
comunicación TCP/IP). El sucesor, el planificador de almacenamiento (Storage Sched ),
propaga la petición hacia un multiplexor de almacenamientos (Storage Group), al que
a su vez se conectan distintos dispositivos de almacenamiento: un sistema de ficheros
montado (File Storage Driver ), un robot de cintas (Tape Storage Driver ) e incluso un
servidor web (HTTP Storage Driver ). La labor del planificador es decidir la fuente que
utilizará para obtener el objeto MO (en el ejemplo el File Storage Driver ), 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 HTTP.
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 HTTP 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 HTTP,
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.
VODKA
Monitor
Stream
Group
RTP
VODKA_slave
MO
DD2
lookup
lookupAns(A)
HTTP
Frontend
H.263
MO
DD2
Streaming
Sched
MO
DD1 lookup
lookupAns(A)
VODKA_slave
lookup
lookupAns(A)
Monitor
Storage
Sched
lookup
lookupAns(A)
f(State,MO)={DS1,DD2}
f(State,MO)=DS2
lookup
lookupAns(B)
Storage
Driver
(File)
transfer
HTTP
Streamer
Storage
Group
lookup
lookupAns(A,B,C)
Storage
Driver
(TAPE)
HTTP
Frontend
MO
lookup
lookupAns(C)
Storage
Group
Storage
Driver
(HTTP)
Video Stream
HTTP
PIPE
DD1
TCP
PIPE
TCP
FILE
DD2
DS1
DS2
STREAM I/O
STORAGE I/O
Figura 7: Ejemplo de transferencia en un sistema sin caché
borg24
borg25
VODKA_slave
Streaming
Sched
10Mb/s
HTTP
Frontend
VODKA_slave
Cache
Sched
HTTP
Streamer
Storage
Sched
100Mb/s
Cache
Group
Storage
Group
10Mb/s
Storage
Driver
(File)
VODKA_slave
Storage
Driver
(TAPE)
100Mb/s
ATM
Streaming
Sched
Cache
Sched
HTTP
Streamer
Cache
Driver
HTTP
Frontend
covas
100Mb/s
100Mb/s
Cache
Driver
(File)
Cache
Driver
(File)
VODKA_slave
VODKA_slave
borg1
borg22
Cache
Driver
(File)
VODKA_slave
borg23
Figura 8: Configuración de Borg en el campus universitario
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
http://www.publicsource.apple.com/projects/streaming/
[2] J. Armstrong, R. Virding, C. Wikström, M. Williams. Concurrent Programming in
Erlang. Second Edition, Prentice-Hall. 1996.
[3] M. Barreiro, V. M. Gulı́as, Cluster setup and its administration. In Rajkumar
Buyya, editor, High Performance Cluster Computing, Vol. I. Prentice Hall, 1999.
[4] S. G. Chan and F. Tobagi Hierarchical storage systems for interactive Video-ondemand 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 Stony
Brook Video Server. Software – Practice and Experience. 1997.
[6] T. Chiueh, M. Vernick, C. Venkatramani, Performance Evaluation of Stony Brook
Video Server. ECSL-TR-24. 1997.
[7] Cisco Systems, Inc. A Distributed Video Server Architecture for Flexible EnterpriseWide Video Delivery en
http://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-Memory
Multiprocessors. Distributed Multimedia Research Center and Computer Science
Department, University of Minnesota, and Ronald J. Vetter, Computer Science Department, North Dakota State University. 1996.
[9] U. Ekström, 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 of
Reusable 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” Release 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 en
http://www.mpeg-4player.com/products/server/index.asp
[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 980-07-6694-4, Orlando, USA, July 2000.
[17] Sun Microsystems Inc. Sun StorEdge Media Central Streaming Server en
http://www.sun.com/storage/media-central/
[18] M. Vernick, C. Venkatramani, T. Chiueh, Adventures in Building The Stony Brook
Video Server. Proceedings of ACM Multimedia ’96, Boston, MA. 1996
[19] P. Wilkinson, M. DeSisto, H. Rother, Y. Wong. IBM VideoCharger 101. IBM Redbook. International Technical Support Organization. 1999.