ramcloud overview john ousterhout stanford university
TRANSCRIPT
![Page 1: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/1.jpg)
RAMCloud Overview
John Ousterhout
Stanford University
![Page 2: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/2.jpg)
April 1, 2010 RAMCloud Overview Slide 2
Introduction
● Large-scale storage system entirely in DRAM
● Interesting combination: scale, low latency
● Enable new applications?
● The future of datacenter storage?
![Page 3: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/3.jpg)
April 1, 2010 RAMCloud Overview Slide 3
Outline
● Overview of RAMCloud
● Motivation
● Research challenges
● Basic cluster structure and data model
![Page 4: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/4.jpg)
April 1, 2010 RAMCloud Overview Slide 4
The Basic Idea
● Storage for datacenters
● 1000-10000 commodity servers
● 32-64 GB DRAM/server
● All data always in RAM
● Durable and available
● Performance goals: High throughput:
1M ops/sec/server Low-latency access:
5-10µs RPC
Application Servers
Storage Servers
Datacenter
![Page 5: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/5.jpg)
April 1, 2010 RAMCloud Overview Slide 5
Example Configurations
Today 5-10 years
# servers 2000 4000
GB/server 24GB 256GB
Total capacity 48TB 1PB
Total server cost $3.1M $6M
$/GB $65 $6
![Page 6: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/6.jpg)
April 1, 2010 RAMCloud Overview Slide 6
RAMCloud Motivation: Latency
● Large-scale apps struggle with high latency Facebook: can only make 100-150 internal requests per page
UI
App.Logic
DataStructures
Traditional Application
UI
Bus.Logic
App
licat
ion
Ser
vers S
torage Servers
Web Application
<< 1µs latency 0.5-10ms latency
Single machineDatacenter
![Page 7: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/7.jpg)
April 1, 2010 RAMCloud Overview Slide 7
ComputationPower
Dimensions of Scalability
StorageCapacity
Data AccessRate
![Page 8: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/8.jpg)
April 1, 2010 RAMCloud Overview Slide 8
ComputationPower
Dimensions of Scalability
StorageCapacity
Data AccessRate
Not providedby today's infrastructure
![Page 9: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/9.jpg)
April 1, 2010 RAMCloud Overview Slide 9
MapReduce
Sequential data access → high data access rate Not all applications fit this model
Computation
Data
![Page 10: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/10.jpg)
April 1, 2010 RAMCloud Overview Slide 10
RAMCloud Motivation: Latency
● RAMCloud goal: large scale and low latency
● Enable a new breed of information-intensive applications
UI
App.Logic
DataStructures
Traditional Application
UI
Bus.Logic
App
licat
ion
Ser
vers S
torage Servers
Web Application
<< 1µs latency 0.5-10ms latency
Single machineDatacenter
5-10µs
![Page 11: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/11.jpg)
April 1, 2010 RAMCloud Overview Slide 11
RAMCloud Motivation: Scalability
● Relational databases don’t scale
● Every large-scale Web application has problems: Facebook: 4000 MySQL instances + 2000 memcached servers
● Major system redesign for every 10x increase in scale
● New forms of storage appearing: Bigtable Dynamo PNUTS Sinfonia H-store memcached
![Page 12: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/12.jpg)
April 1, 2010 RAMCloud Overview Slide 12
RAMCloud Motivation: TechnologyDisk access rate not keeping up with capacity:
● Disks must become more archival
● More information must move to memory
Mid-1980’s 2009 Change
Disk capacity 30 MB 500 GB 16667x
Max. transfer rate 2 MB/s 100 MB/s 50x
Latency (seek & rotate) 20 ms 10 ms 2x
Capacity/bandwidth(large blocks)
15 s 5000 s 333x
Capacity/bandwidth(1KB blocks)
600 s 58 days 8333x
Jim Gray's rule 5 min 30 hrs 360x
![Page 13: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/13.jpg)
April 1, 2010 RAMCloud Overview Slide 13
Why Not a Caching Approach?
● Lost performance: 1% misses → 10x performance degradation Hard to approach 1% misses (Facebook ~ 5-7% misses)
● Won’t save much money: Already have to keep information in memory Example: Facebook caches ~75% of data size
● Changes disk management issues: Optimize for reads, vs. writes & recovery
![Page 14: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/14.jpg)
April 1, 2010 RAMCloud Overview Slide 14
Why not Flash Memory?
● Many candidate technologies besides DRAM Flash (NAND, NOR) PC RAM …
● DRAM enables lowest latency today: 5-10x faster than flash
● Most RAMCloud techniques will apply to other technologies
![Page 15: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/15.jpg)
April 1, 2010 RAMCloud Overview Slide 15
Is RAMCloud Capacity Sufficient?
● Facebook: 200 TB of (non-image) data in 2009
● Amazon:Revenues/year: $16BOrders/year: 400M? ($40/order?)Bytes/order: 1000-10000?Order data/year: 0.4-4.0 TB?RAMCloud cost: $26-260K?
● United Airlines:Total flights/day: 4000? (30,000 for all airlines in U.S.)Passenger flights/year: 200M?Bytes/passenger-flight: 1000-10000?Order data/year: 0.2-2.0 TB?RAMCloud cost: $13-130K?
● Ready today for almost all online data; media soon
![Page 16: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/16.jpg)
April 1, 2010 RAMCloud Overview Slide 16
RAMCloud Research Issues
● Data durability/availability
● Fast RPCs
● Data model, concurrency/consistency model
● Data distribution, scaling
● Automated management
● Multi-tenancy
● Client-server functional distribution
● Node architecture
![Page 17: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/17.jpg)
April 1, 2010 RAMCloud Overview Slide 17
RAMCloud Cluster Structure
ModifiedLinux
Master Backup
ServersClients(App Servers)
OS/VMM
RAMCloudLibrary
Application
Untrusted TrustedCoordinator
![Page 18: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/18.jpg)
April 1, 2010 RAMCloud Overview Slide 18
Client Library vs. Server
● Move functionality to library? Flexibility: enable different implementations Throughput: offload servers May improve performance (e.g., aggregation)
● Concentrate functionality in servers? May improve performance (e.g., faster synchronization) Can't depend on proper client behavior:
● Security/access control● Consistency/crash recovery
ApplicationRAMCloud
LibraryRAMCloud
Server
ApplicationCustomLibrary
![Page 19: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/19.jpg)
April 1, 2010 RAMCloud Overview Slide 19
Data Model Rationale
How to get best application-level performance?
Lower-level APIsLess server functionality
Higher-level APIsMore server functionality
Key-value store
Distributed shared memory : Server implementation easy Low-level performance good APIs not convenient for
applications Lose performance in
application-level synchronization
Distributed shared memory : Server implementation easy Low-level performance good APIs not convenient for
applications Lose performance in
application-level synchronization
Relational database : Powerful facilities for apps Best RDBMS performance Simple cases pay RDBMS
performance More complexity in servers
Relational database : Powerful facilities for apps Best RDBMS performance Simple cases pay RDBMS
performance More complexity in servers
![Page 20: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/20.jpg)
April 1, 2010 RAMCloud Overview Slide 20
Data Model Basics● Workspace:
All data for one or more apps Unit of access control
● Table: Related collection of objects
● Object: Variable-length up to 1MB Contents opaque to servers
● Id: 64 bits, unique within table Chosen explicitly by client or
implicitly by server (0,1,2,...)
● Version: 64 bits Guaranteed increasing, even across deletes
Workspace
Tableid objectid objectid objectid objectid object
id objectid objectid objectid object
Table
versversversversvers
versversversvers
![Page 21: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/21.jpg)
April 1, 2010 RAMCloud Overview Slide 21
Basic Operations
get(tableId, objId) → (blob, version)
put(tableId, blob) → (objId, version)
put(tableId, objId, blob) → (version)
delete(tableId, objId)
Other facilities (discussed in later talks)
● Conditional updates
● Mini-transactions
● Indexes
![Page 22: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/22.jpg)
April 1, 2010 RAMCloud Overview Slide 22
Other Design Goals
● Data distributed automatically by RAMCloud: Tables can be split across multiple servers Indexes can be split across multiple servers Distribution transparent to applications
● Multi-tenancy for cloud computing: Support multiple (potentially hostile) applications Cost proportional to application size
![Page 23: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/23.jpg)
April 1, 2010 RAMCloud Overview Slide 23
Conclusion
● Interesting combination of scale and latency
● Enable more powerful uses of information at scale: 1000-10000 clients 100TB - 1PB 5-10 µs latency
![Page 24: RAMCloud Overview John Ousterhout Stanford University](https://reader034.vdocuments.site/reader034/viewer/2022051416/56649e495503460f94b3ce54/html5/thumbnails/24.jpg)
April 1, 2010 RAMCloud Overview Slide 24
Questions/Comments