How to Tell if Your Cloud Files Are Vulnerable to Drive Crashes

1. How to Tell if Your Cloud Files Are Vulnerable to Drive Crashes K. Bowers, M. van Dijk, A. Juels, A. Oprea, R. L. Rivest

2. Outline • Motivation and idea • Storage system • Challenge and control • Network • Hard drive • Lock-step • Choose the threshold

3. Motivation and Idea • Cloud server: “We store 3 copies of your file in 3 different drives. We are 2 fault-tolerant.” • Pizza store: “We have 2 ovens.” • How do you know if it’s true? • Idea : multiple devices can do parallel workbut single device can’t.

4. Example – pizza store • Assume we know • The pizza store has 2 ovens • An oven “usually” takes 5 min to bake a pizza • The store is a 15 min drive from here • Time needed for 24 pizzas ? • 1 oven : 5·24=120 min • 2 ovens: 60 min • Drive time: 15 min • Task for the pizza store:“Send me 24 pizzas in 80 min.”Task for the cloud server: “Send me a block of the file from each drive in xxxx milliseconds” • What’s the problem with the task in real life?

5. Problems for the two examples • How to design the task? • Cloud server / pizza store • Design the time limit • Challenge of the design • Network latency / pizza delivery traffic time • Drive read time / oven baking speed • How to make the queries unpredictable?

6. Network latency • Ping hosts in Santa Clara and Shanghai from Boston • Latency 1 ≈ Latency 2 • Reduce network-timing variance • Server applies hash function before transmitting

7. Basic task model • Assume Server has c drives C1,…,Cc • file F={f1,…,fm} G={g1,…,gn} • E.g., n=3m, G={g1,…,gn} ={f1,…,fm,f1,…,fm,f1,…,fm} • Equally distribute {g1,…,gn} to the c drives • C1 =, C2 =, …… , Cc = • E.g., C1 ={1,…,m}, C2 ={m+1,…,2m}, ……, C3 ={2m+1,…,3m} • Task for Server: “Show me (i1,…,ic)”where each ijCj , for j = 1,…,c

8. Drive – read time • Task: Server reads a block from each drive • The block size (the size of each gi) ? • The time limit for this task? • Two main factors of drive read time • Seek : disk head moves to the right track and sector • Data transfer rate (throughput) • The drive used in this paper • 3.5ms seek time and 73MB/s to 125MB/s throughput

9. Drive – determine the block size • Seek time depends on the distance that the disk head needs to move • Throughput depends on the position of the block • Outer tracks are faster than inner tracks • Sequential data are faster than scattered data • Force to perform a seek for EVERY block • Using small block size • Query random pattern of blocks

10. Drive – determine the block size • Read time vs. block size • We can’t choose block size less than64 KB • Choose 64 KB • Read time distributionsof 64 KB blocks

11. Drive – time limit? Not ready • Recall the two examples • Pizza store with 2 ovens: query 24 pizzas (12 steps) • Cloud server with 3 drives: query 3 blocks (1 step) • Why use 12 steps instead of 1 step for pizza store? • Enlarge the gap between one oven and two ovens • Play the same trick to Cloud server, query q steps (query cq blocks)? • Tell Server the cq blocks at beginning? • Tell Server the next c blocks for q times? • Solution : lock-step

12. Lock-step (q steps) • Client Server • Server performs the following process • Client Server • Client checks the correctness and timing

13. Gap, number of steps, time limit • Lock-step ensures the security of the increase of the steps • The more steps, the larger gap threshold

14. Experiments : c = 5 drives • Read time gap

15. Experiments : c = 5 drives • Response time gap between honest max and adversary min

16. Experiments : c = 5 drives Luckiest adversary

17. Future woks • Integrate the protocols with other existing storage devices. • Multi-tenant storage devices.

18. Discussion • The design of the tasks depends on • seek time, throughput, RPM, buffer • How to verify the specification and the statistics of the drives? • Lock-step checking (next page)

19. Discussion • Lock-step Shortcut for Client?