闫晓云:数据中心基础设施故障管理的最佳实践

本篇文章2953字，读完约7分钟

闫晓云:数据中心基础设施故障管理的最佳实践 数据中心的可靠性是最重要的，因此我们将在建设的早期阶段做大量的2N或N+1架构。在操作和维护方面，我们还将对数据中心进行巡视检查和维护。除此之外，我们认为数据中心的监控系统可以说是帮助我们发现数据中心监控状态的眼睛。

我叫严晓云，来自百度系统部。我主要负责百度基础设施监控和运维系统的研发。今天我想与大家分享的主题是数据中心基础设施故障管理的最佳实践，这也是2016年ODCC数据中心基础设施运营和维护最佳实践项目的延续。副标题是关于警报融合和监控架构。这是为了强调故障和警报是两个不同的概念，因为不是所有的警报都是故障，因为许多警报可能是由数据中心的正常运行引起的。因此，我今天的分享可以用一句话来概括:如果真正有意义的故障是通过处理数据中心中的原始警报而产生的，那么数据中心基础设施的故障管理就可以做得很好。

数据中心的可靠性是最重要的，因此我们将在建设的早期阶段做大量的2N或N+1架构。在操作和维护方面，我们还将对数据中心进行巡视检查和维护。除此之外，我们认为数据中心的监控系统可以说是帮助我们发现数据中心监控状态的眼睛。然而，在我看来，这种眼睛在数据中心实际上有许多问题，而最重要的一个问题恰恰是因为这种眼睛看到了太多的东西。例如，有一个实际的机房，大约有80，000台服务器。我数了两个多月的警报数据。你可以看到上面有许多要点。一个点表示数据中心在12小时内收到的警报数量。有160个点和160个12小时，也就是2个多月。每个点代表我们的数据中心在12小时内收到的警报数，12小时内最多收到5，800个警报，平均每小时610个警报，中位数超过300个警报。这是我们数据中心的真实案例，所以在我看来，这样的报警量很难满足数据中心运行和维护的要求。我认为警报至少有三个问题。

首先，这个数字实在太大了。一个接一个地处理这么大的数字是非常困难的。许多操作和维护同事已经直接批量确认。这样，批量确认可以省略一些重要的警报。

第二，这种警报不能直接定位故障的根本原因，特别是在一些重大故障的情况下，会有大量的警报在屏幕上不断闪烁，导致我们刚加入的一些新生感到恐慌，不知道发生了什么。

第三，我认为数据中心的许多警报系统并不总是反映数据中心的真实健康状况。举两个例子，我们使用了很多高压DC模块，这些模块也有很多坏的部分，所以我们也和我们的供应商谈，问他们有什么方法可以帮助我们提前发现模块的故障。制造商反馈的最有效方法是查看高压模块的内部温度。如果其温度相对较高，则表明其电源组件可能存在问题。然而，不幸的是，在高压模块中根本没有温度监控。它向我报告了大量的电压、电流和功率。到那时，它将不会对我们发现它的缺点产生直接影响。另一个例子是水泵。我们还与水泵供应商讨论了如何提前发现水泵故障。他给我们反馈来看它的振动信号。如果振动超过标准，发现泵逐渐变大，表明泵有问题。然而，同样的情况是一样的。水泵的监控信号中没有振动信号。因此，这些都是当前数据中心监控中遇到的问题。

在遇到这些问题后，我总结了两种帮助我们解决这些问题的方法。一个是警报过滤。通过设置一个合理的阈值，许多垃圾警报将被过滤。对于一些正常操作，可以根据情况提前阻止一些垃圾警报。另一个是报警位置，它可以帮助我们识别报警的根本原因和发现故障。例如，如果我们数据中心的专家站在我们数据中心的分布单线图上，他看到这个开关跳闸和那个开关跳闸，基本上他可以看到现在正在发生什么。事实上，我们可以抽象这种规则，然后将其固化到软件中。下一次出现这种情况时，我们的软件会自动做出判断。

但是它到底会怎样着陆呢？第一个想法是让工厂去做。当我们招标时，让工厂按照我们的要求去做。着陆时，让工厂根据投标执行此功能。但是现实往往有一些困难。首先，它没有那么灵活。制造商通常生产标准产品。他们提供给我们的产品的所有功能并非都能实现。此外，即使一些负责任的制造商按照我们的要求做了一些定制项目，在他们完成之后，尤其是各种管理系统，事实上，我们在未来还有很多维护要求。此时升级软件时，我们会遇到一些困难。因此，我们的公司，包括腾讯，以及我们的上层管理系统都是我们自己开发的。如果我们想做我们自己的研究和开发，实际上有两种方法，无论是百度还是腾讯，基本上都遵循这条路径。首先，基于制造商的警报，我们自己进行处理融合。我们通过制造商的界面收集信息，然后我们自己进行报警融合。另一种方式是我根本不相信制造商的警报。我不看任何制造商的警报和系统警报。我只收集制造商或设备状态的实时数据，然后由报警引擎根据收集到的数据进行判断。不管怎样，有两个重要的问题需要解决。一是基础数据的准确性和及时性，必须非常及时地发出警报，不能遗漏数据。一千个警报不能说。当你把它寄给我时，只有800个。这还不够，所以这两个问题都需要解决。

首先，让我们谈谈数据的及时性和可靠性。俗话说得好，如果你不能衡量，你就不能管理，如果你不能管理，你就不能提高。传统的数据中心架构是这样的。制造商在数据中心本地有一个监控系统，下面有一些采集器来采集被监控设备。然后，制造商通过接口将信息传输到我们的上级管理系统。该界面每天将发送数百个警报，因此许多警报无法逐个手动比较。在我们得到统计数据之前，我们还会收到许多警报。我们也认为界面不会有问题，但是当我们做统计时，我们发现这种情况仍然很严重。结果我们直接与供应商打开了一个数据库图，我们的上层制作了另一个软件从数据库中直接捕获底层的报警，然后与界面捕获的报警进行比较。结果对比发现情况比我们预期的要糟糕得多。然而，有了这样的机制，我们持续改进的基础已经建立。所以我们也发现了很多与操作者有关的界面问题。我们已经和他们来回谈了大约半年了。我们基本上可以说我们现在已经处理了接口问题。一天，我们的电池在一个小时内报告了40，000次警报，但没有一次没有被错过。

另外，如何进行告警融合，我们现在有两种方式来进行告警融合，比较常见的是告警融合引擎，在我们收集了所有的原始告警之后，我们将进行三重合并，基本的合并是在告警的开始和结束时合并告警，其次是在设备级别的告警，并且相同类型的告警将被合并在一起。还有系统级警报，根据警报顺序一个接一个地配备许多规则。报警规则生效后，系统将自动判断当前是否正在进行不间断电源或空音旋转，判断后最终会出现根本原因报警。另一种方法叫做故障预测引擎。我们将使用机器学习算法来查看其半小时和一小时的数据，如温度，包括泵的振动信号。根据它的学习数据，我们可以在半小时和一小时后基本上预测这个点的值。我们将比较预测值和实际值。如果两者之间的差异达到一定程度，我们将判断这一点是有问题的。

最后，我想说两个呼吁，希望以ODCC为平台，聚集产业力量，共同建设产业生态。一个是我们希望制造商能给系统增加数据层功能，使数据标准化，预测故障引擎，融合故障引擎，这样我们只关注系统中的规则，我们不需要自己开发引擎，也不是所有的用户都有能力自己开发引擎。此外，我希望我们能进一步简化接口和监控框架，统一收集器接口。这样，用户管理系统可以直接从收集器级别收集监控数据，而不必通过北方接口收集。这就是我今天分享的，谢谢！