Fail stop Fault
In distributed systems, fail stop faults, sometimes referred to as crash faults, are a kind of benign failure in which a node or component suddenly stops working or becomes inaccessible. In essence, the component stops functioning and is unable to engage with the system any more.
Here’s a detailed explanation:
- Nature of Failure: A component’s functionality completely and instantly ceasing to function is a fail-stop fault. The impacted node just shuts down and ceases to communicate. This indicates that the component loses its ability to respond to messages or requests from other areas of the system.
- Predictability and Management: The impact of a crash fault is typically foreseeable, in contrast to more complicated failures, because the node simply goes offline and does not transmit false information. In comparison to defects like Byzantine faults, this makes them generally easier to manage. A component that either operates perfectly or stops entirely without displaying any random or malevolent behaviour is referred to as a fail-stop.
- Causes: A hardware malfunction, a software defect that causes a crash, or a power outage are examples of fail-stop problems that can result from either software or hardware failures.
Distinction from Byzantine Faults
Differentiating crash faults from Byzantine faults is essential.
- Crash Faults (Fail-Stop): These are easier since, as previously said, a malfunctioning node simply ceases and its effect can be determined.
- Byzantine Faults: These are far more difficult since a node may behave deliberately or inconsistently, possibly transmitting false or conflicting information to other network nodes. Consensus algorithms cannot manage Byzantine behaviour if they are only made for crash faults.
System Resilience and Impact
Fault tolerance in a distributed system refers to the ability to function properly even in the event that a component fails. In particular, crash fault tolerance (CFT) refers to the resilience incorporated into a protocol that allows it to continue and come to an agreement even in the event that certain components suffer these benign failures.
The entire system is not meant to be rendered inoperable by the failure of a single node owing to a crash fault because distributed systems are made to guard against single points of failure. Other active nodes keep in touch and base their decisions on messages from the remaining reachable nodes even if one of them becomes inaccessible. However, improper handling of crash failures can still result in loss of service, downtime, and perhaps corrupted or lost data.
Detection
It is reasonably easy to identify a crash defect in synchronous systems by employing techniques such as timeouts or heartbeat signals. On the other hand, it can be difficult to tell whether a component is slow or crashed in asynchronous systems.
Designing Systems to Handle Fail-Stop Failures
System Design to Address Fail-Stop Failures: The following design principles are used to address fail-stop failures:
- Redundancy: Having several parts that can carry out the same function and enable the system to switch to another in the event of a failure is known as redundancy and fault tolerance.
- Replication: Multiple copies of processes or data are stored on different machines or nodes. Another replica can take over in the event of a failure, maintaining service. A financial system might, for example, maintain several copies of customer account balances on many computers to guarantee that transactions are completed without data loss even in the event of a machine failure.
- Error Checking and Correction: Adding safeguards to stop minor mistakes from turning into more serious ones.
- Monitoring and Alerting: Systems are designed to detect fail-stop failures rapidly and notify administrators or users so they can take appropriate action.
- Graceful Degradation: Instead of failing entirely, the system can be built to continue operating at a reduced capacity if full redundancy is not practical.
- Network Communication Example: When sending a request to a server in network communication, a client might resubmit the request to another server if they don’t hear back from the server within a certain amount of time.
Consensus Algorithms for Crash Faults
There are two well-known consensus algorithms that are especially made to withstand crash faults:
RAFT (Replicated And Fault-Tolerant): Similar to PAXOS in terms of fault tolerance and performance, this algorithm was created with ease of comprehension in mind. A leader’s log (data) is copied to every follower node in its leader-follower paradigm. Due to its reliance on majority voting, Replicated And Fault-Tolerant can withstand up to N/2 – 1 follower node failures (where N is the total number of nodes) without compromising efficiency. It is utilized for service ordering in platforms such as Hyperledger Fabric, R3 Corda, and ConsenSys Quorum.
PAXOS: PAXOS, the first consensus algorithm created to reach consensus even in the event of a breakdown or network failure, was first proposed by Leslie Lamport in 1989. It employs a two-phase protocol with proposers and acceptors (prepare and accept phases). While PAXOS can withstand F crash failures when there are 2F + 1 processes in the network, consensus is stopped if more than N/2 (where N is the total number of acceptors) acceptors fail. RAFT is a simplified and more popular option for multiple consecutive choices (also known as “multi PAXOS”), notwithstanding its theoretical strength. In contrast to PAXOS, where any node has the ability to become a leader, RAFT explicitly permits the leader selection of the best-updated nodes.