1. RAMCloud Scalable High-Performance Storage Entirely in DRAM John Ousterhout, Parag Agrawal, David Erickson, Christos Kozyrakis, Jacob Leverich, David Mazières, Subhasish Mitra, Aravind Narayanan, Guru Parulkar, Mendel Rosenblum, Stephen M. Rumble, Eric Stratmann, and Ryan Stutsman Stanford University Presented by Sangjin Han (many slides are stolen from https://ramcloud.stanford.edu) 1

2. Features (or Goals) Low latency: 5-10 µs (not milliseconds) High throughput: 1M operations/s Key-value storage with 1000s of servers No replicas Entirely in DRAM – Disks only for backup Fast recovery (1-2 secs) 2

3. Why DRAM? 3 Mid-1980’s2009Change Disk capacity30 MB500 GB16667x Max. transfer rate2 MB/s100 MB/s50x Latency (seek & rotate)20 ms10 ms2x Capacity/bandwidth (large blocks) 15 s5000 s333x Capacity/bandwidth (1KB blocks) 600 s58 days8333x Jim Gray’s Rule (1KB)5 min.30 hours360x Today 5-10 years # servers10004000 GB/server64GB256GB Total capacity64TB1PB Total server cost$4M$6M $/GB$60$6

4. create(tableId, blob) => objectId, version read(tableId, objectId) => blob, version write(tableId, objectId, blob) => version cwrite(tableId, objectId, blob, version) => version delete(tableId, objectId) June 3, 2011RAMCloud Overview & StatusSlide 4 Data Model Tables Identifier (64b) Version (64b) Blob (≤1MB) Object (Only overwrite if version matches)

5. Master Backup Master Backup Master Backup Master Backup … Appl. Library Appl. Library Appl. Library Appl. Library … Datacenter Network Coordinator 1000 – 10,000 Storage Servers 1000 – 100,000 Application Servers 32-64GB/server 5 Overall Architecture

6. Per-Node Architecture 6 One server per data 2-3 backups for buffered logging

7. Coordinator Centralized server for data placement E.g, Clients obtain a map from the coordinator – And cache 7 Table #First KeyLast KeyServer 1202 64 - 1192.168.0.1 4763,7425,723,742192.168.0.2 ………

8. Fast Recovery (First Try) 8 Recovery Master Backups Crashed Master Reconstruct data from backup logs Bottleneck: disk B/W Solution: more disks

9. Fast Recovery (Second Try) Randomly distribute log shards Bottleneck: recovery master Solution: no single recovery master 9 Recovery Master ~1000 Backups Crashed Master

10. Fast Recovery (Third Try) Temporarily distributed recovery masters Happy? – 35 GB recovery in 1.6s using 60 nodes (SOSP 2011) 10 Recovery Masters Backups Crashed Master

11. Typical Datacenter Latency 11

12. RAMCloud Latency 12

13. Publication History Unveiling: SOSP 2009 WIP White paper: Operating Systems Review 2009 – What you read (Call for) low latency: HotOS 2011 Fast recovery: SOSP 2011 Ongoing work: index, transaction, transport, … Visit http://ramcloud.stanford.edu 13

14. Thoughts & Discussion Garbage collection? Infiniband vs. Ethernet – HW support for transport layer? Killer app? Non volatile memory? Synchronous vs. asynchronous query Moving data vs. Moving code How many papers out of this project? :P 14

15. Thanks 15

16. SORRY My English still s^^ks Would you repeat the question – SLOWLY and – CLEARLY 16 ??????