CloudMedia: When Cloud on Demand Meets Video on Demand

Transcription

1 CloudMeda: When Cloud on Demand Meets Vdeo on Demand Yu Wu, Chuan Wu, Bo L, Xuanja Qu, Francs C.M. Lau Department of Computer Scence, The Unversty of Hong Kong, Emal: Department of Computer Scence and Engneerng, Hong Kong Unversty of Scence and Technology, Emal: Abstract Internet-based cloud computng s a new computng paradgm amng to provde agle and scalable resource access n a utlty-lke fashon. Other than beng an deal platform for computaton-ntensve tasks, clouds are beleved to be also sutable to support large-scale applcatons wth perods of flash crowds by provdng elastc amounts of bandwdth and other resources on the fly. The fundamental queston s how to confgure the cloud utlty to meet the hghly dynamc demands of such applcatons at a modest cost. In ths paper, we address ths practcal ssue wth sold theoretcal analyss and effcent algorthm desgn usng Vdeo on Demand (VoD as the example applcaton. Havng ntensve bandwdth and storage demands n real tme, VoD applcatons are purportedly deal canddates to be supported on a cloud platform, where the on-demand resource supply of the cloud meets the dynamc demands of the VoD applcatons. We ntroduce a queueng network based model to characterze the vewng behavors of users n a multchannel VoD applcaton, and derve the server capactes needed to support smooth playback n the channels for two popular streamng models: clent-server and P2P. We then propose a dynamc cloud resource provsonng algorthm whch, usng the derved capactes and nstantaneous network statstcs as nputs, can effectvely support VoD streamng wth low cloud utlzaton cost. Our analyss and algorthm desgn are verfed and extensvely evaluated usng large-scale experments under dynamc realstc settngs on a home-bult cloud platform. I. INTRODUCTION Cloud computng has recently emerged as a new computng paradgm for organzng a shared pool of servers n datacenters nto a cloud nfrastructure that can provde ondemand server utltes (CPU, storage, bandwdth, etc. to users anywhere anytme. To enable dfferent applcatons runnng on a cloud effcently, vrtualzaton s often appled, whch allows multple vrtual machnes (VMs to run on the same physcal server; ths form of sharng a physcal server allows resources to be rapdly provsoned and released wth mnmal management efforts and overheads. Resource provsonng s typcally based on Servce Level Agreements (SLAs between the cloud provder and the cloud consumer. Dfferent servce models of a cloud nfrastructure have been proposed ([], namely Software as a Servce (SaaS, Platform as a Servce (PaaS, and Infrastructure as a Servce (IaaS, among whch the IaaS model provdes the most flexblty where a consumer can deploy and run any software on ts allocated VMs. The research was supported n part by grants from RGC under the contracts 787E and 6568, and by a grant from Huawe Technologes Co. Ltd. under the contract HUAW8-5L8/PN. The elastc and on-demand nature of resource provsonng has made cloud computng very promsng n varous applcatons, ncludng many that are computaton-ntensve [2], [3] and applcatons wth hghly dynamc server resource demands [4]. In partcular, dynamc resource provsonng va a cloud s best suted for Internet-based applcatons (e.g. YouTube that have to handle frequent surges of user requests. Real-lfe cloud mplementatons have demonstrated that cloud nfrastructures ndeed have substantal advantages over prvate server clusters or CDNs n terms of system scalablty, and they can lead to sgnfcant reducton n operatonal costs wth respect to machnes, bandwdth, and management. Our work focuses on Internet-based applcatons that are to be supported by cloud nfrastructures. Lttle effort so far has been devoted to understandng and explorng how these Internet-based applcatons can fully explot a cloud nfrastructure. One fundamental queston s how to quantfy dynamc user demands, or more precsely, how should an applcaton provder learn the dynamc demands from users and relay them to the cloud servce accordngly? Our work as presented n ths paper makes the frst attempt to address ths problem. Specfcally, our soluton answers the queston of how an applcaton provder can most effectvely confgure the cloud utlty to acheve the best applcaton performance at a reduced cost. We choose Vdeo on Demand (VoD as the representatve applcaton n ths study. Wth ntensve and dynamc bandwdth/storage demands n real tme, VoD applcatons present a sgnfcant challenge to resource provsonng n servce offerng. Although many popular VoD servces (e.g., PPLve, UUSee have leveraged peerto-peer (P2P technology for cost reducton, exstng studes showed that dedcated servers are stll caterng for 4 7% of overall streamng bandwdth demand n these systems [5], [6]. The cloud nfrastructure as an alternatve to dedcated servers sets out to meet the challenge by dynamcally composng and optmzng the needed servces at reduced costs. Our contrbutons n ths study are as follows. Frst, we nvestgate by sold theoretcal analyss the equlbrum demand for streamng server capacty n a VoD applcaton wth multple vdeo channels. We ntroduce a new queueng network model to characterze the dynamc vewng behavors of VoD users, and derve the server capacty needed to support smooth playback n the channels. Both clent-server VoD and P2P VoD are nvestgated, whch are the two most

2 representatve mplementatons of VoD applcatons n today s Internet. Second, by followng practcal cloud chargng models, we formulate two optmzaton problems for cloud provsonng, ncludng VM provsonng and storage rental, n a cloud nfrastructure. We propose a practcal algorthm, whch can dynamcally confgure cloud resources to address the contnuous demands for streamng dfferent chunks and vdeos over tme. Wth ths algorthm and usng nstantaneous network statstcs as nputs, a VoD applcaton provder perodcally derves the requred server resources by approxmately solvng the two optmzaton problems usng effcent heurstcs, and communcates the results to the cloud provder usng SLAs. Thrd, based on a VoD prototype runnng on a cloud platform (called CloudMeda we have bult and mplemented usng a cluster of machnes, we carry out verfcaton of our analyss and extensve evaluaton of our algorthm desgn n a dynamc and realstc envronment. The results show that hgh-performance mult-channel VoD streamng can be mplemented wth low cloud (server costs usng our algorthm, and that by engagng a cloud n leu of dedcated servers, a P2P VoD applcaton can readly enjoy the benefts of further reduced costs and mproved scalablty. The remander of ths paper s organzed as follows. We dscuss related work n Sec. II. In Sec. III, we present the model of the cloud nfrastructure, as well as that of the mult-channel VoD applcaton. We ntroduce a new Jackson queueng network model and derve server capacty demand n the VoD system n Sec. IV. We formulate the cloud VM provsonng and storage rental optmzaton problems, and propose a practcal dynamc cloud provsonng algorthm n Sec. V. Sec. VI presents our extensve expermental evaluatons under realstc settngs. Fnally, we conclude the paper n Sec. VII. II. RELATED WORK Recently there s an upsurge of nterest n the research communty n ssues arsng from runnng computaton-ntensve and data-ntensve applcatons on clouds [3][7][8][9][][]. Many of these applcatons can now be satsfactorly supported by commercal cloud servces [2][3]. Researchers however have focused manly on how a cloud nfrastructure can provde for the qualty of servce (QoS as requred by the applcaton and based on the SLA negotated [7][8], and how user prvacy and content confdentalty can be protected when a user entrusts a cloud wth a task [9][]. Our work devates from these popular topcs and focuses nstead on the ssue of cloud s utlzaton by large-scale Internet-based applcatons. Our study s from the vewpont of a cloud consumer,.e., an Internet applcaton provder n our case. It seems that no exstng work has ever addressed the challenges or proposed any approach from such an angle. There have been many theoretcal studes on performance modelng of P2P streamng applcatons, e.g., on maxmum sustanable streamng rate or smooth streamng probabltes n P2P lve streamng [4][5][6], and on start-up delay performance n P2P VoD streamng [7]. These work typcally assume a fxed server capacty n the analyss, and none has conducted ther study from the perspectve of equlbrum server capacty whch s needed to mantan a set level of user playback performance n dynamc VoD networks. Wu et.al [5] leverage Jackson queueng network wth nfnteserver queues to model the channel churns, whch mght not apply to real systems due to the mpractcal assumpton that server resources are unlmted. We are only aware of one study [8] whch dscusses the mnmum server bandwdth requred to support a fxed streamng rate n P2P lve streamng for set top boxes wthout any dynamcs. However, ther bounds are acheved va a tree-based algorthm and are most lkely not applcable to real-world VoD streamng servce. To the best of our knowledge, our study s the frst to put forward a Jackson queueng network model to derve the demand for server capacty n Internet-based P2P VoD streamng whch s much more challengng than lve streamng due to aggravated chunk avalablty ssues and user dynamcs. As for practcal server capacty provsonng, exstng studes ether focus on provsonng dedcated prvate servers by the applcaton provder [9][2], or schedulng server resources among multple applcatons nsde a cloud by a cloud provder []. In ths paper, we seek to desgn a resource provsonng framework from the vewpont of a cloud consumer. III. SYSTEM MODELS A. The Cloud Infrastructure The IaaS cloud system under our nvestgaton conssts of a collecton of nterconnected computng and storage servers. The servers are of two categores: NFS storage servers, organzed nto a number of NFS clusters by ther performance levels (e.g., storage capacty and I/O speeds, and computng servers whch support the runnng and provsonng of vrtual machnes (VMs. The VM nstances generally have dfferent confguraton levels n terms of CPU computng unts and I/O speeds. There are a number of vrtual clusters, each consstng of VMs of the same level of confguraton. Cloud applcatons run on the VMs and utlze the NFS storage system va the VMs. We assume each VM can access all the NFS clusters va hgh-speed Ethernet swtches and LAN buses. The cloud archtecture s llustrated n Fg., wth the followng man functonal modules: Broker s a communcatng nterface between the cloud provder and a cloud consumer, va whch the consumer can submt requests to the cloud. Request Montor lstens to the requests from the consumers (brokers, and forwards them to the SLA negotator. SLA Negotator negotates the Servce Level Agreements (SLAs wth the cloud consumers based on the prcng polcy and QoS levels set by the cloud provder. VM Scheduler s responsble for VM provsonng to meet the demands of the applcatons. VM Montor keeps track of all the VM nstances provsoned and montors ther actvtes and performance.

3 TABLE I NOTATION TABLE Fg.. The cloud model. NFS scheduler carres out content placement onto the NFS clusters. In ths cloud model, servces are charged by usage tme, followng the chargng model of leadng commercal cloud provders such as Amazon EC2 [2] and S3[3]. Two types of charges are leved on a cloud consumer, the rental fees of the VMs to run the applcaton and the storage cost to use the NFS clusters, both of whch are based on a per tme unt rate, wth dfferent VMs (NFS servers of dfferent confguraton levels requestng dfferent prces. B. The VoD Applcaton Model As a cloud consumer, the VoD applcaton possesses a large collecton of vdeos (each referred to as a vdeo channel. A user can jon any of the channels and watch any porton of a vdeo at any gven tme. Suppose the streamng playback rate of each channel s r bytes/s, and each vdeo stream s dvded nto consecutve chunks of sze rt bytes, correspondng to T seconds of the playback at rate r. The sze of the local playback buffer at each user s suffcent to cache any one vdeo n the system, and a chunk of a channel once downloaded wll reman avalable n the buffer untl the user leaves the channel. We study two models of VoD mplementaton n ths paper,.e., the clent-server model and the P2P paradgm. In the clent-server model, all users drectly obtan the chunks of ther desred vdeos from the streamng servers,.e., the cloud nfrastructure n our desgn. For the P2P VoD model, we assume a mesh-pull based P2P VoD desgn, where users watchng the same vdeo channel are organzed nto a mesh overlay, exchange vdeo chunks among themselves based on perodcally exchanged buffer avalablty btmaps, and resort to streamng servers only when deemed necessary. In stateof-the-art P2P VoD systems [2], streamng servers are stll largely ndspensable as they are the only persstent sources of all orgnal vdeos and needed from tme to tme to compensate for nsuffcent upload bandwdth of some peers. In our desgn, such streamng server servce wll be mplemented by the cloud servce. Symbol r R T J Q s m P j Λ λ Defnton The streamng playback rate of each vdeo channel The allocated bandwdth of each VM The playback tme of a vdeo chunk Number of chunks that channel c s dvded nto The -th queue n channel c The upload bandwdth to serve chunk n channel c The number of (queueng theoretcal servers n queue Q The capacty provsoned from the cloud for chunk n channel c The probablty that users n Q swtch to Q j The external arrval rate to channel c The aggregate arrval rate to Q n channel c µ The servce rate of each server n a multple-servers queue α The fracton of peers who enter the frst chunk queue upon jonng a channel p (k The probablty that Q has k peers. n ν ν j Γ The number of peers n Q The total number of chunk of channel c n the P2P overlay (equvalently the number of peers n the overlay who own chunk The number of peers n Q j who own chunk The capacty contrbuted to upload chunk n channel c from the P2P overlay C. Interplay between Cloud and VoD Applcaton As a cloud consumer, the VoD applcaton provder places the vdeo contents onto the NFS clusters and deploys the VoD server applcaton onto the VMs, elmnatng the need for tradtonal streamng servers. To support such a content dstrbuton applcaton, each VM n the cloud s assumed to be assgned a guaranteed amount of bandwdth based on QoS provsonng; the bandwdth provsoned to each VM s R, whch s the same for all VMs and satsfes R>r, wthout loss of generalty. Over tme, the VoD applcaton provder requests dfferent numbers of VMs and dfferent amounts of storage capacty from the cloud va the broker. The requests are based on the current demand from the VoD users, as well as the operatonal budget and the SLA wth the cloud provder. The cloud processes the requests receved va the request montor and adjusts VM and NFS storage allocatons va the VM and NFS schedulers. Our objectve n ths paper s to study how a VoD applcaton provder can metculously confgure ts usage of the cloud nfrastructure to acheve the best performance of the applcaton wth a modest cost over tme. Issues regardng the mplementaton of the functon modules and the QoS provsonng (e.g., allocatng bandwdths to the VMs n the cloud nfrastructure represent orthogonal research problems, whch are out of the scope of the current paper. We summarze mportant notatons used n the paper n Table I for ease of reference. We refer to the VoD system usng the cloud nfrastructure to mplement streamng servers as CloudMeda herenafter. IV. SERVER CAPACITY DEMAND ANALYSIS: A QUEUEING NETWORK APPROACH We frst study the equlbrum demand for streamng server capacty n a VoD applcaton n both the clent-server and the

4 P2P mode, the results of whch can translate nto gudelnes for the VoD provder to confgure ts cloud usage. A. Queueng Network Modelng We ntroduce a Jackson queueng network based model to characterze the vewng behavors of VoD users nsde each channel n the VoD system. The model facltates our study of the server capacty needed to support smooth playback n the channels. A Jackson Network [22] s a network of queues where the arrvals at each queue form a Posson process, and the job servce tmes are exponentally dstrbuted. An open Jackson Network s one wth external job arrvals nto or departures from the system. For each vdeo channel c, let J be the number of chunks the vdeo s dvded nto. The vewng behavor of users n channel c can be modeled as an open Jackson queueng network. We model each chunk n channel c as a queue Q, =,...,J. A user downloadng a chunk s a job n the correspondng queue. The user arrval to download a chunk equals the job arrval at the queue, and fnshng downloadnga chunk maps to completng a job n the queueng. The queueng tme of a job n the queue corresponds to the watng tme of the user for avalable bandwdth for the download. The servce tme of a job n a queue maps to the actual chunk download tme of a user. There are m servers n queue Q wth servce rate µ each, and the servce tme of a job n a server s assumed to be exponentally dstrbuted wth an average of. The servce µ rate µ of each server maps to the bandwdth R of each VM n the cloud nfrastructure (to smplfy later computaton of the number of VMs servng each chunk wth R = µ rt (recall rt s the sze of each chunk n bytes. As assumed n the prevous secton, R should be larger than the streamng playback rate r, to make t possble that the retreval of a chunk (of playback tme T can be completed wthn tme T consderng both watng and actual download tmes. The total servce rate of m servers n queue Q maps to the overall avalable bandwdth to upload chunk n the network, whch s s = µm rt = Rm. The sojourn tme of a job,.e., the sum of queueng and servce tmes, corresponds to the total tme a user spends on the retreval of a chunk. Let P denote the chunk transfer probablty matrx of channel c, wth entres P j representng the probablty that a user downloadng chunk wll move on to download chunk j (j may or may not be consecutve to. The transfer probabltes reflect vewng behavors of the VoD users. They satsfy j= P j,, and j= P j s the probablty that a user downloadng chunk leaves the channel. Correspondngly, all queues n the Jackson network are nterconnected, wth job transton probablty ndcated by P. External user arrval nto the channel and departure from the channel map to the external arrval and departure n the Note that servers n a multple-server queue n queueng theory s dfferent from servers n a VoD applcaton or a cloud. Λ Fg. 2. λ λ λ J n... n nj... μ m μ m... μ m J Channel-level queueng network model. open Jackson network. Wthout loss of generalty, we assume a fracton α of the arrved users start watchng the channel from the begnnng,.e., they go nto queue Q, and the rest α of the arrved users choose to start wth the other chunks wth a unform probablty. We assume the external arrval of users to the channel follows a Posson process wth an average arrval rate of Λ. 2 Together wth the assumpton that the servce tme n each chunk queue s exponentally dstrbuted, we can derve that the arrval to each queue s Posson, snce subflows resultng from stochastcally splttng a Posson flow are stll Posson, and the aggregaton of multple Posson flows s stll a Posson flow. Therefore, the queueng network we have modeled s an open Jackson queueng network wth a number J of M/M/m / queues. An llustraton of the queueng network s gven n Fg. 2, where λ s the arrval rate to queue Q, and n s the number of users currently n the queue (ncludng both watng and downloadng ones, =,...,J. B. Clent-Server VoD Based on the queueng network model, we now study the amount of upload capacty needed to support smooth playback n each channel. We frst consder the case that the VoD applcaton s mplemented n the clent-server mode. We study the upload capacty needed to serve each chunk n channel c, such that a smooth playback can be acheved at the users n the stable state of the VoD system. Mappng t nto the Jackson network, we derve the requred number of servers m of each queue Q, =,...,J, n the equlbrum state, such that the expected sojourn tme of each user n each chunk queue s T. Recall that T s the playback tme of each chunk at the streamng playback rate r n the VoD system. To guarantee smooth playback at each user, the average tme of retrevng each chunk (watng plus downloadng should be no longer than the playback tme of the chunk. By settng the expected sojourn tme of each queue to T, we seek to derve the necessary amount of upload bandwdth to serve each chunk. The equlbrum of a Jackson network s characterzed by the condtons n (, when the ndvdual queues acheve ther 2 Note that the average Posson arrval rate s fxed only at one tme, to derve the server capacty demand n one tme nterval. In our practcal cloud provsonng algorthm n Sec. V-B, the average arrval rate s dynamcally learned and varyng over tme, n order to capture the burstness of user arrvals at dfferent tmes.

5 respectve equlbrum. λ = α Λ + j= λ j P j, λ = α J Λ + j= λ j ρ Here ρ = λ µ = λ µ <m. P j,=2,...,j, s the server utlzaton n queue Q. To derve the requred servce rates of the queues for smooth playback, we frst derve the expected number of users n each queue n equlbrum, and then apply Lttle s law. Let p (k denote the probablty that k users are n chunk queue Q. Usng the standard queung analyss together wth Erlang s C-Formula [23], we derve the equlbrum dstrbuton of users n the queues as m p ρ k ( = ( + m ρ m k! ρ, p (k = k= p m!(m k ( ρ, ( k m k! p ( m ρ k! m k m (k >m, ( =,...,J. (2 Then, we can derve the expected number of users n queue as E(n = k= k p (k = p ( [ m k= k ρ k k! (3 Q + m m m! where W = ρ m W m + (m ++ W ], W,=,...,J. If the average sojourn tme n each queue Q s T, we have E(n =λ T, accordng to Lttle s Law. Gven λ and T, based on ths equaton and Eqn. (3, we can derve the expected number of servers, m, n queue Q whch guarantees smooth playback. In partcular, m s are calculated as follows. We frst derve λ s usng Eqn. ( and then λ T s known. We then derve m s n an teratve fashon: we ntalze m to, and ncrease ts value each step untl E(n becomes equal to λ T. The total upload bandwdth needed to serve chunk s therefore s = Rm. Wth the clent-server mplementaton, ths s the amount of upload capacty,, the cloud nfrastructure needs to supply to serve chunk, for =,...,J C. P2P VoD In a P2P VoD applcaton, the requred upload bandwdth to serve each chunk (.e., s = Rm, comes from two sources: upload capacty provsoned by the cloud, and upload bandwdth Γ from peers n the channel who own chunk. We have Rm = + Γ. To derve the capacty needed from the cloud, we study the total upload bandwdth that can be provded from the peers, n a P2P VoD system based on a typcal rarest-frst schedulng scheme. The P2P VoD scheme: A tracker server mantans lsts of peers n each vdeo channel and the chunks they buffer. A peer obtans the lst of peers from the tracker who have the chunks t wshes to download, and requests the chunks from., these peers. In response to the requests, a peer always serves chunks accordng to ther rareness,.e., requests for the rarest chunk are served frst, and then those for the less rare chunk, and so on, as many as ts upload bandwdth can accommodate. The rareness of chunks s provded by the tracker, based on the number of peers currently ownng each chunk. Based on the above scheme, we frst derve the expected number of peers who buffer chunk ( =,...,J n the equlbrum state, and then study the bandwdth suppled by those peers for uploadng the chunk. Let ν denote the number of peers n channel c that have chunk n ther buffers. It s the sum of the numbers of peers who have prevously downloaded the chunk and are currently n other chunk queues. The peers n queue Q are stll downloadng chunk, and we do not consder them as supplers of the chunk. Let ν j (j = denote the number of peers n chunk queue Q j that have buffered chunk. We use ν to denote the number of peers n queue Q (who can supply chunk upon departure from the queue, and thus E(ν =E(n. Proposton : The expected number of peers n chunk queue Q j n the equlbrum state, whch have buffered chunk, s J E(ν j = E(ν l P lj, =,...,J, j =. l= Due to space constrant, nterested readers are referred to our techncal report [24] for the detaled proof of the proposton. Snce E(n can be derved usng Eqn. (3, we can derve E(ν = E(n, based on whch E(ν j, j =, can be calculated usng Proposton. Then the expected total number of peers n channel c who have chunk s derved as E(ν = j=,j = E(ν j. (4 We next study the amount of upload bandwdth suppled by those peers wth chunk to serve the chunk, denoted as Γ, =,...,J. In the followng analyss, each peer s assumed to have the same upload bandwdth of u (the analyss can be readly extended to cases wth heterogeneous bandwdths. We sort the chunks n ncreasng order of E(ν,.e., decreasng order of chunk rareness, and denote the ordered chunk sequence as {π,...,π J }, where π represents the rarest chunk. Let Ψ(π j, π k denote the probablty that a peer smultaneously owns chunks π j and π k. Based on a smplfed assumpton that each of the E(ν π k peers that own chunk π k supples an equal share of the total upload bandwdth Γ π k for the chunk, we derve the expected amount of peer upload bandwdth contrbuton as E(Γ π k = mn{m π r, E(ν π u}, k =, π k u mn{m π k r, E(ν k j= [Ψ(πj, π k E(Γ π j l= E(n l ]}, E(ν π j k =2,...,J. (5 The ratonale behnd the above formula s as follows. For the rarest chunk π, all peers wth the chunk wll maxmally allocate bandwdth to serve t, and thus the overall

6 peer bandwdth contrbuton E(Γ π s the mnmal between the total upload bandwdth from those peers, E(ν π u, and the bandwdth demand to address ts download requests, m π r. For another chunk π k, the upload capacty that can be suppled from peers that own the chunk, equals the total upload bandwdth from those peers, E(ν π k u, mnus ther bandwdth already allocated to other rarer chunks. The deducton part s calculated as follows: for each chunk π j whch s rarer than π k (j <k, Ψ(π j, π k l= E(n l s the number of peers n the channel who concurrently own both chunks, and the bandwdth each of them contrbutes to serve chunk π j s E(Γ π j, based E(ν π j on the smplfed assumpton above. The probablty that a peer smultaneously owns two chunks π j and π k,.e., Ψ(π j, π k, can be calculated by summng up the probabltes of all possble sequences of chunk queue transtons, whch nclude queue Q π j and queue Q π k. Due to space constrant, nterested readers are referred to our techncal report [24] for the detaled steps. Wth the amount of peer bandwdth contrbuton computed usng Eqn. (5, we can eventually derve the expected upload capacty that the cloud needs to supplement for uploadng chunk, as E( =Rm E(Γ, for =,...,J V. CLOUD PROVISIONING ALGORITHM We now desgn a dynamc provsonng algorthm whch the VoD provder would execute when requestng the needed cloud resources. The algorthm makes use of the demand derved n the prevous secton. We frst formulate two optmzaton problems to characterze optmal VM request and storage rental, and then desgn the cloud provsonng algorthm. A. Optmal VM and Storage Rental To deploy a VoD server applcaton on the cloud nfrastructure presented n Sec. III, the VoD provder needs to request a certan amount of storage to store ts vdeos, as well as a number of VMs to serve the chunks from the storage. Based on the equlbrum demand E(, =,...,J,c =,...,C, derved n Sec. IV and the VoD provder s budget, the VM and storage confguraton can be formulated nto two optmzaton problems. Our dscusson n ths subsecton apply to both clent-server-based and P2P VoD applcatons. Storage Rental: Let constant vector {u,...,u F } represent the performance factors for NFS cluster,...,f, respectvely, where a larger u f for a cluster means a hgher performance level (e.g. larger I/O throughput. Bnary varable x f ndcates that chunk n channel c s to be deployed n NFS cluster f wth x f =, and not wth x f =. Let S f be the avalable storage capacty of cluster f n bytes, and p f be the storage cost per byte per unt tme on f. B S denotes the storage budget per unt tme the VoD provder s wllng to afford. Recall the sze of each chunk s rt. The optmal storage rental problem, to decde whch NFS cluster each chunk n each vdeo should be deployed onto, s formulated as:. max C C c= s.t. C c= c= = F f= x = x f S f rt, F f= u f x f f =, =,...,J,c=,...,C, f =, 2,...,F, F = f= p f rt x f BS, x f = {, }, =,...,J, c =,...,C,f =,...,F. The objectve functon maxmzes the aggregate performance for retrevng all chunks n all vdeos from the NFS storage system, where x f represents the aggregate demand of chunk n channel c from cluster f. Wth the frst constrant, we restrct that only one copy of each chunk s to be deployed n the storage system, snce all VMs can access all NFS servers. The second and thrd constrants represent the storage capacty and budget constrants, respectvely. The optmzaton problem n (6 s a Knapsack-lke problem [25]. We desgn an effcent heurstc to derve the approxmaton soluton: Storage rental heurstc: Sort all chunks n all channels n decreasng order of,=,...,j,c=,...,c, and sort the NFS clusters n decreasng order of the margnal utlty per unt cost u f p f,f =,...,F. Startng wth the chunk wth the hghest demand, we store t n the best NFS cluster (wth the largest u f p f as long as the cluster s not full, or move on to the second best cluster otherwse. Ths process repeats for all the chunks n the ordered lst, as long as the total storage budget spent does not exceed B S. Wth ths heurstc, we seek to place the most popular chunks on the NFS clusters at the hghest performance level wth the most economc budget expendture. We note that f the budget runs out when not all the chunks have been stored, the optmzaton problem does not have a feasble soluton, whch sgnals to the VoD provder that ther set budget s not feasble gven the current storage prces, whch should be ncreased. 2 VM Confguraton: Let constant vector {ũ,...,ũ V } represent the performance factors for VMs n vrtual cluster,...,v, respectvely, where a larger ũ v for a cluster means a hgher-grade confguraton (e.g., CPU, I/O. We defne varable z v as the number of VMs to request from vrtual cluster v, to serve chunk n channel c. Let N v be the maxmal number of avalable VMs cluster v can provson, and p v be the rental cost per unt tme of one VM from cluster v. B M denotes the VM rental budget per unt tme from the VoD provder. Recall R s the bandwdth each VM s allocated. The optmal VM confguraton problem, to decde how many VMs per vrtual cluster the VoD provder should request, s formulated as: max C c= = V v= z v s.t. C c= C c= V v= ũvz v = = z v = (6, =, R 2,...,J,c=,...,C, Nv, v =,...,V, V v= pvz v BM. (7 The objectve functon maxmzes the aggregate performance for servng all chunks of all vdeos from the VMs

7 requested. The frst constrant states that the total upload bandwdth of VMs requested for each chunk should be suffcent to serve the demand for the chunk. The second and thrd constrants represent the VM number and budget constrants. We desgn the followng heurstc to solve the optmzaton problem n (7: VM confguraton heurstc: Sort VM clusters n decreasng order of the margnal utlty per unt cot ũv p v,v =,...,V. For any chunk n channel c, the total number of VMs t needs s R, and we allocate as many VMs as possble to serve ths demand from the best vrtual cluster (wth the largest ũv p v f t stll has avalable VMs, or move on to the second best VM cluster otherwse. Ths process repeats for all chunks, as long as the total VM rental budget B M s not exceeded. Wth ths heurstc, we seek to maxmally place chunks on the vrtual clusters wth the best confguratons at the modest budget. Note that z v can be fractonal: ts nteger part corresponds to the number of VMs whch wll be entrely used to serve chunk, and the fractonal part ndcates the fracton of bandwdth used to serve chunk at a shared VM, whch may concurrently serve multple chunks. If one VM s used to serve more than one chunk, we wll maxmally allow consecutve chunks n one channel to be served by the VM. Smlarly, f the VM rental budget s exceeded when not all the chunk demand has been served, the optmzaton problem s not feasble, and the VoD provder should ncrease the budget accordngly. B. Dynamc Cloud Provsonng Algorthm We now propose a practcal algorthm through whch the cloud and VoD provders would cooperate to mplement our VoD-on-cloud system, CloudMeda. We llustrate our algorthm wth the case of a P2P VoD applcaton, and the algorthm can be easly adapted to clent-server VoD applcatons. To start, the VoD provder deploys ts vdeos to the NFS cluster and the server applcaton to VMs n the cloud nfrastructure, where the amount of storage and the number of VMs are estmated usng the storage and VM rental heurstcs presented n Sec. V-A, and based on the applcaton s emprcal user scale and vewng pattern nformaton and the equlbrum demand derved. Overtme, the VoD provder dynamcally adjusts ts cloud resource requests based on the current demand. As hourly resource rental s commonly supported n stateof-the-art cloud systems [2], we assume our provsonng algorthm below s perodcally run every nterval of T = hour. Key modules n the algorthm are llustrated n Fg. 3. The trackng server mantans peer lsts for each vdeo and the chunks they are cachng, as well as the IP addresses and ports of the entry ponts to the cloud nfrastructure (.e., publc access addresses of the cloud. When a peer frst jons or seeks to a new playback poston n a channel, t asks for neghbors from the trackng server whch returns a lst of peers who have the requred chunks. If there s nsuffcent peer supply, the trackng server wll return a 3-tuple,.e., <IP address of a cloud entry pont, a lst of port numbers, a tcket> to the ( c Fg. 3. ( c P j ( c ( c J CloudMeda: an llustraton of the key modules. peer. Then the peer can send ts chunk requests to the cloud. Once the tcket s verfed at the entry pont, the requests wll be forwarded to the VMs n the cloud whch wll then serve the requested chunks usng the port-forwardng technque. A VM wll send a requred chunk drectly to the peer. Durng each nterval T, the trackng server summarzes the average user arrval rate Λ to each channel c =,...,C, as well as the vewng patterns P j for each channel. It then sends these statstcs to the controller at the end of the nterval. Usng the collected arrval rates and vewng patterns, the controller estmates the equlbrum demand for upload capacty to serve each chunk,.e, s = Rm, =,...,J,c =,...,C, usng the analytcal method n Sec. IV-B, and the expected amount of peer upload bandwdth contrbuton for each chunk, E(Γ, based on the method n Sec. IV-C. The expected amount of upload capacty to be provsoned from the cloud s therefore E( =Rm E(Γ. The controller then negotates wth the cloud provder va the broker, for prces of VM and storage rental and QoS of the resources. When the SLA s set and nformaton on the vrtual and NFS clusters s provded (e.g., prces, current avalablty, the controller computes n detals ts VM requests for each chunk, applyng the heurstcs n Sec. V-A2, accordng to ts VM rental budget. If there are new vdeos to deploy or f the demand for chunks has changed sgnfcantly snce last nterval, the controller may also recompute the NFS storage rental usng the heurstc n Sec. V-A. Then, t sends the change requests to the cloud va the broker. After the requests are receved by the request montor n the cloud nfrastructure (shown n Fg., the VM scheduler and the NFS scheduler adjust ther VM and NFS server provsonng accordngly. In our dynamc provsonng algorthm, user arrval patterns n the prevous tme nterval (hour are used to predct the capacty demand n the next nterval. Ths desgn acheves mplementaton smplcty, and has been valdated by our evaluaton results, the cloud resources provsoned based on the predcted equlbrum demand serve the actual demand qute well. Nevertheless, more accurate predcton method based on hstorcal data collected over more ntervals can be appled for better performance, whch however s not the focus of the current paper and can be treated n our future work.

8 Bandwdth (Mbps C/S reserved C/S used P2P reserved P2P used Hours Fg. 4. Cloud capacty provsonng vs. usage. VI. PERFORMANCE EVALUATION We verfy our analytcal results and evaluate the performance of the dynamc cloud provsonng algorthm, based on large-scale experments usng a cloud system and a prototype VoD applcaton we have mplemented and deployed on a cluster of machnes. A. Prototype Implementaton and Expermental Settngs We have bult a cloud nfrastructure and a VoD system usng + commodty computers (Intel(R Pentum(R 4 CPU 2.8GHz, G RAM, and 8G hard drve, obsoleted from student laboratores n the Computer Scence Department at the Unversty of Hong Kong. The computers are nterconnected va a collecton of IBM 8275 Ethernet swtches (Model 324. We dvde the computers nto 3 groups, one for constructng the cloud nfrastructure (about 5 computers, one for emulatng the VoD user network (about 5 computers, and the other wth 3 computers for mplementng control mechansms (e.g., trackng server and the controller module. The computers allocated for cloud servces are further dvded nto vrtual clusters and NFS clusters. On each physcal machne n a vrtual cluster, we nstall Xen hypervsor VMs [26] wth Fedora 8 as the hostng operatng system. On each Xen VM, we nstall CentOS 5.4 as the guest operatng system and a modfed Apache server (based on verson to provde the streamng server servce. A lght-weghted cloud management system to acheve the functonal modules n Sec. III-A s mplemented usng Java, whch features a userfrendly management GUI, rapd launch, allocaton, and shutdown of VMs based on user demands, real-tme performance montorng and load balancng among VMs, etc. On each of the computers allocated for VoD network, we run tens of concurrent VoD clents (users. Each VoD clent s mplemented n Java and executed as one process. In the clentserver mode of the VoD applcaton, the users drectly connect to server servces n the cloud; n the P2P mode, the peers n each channel nterconnect nto a mesh overlay and resort to the cloud only when necessary. Meda chunks are delvered over TCP connectons among the cloud and the users. We create 3 VM clusters and 2 NFS clusters wth dfferent confguratons gven n Table II and Table III, respectvely. Each VM n the VM clusters s allocated a fxed bandwdth of Mbps. The prces are set based on the chargng model of Amazon EC2 [2] and S3 [3]. The VM and storage rental budgets are B M = $ per hour and B S = $ per hour, respectvely. We deploy 2 vdeo channels wth dfferent populartes followng a Zpf-lke dstrbuton wth the total number of concurrent onlne peers around 25. The streamng playback rate of each channel s r = 5 Kbytes/s (4 Kbps and the length of each vdeo s mnutes. The sze of each chunk s 5 Mbytes, correspondng to a playback tme of T =5mnutes. 3 To emulate realstc VoD user dynamcs, we have generated a synthetc trace, followng the measured user dynamcs and other characterstcs n PPLve VoD as dscussed n [2]. Specfcally, user populaton n each channel follows a daly pattern wth two flash crowds around noon and n the evenng, respectvely. The nterval between two playback jumps made by a VoD user follows an exponental dstrbuton wth an expected length of 5 mnutes. The upload capacty of users follows a Pareto dstrbuton wthn range [8Kbps, Mbps] wth shape parameter k =3, whch s mplemented va bandwdth control n VoD clent processes. B. Streamng Performance We emulate the executon of user swarms together wth CloudMeda system over one week s tme, and plot n Fg. 4 the provsoned upload capacty from the cloud nfrastructure and the actually used cloud upload capacty by the users, n both the cases of clent-server and P2P VoD mplementatons. We observe that n the majorty of tme, provsoned bandwdth s larger than the used, showng the effectveness of our server demand predcton: even f smplfed assumptons have been made n our modelng, expermental results under realstc settngs have exhbted good matchng between user demand and cloud supply, even at tmes of flash crowds. In addton, the amount of cloud capacty needed n P2P VoD s much smaller than that n clent-server VoD, showng that peerasssted mplementaton can further sgnfcantly allevate the operatonal cost of VoD provders, who have already exploted the cost-effcent cloud paradgm. Fg. 5 shows the average streamng qualty n the 2 streamng channels, computed as the percentage of users n all the channels wth smooth playback n the past 5 mnutes. The streamng qualty n P2P VoD s slghtly worse than that n clent-server VoD (but stll acheves an average of.95, whch represents a mnor tradeoff between streamng qualty and server (cloud cost wth a peer-asssted mplementaton. We next take a closer look at the streamng performance n each of the streamng channels. In Fg. 6, we plot the streamng qualty vs. the number of users n each channel n clent-server VoD. The samples plotted are szes of the 2 channels durng one day s perod of tme (note that the sze of each channel vares over tme. We see that the streamng qualty s generally good regardless of channel szes. The results for P2P VoD are slghtly worse, whch we omt from the fgure, as they sgnfcantly overlap wth the results of clent-server VoD. 3 The selecton of chunk sze should am to mnmze the unnecessary number of tmes of VM swtchng durng users playback, whle consderng the average length of contnuous playback between two VCR operatons as well as the actual transmsson effcency. We have expermented wth dfferent chunk szes and dentfed the one presented here as the best.

9 TABLE II VIRTUAL CLUSTER CONFIGURATIONS Type Utlty (ũ v Memory CPU Hard Dsk Prce ( p v per hour No. of VMs per cluster (N v Standard.6 28 MB 5MHz 5GB $ Medum.8 92 MB 5MHz 5GB $.7 3 Advanced 256 MB 5MHz 5GB $.8 45 TABLE III NFS CLUSTER CONFIGURATIONS Type Utlty(u f Rotaton Speed Prce(p f (per GB per hour Capacty(S f Standard.8 72 RPM $. 4 2 GB Hgh 8 RPM $ GB In the companon fgure of Fg. 7, we plot the bandwdth provsoned to each channel (from the cloud aganst the current sze of the channel. We observe that bandwdth demand lnearly ncreases wth the number of users n a channel n clent-server VoD, but scales very well wth P2P VoD. C. VM and Storage Usage We next nvestgate the effcency of VM startup and shutdown, the effectveness of our storage and VM confguraton heurstcs, as well as the costs nvolved n operatng the cloud. In our mplementaton, VM nstances are pre-deployed (and n off state n the physcal machnes n the cloud nfrastructure, correspondng to 3 dfferent confguratons gven n Table II. When the CloudMeda system s n operaton, VMs are launched and shut down by the cloud management system accordng to real-tme VoD users demand, usng the dynamc provsonng algorthm n Sec. V. It takes around 25 seconds to turn on a VM, and even less tme to shut t down. As VMs can be launched (or shut down n parallel, latency nvolved n VM provsonng s small (at seconds, whch enables tmely servce provsonng for a VoD applcaton. To evaluate the effectveness of our storage rental and VM confguraton heurstcs, we select 4 channels wth dfferent average user numbers of, 6, 2, 6, respectvely, and compute the aggregate storage utlty ( F = f= u f x f and aggregate VM utlty ( V = v= ũvz v n each channel at dfferent tmes, n the case of P2P VoD. In our experments, the performance factors ũ v and u f reflect the dfferent memory allocaton and hard dsk speeds of dfferent VM and storage clusters, respectvely. Therefore, the aggregate utltes represent overall I/O performance at the allocated VMs and storage servers, respectvely. The evoluton of the utlty values n Fg. 8 and 9 shows the adaptveness of our heurstcs, whch always strves to acheve the best storage and VM allocaton for chunks (and channels accordng to ther current popularty. Fg. gves the total VM rental cost to support the VoD system n one day s perod of tme, n the cases of P2P VoD and clent-server VoD, respectvely. We observe that the average cost of VM rental wth P2P VoD s about $4.27 per hour, and that for clent-server VoD s much larger at an average of $48 per hour, whch also vares sgnfcantly over tme due to the dynamcs of user populaton. Ths llustrates the great potental of usng a hybrd P2P and cloud paradgm n provdng hgh-performance streamng wth low cost. On the other hand, the storage cost for NFS rental can almost be gnored, at around $.8 per day. Snce our costs are derved based on practcal prcng models from [2] [3], ths verfes that the cost of deployng a large-scale VoD applcaton on a cloud nfrastructure largely les at the VM rentals, nstead of storng the many vdeos onto the cloud storage. D. Impact of Peer Bandwdth Suffcency We have also evaluated the mpact of peers upload bandwdth avalablty on cloud capacty provsonng and streamng qualty, n the case of P2P VoD mplementaton. Wth dfferent experments, we vary the rato of average upload capacty per peer over the streamng rate r. As expected, less cloud resource s needed when peer average upload capacty s larger, whose plots we omt as the results are qute ntutve. We plot n Fg. the evoluton of average streamng qualty n the system at dfferent peer average bandwdth levels. The streamng qualtes are satsfactory n all cases, showng that our cloud capacty provsonng can well absorb dfferent bandwdth demand from the P2P overlay over tme, no matter whether the peer bandwdth contrbuton s suffcent or not. VII. CONCLUDING REMARKS Ths paper ntroduces the paradgm of utlzng cloud servces to support large-scale Internet-based applcatons. Usng the example of vdeo-on-demand applcatons, we demonstrate how on-demand cloud resource provsonng can desrably meet the dynamc and ntensve resource demands of VoD over the Internet. Our man contrbutons are: Frst, we propose a novel queueng network model to characterze users vewng behavors, wth whch we derve the equlbrum demand of upload bandwdth for smooth playback for both clent-server and P2P VoD mplementatons. Second, takng practcal cloud parameters nto account, we formulate two optmzaton problems related to VM provsonng and storage rental, for whch we propose some effcent solutons. Thrd, a practcal dynamc cloud provsonng algorthm s desgned and mplemented, by whch a VoD provder can effectvely confgure the cloud servces to meet ts demands. Our extensve performance evaluatons based on real system mplementatons adopt practcal user dynamcs observed n real-world VoD systems, and the results confrmed the adaptablty and effectveness of CloudMeda n handlng tme-

10 Streamng qualty C/S (avg.=.97 P2P (avg.= Hours Streamng qualty.5 C/S Number of users n a channel Bandwdth (Mbps P2P C/S Number of users n a channel Fg. 5. system. Average streamng qualty n the VoD Fg. 6. Channel streamng qualty vs. channel sze for all channels n one day s tme. Fg. 7. Cloud capacty provsonng vs. channel sze for all channels n one day s tme. Aggregate storage utlty channel (avg. sze=6 channel 2 (avg. sze= channel 3 (avg. sze=2 channel 4 (avg. sze= tme (hour Aggregate VM utlty 5 channel (avg. sze=6 channel 2 (avg. sze= channel 3 (avg. sze=2 channel 4 (avg. sze= tme (hour Overall VM cost ($/hour C/S P2P tme (hour Fg. 8. Evoluton of aggregate storage utlty n 4 representatve channels. Streamng qualty.5 Fg. 9. Evoluton of aggregate VM utlty n 4 representatve channels. Streamng qualty.5 Fg.. Evoluton of overall VM rental cost. avg.=.95 avg.=.95 avg.= Days n a week Days n a week Days n a week Fg.. Average streamng qualty wth P2P VoD mplementaton, at dfferent ratos of peer average upload capacty over the streamng rate: (.9, (2, (3.2. varyng demands and guaranteeng smooth playback at any tme. It can be observed that the combnaton of cloud and the P2P paradgm can acheve ultmate scalablty for Internetbased applcatons wth mnmum operatonal costs. In our ongong work, we are expandng to cloud systems spannng dfferent geographc locatons, as well as more extensve evaluatons wth Internet-wde deployment. REFERENCES [] Cloud Computng, [2] M. Armbrust, A. Fox, R. Grfth, A. D. Joseph, R. Katz, A. Konwnsk, G. Lee, D. P. A. Rabkn, I. Stoca, and M. Zahara, Above the Clouds: A Berkeley Vew of Cloud Computng, Techncal report, 29. [3] S. Pandey, L. Wu, S. Guru, and R. Buyya, A Partcle Swarm Optmzaton (PSO-based Heurstc for Schedulng Workflow Applcatons n Cloud Computng Envronment, n Proc. of IEEE AINA, 2. [4] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandc, Cloud Computng and Emergng IT Platforms: Vson, Hype, and Realty for Delverng Computng as the 5th Utlty, Future Generaton Computer Systems, Elsever Scence, vol. 25, no. 6, pp , June 26. [5] B. Cheng, X. Lu, Z. Zhang, H. Jn, L. Sten, and X. Lao, Evaluaton and Optmzaton of a Peer-to-Peer Vdeo-on-Demand System, J. Syst. Archt., vol. 54, no. 7, pp , Jul. 28. [6] Z. Lu, C. Wu, B. L, and S. Zhao, UUSee: Large-Scale Operatonal On- Demand Streamng wth Random Network Codng, n Proc. of IEEE INFOCOM, March 2. [7] Y. Xao, C. Ln, Y. Jang, X. Chu, and S. Shen, Reputaton-based QoS Provsonng n Cloud Computng va Drchlet Multnomal Model, n Proc. of IEEE ICC, 2. [8] Pexoto, M. Santana, M. Estrella, J. Tavares, T. Kuehne, B. Santana, and R.H.C., A Metascheduler Archtecture to Provde QoS on the Cloud Computng, n Proc. of IEEE ICT, 2. [9] S. Yu, C. Wang, K. Ren, and W. Lou, Achevng Secure, Scalable, and Fne-graned Data Access Control n Cloud Computng, n Proc. of IEEE INFOCOM, 2. Streamng qualty.5 [] C. Wang, Q. Wang, K. Ren, and W. Lou, Prvacy-Preservng Publc Audtng for Data Storage Securty n Cloud Computng, n Proc. of IEEE INFOCOM, 2. [] R. Urgaonkar, U. C. Kozat, K. Igarash, and M. J. Neely, Dynamc Resource Allocaton and Power Management n Vrtualzed Data Centers, n Proc. of IEEE/IFIP NOMS, 2. [2] Amazon Elastc Compute Cloud, [3] Amazon Smple Storage Servce, [4] S. Lu, M. Chen, S. Sengupta, M. Chang, J. L, and P. A. Chou, P2P Streamng Capacty under Node Degree Bound, n Proc. of IEEE INFOCOM, March 2. [5] D. Wu, Y. Lu, and K. W.Ross, Queung Network Models for Mult- Channel P2P Lve Streamng Systems, n Proc. of IEEE INFOCOM, 29. [6] R. Kumar, Y. Lu, and K. Ross, Stochastc Flud Theory for P2P Streamng Systems, n Proc. of IEEE INFOCOM, 27. [7] N. Parvez, C. Wllamson, A. Mahant, and N. Carlsson, Analyss of BtTorrent-lke Protocols for On-Demand Stored Meda Streamng, n Proc. of ACM SIGMETRICS, June 28. [8] S. Lu, R. Zhang-Shen, W. Jang, J. Rexford, and M. Chang, Performance Bounds for Peer-Asssted Lve Streamng, n Proc. of ACM SIGMETRICS, June 28. [9] C. Wu, B. L, and S. Zhao, Mult-channel Lve P2P Streamng: Refocusng on Servers, n Proc. of IEEE INFOCOM, 28. [2] F. Lu, Y. Sun, B. L, and B. L, Quota: Ratonng Server Resources n Peer-Asssted Onlne Hostng Systems, n Proc. of IEEE ICNP, 29. [2] Y. Huang, T. Z. J. Fu, D.-M. Chu, J. C. S. Lu, and C. Huang, Challenges, Desgn and Analyss of a Large-Scale P2P-VoD System, n Proc. of ACM SIGCOMM, August 28. [22] J. R. Jackson, Jobshop-lke Queueng Systems, Management Scence, vol., no., pp. 3 42, 963. [23] Robert B. Cooper, Introducton to Queueng Theory (2nd Edton. Elsever North Holland, 98. [24] Y. Wu, C. Wu, B. L, X. Qu, and F. C. Lau, Cloud- Meda: When Cloud on Demand Meets Vdeo on Demand, ywu/papers/cloudmeda.pdf, CS, The Unversty of Hong Kong, Tech. Rep., February 2. [25] H. Kellerer, U. Pferschy, and D. Psnger, Knapsack Problems. Sprnger, 24. [26] Xen,