2018-08-14 14:00
鲍永成：各位嘉宾下午好，我是来自京东的鲍永成。题目是数据中心的资源调度。
随着数据中心的发展，从虚拟化到容器化到编排，包括现在的微服务等等，这些都在不断的发展，有另外一个问题，随着数据中心的规模不断扩大，数据中心资源使用提升的问题，所以我们在京东的J也就是二次开发的版本，这个基础上完成了京东所有业务的上容器之外，从去年双11开始就上线了阿基米德调度，带来的巨大的经济收益。如果大家数据中心到了一定规模、容器也到了一定规模之后，我相信或多或少都会往这个方向去走。
说起调度，调度是与数据中心的很多资源有关，比如服务器、网络，还有集群管理编排等等，没有前面这些若干步骤，你没有办法直接调到资源调度的，这里面涉及到很多问题，比如容器的轻量化部署和迁移，因为资源调度是非常复杂的。
阿基米德整个获得的收益，整个数据中心的CPU、内存、能耗等等都有很好的一个提升。阿基米德是在JDOS上产生的，把它的负载平衡、日志、监控中心等等这些内容全部重新做了一遍，原有数据中心的内容都能满足，今天重点讲阿基米德。
阿基米德调度系统服务对象主要是三个：中间件及数据库、在线业务和数据计算。很多公司并不是全球性的公司，有很典型时空利用率，后半夜这么长的时间，资源使用率非常低。这时候想到，上面绿色的线是大数据，还有一些在线实时的计算等等这样一些资源使用的情况。还有一个比较重要的一点，绿色的部分，用户在申请资源的时候，不管你用容器还是虚机并不能解决资源使用率的问题，这个时候并不能真正使用到资源，有的申请了说我要八个核其实只使用了一个核。但如果你用传统方式给做资源的收缩之类，会带来很多的不便。比如你用虚机可能比较重，但如果用容器说我申请八个核可能99%的时间用不到八个，但我要用到八个核了会怎么样，这就涉及到调度的问题。你不能再使用简单的鲁棒性非常差的方法。
我们把调度任务分两大类，在线业务，在线业务与离线计算任务混合的。不管你如何调度，通过算法还是各种能力，最终到达一个瓶颈40%上下就很难往下走了。你只能把离线任务和在线任务做一个混合，但它也有瓶颈，如果你把整机的CPU80%以上还是会影响在线业务，不管你用虚机还是容器，最后的隔离并不彻底。有些把CPU拔高了，就会抢占其他的CPU，所以我说在不影响业务原有服务质量的情况下做资源调度。
在线业务，能把整个CPU的监控图能提升上一个台阶，提升百分之三四十是没有问题的，但再往上提升问题就来了。所以这时候需要用离线任务补充，那你也不可能把每个CPU都达到80%以上。
整个监控数据建议大家用秒，因为分钟级是达不到要求的。现在我们数据中心规模非常之大，用的是全秒级监控的采集，那也是非常大的代价，需要有非常好的JDOS的集群，否则的话没有办法做全秒级的。
在线业务，因为你在调度这一块，我们有一些小图画。其实第一版的阿基米德是了一些性能上的改动，比如排序的时候，不再放到自己的内存做排序，取得最优解，之后过滤的时候我们会尽快的反馈，不会从头到尾，也就是我们并不是全局最优。像在线业务跟离线数据计算，整个离线计算还是采用价值来用调度的，但往下首先左边大数据的一些存量的计算，右边是阿基米德的调度器加上阿基米德提供的，所以阿基米德关注的并不是每一个离线计算的效果，关注的每一个计算单元整体的负载。很典型一个架构就是存储与计算分离。
大家知道存储数据的增量是没有计算的增量快，大家也发现随着业务的增长，计算会比业务的增长还要快，如果不断买机器来补充大数据在线计算的话，这个量非常夸张的。
在整个运营的过程中，其实一个主导刚才也反复提及，把大数据的任务搬到在线集群上的前提是把影响在线业务，内存不超过63%这样比较友好的权重。我们最终考虑整个数据中心平均的资源使用率，不是有些资源使用率特别高，有些资源使用率零，这样并不能达到调度的目的。
因为大数据有一些安全的要求，对一些IP做一些授权的访问，这些都不能妥协。因为每个公司最有价值的数据是不能被窃取的，所以它原来大数据计算那些安全的级别都不受任何的影响。还有是容器调度，当某一台物理机的负载超出原来预测值之后，上面每台节点不会有驱逐器，它就会杀掉一些容器。杀谁的容器？我们一般会杀一些非核心系统的，还有一些离线计算的，来释放资源。
整个阿基米德系统的架构，也非常简单。其实就是在原来的集群，把这个调度器剥离出来成为一个完整的细胞，每次需要调度了，它知道调度的需求，产生需求到节点上这样一个过程。但整个调度过程效率非常高，会自动完成，后面是一个秒级的监控，因为分钟级的会把毛刺消掉。
这里提一下TSDB，我们现在数据中心大家要求1个PS，所以这个集群也不能建的特别大，你不可能一个QPS过来用了大几十台容器来承担这个量，我们用了25台就承担了1亿个QPS。整个架构也相对来说比较简单，我们未来会计复本数的复制关系会做记录。
重要的一点，整个的调度从调度效率和调度结果需要可视化。你整个的调度过程是需要能可被观察的，不能说你最后调度结果是这样的，调度的整个过程和效果都要被可视化的。资源分配应该是正态分布最合理，中间是请求的相应时间也非常重要，还有调度的应用时间也非常重要。
其实整个调度平台很像现在AI的训练，不是每天都要上一些新的算法，我们每天大量的工作都是做仿真，就是把现实集群作为的数据都拷贝下来做时间修正，修正后放到我们的仿真平台上一些新的算法，调度完之后再反过来验证线上调度算法的优劣，如果新的调度算法明显比现在的调度算法更优，我们会上新的调度算法，这样一步一步迭代来走。很像AI里面的打妖是一回事，现在社区还没有这个法律平台，我们有计划今年下半年会把它开源出来，因为有时候调度真的是非常危险。所以我们在仿真平台里不仅仅仿真调度的效率、结果，还会有一些调度之后这个值代表哪些业务负载的权重的随机，来做最后整个路的节点，这样一个负载的判断。
在线应用于离线计算的资源隔离，通过过去五年多的时间来看，整个隔离并不彻底，我说的不彻底并不是说隔离不好。都是在一些极端情况，我们京东现在所有的业务都在容器上，包括中间件、数据库，所以责任够大。任何的风吹草动都有可能首当其冲会挑战它，比如有一个毛刺。我们实践过程中就发现，你需要对在线业务运行的任何的状况都非常了解。
还有内存的Group，操作系统的内存回收，可能是几微妙或者几号码，就导致一些低延迟的应用会出现几个毛刺，我们现在把回收会做成分组。
第二个是对整个节点要做一个资源划分，一是系统预留，系统会给我们保留两个CPU，中断之类的也会打散，我们跑大数据理性计算的容器是用CPUSet，而不是CPUshare。
在整个调度领域，其实刚才说了很多CPU，实践中如果你的规模已经下来或者对延迟的敏感不是那么强烈的话，CPU调度不是太大问题，其实最难的，调度按照资源来说无外乎是CPU、内存、磁盘、网络。其实网络现在还好，只需要做到上线，基本上不会出现大问题。
磁盘也还好，最难的是内存。其实CPU用的都不高，内存用的是比较高的。调度容器了，有256G，最后发现你申请的都调满了，应该OK了吧？其实真正内容的使用率并没有，可能只有30%，至少调60%是没有问题的，我们正常是调到67%，是可以的。这是通过大量的算法预测出来的，当然这个跟业务也有一定的关联性，总体来说是这个线。
我们现在把256G内容调度出上千G的内容都有可能，这些内容根据时间的维度，比如星期一到星期五，可能只有星期五的内存高，就把其它星期的内存低的时候内存拿出来做其它的业务。
在线业务，CPU47%-63%。
离线计算，CPU 80%。
调度结构：平均资源使用率、碎片率。
调度效率刚才也说了。
挑战三，我们现在正在做一件事，可能今年大促不买机器了。可能会把在线业务，是大数据用在线业务的资源，不代表在线业务不能用大数据的机器资源，今年会把在线业务透明的移到大数据的集群上去，底层是JDOS的透明的通向内层，这样会节省大量的机器。
调度的三板斧，一是秒级监控。二是算法预测，依然要有保护性的一些过滤。三是兜底方案，强资源隔离、驱逐器、内存SWAP/MVMe。因为强资源隔离并不是太现实的事，所以要认识到这个问题，业务之间会有影响，只是说这个影响怎么来做，让影响降到最低。驱逐器，这个驱逐是不需要任何的信息，只关注这台机器的负载，我会有一个上线，CPU到70%或者内存到60%就会出发，对所有的容器做一些排序，发现哪些能杀掉就杀掉，所以我们在标签上会打很多相关的属性。
今天主要分享这些，谢谢大家。