【QNX】高可用性框架HAM（1）：引言

                                            第一章 引言

一：本章内容

    •哪里出了问题?

    •HA的软件基础

二：问题在哪里?

        理想的高可用性(HA)系统是一种持续运行的系统，可以不间断地运行一段不确定的时间。在实践中，HA系统会争取“5个9”的可用性，即系统在一年内能够维持的正常运行时间的百分比——99.999%的正常运行时间，相当于每年大约5分钟的停机时间。

        很明显, 对于系统失败是由于这样或那样的原因造成的，系统没有按照用户和设计者希望的那样可用。在所有可能导致系统故障的原因中——断电、部件故障、操作人员失误、软件故障等等——其中软件故障占了绝大部分。

        许多HA系统试图解决系统故障的问题，是通过求助于硬件解决方案，例如:

    （1）加固硬件

    （2）冗余系统/组件

    （3）热交换CompactPCI组件

    （4）聚类

        但是，如果这些系统崩溃是由软件故障引起的，那么在这个问题上即使投入再多的硬件可能也解决不了问题。如果在恢复系统之后，系统内存的状态没有得到正确地恢复，那么该怎么办? 如果您的系统是一个HA系统(例如，一个消费设备)，而冗余硬件根本不是一个选项，又该怎么办? 亦或者，如果您的特定HA系统基于自定义机箱，而基于PCI的HA“解决方案”对这种机箱毫无意义，又该怎么办?

三：HA的软件基础

        大多数系统设计人员不会考虑使用“标准”桌面PC作为有效HA系统的基础。除了由硬件本身引起的可靠性问题外，底层软件并不适合连续操作。当桌面操作系统和应用程序需要修补或升级时，大多数用户都希望重新启动他们的计算机。不幸的是，作为日常操作的一部分，他们可能已经习惯于重新启动！

        但是在HA系统中，可能需要在活动系统上升级各种软件组件。各个模块应该便于分析和修复，同时不影响系统本身的可用性。

        我们认为，有效的HA系统必须通过模块化的系统设计和实现方法来解决主要问题——软件故障。基于微内核架构，QNX RTOS不仅有助于隔离整个系统中的问题区域，而且还确保了系统组件的完全独立性。每个组件都享有完整的基于MMU的内存保护。系统级模块(如设备驱动程序)可以从与任何其他进程相同的隔离和保护中获益。您可以启动和停止驱动程序、网络协议、文件系统等，而不需要触及内核。微内核RTOS从本质上保持单点故障(SPOF)数量尽可能低。

        QNX高可用性框架为构建高效的HA系统提供了可靠的软件基础设施。除了支持面向硬件的HA解决方案(例如CompactPCI和自定义硬件)之外，您还拥有在整个系统中出现软件故障之前隔离甚至修复软件故障的工具。

        例如，假设一个设备驱动程序因为试图写入分配给另一个进程的内存而崩溃。MMU将向QNX微核发出警报，后者将向高可用性管理器(HAM)发出警报。然后，HAM可以重新启动驱动程序。此外，还可以生成转储文件进行事后分析。

        查看这个转储文件，您可以立即确定哪行代码是罪魁祸首，然后准备一个修复程序，您可以在该字段中的所有其他单元遇到相同的错误之前将其下载。使用传统的操作系统，一个流氓驱动程序可能会运行几天，然后系统变得腐败到足以失败----然后再确定问题就太晚了，更不用说动态安装升级的驱动程序了！    

        HAM可以执行多级恢复，按一定的顺序执行多个操作。当序列中的各种操作之间存在严格的依赖关系时，这种技术是有用的，这样系统就可以将自己恢复到故障前的状态。

        配备了QNX Neutrino RTOS本身以及高可用性框架中的特殊工具和API，您就能够预测可能发生的各种问题，隔离它们，然后相应地进行计划。换句话说，假设故障会发生，您现在就可以针对它进行设计，并构建能够智能恢复的系统。

【翻译自：QNX官方英文文档 http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.ham/topic/about.html】