WARNING:
JavaScript is turned OFF. None of the links on this concept map will
work until it is reactivated.
If you need help turning JavaScript On, click here.
This Concept Map, created with IHMC CmapTools, has information related to: ch15 repl syst, each logical object is implemented by a collection of physical copies called replicas the replicas are not necessarily consistent all the time (some may have received updates, not yet conveyed to the others) we assume an asynchronous system where processes fail only by crashing and generally assume no network partitions replica managers an RM contains replicas on a computer and access them directly RMs apply operations to replicas recoverably i.e. they do not leave inconsistent results if they crash objects are copied at all RMs unless we state otherwise static systems are based on a fixed set of RMs in a dynamic system: RMs may join or leave (e.g. when they crash) an RM can be a state machine, which has the following properties has State machine applies operations atomically its state is a deterministic function of its initial state and the operations applied all replicas start identical and carry out the same operations Its operations must not be affected by clock readings etc, System model and group communication has each logical object is implemented by a collection of physical copies called replicas the replicas are not necessarily consistent all the time (some may have received updates, not yet conveyed to the others) we assume an asynchronous system where processes fail only by crashing and generally assume no network partitions replica managers an RM contains replicas on a computer and access them directly RMs apply operations to replicas recoverably i.e. they do not leave inconsistent results if they crash objects are copied at all RMs unless we state otherwise static systems are based on a fixed set of RMs in a dynamic system: RMs may join or leave (e.g. when they crash) an RM can be a state machine, which has the following properties, System model and group communication Group communication process groups are useful for managing replicated data but replication systems need to be able to add/remove RMs group membership service provides: interface for adding/removing members create, destroy process groups, add/remove members. A process can generally belong to several groups. implements a failure detector (section 11.1) which monitors members for failures (crashes/communication), and excludes them when unreachable notifies members of changes in membership expands group addresses multicasts addressed to group identifiers, coordinates delivery when membership is changing e.g. IP multicast allows members to join/leave and performs address expansion, but not the other features, System model and group communication Five phases in performing a request issue request the FE either sends the request to a single RM that passes it on to the others or multicasts the request to all of the RMs (in state machine approach) coordination the RMs decide whether to apply the request; and decide on its ordering relative to other requests (according to FIFO, causal or total ordering) execution the RMs execute the request (sometimes tentatively) agreement RMs agree on the effect of the request, .e.g perform 'lazily' or immediately response one or more RMs reply to FE. e.g. for high availability give first response to client. to tolerate byzantine faults, take a vote, process groups are useful for managing replicated data but replication systems need to be able to add/remove RMs group membership service provides: interface for adding/removing members create, destroy process groups, add/remove members. A process can generally belong to several groups. implements a failure detector (section 11.1) which monitors members for failures (crashes/communication), and excludes them when unreachable notifies members of changes in membership expands group addresses multicasts addressed to group identifiers, coordinates delivery when membership is changing e.g. IP multicast allows members to join/leave and performs address expansion, but not the other features has A full membership service maintains group views, which are lists of group members, ordered e.g. as members join group. A new group view is generated each time a process joins or leaves the group. View delivery p 611. The idea is that processes can 'deliver views' (like delivering multicast messages). ideally we would like all processes to get the same information in the same order relative to the messages. view synchronous group communication (p612) with reliability. Illustrated in Fig 15.3 all processes agree on the ordering of messages and membership changes, a joining process can safely get state from another member. or if one crashes, another will know which operations it had already performed This work was done in the ISIS system (Birman)