Sumário: Modelos de Computação Distribuída Tolerante a Faltas

Transcrição

1 Modelos da Computação e Comunicação Confiável Uma introdução 1 Sumário: Modelos de Computação Distribuída Tolerante a Faltas Como conseguir tolerância a faltas? Enquadramentos e estratégias Modelos de gestão da replicação: Operações remotas ou Closed-loop Modelo de Difusão ou Open-loop 2

2 Frameworks and Strategies for Fault Tolerance 2.3 Interaction Fault classification (specially important in distributed systems) Omissive Crash» host that goes down Omission» message that gets lost Timing Assertive» computation gets delayed Syntactic» sensor says air temperature is 100º Semantic» sensor says air temperature is 26º when it is 30º ARBITRARY timing omission crash OMISSIVE syntactic semantic ASSERTIVE 4

3 Basic fault tolerance frameworks Hardware Fault Tolerance Software-Based Hardware Fault Tolerance Software Fault Tolerance Fault-Tolerant Communication 3.5 Classical fault tolerance strategies Fault Tolerance versus Fault Avoidance in HW-FT tradeoff between: reliable but expensive components and cheaper, but less performant and more complex mechanisms Tolerating Design Faults beyond HW-FT, which is helpless with common-mode faults (e.g. SW) Perfect Non-stop Operation? when no perceived glitch is acceptable tightly synchronised replicas 3.6

4 Classical fault tolerance strategies Reconfigurable Operation less expensive, when a glitch is allowed Recoverable Operation cheap, when a noticeable but acceptable service outage allowed Fail-Safe versus Fail-Operational safety track--- when a fault cannot be tolerated, two hypothesis: shutdown, which should be made in some orderly way or contingency plan for degraded operational mode (what is the fail-safe position of the engines of a plane? ) 3.7 Models for Replication management (closed-loop systems) 2.8

5 Reliability of remote operations more complex than meets the eye remote operation expects a reply to the request what if request is lost? what if reply is lost? what if server dies in the middle?» (a) before processing request» (b) after, but before sending reply req req req DISCONNECTED DOWN resp these situations are indistinguishable, if comm s level has volatile state and no error detection req DOWN 3.9 Reliability of remote operations (network failures and remedies) communication error detection (ack): reduce ambiguity to the server 3.10

6 Reliability of remote operations (network failures and remedies) surveillance of communication with server (aya): detect communication error in reply 3.11 Reliability of remote operations (server failures and remedies) surveillance of communication with server (aya): tell failure from slowness server fails before or after executing operation: we cannot know whether or not it was executed solution: repeat request until getting a reply (at-least-once)? ALO incorrect for non-idempotent operations 3.12

7 Reliability of remote operations (server failures and remedies) pending done solution: in doubt, request just once (at-most-once) stable memory registers improve AMO : request IDs are stored in disc or NVRAM marked executed or pending when server recovers, it knows what it executed through the end 3.13 Reliability of event services (Volatile Channels) f=2 event diffusion is open loop sender publishes to a group of destinations and goes on reliability is given by degree of replication vs. failures request goes to n replicas, first reply is enough request is executed if no more than n-1 failures occur request is executed once and only once (exactly-once) 3.14

8 Models for Replication management (open-loop systems) 2.15 State Machine programming Characteristics confinement - atomic commands fault tolerance - easy replication Execution model servers start in same state execute same sequence of input commands, in same order commands modify state variables and produce outputs (I/O or return results) THEN: all follow same sequence of state/outputs Programming message-based, diffusion (multicast) requires deterministic execution open-loop reduces concurrency if cmds are long Client1 Client2 m4 INPUT QUEUE STATE MACHINE OUTPUT 2.16

9 Replicated State Machine (active replication) replicated state machine: all replicas execute at same time achieves error masking Client1 Client2 determinism mandatory replica quorums: INPUT (disseminated) benign communication omissive process failures - f+1 replicas affirmative process failures 2f+1 replicas message ordering: total order of commands to replicas same commands in same order => same results OUTPUT (consolidated) REPLICATED STATE MACHINE 2.17 Replicated State Machine (passive replication) passive replication only Primary executes in the order it decides supports preemption and nondeterminism (active rep. doesn t) state transferred to Backup(s) inter-replica deferred state-level synchronization (checkpoints) Backup(s) log commands until checkpoint received Primary fails: Backup assumes potentially long takeover-glitch message ordering: non-ordered message diffusion P1 - PRIMARY OUTPUT Execute() m4 Checkpoint S() P2- BACKUP Message LOG Empty LOG 2.19