云操作系统设计漫谈

思考的牛

面对当前急速膨胀的数据存储和处理需求，即便再强的单机(如小型机)也无法满足，所以我们不得不借助于规模化的集群系统来处理。而如何将集群机器的计算资源和存储资源进行合理组织、运用和调度，则是目前大中型数据中心首要面对的问题，如果解决不好不但会造成资源浪费严重，还会造成管理成本居高不下，尾大不掉。

本文将以我个人经验谈一谈面向大型数据中心资源管理问题——我们知道单机上的硬件资源(处理器、硬盘、内存、外设等)的管理和任务调度由操作系统全面负责，那么我们放大资源管理和任务调度的范畴，从单机域扩展到整个数据中心范畴考虑，则应该存在一种能够全局把握和管理数集群资源(与单机相比，还包括机柜、网络设备等资源)，并能负责集群范围内任务调度的智能系统，我们不妨称其为云操作系统——本文将重点讨论云操作系统的实际目标、理念，以及可能的实现。

一、建设目标

云操作系统所要实现的目标主要有三个：一是整合资源。即整合IDC内的所有服务器资源，包括CPU、内存、磁盘等，以对外提供服务。对于大型IDC而言(服务器规模超过5000台以上)，其资源总和相当可观，再加上资源复用运用，几乎视为资源无限;二是资源位置透明。即所有资源位置对应用透明，应用不再关心资源位置;三是实现绝对的高可用性，永不宕机，最大程度保证数据和服务的安全性。

同时，我们在设计和实施云操作系统时，必须考虑以下理念和实际运行场景。

机器廉价化。我们云操作系统的实施前提是大规模、低成本。因此不使用专用服务器和专用存储，而使用廉价PC服务器(所有的存储资源将借助于机器自带的SATA盘或者SSD盘)。设计和实施规模在上千台到1万台服务器。

故障常态化。大规模地使用廉价机器(包括廉价网络设备)无疑代表着故障频发，对于这种系统故障常态化场景，云操作必须做到透明failover(失效转移)，才能做到高可用性。

资源池化。这点是云操作系统中最重要的理念之一，所有资源要尽量池化才能做到资源利用和复用最大化。目前看来，磁盘存储资源可以做到完全池化——因为千兆网络带宽和磁盘带宽近似，所以可将所有磁盘资源完全池化，从而每个单机上的任务可采用拉模式(pull模式)访问集群中被池化的磁盘资源;而计算资源(CPU和内存我们都归为计算资源)只能做到半池化——还是因为千兆网络带宽比内存或CPU带宽相差多个数量级，所以无法将内存和CPU资源彻底池化。计算资源只能使用推模式(push模式)方式访问，也就是下发任务到计算资源所在机器运行。如果是单机资源不足运行任务，则需要将大任务拆分为单机资源能满足供给的子任务，化整为零式分布执行。

接管所有资源。理想情况下，云操作系统应尽力接管所有的资源分配和使用,包括内存、计算、I/O等。尽量避免任务直接访问资源(如禁止执行malloc,write\read Connect等系统函数，只能使用受限的指定接口访问资源)

应用混合部署。各种不同应用应该混合部署，机器不再被应用独占。

应用资源访问受限。应用访问资源必须受限，从而避免混合部署的资源争用，因此所有应用实例都要受节制，都需要在受限“沙箱”(“沙箱”仅仅是个逻辑概念，有很多种实现方式，例如cgroup，虚拟机等)——中运行。

应用服务上下文非本地持续化。只有保证服务上下文非本地存储(share nothing)，才能保证任务的迁移、扩展和与运行位置无关。

应用(任务)资源描述、提交、执行标准化。应用按任务方式提交给云操作系统，提交时需要描述任务中的各角色，以及各角色实例的资源配额。例如，一个key value服务角色有master role和slave role两种，同时指明master单一实例的资源配额，slave多实例的资源赔额和实例数量。云操作系的任务调度部分，将按应用的资源描述，选择资源配额充足的物理机启动“沙箱”运行实例(配额限制内运行应用实例)。另外，云操作系统任务调度部分，也要支持runtime式的按需分配新的运行容器，供需要的新实例运行。例如key value的master发现slave实例数目不足时，可要求分配给其新的容器运行新slave实例子(也就是扩容)。

应用故障恢复尽量标准化，但要有所为有所不为。对于多数应用的故障恢复应实现统一化：当发现应用实例故障后，云操作系统再从资源池中分配一个运行环境加载应用实例。但允许应用自己管理failover过程。尤其对于基础性应用，其可用性要求高，很可能需要自己采用主从热备方式、多点提交方式或者其它“奇技淫巧“满足可用性需求，因此对于这种智能要求高的应用，应该允许其自己接管故障恢复等行为。所以云操作系统要张弛有度，不能太集权化。

傻瓜型运维。运维人员只需要负责故障机器下架和标准机器上架。上架后保证机器自动自我配置，且在无需干预情况下自动加入集群。简单的说，不需要IT人员驻留机房现场运维。

二、设计思路

要设计一个面向大中型数据中心的云操作系统，主要考虑以下九大功能模块：

数据总线。数据总线是集群操作系统的基石，负责数据中心内的机器间的消息通讯。数据总线建立在TCP/UDP协议之上，实现点播、组播等功能。且满足异步、同步消息推送、订阅等功能。

分布式存储系统。磁盘存储资源池化，离不开一个分布存储系统。该系统应该实现高可用性、高数据安全性、高吞吐和低延迟。

运行容器。负责任务运行的资源隔离服务，接管一切资源申请，避免不同任务之间的资源争用。

驻机精灵。负责任务运行全生命周期管理，而且还要负责机器健康监测和程序下载等任务。

资源分配中心。资源分配中心管理集群中所有机器的资源信息和位置信息，并且还负责根据应用的资源请求，为其分配可用的物理机，在其上启动运行容器，运行给定实例(也可理解为资源调度中心)。

全局命名中心。服务实例都配以全局逻辑名，各实例之间寻址都使用逻辑名。这些逻辑名和具体的物理IP和端口的映射关系管理由全局命名中心负责。

配置管理中心。配置中心为各应用实例提供了一个配置信息的集中存储地，各应用实例不再本地存储各自配置，而是集中存放。

分布式锁。分布应用中难免有需要串行化完成的动作——任务需要有序执行，或者有需要保护的临界资源——一个时刻只能一个实例访问，这无疑需要分布式锁支持。

故障监控服务。应用实例是否正常运行，异常情况如何发现，这些都是分布系统通用性要求，因此故障监控服务不能缺少。

云操作系统的核心部分应该就是笔者所描述的这些了。不过若要满足前文中提到的应用服务上下文非本地存储，那么可能还要提供一些上下文存储需要用到的存储服务，例如key value服务、No Sql服务、数据库服务、graph DB等在线数据服务等，这些都应该属于云操作系统范畴。

补充说明一下，本文中云操作并非OpenStack以及类似的私有云概念,当前的私有云概念主要面向虚拟机管理领域，而云操作系统面向的是管理IDC所有资源(池化资源、调度资源、恢复资源等)。但这并非说虚拟机和云操作系统对立，因为在我个人看来无论机器虚拟机(machine virtual machine,例如Xen,KVM)或者是系统虚拟机(system virtual machine,如Zone，vps)都可以是云操作系统中一种资源容器(沙盒)，只不过这种容器相对而言很重，我们实践中更希望借助于更轻的方式做资源容器(例如cgroup等)。

【作者简历】
康华，2000年7月获得西安邮电学院计算机软件学士学位，2003年获得西北大学计算机理论与软件硕士学位。日前任职百度，负责key value等存储项目。之前曾在阿里负责弹性云项目，还曾在简网、联想研究院和摩托罗拉任职。主要关注的技术领域有云计算基础架构研发、虚拟化技术研发和操作系统内核研发等。

yuhongweixtjc

大师级的分析，但云操作系统仍显得较远，云落地是个难题．