互联网普及的20年来,尤其是近10年移动互联网、互联网+的浪潮,使互联网技术渗透到各行各业,渗透到人们生活的方方面面,这带来了互联网服务规模和数据规模的大幅增长。日益增长的服务规模和数据规模带来数据中心的急剧膨胀。在大规模的数据中心中,传统的运维方式已经不能满足规模化的需求,于是基于自动化调度的集群管理系统纷纷涌现。
这些系统往往有一个共同的目标,就是提高数据中心的机器利用率。在庞大的数据中心服务器规模下,平均利用率每提高一点,就会带来非常可观的成本节约。这一点我们可以通过一个简单的计算来感受一下。假设数据中心有N台服务器,利用率从R1提高到R2,能节约多少台机器?不考虑其他实际制约因素的情况下,假设能节约X台,那么我们有理想的公式:
N*R1 = (N-X)*R2
=> X*R2 = N*R2 – N*R1
=> X = N*(R2-R1)/R2
如果我们有10万台服务器,利用率从28%提升到40%,那么代入上述公式有:
N= 100000(台),
R1 = 28%,
R2 = 40%
X=100000* (40-28)/40 = 30000(台)
也就是说10万台服务器,利用率从28%提升到40%,就能节省出3万台机器。假设一台机器的成本为2万元,那么节约的成本就有6个亿。
但是遗憾的是,根据盖特纳和麦肯锡前几年的调研数据,全球的服务器利用率并不高,只有6%到12%。即使通过虚拟化技术优化,利用率还是只有7%-17%;这正是传统运维和粗放的资源使用模式带来的最大问题。调度系统的主要目标就是解决这个问题。
通过资源的精细化调度,以及虚拟化的手段,比如Virtual Machine或容器技术,让不同服务共享资源,堆叠高密部署,可以有效的提升资源利用率。但是这种模式对在线业务的应用上存在瓶颈。因为在线业务间的资源共享,高密部署会带来各个层面的资源使用竞争,从而增加在线服务的延迟,尤其是长尾请求的延迟。
对于在线业务来说,延迟的增加往往立刻反应到用户的流失和收入的下降,这是在线业务无法接受的。而近年来随着大数据的普及,对实时性要求并不高的批量离线作业规模越来越大,在资源使用上,逐渐和在线业务的体量相当,甚至超过了在线业务。于是很自然想到,将离线业务和在线业务混合部署在一起运行会怎样?能否在牺牲一些离线作业延迟的情况下,充分利用机器资源,又不影响在线的响应时间?
阿里巴巴从15年开始做了这个尝试。在这之前,阿里内部针对离线和在线场景,分别各有一套调度系统: 从10年开始建设的基于进程的离线资源调度系统Fuxi(伏羲),和从11年开始建设的基于Pouch容器的在线资源调度系统Sigma。 从15年开始,我们尝试将延迟不敏感的批量离线计算任务和延迟敏感的在线服务部署到同一批机器上运行,让在线服务用不完的资源充分被离线使用以提高机器的整体利用率。
这个方案经过2年多的试验论证、架构调整和资源隔离优化,目前已经走向大规模生产,并已服务于电商核心应用和大数据计算服务ODPS业务。混布之后在线机器的平均资源利用率从之前的10%左右提高到了现在的40%以上,并且同时保证了在线服务的SLO目标。