A new distributed storage scheme for cluster video server

A new distributed storage scheme for cluster video server

q

Xiaofei Liao,Hai Jin

*

Cluster and Grid Computing Lab,School of Computer Science and Technology,Huazhong University of Science

and Technology,430074Wuhan,China

Received 5September 2002;received in revised form 4March 2004;accepted 13September 2004

Available online 11November 2004

Abstract

For cluster video servers,it is very important to design a good distributed storage system with high performance.One of the important issues in designing a good distributed storage system is how to store multimedia data on many storage nodes.This issue includes two topics:the scheme of splitting an entire ?le into many clips,and the storage of these clips on many nodes.We have designed a new multimedia data storage scheme for cluster video server.In the new system,a novel multimedia ?le splitting scheme,named Owl,and a clips striping scheme have been proposed.In contrast with tra-ditional media data splitting schemes based on ?xed space length and constant time length,Owl is addressed with the consideration of spatial and temporal information.This scheme Owl has universality for every media format encoded based on time and makes cluster video servers work e?ciently.Besides,the scheme Owl is feasible and easy to implement.With the data splitting scheme and the clips striping scheme,cluster video servers have good performance.ó2004Elsevier B.V.All rights reserved.

Keywords:Cluster;Multimedia;Splitting;Storage system;Scalability

1.Introduction

The past few years have witnessed many design studies describing di?erent schemes of a server that

supports continuous media data types,such as audio and video.The novelty of these studies is attributed to two very important requirements of continuous media that are di?erent from tradi-tional textual data.At ?rst,the realization of mul-timedia services such as video-on-demand requires servers that are able to support a large number of concurrent users,which must share resources of systems.Second,objects of this media type are typically large in size.For example,a MPEG-1en-coded video with two hours requiring 1.2megabits per second (Mbps)for its display is 1.2GB in size.

1383-7621/$-see front matter ó2004Elsevier B.V.All rights reserved.doi:10.1016/j.sysarc.2004.09.001

q This paper is supported by National 863Hi-Tech R&D Project under grant No.2002AA1Z2102.The preliminary version of this paper has been presented at 28th Euromicro Conference 2002.*

Corresponding author.Tel.:+862787543529;fax:+862787557354.

E-mail addresses:x?iao@https://www.360docs.net/doc/5417112202.html, (X.Liao),hjin@https://www.360docs.net/doc/5417112202.html, (H.

Jin).

Journal of Systems Architecture 51(2005)

79–94

To feed these requirements,more and more people tend to run these services on a cluster system com-posed of o?-the-shelf commodities for their low cost-e?ectiveness and fault-tolerant capability, and this area has attracted increasing attention of the researchers.

For a cluster video server,it is very important to design a distributed storage scheme[1,9,11, 12,16]with high performances.Based on these storage systems,the video servers can pump a huge amount of data from disks to many clients at the same time,which is a great challenge problem due to the relatively slow storage I/O and system bus I/O equipments.Many researchers have pro-posed several kinds of highly e?cient parallel mul-timedia storage systems to achieve a satisfactory I/O bandwidth,such as Tiger Shark File System [21],Frangipani[3]and xfs[26].But these schemes have one important shortcoming.Storage is dis-tributed,but delivery is centralized.Because in these systems,although data is partitioned into blocks and striped among storage nodes,it is nec-essary to encapsulate data from many nodes into packets according to a certain protocol like RTP [7],and?nally sent to clients for playing back when clients?requests are admitted.Fig.1has been described the traditional schemes.Fig.1is only conceptual and functional.

In real implementations,the proxy node can be conjoined with a storage node,or be a single node. From this graph,this storage architecture makes the internal network or proxy nodes potential bottlenecks for system performance because of the data?s centralization mode.Another problem is that every media data block,such as A1in Fig. 1,has no logical meanings and is?xed in size.There are many di?culties when clients execute VCR operations,such as SEEK,because the video ser-ver should locate in many distributed blocks data and?nd out the appropriate packets according to particular information of the proxy node.It is obvious that the proxy node cannot deal with too many requests from clients.The number of parallel streams in these cluster video servers is limited to their storage systems architectures.

We have designed and implemented a scalable video server using‘‘intelligent’’network attached storage disks based on a cluster system[5].In this system,a distributed storage system has been implemented,in which media data are distributed among every attached disk and are delivered di-rectly through gateways or switches.We get rid of proxy nodes and make every data storage node as server node.The storage nodes can work in a cooperative manner that makes the data from multiple independent nodes looks like from one machine.The characteristics of the storage system can be summarized into two sides:storage is distributed and delivery is also distributed;every clip of one movie is comprised of many data units with logical meanings and pseudo-?xed size.

There two elementary issues discussed when designing a distributed storage scheme for cluster video server.One is that how to split an entire movie?le into many clips with spatial and tempo-ral information;the other one is how to strip clips onto the distributed storage nodes.One splitting scheme decides clip?s size and clip?s structure. And the clip-stripping scheme must consider the reliability and the load balance performance.All these two aspects will decide the implementation of distributed controlling,distributed delivery

80X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–94

and the VOD server?s performance.They are the key problems for clustered video servers?storage systems.

In this paper,we have designed a new multi-media data storage scheme for cluster video server. In the new system,a novel multimedia?le splitting scheme,named Owl,and a clips striping scheme have been proposed.In contrast with traditional media data splitting schemes based on?xed space length and constant time length,Owl is addressed with the consideration of with spatial and tempo-ral information.This scheme Owl has universality for every media format encoded based on time and makes cluster video servers work e?ciently.Be-sides,the scheme Owl is feasible and easy to imple-ment.And the clips striping policy has taken the intra-movie skewness into consideration.With the clips striping scheme,cluster video servers have good reliability and load balance.

The paper is organized as follows.In Section2, we give the background of the study.Then we pre-sent the novel distributed storage scheme for clus-ter video server in Section3.Section4focuses on Owl in details.Section5focuses on the data strip-ing scheme.In Section6,a sample of how to schedule media streaming tasks under the help of Owl is discussed.We give some experimentations and optimizations for our scheme in Section7. In Section8we survey some related works.Finally, Section9closes with conclusions and future works.

2.Background

2.1.Overview of data splitting scheme

There are two traditional schemes to split mul-timedia?les.One is to divide a?le into many clips according to?xed size policy[19].The other is to split a?le into variable-size blocks[20,24]with equal playback units.Before we decide which split-ting scheme to be used,several factors need to be considered,such as disk overload,operation com-plexity,and system resource utilization.

Variable-size policy derived from the fact that most multimedia data are compressed into varia-ble bit rate(VBR)[15]data streams by time line.Every multimedia stream,such as the video stream and audio stream in MPEG-1format,is com-pressed independently and has its own time line. Therefore,this policy is a natural data splitting scheme according to the property of the multi-media data.Each clip has obvious logical mean-ing.But it has some shortcomings.Firstly,this method is very complex in practice.We have to deal with the time-related information and loca-tion operations between parallel storage nodes. Secondly,operations do not have universality. The operations to one speci?c multimedia format are not adopted for other formats.

Fixed-size policy has its own strong points.The operations to multimedia data are very easy be-cause every clip?le has no logical meaning and every unit?size of one clip?le is disk-sector-aligned.The operation has universality.It is not related to any speci?c multimedia format.But it also has some shortcomings.It is not adaptive for some speci?c VCR operations on multimedia data,such as SEEK.This type of operations will waste much time in a cluster video server because it should collect multimedia information and cal-culate time o?set,location o?set between many clip?les over di?erent nodes.

We propose a new multimedia data splitting scheme,called Owl.We de?ne a tracklayer beyond the actual multimedia data format layer.This scheme has following advantages.First,operations to multimedia data are very easy.At the tracklayer, the size of all data units is pseudo-equal,so the size of a clip?le is almost equal.Second,we can execute the SEEK type operations.Because every unit has logical meaning,it can be managed with real time protocols,such as RTP/RTCP.Third,it uses less runtime resource,as some runtime operations are performed at the pre-processing phase.A cluster video server reads multimedia data quickly and handles more requests.

2.2.Characteristics of media?les encoded based on time

It is very important to design a good data split-ting scheme with university for all media formats. The characteristics of media?les should be taken into consideration.

X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–9481

Any data that changes meaningfully with res-pect to time can be characterized as time-based media.Audio clips,MIDI sequences,movie clips, and animations are common forms of time-based media.Such media data can be obtained from a variety of sources,such as local or network?les, cameras,microphones,and live broadcasts.But when movie?les are stored on mediums,they are organized by some steady standards.MPEG-1 and AVI are two very important media formats in all popular formats,such as mov,rm and wsf. For all time-based media formats,some character-istics are the same in?le structures because the?les are composed of logical meaningful data units. Conclusions from MPEG-1and AVI?les can be extended on many other media formats.

According to MPEG-1and AVI standard,the multimedia stream?le structures with two streams are shown in Fig.2.In Fig.2,every PACK of MPEG-1?le is a logical unit of mixed multimedia data,including video and audio and other types of media data if possible.A PACK includes many packets of audio or video data.One video packet consists of many Group of Pictures(GOPs)and every GOP includes many frames.Di?erent PACKs with the same time o?set are often stacked with each other.And in AVI?le structure,every data chunk has the same function of PACK in MPEG-1.From the Fig.2,it is obvious that di?erent streams are parallel in time line but interleaved in storage space. For the convenience of analyses in the following sections,data chunk is also called PACK.

Therefore,we have following conclusions.First, di?erent types of streams are parallel in time line. Second,a PACK data unit is a decoding unit(at least,the video frame is less than PACK).It has complete logic meaning and?xed size for general ?xed-GOP MPEG-1encoding and AVI formats. Third,the basic information of a PACK can be ob-tained from the pack header.2.3.Cluster video server:distributed storage and delivery

In the previous works,we have designed a novel cluster video server.The system architecture of our cluster video server is illustrated in Fig.2.The video server system consists of three layers.A virtual server,a single entry point,is located on layer1,the top layer.There are one or several RTSP[8]servers on the second layer.All RTP servers,also called‘‘intelligent’’network attached disks[13]or data nodes and data servers,are located on the third layer.

The basic function of the virtual server,which is the only entry-point of the system,is to accept the client requests from viewing clients and resend them to one of RTSP servers.The virtual server can be a pc machine,a workstation server or an intelligent switch.If the virtual server is a compu-ter system,all components of the VOD system are in one network domain.Otherwise,if the virtual server is an intelligent switch,the components of the system can be in di?erent network domain, such as in a peer-to-peer environment.

When the RTSP server accepts a client?s re-quest,it?rst processes the authentication accord-ing to the resource utilization.If passed,the request will be broadcasted to the attached RTP servers with disks,which will be scheduled accord-ing to their own task scheduler.The RTSP server collects the scheduling results and makes a com-prehensive decision,and then it returns the admis-sion control results to the clients,and requests the storage nodes to arrange their playing tasks.

When the request is passed,the RTSP server will accept the RTSP commands and send them to RTP servers,which will receive and execute them.According to the RTSP request types,the RTSP server will execute the‘‘describe’’,‘‘setup’’, and translate the‘‘play’’into‘‘sub-play’’task list

82X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–94

according to clip ?les information of one movie,then indicate these ‘‘disks’’to start a RTP client thread and process media data in turn.The RTSP server has knowledge on the basic information of the requested media ?le.

Based on the above discussion,we have follow-ing conclusions.First,the basic information about the ?lm and the splitting information should be performed at the RTSP server.Secondly,every cli-ent request should have its estimated resource available,such as network bandwidth.This infor-mation is for a RTSP server to negotiate for the re-quest authentication.

3.Overview of cluster video server storage system The cluster video server storage system is based on user-level and what we will talk about does not involve the physical data layout on disks.We try to provide a high performance storage system,which can express the characteristics of our dis-tributed cluster video server fully:scalability and ‘‘intelligent’’network attached storage.In the fu-ture work,we will study disks scheduling policies and bu?ering schemes to optimize our system.Based on our cluster video server architecture,a distributed storage scheme to store large amount of continuous media data among all attached disks of clusters is proposed.In this paper,we call attached disks as storage nodes,data nodes or

RTP servers.Fig.4is our cluster video server stor-age system architecture.In our storage system there are two types of nodes.One is to store index ?les,such as Index server.Another kind of nodes is called storage ones,which are used to store structured clip ?les according to the scheme Owl ,such as node M,node N and node P in Fig.4.From Fig.4,we know well the architecture of our storage system.Here Index server includes some important video server system ?les to create and control playback tasks.We can divide the information of these system ?les into two parts:one is to provide movie ?s basic information to cli-ents ?requests,such as the stream number,the time length and the media format;the other is to decom-pose one client ?s request into many internal clips playback tasks.These important system ?les will be described in detail in the following sections.Note that the Fig.4is conceptual and functional.In real environments,Index server also can be in the same node with the RTSP server.From Fig.4,we can ?nd out that every storage node is work-ing in parallel mode.That is,all media data streams from all storage nodes are self-governed fully at some time and they are ?owing directly to clients.Another very important characteristic is that the internal details are transparent to clients.

To design the storage system well,there are two important issues:how to split a media ?le and how to strip clips onto distributed storage nodes.Consid-ering the data splitting scheme,several

problems

Fig.3.Architecture of one cluster video server.

X.Liao,H.Jin /Journal of Systems Architecture 51(2005)79–9483

should be discussed.At?rst,every clip?le has its own special structure and all clips of one movie must be scheduled according to some index?les prede?ned.Second,the length of one clip?le must be con?rmed.Clips striping schemes are also important.In the following sections,the data split-ting scheme and the clips striping scheme will be discussed in detail.

4.Owl:multimedia data splitting scheme

In this section,some de?nitions and concepts will be discussed at?rst;then the Owl scheme[6] will be proposed in detail.

4.1.Basic idea of Owl scheme

The goals of our novel media?le splitting scheme Owl are:no information loss,ease and operability,universality,and high e?ciency.In the scheme Owl,a new layer will be added to the normal media?les.All operations of Owl do work only in the new layer and the old encoded media data do not be changed.For this reason,the Owl scheme is independent of any media format and can works well for all time-based media?les.

In the new added layer,every decoding unit, like PACK in MPEG-1?les or data chunk in AVI?les,will be reorganized into packets accord-ing to the RTP protocol.And all these packets will be arranged into clips.Fig.5shows the basic idea of Owl.In the Fig.5,the added layer,named Tracklayer,is on the top the normal coding layer, such as MPEG-1,MPEG-4and AVI media encod-ing layer.The bottom of the architecture is the physical data on the disks.

4.2.De?nitions and concepts

There are some de?nitions and concepts in the sub-section,which will be used in the following presentations.

Track:the newly added layer,which includes many media data units like PACK in Fig.1.The decoder at client side decodes the media data according to the track type,such as MPEG-1sys-tem track,MPEG-2program track and RM(Real Media)track.

SDP File:the session description protocol (SDP)[18]?le.It is used for RTSP request‘‘de-scribe’’.The?le records the basic information of a?le,such as time length,track numbers,and

84X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–94

track type.SDF?le is stored on the RTSP server. Fig.6gives a typical SDP sample.

File Header:this structure is located at the beginning of every clip?le.In this part,informa-tion about this clip?le,such as track number, max-bandwidth and duration the clip?le,is re-

corded.Fig.6also gives the?le header structure.

Index File:the?le describes the splitting infor-mation of a?lm,such as the clip numbers,clip size,every clip?s time scope and all storage node numbers.It is used by front-end machine to con-trol the distribution.This important data structure is showed in Fig.7.

Mixed Block:it is accepted by the processing of a media-decoding unit,such as PACK in MPEG-1 or data chunk in AVI in Fig.2.In general,one mixed block consists of several RTP packets with logical meaning.It is the elementary unit transmit-ting over networks.RTP packets in one mixed block have the same timestamp and consecutive sequence numbers,for stream data of these RTP packets belong to the same one media-decoding unit,for example a PACK.One tracklayer consists of many mixed blocks.Fig.8shows a typical mixed block.From the?gure,we?nd out that there are some RTP packets,which have the same time stamp,but consecutive sequence numbers,in one mixed block.Specially,the word SSRC in Fig. 8means the synchronization source identi?er. When multiple streams are transmitting on net-work with the same SSRC value,these streams be-long to one movie?le.

Media Data Bu?ering Times:this is the times that a media data bu?ered from disks bu?er to the NIC bu?er.For example,a block is read from a disk,and saved in a memory bu?er,then sent through a network.In this instance,the block is bu?ered once.

Media Serving Time:this is the time for a cer-tain size of media data block read from disk and sent to a network.Normally,this size is the size of a data packet.

Movie Playing Path:the playing back of a movie is in fact a sequence of object operations: the?rst object retrieves and transmits its data, then it tells the next object to transmit next seg-ment,until all the objects?nished their tasks,like a group of member working in relay through the linked object lists.We call the sequence of objects participating in the playing back course a‘‘Movie Playing Path’’.

Pre-allocated Bandwidth:this is an estimated value calculated from the basic information of a media?le.It is used for the RTP server to?nish stream management and assignment,and adjust the bandwidth utilization for some stream.

4.3.Procedures of Owl scheme

Owl scheme consists of two phases.First,we analyze the basic information of a movie?le and generate a middle?le based on the original movie with added tracklayer.Then this middle?le is split into several clip?les according to users?requests, including the number of clips and the time length of every clip.The middle movie?le is the key of

X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–9485

the splitting scheme and it comprises all structured mixed blocks.

In the?rst phase,we get the information of original movie?le.According to Fig.5,a three-layer coding architecture for a normal media?le is presented.Traditionally,media data are read from the bottom layer and operated on the third layer.The video server must know well the detail of all media formats it supports.Since the media formats on the second layer are di?erent,the opera-tions are di?erent.For example,the operations of reading a video frame from a MPEG-1?le and from an AVI?le have very big distinctions.Owl scheme provides a new layer:Tracklayer,at which any media format is transparent to the upper application.The only identi?er of this speci?c media format is Track type code.For example, we assign the MPEG-1system stream‘‘MP1S’’, the MPEG-2system?le‘‘MP2S’’,and an AVI?le

‘‘AVI’’.The Track type code is very important for clients to select an appropriate decoder.The?le interface module of a VoD server does not take care of the media formats and all source codes can be reused for all media formats due to its uni-versality.We also provide a media?le splitting tool to deal with each media format.

Fig.9illustrates the architecture of track?le structure.The tracklayer consists of many mixed blocks.Each mixed block is an independent data unit.It is divided into several data packets accord-ing to the size of a RTP packet payload de?ned in advance.The mixed block is pseudo-?xed in size because that a PACK in MPEG-1or a data chunk in AVI is equal in size.All mixed blocks of one tracklayer are organized by time sequence.Fig. 10is the comparison between the original movie ?le structure and the middle?le structure with one tracklayer.The middle?le only has extra ‘‘Track Header’’and‘‘File Header’’in size.Note that the middle?le has only one tracklayer in this graph.The?gure is only an example to display the di?erence between original movie?les and middle ?les.It is possible that there will be many tracklay-ers in one movie.For example,middle?les based on MPEG-4have three tracklayers:video,audio, caption.

The second phase?s tasks are to divide the middle ?les into clips and to generate the SDP?les and Index?les.According to Section3,there must be a SDP?le and Index?le at RTSP server for cluster video servers.SDP?les store information needed by the clients,and Index?les are for distributed control on RTSP server nodes.SDP and Index?les are cre-ated with information from the original movie?le. Fig.11gives a snapshot for the distributed control and scheduling of clip?les for cluster video server.

The middle?les with added track are divided into clip?les for the cluster video server according to users?requests.When users have no idea of the dividing of middle?les,the scheme of Owl will pre-sent a proposal of how to cutting middle?les into clips.According to intra-movie skewness[23],it is advisable to split media?les into clips with the

86X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–94

characteristic time length.In[23],authors claim that the intra-movie skewness is caused by the fact that people have di?erent viewing time and they have the following conclusion:some people do not view movies all the way through to completion and most of them stop watching at the beginning. This tendency leads to the large gap between the access number of head segments and that of oth-ers.It is obvious that the one movie?s head parts, whose access ratios are?uctuating in the same lit-tle range,should be cut into one clip and other parts can be divided into clips according to an average time length.Each clip?le has its own structure,showed in Fig.12.From this Fig.12, the sample clip?le has two tracks,the MPEG-1 system stream and AVI stream.

4.4.An example of Owl scheme

At the end of this section,we give an example of Owl scheme.Given a MPEG-1movie?le eagle, which is233.4MB,25fps,and1380s long.It is a system stream?le.All experiments are based on the movie eagle in this paper.The cluster has one RTSP server and two data nodes as storage nodes. The movie,eagle,is cut into four clips.In the video server,there are four clip?les,one Index?le and one SDP?le.One index?le is illustrated in Fig.

13.In Fig.3,the word‘‘EndP’’means the last RTP packet number and the word‘‘StartP’’means the?rst RTP packet number.

Fig.14gives a comparison of this middle movie ?le added tracklayer and four clip?les.Based on the structure of a clip?le,we can pre-allocate bandwidth according to the information of the clip ?le header for stream management and bandwidth adjustment.

5.Clip striping schemes

Without a good clip striping strategy,the movie data splitting scheme is no use for clustered video servers.The advantage of Owl scheme should be

X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–9487

exhibited by clip placement techniques.Another problem of distributed video servers is fault toler-ance.If some storage nodes failed,many movie playing path s will crash and normal playback re-quests are cut down.There is a great loss if the failed video servers are used for commercial aims.Researchers have done considerable work about the data striping schemes taking into ac-count both the normal and fault modes.Most of them evolve from RAID techniques,but have been improved in various aspects such as read/write la-tency,bu?er management,and the number of simultaneous failures that can be tolerated.

One normal scheme is mirrored data placement.For high data availability,many projects have adopted the technique.The scheme mirrored all data blocks interleaved among all data nodes.It divided the data nodes into two sets.One set is used to store original data blocks called primary set;the other is as a backup device to store the same data blocks as those on primary set.Fig.15describes the idea.

From Fig.15,we can ?nd out that node M[i ]is the backup of node N[i ].If there is a Movie Play-ing Path N[1]!N[2]!N[3]and node N[2]failed,a new Movie Playing Path will be created:N[1]!M[2]!N[3].Node M[2]will take over all tasks of node N[2].For video-on-demand applications,if the load is simply shifted to the node that contains a backup copy during the node failure,the load on the backup node will be doubled.

Another widely used scheme is called chained placement [17],as shown in Fig.16.For a random access pattern,this scheme can achieve better per-formance in the fault mode than straightforward mirrored-placement.However,without dynamic load balancing,chained placement probably still su?ers load imbalance due to the fact that the load

of the failed node is now completely shifted to its adjacent two nodes.

Interleaved placement [2]is a method to achieve load balancing in the fault mode.With interleaved placement,each backup copy is subdivided into sub-blocks each of which is stored on a di?erent node except the one containing the primary copy.When a node failure occurs,interleaved placement is able to do a better job of balancing the load than mirrored placement and chained placement,since the workload of the failed node will be distributed among operational nodes.However,it can only tolerate one node failure and may su?er great per-formance degradation due to small block size when the number of nodes is large.

There are several kinds of random placement policies,such as semi-random placement and full-random placement.However,random place-ment only provide probabilistic guarantee of load balancing and cannot tolerate multiple failures.And,it has the drawback of maintaining a huge video index of the striping data blocks in practice.According to above analysis on clip striping polices,we choose chained placement scheme in our cluster video server.This scheme is easier to use than interleaved placement and random place-ment,and its performance is better than that of mirrored placement.In the next sub-section,we will study the impact of the clip ?s length on video systems based on chained striping policy.

6.Task scheduling of distributed storage systems in cluster video servers

Tasks scheduling in Owl focuses on distributed control for attached ‘‘disks’’under the RTSP

ser-

Fig.15.Mirrored placement

scheme.

Fig.16.Chained placement scheme.

88X.Liao,H.Jin /Journal of Systems Architecture 51(2005)79–94

ver.As Fig.11shows,SDP and Index?les are lo-cated on the RTSP server and clip?les are distrib-uted on all intelligent‘‘disks’’.From Section2,one RTSP server is initialized and many RTP servers on‘‘disks’’nodes.

According to the chained placement scheme,we arrange three movies,A,B and C,onto four stor-age nodes,M,N,P and Q.Table1shows the stor-age status of three movies on four storage nodes with the replica degree two.When RTSP server re-ceives a request command‘‘describe’’for movie A, it?rst makes a decision about admission control according to the resource utilization,such as net-work bandwidth assumption.If admitted,RTSP server reads SDP information from local disks and sends it to clients.Then,the RTSP server cre-ates a stream session with requesting client.At last,if the client sends‘‘play’’,RTSP server re-serves the command and creates a Movie Playing Path,showed in Fig.17,according to the index?le of movie A.The path has three object operations, one is‘‘playing the?rst clip from node M’’,the second one is‘‘playing the second clip from node N’’,the third one is‘‘playing the third clip from node Q’’and the last one is‘‘playing the last clip from node Q’’.

As a result,the RTSP server executes the?rst operation of the path.Then the RTP server on node M starts up a new sub-task.It reads packets from its clip?le and sends packets to clients di-rectly;of course,it should control the streaming speed and adjust the picture quality by CBR or VBR.Node M should send checkpoint packets to the RTSP server timely,such as current clip?le position,current time position,current RTP sta-tus,and current average bandwidth utilization. The information is used for VoD status controlling and callback in case of node faults.When node M reports to the RTSP server that its clip?le is played over,the RTSP server sends a Fin signal to the RTP server of node M and this node will clear the?nished clip?le?s playing thread.Then the RTSP server will execute the left operations of its Movie Playing Path of movie A as it does the?rst operation on node M.

When all operations of one path have been?n-ished,the RTSP server clears all threads memory space for this movie.Meanwhile,many other paths are being scheduled.

7.Evaluations and design optimizations of Owl scheme

In this section,we?rst evaluate Owl splitting scheme with aspect to disk space,memory space and CPU running time[14];in the last sub-section, some discussions will be provided to make design optimizations of Owl.

7.1.Cost of disk space

Owl scheme occupies more disk space compared with original?le structure.We cut movie eagle into

Table1

Four clips of movie eagle on four storage nodes with replica degree two

Node name Node IP Clip number

Node M192.168.0.1A#1,A#4,B#4,B#3,C#3,C#2

Node N192.168.0.2A#2,A#1,B#1,B#4,C#4,C#3

Node P192.168.0.4A#3,A#2,B#2,B#1,C#1,C#4

Node Q192.168.0.10A#4,A#3,B#3,B#2,C#2,

C#1 Fig.17.A movie playing path for movie A.

X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–9489

10clips,with total size of ten clip?les almost 241.8MB.SDP?le is654Bytes.Index?le is924

Bytes.We need almost8.4MB extra disk space to use Owl scheme,which is3.6%of original?le space.

Considering a120min long movie(MPE G-1), the size of the movie?le is600MB.According to the above ratio,only21MB extra space is needed to use Owl scheme.For a cluster video server sys-tem,this extra space is acceptable.

7.2.Cost of memory space

Owl scheme saves precious memory space.We discuss this issue by counting media data bu?ering times.Fig.18shows the VoD serving times for tra-ditional schemes and our Owl scheme.

In Fig.18,we?nd that Owl scheme saves one-third of memory space from the viewpoint of media data bu?ering times.The reason is that when splitting?les into clips we have done the work of analyzing media format.Considering that memory is the important resource for a VoD system,we can easily get a conclusion that Owl scheme has better performance than traditional ones.

7.3.Cost of CPU running time

Owl scheme also saves CPU running time.Its media serving time is less than that of other schemes.We perform the following experiment to illustrate the performance.

We use the same movie?le eagle described in Section7.1.The size of a data packet is1450Bytes. Bu?er size is three times of a data packet size.The cluster nodes are PIII800with128MB memory.The traditional scheme used for comparison is var-iable-size one.The time used for distributed control is ignored for both schemes.The testing program for traditional scheme only gets data packets from original?le and discards.The test program for Owl scheme reads data packets from one clip?le and discards.Both tests use10data packets each.

Fig.19shows the results for both tests.The media serving time for the?rst ten data packets is0.75ms and0.14ms for variable-size scheme and Owl one,respectively.The media serving time for100th10data packets is0.47ms,0.10ms for variable-size scheme and Owl scheme,respectively.

In Fig.19,we?nd that the media serving time of Owl scheme is less than that of traditional schemes.This is due to the fact that most work focuses on analyzing media data in using Owl scheme has been done before serving requests.

From all these discussions,we conclude that Owl scheme is a trade-o?between disk space and memory space,and also a trade-o?between pre-processing time and serving time.The aim of Owl scheme is to reduce the runtime resource requirement,to improve e?ciency,and to handle more user requests.Most of the work is done dur-ing the period of splitting?les into clips to reduce the load of serving time.

7.4.Clip length analysis

Based on our cluster video server,we perform several tests to?nd out the relationship between clip length and system performance.

Fig.19.Media serving time. 90X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–94

We test the request-success ratio and the num-ber of concurrent streams.Request-success ratio is de?ned as the ratio of accepted requests to all the client requests issued.Given a request arrival rate,this metric re?ects the service capability of the server system.And concurrent stream number re?ects the peak performance of the system while guaranteeing the quality of service.

In these tests,we use a cluster with one RTSP server and eight storage nodes.The cluster nodes are PIII800with128MB memory.In these data nodes,we have stored100movies,which all are 120min long and have been divided into many clips with di?erent clip length using Owl scheme. According to Section5,these clip?les are stored in chained placement scheme.

Due to limited clients to send requests in our test environments,we design a pseudo-client player.The pseudo-client player sends out requests according to RTSP protocol,receive media data as RTP protocol does,but discards them after re-organizing all RTP packets into decodable data units.That is to say,the pseudo-client player simu-lates many requests and every request does what a normal client player does expect the decoding and displaying operations.In our experiment,we have ?ve client PCs,which are all the same as cluster nodes.

We make several assumptions.First,the clients requests arrive as a steady Poisson stream,and the arrival rate is and k we set it0.045;second,clients?movie selection pattern is conform to Zipf distri-bution(a=1)[22].

We perform nine experiments with nine clip lengths.The?rst step of each experiment is to split all movies into clips by using Owl scheme accord-ing to the corresponding clip size.Second,all clip ?les are stored on all data nodes according to chained placement policy.All index and SDP?les are stored on Index servers.Pseudo-client players of every Client PC start up with simulative client player number.We assume the number200.There are1000movie requests in each experiment.

Fig.20reveals the relationship between clip length and request-success ratio.Fig.21shows dif-ferent concurrent stream number when clip sizes are di?erent.From them,we can see the length of clip has only slight in?uence to the system per-formance.This result is probably due to our assumption that the pseudo-client requests arrive as a steady Poisson stream,which is one important characteristic that the numbers of request appear-ing in two di?erent time ranges are independent random variables.A single long clip has the same e?ect as a group of short clips in assigning the playing task,though they occupy di?erent periods of playing time in the time axis of one movie. 8.Related works

In[26],the authors proposed the problem of storing media data on disk arrays and found

that Fig.20.Relationships between success ratio and clip

length.

Fig.21.Relationships between concurrent streams number and clip length.

X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–9491

most multimedia applications cannot support the continuous display of multimedia objects and suf-fer from low I/O bandwidth and load balancing between many disks.The storage scheme is very important in these systems about multimedia. With the development of multimedia applications and hardware platforms,we should focus on the media storage system,from splitting media?les into many clips to storing many clips on a large disk array.

In[20],authors analyzed?xed-size clip place-ment policy and variable-size clip placement policy;and gave the conclusion that the later is better than the former in a VoD server.But there are some problems in its consideration.The authors put their emphasis on disk space management.In fact we have to consider the VCR operations in distributed environment.Variable-size clip place-ment policy makes the VCR operations complex and the policy module cannot be reused for every media format.It is not universal.

In[19],to determine the?xed clip size,the authors presented analytical models that use the server con?guration and the workload character-istics to predict the load on the most heavily loaded disk in redundant and non-redundant ar-rays.They used these models to evaluate the e?ect of various system parameters on the optimal clip size.

In[4],the authors described the architecture of Fellini storage system implemented at Bell Labora-tories.This system can store continuous media (CM)data and non-media data.CM data has real-time characteristic but non-media data was not real-time.We should also extend our scheme to be adaptive for non-media data.

Lee provided a system design of pull-based par-allel video server[14]and derived a performance model to obtain various performance metrics such as server service delay,client bu?er requirement and admission scheduling delay.In their parallel architecture,the movie segments were ordered in a round robin manner to avoid the load imbalance problem caused by inter-movie skewness.How-ever,they did not provide an e?ective and e?cient data-splitting scheme to solve the intra-movie skewness problem[24].

Clip?les size is associated with parallel granu-larity and is a very important parameter.In[10], Lee provided a very thin granularity parallel scheduling scheme.But Owl scheme is coarse gran-ularity parallel streaming.In Owl scheme,parallel streaming happens between clips of di?erent mov-ies,not clips of the same movie.The most impor-tant reason is that Owl scheme is used for Ethernet environment only.In thin granularity parallel scheme,clip?le can even be one video frame. But this needs very strict coordination between many data nodes,but coordination is very di?cult in Ethernet environment.

Track has been used in many?elds,such as in QuickTime movie format[25],MBoneVCR[27] system,and even in MPEG-4format.In Owl scheme,this concept makes full use of traditional meanings of Track.Track is used as a container for every possible media data.For every client with di?erent network bandwidth,there are sev-eral Tracks for one movie.For example,Track of average bandwidth200KB per second and Track of average bandwidth1MB per second can co-exist for the same media data.But there are some di?erences.First,in Owl scheme it encap-sulates the media data into network packets list. Second,Track of the Owl scheme is helpful for dis-tributed video servers.There are the same Track data links in all clips for a movie,while traditional Track does not consider these.

9.Conclusions and future work

In this paper,we present a new distributed stor-age scheme for cluster video servers.In the new scheme,one multimedia data splitting scheme, called Owl,and a clip striping policy are proposed. Compared with traditional data splitting schemes,?xed-size clip placement policy and variable-size clip placement policy,Owl scheme has been proven to have some superiority.Owl scheme ab-sorbs excellence of two traditional schemes,?xed size and logical meaning,universality and high e?ciency.

Owl scheme proposed in this paper works well for the multimedia application such as non-inter-

92X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–94

active VoD tra?c,but not suitable for interactive tra?c such as video editing.For further study, we will try our best to propose an on-line movie data-splitting scheme to be used for interactive vi-deo tra?c.We will also study the impact of net-work transmission,VBR,and client?s decoding e?ciency of Owl scheme.

References

[1]A.Shankar,G.Meglicki,J.Russ,H.Yang, E.Chris

Garrison,Building and supporting a massive data infra-structure for the masses,in:Proceedings of the30th annual ACM SIGUCCS conference on User services,2002. [2]A.Cohen,W.A.Burkhard,Segmented information dis-

persal(SID)data layouts for digital video servers,IEEE Transactions on Knowledge and Data Engineering13(4) (2001).

[3]C.A.Thekkath,T.Mann,E.K.Lee,Frangipani:A scalable

distributed?le system,in:Proceedings of ACM Sympo-sium on Operating System Principles,1997.

[4]C.Martin,P.S.Narayan, B.Ozden,R.Rastogi, A.

Silberschatz,The Fellini multimedia storage system,Jour-nal of Digital Libraries(1997).

[5]G.Tan,H.Jin,S.Wu,Clustered multimedia servers:

architectures and storage systems,Annual Review for Scalable Computing5(2003).

[6]H.Jin,X.Liao,Owl:a new multimedia data splitting

scheme for cluster video server,in:Proceeding of Euro-micro Conference,2002,pp.144–151.

[7]H.Schulzrinne,S.Casner,R.Frederick,V.Jacobson,

RTP:A Transport Protocol for Real-Time Applications, RFC,1889.

[8]H.Schulzrinne,A.Rao,https://www.360docs.net/doc/5417112202.html,nphier,RTSP:Real Time

Streaming Protocol,RFC2326.

[9]J.Yin,J.-P.Martin, A.Venkataramani,L.Alvisi,M.

Dahlin,Separating agreement from execution for byzan-tine fault tolerant services,in:Proceedings of the nine-teenth ACM symposium on Operating systems principles, 2003.

[10]J.Y.B.Lee,Supporting server-level fault tolerance in

concurrent-push-based parallel video servers,IEEE Trans-actions on Circuits and Systems for Video Technology11

(1)(2001).

[11]J.Segarra,V.Cholvi,Placement of storage capacity in

distributed video servers,in:Proceedings of IEEE Inter-national Conference on Communications,vol.4,2002,pp.

2537–2541.

[12]J.Y.B.Lee,Parallel video servers:a tutorial,IEEE Multi-

media5(2)(1998).

[13]J.Y.B.Lee,P.C.Wong,A server array approach for video-

on-demand service on local area networks,in:Proceedings IEEE INFOCOM?96,March1996.[14]J.Y.B.Lee,P.C.Wong,Performance analysis of a pull-

based parallel video server,IEEE Transactions on Parallel and Distributed Systems11(December)(2000)1217–1231.

[15]https://www.360docs.net/doc/5417112202.html,uderdale,D.H.K Tsang,A new technique for trans-

mission of pre-encode MPEG VBR video using CBR service,in:Proceedings of IEEE ICC96,1996,pp.1416–1420.

[16]K.Hwang,H.Jin,R.S.C.Ho,Orthogonal striping and

mirroring in distributed RAID for I/O-centric cluster computing,IEEE Transactions on Parallel and Distributed Systems13(1)(2002).

[17]L.Golubchik,J.C.Lui,R.R.Muntz,Chained declustering:

load balancing and robustness to skew and failures,in: Proceedings of the Second International Workshop on Research Issues in Data Engineering:Transaction and Query Processing,1992,pp.88–95.

[18]M.Handley,V.Jacobson,Session Description Protocol

(SDP),RFC2327.

[19]P.Shenoy,H.M.Vin,E?cient striping techniques for

multimedia?le servers,in:Proceedings of the7th Interna-tional Workshop on Network and Operating System Support for Digital Audio and Video(NOSSDAV?97), 1997,pp.25–36.

[20]P.Shenoy,P.Goyal,H.M.Vin,Issues in multimedia server

design,ACM Computing Surveys27(4)(1995)636–639.

[21]R.Haskin,F.Schmuck,The tiger shark?le system,in:

Proceedings of COMPCON,1996.

[22]R.L.Axtell,Zipf distribution of US?rm sizes,Science293

(2001).

[23]S.Wu,H.Jin,Study of load balancing issues based on

intra-movie skewness for parallel video servers,in:Pro-ceedings of International Symposium on Cluster Comput-ing and the Grid,2002,pp.268–269.

[24]S.Sahu,Z.L.Zhang,J.Kurose, D.Towlsey,On the

e?cient retrieval of VBR video in a multimedia server,in: Proceedings of IEEE International Conference on Multi-media Computing and Systems?97,1997.

[25]The QuickTime Technical Reference Library,QuickTime

File Format,March27,2001.

[26]T.E.Anderson,M.D.Dahlin,J.M.Neefe,D.A.Patterson,

D.S.Roselli,R.Y.Wang,Serverless network?le systems,

ACM Transactions on Computer Systems(1996).

[27]W.Holfelder,MBone VCR video conference recording on

the Mbone,in:Proceedings of ACM Multimedia,

1995.

Xiaofei Liao now is a Ph.D.candidate

of school of computer science and

technology,Huazhong University of

Science and Technology(HUST),

Wuhan,China.His research interest

covers multimedia services,cluster and

grid computing,and peer-to-peer

computing.

X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–9493

Hai Jin is a professor of school of computer science and technology, Huazhong University of Science and Technology(HUST),Wuhan,China. He received Master and Ph.D.degrees at HUST in1991and1994,respec-tively.He was a Postdoc Fellow at Department of Electrical and Elec-tronic Engineering,The University of Hong Kong,and a visiting scholar at Department of Electrical Engineering-System,University of South California,Los Angeles,USA,from1998to2000.His research interests cover cluster computing,grid computing, multimedia systems,network storage,and network security.He is the editor of several international journals,such as Interna-tional Journal of Computers and Applications,International Journal of Grid and Utility Computing,Journal of Computer Science and Technology.He is now leading the largest grid Computing project in China,called ChinaGrid,funded by the Ministry of Education,China.

94X.Liao,H.Jin/Journal of Systems Architecture51(2005)79–94