IEEE Spectrum November, 2015 - 54

Are You An
Electrical
Engineering
Student
Looking For An
Internship?

Look
No
Further!
We Have
Internship
Opportunities
for Students.
Visit us at:
www.AfterCollege.com/
IEEE_Internships

on different servers. So when a write
request arrives at a master, it updates
its information in DRAM and then forwards the new data on to several backup
RAMCloud servers. This need for replication explains why writing data takes
longer than reading it.
In addition to these general measures,
we had to solve two specific problems
to make RAMCloud's backup strategy
really bulletproof. The first was what
to do if a server loses power before it
has made backup copies. RAMCloud
deals with that possibility using a small
amount of nonvolatile memory on each
machine. When new data is written to
one machine, the backup machines associated with it collect that data temporarily in some form of fast but nonvolatile
memory. That could take the form of
battery-backed DRAM, for example.
These backups then write the data to disk
or flash in the background. Having the
data in fast nonvolatile memory at the
start ensures that the information can
be recovered if a power failure occurs
before the data is written to disk or flash.
The second problem is that a RAMCloud
cluster with thousands of servers will
inevitably experience frequent server
crashes. RAMCloud keeps only a single
copy of information in DRAM, so data
that was stored on a crashed server will
be unavailable until it can be reconstructed from information on the hard
disks (or flash memories) of its backups. If
all the crashed machine's data were held
on one other disk, it would take several
minutes to get it into working memory.
To avoid that long a delay, RAMCloud
scatters the backup data for each master across all of the other servers in the
cluster, which could amount to thousands of machines. After a crash, all
of those machines work in parallel
to reconstruct the lost data. With the
work spread among so many computers, RAMCloud can recover from server
failures in just 1 to 2 seconds-so fast that
most Web users wouldn't even notice.
although ramcloud is just a university

research project, our goal was to create
a production-quality system that can be
used for real applications. At the beginning
of last year, the system reached version
1.0: The basic features were in place, and
the software was mature enough for early

adopters to begin experiments. Since then,
several groups outside Stanford have
begun experimenting with RAMCloud's
open-source code, for such things as the
Distributed Main Memory Database project at telecom giant Huawei.
One possible impediment is that
RAMCloud does not support the relational
data model that dominates information
technology today. It does not provide the
convenient facilities of a relational database management system, so many applications would have to be reprogrammed
to use it. But that's perhaps not as big
an issue as it would appear. The applications for which RAMCloud would be most
advantageous haven't yet been written,
simply because there is no storage system
capable of supporting them.
So RAMCloud's early adopters are not
likely to be those using existing enterprise applications. Instead, the first users
will probably be developers who discover that today's storage systems are
just not fast enough to meet their needs.
These groups can design their applications around RAMCloud from the start,
and they should be more willing than
most to try it out. Desperate people are,
after all, the friend of new technology!
If RAMCloud proves successful with its
early adopters, it may not be long before it
spreads into the mainstream. RAMCloud
is a good match for cloud-computing data
centers such as Amazon Web Services,
Google Cloud, or Microsoft Windows
Azure. In such an environment, the cost
of a RAMCloud cluster could be amortized across many users, who could then
take advantage of high-speed storage at
very low cost, while retaining the ability to expand easily as their needs grow.
RAMCloud represents a new class of
storage that simultaneously achieves
vast capacity and low latency. It would
let something like a million CPU cores
within a data center work together on
data sets of 1 petabyte or more, where any
core can access any data item in 5 to 10 μs.
That's one-thousandth of the time it
typically takes now. So if you're already
impressed by the speed and power of
today's large-scale Web applications, fasten your seat belt and get ready for even
bigger thrills in the future. n
post your comments at http://spectrum.
ieee.org/ramcloud1115

http://www.AfterCollege.com/ http://spectrum http://www.ieee.org/ramcloud1115

Table of Contents for the Digital Edition of IEEE Spectrum November, 2015