正如单机操作系统的内核，在阿里云OS中，飞天大规模分布式计算平台起到了承上启下的关键作用。飞天运行在通过网络互联的通用服务器集群上，隐藏了海量硬件所带来的复杂度和不可靠，向云OS的其他组件提供可信赖的的计算能力和存储能力。
具体来讲，飞天本身是一个由多个组件所构成的复杂的分布式系统，其中的核心组件是以下两个子系统。
在实现飞天云计算平台的过程中，工程师们面临了许多技术挑战，包括：
其中，不可靠的硬件是最基本的挑战。集群规模达到上千台后，单机上的小概率事件变成了必然的、频繁发生的事件。硬盘、硬盘控制器、CPU、内存、主板、电源等故障造成的宕机每天都会发生。这类硬件失效故障，我们称之为“硬”故障（fail-stop故障）。此外，还有一类故障现象不那么明显，称之为“软”故障，例如，磁盘可访问但速度只有正常的1/10、服务器没有宕机但程序运行缓慢、网络时好时坏等。这类“软”故障同样会影响服务质量，因为在线服务如果执行缓慢会造成客户端超时，而对离线作业而言，哪怕只有1%的数据处理任务缓慢，也会拖延整个数据分析作业的完成时间。
硬、软故障发生都会对系统的可靠性甚至可用性造成不良影响，因此如何及时有效地进行故障检测和恢复就变得比较关键。对于硬故障的检测业界已有成熟的方案，本文第一部分只重点讨论软故障的检测；本文的第二部分将集中探讨故障恢复策略相关的问题；最后，我们将介绍如何在保证数据可靠的同时满足在线应用的低延时需求。
云环境中的软故障检测
检测“软”故障有两种思路。
例子一：检测作业在某台服务器上执行特别缓慢的情况。
我们统计每个作业在每台服务器上的执行时间。因为输入数据被均匀地切片，每台服务器上的执行时间应该大致相同。如果某台服务器上执行时间超过了平均时间的三倍，它就被标记为“缓慢”。如果各种不同作业在某台服务器上都“缓慢”，那么我们有充分理由怀疑这台服务器有问题（但不知道原因）。调度系统会自动把这台服务器加入黑名单，不再用它执行作业。之后再自动或人工检查这些可疑服务器的具体故障原因。
例子二：检测磁盘读写慢的情况。
我们在分布式文件系统里也会统计每次磁盘访问的时间。如果某块磁盘有大比率的访问时间远远超过系统平均值，那么很有可能是这块磁盘快要发生故障了。文件系统此时会做三件事：
故障自动恢复的策略
在检测到故障后，需要有自动及时的故障恢复机制。然而，故障自动恢复机制一旦没有考虑周全就会成为一把双刃剑。让我们从Amazon云服务那次严重的事故说起。
Amazon EC2大规模停机事件
2011年4月21日，Amazon的虚拟主机服务EC2发生大规模停机，时间超过两天，影响波及Reddit、Foursquare、Quora等众多网站。事后Amazon对此次事故作了详细分析。事故起因是Amazon对集群网络作日常维护升级时操作错误，网络流量被全部切换到备用网络，导致备用网络过载。自动故障恢复机制检测到网络不通，认为服务器大量宕机，马上开始数据复制以替换“宕机”的服务器上的数据副本，引发了“镜像风暴”（大量服务器同时尝试创建数据镜像）。而由此增加的数据流量更加剧了网络过载，从而使故障在集群中蔓延，进入恶性循环。最终采取了包括暂时关闭自动故障恢复系统和增加硬件在内的多种措施，服务于故障发生两天半以后恢复。
在此案例中，故障自动检测和恢复的策略是“在数据副本所在服务器失去联系时，复制数据”。这一策略对“一台服务器故障”这种小范围的常见问题很有效，然而在大范围故障如“网络过载”的场景下，可能会起反作用。在这个案例中，如果根本没有故障自动恢复机制，故障影响范围反而不会有那么大。
实际上，这一模式在过去的大规模分布式系统故障中反复出现：发生了未曾预料到的、中小范围的故障
→故障自动恢复机制采取了错误的手段
→故障恶化，进入恶性循环
Amazon S3存储服务2008年的故障就仅仅是由于故障自动检测机制的自身状态中一个bit出错，然而故障同样迅速蔓延到整个系统，导致服务在没有发生硬件故障的情况下不可用。
对此，我们的策略是限制故障自动恢复机制的作用范围：
以前面提到的硬盘访问变慢为例：考虑到硬盘平均日故障率小于千分之一，我们给前述的疑似问题硬盘自动下线机制设置上限，例如，任何时候只能通过此机制下线总数1%的硬盘。此限制可以防止极端情况下，如大量硬盘出现问题，或者自动下线机制本身故障时，故障恢复机制本身不会引发灾难。
数据可靠性和实时性能优化
云环境中，由于分布式系统有硬件故障多发的特点，保证数据可靠性成为文件系统的一个挑战。
在飞天云计算平台的实际运营中发生故障最多的硬件是硬盘。硬盘故障占阿里云数据中心故障总数的80%。原因之一是硬盘是数量最多的部件，例如一个3000节点的集群就有30000多块硬盘，即使硬盘本身的平均无故障工作时间（MTBF）达到1,000,000小时，30000块硬盘也意味着平均每33小时就有一次硬盘故障发生。实际运营数据显示硬盘厂家标称的MTBF值并不可靠，生产环境的硬盘故障率可以几倍到几十倍于标称值。
硬盘故障最直接影响的就是盘古分布式文件系统。为了保证数据安全性，盘古文件系统对所有的数据均采用了多份拷贝。在创建文件时，用户可以指定文件数据的拷贝数目，文件系统会保证数据分布在不同的节点和不同的机架上，使得单个硬件故障不会造成数据无法访问。
多副本技术是业内广泛认可的有效防止数据丢失的技术，通常采用流水线方式传递写需求以减轻单个节点的负载。但这会导致数据写入的延迟增大，因为只有当所有副本都写成功后才能结束一个写操作。
由于磁盘读写特性，上述多副本写入磁盘的延迟通常在几十毫秒量级，有时可达100毫秒以上。云环境中的线上应用，有时会有更高的实时性要求。盘古通过内存日志文件（in-memory redo log）来解决此问题。
内存日志文件的基本思想基于以下事实：虽然服务器因为掉电或者宕机丢失内存数据的概率高于硬盘损坏的概率（所以在单机系统中我们会把日志文件写入磁盘以避免内存数据丢失），但多台服务器同时故障的概率却可以低到能够满足数据可靠性的要求。对于实时性要求高的应用，盘古提供接口，使得数据文件进入指定数量服务器的内存即可认为是写成功；盘古的后台线程随后会把内存中的数据批量写入磁盘。
盘古在保证内存日志的可靠性和低延时上做了如下考虑。
保证redo log是多份拷贝的，避免单机故障造成数据损坏或丢失。
为降低写入延迟，确保redo log写入多个数据服务器内存buffer后即返回成功，由后台工作线程保证内存数据在很短时间内持久化到磁盘。
严格检测redo log数据的健康状态，并及时采取补救策略确保数据的可靠性。
分布式系统的一个优势是对单点故障的屏蔽：数据的可靠性通过多台服务器间的复制备份得到极大的增强。对于单机，内存数据是易丢失的；但在多机环境下，如果能保证服务器不是同一时间宕机，并辅以严格的策略保证，内存数据在不降低可靠性的情况下，可以极大地提高性能。阿里云的数据中心保证了很好的硬件隔离和冗余，并备有UPS等应急措施，为我们提供了使用内存缓冲的良好硬件环境。
下面主要介绍我们在内存文件数据可靠性上的一些考虑。
写入内存阶段
确保多个数据服务器成功接收数据并放到内存buffer中（这点是redo log的设计基础）。
选择数据服务器充分考虑硬件的隔离性，避免故障的关联。
在接受数据时数据服务器判断自身的健康状态：
所写的磁盘状态是正常的，并且剩余空间足够；
当前的workload状况良好，比如内存和I/O队列没有超负荷。
内存到磁盘持久化阶段
限制从内存buffer到磁盘I/O的最长时间（30秒内）。
发现写入超时后（比如磁盘异常慢或I/O请求超载），立刻通知master服务器进行复制备份。
当发现写入异常（磁盘坏或者满等）后，立刻报警，通知master复制。
检测与复制阶段
可以看出，写入内存阶段的策略是预防措施；内存到磁盘持久化阶段最危险，我们确保这个阶段尽可能短（保证预期性能的情况下给出最长写入时间），并在确认出错后及时采取措施；检测与复制阶段是典型的磁盘坏掉但保证数据不丢的策略。
小结
在设计和实现飞天云计算平台过程中，工程师们花费了大量努力来应对海量硬件所带来的可靠性的挑战。本文叙述了部分设计思路但远远不是全部。锤炼一个健壮的大规模分布式系统一定需要良好的设计、精致的实现以及严格的测试。有了飞天这个稳定可靠的云OS内核，各种丰富的云计算服务及应用便有了生存、长大的肥沃土壤。我们随后将会介绍的各种云服务，正是运行建立在阿里云自行研发的飞天云计算平台上。
