RAMCloud Scalable High-Performance Storage Entirely in DRAM John Ousterhout, Parag Agrawal, David Erickson, Christos Kozyrakis, Jacob Leverich, David Mazières,

Slides:

Advertisements

Similar presentations

MinCopysets: Derandomizing Replication in Cloud Storage

Advertisements

Fast Crash Recovery in RAMCloud

The Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung SOSP 2003 Presented by Wenhao Xu University of British Columbia.

What happens when you try to build a low latency NIC? Mario Flajslik.

Storing Data: Disks and Files: Chapter 9

G O O G L E F I L E S Y S T E M 陳仕融黃振凱林佑恩 Z 1.

Operating Systems ECE344 Ashvin Goel ECE University of Toronto Disks and RAID.

MICA: A Holistic Approach to Fast In-Memory Key-Value Storage

John Ousterhout Stanford University RAMCloud Overview and Update SEDCL Retreat June, 2014.

RAMCloud: Scalable High-Performance Storage Entirely in DRAM John Ousterhout Stanford University (with Nandu Jayakumar, Diego Ongaro, Mendel Rosenblum,

RAMCloud 1.0 John Ousterhout Stanford University (with Arjun Gopalan, Ashish Gupta, Ankita Kejriwal, Collin Lee, Behnam Montazeri, Diego Ongaro, Seo Jin.

Log-Structured Memory for DRAM-Based Storage Stephen Rumble, Ankita Kejriwal, and John Ousterhout Stanford University.

SEDCL: Stanford Experimental Data Center Laboratory.

CS 140 Lecture Notes: Technology and Operating SystemsSlide 1 Technology Changes Mid-1980’s2009Change CPU speed15 MHz2 GHz133x Memory size8 MB4 GB500x.

CPSC-608 Database Systems Fall 2010 Instructor: Jianer Chen Office: HRBB 315C Phone: Notes #5.

1 CS222: Principles of Database Management Fall 2010 Professor Chen Li Department of Computer Science University of California, Irvine Notes 01.

CS 142 Lecture Notes: Large-Scale Web ApplicationsSlide 1 RAMCloud Overview ● Storage for datacenters ● commodity servers ● GB DRAM/server.

Metrics for RAMCloud Recovery John Ousterhout Stanford University.

The RAMCloud Storage System

RAMCloud Design Review Recovery Ryan Stutsman April 1,

A Compilation of RAMCloud Slides (through Oct. 2012) John Ousterhout Stanford University.

It’s Time for Low Latency Steve Rumble, Diego Ongaro, Ryan Stutsman, Mendel Rosenblum, John Ousterhout Stanford University 報告者 : 厲秉忠

What We Have Learned From RAMCloud John Ousterhout Stanford University (with Asaf Cidon, Ankita Kejriwal, Diego Ongaro, Mendel Rosenblum, Stephen Rumble,

CSC 456 Operating Systems Seminar Presentation (11/13/2012) Leon Weingard, Liang Xin The Google File System.

RAMCloud Overview John Ousterhout Stanford University.

RAMCloud: a Low-Latency Datacenter Storage System John Ousterhout Stanford University

RAMCloud: Concept and Challenges John Ousterhout Stanford University.

RAMCloud: A Low-Latency Datacenter Storage System Ankita Kejriwal Stanford University (Joint work with Diego Ongaro, Ryan Stutsman, Steve Rumble, Mendel.

Cool ideas from RAMCloud Diego Ongaro Stanford University Joint work with Asaf Cidon, Ankita Kejriwal, John Ousterhout, Mendel Rosenblum, Stephen Rumble,

John Ousterhout Stanford University RAMCloud Overview and Update SEDCL Forum January, 2015.

RAMCloud: System Performance Measurements (Jun ‘11) Nandu Jayakumar

1 Moshe Shadmon ScaleDB Scaling MySQL in the Cloud.

Low-Latency Datacenters John Ousterhout Platform Lab Retreat May 29, 2015.

IMDGs An essential part of your architecture. About me

Hardware Trends. Contents Memory Hard Disks Processors Network Accessories Future.

Bigtable: A Distributed Storage System for Structured Data 1.

Durability and Crash Recovery for Distributed In-Memory Storage Ryan Stutsman, Asaf Cidon, Ankita Kejriwal, Ali Mashtizadeh, Aravind Narayanan, Diego Ongaro,

DBI313. MetricOLTPDWLog Read/Write mixMostly reads, smaller # of rows at a time Scan intensive, large portions of data at a time, bulk loading Mostly.

RAMCloud: Low-latency DRAM-based storage Jonathan Ellithorpe, Arjun Gopalan, Ashish Gupta, Ankita Kejriwal, Collin Lee, Behnam Montazeri, Diego Ongaro,

RAMCloud: Scalable High-Performance Storage Entirely in DRAM John Ousterhout Stanford University (with Christos Kozyrakis, David Mazières, Aravind Narayanan,

26-Oct-15CSE 542: Operating Systems1 File system trace papers The Design and Implementation of a Log- Structured File System. M. Rosenblum, and J.K. Ousterhout.

MapReduce and GFS. Introduction r To understand Google’s file system let us look at the sort of processing that needs to be done r We will look at MapReduce.

Log-structured Memory for DRAM-based Storage Stephen Rumble, John Ousterhout Center for Future Architectures Research Storage3.2: Architectures.

CS 140 Lecture Notes: Technology and Operating Systems Slide 1 Technology Changes Mid-1980’s2012Change CPU speed15 MHz2.5 GHz167x Memory size8 MB4 GB500x.

Fast Crash Recovery in RAMCloud. Motivation The role of DRAM has been increasing – Facebook used 150TB of DRAM For 200TB of disk storage However, there.

Experiences With RAMCloud Applications John Ousterhout, Jonathan Ellithorpe, Bob Brown.

GFS. Google r Servers are a mix of commodity machines and machines specifically designed for Google m Not necessarily the fastest m Purchases are based.

RAMCloud Overview and Status John Ousterhout Stanford University.

Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition File System Implementation.

Implementing Linearizability at Large Scale and Low Latency Collin Lee, Seo Jin Park, Ankita Kejriwal, † Satoshi Matsushita, John Ousterhout Platform Lab.

CPSC-608 Database Systems Fall 2015 Instructor: Jianer Chen Office: HRBB 315C Phone: Notes #5.

)1()1( Presenter: Noam Presman Advanced Topics in Storage Systems – Semester B 2013 Authors: A.Cidon, R.Stutsman, S.Rumble, S.Katti,

CSci8211: Distributed Systems: RAMCloud 1 Distributed Shared Memory/Storage Case Study: RAMCloud Developed by Stanford Platform Lab  Key Idea: Scalable.

John Ousterhout Stanford University RAMCloud Overview and Update SEDCL Retreat June, 2013.

CS 140 Lecture Notes: Technology and Operating Systems Slide 1 Technology Changes Mid-1980’s2012Change CPU speed15 MHz2.5 GHz167x Memory size8 MB4 GB500x.

CubicRing ENABLING ONE-HOP FAILURE DETECTION AND RECOVERY FOR DISTRIBUTED IN- MEMORY STORAGE SYSTEMS Yiming Zhang, Chuanxiong Guo, Dongsheng Li, Rui Chu,

RAMCloud and the Low-Latency Datacenter John Ousterhout Stanford Platform Laboratory.

Lecture 17 Raid. Device Protocol Variants Status checks: polling vs. interrupts Data: PIO vs. DMA Control: special instructions vs. memory-mapped I/O.

Log-Structured Memory for DRAM-Based Storage Stephen Rumble and John Ousterhout Stanford University.

Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung

CS 540 Database Management Systems

CPSC-608 Database Systems

The Google File System Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung Google Presented by Jiamin Huang EECS 582 – W16.

Filesystems 2 Adapted from slides of Hank Levy

CS 140 Lecture Notes: Technology and Operating Systems

RAMCloud Architecture

RAMCloud Architecture

CS 140 Lecture Notes: Technology and Operating Systems

A Redundant Global Storage Architecture

The Design and Implementation of a Log-Structured File System

Presentation transcript:

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 1

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

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 # servers GB/server64GB256GB Total capacity64TB1PB Total server cost$4M$6M $/GB$60$6

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)

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

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

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

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

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

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

Typical Datacenter Latency 11

RAMCloud Latency 12

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 13

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

Thanks 15

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