【IT168 技术】正如单机操作系统的内核，在阿里云OS中，飞天大规模分布式计算平台起到了承上启下的关键作用。飞天运行在通过网络互联的通用服务器集群上，隐藏了海量硬件所带来的复杂度和不可靠，向云OS的其他组件提供可信赖的的计算能力和存储能力。

　　具体来讲，飞天本身是一个由多个组件所构成的复杂的分布式系统，其中的核心组件是以下两个子系统。

　　计算资源调度系统(又称伏羲)：管理和调度集群计算资源;在多个云服务间动态分配计算资源，以满足用户的计算需求;自动检测服务器故障并迁移故障服务器上的服务。

　　分布式文件系统(又称盘古)：管理集群的所有硬盘;合理地安排数据存放位置以兼顾性能和数据安全性;自动检测磁盘故障并复制数据以保证安全。

　　在实现飞天云计算平台的过程中，工程师们面临了许多技术挑战，包括：

　　在不可靠硬件基础上提供高可靠的计算能力和存储能力;

　　提供高可用服务;

　　低成本运维海量硬件;

　　在线应用与离线应用并存;

　　克服节点间带宽的限制;

　　最大化利用计算资源，等等。

　　其中，不可靠的硬件是最基本的挑战。集群规模达到上千台后，单机上的小概率事件变成了必然的、频繁发生的事件。硬盘、硬盘控制器、CPU、内存、主板、电源等故障造成的宕机每天都会发生。这类硬件失效故障，我们称之为“硬”故障(fail-stop故障)。此外，还有一类故障现象不那么明显，称之为“软”故障，例如，磁盘可访问但速度只有正常的1/10、服务器没有宕机但程序运行缓慢、网络时好时坏等。这类“软”故障同样会影响服务质量，因为在线服务如果执行缓慢会造成客户端超时，而对离线作业而言，哪怕只有1%的数据处理任务缓慢，也会拖延整个数据分析作业的完成时间。

　　硬、软故障发生都会对系统的可靠性甚至可用性造成不良影响，因此如何及时有效地进行故障检测和恢复就变得比较关键。对于硬故障的检测业界已有成熟的方案，本文第一部分只重点讨论软故障的检测;本文的第二部分将集中探讨故障恢复策略相关的问题;最后，我们将介绍如何在保证数据可靠的同时满足在线应用的低延时需求。

　　云环境中的软故障检测

　　检测“软”故障有两种思路。

　　一种思路是针对每种具体故障设计检测方法。但“软”故障产生的原因可能很多，例如执行缓慢可能是服务器硬件故障、网络故障、磁盘故障、操作系统软件故障等，逐一检测会使系统过于复杂。

　　另一种思路是从宏观现象来检测，下面看两个例子。

　　例子一：检测作业在某台服务器上执行特别缓慢的情况。

　　我们统计每个作业在每台服务器上的执行时间。因为输入数据被均匀地切片，每台服务器上的执行时间应该大致相同。如果某台服务器上执行时间超过了平均时间的三倍，它就被标记为“缓慢”。如果各种不同作业在某台服务器上都“缓慢”，那么我们有充分理由怀疑这台服务器有问题(但不知道原因)。调度系统会自动把这台服务器加入黑名单，不再用它执行作业。之后再自动或人工检查这些可疑服务器的具体故障原因。

　　例子二：检测磁盘读写慢的情况。

　　我们在分布式文件系统里也会统计每次磁盘访问的时间。如果某块磁盘有大比率的访问时间远远超过系统平均值，那么很有可能是这块磁盘快要发生故障了。文件系统此时会做三件事：

　　停止写新数据到这块磁盘，防止更多数据处于危险中;

　　开始为这块磁盘上的数据增加更多副本;

　　当这块磁盘上的所有数据都有额外的副本，就可以将它下线，待运维处理。

　　故障自动恢复的策略

　　在检测到故障后，需要有自动及时的故障恢复机制。然而，故障自动恢复机制一旦没有考虑周全就会成为一把双刃剑。让我们从Amazon云服务那次严重的事故说起。