1 / 16

Toward Fault-tolerant P2P Systems: Constructing a Stable Virtual Peer from Multiple Unstable Peers

Toward Fault-tolerant P2P Systems: Constructing a Stable Virtual Peer from Multiple Unstable Peers. Kota Abe, Tatsuya Ueda (Presenter) , Masanori Shikano, Hayato Ishibashi and Toshio Matsuura Osaka City University 14/Oct/2009 AP2PS2009. Background. P2P systems pros and cons

kiefer
Download Presentation

Toward Fault-tolerant P2P Systems: Constructing a Stable Virtual Peer from Multiple Unstable Peers

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. Toward Fault-tolerant P2P Systems: Constructinga Stable Virtual Peer from Multiple Unstable Peers Kota Abe, Tatsuya Ueda (Presenter), Masanori Shikano, Hayato Ishibashi andToshio MatsuuraOsaka City University 14/Oct/2009 AP2PS2009 AP2PS2009

  2. Background • P2P systems pros and cons • pros: scalability, no single point of failure, etc. • cons: hard to implement! • detect remote peer failure • replicate data over multiple peers • manage multiple pointers to backup peers • Implementing these measures is delicate work and troublesome burden for developers GOAL! • Implement a reliable layer for fault tolerant P2P systems AP2PS2009

  3. Our Approach • Virtual Peer (VP) • Group multiple unstable peers to form a stablevirtual peer(redundant system) Virtual Peer(VP) Virtual Peer(VP) AP2PS2009

  4. Our Approach (Cont'd) • A virtual peer consists of multiple member peers • A P2P application runs on a virtual peer as a virtual process • Failed member peer is replaced with another (non-failed) one • A virtual process is fault-tolerant • It does not fail even if some part of the member peers fail • Application developers do not need to take care of peer failure Virtual Peer Virtual Process memberpeer1 memberpeer2 memberpeer3 AP2PS2009

  5. Issues to solve • How to achieve fault-tolerance of a virtual process? • How to ensure identical message sequences? • How to handle peer failure? • How to communicate with a remote virtual peer? AP2PS2009

  6. 1. Achieving fault-tolerance of virtual process • The state of a virtual process must be replicated over multiple member peers • Each member peer simultaneously and redundantly executes the same application, as a process • To maintain the state of each process identical: • A process must be a state machine • its state must be changed only by external messages • Also, each process receives the identical message sequence (aka atomic broadcasting) • Merit: application programs can be quite simple • Just process the received messages in order AP2PS2009

  7. 2. Ensuring identical message sequences • To implement atomic broadcast, the Paxos consensus algorithm is used • Paxos • Distributed algorithm to form a consensus between multiple nodes (peers) on an unreliable network • Only a dedicated leader peer can propose values • The leader is elected by using a leader election algorithm • All peers eventually choose an identical value • Majority agreement is required • All the member peers in VP execute Paxos algorithm • External messages sent to a VP are processed by the Paxos algorithm to be identically ordered AP2PS2009

  8. 3. Handling peer failure • Failed member peer must be replaced to keep the number of the peers constant • Otherwise the VP eventually will not be functional because majority agreement is required by Paxos • All the member peers must have a consistent view of membership configuration • Paxos is also used to update a member configuration without losing consistency AP2PS2009

  9. 3. Handling peer failure (Cont'd) Virtual Peer • The leader peer chooses another peer p from the P2P network • If leader peer fails, new leader is elected • The leader peer proposes a peer configuration change • p executes the same process • The state must be same • Process migration technique is used • Note that the majority of member peers must be alive during this replacing sequence Process Process Process Process Leader Peer Member Peer Member Peer Keep Alive choose randomly Timeout fail Peer p Paxos Process migration (replication) Virtual Peer AP2PS2009

  10. 4. Communication with virtual peer • How to deliver messages to VPs • Member peers are not fixed! • Solution: Use ALM (Application Level Multicast) • Each VP has a dedicated ALM group • All member peers join in • Messages sent to a VP are multicast to the group • We have implemented ALM by using range queries on Skip Graph ALM group Multicast by group id Virtual Peer AP2PS2009

  11. Our implementation: musasabi • A platform forimplementing P2P services • Implemented in Java • Each peer executes a musasabi instance • An application program written in Java can be executed on musasabi • Java sandbox mechanism is used to protect a local node • musasabi uses PIAX for P2P networking • PIAX provides Skip Graph, ALM (over Skip Graph) etc. • http://www.piax.org/en/ Process 1 Process 2 Process 3 musasabi PIAX Java VM Base Operating SystemWindows, MacOS X, Linux … Configuration of musasabi AP2PS2009

  12. Process migration in musasabi • musasabi supports strong mobility • Transfer the program, data and execution context (thread stack and program counter) • Not easy in Java (not supported by the standard JVMs) • Some implementations use customized JVMs or native libraries (not portable) • Not suitable for P2P systems! • Implementation of strong mobility in musasabi • Use Apache Javaflow library • Javaflow allows to capture and resume the execution context • Captured contexts can be transferred to a remote node! • Javaflow uses byte code translation technique and thus works on the standard JVMs AP2PS2009

  13. Reliability of virtual peers Virtual Peer A VP fails if a majority of member peers fails • Maximum time toreplace a failed peeris 60sec • Each peer fails independently • Intervals of peerfailure are exponentiallydistributed • Peer failure rate:50% of peers failin an hour Process Process Process Leader Peer Member Peer Member Peer Keep Alive 7 peers choose randomly fail Timeout Process Paxos Peer p 60sec Reliability of VP 5 peers 3peers Process migration (replication) Elapsed time (days) 7 peers are enough in this case After 1 year Virtual Peer

  14. MTTF of virtual peer Relation between MTTF (Mean Time To Failure) of a VP and # of its member peer is analyzed • Each peer fails independently • Intervals of peerfailure are exponentiallydistributed • Maximum time toreplace a failed peer is 60sec • Peer failure rate isvaried (x-axis) 9 peers MTTF of VP (year) 7 peers 5 peers Even in excessive peer failure environment, VP is stable if it has enough member peers Duration of 50% of the peers fail (minutes) frequently peer fails less frequently AP2PS2009

  15. Conclusion and Future work • We proposed a novel method to construct a stable virtual peer from multiple unstable peers • Integrate the Paxos consensus algorithm, process migration technique and ALM • An application running on a VP virtually does not fail • Application programs can be quite simple • The method can be used for reducing development costs, and for improving stability, of P2P systems • Future work • Improve the method for choosing good member peers • Investigate and improve security issues of VPs • Evaluate the method on the Internet AP2PS2009

  16. Questions? This research was partially supported by National Institute of Information and Communication Technology (NICT), Japan AP2PS2009

More Related