大规模集群管理和运维自动化

栏目: 服务器 · 发布时间: 6年前

内容简介：说到大规模集群管理，就离不开运维自动化。一个人手工也许可以运维几百台机器，但是随着集群规模的增长，我们需要的是一个人运维数万台机器。这在大规模集群管理中是一个常见的问题。因此，运维自动化是一个很重要的事情，这也是为什么很多公司原因上云，因为上云之后运维的问题就托管给云平台了。这也是云平台这么贵还能卖的这么好的原因。运维自动化的问题到底是一个什么问题？我认为，可以拆解为以下子问题：这里的每一个问题都是复杂的，困难的问题，远非表面上看起来那么简单。以下仅作简单的展开，提供一些思路。

说到大规模集群管理，就离不开运维自动化。一个人手工也许可以运维几百台机器，但是随着集群规模的增长，我们需要的是一个人运维数万台机器。这在大规模集群管理中是一个常见的问题。因此，运维自动化是一个很重要的事情，这也是为什么很多公司原因上云，因为上云之后运维的问题就托管给云平台了。这也是云平台这么贵还能卖的这么好的原因。

运维自动化的问题到底是一个什么问题？我认为，可以拆解为以下子问题：

自动发现错误
自动修复错误
安全（Safety 而非 Security）

这里的每一个问题都是复杂的，困难的问题，远非表面上看起来那么简单。以下仅作简单的展开，提供一些思路。

自动发现错误

我们先简单的将错误划分为两类：硬件错误和软件错误。

硬件错误

通常，商业硬件都会提供一些接口用于获取硬件错误信息，这些错误信息是由硬件自检产生的，例如硬盘 S.M.A.R.T。通过这些接口报告的错误信息是比较准确的。但是还有一些情况，虽然硬件出问题了，但是硬件自检没有检测到。这种情况也会影响运行的软件，需要通过其他方式进行检测。这种问题通常是由业务方发现异常，排除软件错误因素后，或由统计结论导出，确认为硬件问题。具体是什么硬件问题，还需要离线进行进一步检测。

还有一类特殊的硬件错误，发生点不在本机，但是也会影响服务，即网络错误。网络错误根据现象一般有以下分类：

传输内容错误，例如数据位反转
大量丢包，例如 CRC 校验莫名出现大量错误，但是实际上没错（有可能是硬件错误，也有可能是系统内核错误）
带宽下降，例如交换机错误
连接丢失，例如交换机错误

由于网络错误不一定发生在本机，因此很难通过单机定位问题，通常通过 PingMesh 结合其他手段发现问题，例如流量监控，内核关键 metric，交换机关键 metric。最近的新方向是结合 SDN 和机器学习发现并解决网络问题。

软件错误

软件错误的类型五花八门。通用的检测和容忍错误的机制是复杂而困难的（例如拜占庭问题），所以要允许用户灵活方便的扩展错误发现规则。一般来说，软件错误有以下几种：

操作系统错误
依赖环境错误
数据错误
配置错误
自身 bug

自动修复错误

通用的解决所有问题的方案（大概率）是不存在的，但是我们又不能完全为每一个特殊的错误定制修复的方法。对于硬件故障，我们只有换机器一条路可走。对于操作系统的问题，通常重启即可解决问题，如果不能解决问题，可能需要重做系统。重做系统也涵盖了系统升级的需求（考虑到有些时候需要升级内核才能解决问题）。数据错误需要使用强 checksum 校验，具体需要多强，需要覆盖多大范围，则是一个仁者见仁智者见智的问题。配置错误和自身 bug 其实是部署需要解决的问题，如果能够及时发现问题，只需要在部署的过程中中止并回滚即可解决问题。而如何部署，又是一个可以写一篇文章的大问题了:D

安全

自动化最担心的问题就是安全。不能保证安全会导致可怕的后果，例如瞬间几万台机器被重做系统。在大规模集群管理中，所谓安全，实际上指的是安全规则，安全规则保证的则是 SLA。可预期的 SLA 通常由 MTBF（Mean Time Between Failures）计算得出理论上限。自动修复会导致理论 MTBF 降低，这是因为我们通过错误发现机制在建模的时候考虑了更多的错误因素。重启服务，重启机器，重做系统，换机器，都会导致服务中断。我们可以认为，在错误修复期间，这台机器上的服务不可用。此时，如何有序的保证剩下的可用机器总是大于一定数量（并且满足一定规则），则是安全的核心。

以上所述就是小编给大家介绍的《大规模集群管理和运维自动化》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对码农网的支持！