1993 · 157 citations · 15 references
ComputingComputer EngineeringComputer ScienceFault ToleranceFault-tolerant SystemsSoftware EngineeringFailure DetectionHigh AvailabilityReliable System DesignSoftware Fault ToleranceCheckpointingData ConsistencyFault Tolerance ArchitectureFault Tolerance MechanismsFault Tolerant ArchitecturesFault-tolerant ArchitectureOperating System Abstraction LayersSoftware Fault Detection
Software‑implemented fault tolerance refers to software facilities that detect and recover from faults not handled by hardware or OS, covering crashes or hangs caused by software or undetected hardware/OS faults, and has been adopted in newer AT&T telecom products. The paper defines four levels of software fault tolerance based on application availability and data consistency when faults occur. The authors provide reusable components—Watchd, libft, and nDFS—that implement up to the third fault‑tolerance level by automatically restarting failed processes, checkpointing and recovering volatile data, and replicating persistent data, and have been ported to multiple UNIX platforms for easy integration. Experiences show that these modules efficiently and economically enhance fault tolerance, with performance overhead ranging from 0.1% to 14% depending on the amount of critical data checkpointed and replicated.
By software implemented fault tolerance, we mean a set of software facilities to detect ‘and recover from faults that are are not handled by the underlying hardware or operating system. We consider those faults that cause an application process to crash or hang; they include software faults as well as faults in the underlying hardware and operating system layers if they are undetected in those layers. We define 4 levels of software fault tolerance based on availability and data consistency of an application in the presence of such faults. Watchd, libft and nDFS are reusable components that provide up to the 3rd level of software fault tolerance. They perform, respectively, automatic detection and restart of failed processes, periodic checkpointing and recovery of critical volatile data, and replication and synchronization of persistent data in an application software system. These modules have been ported to a number of UNIX’ platforms and can be used by any application with minimal programming egort. Some newer telecommunications products in AT&T have already enhanced their fault-tolerance capability using these three components. Experience with those products to date indicates that these modules provide eficient and economical means to increase the level of fault tolerance in a software product. The performance overhead due to these components depends on the level and varies from 0.1% to 14% based on the amount of critical data being checkpointed and replicated.
15
Condor-a hunter of idle workstations
Michael Litzkow, Miron Livny, Matt W. Mutka · 2003 · 2.3K citations · Full text
End-To-End Arguments In System Design
Jerome H. Saltzer, David P. Reed, David D. Clark · 1984 · 2.1K citations
System structure for software fault tolerance
Brian Randell · ACM SIGPLAN Notices · 1975 · 1.5K citations · Full text
Knowledge and common knowledge in a distributed environment
Joseph Y. Halpern, Yoram Moses · Journal of the ACM · 1990 · 963 citations · Full text