Cloud-related Storage Research in Santa Cruz

Transcription

1 Cloud-related Storage Research in Santa Cruz Darrell Long University of California, Santa Cruz

2 Trading Storage for Computation (and vice versa) 2

3 Trade Storage for Computation Inputs rocess Result Storing rarely used intermediate or final results is wasteful But, if results are still used, even infrequently, they may not be discarded In the cloud, computing a result is often cheaper than storing it store the inputs and process, recompute on demand Challenges: Cost Calculation: when is re-computation is cheaper than storage? rovenance: what must be known in order to reproduce a result? 3

4 Old Idea, New otential Storage Recomputation Balancing storage and computation is common Data de-duplication, file compression, dynamic programming... The cloud allows opportunities for large scale tradeoffs Quickly allocate resources to compute on demand No need for over provisioning to prepare for rare events purchase on demand computation when needed 4

5 Example Archive of 100,000 photos rovide bmp, jpeg, tiff, Adobe, png Use Amazon Web Services AWS rices- June S3 Storage Cost $0.18 per GB/Month S3 Data In $0.03 per GB Store Everything 1600x1200 images in 5 formats= 2.2TB 100 GB of requests Cs =$ per month S3 Data Out EC2 Sm. Machine Instance EC2 Data In EC2 Data Out $0.17 per GB $0.10 per hour $0.10 per GB $0.17 per GB Recompute Formats on Demand Raw BM=550 GB 720 on demand small linux instance hours 100 GB out from S3 to EC2+100 GB EC2 Out Cr =$ per month Cr = Cost of Re-computation Cs = Cost of Storage 5

6 Evolvable, Reliable, Energy-Efficient Disk-Based Archival Storage 6

7 Existing approaches to archival storage Tape Disk Array MAID ergamum Media Costs low medium - high medium low Random Access erformance Centralized Controller poor good medium medium yes usually yes no ower Usage low high medium low Media per reader many one one one 7

8 ergamum tome Tome D0 D1 D2 Region with 3 Segments Region with 5 Segments Low-ower CU timestamp(d0) timestamp(d1) timestamp(d2) sig(d0) sig(d1) sig(d2) Network SATA Disk Segment arity NVRAM Low power CU & DRAM: NAS functions, consistency checking, parity ops SATA hard drive: low-cost, persistent storage Data stored in segments with parity appended NVRAM: metadata storage (data signatures, time stamps, index, etc.) Ethernet controller: commodity interconnection network 8

9 Two-level reliability approach Redundancy Group arity Region Redundancy Group R R R R R R R R R R R R R R R R R R Redundancy Group R R R R R R R R R R R R R R R R R R Redundancy Group R R R R R R Redundancy Group Tome 0 R R R R R R R R R R R R Tome 1 Tome 2 Tome 3 Intra-disk - protection from latent sector errors Increased reliability reduces scrubbing needs Fix errors with as little spin-up as possible Inter-disk - protection from device loss 9

10 Secure, Long-Term Storage Without Encryption 10

11 Keeping Secrets by Splitting Them Creates n shares, m required for recovery n out of n schemes (e.g. XOR based) m out of n threshold schemes (e.g. Shamirʼs scheme) Benefits Fewer than m shares reveals no information Unconditionally secure Reconstruction not dependent on a single share Well suited to the group trust model R 1... R 2 = R n-1 S S 11

12 OTSHARDS Overview User Object Fragment Fragment Fragment Shard Shard Shard Shard X Shard Y arity Shard Archive 0 Archive 1 Archive 2 Archive 3 Redundancy Group 12

13 Two-Level Split Security Adversary needs to compromise a lot of random data with two levels of splitting With 50% of the shards, only 0.04% of data was revealed with a 3-way XOR split and 3 of 4 Shamir split % of Secrets Recovered of3 2of4 3of4 % of Secrets Recovered of3 2of4 3of % of Total Secret Shares One level: Shamir split % of Total Shares Two levels: 3-way XOR, Shamir split 13

14 OTSHARDS User Model Users access data with a OTSHARDS client Local installation Shared installation OTSHARDS client transforms data Archives never see clear data Archives manage redundancy themselves OTSHARDS Client OTSHARDS Client A B C Redundancy Data 14

15 Store, Forget & Check 15

16 Whatʼs the problem? Systems store data on remote nodes Remote nodes may not be trustworthy Data owner must check to ensure that data is really stored Two current approaches: Read data from multiple sites and check for consistency Generate checksum remotely and compare to checksum of local data We developed an efficient algorithm that does not require Keeping a local copy of the data Keeping a set of questions and answers 16

17 Cloud storage: back-up Clouds can be racks of servers or peer-to-peer articipants in the scheme offer limited storage on their machine in exchange for storing their own data Data protected using parity or redundancy Extra blocks calculated using m/n redundancy codes Generate n blocks Require any m of the blocks to rebuild the data Many known mechanisms for m/n codes Linear interpolation XOR and Galois field-based articipants need to be able to verify that other nodes are doing their part... 17

18 Algebraic signatures Algebraic properties Assume that X and Y are large data objects: sig(x Y) = sig(x) sig(y) sig(β X) = β sig(x) Multiplication is in the Galois field of the signature calculation Signatures and parity formation commute Signatures can be updated from the old signature and the signature of the delta (XOR) between old and new data Signature calculation is fast! Hundreds of megabytes per second on a modern CU Speed limited by disk bandwidth 18

19 Our algorithm Store data across distributed system Challenge sites to prove that they hold the data Sites respond with the signatures of requested data Sites reveal tiny amount of information: size of signature Challenger verifies that the signatures are consistent D 1 D 2 D 3 sig1 sig2 sig3 sigp Calculate signature of 32 byte ranges at 4+i 71, i = 5,,20 sig 1 sig 2 sig 3 sig 19