Dynamic Segment Replication Policy for Load ... - Semantic Scholar

Dynamic Segment Replication Policy for Load-Balancing in Video-on-Demand Servers Asit Dan Martin Kienzle Dinkar Sitaram IBM Research Division, T. J. Watson Research Center Yorktown Heights, NY 10598

ABSTRACT In a video-on-demand server, resource reservation is needed for continuous delivery. Hence any given server can serve only upto a xed number of clients. Dierent videos may be placed on dierent disks or disk array groups. Since the access rates to dierent movies is not uniform, there may be load imbalance among the disks in the system. In this paper, we propose a dynamic policy (called the Dynamic Segment Replication Policy) that replicates segments of les in order to balance the load across the disks. By using simulation, the proposed policy is shown to be responsive to quick load surges and to be superior to a policy based on static replication of hot movies. IBM Research Report RC19589

1 Introduction Recent progress in digital video technology has led to large scale multimedia systems that store videos on disks and provide video-on-demand services to many clients over a network [9, 14, 8]. Video servers need to implement resource reservation for all the resources needed to deliver a video stream in order to satisfy the hard real-time constraints on response time [12, 1]. Resource reservation implies that each system component (e.g. a disk) can service at most a xed number of users that is dependent upon its bandwidth. Dierent videos are stored on dierent disks or disk groups. Load imbalance across disk groups may arise due to the non-uniform access patterns to dierent videos. Because of the nite capacity of each disk, this leads to requests for videos on highly loaded disks being rejected or deferred even though sucient bandwidth is available on lightly loaded disks. In order to balance the load across all the disks, each media le can be spread over all the disks [11]. This approach however has several limitations (detailed in Section 2) such as the diculty of supporting multiple types of disks, the complexity of system recon guration (e.g. adding new disks), high replication overhead in order to achieve availability and a complex recovery procedure [2], etc., and hence, is not preferred. Load-balancing across multiple servers and/or disk groups is interesting in its own right. Short term load imbalance across servers and/or disk groups implies that extra server capacity has to be provided to satisfy certain performance objectives, whereas improved load-balancing reduces the amount of required excess server capacity [17]. Static replication of all les for high availability and also for load balancing in the le-server context has been proposed in [10, 15]. This is not desirable in multimedia systems due to the large size of multimedia objects. Replication of the relatively small and frequently accessed read-only system les for load-balancing among le servers has been proposed in [13] and the eectiveness of various such policies have been studied in [15]. In the 1

presence of frequently-used short multimedia objects (e.g. commercials) the replication of short objects can be used to lessen the load imbalance problem. This approach still cannot cope with sudden load surges on other objects and would require the knowledge of the access patterns of the application in advance. A dynamic approach that uses partial replication of multimedia les for load-balancing in multimedia systems is proposed in [6]. It is based on the observation that if there were a number of consecutive requests for the same video and the blocks read in by the rst request are copied to another disk, it would be possible to switch the following requests to the partial replica just created. The approach is quite general, however, it requires complex space management in order to deal with the variable sized fragments of les residing on dierent disks. A more pragmatic policy referred to as the Dynamic Segment Replication or DSR policy is studied in this paper. The policy is based on partitioning each multimedia object into a small number of xed size segments (e.g. a movie may consist of 8 segments). Here, each segment is much larger than the disk block size. Dierent segments of a video object may be placed on dierent logical disks. We de ne a logical disk as either a single disk or a disk array whose space and bandwidth is managed uniformly by some lower level policy (in Figure 1 logical disk D1 consists of physical disks D11; D12 and D13). Hence the placement of a video le on dierent logical disks may be thought of as hierarchical striping. We assume that multimedia les are normally viewed in a sequential manner. If the load on the segments preceding a given segment is high, then by replicating that particular segment and/or all its following segments, it is possible to balance the load on the disks. We refer to such replicated segments as temporary segments since they need to be overwritten if the relative demands for videos change. The original segments in contrast are referred to as permanent segments. Replicating segments of a multimedia object rather than the entire object reduces the space overhead associated with replication. This leads to more ecient usage of the available space and hence better load balancing. Since the time to replicate the segment is much smaller 2

than the time to replicate the entire video, the approach also provides quick response to load imbalances. The DSR policy can also deal with the problem of poor initial placement of multimedia objects. As detailed in [7], by reclassifying temporary segments as permanent and permanent segments as temporary, it is possible to dynamically migrate multimedia objects. However, we do not consider this aspect of the DSR policy in this paper. The remainder of this paper is organized as follows. Section 2 describes various reasons for having multiple striping groups in a single video server. Section 3 provides an overview of the DSR policy and illustrates through an example the various trade-os in choosing a particular segment for replication. The implementation details of the DSR policy is provided in Section 4. In Section 5 using a detailed simulation, the performance of the DSR policy under various workloads is studied and compared to that of a policy based on the replication of the most popular videos. Finally, Section 6 summarizes the results.

2 Number of Striping Groups We now detail various considerations that make multiple striping groups in a video server desirable. In a real environment, there may be various types of disks in the same system. All the disks of such systems can not be striped in a single group since it is dicult to use space and bandwidth of all disks eectively. For example, under a simple striping policy such as round-robin policy, the successive blocks of a video are stored in dierent disks in order. Here, the blocks of the video les are evenly distributed over the disks. Hence it would not be possible to store more blocks than the capacity of the smallest disk on any disk, leading to wastage of storage space on the larger disks. Alternative striping schemes may be more ecient in their use of storage but lead to imbalances in the load among dierent disks in the striped set since the blocks are no longer evenly distributed 3

over the disks. Thus it is natural to group dierent types of disks into separate striping groups. The use of a single striping group also makes simple system recon guration, such as adding a single disk to the system, dicult. Since all the les are striped over all the disks, some of the blocks of every video le have to be moved. As the time needed for system recon guration is hard to estimate (depending for example on the load on the system) this may lead to large segments of each le being unavailable for varying amounts of time. Limiting system recon guration to times when the system is not operational or lightly loaded may not be desirable in practice. If multiple striping groups are used only the striping group that is being recon gured is aected. Additionally, as will be seen later, with just a small amount of replication, the loss in viewership can be made smaller even if the system is heavily loaded. Single striping group also has various recovery implications in the event of a single disk failure. If the recovery is made from back up tapes then the recovery overhead could be high either in time or in the number of backup tapes required. Since some blocks from every video that has not been replicated has been lost, every non-replicated video has to be read to extract the lost blocks. If the backup copy of each video le is stored sequentially on tape, this could take a very long time. An alternative would be to store the images of every disk on tape, increasing signi cantly the backup tape requirements and making the procedure for loading a video onto disks from tape more complex. Parity-based recovery schemes lead either to higher disk storage overhead and/or high processor (parity computation) and buer storage overhead for recovery [2]. In the following, we show that the use of multiple striping groups signi cantly reduces the amount of storage overhead needed to ensure high availability.

4

2.1 Availability vs Replication Trade-o Intuitively, if all the disks in the server are striped together, then failure of any single disk results in unavailability of all the videos, and if the disks are striped into multiple groups, then only the videos in the group containing the failed disk are lost. Since the access patterns to videos is likely to be skewed, it is possible to replicate some of the popular videos in order to increase availability. The availability of the system is de ned as the fraction of viewers who can continue viewing the videos even in the event of a single disk failure and is given by A = 1 ? E=V where E is the number of aected viewers and V is the total number of viewers in the system. Let there be S striping groups and M videos with the access frequency to the replica of video m on striping group s as fm;s. Let Bs be the set of videos on striping group s and gm;s be the number of viewers of video m that can be shifted to an alternate striping group if a disk in striping group s fails. Clearly gm;s = 0 if video m is not replicated. For replicated videos, gm;s depends upon the actual load on the disks containing the replica of video m. Assuming all the load for the replicated videos can be shifted to a non-failed striping group, (i.e., gm;s = fm;s ), we can obtain a simple expression for the upper bound on availability. This is equivalent to assuming that the system is con gured with enough spare capacity to ensure that none of the viewers of a popular video is lost on a disk failure. The number of lost viewers1 for the non-replicated videos in striping group s is given by Ls = PmBs fm;s ? gm;s . If the probability that striping group s becomes unavailable due to failure of a disk is us, the expected loss due to failure of a single disk is given by E = PSs=1 usLs. If all the disks are assumed to be identical, us = Ds =D where Ds is the number of disks in striping group s and D is the total number of disks. Given an availability requirement A, it is possible to compute the required storage overhead for replication. Under skewed access, high availability (say 90%) can be achieved 1

Spare disks can be used to restage the lost non-replicated les to resume service for the aected

viewers.

5

with only a small increase in replication storage overhead using a small number (4 to 8) of striping groups. Figure 5 shows the replication overhead as a function of the number of striping groups for various availability requirements. The access distribution to various videos is the empirical distribution shown in [3] derived from data in [16]. The gure shows that the required replication overhead increases as the availability requirement becomes higher. The replication overhead also drops signi cantly as the number of striping groups increases. With multiple striping groups, no replication will be required for certain values of availability. For example, to achieve 50% availability, no replication is required if there are 4 striping groups since on a single disk failure, only 25% of the viewers are lost. The reason for the sharp drop in the required replication overhead with the increase in the number of striping groups is that the expected loss from the failure of a single disk drops sharply with the increase in the number of striping groups. The relationship between the expected loss and the number of striping groups is shown in Figure 6 for dierent values of the number of replicated videos. If there is no replication, the expected loss E falls as 1=S . With replication, E is lower, however it still drops sharply with the number of striping groups.

3 Overview of the Proposed Policy With multiple striping groups the load imbalance problem arises naturally. In the following section, we now discuss in detail the DSR policy that addresses this problem. Figure 1 provides an overview of the system components. Each striping group consists of a number of physical disks. The server implements a hierarchical policy whereby the DSR policy balances the load among the various striping groups while some lower level policy is responsible for scheduling the I/Os to the physical disks in each striping group. We refer to a set of physical disks striped together as a logical disk in order to emphasize 6

the hierarchical nature of the DSR policy. For example, in the gure, logical disk D1 consists of the physical disks D11 through D13. Thus the DSR policy considers only the total bandwidth and space available from the logical disk and not the bandwidth and space on individual disks. The space in each logical disk is divided into a number of xed size segments. All disk segments are chosen to be the same size so as to simplify space management on the logical disk. To further reduce book keeping overhead, the size of the segments is chosen to be large so that there are only a small number of segments per video. As discussed earlier, the segments may be permanent segments initially containing some video or temporary segments into which video segments may be copied in order to balance the load. Due to non-uniform load to dierent videos, at any instant there may be imbalances in the number of current streams (loads) among the various logical disks. Videos are assumed to be viewed sequentially by one or more streams where typically each stream corresponds to a client.2 In order to avoid putting extra load on a heavily loaded logical disk, a temporary segment is created on a lightly loaded logical disk by using the blocks that have been brought in for viewing by a stream reading the segment. Such a stream that is used for both viewing and replicating to another disk will be referred to as a copyback stream in this paper. Thus in Figure 1 stream S 1 is a copyback stream since the blocks read from the heavily loaded logical disk D1 for transmission to the client are also written back to the lightly loaded logical disk D2. The decision to replicate a video segment depends on various factors, such as the current load, the future load, available replication space, etc.. Precisely, there are four types of decisions that are taken by the DSR policy. These are the decisions on 1) when to replicate, 2) selection of a segment on the source logical disk to replicate, 3) selection of a logical disk on which to replicate the segment and 4) selection of a segment on the target logical disk to be replaced. The implementation details of the DSR policy is 2

Multiple clients can share a single stream in order to reduce the demand on the video server [4, 5].

7

described in the next section. Below we illustrate through a brief example some of the trade-os that any such dynamic replication policy needs to make.

3.1 Illustrations of Segment Replication Trade-os Consider an example of a logical disk with multiple videos and streams as shown in Figure 2. The logical disk contains video M 1 and part of M 2. In the example, both the videos are subdivided into four xed-size segments, M 11 through M 14 and M 21 through M 24, respectively. The logical disk contains a copy of all the segments of video M 1, and only the last two segments of video M 2. The arrows S 11 through S 24 represent the positions of the various streams reading the videos. Assuming none of the segments of M 1 are replicated in other disks, and this particular logical disk is overloaded, by replicating segment M 13 on another logical disk, it would be possible to shift the streams reading segment M 12 to the other logical disk as they reach segment M 13. However, if only segment M 13 is replicated in other disks, and not segment M 14, then it would be necessary to switch the streams back to the current disk after they complete reading segment M 13 from other disks. It may thus be desirable to replicate segment M 14 as well for future use. Note however, while it is desirable to replicate M 14 in the future, it is not necessary to replicate it now, since replicating segment M 13 would allow the load on the logical disk to be reduced faster. For video M 2, under the assumption that there is no other replica of segments M 23 and M 24, there is very little bene t in replicating segment M 24 in another disk since no other stream is following stream S 21. It may or may not be desirable to replicate segment M 23 depending upon the number of streams reading segment M 22. The trade-os in replicating various segments also change if there are additional already existing replicas of those video segments. First, in considering the bene t of replicating a segment such as M 13, it is necessary to take into account the load on all replicas of segment M 12. Also, if there are additional replicas of segment M 13, then the bene t of replicating M 13 may be reduced since it may be possible to 8

switch the load on segment M 12 to the already-existing replicas. We like to note an important feature of the DSR policy as illustrated by the above example. The replication decision is based on load estimation that is deterministic due to sequential playback rather than statistically anticipatory in nature as in a general environment. In the later environment, it is generally assumed that if a segment is heavily loaded now, it may be heavily loaded in the future. Hence, the actual payo is unknown in that environment. In contrast, in the current environment, the actual payo from the decision to replicate a segment can be estimated with certainty from the load on the previous segments assuming linear playback.

4 Details of Implementation We now detail the implementation of the DSR policy. As described in the overview, four types of decisions need to be taken by the DSR policy. We rst describe the necessary data structures, and then consider each of these decisions in turn. Figure 3 shows the data structure necessary for each video. In a table called video table, there is a record for each video containing the number of segments in that video and a pointer to a table, called the video segment table. The video segment table maintains various information about the segments of a particular video and contains an entry for each segment. Note that dierent videos may not have the same number of segments since the segments are of xed size, and the videos are of dierent sizes. The xed size segments simpli es space management on the logical disks. Each entry in the video segment table keeps track of the current number of replicas for that segment, the number of streams currently reading any of the replicas of that segment, and the logical disks on which the segment replicas reside. As mentioned earlier, the space on the logical disk is also organized into segments. The data structure for each logical disk is shown in Figure 4. Each entry in the disk table corresponds to a logical disk and maintains various 9

counters that keep track of the number of free, inactive (i.e., no stream is reading from or writing on this segment) and active disk segments on that logical disk and the total number of current read and write streams on that logical disk. The entry also contains a pointer to a disk segment table that maintains various information regarding the segments on that logical disk. Each disk segment table entry contains the disk segment number, the video id and video segment number if a valid copy exists, a counter containing the current number of streams reading from that replica of the segment and a ag indicating whether or not the segment is currently in the process of being replicated (copied back). In addition to the above tables, there is also a stream table (not shown here) that contains a record for each stream. Each stream table entry contains a ag indicating whether or not the stream is creating a replica of the segment and the logical disk on which the replica is being created. The DSR policy is executed when a stream is about to read a new segment. First, to balance the load across logical disks, the replica of the segment residing on a lightly loaded logical disk is chosen for reading. This is accomplished by scanning the entry in the video segment table to nd all the logical disks that contain replicas of the video segment (including replicas in progress) and looking up the corresponding disk records to nd the least loaded logical disk. The relevant load information, i.e., the load counters in the disk segment entry for the selected logical disk and in the video segment entry are updated. In addition, if the disk segment was previously inactive and has now become active, the active counter in the current disk record is updated. Similarly, if the previous disk segment became inactive, the inactive count in that disk record is also updated. Also, if the current stream was replicating a segment, the data structures have to be updated to indicate that the replication is complete. This is done by resetting the ag in the disk segment entry that previously indicated that a new replica was being created. The ag in the stream record (not shown here) is also reset to indicate that the stream is no longer creating a replica. 10

The new load may trigger a decision to replicate this segment on another disk using copyback. Below we detail the condition that triggers the replication decision as well as the selection of a disk segment on which a new replica is created.

4.1 Decision on When to Replicate Replication of segments in order to reduce the load on the logical disk is necessary whenever the logical disk is overloaded. The decision to replicate is taken if both the new read load and the future read load in one segment time on this logical disk exceed a pre-speci ed threshold, rth. The future load is checked in addition to the current load since the replication decision may already have been triggered by another stream, and hence, the future load may be below threshold. The future read load in one segment time is estimated by summing the estimated future load on each segment of the logical disk. It is assumed that the future load of a video segment will be uniformly distributed over all replicas. For any segment i other than the rst, the future load is estimated as ni?1=ri where ni?1 is the number of viewers of segment i ? 1 and ri is the number of current replicas of segment i. The future load for the rst segment is estimated as n1=r1 under the assumption that the number of streams reading the rst segment in the future will be equal to the current number.

4.2 Selection of Source Segment Upon a decision to replicate a segment, the DSR policy then selects a segment to replicate. Since the DSR policy uses copyback streams, replication can start only when a stream starts reading a new segment. Hence if the logical disk load exceeds threshold at a segment boundary crossing, a decision is made if it is desirable to replicate this segment using a copyback stream. The current segment is selected for replication if it has the highest estimated payo among all the segments on the logical disk. Note that the DSR policy thus does not trigger replication of a segment simply because a stream 11

reading that segment caused the load on the logical disk to exceed the threshold. This avoids the problem of replicating a lightly loaded segment simply because it happened to be the segment that triggered the threshold. The estimated payo pi from replicating segment i of a video is a measure of the future load that may be reduced from the current disk. This is computed as

pi = (1=ri ? 1=(ri + 1))

i?1 X n wi?j?1 j =0

j

(1)

where w is a weighting factor. The motivation for using this formula is as follows. It is desirable to replicate a segment where the payo in terms of the load that can be diverted in the future is expected to be high. The load that can be shifted in the immediate future (one segment time) is given by the load on the previous segment. However, the load on earlier segments represents the load that can be shifted in increasingly distant future. To give preference to the immediate load transfer, the payo from replicating a segment is computed by exponentially weighting the load on previous segments by their distance from the current segment. The load on previous segments can be found from the corresponding video segment entries in the video segment table. Additionally, if there are ri replicas of the current segment i, creating an additional replica will result in only (1=ri ? 1=(ri + 1)) of the payo in terms of load shift. The current number of replicas ri can also be found from the video segment entry for that segment. The pi can be eciently computed in a recursive manner.

4.3 Selection of Target Logical Disk and Segment Upon a decision to replicate a segment and the selection of a source segemnt, the DSR policy then attempts to nd a target logical disk and a target segment. The disk with the lowest future read load is selected as the target disk. The future read load rather than the current load on the target disk is used since the future read load includes an estimate 12

of the impact of any replication decisions that have already been made. Hence, the use of the future load also avoids the hot spot problem that would have been be created if a number of logical disks were to simultaneously exceed the threshold. Alternatively, if the current load is used, all invocations of the DSR policy might pick the same least loaded logical disk for replication and hence, result in eventual overload of the target logical disk. There are three additional criteria that the target logical disk need to satisfy. First, there must be at least one temporary inactive segment in the target logical disk on which a new replica can be created. Next, both the current read load and the future read load in one segment time on the target disk are checked to verify that they are below the corresponding loads for the source disk. In addition, the current total load on the target disk (read+write) has to be lower than a pre-de ned threshold called the write threshold, wth. This is to ensure that the policy does not attempt to replicate to a heavily-loaded target disk. The current read and write loads can be found in the disk record while the future load is estimated as before from the current load. Once a target logical disk has been found, the policy computes the payo pi for each inactive temporary segment and deletes the segment with the lowest payo.

5 Simulation Results In this section, we use simulation study to compare the eectiveness of the proposed policy to that of a policy based on static replication of the popular movies. The data rate is assumed to be MPEG-1 ( 192 KB/s) and the size of a movie is 1 GB (approximately 90 minutes of playback time). The simulated environment consists of 8 striping groups with each striping group supporting 127 viewers and 88 dierent movies stored in these groups. The movie access pattern is assumed to follow the empirical Zipf distribution as described in Section 2.1. Hence, the movies are allocated to the striping groups using the 13

following algorithm so as to attempt to balance the load evenly. The allocation process can be thought of as folding the frequency distribution curve. First, the eight movies with the highest access frequencies are assigned to the eight striping groups in ascending order. Then another eight movies with the next highest frequencies are assigned to the striping groups in descending order. The process is repeated until all the movies had been allocated. In addition, it is assumed that there is some extra space in the system (1 movie's worth of extra space in each striping group) so that 8 new movies can be stored. This amounts to 9% of the available space. Under the static policy, a second copy of the eight hottest movies are placed on the eight striping groups in descending order (so that dierent replicas of the same movie are on dierent groups). The extra space is used as free space under the DSR policy. An alternative simulation environment where some of disks are set aside as free space is also considered in Section 5.3. The replication and write thresholds (rth and wth) for the DSR policy is set to 90 and 120 streams, (i.e., 70% and 95% of the logical disk capacity) respectively. In general, the choice of these thresholds will depend on the the segment size (and hence, the segment replication time) and the number of streams each striping group can support. Therefore, these thresholds will be tunable parameters for speci c environments. A lower replication threshold causes the system to be overly responsive (even when it may not be necessary) while a higher threshold avoids unnecessary replication at the risk of load imbalance. From experiments, we observe that the above settings work rather well, and the results are not very sensitive to small changes to these parameters.

5.1 Comparison of Static Replication and DSR Policies Figure 7 compares the fractions of requests rejected due to overload under the static and the DSR policies. Each point in the gure corresponds to a run simulating 8 hours of playback time. Since each simulation run starts with an empty system, during the initial transition phase there are very few viewers in the system. Rejection occurs only after the 14

number of viewers in the system reaches disk capacity. We therefore, ignore the initial transient (1 hour 45 minutes) and start collecting rejection data from that time onwards. For both the policies, the rejection rate increases with the increase in the average number of active viewers, and hence, the increased load on all disks. The server load under a given arrival process is measured in terms of the number of concurrent viewers in a system where none of the requests are rejected. For any given server load, the DSR policy has a lower rejection rate than that of the static policy. Note that the DSR policy has a lower rejection rate even though the simulation is set up to favor the static policy by pre-replicating the hottest movies. In many environments, a system is con gured to handle dynamic load changes while satisfying certain performance objectives [17]. In the current environment, one such performance objective for con guring the server could be to contain the rejection rate below a certain threshold (say 1%). The horizontal dotted line represents a 1% rejection rate. If the server capacity is considered to be the load at which the rejection rate reaches 1%, it can be seen that the server capacity under the DSR policy is 955 whereas that under the static policy is 825. The DSR policy can thus support 16% more users without any additional space or bandwidth. In addition, the rejection rate under the DSR policy is virtually zero until the system is overloaded; after which the rejection rate increases sharply. This behavior is preferable to that of the static policy, where the rejection rate rises smoothly. We now explain the reasons for the dierence in the rejection rates under the two policies by taking a closer look at their behaviors. Figure 8 shows the activity on a heavily loaded disk under the static policy sampled every 5 minutes. The total server load is 890 which corresponds to the 2% rejection rate under the static policy in Figure 7. The disk load is measured as the number of concurrent streams on this disk. The horizontal dotted line at the top of the plot at 127 streams indicates the capacity of the logical disk. The three other curves shown are the disk load, the number of new requests for movies on that logical disk and the number of rejections due to disk overload. It can be seen from the 15

gure that under the static policy the disk load frequently becomes equal to the capacity of the logical disk. Whenever this happens, all new requests have to be rejected. After some time, when some of the current requests have terminated, it is possible to accept new requests and the number of rejections again becomes zero. The tapering o of the disk load at the end signi es ending of the simulation run, so that no new requests are generated. Figure 9 shows the corresponding plot for the DSR policy. The additional horizontal line at 90 streams is the threshold of the DSR policy. As mentioned earlier, the threshold is the load at which the DSR policy attempts to shift load o the disk by dynamically replicating some of the segments. In contrast to the static policy, the load on the disk under the DSR policy never reaches the capacity of the disk. Hence there are no rejections under the DSR policy. Figure 10 shows the corresponding copyback activity from this disk. The copyback enables the DSR policy to keep the load on this disk below threshold. As before, the data about the number of copyback streams from this disk are sampled at 5 minutes intervals. For reference, the disk load is also shown in this gure. As before, the two horizontal lines at 127 and 90 streams represent the capacity of the disk and the disk threshold. It can be seen that whenever the disk load exceeds the threshold, the DSR policy starts copyback streams that allow future load on the disk to be shifted. Note also that due to the limited replication space in other disks the same segment may be copied multiple times on demand basis. Hence, in the current simulation run, there is continuous copyback activity. Such repeated copyback will be avoided when the temporary segments are marked as permanent (and hence, can not be deleted) and other permanent segments can be marked temporary. This will be further explored in our future work.

16

5.2 Performance under Load Surge In a general environment, the load on a video server cannot be predicted exactly. Therefore, we consider the performance of both the policies in the presence of a load surge. The load surge is simulated by doubling the access rate to the most popular movie after the simulation had run for 4 hours. Figure 11 illustrates the dierence in rejection rate between the two policies. As before, the rejection rate of requests is plotted against the server load. Only the rejection rates after the load change are plotted. For reference, the rejection rate of the static policy with no load surge from gure 7 is also shown. As before, the rejection rate under the static policy is higher than that under the DSR policy. With the same amount of disk space and bandwidth, the DSR policy now supports 21% more users than the static policy. In addition, comparison of the rejection rates for the static policy with and without a load surge shows that the static policy performs substantially worse in the presence of unpredictable load. On the other hand, since the DSR policy reaches a 1% rejection rate with slightly less than 950 users, its performance is only slightly degraded. As before, the rejection rate of the DSR policy is virtually zero until the system capacity is reached.

5.3 Stress-tests In order to make a stress-test of the DSR policy, simulations are run with a large number of striping groups or logical disks (61). Each logical disk is assumed to be able to hold 2 GB or 2 movies. With a bandwidth of 3 MB/s, each disk is further assumed to be able to support 19 viewers at 192 KB/s. A dierent placement strategy than that used in the previous runs is used here. Of the 61 disks, 55 are assumed to be primary disks on which 110 movies are placed. In the runs with the static policy, the other 6 disks (representing approximately 10% of the bandwidth and storage) had copies of the 12 movies with the greatest access frequency. In the simulation runs, the DSR policy use these disks as free 17

space. Note that the current placement policy is bene cial for the static policy, since it would be dicult to distribute 10% extra space over the 55 striping groups in a way that can be used by the whole le replication method. With a large number of striping groups, it is dicult to balance the load across all disks. Under the earlier described empirical access frequency distribution, the performance of the static policy will be signi cantly worse since some of the popular movies need to be replicated many times even for a small server load. Hence, to reduce the disadvantages of the static policy a less skewed access frequency distribution is used here. The actual movie access distribution is derived by randomly choosing a value in the range (0:7=M; 1:3=M ) for each movie and normalizing the resulting distribution. Here, M is the number of movies in the system. Since 1=M is the access probability for all the movies under a uniform distribution, the above procedure is equivalent to superimposing a variation of 30% on a uniform distribution. Also, the ratio between the access frequencies of the most frequently accessed and least frequently accessed movie is less than 2 : 1. Figure 12 shows the eect of increasing server load on both the policies. The DSR policy again outperforms the static policy. Note also that the DSR policy performs quite well even with a large number of striping groups. Figures 13 and 14 show the disk load under the two policies on a heavily loaded disk. The horizontal line at 19 streams represents the capacity of the disk while the horizontal line at 14 streams is the threshold for the DSR policy. As before, the rejection rate is lower under the DSR policy since the DSR policy is able to shift some of the load. Examination of Figure 15 shows that this is because copyback streams are started whenever the disk load exceeds replication threshold.

18

6 Conclusions In an on-demand video server environment, resource reservation is necessary due to stringent response time requirements. Due to varying access patterns, there can be load imbalance among the various disks in the system. A possible solution to the problem of load imbalance is to stripe all the videos over all the disks. This solution has a number of limitations such as the diculty of striping together disks of dierent types eciently and the diculty of restoring a backup copy from tape. Such problems can be avoided if there are multiple striping groups. In addition, under a single striping group if a single disk in the system fails, all the videos in the system may become unavailable. Alternatively, if there are multiple striping groups, only the videos in the failed group become unavailable. Also, popular videos can be replicated to other striping groups in order to limit the loss of viewers. The number of popular videos that need to be replicated in order to achieve a certain availability (de ned as the percent of lost viewers) is smaller with a larger number of striping groups. This is because a smaller number of viewers is lost when a single disk fails. By examining the trade-os between availability, the number of striping groups and the number of replicated popular videos, we showed that high availability (10% lost viewers) with little replication overhead can be provided by a small number (4 to 8) of striping groups. The use of multiple striping groups makes it necessary to deal with the problem of load imbalance among multiple striping groups. In this paper, a dynamic segment replication policy that treats each striping group as a single large logical disk is proposed. It partitions the video les into a small number of segments and dynamically replicates these segments in order to balance the load. If say 8 segments per video are used, the segment copying time is much lower than the time needed to replicate the entire video. Thus the proposed policy is very responsive to load changes. By replicating dierent segments to dierent striping groups, the eect of hierarchical striping of videos can be 19

achieved. At the top level, the segments are distributed over logical disks, and at the lower level, each segment is striped over the physical disks comprising a logical disk. Since the policy replicates only portions of videos as needed, it is more ecient in the use of space than a whole- le replication policy. The DSR policy was compared to the policy of static replication of the popular videos. The policies were compared under unchanging skewed load, sudden load change and a stress-test for the DSR policy. Under unchanging load, it was shown that even with a small number of striping groups the DSR policy could support signi cantly more streams than the static policy using the same number of disks. The capacity of the system was de ned as the number of streams that could be supported with a given rejection rate due to disk overload. In addition, the DSR rejection rate is zero until close to the system capacity and then rises sharply whereas the rejection rate for the static policy is nonzero for a server load well below the system capacity. Thus the DSR policy has superior performance characteristics as well. Next, the policies were compared in the presence of a sudden load change to see if the DSR policy could cope with sudden shifts in access patterns. The results showed that the performance of the DSR policy was almost unchanged whereas the performance of the static policy was signi cantly degraded due to its inability to adapt to the changing load. Finally, a stress test with a large number of striping groups and a more uniform access distribution was carried out. The DSR policy was again shown to be superior.

References [1] Anderson, D. P., \Metascheduling for Continuous Media," ACM Transactions on Computer Systems, Vol. 11, No. 3, August 1993, pp. 226{252. [2] Berson, S., L. Golubchik, and R. R. Muntz, \A Fault-Tolerant Design of a Multimedia Server", UCLA Tech. Report CSA-940009, Feb. 1994. [3] Dan, A., and D. Sitaram, \Buer Management Policy for an On-Demand Video Server", IBM Research Report RC 19347, Yorktown Heights, NY, 1994.

20

[4] Dan, A., D. Sitaram and P. Shahabuddin, \Scheduling Policies for an On-Demand Video Server with Batching", IBM Research Report RC 19381, Yorktown Heights, NY, 1994. [5] Dan, A., P. Shahabuddin, D. Sitaram and D. Towsley, \Channel Allocation under Batching and VCR Control in Movie-On-Demand Servers", IBM Research Report RC 19588, Yorktown Heights, NY, 1994. [6] Dan, A., M. Kienzle, D. Sitaram and P. S. Yu, \Improvement of Load-Balancing in Multimedia Servers by Partial File Replication", IBM Research Report in preperation. [7] Dan, A., M. Kienzle, D. Sitaram and P. S. Yu, \Improvement of Load Balancing in a File Server through Dynamic Replication of Data Objects", U. S. Patent Y0993-078 [8] Electronic Engineering Times, March 15, 1993, pp 72. [9] Fox, E. A., \The Coming Revolution in Interactive Digital Video," Communication of the ACM, Vol. 7, July 1989, pp. 794{801. [10] Liskov, B., et. al., \Replication in the Harp File System", ACM Symp. on Operating Systems Principles, 1991, pp. 226-238. [11] Livny, M., S. Khosha an, H. Boral, \Multi-Disk Management Algorithms", Performance Evaluation Review, Vol. 15, May 1987, pp. 69{77. [12] Rangan, P. V., H. M. Vin, and S. Ramanathan, \Designing an On-Demand Multimedia Service," IEEE Communication Magazine, Vol. 30, July 1992, pp. 56{65. [13] Satyanarayanan, M., et. al., \Coda: A Highly Available File System for a Distributed Workstation Environment", IEEE Trans. on Computers, Special Issue on Fault-Tolerant Computing, April 1990. [14] Sincoskie, W. D., \System Architecture for a Large Scale Video On Demand Service," Computer Networks and ISDN System, Vol. 22, 1991, pp. 155{162. [15] Sitaram, D., A. Dan, and P. Yu, \Issues in the Design of Multi-Server File Systems to Cope with Load Skew", Second International Conference on Parallel and Distributed Information Systems, January 1993. [16] Video Store Magazine, Dec. 13, 1992. [17] Yu, P. and A. Dan. \Performance Evaluation of Transaction Processing Coupling Architectures for handling System Dynamics", IEEE Trans. on Parallel and Distributed Systems, Vol. 5, Feb. 1994, pp. 139{153.

21

Disk Free Inactive Active Total Seg. Read Id Seg. Seg. Count Count Count Load D1 10 15 30 60 D2 5 20 35 75

Video Server

D1 1

1

1

2 2

D11

D12

2 0

Disk Table

D2 2

Total Pointer to Write Load Disk Segment Table

6

6

7

2

7

7

4

4

5

Disk Seg. Video Id Number

D13

Video Seg. Number of Read Str. Number

Primary Copyback Flag Flag

1

Movie 1

4

10

1

0

2

Movie 2

2

50

0

1

3

Movie 2

6

15

0

0

Disk Segment Table

Figure 1: Dynamic replication overview S

S 11

S

12

Figure 4: Disk data structures

S 16 S 17

15

Movie 1 M 11

M13

M12

M14 S 24

S 22

S 21

Movie 2 M 23

M 24

Figure 2: Example disk load Video Id

Pointer to Video Segment Table

Segment Count

Movie 1 Movie 2

Figure 5: Availability requirements

7 5 Video Table

Segment Number

Number of Read Streams

Number of Replicas

1

30

3

D1 D2 D4

2

20

3

D1 D3 D5

3

15

1

D1

Disk Ids of Replicas

Video Segment Table

Figure 3: Video data structures

Figure 6: Eect of number of striping groups 22

Figure 10: Copyback Streams

Figure 7: Static vs Dynamic Policy, no load

change

Figure 8: Disk Load under Static Policy

Figure 11: Static vs Dynamic policy, load

surge.

Figure 12: Static vs Dynamic policy, nonFigure 9: Disk Load under Dynamic Policy empirical distribution 23

Figure 13: Activity of loaded disk, static policy

Figure 14: Activity of loaded disk, dynamic

policy

Figure 15: Copyback streams, non-empirical distribution

24