Trade- Offs in Cloud Storage Architecture. Stefan Tai

Transcription

1 Trade- Offs in Cloud Storage Architecture Stefan Tai

2 Cloud computing is about providing and consuming resources as services There are five essential characteristics of cloud services [NIST] [NIST]: computing/

3 1. Elastic Scalability

4 2. On- demand Self- Service

5 3. Ubiquitous Network Access

6 4. Resource Pooling

7 5. Measured Service

8 Essential characteristics Security High Availability Reliability Rapid Elasticity Data Consistency Measured Service On- demand Self- service Demand- side Aggregation Multi- Channel Access Multi- Tenancy Efficiency Resource Pooling Supply- side Savings Broad Network Access Client Latency

9 ...and diverse Trade- offs Security High Availability Reliability Rapid Elasticity Data Consistency Measured Service Demand- side Aggregation $ On- demand Self- service Multi- Channel Access Multi- Tenancy Efficiency Resource Pooling Supply- side Savings Broad Network Access Client Latency

10 Trade- offs are unavoidable Trade- off decisions cannot (always) be made during design- time, rather, the factors determining trade- off decisions are likely to dynamically change during runtime, e.g. Workload patterns might change because user location changes times of (peek) usage changes (partly user- controlled) applications & features change Failure patterns might change because hardware characteristics change software characteristics change network reliability changes

11 Key Challenges Measurable qualities and trade- offs Consumer- observable vs. Provider- side Metrics: $ vs. msec Tunable qualities and trade- offs At runtime, not (only) design/deployment- time Continuous evaluation

12 Example: Cloud Storage Service

13 A simple Web API to start with Storage Consumer Storage Provider write (file, key) read (file, key) Programming Model Storage Model

14 Let s have a closer look at write() Storage Consumer Storage Provider write (file, key) Programming Model Storage Model

15 (N,R,W) Quorum System Storage Consumer Storage Provider the girl with the dragon tattoo (key) write (file, key) Programming Model fff A cd38 (MD5 hash of key) bbb E Coordinator Node B 333 Replica Node Storage Model 999 D C 666

16 with Eventual Consistency Storage Consumer Storage Provider the girl with the dragon tattoo (key) write (file, key) Programming Model fff A cd38 (MD5 hash of key) bbb E Coordinator Node B 333 Replica Node Hinted Handoff Node Storage Model 999 D C 666

17 A well- known Trade- Off: CAP Theorem Consis- tency Avail- ability Either C, or A, but not both (Network Partitions assumed in a Cloud context) Tolerance to Network Partitions

18 Consistency vs. Availability Atomic Consistent Isolated Durable ACID BASE Basically Available Soft- State Eventually Consistent Traditional DBMS NoSQL Cloud Storage

19 Measuring client- observable t0 Client Eventual Consistency Send Update Request Cloud Storage Provider #1 t1 Receive Response How soon (how late) is eventual? Client- observable time window (t1,t2) Update Propagation #2 #n t2 time Bermbach/Tai 2011

20 Setup Cloud Clock Sync. Protocol

21 Experimental Findings for Amazon S3 LOW SAW [Bermbach2011]: David Bermbach and Stefan Tai: Eventual Consistency: How soon is eventual? An Evaluation of Amazon S3 s Consistency Behavior Middleware for Services Computing Workshop. to appear December 2011, ACM.

22 Length of S3 LOW/SAW Periods Avg. Bermbach/Tai 2011

23 Experimental Findings for Apache Cassandra Bermbach/Tai 2011

24 Comparing S3 and Cassandra Amazon S3 1 Apache Cassandra 2 Two different periodicities 12% violations of monotonic read consistency One availability zone out of three usually lags behind (in 50% of all tests) > 99 % of all LOW writes create consistent data after 175ms Read availability > 8 nines Geometric distribution % violations of monotonic read consistency No influence of geographic distribution > 99% of all writes create consistent data after 35ms Read availability 100% 1 Setup: high redundancy with replication over 3 availability zones; test duration 7 days 2 Setup: deployed on 3 large EC2 instances in different availability zones; Consistency level ONE; 3 replica; test duration 24h Bermbach/Tai 2011

25 Further S3 Measurements Two files, same bucket, different behavior Bermbach/Tai 2011

26 Client- observable measurable qualities as defined, as agreed?

27 Objective (1.): Understanding the C- A- Spectrum for use in Applications A B A S E A C I D C t

28 (2.) Tuning Knobs to dynamically manage trade- offs Storage Consumer Storage Provider the girl with the dragon tattoo (key) write (file, key) Programming Model fff A cd38 (MD5 hash of key) config_ring (N,R,W) = (3,2,2) Config Model bbb E Coordinator Node Replica Node B 333 N Durability Storage Model R W Read- Availability Write- Availability 999 D C 666

29 3. Reliable, client- observable behavior

30 Our Agenda Understanding relevant qualities and critical trade- off decisions that need to be addressed on a per- application basis, on a per- provider, and per- client/ tenant basis Providing tuning knobs that translate into novel programming / configuration / deployment models for the Cloud Continuously monitoring and evaluating runtime data (e.g., nr. of transactions, load and utilization) within the trade- off model and automating trade- off adjustments

31 Our Vision: The Harmonic Cloud Architecture Trade- Off Equalizer

32 Thank You Stefan Tai / tai@fzi.de

33 Acknowledgments David Bermbach Markus Klems