A data-centric approach to CORBA fault-tolerance - A concrete and detailed implementation, allowing a clear and simple evolution path for legacy software. 2003 Poster submission.

1. Abstract
Consider a typical service program that is accessible by many
clients over the network. The challenge is to robustify the service
for high availability and load balancing with little or no intervention
to existing client or server code. In this domain, there is a growing
understanding that replication based on group communication
techniques fails to scale well, and incurs costly cross-server
communication.
Our work focuses on a different, data-centric, approach and
provides a concrete and detailed implementation and
performance assessment. In addition, we allow a clear and
simple evolution path for legacy software.
Aquarius – A Data-Centric approach
to CORBA fault-tolerance
Gregory Chokler, Dahlia Malkhi, Barak Merimovich, David Rabinowitz
Hebrew University of Jerusalem
{grishac,dalia,barakm,dar}@cs.huji.ac.il
The Data-Centric Approach
A service is a shared object which is manipulated by multiple
clients. Copies of the object reside on a collection of persistent
storage servers, and are accesses by an unbounded number of
transient client processes. To coordinate updates to the copies of
the object, clients perform a three phase commit protocol.
First, an update is written ‘next’ to the object. Then the client
attempts to commit a new order, that includes the update, at a
majority of servers. Finally, the update is committed, and invoked
on all copies.
Advantages of DCA
• Minimal additional functionality on servers and
clients.
• Servers are unaware of each other.
• Faithfully models Storage Area Networks.
• Alleviates cost of monitoring replicas, and
reconfiguring after failures.
• Each replicated object can have its own group,
failure threshold, quorum system…
• Supports Byzantine Quorum systems by
employing masking quorum systems, and response
voting.
• Limits redundancy only to the places where it is
needed – object replication.
• Useful for many applications – database servers,
client-server middleware.
Aquarius
•Proof of concept – DCA can work.
• 3 tier architecture – Persistent client agents run
the actual ordering protocol, minimizing contention
for the leadership position.
• The proxy is CORBA service that has been highly
optimized to handle the task of redirecting client
operations to the relevant servers. Optimizations
include a unique threading model that uses a fixed
number of threads to handle all client requests and
server responses asynchronously.
• Replicas achieve agreement on the order of the
requests.
• Provides transparent fault tolerance support to
legacy applications. No special code for fault
tolerance is needed! Platform (ORB and OS)
independent.
Coordination
Fail-prone
storage units
Reliable shared
object
Aquarius Architecture
Aquarius Proxy
Future Work
• Recovery
• Monitoring and security
• Pluggable quorums
− Byzantine quorums
− Quorums that allow dirty reads
− Asynchronous backups
References
• G. Chokler, D. Malkhi and D. Dolev. A data-
centric approach for scalable state machine
replication.
• Object Management Group. Fault Tolerant
CORBA Specification, OMG Document
ptc/2000-04-04, April 2000.
• G. Chokler, D. Malkhi, B. Merimovich and D.
Rabinowitz. Aquarius: A Data-Centric approach
to CORBA Fault-Tolerance.
•For more details see:
http://www.cs.huji.ac.il/labs/danss/aquarius/
Performance
Round Trip Time in milliseconds Test uses 5 servers
Conclusions
• Aquarius shows linear performance for
varying numbers of clients and servers,
indicating a high level of scalability. DCA
eliminates the need for all cross-server
communications.
• There are more areas where DCA can be
used for fault tolerance, for example - file
system and SANs.
QOA Design
• Lightweight object adapter
• Adds minimal functionality required by the
ordering protocol to maintain the ordering state of
the replica.
Proxy Design
• The proxy is responsible for creating and
accessing the replicas.
• Unique ID added to each message using
CORBA Portable Interceptors.
• Only the leader proxy performs the ordering
protocol.
• A proxy tries to become the leader when a
forwarded request times out.
• RankException indicates someone else has
become the leader.