Utilización de Clusters Linux como Servidores de

Utilización de Clusters Linux como Servidores de

HA
C LU C E
Utilización de Clusters Linux como
Servidores de Vı́deo Bajo Demanda
Dr. Vı́ctor M. Gulı́as
[email protected]
Departamento de Computación
Universidade da Coruña
financiado por:
Contenido
• Antecedentes. Cluster Borg.
• Video Bajo Demanda. Problemática.
• Objetivos y Propuesta de Diseño Inicial.
• Tecnologı́as Clave.
• Refinamiento del Diseño.
• Conclusiones y Lı́neas de Trabajo Actuales.
Antecedentes
• 1994. Paradigma Funcional + Computación Paralela
– Declarativo, sin efectos colaterales
– Alto nivel de expresividad, abstracción, prototipado
• 1995. Extensión concurrente de Yale Haskell
– Concurrencia explı́cita, comunicación de orden superior
• 1996-1999. RTS de un lenguaje funcional distribuido
– Modelo semi-implı́cito (anotaciones, equilibrado dinámico de carga)
– Modelo explı́cito, comunicación ası́ncrona de orden superior
– Arquitectura de interés: Clusters Beowulf
Borg, El Cluster Beowulf del LFCIA
4
6
7
5
1 FORERUNNER 3810 (External world)
2 10 Mb Ethernet link
3
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 3300 Switch (4, 24 slots per switch)
5
3
4
1
7
6
7 1 Gb link (2 independent networks)
CPU
2
frontend
CPU
...
CPU
CPU
CPU
...
CPU
Video Bajo Demanda. Requerimientos
• 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.
• Aplicaciones: Pelı́culas bajo demanda, aprendizaje a distancia, noticias
interactivas, etc.
• Principales requerimientos:
– Gran capacidad de almacenamiento
– Gran ancho de banda
– Tiempo de respuesta predecible (pref. bajo)
– Soportar a gran número de usuarios concurrentes
– Escalabilidad
– Adaptabilidad
– Tolerancia a fallos
– Bajo coste
Soluciones (Comerciales) Existentes VoD
• Inicio proyecto 1999 (MPEG-2 2Mbps [LAN], Real 28 Kbps [WAN])
– Apple, Quicktime Streaming Server (ahora Darwin Streaming Server)
– IBM, DB2 Digital Library Video Charger
– Microsoft, NetShow Theater (ahora Windows Media Server)
– Oracle, Video Server
– Real Networks, RealVideo Server
– SGI, WebForce MediaBase (ahora Kassenna)
– Sun, StorEdge Media Central
– Diversas soluciones a partir de otras soluciones comerciales
• Soluciones caras, cerradas, no escalables, no adaptables
VoDka: Servidor VoD Funcional Distribuido
• Sistema de almacenamiento jerárquico, basado en clusters
Linux construidos a partir de componentes de consumo
• Diseño usando patrones de diseño GoF y behaviours OTP
• Lenguajes de desarrollo:
– Monitorización, Control, planificación: Erlang/OTP
– Entrada/Salida: C (prototipado en Erlang/OTP)
• Énfasis en reutilización:
– uso de herramientas Open-Source (Linux, Erlang/OTP, ...)
– adaptación de soluciones existentes (Darwin)
– independización de subsistemas (OpenMonet, Erlatron)
Propuesta de Diseño Inicial
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
• Estructura jerárquica con 3 niveles:
– Nivel Terciario (Storage): Gran capacidad
– Nivel Secundario (Cache): Planificación, ancho de banda agregado
– Nivel Primario (Streaming): Adaptación de protocolos
Configuración de Borg como Servidor VoD
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
Tecnologı́as Clave: Erlang/OTP
• Diseñado, implementado y utilizado por Ericsson AB para la programación de sus sistemas de control distribuidos complejos
• Apropiado para sistemas tiempo real (soft) distribuidos tolerantes a fallos
• Caracterı́sticas de diseño a resaltar:
– Funcional: sin efectos colaterales
– Concurrente: Paso de mensajes ası́ncrono, transporte transparente
de valores, comunicaciones de orden superior
– Distribuido: Ubicación transparente de procesos en nodos
– Primitivas para soporte de tolerancia a fallos
– Reemplazamiento “en caliente” de código sin detener el sistema
• Open Telecom Platform: bibliotecas y patrones de diseño distribuido
– Servidores genéricos
– Mecanismos de supervisión
– Base de datos distribuida (transparencia de ubicación, fragmentación,
replicación, integración con el lenguaje)
– Integración: SNMP, ASN.1, Interfaz C, Corba, Java, HTTP
Tecnologı́as Clave: Cluster Linux
• Amplia experiencia anterior propia y ajena con redes de alta velocidad,
sistemas distribuidos y clustering sobre linux.
• 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)
• 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...)
Lecciones Aprendidas
• Necesidad de flexibilidad: redefinición de la arquitectura jerárquica,
dando lugar a otra composición de módulos con un API estándar.
– El número de niveles y la forma en que se componen debe ser flexible
(Ej.: Un servidor entero como fuente de datos para otro servidor)
– En cada nivel: distintos protocolos tanto de almacenamiento como
de transferencia
• Necesidad de factorización: abstracción del proceso de comunicación
(pipes, transfers), introspección de servidores (VoDka Browser ), monitorización (observer+mediator ), etc.
• Independencia respecto a protocolos y formatos (actualmente en constante cambio)
• Los cuellos de botella no están tanto en la red sino en los nodos:
acceso a disco
• TCP/IP es cómodo para la comunicación entre módulos pero a partir
de cientos de Mb/s es un protocolo pesado
• No existe almacenamiento off-line masivo eficiente con hardware de
consumo (commodity ). Los cargadores eficientes son muy caros (IBM
3575: $15000).
Refinamiento del Diseño. Propuesta Actual (I)
Separación del subsistema de gestión (aplicación web convencional) y del
núcleo (kernel) servidor de vı́deo.
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
El esquema representa la estructura de la versión SMIRNOFF (Second Monitoring and Improved Release Now Offering Further Features)
Refinamiento del Diseño. Propuesta Actual (II)
Transferencias internas en VoDka ante una petición HTTP desde un cliente
remoto.
VODKA
Monitor
Stream
Group
RTP
VODKA_slave
MO
DD2
lookup
lookupAns(A)
Streaming
Sched
MO
DD1 lookup
lookupAns(A)
HTTP
Frontend
H.263
VODKA_slave
MO
DD2
lookup
lookupAns(A)
Storage
Sched
Monitor
lookup
lookupAns(A,B,C)
f(State,MO)={DS1,DD2}
f(State,MO)=DS2
HTTP
Streamer
lookup
lookupAns(A)
Storage
Driver
(File)
transfer
lookup
lookupAns(B)
Storage
Driver
(TAPE)
HTTP
Frontend
MO
Storage
Group
Video Stream
HTTP
DD1
PIPE
TCP
DS1
TCP
DD2
PIPE
FILE
DS2
STREAM I/O
lookup
lookupAns(C)
Storage
Group
Storage
Driver
(HTTP)
STORAGE I/O
Un servidor completo puede ser fuente de datos para la capa de almacenamiento, usando la entrada al storage driver correspondiente.
Refinamiento del Diseño. Propuesta Actual (III)
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)
Cache
Driver
(File)
Storage
Driver
(TAPE)
Storage
Group
Storage
Driver
(HTTP)
La figura muestra la flexibilidad de VoDka SMIRNOFF: un nivel de streaming,
n de cache y uno de almacenamiento masivo.
Refinamiento del Diseño. Propuesta Actual (IV)
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
Transformaciones XSL en Cluster
• Transformacion documentos XML generados por OpenMonet
– Selección XSL en base a tipo documento, browser, etc.: mod_xsl
– Adaptación biblioteca XSLT C++ (sablotron): sablotron_adapter
– Equilibrado de carga: erlatron
erlatron
slave
result
C adapter
sablotron
library
port
ready
Client
xslt
xslt
erlatron
master
erlatron
slave
C adapter
erlatron
slave
C adapter
Client
pool of workers
erlatron server
40
35
30
ab -c C -n 250
150
execution time (s)
requests per second
200
ab -c 10 -n 500
ab -c 15 -n 500
ab -c 25 -n 500
ab -c 50 -n 500
25
20
15
10
100
50
5
0
0
1 2
4
8
12
16
number of slaves (P)
22
12 4
8
12
16 20 24
concurrency level (C)
48
Conclusiones y Lineas de Trabajo Actual
• Necesidad de flexibilidad
• Necesidad de factorización
• Independencia respecto a protocolos y formatos
• Ccuellos de botella: acceso a disco
• TCP/IP protocolo pesado
• No existe almacenamiento (commodity ) off-line masivo
• Implantación de un prototipo dentro del campus universitario
• Estudio de adaptación e implantación de un prototipo en la red de
cable de R
Fuentes de Financiación
• Proyectos Relacionados:
– FEDER 1FD97-1759 (desarrollo del servidor de vı́deo bajo demanda)
(partner tecnológico R)
– XUNTA PGIDT99COM10502 (modelización del rendimiento)
– Universidade da Coruña 2000-5050252026 (patrones de diseño en
sistemas funcionales distribuidos)
• Infraestructura:
– Xunta de Galicia. Infraestructura 1998. Borg
– Xunta de Galicia. Infraestructura 2001. BorgTNG
Recursos en el Web
• LFCIA Home Page. http://www.lfcia.org
• VoDka Project Home Page. http://vodka.lfcia.org
• OpenMonet Home Page. http://monet.sourceforge.net
• mod_xsl Home Page. http://modxsl.sourceforge.net
A Coruña, 12-14 de septiembre de 2001
http://www.lfcia.org/sit01