Rapport d`Expertise d`un Prototype de Serveur Vidéo

Transcription

i
Rapport d’Expertise d’un
Prototype de Serveur Vidéo
Institut Eurécom
CCETT/CNET/France Telecom
Jamel Gafsi et Ernst W. Biersack
Institut EURECOM
B.P. 193, 06904 Sophia Antipolis, FRANCE
fgafsi,[email protected]
Janvier 2000
Table des matières
1
2
Résumé
3
1.1
Contexte du projet d’expertise . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
Objectifs du projet d’expertise . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1
Cadrage technique des travaux . . . . . . . . . . . . . . . . . . . . .
3
1.2.2
Développements complémentaires et consolidation des logiciels serveurs
4
Prototype du serveur vidéo d’ Eurécom
4
2.1
Résumé des travaux de recherche et de développement . . . . . . . . . . . . .
4
2.2
Originalité de la solution retenue . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Description détaillée du prototype de serveur vidéo . . . . . . . . . . . . . . .
6
2.3.1
Environnement du serveur vidéo . . . . . . . . . . . . . . . . . . . . .
6
2.3.2
Architecture et configuration du serveur vidéo . . . . . . . . . . . . . .
7
2.3.3
Composantes du prototype de serveur vidéo . . . . . . . . . . . . . . .
9
2.3.4
Flux de messages et d’information au sein du serveur vidéo . . . . . .
12
Vers un prototype de serveur vidéo d’une grande maturité . . . . . . . . . . . .
13
2.4
3
Développements complémentaires et consolidation effectués dans le cadre du projet de l’expertise
15
3.1
3.2
3.3
Portage de la partie client en Java . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.1
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.2
Outils et tâches à accomplir . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.3
Implémentation du client en Java . . . . . . . . . . . . . . . . . . . . .
17
3.1.4
Migration du client en Java: Résultats . . . . . . . . . . . . . . . . . .
22
Réimplémentation des algorithmes d’ordonnancement et d’extraction des données 23
3.2.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.2
Implémentation de l’ordonnancement asynchrone . . . . . . . . . . . .
24
Utilisation de UDP pour le transfert des données . . . . . . . . . . . . . . . . .
25
4
Tests d’evaluation de la performance du nouveau prototype de serveur vidéo
26
5
Valorisation et démonstration
30
6
Conclusions
30
2
1 Résumé
1.1 Contexte du projet d’expertise
Les applications multimédia telle que la vidéo à la demande requièrent un dispositif de stockage
des données audio et vidéo appelé serveur vidéo. Étant donné l’importance du volume des données vidéo, un serveur vidéo comporte habituellement de nombreux disques. Par ailleurs, la
vidéo à la demande est particulièrement gourmande en capacité de mémoire et de largeur de
bande passante. Ceci nécessite la conception d’un serveur comportant plusieurs noeuds (machines) pour servir un grand nombre de clients.
L’Institut Eurécom a con¸cu une architecture de serveur vidéo, appelée la matrice à serveurs
[1], où chaque vidéo est répartie sur la totalité des noeuds de serveurs et chaque noeud ne stocke
qu’une partie de la vidéo. Cette architecture a pour avantage majeur une parfaite répartition de la
charge et la faculté d’augmenter le nombre de noeuds ou de disques pour s’adapter aux besoins
du serveur en matière de bande passante et de volume de stockage. Le serveur, tout comme les
clients, tournent sur les plates-formes multiples (stations de travail, PC). Le prototype stocke
les vidéos codés en MPEG-1 et dessert un grand nombre de clients consommant chacun des
flux MPEG-1 avec 25 trames/s. Le prototype implémente plusieurs algorithmes d’entrelacement (répartition) et d’ordonnancement des flux vidéo. Le client est muni des fonctionnalités
interactives telles que play, pause, reposition, stop, fast forward et fast backward.
De son côté, CNET/France Telecom envisage d’utiliser le prototype de serveur vidéo d’Eurécom pour supporter l’application de la vidéo à la demande qui servira comme application
de test pour les nouvelles plates-formes et technologies du réseau tel que l’ADSL. En outre,
les travaux de l’expertise doivent mener à intégrer le serveur vidéo d’Eurécom dans une offre
serveur complète et étudier les modalités de sa commercialisation.
1.2 Objectifs du projet d’expertise
L’objectif du projet est d’aboutir à un prototype de serveur vidéo d’une plus grande maturité, qui
est à la fois stable, fiable et flexible en matière des plates-formes utilisées. Voici les principaux
points qui doivent être effectués dans le cadre de ce projet:
1.2.1
Cadrage technique des travaux
Il s’agit de préciser l’ensemble logiciel à fiabiliser et son environnement (système opératoire,.)
dans l’objectif de favoriser à terme son intégration dans une offre serveur complète et conforme
aux standards en vigueur. En particulier l’analyse devra prendre en compte la possibilité d’une
intégration avec des logiciels client/serveur du commerce basés sur les protocoles définis par
l’IETF (RTSP, RTP,..).
3
1.2.2
Développements complémentaires et consolidation des logiciels serveurs
Cette tâche intègre les parties suivantes:
1. Mener à bien les compléments de développement qui consistent en particulier à atteindre
une architecture flexible à la largeur d’échelle (scalable) tout en gardant l’aspect distribué
de l’architecture ainsi que des algorithmes d’ordonnancement et de stockage des données.
2. Garantir un fonctionnement fiable de ces logiciels. Pour ceci, le serveur vidéo doit être
tolérant à la défaillance de certaines de ses composantes telles que un disque ou une machine. La détection des pannes doit être immédiate afin de réduire le temps d’interruption
du côté des clients.
3. Refaire la partie client du serveur vidéo. Ceci consiste à implémenter le client en Java.
Ce point nous parait d’une grande importance. En effet, la migration du client vers Java
permettra une indépendance totale de la machine et du système d’exploitation utilisés par
le client.
4. Tests et validation. Les tests et la validation seront menés dans les laboratoires de l’Institut
Eurécom. Ces travaux consistent à définir et décrire les procédures de Test (cahier de recette) et mettre en place les outils nécessaires aux tests qualitatifs et tests de performance.
Finalement, ces tests doivent être effectués et documentés.
5. Valorisation et démonstration à des tiers. De manière à favoriser la valorisation des travaux auprès de partenaires potentiels, Eurécom mettra en place une plate-forme de démonstration dans ses locaux et réalisera un document de synthèse de positionnement du
système à valoriser, des principes techniques mis en oeuvre des performances obtenues.
2
Prototype du serveur vidéo d’ Eurécom
Les serveurs multimédia sont différents des systèmes d’information traditionnels. Ceci est spécialement dû au fait que l’information multimédia est volumineuse, gourmande en bande passante et impose ses contraintes en temps réel. Par conséquent, les applications multimédia, telles
que la vidéo à la demande, nécessitent la conception de nouveaux mécanismes de stockage,
d’ordonnancement, de mémorisation et de livraison de l’information multimédia. Le serveur
vidéo est un dispositif de stockage distribué de données audio et vidéo assurant le service d’un
grand nombre de clients.
2.1 Résumé des travaux de recherche et de développement
A l’Institut Eurecom ont été effectués plusieurs travaux de recherche portant surtout sur la configuration et la conception de l’architecture du serveur vidéo [2], les techniques de répartition des
4
données sur les différents disques du serveur [3], les algorithmes de lecture des données, les
mécanismes d’ordonnancement des flux multiples au niveau du serveur [4, 5, 6], la gestion de
la mémoire, la synchronisation des trames vidéo [7, 8] et enfin la fiabilité du serveur vidéo
[9, 10, 11, 12].
Étant donné l’importance du volume des données vidéo, un serveur vidéo comporte habituellement de nombreux disques. Par ailleurs, les besoins en mémoire et en largeur de bande passante
nécessitent de concevoir un serveur comportant plusieurs noeuds (machines) pour servir un
grand nombre de clients. Une architecture de serveur vidéo a été con¸cue : chaque vidéo est répartie sur la totalité des noeuds du serveurs et chaque noeud ne stocke qu’une partie de la vidéo.
Cette architecture a pour avantage majeur une parfaite répartition de la charge et la flexibilité
d’augmenter le nombre de noeuds ou de disques.
Une équipe travaille sur les serveurs vidéo depuis cinq ans, durant lesquels ont été effectués
plusieurs travaux de recherche portant surtout sur l’architecture du serveur, la synchronisation et
l’ordonnancement des trames des flux vidéo. Récemment, des travaux portant sur la conception
de serveurs vidéo à grande échelle ont été réalisés dans le cadre d’une thèse de doctorat [13].
Ces travaux étudient principalement le stockage et la répartition de la vidéo ainsi que la fiabilité
du serveur [3, 11, 14]. Afin de mettre en oeuvre les résultats de ces recherches, un prototype de
serveur vidéo distribué basé sur ces résultats a été implémenté [15, 16, 17]. Un second objectif
est d’étudier la performance et la qualité de service du prototype du serveur vidéo.
Le serveur vidéo permet le stockage de films vidéo codés dans le format MPEG-1, la distribution de ces données à travers le réseau et leur visualisation (à raison de 25 images par seconde)
par un nombre élevé de clients (application Video-On-Demand). Le prototype implémente une
diversité d’algorithmes de réplication de données. Le client est muni des fonctionnalités interactives telles que play, pause, reposition, stop, fast-forward et fast-backward.
2.2 Originalité de la solution retenue
L’originalité du travail effectué à Eurécom consiste à avoir con¸cu et implémenté un prototype
de serveur vidéo ayant les qualités suivantes:
– Le serveur utilise des composantes (hardware) standards et toute la complexité et l’intelligence du serveur sont en software. Ceci donne au prototype une indépendance à l’égard
des changements de performances et de technologies au niveau des composantes hardware. Il est également à noter que cette solution software est indépendante du format
utilisé et permet par la suite de supporter une multitude formats audio et vidéo.
– Le prototype sait intégrer des composantes hétérogènes (capacité de stockage et de bande
passante, etc.) et implémente une variété d’algorithmes de répartition de la vidéo, d’ordonnancement des flux vidéo multiples et de fiabilité.
– Le serveur ainsi que le client tournent sur des plates-formes multiples (Solaris et Windows
NT).
5
– Le client n’a pas besoin de hardware particulier pour décoder le flux vidéo. A titre
d’exemple, le décodage des flux MPEG-1 qui sont re¸cus par le client s’effectue en software.
– Le serveur vidéo tourne sur des réseaux différents tels que ATM et Ethernet. Le stockage
des données vidéo peut aussi s’effectuer à distance.
2.3 Description détaillée du prototype de serveur vidéo
2.3.1
Environnement du serveur vidéo
La Figure 1 illustre l’environnement d’un serveur vidéo. Elle distingue trois parties: le serveur
vidéo, un réseau haut débit et les clients.
Matrice a disques
Memoire vive
I/O Bus
Client
Client
Reseau haut debit
Ecriture
Client
Lecture
Client
Serveur video
F IG . 1 – Architecture et environnement du serveur vidéo
L’environnement du serveur vidéo contient principalement trois parties:
– Une matrice à disques pour le stockage de la vidéo: Afin d’atteindre un grande capacité
de stockage et une large bande passante, le serveur vidéo est typiquement composé de
plusieurs disques magnétiques. Un système qui contient plusieurs disques magnétiques
est nommé une matrice à disques (disk array). Cette matrice à disques est composée de
disques multiples stockant les vidéos. La capacité de stockage de la matrice est donc proportionnelle au nombre de disques qu’elle contient. Noter que chaque vidéo est découpée
en morceaux appelés blocs. Ceux-ci sont ensuite stockés sur plusieurs composantes du
serveur vidéo. La distribution des blocs d’une vidéo sur plusieurs disques et noeuds du
serveur vidéo améliore la performance du serveur en terme de débit et répartie sa charge
équitablement sur ses différentes composantes. Il est à noter que répartir la vidéo sur le
serveur vidéo ne veut pas dire la répliquer.
– Un bus entrée/sortie (I/O bus) (e.g. SCSI) qui sert à transférer les données extraites des
disques vers le buffer. Afin d’exploiter toute la bande passante de la matrice à disques, la
6
capacité de transfert du I/O bus doit être supérieure à la somme des débits de transfert de
tous les disques de la matrice.
– Une mémoire tampon (buffer): Le débit de transfert des données au niveau d’un disque
magnétique atteint aujourd’hui des dizaines de Mbit=sec. Ce débit dépasse largement le
débit de consommation du flux vidéo chez le client ( jusqu’à 8 Mbit=sec pour MPEG-2).
Afin d’absorber cette différence de débit et assurer un flux vidéo continu, les blocs vidéo
extraits de chaque disque sont stockés temporairement au niveau du buffer avant d’être
envoyés vers le client correspondant. Comme indiqué dans la Figure 1, le buffer est fondé
sur la méthode du double buffer (double buffering): le serveur vidéo réserve pour chaque
flux deux espaces buffer. Chaque espace a la taille d’un bloc et sert soit à l’ ’écriture d’un
bloc provenant du I/O bus, soit à la lecture d’un bloc avant son envoi vers le client. Noter
que les deux espaces buffer alternent leurs rôles d’une unité de service à une autre.
Un réseau à haut débit est indispensable pour véhiculer des flots de données très importants.
En effet, même sous sa forme compressée, l’information vidéo reste très gourmande en bande
passante (jusqu’à 8Mbit=sec pour MPEG-2). Actuellement, la plupart des réseaux ne sont pas
capables de fournir la bande passante nécessaire pour permettre à un serveur vidéo de servir
des centaines ou des milliers de clients simultanément. Cette limitation en matière de bande
passante au niveau du réseau est le facteur décisif qui empêche le marché de la VOD d’atteindre
une large population.
Chaque client est connecté au serveur vidéo via le réseau haut débit. Il s’agit bien d’un rapport
de producteur-consommateur. En effet, le client envoie sa requête au serveur vidéo. L’entité
centrale du serveur vidéo, appelée aussi meta serveur, fournit à ce nouveau client la liste des
vidéos disponibles. Le client renvoie alors une requête indiquant la vidéo qu’il a choisie. Ensuite, le meta serveur effectue un contrôle d’admission de ce nouveau client. Dans le cas où ce
dernier est admis, le meta serveur informe le serveur vidéo de la présence de ce client, qui, à son
tour, établit une connection avec ce dernier. Le client commence ainsi à recevoir son propre flux
vidéo en temps réel. Le client dispose des fonctions classiques d’interactivité et a la possibilité
d’envoyer des requêtes telles que fast forward ou pause au serveur vidéo, qui, de son côté, traite
cette demande et exécute la fonction désirée par le client.
2.3.2
Architecture et configuration du serveur vidéo
Les serveurs vidéo sont des systèmes où les solutions distribuées sont essentielles au vu du volume très large des données à stocker et du débit très haut à atteindre. Nous avons proposé une
architecture de serveur vidéo distribuée dont voici les caractéristiques: étant donnée la demande
en matière de capacité de stockage et de bande passante, le serveur vidéo est typiquement basé
sur la matrice à disques appelée aussi noeud. En outre, pour pouvoir servir plus de clients,
le serveur vidéo doit voir sa capacité en terme de bande passante augmenter. Cependant, cette
demande en bande passante ne peut pas être satisfaite en ajoutant simplement des disques au
sein du même noeud. En effet, un noeud, à cause des limitations imposées par ses composantes
7
(buffer, CPU, I/O bus, etc.), ne peut contenir qu’un nombre restreint de disques. Par conséquent, augmenter la capacité du serveur vidéo pour admettre plus de clients revient à ajouter de
nouveaux noeuds à côté des noeuds déjà existants.
Traditionnellement, un serveur vidéo est composé de plusieurs noeuds indépendants et autonomes: chaque vidéo est entièrement stockée sur un des noeuds. Cette configuration de noeuds
autonomes présente deux inconvénients majeurs:
1. La charge du serveur vidéo est distribuée d’une fa¸con inégale entre les différents noeuds.
Les noeuds qui contiennent les vidéos les plus populaires sont surchargés (hot spots)
tandis que d’autres noeuds restent sous-chargés.
2. Le nombre de clients accédant à une vidéo très populaire est limité par la capacité du
noeud où cette vidéo est stockée. Afin de permettre à plus de clients d’accéder à la même
vidéo populaire, cette dernière doit être copiée sur d’autres noeuds. Mais, ceci est inefficace à l’égard de la capacité de stockage du serveur vidéo. En outre, les variations de
popularité des différentes vidéos stockées rendra la mise à jour du contenu du serveur
vidéo complexe.
Notre approche s’inspire de la configuration de la matrice à disques où chaque vidéo est distribuée sur les différents disques de cette matrice. Nous avons ainsi proposé une architecture
de serveur vidéo où plusieurs noeuds constituent ensemble une matrice appelée la matrice à
serveurs [1]. La Figure 2 illustre l’architecture de la matrice à serveurs.
Matrice a Serveurs
Noeud
Client
Client
Noeud
Reseau haut debit
Client
Client
Noeud
F IG . 2 – La Matrice à serveurs
Chaque noeud de la matrice à serveurs est lui-même une matrice à disques. Contrairement aux
serveurs autonomes, un noeud de la matrice à serveurs ne stocke qu’une partie de chaque vidéo.
En effet, chaque vidéo est découpée en blocs et ces derniers sont répartis sur les différents
8
noeuds de la matrice à serveurs. Par exemple, le premier bloc de la vidéo est stocké sur le
premier noeud, le deuxième bloc sur le deuxième noeud, , le i ème bloc est stocké sur le
noeud (i mod N ) + 1 où N représente le nombre de noeuds qui sont contenus dans le serveur
vidéo. La répartition de la charge entre les noeuds du serveur est équitable et ne dépend pas
de la popularité des vidéos consommées. Cette répartition de la charge est même parfaite si
chaque vidéo est répartie sur tous les noeuds de la matrice à serveurs. De plus, la capacité totale
du serveur vidéo peut être utilisée pour servir un grand nombre de clients, qui, tous, peuvent
utiliser la même vidéo très populaire. Cette répartition a l’avantage d’éviter de copier les vidéos
populaires sur plusieurs noeuds.
L’architecture de la matrice à serveurs indique que chaque vidéo est découpée en plusieurs blocs
et que ces derniers sont stockés sur les différents noeuds de la matrice à serveurs. En revanche,
cette architecture ne précise ni (i) la fréquence d’extraction des données, ni (ii) l’ordre suivant
lequel les différents flux sont servis par les noeuds et des disques du serveur vidéo ni (iii) la
granularité de distribution des données vidéo sur les noeuds ainsi que sur les disques à l’intérieur
d’un noeud.
2.3.3
Composantes du prototype de serveur vidéo
Fondé sur la matrice à serveurs, le prototype de serveur vidéo est composé principalement de
trois composantes qui sont le Meta-serveur, les Disk-serveurs et le Client. Le Meta-serveur et
les Disk-serveurs constituent le serveur en lui-même. La figure 3 représente l’architecture du
serveur vidéo.
Disk Serveur
Disk Serveur
Disk Serveur
Disk Serveur
Meta Serveur
Client
Client
Client
Client
F IG . 3 – Architecture du serveur vidéo
Le stockage des vidéos est distribué sur plusieurs machines afin d’optimiser la performance du
9
serveur vidéo.
Meta-serveur constitue les éléments clefs de l’architecture du serveur vidéo :
– Il stocke les “meta-informations”. Ce sont ces informations qui lui permettent d’exécuter
les tâches dont il est chargé. Voici les différentes meta-informations stockées par le metaserveur :
– des listes de disk-serveurs : la liste des disk-serveurs stockant chaque vidéo est disponible à partir du meta-serveur : c’est grâce à cette liste que le meta-serveur peut
initialiser les connections entre le client et les disk-serveurs en fonction de la requête
du film formulée par le client au meta-serveur.
– la taille du film en temps : cette information permet aux applications du client de
détecter la fin du film et de se terminer.
– les types de distribution des différentes vidéos et de duplication utilisés pour chaque
film : suivant les disk-serveurs connectés ou non, le Meta-serveur peut déterminer si
le client peut ou non avoir accès au film demandé.
– Il gère les admissions des clients. C’est lui qui décide si un client peut se connecter au
serveur ou non en fonction du nombre de clients déjà connectés, et des capacités du
serveur.
– Quand le Meta-serveur admet un client, il établi une connection entre lui et ce dernier.
Le Meta-serveur fournit au client la liste des films disponibles et c’est lui qui re¸coit la
requête du client.
– Il initie les connections entre les différents composants du serveur vidéo : Les connections
entre le client et les disk-serveurs sont initialisées à partir des informations que le Metaserveur obtient du client (film sélectionné, port et adresse) et de la liste des disk-serveurs
sur lesquels est stocké le film demandé par le client.
Ces différentes fonctionnalités sont représentées sur la figure 4.
Disk-serveur est une machine à laquelle sont connectés plusieurs disques. Le serveur vidéo
en lui-même est constitué du Meta-serveur et de plusieurs disk-serveurs qui sont chargés des
taches suivantes (cf Figure 5):
– Un disk-serveur stocke des morceaux de vidéos sur les disques qui lui sont attachés. Le
stockage des films sur des disques permet un accès mémoire plus rapide que les bandes
magnétiques ; les disques permettent également à plusieurs utilisateurs d’accéder à une
même donnée simultanément.
10
Stoquage des Meta informations
Meta Serveur
Initialisation des connections
Disk Serveur
Controle des admissions
Client
F IG . 4 – Fonctionalités du Meta-serveur
– Il coordonne les fonctions de lecture et d’envoi des données afin de garantir leur distribution aux clients de manière interactive (play, pause...etc.).
– Il exécute les fonctions de maintenance du serveur ordonnées par le Meta-serveur (écriture sur les disques, suppression de films, renommage de films...etc.).
Stoquage des donnees video
Acces au reseau
Disk Serveur
Coordination
Meta Serveur
Client
F IG . 5 – Fonctionalités du Disk serveur
le Client permet à l’utilisateur d’accéder aux fonctionnalités du serveur au travers d’une interface. Ceci inclut (cf Figure 6):
– l’affichage de la liste des films disponibles fournie par le Meta-serveur
– l’accès aux fonctions d’interactivité (play, pause...etc.)
– la réception des données vidéo
– l’assemblage des données vidéo
– la visualisation des données vidéo grâce à un “player process”
11
Visualisation
Interraction
Client
Acces au reseau
Meta Serveur
Disk Serveur
F IG . 6 – Fonctionnalités du client
2.3.4
Flux de messages et d’information au sein du serveur vidéo
On peut donc représenter les interactions entre les différentes composantes du serveur vidéo par
le schéma récapitulatif de la figure 7.
1. Flux des Meta informations : le Meta-serveur transmet au client les informations dont
il a besoin pour émettre la requête d’un film, et pour être connecté aux disk-serveurs
stockant le film demandé. Le client transmet au Meta-serveur les informations requises
pour l’initialisation des connections avec les disk-serveurs.
2. Flux du control vidéo : Le client commande la lecture du film par les fonctions classiques
play, pause...etc. Les disk-serveurs accusent la réception.
3. Flux des données vidéo : Les disk-serveurs envoient les blocs de données vidéo au client.
4. Flux des informations du serveur : ce sont les informations internes au serveur qui transitent par cette voie. Le Meta-serveur prévient les disk-serveurs concernés par la requête
d’un client. Les disk-serveurs donnent la confirmation de la disponibilité des données
vidéo.
Seul le flux des données vidéo est unidirectionnel et de volume important, les autres flux sont
bidirectionnels et de faible volume.
Pour plus de précision, la figure 8 illustre ce qui se passe chronologiquement entre le moment
où le client émet la requête pour une vidéo et la réception des premières séquences vidéo du
côté du client.
1. (figure 8(a)) Le client envoie le message MSG CLIENTOPENSTREAM pour le prévenir
qu’il désire avoir accès à un film. Le Meta-serveur lui demande son adresse et son port
qui seront utilisés pour établir les connections.
12
Disk Serveur
Disk Serveur
Disk Serveur
Disk Serveur
Meta Serveur
Client
Flux des Meta informations
Flux du control video
Flux des donnees video
Flux des information du serveur
F IG . 7 – Flux d’informations dans le serveur vidéo
2. (figure 8(b)) Le Meta-serveur détermine les Disk-serveurs sur lesquels est stocké le film
demandé par le client, il leur envoie le message MSG SERVERADDCLIENT, ainsi que
l’adresse, le port du client et le nom du film demandé.
3. (figure 8(c)) Les Disk-serveurs ouvrent une connection sur le client.
4. (figure 8(d)) Le client envoie le message MSG STREAM PLAY à tous les Disk-serveurs
par la connection de faible bande-passante établie avec les Disk-serveurs.
5. (figure 8(e)) Les Disk-serveurs envoient les blocs de données vidéo par la connection de
haute bande passante avec le client.
2.4 Vers un prototype de serveur vidéo d’une grande maturité
Afin d’aboutir à un prototype de serveur vidéo qui soit à la fois indépendant des plates formes
utilisées, scalable, d’une haute performance et fiable, quelques parties du prototype ont été
récon¸cues et réimplémentées. Nous avons identifié les parties qui nous paraissaient les plus
significatives et importantes pour être réalisées dans le contexte du projet d’expertise avec
CNET/France Telecom:
– Flexibilité et Portabilité: Le serveur vidéo doit être indépendant de la plate forme utilisée. En particulier, la partie client du serveur vidéo doit être reconcue et réimplémentée
en Java pour atteindre les deux objectifs suivants:
– Portabilité du code : le code doit être unique pour toute plate forme utilisée par le
client, ce qui n’est pas le cas pour le client actuel codé en C++.
13
Disk Serveur
Disk Serveur
Disk Serveur
Disk Serveur
Meta Serveur
Meta Serveur
Client
Client
(a) Le Client émet la requête au Metaserveur
Disk Serveur
(b) Le Meta-serveur transmet la requête
aux Disk-serveurs concernés
Disk Serveur
Disk Serveur
Disk Serveur
Meta Serveur
Meta Serveur
Client
Client
(c) Les Disk-serveurs se connectent au
Client
Disk Serveur
(d) Le Client appelle la commande PLAY
Disk Serveur
Connection (etablie)
Meta Serveur
Connection demandee
Message
Client
Donnee video
(e) Les Disk-serveurs envoient la données
vidéo
F IG . 8 – Flux des messages lors d’une requête d’un client
– Portabilité du décodage des données vidéo transmises : le décodage des flux vidéo
doit être indépendant de la plate forme utilisée par le client. Dans la version du
client implémenté en C++, on a par exemple deux décodeurs MPEG distincts : l’un
tournant sur PC, l’autre sur station UNIX.
14
– Performance : Le serveur vidéo doit permettre à plusieurs clients d’être servis simultanément. L’étude de la performance concerne le nombre maximum de clients qui peuvent
être supportés et le besoin en ressources, surtout en ce qui concerne la bande passante.
– Qualité de service : on peut résumer la qualité de service du serveur vidéo par les trois
contraintes suivantes:
1. La maı̂trise du temps de latence initial qui est le temps écoulé entre l’envoi d’une
requête du côté du client jusqu’au moment où ce dernier re¸coit la première séquence
vidéo.
2. La répartition de la charge qui a un impact direct sur la performance du serveur
vidéo. Celle-ci doit être répartie équitablement sur toutes les composantes du serveur
vidéo.
3. La fiabilité du serveur vidéo. Elle se mesure par la capacité du serveur à survivre à
des pannes de certaines de ses composantes. La fiabilité du serveur vidéo est d’une
importance telle que la simple panne d’un disque ou d’un noeud du serveur vidéo
affectera toutes vidéos stockées dans le serveur ainsi que tous les clients servis. D’où
la nécessité d’implémenter et de tester le mécanisme de fiabilité pour le prototype
du serveur vidéo.
3 Développements complémentaires et consolidation effectués
dans le cadre du projet de l’expertise
3.1 Portage de la partie client en Java
3.1.1
Résumé
La partie client qui a été implémentée en C++ a été réimplémentée en Java, ce qui permettra de
rendre la partie client indépendante de la plate-forme utilisée. Le travail de migration consiste
à concevoir et implémenter en Java la partie client du prototype existant. Ceci inclut les points
suivants:
– La gestion des connections Client/Serveur.
– La gestion de la mémoire vive du côté du client.
– La gestion de la réception, du décodage et de l’affichage des flux vidéo.
– Le support des fonctions classiques d’interactivité.
– La détection des pannes de certaines composantes du serveur. Nous nous sommes décidés
pour une détection de pannes initiée chez le client et non chez le serveur afin de réduire
la complexité du côté du serveur vidéo.
15
– La conception d’une interface graphique conviviale
– L’étude de la performance du client. La performance du client est déterminée par le temps
de latence initial, le besoin en buffer chez le client et la rapidité du client de détecter et de
gérer les pannes des composantes du serveur vidéo.
3.1.2
Outils et tâches à accomplir
Nous utilisons l’outil JMF (Java Media Framework) qui constitue un ensemble de classes
et librairies Java qui supportent le streaming et le décodage des données multimédia. JMF est
un ensemble de classes permettant la visualisation et la capture de données multimédia à partir
d’une application ou bien d’une applet. Ceci inclut la visualisation de séquences vidéo compressées sous plusieurs formats dont celui de MPEG-1 que nous considérons. Plus précisément, nous
utilisons le Java Media Player du JMF pour la partie client. Cependant, le Java Media Player
visualise normalement une vidéo sous forme de fichier et non sous forme d’un flux continue.
Ceci nous a emmené à intégrer des changements radicaux au sein des routines utilisées afin de
supporter la visualisation des flux provenant des différents noeuds du serveur vidéo.
Voici les différentes tâches effectuées pour la migration du client en Java:
1. Gérer les communications Client/Meta-Serveur et Client/Disk-Serveur.
2. Re¸cevoir les données MPEG1 provenant des différents Disk-Serveurs
3. Gérer le buffer d’une fa¸con autonome. Le stockage des blocs provenant des disk-Serveurs
dans le buffer permet d’une part de gérer les retards des blocs dus au réseau et d’autre part
de détacher les fonctions du Java Media Player de JMF des tâches de réception des blocs.
Ceci permet de réaliser un client modulaire composé de parties indépendantes.
4. Réalisation du décodage et de la visualisation en JMF. A côté des avantages de portabilité
de JMF, il permet aussi d’obtenir le “full Screen” sous UNIX ce qui n’était pas possible
auparavant avec le client en C++. Le “resize” est devenu aussi possible (déterminer une
taille de fenêtrage quelconque).
5. Gestion et Structures de données. Nous avons utilisé l’héritage Java pour réaliser une
implémentation objet.
16
3.1.3
Implémentation du client en Java
L’implémetation a été réalisée d’une fa¸con modulaire. Ceci s’exprime sous forme de packages.
Le code est globalement composé de 6 packages qui sont les suivants:
1. Module inter (Interface client): Ce package contient les classes Interface et HelpVod.
(a) Classe Interface: C’est la partie visible de l’application. L’utilisateur dispose des
fonctions d’interactivité suivantes pour l’application VOD.
–
–
–
–
–
–
–
–
Liste des films disponibles
Play
Pause
Forward
Backward
to 0
Stop
Exit
Les boutons sont disponibles (activés ou désactivés) conformément aux contraintes
imposées par la partie serveur. La réaction du serveur n’est pas immédiate et il faut
aussi gérer les temps de latence dû au buffer. La figure 9 montre l’interface en mode
PAUSE avec le bouton correspondant à la commande PLAY activée , la figure 10
montre l’interface en mode PLAY, avec le bouton correspondant à la commande
PAUSE activée.
F IG . 9 – L’interface Client en mode PAUSE
Le menu de l’interface permet de configurer le client, de quitter le logiciel, de configurer l’application pour du mirroring et aussi d’obtenir une boite d’aide. Le mirroring peut ainsi être activé ou désactivé lors du déroulement du film. Par défaut il n’y
a pas de mirroring, il faut l’activer si on per¸coit une discontinuité dans le film ou
pour effectuer des tests.
17
F IG . 10 – L’interface Client en mode PLAY
La liste des films disponibles est générée par le Meta-serveur après la requête du
client : ==Requete sur le Metaserveur
listeFilms = clientMeta:getV ideoList();
Le JMF est une application de l’interface et est initialisée au même niveau. Le protocole et la connexion de la source d’information est réalisée dans l’initialisation de
l’interface.
L’instanciation du JMF passe par une phase de contrôle du protocole de communication défini au préalable. Ensuite il faut lier la source de l’information au JMF
et ceci requiert une connection de type Socket (voir le module de connection). La
source est le buffer et le player est connecté avec une dataSource. Il faut s’assurer
du bon fonctionnement de l’opération en utilisant des exceptions.
La création du panel graphique du JMF est généré lors du premier appel à play. En
effet, le JMF a besoin de lire la séquence 0 pour déterminer la résolution du film.
Le JMF attend donc la première trame avant de se déclarer en tant que composant
graphique.
(b) Classe HelpVod: C’est une trame d’aide à l’utilisation du logiciel.
2.
Module buffer: Ce module contient les classes CellBuffer, Buffer et ReaderBuffer.
(a) Classe CellBuffer :
C’est une structure d’information qui permet d’identifier les données du buffer (VideoBlockInfo) et de stocker les blocs. Les méthodes permettent un accès aux données sous certaines contraintes. En effet, la cellule de stockage est soit bloquée soit
débloquée. Cette gestion permet de définir les blocs en mode lecture et les blocs
disponibles en écriture .
18
(b) Classe Buffer :
C’est une classe importante, car elle est autogérée au niveau de son évolution. C’est
une liste de CellBuffer qui s’autogère. Cette classe comporte plusieurs algorithmes
qui permettent de prendre en compte les contraintes du réseau. Ainsi nous avons fait:
– la mise en place des données ,! Ordering
– Le repérage des séquences manquantes ,! Mirroring
– La gestion des données disponibles
– La gestion de la capacité
Ordering : Il s’agit d’un algorithme qui met à disposition du JMF la bonne séquence. Pour définir la bonne séquence nous utilisons le fait qu’un film est séquentiel, et donc il nous reste à lire la séquence d’indice le plus faible qui n’a pas été lue
auparavant dans le buffer.
Mirroring : Le buffer dans sa conception nous permet aussi de détecter les séquences manquantes. En effet, un séquence manquante est très facile à repérer par
un indice manquant dans la suite des séquences. Par exemple si nous avons dans le
buffer :
10 11 12 14 15 =) Pas d’erreur
10 12 13 14 15 =) Une erreur : séquence 11 manquante
En effet, nous avons une taille de buffer qui nous garantie que si la séquence 10 + 1
ne correspond pas à la séquence 11, il y a alors un problème au niveau de l’émission
des données (les Disk-serveurs). Le mirroring est disponible lorsque le buffer est
totalement rempli.
La détection est basée sur le principe que la séquence nécessaire est arrivée dans
le cas où le déroulement des opérations est normal. Le buffer permet d’attendre la
bonne séquence et donc de tolérer un certain retard. Mais si lors de l’écriture dans
le JMF il manque une séquence, on est alors certain qu’il y a un problème au niveau
de l’émission de cette même séquence.
Les données disponibles : Pour gérer l’ordering, le buffer se remplit totalement et
commence l’émission des données vers le JMF. Cela induit un temps de latence mais
sécurise le flux de données. En effet, on est alors sûr d’avoir une séquence valide
(Ordering).
Gestion de la capacité du buffer : Le buffer est actif au niveau du JMF quand il
est rempli. Cette solution permet d’avoir une fluidité et aussi des tests tels que le
Mirroring.
C’est un test bloquant pour le JMF et pour l’écriture dans le buffer. On lit quand on
est en mode lecture et on écrit quand on ne l’est pas.
19
3. Module info: Ce package contient les classes: DiskGroupInfo, VideoInfo, VideoBlockinfo, ServerInfo, HostInfo et Options.
(a) Classe DiskGroupInfo : L’information sur les serveurs et les disques est stockée
dans cette classe.
L’implémentation est relativement simple et comporte seulement des accésseurs.
(b) Classe VideoInfo : La classe VideoInfo hérite de DiskGroupInfo pour créer une
classe plus complète. L’information sur la vidéo courante est alors complète. Le
choix de l’héritage à ce niveau est naturelle contrairement à la version C++ où il y a
une simple encapsulation des structures.
(c) Classe VideoBlockInfo : Chaque bloc de données est liée à une information relative
à ce même bloc.
(d) Classe ServerInfo : La structure existe mais n’est pas utile pour le client. Cette sera
utile pour l’implémentation d’un Disk-Serveur basé sur Java.
(e) Classes HostInfo et Options: Ce sont des classes essentiellement destinées à effectuer des statistiques sur les temps de latence et la charge du CPU.
4. Module connection: Gère les connections et la réception des données. Ce module contient
les classes: MessageConnection, ConnectionDisk, ConnectionClientMeta, CreateSocket,
MyDataOutputStream, MyDataInputStream.
(a) Classe MessageConnection : La communication TCP permet de recevoir et d’émettre
des données et ceci en relation avec un serveur. Nous disposons d’un serveur VOD
possédant son propre protocole. La messagerie est très spécifique et il faut définir
des méthodes de plus haut niveau pour obtenir une bonne gestion des messages.
(b) Classe ConnectionClientMeta : C’est une connection spécialisée qui utilise la classe
MessageConnection pour la communication de plus haut niveau. Le Meta-serveur
est alors adressé par cette classe suivant le protocole Client/Meta-Server. La gestion
est de plus haut niveau et les requêtes sont plus faciles à émettre.
(c) Classe ConnectionDisk : Cette classe est vouée à la réception des paquets MPEG.
Elle gère la connection entre le client et Les Disk-Serveurs. La partie réseau est
liée par deux connections TCP et la partie client stocke les informations dans le
buffer. Une connection permet de commander les Disk-Serveur suivant un protocole
simple (MessageConnection) tandis que l’autre connection est chargée de l’envoi
des paquets. Cette structure est Thread par sa conception et ainsi le buffer re¸coit les
paquets de fa¸con asynchrone.
La réalisation des connections dépend donc des Disk-Serveurs. En effet, le client
attend une tentative de chaque serveur. La connection TCP est établie par l’instantiation de la classe DataInputStream :
(new DataInputStream((soquetteServeur1:accept()):getInputStream()); ):
20
(d) Classe CreateSocket : Cette classe est dédiée à l’initialisation du JMF. C’est une
connection interne qui attend un ServerSocket du JMF. Son implémentation est
Thread et l’attente est gérée par une exception.
(e) Classes MyDataOutputStream et MyDataInputStream :
Ces deux classes sont dérivées de DataOutputStream et DataInputStream pour des
raisons de spécialisation. Cela permet une gestion de plus haut niveau :
0 public void send(String chaine)f
1 send(chaine:length());
2 try f
3 writeBytes(chaine);
4 flush();
5 gcatch(IOExceptionio)f
6 System:out:println("SEND ECHEC sur les chars");
7g
8g
5. Module config: C’est le package de configuration du client VOD et contient les classes
Config et HelpConfig.
Classe Config : Pour utiliser le client VOD il est nécessaire au préalable de le configurer :
Il faut spécifier son identité, le nom du serveur et surtout sous quel mode on veut évoluer
(ATM ou Ethernet). Il est possible de configurer l’application avant de lancer le client
(ceci est fortement recommandé pour la première utilisation du logiciel).
6. Module vodpull: Ce package nous est imposé par JMF. En effet, le Java Media FrameWork permet de définir sa propre source de données. L’utilisation la plus courante du JMF
est la lecture de fichier MPEG. Dans notre cas, la configuration est totalement différente.
Les données ne sont pas disponibles dans un fichier mais elles arrivent par paquets. Il faut
donc redéfinir la source des données au niveau du JMF. Il existe deux type de protocole
pour le contrôle de la source :
– Contrôle de la source PushDataSource
– Source non contrôle PullDataSource
Le deuxième cas nous concerne, les informations arrivent séquentiellement. L’implémentation de l’interface doit être précise. Dans notre cas la source provient du buffer. L’alimentation en données est réalisée par la classe ReadBuffer. Le flux de données n’est pas
continu et est dirigé dans un stream.
Le module vodpull contient plusieurs classes liées à l’implémentation de l’interface de
JMF. Le protocole ainsi que le type de la source est redéfinit. Le reste du JMF n’est pas
reimplémenter et on utilise les classes fournies par SUN.
21
3.1.4
Migration du client en Java: Résultats
Nous avons réimplémenté la partie client du prototype en Java. Le code fourni est modulaire et
concerne les parties suivantes:
1. La gestion des connections Client/Serveur : C’est le premier point sur lequel nous nous
sommes penchés. Partant des classes Java permettant d’instancier des objets de type Socket, nous avons créé nos propres classes adaptées au protocole de communication entre
le client et le Meta-Serveur et entre le Client et les disk-Serveurs.
2. La gestion de la mémoire (du côté du client) : La gestion de la mémoire du client est gérée
à l’aide des classes appartenant au module buffer.
3. La gestion de la réception, du décodage et de l’affichage des flux vidéo : La réception des
données vidéos est gérée dans la classe ConnectionDisk. Le décodage et l’affichage des
flux vidéo se fait à travers le JMF.
4. Le support des fonctions d’interactivité : Les fonctions d’interactivité sont gérées dans la
classe ConnectionDisk. Les fonctions classiques de contrôle vidéo sont disponibles par
l’intermédiaire de l’interface.
5. La détection des pannes de certaines composantes du serveur : Le client détecte si des
blocs ne lui parviennent pas. Si le mécanisme de réplication des données (mirroring) est
activé du côté du serveur, ce dernier se charge d’envoyer les blocs manquants vers le
client.
6. La conception d’une interface graphique conviviale : La classe Interface instancie une
interface munie de toutes les fonctionnalités énumérées dans la section ??
Nous avons intégré le nouveau client au sein de notre prototype de serveur vidéo et effectué des
tests de performance et de qualité de service. Nous avons considéré plusieurs environnements
(Ethernet et ATM) et des plates formes différentes (UNIX et NT). Après avoir validé les différentes fonctions du nouveau client, nous avons examiné le temps de latence qui représente le
critère de performance le plus significatif du client. Le temps de latence est défini comme le
temps qui s’écoule entre l’émission d’une requête par le client et l’instant où la première image
est visualisée chez ce dernier. Ce temps de latence est la somme de deux valeurs qui sont les
suivantes:
– le temps écoulé entre l’émission d’une requête et l’établissement des connections entre le
client et les différents disk-Serveurs. Ce temps t0 est négligeable (de l’ordre de quelques
22
millisecondes) et correspond à la somme des RTT des différents messages nécessaires
pour initialiser ces connections.
– le temps écoulé entre la commande “PLAY” et l’affichage de la première image du film
à l’écran : avant de lancer la visualisation du côté du client, celui-ci stocke en mémoire
quelques blocs consécutifs pour réordonner les blocs et les afficher dans les délais. Afin
de permettre cette bufferisation, un espace buffer de l’ordre de (n + 2) fois la taille du
bloc doit être réservé où n désigne le nombre de connections que le client maintient
avec les différents Disk-Serveurs. Par conséquent un temps de latence supplémentaire est
nécessaire ; il est de l’ordre de (n + 2) fois la durée d’une période (dans notre cas, une
période est égale à une seconde).
Le temps de latence tL est donc : tL = (n + 2) + t0. Par exemple un client ayant émis une
requête pour une vidéo stockée sur trois noeuds verra apparaı̂tre les premières images du film
5 secondes après l’émission de la requête (on considère t0 comme négligeable). Si le client effectue un “FORWARD”, “REWARD” ou “REPOSITIONNING” avant la commande “PLAY”,
le temps écoulé entre la commande “PLAY” et l’affichage des prochaines images est supérieur
à tL. En effet le repositionement des variables dans le buffer nécessite une demi-seconde supplémentaire, le temps de latence est alors tL = tL + 0:5. Toujours avec le même exemple, si le
client effectue un repositionnement de la vidéo, il verra apparaitre de nouvelles images à l’écran
5:5 secondes après avoir appuyé sur la commande “PLAY”.
0
3.2 Réimplémentation des algorithmes d’ordonnancement et d’extraction
des données
3.2.1
Motivation
Plusieurs projets étudiants ont contribué à la réalisation du prototype de serveur vidéo d’Eurécom. Ce prototype a donc évolué en lui intégrant des nouvelles fonctionnalités telles que les
mécanismes de fiabilité ou encore les méthodes de distribution des données. Un projet avec
France Telecom (Agora-Sophia Antipolis) et IBM (la Gaude) nous a permis de valider l’architecture distribuée du prototype. Dans le cadre de ce projet, nous avons configuré un prototype
composé de 6 noeuds dont un chez France Telecom et un autre chez IBM. Nous avons validé
les algorithmes de distribution des données à distance ainsi que les mécanismes de fiabilité.
En utilisant la plate forme ATM (Eurosud 155) liant Eurécom, France Telecom Agora et IBM
la Gaude, nous avons validé le bon fonctionnement de l’application de la vidéo à la demande.
Les clients étaient aussi localisés dans ces différents locaux. En outre, nous avons effectué des
tests de performance du prototype de serveur vidéo en variant la configuration du serveur en
terme du nombre de disques et de noeuds du serveur. Ces tests ont été effectués sur Ethernet
et aussi sur ATM. Les résultats ont montré que la performance de notre prototype de serveur
vidéo n’augmente pas en fonction du nombre de ses composantes. Ce problème nous paraissait
23
majeur et nous devions le résoudre afin d’aboutir à une configuration de serveur vidéo dont la
performance serait proportionnelle au nombre de ses composantes. Afin de résoudre ce problème de performance, nous avons commencé par trouver le goulot d’étranglement du serveur
vidéo. Deux alternatives ont été étudiées: le goulot d’étranglement est la capacité hardware, ou
il est lié à l’organisation du logiciel.
Dans le reste de cette section, nous présenterons les travaux qui ont été fait afin de résoudre les
problèmes indiqués ci-dessus.
3.2.2
Implémentation de l’ordonnancement asynchrone
Comme nous l’avons déjà évoqué, la performance du serveur vidéo n’évolue pas d’une fa¸con
linéaire en fonction du nombre de ses composantes (disques et noeuds). Nous avons étudié les
différentes possibilités qui pourraient en être l’origine. Nous avons tracé des scénarios multiples
où nous avons considéré trois différents modes de fonctionnement du serveur vidéo qui sont:
– Le mode read only, où le serveur vidéo n’effectue que des opérations de lecture (au niveau
de ses disques SCSI). Ce mode permet de bien déterminer la capacité des disques SCSI
en terme de débit de lecture.
– Le mode read and write, où le serveur vidéo effectue en plus des opérations de lecture
mais aussi des opérations d’écriture dans le buffer. Ceci permet de déterminer la capacité
de la machine en terme de débit interne d’écriture. Ceci permet aussi de déterminer le
nombre maximum de disques SCSI qui peuvent être connectés à une seule machine.
– Le mode read, write, and send, qui traduit le fonctionnement normal du serveur vidéo.
Dans ce mode, nous ajoutons l’envoie des données par l’interface réseau de chaque machine, ce qui permet de déterminer le nombre maximum de flux que peut supporter une
configuration donnée (serveur et réseau).
Nous avons analysé les résultats obtenus de cette étude. Un problème majeur que nous avons
pu localisé est lié à l’organisation du logociel serveur. Ce dernier a empêché la scalabilité du
serveur, du moins dans le cas où les différents facteurs du hardware n’étaient pas saturés. Il nous
était donc indispensable de se pencher sur l’organisation du logiciel et plus précisément sur le
mécanisme d’ordonnancement au niveau de chaque Disk-Serveur.
Problème La lecture des différents blocs au niveau des disques d’un noeud était effectuée
d’une fa¸con synchrone et assuré par un seul thread. Ceci a impliqué que chaque noeud fut insensible à l’augmentation du nombre de ses disques. En outre, le mécanisme d’ordonnancement,
qui est distribué, traite sur chaque disque la totalité de la liste durant chaque unité de service (
chaque seconde), ce qui fait que la charge au niveau de chaque disque soit élevée d’une fa¸con
permanente.
24
Solution Le processus d’ordonnancement au niveau de chaque Disk-Serveur a été de nouveau
con¸cu. La technique de multi-threading a été implémentée. La nouvelle conception contient
trois types de threads qui sont:
– Les threads du mécanisme d’ordonnancement (scheduler threads) qui sont responsables
de l’initialisation des premières requêtes de lecture, du traitement des fonctions d’interactivité (play, stop ou repositioning) et aussi des requêtes provenant du Meta-Serveur et qui
concernent spécialement les nouveaux clients admis, les clients qui quittent la session, la
distribution des données, etc.. Il est à noter que chaque Disk-Serveur contient exactement
un thread d’ordonnancement.
– Les threads de lecture du disque (disk reader threads) qui sont responsables de la lecture
des données vidéo au niveau du disque. Chaque bloc lu est placé dans une file d’attente
(sender queue). En outre le thread de lecture détermine la prochaine requête de lecture du
flux en question et le place convenablement dans la structure du mécanisme d’ordonnancement. Il est à noter que chaque disque a son propre thread de lecture. Par conséquent,
l’introduction des threads de lecture permet de créer un parallélisme au sein du serveur
vidéo. En effet, plusieurs opérations de lecture peuvent être effectuées simultanément.
– Les thread d’envoi (sender threads) qui sont responsables de l’envoi des blocs provenant
de la sender queue. Chaque Disk-Serveur possède un thread d’envoi.
Étant donné que les parties du serveur vidéo sont liées, le changement profond effectué sur
l’ordonnancement des flux a entraı̂né des changements dans la majorité des modules et fonctions
du Disk-Serveur et aussi du Meta-Serveur. Par exemple, l’outil de distribution des données a été
implémenté afin d’adapter la distribution des blocs à la logique du multi-threading.
3.3 Utilisation de UDP pour le transfert des données
Nous avons toujours utilisé le protocole TCP pour la transmission des données vidéo, ce qui
n’est pas le choix idéal étant donné que TCP intègre ses mécanismes de fenêtrage et de contrôle
d’erreur et de flux qui peuvent souvent freiner la transmission fluide des données vidéo du
serveur vers les clients. Par conséquent, il nous paraissait indispensable d’utliser UDP pour la
transmission des données au lieu de TCP. Ce changement ne va pas être trivial vu que UDP
impose une taille limite des blocs envoyés du côté du serveur, ce qui nous obligera à segmenter
les blocs à envoyer au niveau du serveur et de les réassembler au niveau du client.
Afin de supporter un transfert haut débit et l’aspect temps réel de l’application de la VoD que
le serveur vidéo supporte, l’utilisation de UDP, qui est un protocole du type datagram, nous
paraissait adéquate. Cependant, étant donné que la taille d’un paquet envoyé sur le réseau est
limitée dans le cas de UDP (souvent à 64 KByte), les différents blocs doivent être segmentés
25
avant d’être émis sur le réseau. Du côté du client, les blocs originaux doivent être reconstruits
(réassemblage).
– Du côté du serveur, chaque Disk-Serveur, avant d’envoyer un bloc, découpe ce dernier en
sous-blocs d’une taille inférieure ou égale à 64 KByte chacun.
– Du côté du client, la couche UDP se charge du réassemblage des sous-blocs appartenant
au même bloc. Chaque bloc est donc régénéré progressivement au sein d’un buffe. Une
fois le bloc est reconstruit, ce dernier est envoyé au buffer du client et suit les étapes que
nous avons déjà détaillées dans la section 3.1.
Nous étions donc obligé d’introduire une sous-couche qui effectue la segmentation et le réassemblage afin d’utiliser UDP pour le transfert des données vidéo.
4
Tests d’evaluation de la performance du nouveau prototype de serveur vidéo
Après avoir modifié plusieurs parties du logiciel du serveur vidéo, la dernière phase de ce projet
a été dédiée à l’étude de la performance du prototype de serveur vidéo . Pour cela, nous avons
défini des scénarios de test qui nous permettront d’évaluer le débit et la scalabilité du serveur
vidéo. Dans cette section, nous montrerons les résultats de performance les plus significatifs de
cette étude.
Le débit du serveur vidéo est définit comme le nombre maximal de flux qui peuvent être supportés sans que le serveur vidéo soit saturé. Tous les clients admis sont servis une fois durant
chaque unité de service. Nous calculons le débit du serveur vidéo comme suit: Les files d’attente
qui sont utilisées au niveau de chaque Disk-Serveur pour détacher les commandes de lecture de
celles de l’envoi entre les différents threads servent aussi à mesurer le débit du serveur. En effet,
tant la taille de la file d’attente reste inchangé ou varie légèrement, le serveur n’a pas encore
atteint ses limites. En revanche, dès que la taille de la file d’attente augmente d’une fa¸con continue et dépasse un seuil, le serveur a bien dépassé sa capacité et le débit du serveur sera donc
identifié. Ce même principe va être utilisé pour introduire le mécanisme de contrôle d’admission
au sein du serveur vidéo.
Pour effectuer les tests, nous avons utilisé trois différentes familles de disques SCSI. Les disques
dits lents ont chacun une capacité de stockage de 1GByte et un débit de 4MByte=sec. La
deuxième famille contient des disques médium de 2GByte de capacité et de 10MByte=sec
en terme de débit pour chacun. Finalement, les disques dits rapides ont chacun une capacité de
9GByte et un débit de 20MByte=sec. Nous utilisons également des machines UNIX différentes:
SPARCstation 20, UltraSPARC 1 et UltraSPARC 10. Il est à noter que la SPARC20 est la
machine la moins performante, tandis que la Ultra 10 est la plus performante.
On considère une seule station UNIX et on lui connecte progressivement des disques. Nous
calculons le débit du serveur pour chaque configuration. Nous avons connecté les disques lents
26
progressivement avec une station lente SPARCstation 20 (configuration lente). En outre, nous
avons connecté les disques rapides progressivement avec une station rapide UltraSPARC 10
(configuration rapide). La figure 11 illustre les résultats obtenus. Ces résultats montrent que
– Le débit d’un serveur vidéo constitué d’un seul Disk-Serveur augmente en fonction du
nombre de disques qui sont connectés à ce Disk-Serveur.
– Les résultats obtenus avec la configuration lente (station SPARCstation 20 et des disques
lents) et aussi avec la configuration rapide montrent que le débit du serveur vidéo augmente bien quand le nombre de disques connectés augmente. Nous avons réalisé que dans
le cas d’une configuration lente, la capacité du serveur est déterminée par la capacité de
ses disques et non par celle de la machine SPARCstation20. En revanche, dans le cas
d’une configuration rapide, la limitation de la capacité du serveur est due à la limitation
de la capacité de sa machine. Ceci est lié à la capacité de l’adaptateur SCSI, ne dépassant
pas 40Mbytes=sec dans le cas de UltraSPARC 10 avec les disques rapides. Afin d’éliminer ce goulot d’étranglement, un deuxième controller doit être installé, ce qui aboutirai à
saturer la capacité du PCI Bus qui est limité à 66Mbytes=sec.
Debit du serveur video avec un Disk−Serveur
180
Nombre de clients admis
160
Configuration rapide
Configuration lente
140
120
100
80
60
40
20
0
1
2
3
Nombre de disques sur un noeud
4
F IG . 11 – Débit et évolutivité d’un serveur vidéo composé d’un Disk-Serveur
Le tableau 1 illustre les résultats obtenus avec plus de détails.
Nous considérons comme suit un serveur vidéo composé de plusieurs Disk-Serveurs afin de
tester son évolutivité et la performance quand on lui ajoute progressivement de nouvelles machines. Nous considérons les configurations lentes (SPARCstation 20 et disques lents) et les
configurations médium (UltraSPARC 1 et disques médiums). Chaque machine est connectée
uniquement à un seul disque. Nous mesurons le débit du serveur pour des configurations allant
d’une machine à 8 machines. Les résultats sont illustrés dans la figure 12. Ceux-ci montrent
que le débit du serveur vidéo augmente d’une fa¸con quasi linéaire avec le nombre de noeuds
contenus dans le serveur.
27
Configuration
Débit en nombre de clients Débit en Bytes/sec
SPARCstation 20 et 1 disque
13 clients
2:293:616 bytes/sec
SPARCstation 20 et 2 disques
26 clients
4:587:232 bytes/sec
35 clients
6:175:120 bytes/sec
40 clients
7:057:280 bytes/sec
UltraSPARC 10 et 1 disque
72 clients
12:703:104 bytes/sec
UltraSPARC 10 et 2 disques
112 clients
145 clients
25:582:640 byte/sec
173 clients
30:522:736 byte/sec
TAB . 1 – Résultats de performance pour un serveur vidéo composé d’un Disk-Serveur
Nombre de clients admis
Debit du serveur video avec plusieurs Disk−Serveurs
100
Configurations lentes et medium
90
80
70
60
50
40
30
20
10
1
2
3
4
5
6
7
Nombre de noeuds dans le serveur
8
F IG . 12 – Débit et scalabilité d’un serveur vidéo composé de plusieurs noeuds
Le tableau 3 montrent ces résultats en détails.
Nous avons vu que le serveur vidéo est bien scalable en terme du nombre des disques qui sont
Configuration
1 SPARCstation 20
12 clients
2:117:184 bytes/sec
2 SPARCstation 20
24 clients
4:234:368 bytes/sec
3 SPARCstation 20
33 clients
5:822:256 bytes/sec
4 SPARCstation 20
43 clients
7:586:576 bytes/sec
4 SPARCstation 20 et 1 UltraSPARC 1
48 clients
8:468:736 bytes/sec
54 clients
9:527:328 bytes/sec
61 clients
85 clients
TAB . 2 – Résultats de performance pour un serveur vidéo composé de plusieurs Disk-Serveurs
28
contenus dans le même Disk-Serveur et aussi en terme du nombre de Disk-Serveurs qui sont
contenus dans le serveur vidéo. Nous allons combiner ces deux aspects et étudier la scalabilité
du serveur vidéo quand on varie le nombre de Disk-Serveur et le nombre de disques par DiskServeur. Un exemple des résultats est indiqué dans le tableau 3. Nous considérons d’un côté
deux machines rapides connectées à 1 ou à 2 disques chacune. De l’autre côté, nous examinons
la performance pour un serveur vidéo hétérogène composé de 4 machines ayant 1 disque ou 2
disques chacune.
Configuration
2 Ultra 10, 1 Ultra 1 et 1 SPARC 20
(1 disque par noeud)
2 Ultra 10, 1 Ultra 1 et 1 SPARC 20
(2 disques par noeud)
58 clients
111
:
19 587 504
clients
197 clients
25 410 816
144
2 Ultra 10 et (1 disque par noeud)
2 Ultra 10 et (2 disques par noeud)
:
clients
bytes/sec
: : bytes/sec
TAB . 3 – Débit d’un serveur vidéo composé de plusieurs noeuds et plusieurs disques
Les résultats du tableau 3 montrent que:
– Un serveur vidéo composé de machines hétérogènes est limité par la capacité de la machine la plus lente. Par exemple, un serveur vidéo composé de deux machines Ultra 10
ayant chacune deux disques atteint un débit de 197 clients. Cependant, un serveur constitué de 4 machines (deux Ultra 10, une Ultra 1 et une SPARC 20) ayant chacune 1 disque
a un débit qui ne dépasse pas 58 clients.
– Avec deux machines Ultra 10 ayant chacune 2 disques, le serveur vidéo atteint un débit de
197 clients. Sachant que l’interface réseau de chaque noeud du serveur vidéo ne dépasse
pas le débit de 90 clients qui consomment des flux MPEG1 à 1:5 Mbit/sec, nous déduisons
que le nombre de disques utiles qui doivent être connectés à une machine Ultra 10 est égal
à deux. Ajouter plus de disques ne contribuera pas à l’augmentation du débit du serveur,
mais seulement à celle de sa capacité de stockage.
– Les résultats montrent bien que le serveur vidéo est scalable et a la capacité d’atteindre
une très haute performance en terme du nombre de clients qui peuvent être admis simultanément.
L’étude de performance du serveur vidéo a été accompagné par l’étude de sa fiabilité . Cette
étude a consisté surtout à forcer la panne de quelques composantes du serveur vidéo et de
tester le bon fonctionnement des mécanismes de détection des pannes et de reconstruction des
blocs perdus. La reconstruction consiste à extraire les copies des blocs perdus. Les mécanismes
d’ordonnancement et d’extraction sont adaptés pour le mode de défaillance et les tests effectués
montrent que le serveur vidéo est capable de survivre dans le cas de la défaillance d’un de ses
29
Disk-Serveurs contenant plusieurs disques. Pour des raisons de test, le client est menu d’une
interface qui active et désactive le mécanisme de fiabilité, ce qui nous a permis de comparer
qualitativement l’impact de rendre le serveur vidéo tolérant à la défaillance de ses composantes.
5
Valorisation et démonstration
Le but de cette phase est de favoriser la valorisation des travaux auprès de partenaires potentiels. Dans ce cadre, nous mettons en place la plate-forme de démonstration dan les locaux
d’Eurecom. Ce rapport servira comme document de synthèse de positionnement du système à
valoriser, de ses techniques et des performances obtenues.
6
Conclusions
Dans le cadre du projet d’expertise entre l’Institut Eurécom et CNET/France Telecom, des travaux ont été effectués sur le prototype de serveur vidéo existant d’Eurécom. Ces travaux ont
permis d’atteindre les objectifs qui ont été indiqués dans la section 1.2 et qui sont les suivants:
– Refaire la partie client du serveur vidéo. Ceci consiste à implémenter le client en Java. La
migration du client vers Java a permis une indépendance totale de la machine et du système d’exploitation utilisés par le client. Le décodage des flux MPEG1 est ainsi effectué
de la même fa¸con sur UNIX et sur NT. Grâce à JMF, un client sur UNIX peut visualiser
le flux re¸cu en plein écran, ce qui n’était pas possible auparavant.
– Mener à bien les compléments de développement qui consistent en particulier à atteindre
une architecture flexible à la largeur d’échelle (scalable) tout en gardant l’aspect distribué
de l’architecture ainsi que des algorithmes d’ordonnancement et de stockage des données. Dans ce cadre, nous avons réimplémenté les mécanismes d’ordonnancement chez
les Disk-Serveurs et adapté l’outil de distribution des données aux changements effectués La réimplémentation de l’outil d’ordonnancement a permis de paralléliser la lecture,
l’écriture et l’envoi des blocs, ce qui a permis d’atteindre une scalabilité et haute performance que nous avons illustré. Nous avons tout de même conservé l’aspect distribué de
l’ordonnancement et de l’exécution des tâches au sein de chaque Disk-Serveur, ce qui garantie la flexibilité du serveur et la possibilité d’ajouter de nouvelles composantes quand
c’est nécessaire.
– Garantir un fonctionnement fiable de ces logiciels. La détection des pannes est immédiate
et déclenche l’envoi des copies des blocs perdus. L’étude fiabilité du serveur vidéo était
qualitative. Pour le client, une panne d’un disque ou d’une machine entraı̂ne une interruption de quelques secondes, après laquelle le serveur est capable de reconstruire les
données perdues et le client verra son flux reprendre sa continuité.
30
– Tests et validation. Les différents tests de performance et de scalabilité du nouveau prototype de serveur vidéo ont montré que le serveur vidéo est scalable en terme du nombre
de disques qui sont contenus dans un Disk-Serveur et aussi en terme du nombre de DiskServeurs qui sont contenus dans le serveur vidéo. L’étude a aussi permis de déterminer les
différentes limites de la hardware et le nombre utile de disques qui doivent être connectés
à chaque Disk-Serveur.
Références
[1] C. Bernhardt and E. W. Biersack, “The server array: A scalable video server architecture,” in High-Speed Networks for Multimedia Applications (W. Effelsberg, A. Danthine,
D. Ferarri, and O. Spaniol, eds.), Kluwer Publishers, Amsterdam, The Netherlands, 1996.
[2] C. Bernhardt and E. W. Biersack, “The server array: A novel architecture for a scalable
video server,” in Conference on Distributed Multimedia Systems and Applications, (Stanford, USA), pp. 85–88, Aug. 1995.
[3] J. Gafsi and E. W. Biersack, “Data striping and reliablity aspects in distributed video
servers,” In Cluster Computing: Networks, Software Tools, and Applications, vol. 2 (1),
pp. 75–91, February 1999.
[4] E. W. Biersack and F. Thiesse, “A new class of constant data length retrieval algorithms
for video servers with vbr streams,” in Multimedia Storage and Archiving Systems, SPIE
Photonics East ‘96 Symposium, (Boston, MA), Nov. 1996.
[5] E. W. Biersack, F. Thiesse, and C. Bernhardt, “Constant data length retrieval for video
servers with variable bit rate streams,” in Proc. of the IEEE Conf. on Multimedia Systems,
(Hiroshima, Japan), pp. 151–155, June 1996.
[6] E. W. Biersack and F. Thiesse, “Statistical admission control in video servers with constant
data length retrieval of vbr streams,” in Third International Conference on Multimedia
Modeling, (Toulouse, France), pp. 423–438, World Scientific, Singapore, Nov. 1996.
[7] E. W. Biersack, W. Geyer, and C. Bernhardt, “Intra- and inter-stream synchronization for
stored multimedia streams,” in Proc. of the IEEE Conf. on Multimedia Systems, (Hiroshima, Japan), pp. 372–381, June 1996.
[8] E. W. Biersack and W. Geyer, “Synchronized delivery and playout of distributed stored
multimedia streams,” ACM Multimedia Systems, vol. 7, pp. 70–90, Jan. 1999.
[9] J. Gafsi and E. W. Biersack, “Performance and reliability study for distributed video servers: Mirroring or parity?,” in Proceedings of the IEEE international conference on multimedia computing and systems (ICMCS’99), (Florence, Italy), June 1999.
31
[10] J. Gafsi and E. W. Biersack, “Performance and cost comparison of mirroring- and paritybased reliability schemes for video servers,” in Proceedings of KiVS’99, (Darmstadt, Germany), March 1999.
[11] J. Gafsi and E. W. Biersack, “Modeling and performance comparison of reliability strategies for distributed video servers,” to appear in IEEE Transactions on Parallel and Distributed Systems, February 2000.
[12] J. Gafsi and E. W. Biersack, “A novel replica placement strategy for video servers,” in
Proceedings of the 6th International Workshop On Interactive and Distributed Multimedia
Systems IDMS’99, Toulouse, France, October 12-15 1999.
[13] J. Gafsi, DESIGN AND PERFORMANCE OF LARGE SCALE VIDEO SERVERS. PhD
thesis, ENST Paris, Institut Eurecom, November 1999.
[14] J. Gafsi and E. W. Biersack, “Serveurs video: Architecture et perfromance,” Hermes
Science Publications, 1999.
[15] J. Gafsi, U. Walther, and E. W. Biersack, “Design and implementation of a scalable, reliable, and distributed vod-server,” in Proceedings of to the 5th joint IFIP-TC6 and ICCC
Conference on Computer Communications, October 1998.
[16] W. Ulrich, “Design and implementation of a distributed, reliable mpeg video server on atm
networks using forward error correction methods,” November 1997.
[17] J. Exner, “A reliable video server based on mirroring: Design, implementation, and performance analysis,” Master’s thesis, University of Karlsruhe/Institut Eurecom, Sophia Antipolis, France, Jan. 1999.
32

Rapport d`Expertise d`un Prototype de Serveur Vidéo

Transcription

Documents pareils

DF.18-01 Fiche produit - Sku Pied à coulisse pour disques

Fiche technique – 208 T16 Pikes Peak :

PD-M426

Boitier Externe USB pour 4 disques durs IDE

Quad Hytrack 320 2

Accord Exacta HL__TL ALLOWIN QUATRO

Subject: Le Matériel

Amélie D

Disque dur de 500 Go bientôt chez maxtor La compagnie de

Projet de JAVA : Moteur de recherche d`images