DOC PREVIEW
On Object Maintenance in Peer-to-Peer Systems

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

On Object Maintenance in Peer-to-Peer SystemsKiran Tati and Geoffrey M. VoelkerDepartment of Computer Science and EngineeringUniversity of California, San Diego1. INTRODUCTIONStorageis often a fundamentalservice providedbypeer-to-peer systems, where the system stores data objects on behalfof higher-level services, applications, and users. A primarychallenge in peer-to-peer storage systems is to efficientlymaintain object availability and reliability in the face of nodechurn. Nodes in peer-to-peer systems exhibitbothtemporaryand permanent failures, requiring the use of redundancy tomask and cope with such failures (e.g., [1, 4, 10, 16, 21]).The cost of redundancy, however, is additional storage andbandwidth for creating and repairing stored data.Since bandwidth is typically a much more scarce resourcethan storage in peer-to-peersystems, strategies for efficientlymaintaining objects focus on reducing the bandwidth over-head of managing redundancy,trading off storage as a result.Typically, these strategiescreateredundantversionsofobjectdata using either replication or erasure coding as redundancymechanisms, and either react to node failures immediatelyor lazily as a repair policy.In this paper, we revisit object maintenance in peer-to-peersystems, focusing on how temporary and permanent churnimpact the overheads associated with object maintenance.We have a number of goals: to highlight how different en-vironments exhibit different degrees of temporary and per-manent churn; to provide further insight into how churn indifferent environments affects the tuning of object mainte-nancestrategies; and to examinehow object maintenanceandchurn interact with other constraintssuch as storage capacity.When possible, we highlight behavior independent of partic-ular object maintenance strategies. When an issue dependson a particular strategy, though, we explore it in the contextof a strategy in essence similar to TotalRecall [4], whichuses erasure coding, lazy repair of data blocks, and randomindirect placement (we also assume that repairs incorporateremaining blocks rather than regenerating redundancy fromscratch).1Overall, we emphasize that the degrees of both tempo-rary and permanent churn depend heavily on the environ-ment of the hosts comprising the system. Previous workhas highlighted how ranges of churn affect object lookupalgorithms [14]; in this paper, we explore how these differ-ences impact the source of overheads for object maintenancestrategies. Inenvironments with lowpermanentchurn,objectmaintenance strategies incur much of their overhead wheninitially storing object data to account for temporary churn.In environments with high permanent churn, however, object1We choose one strategy to be illustrative more than to advocate aparticular approach, and choose this strategy because of familiarity;the tradeoffs between replication and erasure coding, for example,have been well studied [2, 5, 12,15,19], and each has its strengthsand weaknesses.maintenance strategies incur most of their overhead dealingwithrepairs—even if the system experiences high temporarychurn. Finally, we highlight additional practical issues thatobject maintenance strategies must face, in particular deal-ing with storage capacity constraints. Random placement,for example, unbalances storage load in proportion to thedistribution of node uptimes, with both positive and negativeconsequences.2. CHURNPeer-to-peersystems experiencechurnas a result of a com-bination of temporary and permanent failures. A temporaryfailure occurs when a node departs the system for a periodof time and then comes back. Any data stored on the nodebecomes unavailable during this period, but is not perma-nently lost. Examples of temporary failures are when homeusers login to systems in the evening, or when business usersuse systems during the day but logoff overnight. A perma-nent failure corresponds to a loss of data on a node, suchas when a disk or machine fails, or when a user leaves afile sharing system permanently. Temporaryfailures directlyimpact availability, and permanent failures directly impactreliability.The degrees of both temporary and permanent churn de-pend heavily on the environment of the hosts comprising thesystem. Systems incorporatinghome and business hosts tendto experience much higher levels of churn than systems in-corporating server hosts maintained in machine rooms. Forexample, Table 1 illustrates the churn characteristics takenfrom traces of three different host populations, the Overnetfile sharing system [3], the PlanetLab testbed [17], and hostsin a large corporation [6].The observation that different environments experiencedifferent degrees of churn is not new, although character-izations of churn tend to focus just on temporary churn(e.g., [14]). Characterizing permanent churn in deployedsystems remains an open question, in part because doingso requires long-term measurement as well as assumptionsabout node behavior; deciding that a node has left perma-nently within a finite trace essentially requires a thresholdfor assuming that observing that a node has left the systemmeans that it has left permanently. For the Overnet trace, weconsider host departures where the host leaves for more thansix days a permanent failure; all other host departures aretemporary failures. Given the short period of the trace, usinga larger threshold would result in little permanent churn. Asa result, we considerthis thresholdan upper bound on perma-nent churn for this population. For the PlanetLab trace, weconsider host departures where the host leaves for more thanthirty days a permanent failure; all other host departures aretemporary failures. For the FarSite study, we use numbersSystem Start Date DurationTotal Ave Nodes Temporary Failures Permanent FailuresNodes Per Day Total Per Day (Host) Total Per Day (Host)Overnet Jan 15th, 03 7 days 1469 1028 33084 4736 (4.61) 107 107 (0.104)PlanetLab Apr 1st, 04 406 days 655 318 13633 34 (0.11) 593 1.6 (0.005)FarSite July 1st, 99 35 days 60000 45000 87500 2500 (0.05) 7000 200 (0.004)Table 1: Churn in representative systems. 0 20 40 60 80 100 0 20 40 60 80 100 120 140 160Percentage of NodesTime (in Hours)OverNetPlanetLabFigure 1: Tracking node availability among a set of nodes overtime. The monitored set of nodes are those nodes that were inthe system at 24 hours into the trace.reported in the paper.Comparing the churn in the different environments, wesee that the environments have very


On Object Maintenance in Peer-to-Peer Systems

Download On Object Maintenance in Peer-to-Peer Systems
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view On Object Maintenance in Peer-to-Peer Systems and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view On Object Maintenance in Peer-to-Peer Systems 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?