NCAPS Fault Tolerance Architecture for Real-Time Systems
This paper critically examines the NCAPS (Application High Availability in UNIX Computer Clusters) system developed by Tandem Computers, as presented in a 1998 case study by Luiz A. Laranjeira. The first section evaluates the system's software architecture and fault tolerance strategies, including redundancy through process pairs, fault detection via the Process Pairs Manager and Hang Detection Service, and system recovery mechanisms. The second section proposes a practical application design that integrates NCAPS with Web 2.0 technology to deliver a fault-tolerant, continuously available Internet banking service, addressing the reliability and availability expectations of modern online banking customers.
- Introduction and Design Goals: Context, motivation, and key availability objectives
- NCAPS System Architecture: Core software components and cluster structure
- Fault Tolerance Strategies: Redundancy, fault detection, and error isolation methods
- System Reconfiguration and Recovery: User-defined reconfiguration and PPM-driven recovery
- Internet Banking Application Design: Web 2.0 and NCAPS integration for online banking
- Conclusion: Evaluation summary, gaps, and future relevance
✍️ How to write this paper — guide, tools & examples ▾
What makes this paper effective
- The paper grounds every architectural claim in direct quotations from the Laranjeira case study, giving the critique strong evidentiary support while keeping the analysis focused.
- It honestly acknowledges information gaps in the source material—such as the absence of fault-type classification—rather than overstating the system's documented capabilities.
- The second section applies the theoretical framework from Part I to a concrete real-world use case (Internet banking), demonstrating practical integration of course concepts.
Key academic technique demonstrated
The paper employs a structured comparative critique: it first establishes fault tolerance categories (redundancy, detection, isolation, reconfiguration, recovery) as an evaluative framework, then systematically measures the NCAPS system against each category. This technique is effective for technology assessments because it creates transparent criteria against which readers can independently judge the system's strengths and shortcomings.
Structure breakdown
The paper is organized in two discrete parts. Part I (system critique) moves from design goals → architecture overview → fault tolerance strategies (each sub-strategy given its own heading) → recovery. Part II (application design) moves from motivation (Internet adoption trends) → use case selection → Web 2.0 front-end design → integration with NCAPS for availability and fault tolerance → concluding synthesis. References follow at the end in a consistent author-date format.
Introduction and Design Goals
Since the dawn of the Internet, the need for application availability and reliability has continually grown. This need is especially strong in the military, aerospace, and aircraft control industries, where any amount of downtime can have fatal consequences. In the 1998 case study titled "NCAPS: Application High Availability in UNIX Computer Clusters," by Luiz A. Laranjeira, Tandem Computers developed a specialized software system capable of running on Unix computer clusters while providing a superior level of application availability. This essay offers a critique of that case study as well as of the software architecture and fault tolerance strategies used.
At the time of the case study, there was still a pressing need to improve the recovery times of existing high-availability solutions, particularly for real-time critical applications. Recovery times were too long, expensive, and unreliable, lasting anywhere between one minute and an hour. The key design goal of the NCAPS system was therefore to provide continuous availability of real-time critical systems in the event of hardware, software, or operating system faults. By significantly shrinking the recovery times of large-scale applications, the NCAPS design aimed not only to keep vital systems running, but also to reduce the substantial costs associated with downtime.
NCAPS System Architecture
NCAPS provides specialized system software that runs on a Unix computer cluster with two or more nodes — widely considered the minimum requirement for a high-availability cluster. The system can provide more rapid failover because it is based on a primary/backup scheme in which two instances of an application run simultaneously.
As described in the case study, the NCAPS software architecture includes five core components: the Node Status Monitor (NSM), the Keepalive (KpA), the Process Pairs Manager (PPM), the Open Fault Tolerance Library (OftLib), and the Command Line Interface (CLI). The NSM, KpA, and PPM are replicated in both nodes and interact through continuous monitoring and message communication. The NSM monitors the state of the two nodes. The KpA monitors registered processes and uses a script to restart them in the event of failure.
Most importantly, the PPM is the core of the NCAPS system: it starts, monitors, and manages application processes through a process pairs paradigm. The PPM state model can also be configured by the user, which is a key competitive advantage over other high-availability software vendors.
Fault Tolerance Strategies
Redundancy has been defined as the duplication of critical components of a system with the intention of increasing reliability, usually in the form of a backup or fail-safe (Answers.com, 2010). The two nodes of the NCAPS system provide redundancy by mirroring each other, always maintaining one node in primary status and the other in backup status. If one fails, the other is available to take over.
Redundancy in the NCAPS system is also present in the NSM, where "heartbeats" are exchanged between the two NSM instances. "When one NSM does not receive a configurable number of heartbeats from the other within a configurable period of time, it sends a node-down message to its subscribers (the PPM only). When the other node is restarted and the two NSMs resume exchanging heartbeats, the NSM sends a node-up message to its subscribers" (Laranjeira, 1998, p. 442).
Always ready to switch from backup to primary state, the PPM provides redundancy as well: "One instance of the PPM and of the watched application run in each of two nodes of a cluster. In one node an instance of the application is in a primary state and is providing service. In the other node another instance of the application is in a backup state. A backup application is not providing service, but it is initialized and ready to take over in case of a failure of the primary application or of its node" (Laranjeira, 1998, p. 442).
Described as a highly available service implemented as a primary and shadow instance, the Keepalive component offers further redundancy: "These two instances send heartbeats to each other and share information through a memory-mapped file. If the shadow instance dies, the primary restarts it. If the primary instance dies, the shadow instance becomes primary, takes control of the memory-mapped file, and spawns another shadow instance" (Laranjeira, 1998, p. 442).
Information on fault and error isolation and containment within the NCAPS system was not clearly disclosed in the case study. Regarding the PPM and application processes, the following was stated: "In failure situations, the PPM executes a cleanup script and restarts the application to a maximum configurable number of times. The cleanup script ensures that all application processes have exited before the application is restarted" (Laranjeira, 1998, p. 443). In addition, the Hang Detection Service will terminate an offending process if a hang is detected. Beyond these points, relatively little information was provided on how faults or errors are isolated and contained.
The case study provides little definition of the types of faults the system detects, whether transient, permanent, or intermittent. Based on course material, this omission raises concerns: "In an ultra-reliable system, it is essential to have error detection and recovery mechanisms designed to handle transient faults. These mechanisms must be able to distinguish transient faults from permanent or intermittent faults, so that when a transient fault is detected in a unit the unit is not discarded" (Course Objectives). This does not necessarily mean that NCAPS cannot distinguish between fault types, but the absence of this information in the case study leaves important questions unanswered.
Fault detection functionality in the NCAPS system is provided by the PPM: "When an application process fails, the PPM detects it and restarts it up to a maximum configurable number of times. After this threshold is exceeded, the next failure of that process will imply a failure of the application" (Laranjeira, 1998, p. 443). The Application Administration (AAD), a key component of the PPM, also provides fault detection by mediating interactions between the Application State Model (ASM) and the application. The AAD detects an application event such as a failure and directs it into the ASM. After a state change occurs, an ASM action triggers the AAD to send a state-change command message to the application processes (Laranjeira, 1998, p. 446).
Part of the functionality provided by the Open Fault Tolerance Library (OftLib) is the Hang Detection Service (HDS), which detects faults that cause a process to hang. By using heartbeats with specified time intervals, the HDS detects when a heartbeat is not received as expected and responds with an appropriate action — namely, terminating the offending process. Keepalive then detects that the process no longer exists and triggers the appropriate recovery mechanisms (Laranjeira, 1998, p. 444).
Conclusion
Overall, the NCAPS system appears to be a highly effective solution built on a solid, logical architecture. From the primary/backup design to the PPM, NSM, and Keepalive components, redundancy is prevalent throughout the system and helps provide high availability, resiliency, and security. Multiple components monitor the system, applications, and application processes, while enabling communication between the various components. The PPM, AAD, and HDS detect faults by monitoring system heartbeats, errors, and potential failures. System reconfiguration can be defined by the user, and system recovery can be handled by the PPM and the CLI. Because the system offers extensive user-defined capabilities, operators gain the flexibility to configure it to meet their specific needs.
While the case study contains a great deal of detailed information, several gaps remain. A clear definition of the types of faults the system detects — such as transient, permanent, or intermittent — and an explanation of how the system handles each type would have been helpful. Information on how faults and errors are isolated and contained after detection would also have been valuable.
Since the case study was written in 1998, it would be interesting to assess where the product and its functionality stand today. The demand for highly available systems has only increased over time, and the NCAPS system, with its comprehensive approach to fault tolerance, appears to have had a strong foundation from which to remain competitive in the evolving landscape of real-time and fault-tolerant computing.
References
Arunnima, B.S. (2009). Web 2.0 in banking and financial services industry. InfoSys Technologies Limited.
Chen, X.M., Hong, S.J., and Yu, S. (2009). Next-generation banking with Web 2.0. IBM DeveloperWorks.
Jaymalya Palit. (2009). Online customer experience: What works. Infosys Finacle.
Horst, R. (1995). TNet: A reliable system area network. IEEE Micro, 15(1), 37–45.
Laranjeira, L.A. (1998). NCAPS: Application high availability in Unix computer clusters.
Medard, M. and Lumetta, S. (2002). Network reliability and fault tolerance.
Answers.com. (2010). Definition of redundancy.
Always verify citation format against your institution’s current style guide requirements.