OpenSolaris新特性解析之四:FMA

abcmike

http://bbs2.chinaunix.net/viewth ... 26amp%3Btypeid%3D79

这部分主要讨论FMA的一些特性，FMA和SMF一起构成了SOLARIS可预测性的自我恢复这个很显著的特点。

FMA全程是fault management architecture，错误管理框架，用于管理SOLARIS所运行平台上所发生的硬件错误，而SMF的另外一个功能就是管理SOLARIS平台上所发生的软件错误。

我们的讨论思路分两部分进行，第一部分先讨论我们硬件平台的主要错误种类和各种操作系统的处理办法，在这部分里面不会涉及到FMA的具体细节，第二部分里面我们将比较详细的讨论下FMA的具体框架是个什么样子。因为这部分所涉及到的硬件知识比较多，所以希望大家多多参与讨论。

我们的硬件平台只要由三个部分组成：CPU,MEM和我们的IO，IO部分就是我们的PCI总线（现在比较流行的PCIX,PCIE都是PCI的变种和改进，我们主要以PCI总线为例来说明）。那我们的硬件平台为什么会发生错误呢？主要是2个原因，一个是硬件自身发生了错误，比如我们的内存如果使用时间比较长，而环境中的静电比较多的话，可能产生内存芯片某部分被击穿的情况，这种错误是不正常的，需要更换硬件，另外一种是经常发生的，但是不会影响到我们的错误，硬件可以自动修补，还是以内存为例，我们知道内存和北桥的连接是靠总线，总线是什么，说白了就是一排并列的电线，来传递信号，为了简单的说明问题，我们假设总线的宽度是8位的，然后要传递的数据是01010101，由于信号之间存在着串扰，高的电平可能会干扰旁边低的电平变为高电平，传递到内存后就可能变成了11010101，这种数据是不对的，硬件系统通过校验和可以发现，然后再校正或重传，这种类型的错误是正常的，一定会发生，但是对我们没有影响。

所以我们对硬件系统错误的关注就集中到第一种类型上来。

这种类型的错误又分为3种，CPU错，内存错，PCI错误。对于CPU错，windows和LINUX的处理错误是一样的，依靠BIOS的代码，我们知道说开机后固化在eeprom里面的BIOS代码开始自解压到内存，然后就驻留在内存的低端部分，当CPU发生错误时在硬件部分是由MCA(mechine check architecture)机制来处理，并且引发中断，同时在CPU的MCA寄存器群里面保留了大量的错误信息，这种中断由BIOS捕获并进行处理，这种处理是简单的。在SOLARIS里面的处理方式是由FMA自己来处理的，由于是操作系统来处理的，所以可以完成更加强大和完善的功能。

对于内存而言，windows和linux而言，都不能够预测到内存可能出错，如果内存一旦出错，系统就只能hang住，而FMA的机制是可以预测到可能出错的内存。具体来讲，硬件的出错概率是比较小的，这种时候一般是由硬件重传，为了说明问题，我们假设内存读写出错的概率是1%，如果错误的概率小于 1%，我们认为正常，重读或者重写就行了，但是如果内存读写错误的概率大于1%，我们就认为这部分内存可能要出问题了，这部分出错内存的信息保留在内存条上面的一个小芯片里面，叫SPD，FMA从SPD里面读出这部分内存的系统地址（branch,rank,bank,column,row），然后根据北桥寄存器的信息转化为物理地址，再从系统的页表里面把这部分物理地址对应的页表淘汰掉，所以以后对内存的访问再也不会访问到这部分有问题的内存了，就像我们的有些硬盘工具一样可以把坏的磁道屏蔽掉，不让数据存放到上面。并且FMA将这个信息存放到log里面，通过SNMP发送到网管平台了，现在也有了第三方的工具可以把这个信息通过email发送出去，总之通知管理员那一根内存条快要坏了，请检测（比如擦掉上边引起静电的灰尘或者更换）。

对于PCI而言，我们知道现在PCI的错误分为两种PERR和SERR，PERR就是奇偶校验错，一般为串扰所引起，这种情况下，硬件机制直接将数据重传，如果几次重传都不成功，将引发SERR，即使系统错误，这个错误信号传递到南桥，南桥上面的一个寄存器和硬件将把这个SERR转化为NMI，就是非可屏蔽中断，这个中断传递到CPU,我们看到的现象就是WINDOWS出现了蓝屏，而LINUX直接HANG住，键盘和鼠标都没有了反映。在FMA里面不是直接这样处理，当发生SERR后，这个信号会先发到FMA模块，然后FMA找到是那个设备引起的这个错误，比如我们的网卡，然后FMA将这个网卡的寄存器初始化，再进行重传，如果重传不成功，FMA将会把这个网卡从系统中断开来，然后对这个网卡进行单独的重启，这个重启过程和我们开机的时候对网卡的重启过程是一样的，然后再连接到总线上，经过这个过程后，一般的设备都能够恢复正常。

从上面的介绍我们可以看出，SOLARIS在系统稳定性方面确实是做了相当多的工作，这也是SOLARIS在军方中使用很多的原因之一，对于我们平常的用户，这样的好处就是省心，很多工作solaris都帮我们做了或者是避免了。

好了，第一部分的介绍基本上上就完成了，下面将是第二部分。

FMA的架构分为3个部分，error handler, engine和agent。总的来说error handler发现系统中的错误或者是快要出错的地方，engine用于对这个错误进行分析诊断，然后把诊断结果发给agent,由agent来对这个错误进行适当的处理，见图1

具体来讲，error handler一般来说是我们的driver。同时我们可以在系统里面发现一个进程fmd，这个进程是一个调度器，engine和agent都attachd到这个进程上面，error handler发现错误后将错误形成error report发送给fmd，然后由fmd来决定这个错误报告应该发给那个engine，由engine来进行分析和诊断，然后将诊断结果再发给 fmd，fmd 转发给agent,再由agent来进行处理，同时fmd调度日志模块，将这个信息记录在日志里面。

有了这些知识，我们基本上可以使用FMA模块了，具体的命令就是fmadm，fmstat，fmdump，用法比较简单，大家可以man一下，或者看下solaris管理的书，都有的。我只简单介绍下就好了

1fmadm – 用来查询和更改Fault Management配置的命令。

2fmstat – 用来报告fmd和它的模块的静态信息的命令。

3Fmdump – 用来显示系统错误和系统故障信息的命令。


fmadm是用来查询和更改Fault Management配置的命令，包括了以下一系列的子命令：

    *      config – 显示Fault Management的配置,输出显示了系统目前已经加载的各种模块, 包括有分析引擎和Agent。
    *      faulty –  显示故障所在的资源。
    *      repaire – 替换错误的硬件后可以用这个命令来修正错误记录。

fmstat用来报告Fault Management daemon和它的模块的静态信息的命令

fmdump -v用来显示错误信息。里面会有个SUNW-MSG-ID,我们可以用这个值到http://www.sun.com/msg上面去� ... �和解决办法。

最后加上一个附件，这个附件是个FMA的demo，通过这个东西可以对FMA有更好的理解。
用法：
# ./run_fmdemo -d <demo_dir>

where demo_dir can be cpu, mem or pci

使用前记得前切换到root用户，使用说明在下面

Upon startup, the demo harness will pop up the following four xterm windows:

    * Error Log Monitor:  This window monitors the Solaris Fault Manager's error log.  As errors are detected by hardened drivers, the telemetry is captured into special events, called ereports, which are then dispatched to automated diagnosis engines for analysis.
    * Fault Log Monitor:  This window monitors the Solaris Fault Manager's fault log.  When a diagnosis engine determines that a fault has occurred, based in incoming error telemetry, it produces a special event called a suspect list, which lists one or components which are believed to be faulty.
    * Resource cache Monitor: The Resource cache, caches the state of hardware resources that have been the subject of a fault diagnosis.  The contents of the cache are persistent and, among other things, allows the fault manager to re-offline ASRU's after a system restart.
    * Console log Monitor:  This window monitors messages as they are logged to the console.  When the Solaris Fault Manager diagnoses a fault, a localized message is printed to the console which summarizes the fault condition and also provides a URL to an appropriate knowledge article on the Predictive Self-Healing Knowledge Web which provides detailed instructions on how to resolve the fault.