Triton: A peer-assisted cloud storage systems

KARBON PRESENTATION 8 • 24LEVEL 13, 82 SPENCER ST, MELBOURNE

IMMERSE YOURSELF

a Peer-assisted cloud storage System

A. DAvoli Sapienza University of Rome

davoli@di.uniroma1.it

Principles and practice on Evenutal consistency (PAPEC) @ EuROSYS 2014

04/13/2014

TRITON

Cloud Storage DrawBacks (1): REliability AND Availability

Antonio Davoli Triton@PaPEC 2014 • 2

Cloud Storage DrawBacks (2): Security AND Privacy

Antonio Davoli Triton@PaPEC 2014 • 3

Cloud Storage DrawBacks (3): CAPacity AND Concurrency

Antonio Davoli Triton@PaPEC 2014 • 4

Triton: a Peer-Assisted Cloud storage System

• Triton clients are interconnected through a P2P Network and they can achieve fast interactions by exchanging data directly among themselves.

• In addition, they share a Cloud Storage Resource as rendevouz point for update operations.

Antonio Davoli

Power oF cloud + benefits of peer-to-peer (p2p) networks

Triton@PaPEC 2014 • 5

Hybrid Cloud Delivering Static COntents

This hybrid architecture is often employed only in static content distribution systems, such as television and music streaming.

Antonio Davoli Triton@PaPEC 2014 • 6

Hybrid Cloud Dynamic COntents

‣ What happens when users need to modify their shared data?

‣ How can we exploit this new Way of thinking about Cloud infrastructure?

Antonio Davoli Triton@PaPEC 2014 • 7

Triton GOALS

• Increase Access PErformance to Shared Information, • Provide a Mechanism to Synchronize access to contents,• Decrease Inconsistency window while waiting For cloud updates,• Decrease trust on cloud Storage pRoviders.

Antonio Davoli Triton@PaPEC 2014 • 8

Triton Design (1) • Physical Separation BETWEEN Files

information and files Data BlocksFiles are shared among the users. However, in the cloud storage are uploaded only the meta-information about file. (e.g. list of peers, hashes of blocks composing the file).

Antonio Davoli Triton@PaPEC 2014 • 9

Triton design (2)• Files are split in data blocks

Update Result

H1 B1 B2

H1

B2B1

B2B1

Antonio Davoli Triton@PaPEC 2014 • 10

After a write/update operation, the peer uploads on the cloud the information (hashes) of modified blocks and pushes toward the other peers the changes that must be applied (binary-diffs).

Request Proxy Req Commit

Node 1

Node 2

Node 3

Node 4

Node 5

Triton Write Operations

Antonio Davoli

• agreement Protocol to Serialize Accesses to shared REsources.

Considering that often peers are online only for a limited amount of time, it is essential to achieve a convergence soon.

Triton@PaPEC 2014 • 11

Triton Write Operations• Three-pHases agreement Protocol for Update Operations

1. An user who wants to update a file creates a request message and broadcasts it to other users who share the file.

2. Then, the request is spread among the users where each one confirm to the others that has recevied and agree on that request (proxy-request), 3. Finally, when the user receives a quorum of messages starts the commit phase.

Antonio Davoli Triton@PaPEC 2014 • 12

Request Proxy Req Commit

Node 1

Node 2

Node 3

Node 4

Node 5

Triton Read Operations• Read Operations Can be executed In parallel (if they do not conflict

with ongoing writes)

Peers are aware of ongoing operations, thus it is possible to provide an read-only access to all the file blocks that are not involved in some update rounds.

Antonio Davoli Triton@PaPEC 2014 • 13

Triton Consistency

By splitting file in smaller blocks and by working with rolling hashes, Triton reduces the amount of data exchanged by peers after a file update.

• Smaller Blocks

• Pushing UpdatesBy pushing information to other peers, Triton reduces the amount of time to wait for the information to be updated on the cloud.

Antonio Davoli Triton@PaPEC 2014 • 14

Experimental ResultsAntonio Davoli Triton@PaPEC 2014 • 15

Experimental Results We built Triton as a client library and created a file system (in user space) based on the protocol’s access policies. In this way, we guarantee an interoperability with several cloud storage providers.

Many other systems (e.g. Depot [1]) require to run part of the code on a centralized server, Triton instead code runs only on the clients.

Antonio Davoli

[1] Mahajan, P. et al. - Cloud Storage with minimal trust, OSDI’10

Triton@PaPEC 2014 • 16

Antonio Davoli Triton@PaPEC 2014 • 17

Triton Latency for agreement

• Up to 8 Replicas on a Intel Xeon Machine

• Up to 8k Payload

Antonio Davoli Triton@PaPEC 2014 • 18

Triton Performance Results

• 6 Clients,• 5 Amazon Ec2 (Oregon)• 1 Sapienza Reg Elena

CS Dept. (Rome)

What’s Next?

Antonio Davoli Triton@PaPEC • 19

Conclusions & Future WorkTriton is a peer-assisted cloud storage solution that merges the benifits of a P2P in the design of a cloud storage system. It contributes to improve performance and security concerns of classical storage systems.

• Improve Experimental Results by employing a larger set of peers,• Enhance Triton model by applying a Game Theoric Approach for PEers

BehaviorS (Rational and Selfish Peers),• Release the Library Prototype + Integration with p2p Social Nets.

Antonio Davoli Triton@PaPEC 2014 • 19

Antonio Davoli On a New Generation of Cloud Storage Systems• 28

Thanks for your attention. davoli@di.uniroma1.it

On a New Generation of Cloud Storage System • 37Antonio Davoli

Triton Backup Slides

Practical Byzantine Fault Tolerance (BFT)

SPECULATIVE BFT: Zyzzyva

Triton : Request

< REQUEST, t, o, n,H, timestamp@c, c >c

• t, topic related to the file • o, operations to apply,• n, sequence nubmer,• H, is hash of history,• timestamp@c is the timestamp for the op,• c, user ID.

Triton : Proxy-Request

< PROXY −REQ, t, o, n,H, timestamp@c, c, p >p

• t, topic related to the file • o, operations to apply,• n, sequence nubmer,• H, is hash of history,• timestamp@c is the timestamp for the op,• p, the request to forward (collection),• c, user ID.

Triton : Commit

< COMMIT, t, o, n,H,R, timestamp@c, c, p >p

• t, topic related to the file • o, operations to apply,• n, sequence nubmer,• H, is hash of history,• timestamp@c is the timestamp for the op,• p, collection of proxy-requests ,• c, user ID.

KARBON PRESENTATION 7 • 24LEVEL 13, 82 SPENCER ST, MELBOURNE

AWESOME PRESENTATION TEMPLATE

CAP Theorem

CAP Theorem: In a network subject to communication failures, it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.

KARBON PRESENTATION 7 • 24LEVEL 13, 82 SPENCER ST, MELBOURNE

AWESOME PRESENTATION TEMPLATE

CAP Theorem (2)CAP Theorem: Any networked shared-data system can have at most two of three desirable properties:

• COncistency (C), • HIgh Availability (A),• tolerance to network partitions (P)