软件定义的“可靠性”到底可不可靠

李进才

服务器宕机可能是很多运维工程师最可怕的噩梦。谷歌的一项研究表明大多数死机故障是由内存问题引起的，而且每年有1/3的谷歌服务器都会出现可纠正的内存故障，而有1 %的谷歌服务器会出现不可纠正的内存故障，后者是造成系统宕机的典型情况之一。

如果有人说，用软件的方式，可以解决硬件的内存问题，还能减少30 %的服务器宕机故障，你觉得可靠吗？

当前的数据中心已经走向软件定义的时代，从最初的软件定义网络SDN到软件定义数据中心SDDC。为了防止服务器宕机的意外发生，越来越多的企业开始考虑软件定义的解决方案，并通过软件定义的可靠性屏蔽服务器、内存等硬件故障带来的影响。那么软件是如何实现对内存以及服务器可用性的提升呢？

内存故障非常多，就看系统能不能识别出来，有些故障是内存单个或多个bit故障，有些是内存颗粒故障，有些是内存颗粒上的单行或单列的存储单元出现故障，还有firmware故障、内存控制器故障。另外还有一些是内存金手指焊接点老化、主板上的内存插槽松动或有灰尘等引起的故障。

器件质量类的故障只能通过工艺的改进来解决，而信服云要解决的是软件层面可以控制的bit级故障。往往大故障来自于bit级小故障的持续积累，这时要做的就是“防微杜渐”，在小故障发生的时候就抓住它、隔离它，避免影响扩大。

Intel有一种机制叫做MCA（MachineCheck Architecture），可以监测这种类型错误。这个机制的运行方式是：首先需定义出这些错误模型，把可以自动纠正的错误叫做CE（Correctable Error），这些往往是任意单比特错误、部分是单颗粒比特的错误。但是一些错误无法自动纠正恢复，会导致系统宕机，这些错误被定义为UCE（Uncorrectable Error）。根据统计，CE/UCE类的问题类型占内存所有类型问题的59 %，所以，如果能够设计一种故障检查和纠正的机制，其价值会非常大。

这个全套的错误检查和纠正的机制就是ECC（Error Checking and Correcting）。ECC在遇到故障时首先会进行问题识别，通过设计内存主动扫描机制，可以设置一天24 h不休（也可以调整）扫描和发现故障。识别后判断故障位置（这里其实用到了一些特殊的bit计算和校验算法），认定故障位置后，就尝试隔离有问题的内存空间，避免后续业务再次使用该内存空间。

业界主流的IT服务商都会利用Intel的MCA机制进行内存错误处理，但是其软件实现的精细化程度不一，比如有些服务商只是把CE错误屏蔽掉，或者只是简单的告警，没有做进一步处理；还有一些服务商即使有告警但是无法准确定位到发生问题的插槽。而信服云则提出了一个风险区机制，一旦发生内存错误，就将问题单元置于一个“缓冲区”进行观察，当CE错误达到一定阈值则立刻自动隔离有风险的内存区域，避免错误继续扩大引起严重的宕机。

近年来，信服云在内存隔离恢复机制上不断优化，2022年1月推出的超融合HCI6.7.0中还对ECC机制进行了增强。该增强机制的运行方式是：首先通过CPU的BIOS设置CE Record选项，使得硬件识别出内存错误，一旦发现CE/UCE错误，硬件就会把这个错误上报给信服云的软件。然后轮到软件机制上场，OS系统先是判断这个内存是否被软件（包括应用软件和操作系统）使用，如果没有使用就直接隔离，不允许再分配给软件使用。

如果被软件使用了，就获取软件的上下文，判断区分其是被操作系统内核（in_kernel）还是被用户应用软件（in_user）使用。

如果是被应用软件（in_user）使用，对于CE可纠正错误，信服云的内存ECC增强机制就用一块好的内存区域替换掉有错误的内存区域，这个过程中业务完全不受影响。如果是UCE不可纠正的错误，该机制就重新启动该进程，把错误的内存区域释放出来并隔离出去不再使用，进程重启后就可以使用完全正常的内存了。

如果是被操作系統内核（in_kernel）使用，其内存ECC增强机制就把有错误的内存区域的信息记录下来，在系统再次启动的时候，该机制会隔离这些有错误的内存，以保证不会被再次使用。

推出上述机制后，信服云在1 000台主机环境中进行了验证。结果证明，通过软件控制的ECC机制，能够提前发现内存异常，并且100 %自动隔离成功，提前处置以规避更大的故障影响，总体上相对原有方式能够减少30 %的服务器宕机故障。

回到开头的问题，用软件可以解决硬件层面带来的问题吗？毫无疑问，当然可以。信服云的ECC机制就通过创新性的软件技术，更加准确、智能地控制了服务器的内存故障，有效地提高了IT系统的可靠性。