on utilization of contributory on utilization of
play

On Utilization of Contributory On Utilization of Contributory - PowerPoint PPT Presentation

On Utilization of Contributory On Utilization of Contributory Storage in Desktop Grids Storage in Desktop Grids Chreston Miller , Ali R. Butt, and Patrick Butler Department of Computer Science Contributory Storage: Cheap Contributory Storage:


  1. On Utilization of Contributory On Utilization of Contributory Storage in Desktop Grids Storage in Desktop Grids Chreston Miller , Ali R. Butt, and Patrick Butler Department of Computer Science

  2. Contributory Storage: Cheap Contributory Storage: Cheap Storage using Shared Resources Storage using Shared Resources • Distributed setup with many participants • Nodes contribute storage space for sharing • Create a uniform global storage space • Typically supports decentralized store/lookup • Many systems build upon this idea • PAST, CFS, OceanStore, Kosha, LOCKSS,… 2 2

  3. Goal: Use of Contributory Storage Goal: Use of Contributory Storage in Scientific Computing in Scientific Computing • Advantages: • Provides economical storage with large capacity • Supports parallel access to distributed resources • Challenges: • Limited individual file sizes • Unreliable and transient participants  Simple replication or file splitting is likely not to work Need for techniques to use shared storage in scientific computing 3 3

  4. Our Contribution: PeerStripe Our Contribution: PeerStripe Reliable Shared Storage Reliable Shared Storage • Utilizes storage contributed by peer nodes • Adapts data striping to support large files • Employs error coding for fault tolerance • Leverages multicast for efficient replication • Supports easy integration with applications 4 4

  5. Outline Outline • Preamble • End to our Means • Evaluation Study • Conclusion 5 5

  6. Outline Outline • Preamble – Problem – Motivation • End to our Means – Our Contributions – Core Technologies • Evaluation Study • Conclusion 6 6

  7. Core Technologies: Core Technologies: Structured Peer-to-Peer Structured Peer-to-Peer Networks Networks • Implement Distributed Hash Table abstraction • Facilitate decentralized operation • Provide self-organization of participants • Systems based on these networks provide: • Mobility and location transparency • Load-balancing • We use Free Pastry substrate from Rice University and Microsoft 7 7

  8. Core Technologies: Core Technologies: Increasing Data Availability Increasing Data Availability • Erasure codes • Provide redundancy against failures • Incur less space overhead than replication • Advanced codes can withstand multiple failures • Multicast communication protocol • Supports simultaneous messaging to many nodes • Can be leveraged for efficient replication 8 8

  9. Outline Outline • Preamble – Software Architecture – Splitting a file • End to our Means – Redundancy with multicast – Error coding – Interfacing with applications • Experimental Study • Conclusion 9 9

  10. PeerStripe Software Tasks PeerStripe Software Tasks 1. Storing large files • Split file into different size chunks • Use DHT’s to store chunks 2. Error coding chunks • Use online code to provide redundancy 3. Chunk replication • Replicate commonly used chunks 4. Interface with applications • Provide API’s for applications to use 10 10

  11. Part 1: Splitting Files into Chunks Part 1: Splitting Files into Chunks Get capacity from nodes Data File m blocks/chunk Chunk 1 Splitter Encoder n blocks /chunk Nodes x x*m error coded Chunks blocks 11 11

  12. Part 2: Error Coding Chunks Part 2: Error Coding Chunks • Each chunk is separately error coded 1. A chunk is split into equal n size blocks 2. The blocks are error coded into m encoded blocks 3. Encoded blocks are inserted into the DHT 2 1 3 QuickTime™ and a decompressor are needed to see this picture. 12 12

  13. Investigation of Error Codes Investigation of Error Codes • Error codes tested and used: • XOR code: Protect against single failures • Online code: Protect against multiple failures + Good redundancy with small space overhead - Recovery may consume resources 13

  14. Part 3: Multicast-based Part 3: Multicast-based Replication Replication • Leverage multicast for efficient and fast data dissemination to multiple destinations • Faster recovery at the cost of space • Challenge: Creation of a multicast-tree from source to replica destinations 14 14

  15. Creating a Multicast Tree Creating a Multicast Tree S • Use greedy approach • Start from the source S • Using locality-aware DHT select random nodes close to S as first tier • Repeat selecting at each tier till replica location R is reached • Employ standard R R R R R R R R multicast protocols, e.g. Bullet to push data from S to R 15 15

  16. Part 4: Interfacing with Part 4: Interfacing with Applications Applications • Modify applications to use direct calls to the PeerStripe API • Works well for new applications • Link applications with an interposing library to redirect I/O • Transparent integration with existing applications 16 16

  17. Outline Outline • Begin to our Means – Simulation – Real world • End to our Means – PlanetLab – Condor • Evaluation Study • Conclusion 17 17

  18. Evaluation: Overview Evaluation: Overview 1. Simulation study: • Successful File Stores • Number and size of chunks created • System utilization (in terms of storage capacity) • File availability with error coding • Error code performance • Effects of participant churn 2. Design verification on PlanetLab 3. Integration with Condor desktop grid 18 18

  19. Simulation Study Setup Simulation Study Setup • 10,000-node directly connected network • Assigned node capacities with mean 45 GB and variance 10 GB • File system trace of 1.2M files totaling 278.7 TB • Compare with PAST and CFS storage systems 19 19

  20. Number of Successful File Stores Number of Successful File Stores • 7.0x improvement over PAST • 2.9x improvement over CFS 20 20

  21. Number and Size of Chunks Number and Size of Chunks • CFS: 61.25 chunks with stdev of 13.8 • Fixed chunk size of 4 MB • PeerStripe: 3.72 chunks with stdev of 3.1 • Average chunk size 81.28 MB with stdev 19.9 MB  Fewer chunks in PeerStripe allows • Fewer expensive p2p lookups • Performance similar to PAST 21 21

  22. Overall System Capacity Overall System Capacity Utilization Utilization • PeerStripe: 20.19% better than PAST • PeerStripe: 7.18% better than CFS • PeerStripe can utilize the available storage capacity more efficiently even at higher utilization 22 22

  23. Error Coding: File Availability Error Coding: File Availability • XOR code - 23% less failures • Online code - 32% less failures • Online code provides excellent fault tolerance against node failures 23 23

  24. Error Coding Performance Error Coding Performance • Compare XOR (1:1) and Online code with NULL code Erasure Encoded size Encoding time code Size(MB) Overhead Time Overhead Null 4 0% 11 0% XOR 6 50% 79 618% Online 4.12 3% 264 2300% • XOR - factor of 3.3 times faster than online codes • Online code - slower than XOR, • Decoding can start as soon as a block becomes available and can be overlapped with retrieval of other blocks • The efficiency of online code overshadows its overhead 24 24

  25. Effects of Participant Churn Effects of Participant Churn • Failed up to 20% of total nodes Nodes failed Data lost Data regenerated (percentage Total Total Average Sd of total) (GB) (GB) (GB) (GB) 10 percent 0 28044.35 28.04 79.85 20 percent 142.18 58625.78 29.31 80.02 • 29.3 GB of data was regenerated per node failure • Total of 58,625.8 GB regenerated • 142.2 GB data was lost which is small compared to the 278.7 TB of total data • The data recreated per failure is small: 0.01% 25 25

  26. Verification on PlanetLab Verification on PlanetLab • 40 different distributed sites • Number of failed stores reduced by 330% w.r.t. PAST 105% w.r.t. CFS • Storage utilization: CFS 52%, PAST - 47%, PeerStripe - 63% • Online codes provided 98.6% availability through four node failures 26 26

  27. Interfacing with Condor Interfacing with Condor • Utilize a 32-node Condor pool • CFS and PeerStripe worked for smaller files • DHT lookups introduced an overhead - few for PeerStripe • Overhead for PeerStripe is small QuickTime™ and a decompressor are needed to see this picture. 27 27

  28. Outline Outline • Begin to our Means • End to our Means • Experimental Study • Conclusion 28 28

  29. Conclusion Conclusion • P2p-based storage can be extended with erasure coding and striping to provide robust, scalable, and reliable distributed storage for scientific computing. • PeerStripe achieves better utilization of collective capacity of nodes with good performance • Error coding is effective in providing fault tolerance and data availability • Multicast can be used for replica maintenance • Use of interposing library allows easy integration with new and existing applications 29 29

  30. Questions? Questions? • chmille3@cs.vt.edu • butta@cs.vt.edu • http://research.cs.vt.edu/dssl/ 30 30

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend