1 / 32

Mobility

Mobility. Victoria Krafft CS 614 10/25/05. General Idea. People and their machines move around Machines want to share data Networks and machines fail Network connections not available everywhere. Solution:.

oceana
Download Presentation

Mobility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Mobility Victoria Krafft CS 614 10/25/05

  2. General Idea • People and their machines move around • Machines want to share data • Networks and machines fail • Network connections not available everywhere

  3. Solution: Modify network file systems so data can still be accessed when a system is not connected to the network.

  4. Previous Work • Grapevine developed in 1982 • Network File System (NFS) developed in 1984 • Andrew File System (AFS) developed in 1985 • Version control systems

  5. Coda • James Kistler and M. Satyanarayanan in 1992 • Lots of workstations with local disks, laptops, which use distributed file systems • Expand existing cache structures to store all the desired data • Want to continue work through outages

  6. Environment • Lots of untrusted Unix clients • A few trusted servers • High-bandwidth LAN when connected

  7. Basic Design • Shared Unix file system, with volumes mapped to individual file servers • Client cache manager (Venus) • Volume on all servers in Volume Storage Group (VSG) • Client notified when cache no longer valid

  8. Design Decisions • Scalability • Shift work to clients • First Class vs Second Class Replication • Servers know more than clients • Optimistic vs Pessimistic replica control • availability, or consistency?

  9. Venus Design

  10. Venus States

  11. Hoarding • Gather all useful data in cache • User-specified critical data • Data currently in use • Cache equilibrium maintained by hoard walking • Update file priority & critical directories • Re-evaluate priority of cached files • Re-fetch outdated files

  12. Emulation • Venus acts as a pseudo-server • Create replay log containing all updates • Store critical data in recoverable virtual memory in case of crash

  13. Reintegration • Run replay algorithm on each volume • Replay Algorithm: • Parse log and lock contents • Log operations validated and executed • Perform data transfers • Commit and release locks

  14. Reintegration Time

  15. Cache Size

  16. Conflicts?

  17. Conclusions?

  18. Bayou’s Anti-Entropy Algorithm • Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Marvin M. Theimer and Alan J. Demers in 1997 • Weakly consistent replication • Update anywhere model

  19. Environment • Trusted servers • WAN as well as LAN

  20. Algorithm Provides • Support for arbitrary communication topologies • Operation on low-bandwidth networks • Incremental progress • Eventual consistency • Efficient storage management • Propagation through off-line mechanisms • Arbitrary policy choices

  21. How it works • Storage system on each replica (server) contains: • Ordered log of writes • Database which results from those writes • Pairs of servers reconcile by bringing each other up to date • Epidemic behavior ensures spread • Eventually, commit and truncate write log

  22. Server Reconciliation • When server gets write from client, write is logged with accept-stamp • For server S to update server R: • S gets version vector from R • S sends all entries in its write log not in version vector of R. • Enforces property that each server which contains write n from server X has all writes < n from server X.

  23. Write Log Management Or: How to avoid using infinite amounts of disk space • Designated primary replica creates commit sequence number (CSN) when it writes to its database • Each server manages its own log, but discards only stable (committed) writes

  24. Revised update process • If S has committed writes R does not know, send to R • Continue with previous algorithm End result: Write A precedes write B if A has smaller CSN, or if both uncommitted, accepted by the same server, and A accepted before B.

  25. Write Log Truncation • Server can remove committed writes from log file. • If a server has deleted writes needed to reconcile with another server, the database must be copied.

  26. Protocol Extensions • Transportable media • Stable write order provides eventual consistency • Light-weight server creation/retirement

  27. Server Creation/Deletion • Server creates itself by sending a creation write to an existing server • Server retires by: • Sending retirement write • Stops accepting new writes • Reconciles database with at least one other server

  28. Design Dependencies

  29. Results

  30. Results

  31. Conclusions?

  32. Final Questions • Peer-to-peer or server-based architecture? • Conflict reconciliation? • Vulnerability to failures?

More Related