A Bandwidth Management Technique for Hierarchical Storage in Large-Scale Multimedia Servers

Transcription

1 A Bandwidth Management Technique for Hierarchical Storage in Large-Scale Multimedia Servers James Z Wang Kien A Hua Department of Computer Science University of Central Florida Orlando, FL 38-36, USA Abstract Using magnetic disks as a cache for tertiary storage has been shown to be an effective way to address the high storage costs of large-scale multimedia servers We investigate a technique for managing the bandwidth of such a hierarchical storage design In existing schemes, all data items are treated equally; and the same I/O rate is used to load data from tertiary storage when they are requested In our approach, different loading rates are used for data items with different characteristics For frequently used items, we keep a large percentage of their data in the disk buffer and need to use only a small I/O rate to load the missing portions on demand On the contrary, a larger portion of less frequently used items is kept in the tertiary storage To minimize their access latencies, larger I/O rates are used to load the missing parts when these items are needed We formally prove that this approach is better than using the same loading rate for all data items We also show simulation results to quantitatively demonstrate the benefits of our technique They confirm that our scheme is able to provide higher system throughput while ensuring very short latencies (ie, several seconds) for essentially all accesses Such good performance is achieved using surprisingly small disk space (ie, about 5% or less of the database size) Introduction Although the performance of magnetic-platter drives makes them desirable for multimedia applications, their high cost per gigabyte and relatively low storage capacity make them impractical as the sole storage medium for largescale multimedia servers [6, ] For large systems, such as movie-on-demand servers [3,, 5, 3, 0,, 7,, 8, ] which typically contain from,000 to 8,000 movies, economics will dictate the use of large tertiary storage devices such as optical disk drives Typically, these storage subsystems are organized as a hierarchy, in which the magnetic disks are used as a cache for the tertiary storage [5, ] One hierarchical storage design, called PIRATE, was proposed in [7] PIRATE is based on a pipelining concept; in which, a video file is divided into a sequence of slices such that the of time eclipses the time required to materialize (ie, loading into disk), where This strategy ensures a continuous while reducing the latency time because the system can initiate the of an object as soon as a fraction of the object (ie, ) is disk resident This scheme, however, requires a disk space as large as the entire multimedia object before the pipelining mechanism can take place Waiting for the availability of such a large disk space can lengthen the access latency The demand for the large buffer space will also flush out many potentially useful data To address the aforementioned problems, We proposed SEP in [8] to pipeline the slices, through a shared staging buffer about the size of This buffer can be implemented as a circular buffer as illustrated in Figure It shows that the reads from, and the tertiary device writes to different locations of the same buffer We note that since the rate is faster than the materialization rate, the writing pointer can never overtake the reading pointer On the other hand, the way we break up the object into slices ensures that the reading pointer cannot catch up with the writing pointer As soon as the pipelining is complete, the space occupied by this buffer is immediately returned to the buffer pool To further improve the performance, the following three additional features were used in SEP [8]: Buffer Shrinking: The size of the staging buffer shrinks because the sizes of the slices of an object decrease (ie,!$ &%!$ '(% )%!$ * ) The space that becomes free due to buffer shrinking can be collected and used by other requests

2 Head Stealing: When an object is known to be used infrequently, its first slice is assigned a cold temperature (ie, a hate hint) and is made available for replacement as soon as possible Object Pinning: When an object momentarily becomes very high in demand, it is more advantageous to pin the entire object in the disk buffer, rather than using too many staging buffers to serve different users Although we showed in [8] that SEP significantly improved the long latency times of PIRATE, its space requirement is still very large Another disadvantage of this scheme is that pipelining can only be done in the forward direction This drawback makes it unsuitable for implementing VCR functions [] CD Read Data Memory Buffers Used Free Magnetic Disk Buffer Display Data Load into Memory Figure SEP using a circular staging buffer Display Device In this paper, we consider our another approach called BiHOP (Bidirectional Highly Optimized Pipelining) [] Unlike PIRATE and SEP, BiHOP organizes a multimedia object into two categories of data fragments: disk-resident fragment (or D-fragment) and tertiary-device-resident fragment (or T-fragment) The D and T-fragments interleave the data file as illustrated in Figure Assuming that the D- fragments are already disk resident, the pipelining is per- 3 n- n- n n+ 0 time D0 T D T D T3 D3 T Tn Dn materi materi : cached data materi : data loaded on demand materi materi Figure Fragments of a video file materi formed as follows As the system s the first D- fragment, it materializes the next T-fragment from % tertiary devices For, it materializes while ing and Obviously, to maintain the continuous, the elapsed time of ing should be equal to the elapsed time of materializing ; and the elapsed time of ing and should be equal to the elapsed time % of materializing for A unique property of this scheme is that it caches every other data fragments (ie, the D-fragments), instead of caching consecutive fragments as in traditional practice To load the remaining fragments (ie, T-fragments) on demand, one can use a tiny staging buffer about the size of a T-fragment Thus, the access latency, in this case, is essentially zero Another distinctive advantage of BiHOP is its ability to pipeline in either forward or reverse direction due to its symmetrical file structure This unique feature, not possible with PIRATE and SEP, makes it natural for implementing VCR functions [] Obviously, the performance of the above pipelining techniques depends on the ratio:, where is the data rate used to load an object from tertiary devices into disks, and is the rate of the station This ratio is called Production Consumption Rate (PCR) in this paper In the current designs, only one PCR is determined for the system, and all objects in the database are fragmented based on this common ratio In this paper, we would like to argue that the overall performance of a pipelining scheme can be optimized by carefully designing an appropriate PCR for each of the objects We note that is dictated by the quality of service, however, is controllable to optimize the performance of the pipelining technique Given an I/O bandwidth of units, concurrent I/O streams can time share this bandwidth to create logical I/O channels, each with a bandwidth of! units This is the approach taken by existing techniques In our scheme, we do not divide the total bandwidth evenly among the logical channels Instead, some objects are allowed a larger quantum (ie, a bigger share of the total bandwidth) to give the effect of a logical channel with a larger bandwidth Using this strategy, we can control the proper materialization rate for each object in order to take advantage of its characteristics Without loss of generality, we will use BiHOP in this paper to demonstrate the benefits of our bandwidth management technique The reader, however, should keep in mind that the proposed scheme is generally applicable to all pipelining methods To facilitate our study, we will investigate two BiHOP designs: BiHOP and BiHOP, where BiHOP uses a single materialization rate for all objects, whereas BiHOP uses various materialization rates for different objects The subscripts S and V signify the single-materialization-rate approach and variousmaterialization-rate approach, respectively The rest of this paper is organized as follows BiHOP

3 , - * * B C A A A A B and BiHOP are discussed in more detail in Section To quantify the improvement achievable by BiHOP, we present a simulation model in Section 3, and the simulation results are examined in Section Finally, we give our concluding remarks in Section 6 Bandwidth Management for BiHOP The notations used in our discussion are illustrated in Figure 3 They are defined in the following: : Average number of users using the server simultaneously : Number of multimedia objects in the database : Average number of multimedia objects being used simultaneously : Multimedia object : Average number of users using object simultaneously We have : Display rate of each client station The system must be able to deliver data from the disk subsystem to a station at this rate!$ &% : Materialization rate used for object ' % ' : Tertiary bandwidth required by scheme &+ )' to support the concurrent users who are using mul- timedia objects is computed as )(!$ &% % ' : Disk space required by scheme to cache the D-fragments of the objects being used : Size of each multimedia object : Size of each T-fragment : Size of each D-fragment O O D Using the Same Materialization Rate For BiHOP to work, the following conditions must be true: / and 5 :<;>=@? To minimize the size of the staging buffer, we should minimize We can reduce the fraction 7B in Equation () to its irreducible form 7B, such that D is prime to E Thus, the minimum size for the T-fragments is D blocks Accordingly, the size for D-fragments, except the first one, should be EGF D The size for the first D-fragment is H or E <;>=I )? J blocks For instance, if, we have D LK and E NM The sizes of D-fragments and T-fragments, therefore, are blocks and 3 blocks, respectively This example is illustrated in Figure In this case, we need a shared staging area as small as only four blocks (ie, the staging buffer needs to be one block larger than ) Since the staging areas are tiny, they can be implemented in the memory to allow the pipelining to bypass the disk subsystem This leaves the disk space exclusively for caching D-fragments This strategy also has the advantage of conserving disk bandwidth for the buffer replacement activities The size of the entire object can be computed in terms of and as follows: /0 O where is the number of T-fragments in the object Let denote the accumulative size of all the D-fragments of this object It can be computed as follows: B: R S T U WV F <;>=!$ ()? () We note that is equal to the size of the first data slice (ie, ) in PIRATE and SEP The algorithm for managing the D- fragments is the same as in [] O O3 O i ON Tertiary devices B materialize (i) O O3 O i Om Disk buffer k i = B Figure 3 Notations used in this paper D D3 Dd Using Various Materialization Rates In this subsection, we first discuss the guidelines for choosing the appropriate materialization rates for objects with different characteristics These guidelines are then used to design an algorithm for the determination of materialization rates Design Guidelines BiHOP uses various materialization rates for different objects Without loss of generality, we assume that the multimedia objects are numbered so that X XZY [X,

4 - - - ' * * ) where X denotes the average number of users using object simultaneously The following guidelines are used to design the bandwidth management technique: and 3 (3) R We note that the above guidelines will not be followed stringently because the second condition is difficult to meet exactly To justify these two requirements, we prove in the following that a BiHOP scheme satisfying these conditions will require less tertiary bandwidth than BiHOP does Furthermore, this benefit is obtained without using more disk space Tertiary Bandwidth Requirement: To facilitate our discussion, we have the following theorem Theorem For any %, if $??? Y and, then R R Y R R? Theorem can be proved by induction However we will not present the formal proof here due to the space limit In order to allow users to use objects simultaneously, BiHOP requires a tertiary bandwidth computed as follows: 3 R X Applying Theorem to the above equation, we can derive the following: R X R Substitute Equation (3) into the above equation, we have:! $!% & Thus, we conclude that Disk Space Requirement: Without loss of generality, we assume that all of the objects being used have size The disk space required by BiHOP to cache the objects can be computed as:? X equation for X ' (!% $ +* R B Using Equation (), the becomes:!, Substitute Equation (3) into the above equation, we have: X / X F Thus, we can conclude that BiHOP disk space than BiHOP does Bandwidth Determination Algorithm 0? - & does not require more Using the guidelines discussed previously, we designed a Static Bandwidth Allocation (SBA) algorithm given in Figure The following notations are used in the algorithm:!$ X!$ Algorithm: SBA 3 We have: and 76 R 3, where 8 is the number of objects in the database : The size of the disk buffer : The size of object : The access frequency of multimedia object 53 ' $ ( < $ - :/; & = for $ to N do if >?@BA CBD E F G 'JI LK C? H- - :/; then NMO $ = /* store in disk */ else NMO!SR $ P*?@BA CBD! TVU ' E F G $ +* NMO C?N E FWG! $ NMO H- :/; < $ < < ;NX Figure Static bandwidth allocation algorithm Basically, algorithm SBA determines the materialization rate for each multimedia object in the database according to its relative access frequency For each object, SBA first determines the appropriate caching space for its D-fragments This is done by allowing a more frequently referenced object to cache a larger percentage of its data blocks, ie, having larger D-fragments As a result, this object will need a smaller materialization rate to support its pipelining We note that this strategy coincides with the guidelines discussed previously Once SBA has determined the materialization rates for all the data objects, the technique discussed for BiHOP can be used to compute the sizes of T-fragments and D-fragments for each object in the database

5 Y 3 Simulation Model In the last section, we have proved that using various PCRs was the better approach In this section, we develop a simulation model to quantify the benefits Our simulation model is similar to the one used in [8, ] The Request Generator generates a request for a multimedia object and submits it to the Waiting ueue The requests arriving at the Waiting ueue can be viewed as coming from different users The Scheduler examines the requests in the queue in a FCFS manner When bandwidth becomes available for serving the pending request at the head of the queue, the scheduler forwards this request to the Serving Unit This unit then allocates a playback stream to serve this request Serving Unit simulates a hierarchical storage system (either BIHOP or BIHOP ) and the playback mechanism In terms of workloads, each user request is characterized by an interarrival time and choice of object User request interarrivals were modeled using a Poisson process The access frequencies of objects in the database follow a Zipf-like distribution [] Let be the total number of requests for a simulation run The = O number of requests for each object is determined as:, where 8 is the num- ber of objects in the system, and is the skew factor A larger value corresponds to a more skew condition, ie, some objects are accessed considerably more frequently than other objects When, the distribution is uniform, ie all the objects have the same access frequency This Zipf-like distribution is similar to the distribution used in [3] A workload, called a job sequence, is generated for each skew condition Each sequence consists of 0,000 requests For each simulation run, the same sequence is used for both BiHOP and BiHOP Thus, the Request Generator does not really generate requests on the fly Instead, it keeps a database of these request sequences For each simulation run, it scans the appropriate sequence, and appends the next request from the sequence to the Waiting ueue when the corresponding inter-arrival time is up Without loss of generality, we assume that all client dis- B play devices have the same rate (ie, is constant) The playback durations of the objects are uniformly distributed between 7 minutes and 33 minutes The default values for the system and workload parameters are given in Table In our experiments, many of these parameters were also varied to perform various sensitivity analyses In our study, system throughput, average access latency and latency variance are used as the performance metrics The system throughput is computed by dividing the number of requests in the job sequence (ie, 0,000) by the the time it takes to serve the 0,000 requests The access latency of a request is its waiting time in the queue The average latency is computed as the mean of the 0,000 in- Disk space Tertiary R I/O bandwidth! Zipf factor 07 Requests per minute 0 Number of objects 600 3,500,000 blocks,000 blocks/sec 00 blocks/sec 80 blocks/sec ( Minimum object size 00,000 blocks Maximum object size 00,000 blocks Number of requests 0,000 Table Simulation parameters ) dividual latencies The latency variance is computed as R F Y *!, where is the access latency of the th request, and denotes the average access latency Thus, a better scheme should have higher throughput and lower average latency with a very small variance A small variance is desirable because it allows us to assure similar latencies for most requests To avoid the buffer warm-up effect, we actually ran a short sequence of requests to fill up the disk buffer before the actual run takes place The requests in the short sequence were randomly selected from the long sequence to ensure that the data initially cached in the buffer (to simulate the steady-state condition) were relevant and truthfully reflected the distribution of the requests in the workload (ie, the long sequence) Simulation Results In our experiments, we did sensitivity analyses with respect to the following system and workload parameters: PCR, tertiary bandwidth, request rate, disk capacity, and reference skew The simulation results are discussed in the following Performance under Various PCRs To evaluate the performance of BiHOP, we compare it to BiHOP To make the comparison fair, we first determine a good PCR value for BiHOP in this subsection This value of PCR will be used in the subsequence subsections to compare the performance of the two techniques The performance of BiHOP under various PCRs is plotted in Figure 5 We observe that the throughput of BiHOP reaches its peak when PCR is at 08 At this PCR value, the average access latency is about one minute which is acceptable for most VOD applications We thus choose 08 to be the good PCR value for BiHOP We observe that the performance of BiHOP is essentially flat when we increase PCR beyond 08 This is due to the fact that the system does not have enough tertiary bandwidth to efficiently

6 Latency Time(Seconds) Throughput(Services/Hour) PCR (a) Latency PCR (b) Throughput PCR (c) Latency variance Figure 5 Performance of BiHOP! under different PCRs support PCR greater than 08 The performance of BiHOP is also plotted in Figure 5 for comparison Since BiHOP determines its own PCRs for different video files, its performance is insensitive to the changes in the PCR value used by BiHOP The performance curves of BiHOP, however, are not perfectly flat because a different workload was randomly generated for each of the five simulation runs under five different PCR values Comparing the two schemes, we notice that BiHOP significantly undercuts the average latency of BiHOP Furthermore, the latencies experienced in BiHOP are much less varying than those seen in BiHOP In other words, BiHOP offers substantially more predictable performance in terms of access latency Performance under Various Tertiary Bandwidths The performance of BiHOP and BiHOP under various tertiary bandwidths is plotted in Figure 6 We note that there is an abrupt drop in the latency curve of BiHOP when the tertiary bandwidth is 8,000 blocks/second This is due to the log scale used for the vertical axis The plots show that BiHOP is much less demanding on the tertiary bandwidth than BiHOP is For instance, to achieve an average latency of about 60 seconds, it requires BiHOP to have 50% more tertiary bandwidth than it does with BiHOP Furthermore, the small variance of BiHOP indicates that the performance of this scheme is very predictable, eg, one can expect a wait time of no more than 0 seconds with very high confidence when the bandwidth is about,000 blocks/second 3 Performance under Various Request Rates The effect of request rate on the two BiHOP schemes is plotted in Figure 7 Again, BiHOP consistently outperforms BiHOP by a significant margin If an acceptable average latency must be within one minute, then BiHOP can sustain request rates as high as 60 requests/minute In fact, it allows objects to be accessed in about 0 seconds when the request rate is less than 5 and the access latency will be within seconds if the request rate is less than 35 On the other hand, BiHOP can only handle request rates up to 0 requests/minute If we make the requirement more stringent by restricting most of the wait times to less than two minutes, then BiHOP in fact can no longer be used due to its large variances In terms of system throughput, BiHOP outperforms BiHOP by as much as 600 more services per hour Performance under Various Space Ratios We define the space ratio as D 0 = X /0! 0 /0 In this experiment, we want to investigate the effect of this ratio on the performance of BiHOP and BiHOP A good technique should be able to achieve good performance using a reasonably small buffer In other words, we want to keep the Space Ratio as small as possible without compromising too much performance We varied the space ratio from 5% to 0% The results are plotted in Figure 8 It shows that BiHOP is a lot more demanding on disk space To keep the average latency time within one minute, BiHOP needs more than triple of the buffer space needed by BiHOP Another interesting observation is that BiHOP requires surprisingly little disk space to achieve the good performance With a disk space as small as only 5% of the database size, it is able to assure most accesses with latencies less than 30 seconds This suggests that BiHOP is a very cost effective technique for designing high-performance tertiary devices for multimedia applications

7 Latency Time(Seconds) Latency Time(Seconds) Latency Time(Seconds) Tertiary Bandwidth(x000 blocks/sec) Request Rate(Requests/min) Space Ratio(Disk Size/Database Size) (a) Latency (a) Latency (a) Latency Throughput(Services/hour) Throughput(Services/hour) Throughput(Services/hour) Tertiary Bandwidth(x000 blocks/sec) Request Rate(Requests/min) Space Ratio(Disk Size/Database Size) (b) Throughput (b) Throughput (b) Throughput Tertiary Bandwidth(x000 blocks/sec) Request Rate(Requests/min) Space Ratio(Disk Size/Database Size) (c) Latency variance (c) Latency variance (c) Latency variance Figure 6 Performances under different tertiary bandwidths Figure 7 Performances under different request rates Figure 8 Performances under different space ratio 5 Performance under Various Skew Conditions To investigate the performance of the two BiHOP schemes under various applications, we varied the skew factor from 0 to The experimental results are plotted in Figure We observe that BiHOP delivers good average latencies and good system throughput regardless of the skew conditions under this workload On the contrary, BiHOP is only effective for skew conditions larger than 07 assuming an average latency of less than one minute is desired Again, its poor performance can be attributed to the insufficiency of tertiary bandwidth We note that a smaller skew condition can significantly reduce the hit ratio of the disk buffer BiHOP, however, is a lot more efficient in terms of disk space utilization As a result, it is more capable in handling any kind of skew conditions 5 Concluding Remarks Much work has been done to show that pipelining is an efficient technique for designing hierarchical storage subsystems for large-scale multimedia servers The performance of such systems depends on the PCR which is defined as the ratio between the I/O rate used to load data from the tertiary devices into the disk buffer and the rate of the client station Although suitable setting of this ratio is very critical, no work has been done to investigate the proper choices of its values In this paper, we formally proved that using various PCRs for different objects with different characteristics is a better approach than conventional designs which use the same PCR for all objects in the database Based on the proof, we also designed an algorithm for the determination of the appropriate PCRs To quantify

8 Latency Time(Seconds) Throughput(Services/Hour) Zipf (a) Latency Zipf (b) Throughput Zipf (c) Latency variance Figure Performances under different skew conditions the benefit of our technique, we implemented a simulator to compare the performance of two pipelining techniques: BiHOP which uses one PCR for all objects, and BiHOP which uses various PCRs for different objects The simulation results confirm that BiHOP offer substantially better performance It provides higher system throughput while guaranteeing very short latencies for essentially all accesses Such good performance is achieved using surprisingly small disk space (ie, about 5% or less of the database size) This fact convinces us that BiHOP is an excellent technique for designing high-performance tertiary devices for multimedia applications References [] D P Anderson et al A file system for continuous media ACM Trans on Computing Systems, 0():3 337, Nov [] D W Brubeck and L A Bowe Hierarchical storage management in a distributed VOD system IEEE Multimedia, pages 37 7, Fall 6 [3] A Dan, D Sitaram, and P Shahabuddin Scheduling policies for an on-demand video server with batching In Proc of ACM Multimedia, pages 5 3, October [] J K Dey-Sircar et al Providing VCR capabilities in largescale video servers In Proc of ACM Multimedia, pages 5 3, October [5] C S Freedman and D J DeWitt The SPIFFI scalable videoon-demand system In Proc of ACM SIGMOD Conference, pages , San Jose, CA, May 5 [6] J Gemmell, H M Vin, D Kandlur, P Rangan, and L Rowe Multimedia storage servers: A tutorial IEEE Computer, 8(5):0, May 5 [7] S Ghandeharizadeh and C Shahabi On multimedia repositories, personal computers, and hierarcical storage systems In Proc of ACM Multimedia, pages 07, October [8] R T Haskin The shark continuous-media file server In Proceeding of the IEEE Computer Conference Spring 3, pages 5, February 3 [] W Hodge et al Video on demand: Architecture, systems, and applications SMPTE Journal, September 3 [0] Őzden et al A low-cost storage server for movie on demand databases In Proc of the 0th VLDB Conference, Santiago, Chile, [] K A Hua, C Lee, and C M Hua Dynamic load balancing in multicomputer database systems using partition tuning IEEE Trans on Knowledge and Data Engineering, 7(6):68 83, December 5 [] K A Hua, J Z Wang, and S Sheu BiHOP: a bidirectional highly optimized pipelining technique for large-scale multimedia servers In Proc of the IEEE INFOCOM 7, Kobe, Japan, June 7 [3] D R Kenchammana-Hosekote and J Srivastava Scheduling continuous media in a video-on-demand server In Proc of Int l Conf on Multimedia Computing and Systems, pages 8, Boston, Massachusetts, May [] A Laursen et al Oracle media server: Providing consumer based interactive access to multimedia data In Proc of the SIGMOD Conf, pages 70 77, Minneapolis, Minnesota, May [5] T Mori et al Video-on-demand system using optical mass storage system (Japanese) J Applied Physics, (B): , 3 [] L A Rowe and B C Smith A continuous media player In Proc of the 3rd Int l Workshop on Network and Operating System Support for Digital Audio and Video, pages , Nov [7] H M Vin and P V Rangan Designing a multiuser HDTV storage server IEEE Journal on Selected Areas in Communications, ():5, Jan 3 [8] J Z Wang, K A Hua, and H C Young SEP: a space efficient pipelining technique for managing disk buffers in multimedia servers In Proc of the IEEE int l Conf on Multimedia Computing and Systems, Hiroshima, Japan, June 6