PAGE 6
This high consolidation significantly reduces the cost, power, cooling, and space required for
Memcached or key-value store operation. As will be shown in the section “Reducing TCO
through Consolidation”, the power efficiency of flash, combined with a balanced use of all system
resources, results in an order-of-magnitude improvement in Memcached throughput per watt.
Since flash memory retains data when powered down, it allows Memcached and key-value store
data to be preserved across system shutdowns or power failures. This can dramatically reduce
the time it takes to re-populate Memcached after a restart, reducing node downtime. Clients
can initiate Sync operations to Membrain to explicitly control the persistent consistency state.
Using Replication and Automated Failover for HA and Disaster Recovery
In many applications, Memcached and key-value store availability is crucial to delivering the
quality of service required by Web sites. If a Memcached server fails, the application must
go to the primary data service, such as a database, to retrieve data. Database accesses are
much slower than Memcached accesses, a problem exacerbated by the extra load when a
Memcached server is down. Therefore Memcached outages can cause severe degradation in
application throughput and response time. With key-value stores, the store often represents
the primary source of the data. So in the event of a failure, the service will be interrupted.
Membrain solves the problem of availability in the event of planned or unplanned downtime.
Each Membrain server is assigned distinct virtual IP addresses (VIPs). Two Membrain servers
can be configured as a mirrored pair, in which data stores (Memcached set/put/replace, etc.)
to one server are replicated to the other. If one server in the pair goes down, the other trans-
parently assumes its VIPs and serves its clients.
As discussed in more detail later in this white paper, Membrain supports the creation of multiple
virtual storage domains called “containers” to provide fine-grained control over cached resourc-
es. Containers provide isolation and policy control, yet efficiently share processor, DRAM, and
flash resources. Containers can be configured in eviction or store mode as well as persistent or
non-persistent mode. Membrain replication supports all container modes.
Figure 5 shows how Membrain replication works. On each write to a node, the Membrain
messaging service transparently replicates the write to the other node. Replication is done
synchronously so that when a client receives a positive acknowledgment for a write, the data
is guaranteed to reside on both nodes in the pair. The heartbeat function of the Membrain
messaging service detects failures when the messaging connection closes or times out. When
this occurs, the surviving node activates the VIPs of the failed node so that it can take over
servicing requests for the failed node.
When a failed replica comes back into service, it initiates actions to make itself current. First,
it notifies the surviving node that it is ready to recover. The surviving node then starts copying
the necessary data to rebuild the recovering cache, and also starts replication of all new write
operations. When the recovering node has finished repopulating its Memcached and key-value
store data, it takes ownership of its VIPs again and resumes service.
Replication is active-active: writes to a particular container can be sent to either node in a
mirrored pair. Although writes to the same key could be sent to either node, this can result in
inconsistent Memcached caches or key-value stores (i.e., Node 0 has different contents for the
key than Node 1). To maintain consistency, applications should map distinct key sets to each
node in a mirrored pair.
Membrain replication can also be used to perform a “rolling upgrade”, in which the supported
application is updated to a newer version without a service disruption. This is done by taking
one node in a mirrored pair offline, upgrading it, and bringing it back online. When the upgraded
node is back online it goes through the recovery process with the surviving node, and then
resumes service.
Active/active replication fully utilized all nodes
Synchronous replication ensures no data is lost during outages
Automated failover delivers continuous service availability, and eliminates the need for
manual, error prone user intervention
Transparent to client side apps and requires no additional overhead
