SKR 5302: Advanced Distributed Computing

2. System Model: Distributed System

2.7. Failure Model


Is a definition of in which way failures may occur in distributed systems Provides a basis for understanding the effects of failures Definition of the failure model of a service enables construction of a new service that hides the faulty behaviour of the service it builds upon example: TCP on top of IP TCP: reliable byte-stream service IP: unreliable datagram service Specification of Failure Model Specification of failure models requires a way to describe failures Omission failures A process or channel fails to perform actions that it is supposed to do Arbitrary failures Process or channel may exhibit arbitrary behaviour Timing failures Omission Failure Usual assumption that a server has “fail-stop” failure model the server crashes in a “nice” way it halts completely other servers may detect it has failed if the server nevertheless fails in a different way, the software that uses the server, may fail in unpredictable ways It is difficult to detect omission failures for processes in an asynchronous system Student → Do search example of cases for this failure type. Arbitrary Failure (Byzantine failure) Process or channel may exhibit arbitrary behaviour when failing, send/receive arbitrary messages at arbitrary intervals a process may halt or perform “faulty” steps a process may omit to respond now and then By adopting a byzantine failure model, we can attempt to make systems that are “ultra-reliable” (handles HW failures, and provide guaranteed response times) control systems in air planes patient monitoring systems robot control systems control systems for nuclear power plants Time Failure Applicable in synchronous distributed systems responses that are not available to clients in a specified time interval timing guarantees requires guaranteed access to resources when they are needed Examples: control and monitoring systems, multimedia systems Student → Do search example of cases for this failure type.