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

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

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

  1. 自动发现错误

  2. 自动修复错误

  3. 安全(Safety而非Security)

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

自动发现错误

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

硬件错误

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

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

  1. 传输内容错误,例如数据位反转

  2. 大量丢包,例如CRC校验莫名出现大量错误,但是实际上没错(有可能是硬件错误,也有可能是系统内核错误)

  3. 带宽下降,例如交换机错误

  4. 连接丢失,例如交换机错误

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

软件错误

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

  1. 操作系统错误

  2. 依赖环境错误

  3. 数据错误

  4. 配置错误

  5. 自身bug

自动修复错误

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

安全

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