Object replication; process resilience

Object replication

Object replication means keeping copies (replicas) of a distributed object on multiple machines so that they all hold the same state and can serve invocations. It is used for fault tolerance (availability), performance (load sharing, local access) and scalability.

Issues:

• Consistency: invocations on replicas must keep them identical; all replicas must apply the same operations in the same order (e.g. by totally ordered multicast).
• Replicated invocations: a replicated object calling another object may send the same call many times, so duplicates have to be suppressed.
• Replication approaches: the object itself can be made aware of replication (the object handles its own consistency), or the middleware (replicated-object adapter, ORB) does it transparently, e.g. in CORBA's fault-tolerant object groups.

Replication models are active replication (all replicas execute every invocation) and primary-backup (passive) replication; in both, the object group is referenced as a single object.

Process resilience approach

Process resilience means protecting a system against process failures by replicating a process into a process group that works as a single logical process: if a member fails, another takes over, so the service goes on.

Group organization

• Flat group: all processes are equal and decide collectively (e.g. by voting). There is no single point of failure, but decision making is more complex and has more overhead.
• Hierarchical group: one coordinator decides and the workers carry out the instructions. It is simple and fast, but if the coordinator fails the group must elect a new one.

Flat group        Hierarchical group
 P1--P2            Coordinator
  \  /              /   |   \
   P3--P4         W1   W2   W3

Failure masking and group size: a group that survives K failures is K-fault tolerant. With crash (fail-silent) failures, K+1 members suffice; with arbitrary (Byzantine) failures, 2K+1 members are needed so that a majority vote gives the correct result, and 3K+1 members are needed for the members to reach agreement among themselves.

Agreement in faulty systems: members must agree on decisions even with faulty members (consensus, Byzantine agreement). A group membership service is needed to add and remove members and to detect failed members (failure detection by pinging and timeouts).

Example: a replicated database server group of 3 servers answering client requests; if one crashes, the other two keep serving.