Karteikarten
Lecture 8 - Replication methods
Karten in diesem Stapel (17)
- 1Passive replication (Primary backup)Passive replication (Primary backup)
- Front End
* Generates unique ID to each request
* Sends each request to primary
* Receives responses from primary
-Primary
* Receives request
* Processes request if new, re-sends response if it is a repeated request
* Propagates changes to backups
* Sends response to the front end
If primary fails, a backup is promoted to act as primary - 2Passive replication - Message ordering: primary performes message ordering -> implements total ordering - Fault tolerance: to tolerate n failed RMs, n+1 RMs are needed * FE needs to be able the new primary in case of failure - Primary processes messages and propagates only the changes to other RMs * Has large overhead when distributing the changes to RMs * Not-responding RMs have to be excludedPassive replication fundamentals:
- All client requests (via front end processes) directed to nominated primary replica manager
- Single primary RM together with one or more secondary replica managers (operating as backups)
-Single primary RM responsible for all front end communication - and updating of backup RMS - 3Continue: - Distributed applications communicate with primary replica manager, which sends copies of up to date data - Requests for data update from client interface to primary RM is distributed to each backup RM - If primary RM fails a secondary RM observer this and is promoted as the primary RM - To tolerate n processes failures n+1 RMs - Passive replication cannot tolerate Byzantine failuresPassive replication - how it works?
- Request is issued to primary RM, each with unique ID
- Primary RM receives request
- Check request ID, in case request has already been executed
- if request is an update the primary RM sends the updated state and unique request ID to all backup RMs
- Each backup RM sends acknowledgement to primary RM
- When ack is received from all backup RMs the primary RM sends request acknowledgement to front end (client interface)
- All requests to primary RM are processed in order of receipt - 4Active replicationActive replication :
- Front End
* Generate unique ID to each request
* Sends each request to RMs (via group communication)
* Receives response from RMs
- Every replica manager
* Executes every request
* Sends response to FE
- 5Active replication - Message ordering * Group communication delivers all messages in the same order --> implements total ordering - Fault tolerance * To tolerate n failed RMs, (2n+1) RMs are needed * FE needs to collect (n+1) identical responses for success - it can disregard the rest - Performance can be improved by sending read-only requests to individual RMs * System remains consistent, but * Not fault-tolerant anymoreActive replication fundamentals:
- Multiple (group) RM, each with equivalent roles
- The RMs operate as a group
- Each FE (client interface) multicasts requests to a group of RMs
- Requests processed by all RMs independently (and identically)
- Client interface compares all replies received
- Can tolerate N out of 2N+1 failures, ie: consensus when N+1 identical responses received
- Can tolerate byzantine failure - 6Active replication - how it works - Client request is sent to group of RM's using totally ordered reliable multicast, each sent with unique request ID - Each RM processes the request and sends response/result back to the front end - Front end collects response from each RM - Fault tolerance : * Individual RM failures have little effect on performance. For n process fails need 2n+1 RM's (to leave majority n+1 operating)done
- 7Gossip architecture - FE may communicate with one replica manager only or with different replica managers - Replica managers exchange (gossip) message about updates periodicallyGossip operations:
-Query (read only) : client blocked
- Update (modify but do not read state): return to the client ASAP
* Immediately, or
* after delivery to k+1 RMs
- More complex ones are converted to a sequence of these two
- 8—Gossip message ordering - vector timestamp
* Each FE keeps a vector timestamp (prev) which has the version of latest values accessed by FE
* Vector timestamps are included in each message and reply:
* Requests - FE sends prev with every request message to a RM
* Replies - Query: RM returns a value + timestamp new (replica may have been updated since the last call). Update: RM returns timestamp Update ID that is unique to the update
- 9Gossip message exchange b/w clients: - Via the same replicated services: enforces testing the happened - before relation - Directly or via other services: * Should happen via the FE to maintain causality * FE piggybacks vector timestamp on client messages and recipients can merge them with their own
- 10Gossip replica manager states: - Value: actual state of the application - Value timestamp: represents the updates reflected in the value - Update log - keeps updates before becoming stable (cannot be applied yet) or until reception of the update by all RM has been confirmed- Replica timestamp:
* Represents updates accepted by the RM & placed in manager's log
* May be different from value timestamp (not all updates in the log are stable)
- List of identifiers of executed calls
* The same update can arrive from a FE or from other RMs
* To prevent an update from being performed twice
- Timestamp table
* Vector timestamps of other RMs
- To establish when an update has been applied at all RMs - 11—
- 12—
- 13—done
- 14—
- 15—
- 16—
- 17—
Informationen
- Beschreibung
- Distributed systems Karteikarten am Lecture 8 - Replication methods, erstellt von minal Kotwal am 25/10/2016.
- Erstellt von
- minal Kotwal
- Aufrufe
- 2
- Bewertung