阿里集团搜索在线集群非大促部署下CPU利用率日均值不高，除了少部分国际业务流量全天相对比较稳定外，国内在线业务流量全天有明显的波峰波谷现象，集团内以及蚂蚁等的业务大多如此。虽然搜索2015年就基于T4(阿里开源容器技术Pouch前身)实现了如索引构建这种离线任务和在线混部，但是因为当时资源隔离上还不够完善，部分延时特别敏感的业务不敢与之混部，没能充分利用闲置的CPU处理能力。反观离线集群有大量排队的数据预处理、特征抽取、选品、模型训练等任务以很高的负载运行，一些新兴业务因为预算有限申请不到资源而不能快速启动迭代起来，这将严重制约我们探索新业务新方向步伐。
根据业务特点采购合适的几种机型，保证在线业务SLA的前提下，进行合理的任务编排和调度，将闲置资源交给离线使用来提高集群利用率，解决大促前后大规模扩缩容和新兴业务资源需求是我们的梦想。
下面我们就从Hippo总体架构，业务和资源接入方式，资源分配协议，重要特性和新落地场景Yarn on Hippo等几个方面来讲讲搜索是如何实现在离线混部的。
Hippo的Master和Slave实现了镜像化和容器化运行，具备了快速部署和渐进升级的能力。
Hippo Slave将单机划分成在线和离线两个cgroup大组，在线空闲资源超卖给离线，离线间资源超卖。在线负载低时，离线可以借用在线空闲资源，在线负载上升时，借出去的资源要回来，也就是完全动态自主不断调整。目前主要做了CPU/Memory两个维度的超卖。CPU维度主要是基于水位控制的思想，因为超线程以及其他资源的争抢的影响，水位超过一定限制CPU真实处理能力开始非线性增长，在设置的安全水位下，可以将在线的闲置CPU资源超卖给离线使用，并有最小使用量保证，防止调度饿死宕机。Memory本身是非弹性资源，超卖策略上相对弹性资源CPU会保守一些，借用的闲置资源比例在某个阈值后借用比例会降低，Memory如果不能在约定时间内释放出来将综合考虑优先级、运行时间、Memory使用比例等因素选择某个离线进行用户态kill，并由Kernel根据优先级兜底kill。Hippo Slave上每轮调度会计算离线任务的保底Resource Guaranteed和上限Resource Limit资源并以文件方式通知对应的slot，以便slot对应的业务做出决策。高峰期CPU和Memory在离线分配百分比在115%左右。
通过上述资源预估和资源超卖策略，在Hippo Master上动态更新在线和离线预测的资源使用情况，在Hippo Slave上动态调整离线根组和离线任务的可用CPU和Memory资源上限，基本实现了这2个维度资源弹性利用。
资源超卖的约束条件是有效控制Slave上负载，保证在线业务的SLA，根据不同时期的资源需求设置不同的负载控制目标，甚至单台机器的负载控制目标，基本能实现集群负载的动态调控。
Hippo支持了类似Kubernetes任务编排方式POD，在容器化环境中建立一个面向应用的“逻辑主机”模型，它可以包含一个或多个相互间紧密联系的容器，多个业务进程容器可共享slot资源，如PID, IPC, NET, USE, NS, UTS和数据等，每个容器也可单独设置不超过slot总资源的资源限制。相比原生的容器接口，POD通过提供更高层次的抽象，简化了应用的部署和管理。Hippo上的一些系统服务已经使用这种模式部署。
应用动态扩缩容和渐进升级的时候通过ReserveSlot实现资源预留和保证机器不漂移，ReserveSlot占用的资源在线服务不可见，可以被系统服务和离线任务使用，申请ReserveSlot的App+role有优先使用权，能从系统服务和离线任务中抢占回来。阿里云售卖的OpenSearch已经使用该功能实现渐进升级过程。
为了给系统服务和离线任务有一定的资源保障，Hippo开发了资源预留功能，这些预留的资源对在线服务不可见，系统服务和离线任务可见，可以进行集群级别的统一配置，也可以针对单台机器配置。
优先级抢占
SYS/PROD/NONPROD三大优先级，在线可抢占离线，高优先级离线可抢占低优先级离线，NONPROD中最高优先级是NONPROD_PLATFORM平台框架型任务如Yarn，可选择配置不被抢占，有最小资源保障Resource Guaranteed和弹性资源上限Resource Limit。
Hippo slave上支持不同的绑核策略以应对不同业务需求，并根据需要进行重绑核，以解决绑核碎片的问题。
EXCLUSIVE: 在线独占模式，其他在线应用、离线和系统服务不能用，适用延时特别敏感的应用
RESERVED: 在线预留模式，其他在线应用不能用，离线和系统服务可以用，在线默认使用方式
SHARE: 在线应用之间共享模式，离线和系统服务可以用，非EXCLUSIVE和RESERVED的core都可以调度上去，适合长尾少于一个核或希望有较大CPU弹性的在线应用使用
NONE: 离线和系统服务共享模式，非EXCLUSIVE的core都可以调度上去
目前可以根据集群情况、资源稀缺性和控制目标等自定义各个资源维度的分数权重，控制在线和离线使用不同的平铺或堆叠的策略。后续和算法同学合作面向终态的实时决策智能调度，以期实现提升资源分配率和申请成功率，降低资源申请等待时间和碎片，优雅支持应用容器资源水平和垂直扩容，相同机器不同应用错峰部署和share绑核，有效控制整机负载和容器负载，动态扩缩容保证业务SLA等目标。
Hippo Master和Slave上的各自分配、释放、调整、提交、管理等事件，通过日志形式保存下来，并通过Kmon(监控指标采集系统)收集到Timeline Server，可方便用户查询、展示、问题排查和离线训练等。
流控主要是能在一定程度上保护重要业务的资源分配成功率，避免被一瞬间大量涌入的离线业务资源分配请求拖累。Hippo Master在对资源请求进行分组归类、合并打分时，会进行资源请求流量控制。
在介绍在离线混部之前有必要先讲下在线间混部，搜索在线间混部的诉求是拆除各个大业务线不同机器池子的藩篱，共享机器资源池，让各个在线业务能在机器上混合部署，降低分不出资源的概率，没有这一步先行，在离线混部将会被严重掣肘，搜索在2016年双11基本实现了在线间混部。在选择新的在离线方案时，我们本着对现有系统侵入性小，对当前运行在Hippo上的在离线业务完全透明无感知，类似Mesos支持多种调度框架，可快速迭代和落地的原则，最终选择了业界广泛使用、相对成熟的Yarn计算调度框架进行试点。
当前还有一些问题如Memory DoS Attack，百万级网络PPS引发softirq高，磁盘io控制，coredump限速，memory QoS等，需要和内核，网络，Pouch，业务等团队进一步合作优化，让在线业务SLA有更好的保证，并逐步建立起离线任务的SLA。
Hippo目前已支持GPU和FPGA等异构计算设备的调度，有需要的离线任务也可以分时段使用在线释放出来的GPU和FPGA设备。搜索在离线混部基于Sigma/Pouch容器和内核隔离等技术构建，经历双11的检验，在线服务集群和离线计算集群全混部后，必将成为大家值得信赖的基础设施。
最后，热忱期待和热烈欢迎对整个分布式调度生态感兴趣的同学加盟一起共创更好的系统。可邮件yeliang.job@gmail.com。
职位：搜索事业部-分布式系统研发专家-杭州、成都、深圳
职位描述：负责阿里巴巴电商线搜索以及推荐链路的分布式调度系统及DevOPS平台研发，专注于“效率”和“成本“，以系统工程思想推动基础架构升级、打造业界领先的在线服务调度和分布式计算基础架构。
职位要求：
- 精通c/c++、java、golang其中一种语言，良好的数据结构和算法基础。
- 具有分布式系统研发经验特别是高性能计算、mesos、yarn、k8s等相关系统的优先。
- 熟悉linux内核、容器技术、异构计算、网络虚拟化等有加分。
- 具有良好的系统化思维和大局观，有协同软件、OS、硬件全链路分析和解决问题的能力。具有良好的执行力以及强大的责任心。