第三章 QNX对HA的适用性
（The QNX Approach to HA）
一： 重置“解决方案”
处理软件故障的传统方法包括以下机制:
（1）硬件/软件看门狗
这是一个众所周知的无故障硬件。它触发某些代码来检查系统的完备性。这种完备性检查通常涉及检查一组寄存器，这些寄存器是由正常运行的软件组件不断更新的。但是当其中一个组件不能正常工作时，系统就会被重置。
（2）手动操作介入
许多系统的设计并没有包含故障自动检测机制，而是依赖于手动方式——由操作员监视系统的健康状况。如果系统状态被视为无效的，则操作员就会采取适当的操作，通常包括系统重置。
（3）内存错误约束
操作系统(和硬件平台)通常包含了一些特性，这些特性允许您在程序访问不属于自己的内存时生成错误。一旦发生这种情况，程序就变得不可靠了。对于大多数实时操作人员来说，其结果是必须重新设置系统，以便恢复到正常的操作状态。
所有以上这些方法在检测软件故障方面都比较成功。但是这种检测的最终结果，特别是当面对多个可能独立的软件组件中的大量错误时，系统重置是相当激进的方式。
二：传统实时操作系统（RTOS）体系结构
传统的实时嵌入式系统的架构是造成系统恢复不佳的主要原因之一。这些系统的核心是一个实时执行程序——一个由RTOS本身和许多任务组成的单一内存映像。
由于所有任务(包括关键的系统级服务)都共享相同的地址空间，因此当一个任务的完整性受到质疑时，整个系统的完整性就会受到威胁。如果设备驱动程序之类的单个组件发生故障，RTOS本身也可能出现故障。在HA术语中，每个软件组件应该成为一个单点故障(SPOF)。在这种环境中，惟一可靠的恢复机制是重置系统并从头开始。
这样的实时系统提供了非常低的故障恢复粒度，使得HA计划和处理故障的过程看起来很简单(系统重置)，但通常成本非常高(在停机时间、系统恢复等方面)。对于一些嵌入式应用程序，复位可能涉及一个专门的、耗时的过程，以使系统在现场完全恢复运行。
三: 模块化即粒度化（Modularity means granularity)
这里真正需要的是一种更加模块化的方法。系统架构师经常从设计/实现的角度将他们的系统解耦和模块化。理想情况下，这些模块不仅是设计的重点，而且是故障恢复过程的重点，因此，如果一个模块发生故障，那么只有该模块需要重置，系统其余部分的完整性应保持不变。换句话说，那个特定的模块应该是SPOF。
这种模块化方法还将帮助我们解决这样一个事实，即系统重新启动的平均修复时间(MTTR)比替换单个正在运行的任务的MTTR要长得多。
这种对单个任务恢复的增加粒度类型正是QNX微内核所提供的。QNX实时操作系统的体系结构本身提供了许多固有的HA特性，以至于许多QNX用户认为这些特性是理所当然的，并且常常在系统中设计可恢复性，而不用过多考虑这些特性。
让我们简要地看一下QNX RTOS的关键特性，并了解系统设计人员如何轻松地利用这些内置HA-ready特性来构建有效的HA系统。
四： HA的本质
QNX微内核架构的三个关键因素直接组成了HA的本质:
1. QNX Neutrino微内核
只提供一些基本的服务(例如消息传递和实时调度)。这样的结果就是能够提供一个健壮、可靠的系统——内核中代码行数越少，操作系统出错的可能性就越小。此外，内核的固定优先级抢占式调度器确保了一个可预测的系统----需要单独分析和处理的HA软件路径更少。
2. POSIX进程模型
这意味着系统进程之间的mmu支持的完整的内存保护，使得隔离和保护单个任务变得很容易。进程模型还提供了动态的进程创建和销毁，这对于HA系统尤其重要，因为您可以更容易地在现场执行故障检测、恢复和实时升级。
POSIX API提供了一个标准的编程环境，可以帮助实现系统简化、验证和验证。
此外，进程模型使您可以轻松地监视外部任务，这不仅有助于故障检测和诊断，而且还有助于服务分发。
3. 消息传递
在QNX实时操作系统中，所有进程间通信都是通过标准的消息传递进行的。对于HA系统，这有助于任务解耦、任务简化和服务分发。
本地和网络远程消息传递是相同的，对于应用程序实际上是透明的。在网络分布式HA系统中，基于QNX消息传递的方法可以促进复制、冗余和系统简化。
以上这些代表了一些比较突出的面向HA的特性，当QNX RTOS构成HA设计的基础时，这些特性就很容易显现出来。
