Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
NFSv4 Replication for Grid Computing Peter Honeyman Center for Information Technology Integration University of Michigan, ...
Acknowledgements <ul><li>Joint work with Jiaying Zhang </li></ul><ul><ul><li>UM CSE doctoral candidate </li></ul></ul><ul>...
Outline <ul><li>Background </li></ul><ul><li>Consistent replication </li></ul><ul><ul><li>Fine-grained replication control...
Grid computing <ul><li>Emerging global scientific collaborations require access to widely distributed data that is reliabl...
GridFTP <ul><li>Advantages </li></ul><ul><ul><li>Automatic negotiation of TCP options </li></ul></ul><ul><ul><li>Parallel ...
NFSv4 <ul><li>Advantages </li></ul><ul><ul><li>Traditional, well-understood file system semantics </li></ul></ul><ul><ul><...
NFSv4.r <ul><li>Research prototype developed at CITI </li></ul><ul><li>Replicated file system build on NFSv4 </li></ul><ul...
Replication in practice <ul><li>Read-only replication </li></ul><ul><ul><li>Clumsy manual release model </li></ul></ul><ul...
Consistent replication <ul><li>Problem: state of the practice in file system replication  does not  satisfy the requiremen...
Design principles <ul><li>Optimal read-only behavior </li></ul><ul><ul><li>Performance must be identical to un-replicated ...
Replication control client When a client opens a file for writing, the selected server temporarily becomes the primary for...
Replication control client The primary server asynchronously distributes updates to other servers during file modification...
Replication control client When the file is closed and all replication servers are synchronized, the primary server notifi...
Directory updates <ul><li>Prohibit concurrent updates </li></ul><ul><ul><li>A replication server waits for the primary to ...
Close-to-open semantics <ul><li>Server becomes primary after it collects votes from a  majority  of replication servers </...
Durability guarantee <ul><li>“ Active view” update policy </li></ul><ul><ul><li>Every server keeps track of the liveness o...
What I skipped <ul><li>Not the Right Stuff </li></ul><ul><ul><li>GridFTP: manual synchronization </li></ul></ul><ul><ul><l...
NFSv4.r in brief <ul><li>View-based replication control protocol </li></ul><ul><ul><li>Based on (provably correct) El-Abba...
Write-mostly WAN performance <ul><li>Durability overhead </li></ul><ul><ul><li>Synchronous updates </li></ul></ul><ul><li>...
Asynchronous updates <ul><li>Consensus requirement delays client updates </li></ul><ul><ul><li>Median RTT between the prim...
Hierarchical replication control <ul><li>Synchronization is costly over WAN </li></ul><ul><li>Hierarchical replication con...
Shallow & deep control /usr bin local /usr bin local A server with a  shallow control  on a file or directory is the prima...
Primary server election <ul><li>Allow deep control for a directory  D  if  D  has no descendent is controlled by another s...
Ancestry table /root a b c f2 d2 controlled by S1 controlled by S0 controlled by S0 controlled by S2 …… Ancestry Table The...
Primary election <ul><li>S0 and S1 succeed in their primary server elections </li></ul><ul><li>S2’s election fails due to ...
Performance vs. concurrency <ul><li>Associate a timer with deep control </li></ul><ul><ul><li>Reset the timer with subsequ...
Performance vs. concurrency <ul><li>Increase concurrency when the system consists of multiple writers </li></ul><ul><ul><l...
Single remote NFS N.B.: log scale
Deep vs. shallow Shallow controls vs. deep + shallow controls
Deep control timer
Durability revisited <ul><li>Synchronization is expensive, but … </li></ul><ul><li>When we abandon the durability guarante...
Utilization tradeoffs <ul><li>Adding synchronous replication servers enhances durability </li></ul><ul><ul><li>Which reduc...
Placement tradeoffs <ul><li>Nearby replication servers reduce the replication penalty </li></ul><ul><ul><li>Which benefits...
Run-time model
Parameters <ul><li>F: failure free, single server run time </li></ul><ul><li>C: replication overhead </li></ul><ul><li>R: ...
F: run time <ul><li>Failure-free, single server run time </li></ul><ul><li>Can be estimated or measured </li></ul><ul><li>...
C: replication overhead <ul><li>Penalty associated with replication to backup servers </li></ul><ul><li>Proportional to RT...
R: recovery time <ul><li>Time to detect failure of the primary server and switch to a backup server </li></ul><ul><li>We a...
Failure distributions <ul><li>Estimated by analyzing PlanetLab ping data </li></ul><ul><ul><li>716 nodes, 349 sites, 25 co...
PlanetLab failure CDF
Same-site correlated failures sites nodes 11 21 65 259 0.488 5 0.488 0.378 4 0.538 0.440 0.546 3 0.561 0.552 0.593 0.526 2
Different-site correlated failures
Run-time model <ul><li>Discrete event simulation yields expected run time E and utilization (F ÷ E) </li></ul>
Simulated utilization F = one hour One backup server Four backup servers
Simulation results F = one day One backup server Four backup servers
Simulation results F = ten days One backup server Four backup servers
Simulation results discussion <ul><li>For long-running jobs </li></ul><ul><ul><li>Replication improves utilization </li></...
Checkpoint interval F = one day One backup server 20% checkpoint overhead F = ten days, 2% checkpoint overhead One backup ...
Next steps <ul><li>Checkpoint overhead? </li></ul><ul><li>Replication overhead? </li></ul><ul><ul><li>Depends on amount of...
Conclusions <ul><li>Conventional wisdom holds that consistent   mutable   replication   in large-scale distributed systems...
Conclusions <ul><li>Consistent replication in large-scale distributed storage systems is  feasible  and  practical </li></...
Thank you for your attention! www.citi.umich.edu Questions?
Nächste SlideShare
Wird geladen in …5
×

von

NFSv4 Replication for Grid Computing Slide 1 NFSv4 Replication for Grid Computing Slide 2 NFSv4 Replication for Grid Computing Slide 3 NFSv4 Replication for Grid Computing Slide 4 NFSv4 Replication for Grid Computing Slide 5 NFSv4 Replication for Grid Computing Slide 6 NFSv4 Replication for Grid Computing Slide 7 NFSv4 Replication for Grid Computing Slide 8 NFSv4 Replication for Grid Computing Slide 9 NFSv4 Replication for Grid Computing Slide 10 NFSv4 Replication for Grid Computing Slide 11 NFSv4 Replication for Grid Computing Slide 12 NFSv4 Replication for Grid Computing Slide 13 NFSv4 Replication for Grid Computing Slide 14 NFSv4 Replication for Grid Computing Slide 15 NFSv4 Replication for Grid Computing Slide 16 NFSv4 Replication for Grid Computing Slide 17 NFSv4 Replication for Grid Computing Slide 18 NFSv4 Replication for Grid Computing Slide 19 NFSv4 Replication for Grid Computing Slide 20 NFSv4 Replication for Grid Computing Slide 21 NFSv4 Replication for Grid Computing Slide 22 NFSv4 Replication for Grid Computing Slide 23 NFSv4 Replication for Grid Computing Slide 24 NFSv4 Replication for Grid Computing Slide 25 NFSv4 Replication for Grid Computing Slide 26 NFSv4 Replication for Grid Computing Slide 27 NFSv4 Replication for Grid Computing Slide 28 NFSv4 Replication for Grid Computing Slide 29 NFSv4 Replication for Grid Computing Slide 30 NFSv4 Replication for Grid Computing Slide 31 NFSv4 Replication for Grid Computing Slide 32 NFSv4 Replication for Grid Computing Slide 33 NFSv4 Replication for Grid Computing Slide 34 NFSv4 Replication for Grid Computing Slide 35 NFSv4 Replication for Grid Computing Slide 36 NFSv4 Replication for Grid Computing Slide 37 NFSv4 Replication for Grid Computing Slide 38 NFSv4 Replication for Grid Computing Slide 39 NFSv4 Replication for Grid Computing Slide 40 NFSv4 Replication for Grid Computing Slide 41 NFSv4 Replication for Grid Computing Slide 42 NFSv4 Replication for Grid Computing Slide 43 NFSv4 Replication for Grid Computing Slide 44 NFSv4 Replication for Grid Computing Slide 45 NFSv4 Replication for Grid Computing Slide 46 NFSv4 Replication for Grid Computing Slide 47 NFSv4 Replication for Grid Computing Slide 48 NFSv4 Replication for Grid Computing Slide 49 NFSv4 Replication for Grid Computing Slide 50 NFSv4 Replication for Grid Computing Slide 51 NFSv4 Replication for Grid Computing Slide 52
Nächste SlideShare
Performance comparison of Distributed File Systems on 1Gbit networks
Weiter
Herunterladen, um offline zu lesen und im Vollbildmodus anzuzeigen.

0 Gefällt mir

Teilen

Herunterladen, um offline zu lesen

NFSv4 Replication for Grid Computing

Herunterladen, um offline zu lesen

We develop a consistent mutable replication extension for NFSv4 tuned to meet the rigorous demands of large-scale data sharing in global collaborations. The system uses a hierarchical replication control protocol that dynamically elects a primary server at various granularities. Experimental evaluation indicates a substantial performance advantage over a single server system. With the introduction of the hierarchical replication control, the overhead of replication is negligible even when applications mostly write and replication servers are widely distributed.

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen
  • Gehören Sie zu den Ersten, denen das gefällt!

NFSv4 Replication for Grid Computing

  1. 1. NFSv4 Replication for Grid Computing Peter Honeyman Center for Information Technology Integration University of Michigan, Ann Arbor
  2. 2. Acknowledgements <ul><li>Joint work with Jiaying Zhang </li></ul><ul><ul><li>UM CSE doctoral candidate </li></ul></ul><ul><ul><li>Defending later this month </li></ul></ul><ul><li>Partially supported by </li></ul><ul><ul><li>NSF/NMI GridNFS </li></ul></ul><ul><ul><li>DOE/SciDAC Petascale Data Storage Institute </li></ul></ul><ul><ul><li>Network Appliance, Inc. </li></ul></ul><ul><ul><li>IBM ARC </li></ul></ul>
  3. 3. Outline <ul><li>Background </li></ul><ul><li>Consistent replication </li></ul><ul><ul><li>Fine-grained replication control </li></ul></ul><ul><ul><li>Hierarchical replication control </li></ul></ul><ul><li>Evaluation </li></ul><ul><li>Durability revisited NEW! </li></ul><ul><li>Conclusion </li></ul>SKIP SKIP SKIP SKIP SKIP SKIP SKIP SKIP
  4. 4. Grid computing <ul><li>Emerging global scientific collaborations require access to widely distributed data that is reliable, efficient, and convenient </li></ul>SKIP SKIP SKIP Grid Computing
  5. 5. GridFTP <ul><li>Advantages </li></ul><ul><ul><li>Automatic negotiation of TCP options </li></ul></ul><ul><ul><li>Parallel data transfer </li></ul></ul><ul><ul><li>Integrated Grid security </li></ul></ul><ul><ul><li>Easy to install and support across a broad range of platforms </li></ul></ul><ul><li>Drawbacks </li></ul><ul><ul><li>Data sharing requires manual synchronization </li></ul></ul>SKIP SKIP SKIP
  6. 6. NFSv4 <ul><li>Advantages </li></ul><ul><ul><li>Traditional, well-understood file system semantics </li></ul></ul><ul><ul><li>Supports multiple security mechanisms </li></ul></ul><ul><ul><li>Close-to-open consistency </li></ul></ul><ul><ul><ul><li>Reader is is guaranteed to see data written by the last writer to close the file </li></ul></ul></ul><ul><li>Drawbacks </li></ul><ul><ul><li>Wide-area performance </li></ul></ul>SKIP SKIP SKIP
  7. 7. NFSv4.r <ul><li>Research prototype developed at CITI </li></ul><ul><li>Replicated file system build on NFSv4 </li></ul><ul><li>Server-to-server replication control protocol </li></ul><ul><li>High performance data access </li></ul><ul><li>Conventional file system semantics </li></ul>SKIP SKIP SKIP
  8. 8. Replication in practice <ul><li>Read-only replication </li></ul><ul><ul><li>Clumsy manual release model </li></ul></ul><ul><ul><li>Lacks complex data sharing (concurrent writes) </li></ul></ul><ul><li>Optimistic replication </li></ul><ul><ul><li>Inconsistent consistency </li></ul></ul>SKIP SKIP SKIP
  9. 9. Consistent replication <ul><li>Problem: state of the practice in file system replication does not satisfy the requirements of global scientific collaborations </li></ul><ul><li>How can we provide Grid applications efficient and reliable data access? </li></ul><ul><li>Consistent replication </li></ul>SKIP SKIP SKIP
  10. 10. Design principles <ul><li>Optimal read-only behavior </li></ul><ul><ul><li>Performance must be identical to un-replicated local system </li></ul></ul><ul><li>Concurrent write behavior </li></ul><ul><ul><li>Ordered writes, i.e., one-copy serializability </li></ul></ul><ul><ul><li>Close-to-open semantics </li></ul></ul><ul><li>Fine-grained replication control </li></ul><ul><ul><li>The granularity of replication control is a single file or directory </li></ul></ul>SKIP SKIP SKIP
  11. 11. Replication control client When a client opens a file for writing, the selected server temporarily becomes the primary for that file Other replication servers are instructed to forward client requests for that file to the primary if concurrent writes occur SKIP SKIP SKIP wopen
  12. 12. Replication control client The primary server asynchronously distributes updates to other servers during file modification SKIP SKIP SKIP write
  13. 13. Replication control client When the file is closed and all replication servers are synchronized, the primary server notifies the other replication servers that it is no longer the primary server for the file SKIP SKIP SKIP close
  14. 14. Directory updates <ul><li>Prohibit concurrent updates </li></ul><ul><ul><li>A replication server waits for the primary to relinquish its role </li></ul></ul><ul><li>Atomicity for updates that involve multiple objects (e.g. rename) </li></ul><ul><ul><li>A server must become primary for all objects </li></ul></ul><ul><ul><li>Updates are grouped and processed together </li></ul></ul>SKIP SKIP SKIP
  15. 15. Close-to-open semantics <ul><li>Server becomes primary after it collects votes from a majority of replication servers </li></ul><ul><ul><li>Use a majority consensus algorithm </li></ul></ul><ul><ul><li>Cost is dominated by the median RTT from the primary server to other replication servers </li></ul></ul><ul><li>Primary server must ensure that every replication server has acknowledged its election when a written file is closed </li></ul><ul><ul><li>Guarantees close-to-open semantics </li></ul></ul><ul><ul><li>Heuristic: allow a new file to inherit the primary server that controls its parent directory for file creation </li></ul></ul>SKIP SKIP SKIP
  16. 16. Durability guarantee <ul><li>“ Active view” update policy </li></ul><ul><ul><li>Every server keeps track of the liveness of other servers (active view) </li></ul></ul><ul><ul><li>Primary server removes from its active view any server that fails to respond to its request </li></ul></ul><ul><ul><li>Primary server distributes updates synchronously and in parallel </li></ul></ul><ul><ul><li>Primary server acknowledges a client write after a majority of replication servers reply </li></ul></ul><ul><ul><li>Primary sends other servers its active view with file close </li></ul></ul><ul><ul><li>A failed replication server must synchronize with the up-to-date copy before it can rejoin the active group </li></ul></ul><ul><ul><ul><li>I suppose this is expensive </li></ul></ul></ul>SKIP SKIP SKIP
  17. 17. What I skipped <ul><li>Not the Right Stuff </li></ul><ul><ul><li>GridFTP: manual synchronization </li></ul></ul><ul><ul><li>NFSv4.r: write-mostly WAN performance </li></ul></ul><ul><ul><li>AFS, Coda, et al.: sharing semantics </li></ul></ul><ul><li>Consistent replication for Grid computing </li></ul><ul><ul><li>Ordered writes too weak </li></ul></ul><ul><ul><li>Strict consistency too strong </li></ul></ul><ul><ul><li>Open-to-close just right </li></ul></ul>
  18. 18. NFSv4.r in brief <ul><li>View-based replication control protocol </li></ul><ul><ul><li>Based on (provably correct) El-Abbadi, Skeen, and Cristian </li></ul></ul><ul><li>Dynamic election of primary server </li></ul><ul><ul><li>At the granularity of a single file or directory </li></ul></ul><ul><ul><li>Majority consensus on open (for synchronization) </li></ul></ul><ul><li>Synchronous updates to a majority (for durability) </li></ul><ul><li>Total consensus on close (for close-to-open) </li></ul>
  19. 19. Write-mostly WAN performance <ul><li>Durability overhead </li></ul><ul><ul><li>Synchronous updates </li></ul></ul><ul><li>Synchronization overhead </li></ul><ul><ul><li>Consensus management </li></ul></ul>
  20. 20. Asynchronous updates <ul><li>Consensus requirement delays client updates </li></ul><ul><ul><li>Median RTT between the primary server and other replication servers is costly </li></ul></ul><ul><ul><li>Synchronous write performance is worse </li></ul></ul><ul><li>Solution: asynchronous update </li></ul><ul><ul><li>Let application decide whether to wait for server recovery or regenerate the computation results </li></ul></ul><ul><ul><li>OK for Grid computations that checkpoint </li></ul></ul><ul><li>Revisit at end with new ideas </li></ul>
  21. 21. Hierarchical replication control <ul><li>Synchronization is costly over WAN </li></ul><ul><li>Hierarchical replication control </li></ul><ul><ul><li>Amortizes consensus management </li></ul></ul><ul><ul><li>A primary server can assert control at different granularities </li></ul></ul>
  22. 22. Shallow & deep control /usr bin local /usr bin local A server with a shallow control on a file or directory is the primary server for that single object A server with a deep control on a directory is the primary server for everything in the subtree rooted at that directory
  23. 23. Primary server election <ul><li>Allow deep control for a directory D if D has no descendent is controlled by another server </li></ul><ul><li>Grant a shallow control request for object L from peer server P if </li></ul><ul><ul><li>L is not controlled by a server other than P </li></ul></ul><ul><li>Grant a deep control request for directory D from peer server P if </li></ul><ul><ul><li>D is not controlled by a server other than P </li></ul></ul><ul><ul><li>No descendant of D is controlled by a server other than P </li></ul></ul>SKIP SKIP SKIP
  24. 24. Ancestry table /root a b c f2 d2 controlled by S1 controlled by S0 controlled by S0 controlled by S2 …… Ancestry Table The data structure of entries in the ancestry table d1 f1 Ancestry Entry an ancestry entry has the following attributes id = unique identifier of the directory array of counters = set of counters recording which servers controls the directory’s descendants counter array S0 S1 S2 Id 2 0 0 c 0 0 1 b 2 1 0 a 2 1 1 root
  25. 25. Primary election <ul><li>S0 and S1 succeed in their primary server elections </li></ul><ul><li>S2’s election fails due to conflicts </li></ul><ul><li>Solution - S2 then re-tries by asking for shallow control of a </li></ul>a b c S0 S1 S2 control b control c control b deep control a control c deep control a S0 S1 S2  SKIP SKIP SKIP
  26. 26. Performance vs. concurrency <ul><li>Associate a timer with deep control </li></ul><ul><ul><li>Reset the timer with subsequent updates </li></ul></ul><ul><ul><li>Release deep control when timer expires </li></ul></ul><ul><ul><li>A small timer value captures bursty updates </li></ul></ul><ul><li>Issue a separate shallow control for a file written under a deep controlled directory </li></ul><ul><ul><li>Still process the write request immediately </li></ul></ul><ul><ul><li>Subsequent writes on the file do not reset the timer of the deep controlled directory </li></ul></ul>SKIP SKIP SKIP SKIP
  27. 27. Performance vs. concurrency <ul><li>Increase concurrency when the system consists of multiple writers </li></ul><ul><ul><li>Send a revoke request upon concurrent writes </li></ul></ul><ul><ul><li>The primary server shortens releasing timer </li></ul></ul><ul><li>Optimally issues a deep control request for a directory that contains many updates in single writer cases </li></ul>SKIP SKIP SKIP
  28. 28. Single remote NFS N.B.: log scale
  29. 29. Deep vs. shallow Shallow controls vs. deep + shallow controls
  30. 30. Deep control timer
  31. 31. Durability revisited <ul><li>Synchronization is expensive, but … </li></ul><ul><li>When we abandon the durability guarantee, we risk losing the results of the computation </li></ul><ul><ul><li>And may be forced to rerun it </li></ul></ul><ul><ul><li>But it might be worth it </li></ul></ul><ul><li>Goal: maximize utilization </li></ul>NEW NEW NEW
  32. 32. Utilization tradeoffs <ul><li>Adding synchronous replication servers enhances durability </li></ul><ul><ul><li>Which reduces the risk that results are lost </li></ul></ul><ul><ul><li>And that the computation must be restarted </li></ul></ul><ul><ul><li>Which benefits utilization </li></ul></ul><ul><li>But increases run time </li></ul><ul><ul><li>Which reduces utilization </li></ul></ul>
  33. 33. Placement tradeoffs <ul><li>Nearby replication servers reduce the replication penalty </li></ul><ul><ul><li>Which benefits utilization </li></ul></ul><ul><li>Nearby replication servers are more vulnerable to correlated failure </li></ul><ul><ul><li>Which reduces utilization </li></ul></ul>
  34. 34. Run-time model
  35. 35. Parameters <ul><li>F: failure free, single server run time </li></ul><ul><li>C: replication overhead </li></ul><ul><li>R: recovery time </li></ul><ul><li>p fail : server failure </li></ul><ul><li>p recover : successful recovery </li></ul>
  36. 36. F: run time <ul><li>Failure-free, single server run time </li></ul><ul><li>Can be estimated or measured </li></ul><ul><li>Our focus is on 1 to 10 days </li></ul>
  37. 37. C: replication overhead <ul><li>Penalty associated with replication to backup servers </li></ul><ul><li>Proportional to RTT </li></ul><ul><li>Ratio can be measured by running with a backup server a few msec away </li></ul>
  38. 38. R: recovery time <ul><li>Time to detect failure of the primary server and switch to a backup server </li></ul><ul><li>We assume R << F </li></ul><ul><ul><li>Arbitrary realistic value: 10 minutes </li></ul></ul>
  39. 39. Failure distributions <ul><li>Estimated by analyzing PlanetLab ping data </li></ul><ul><ul><li>716 nodes, 349 sites, 25 countries </li></ul></ul><ul><ul><li>All-pairs, 15 minute interval </li></ul></ul><ul><ul><li>From January 2004 to June 2005 </li></ul></ul><ul><ul><ul><li>692 nodes were alive throughout </li></ul></ul></ul><ul><li>We ascribe missing pings to node failure and network partition </li></ul>
  40. 40. PlanetLab failure CDF
  41. 41. Same-site correlated failures sites nodes 11 21 65 259 0.488 5 0.488 0.378 4 0.538 0.440 0.546 3 0.561 0.552 0.593 0.526 2
  42. 42. Different-site correlated failures
  43. 43. Run-time model <ul><li>Discrete event simulation yields expected run time E and utilization (F ÷ E) </li></ul>
  44. 44. Simulated utilization F = one hour One backup server Four backup servers
  45. 45. Simulation results F = one day One backup server Four backup servers
  46. 46. Simulation results F = ten days One backup server Four backup servers
  47. 47. Simulation results discussion <ul><li>For long-running jobs </li></ul><ul><ul><li>Replication improves utilization </li></ul></ul><ul><ul><li>Distant servers improve utilization </li></ul></ul><ul><li>For short jobs </li></ul><ul><ul><li>Replication does not improve utilization </li></ul></ul><ul><li>In general, multiple backup servers don’t help much </li></ul><ul><li>Implications for checkpoint interval … </li></ul>
  48. 48. Checkpoint interval F = one day One backup server 20% checkpoint overhead F = ten days, 2% checkpoint overhead One backup server Four backup servers
  49. 49. Next steps <ul><li>Checkpoint overhead? </li></ul><ul><li>Replication overhead? </li></ul><ul><ul><li>Depends on amount of computation </li></ul></ul><ul><ul><li>We measure < 10% for NAS Grid Benchmarks, which do no computation </li></ul></ul><ul><li>Refine model </li></ul><ul><ul><li>Account for other failures </li></ul></ul><ul><ul><ul><li>Because they are common </li></ul></ul></ul><ul><ul><li>Other model improvements </li></ul></ul>
  50. 50. Conclusions <ul><li>Conventional wisdom holds that consistent mutable replication in large-scale distributed systems is too expensive to consider </li></ul><ul><li>Our study proves otherwise </li></ul>
  51. 51. Conclusions <ul><li>Consistent replication in large-scale distributed storage systems is feasible and practical </li></ul><ul><li>Superior performance </li></ul><ul><li>Rigorous adherence to conventional file system semantics </li></ul><ul><li>Improves cluster utilization </li></ul>
  52. 52. Thank you for your attention! www.citi.umich.edu Questions?

We develop a consistent mutable replication extension for NFSv4 tuned to meet the rigorous demands of large-scale data sharing in global collaborations. The system uses a hierarchical replication control protocol that dynamically elects a primary server at various granularities. Experimental evaluation indicates a substantial performance advantage over a single server system. With the introduction of the hierarchical replication control, the overhead of replication is negligible even when applications mostly write and replication servers are widely distributed.

Aufrufe

Aufrufe insgesamt

3.261

Auf Slideshare

0

Aus Einbettungen

0

Anzahl der Einbettungen

75

Befehle

Downloads

67

Geteilt

0

Kommentare

0

Likes

0

×