为了保证系统在线交易服务的顺利运行，前几年阿里在双11大促前采购了大量机器储备计算资源，双11后大量资源闲置，是否可以将计算任务和线上业务混合部署，在已有弹性资源的基础上，提高集群资源利用率，降低双11的新增成本11资源？在阿里研发效率事业部容器调度领域，测试开发专家何颖为我们揭秘。 写在前面 Sigma是阿里巴巴全集团的Pouch容器调度系统。2017年是Sigma自正式推出以来首次参与双11。双11期间，成功支撑全集团所有容器（交易线中间件、数据库、广告等，20余项业务）的部署，为双11降低IT成本50%，是集团重要的底层基础设施阿里巴巴的运维系统。 Sigma已经是阿里巴巴全网所有机房在线服务管控的核心角色。掌控的宿主资源达到数十万，其重要性不言而喻。其算法的好坏影响着集团整体业务的稳定性、性能、资源利用率。 Sigma-cerebro系统是Sigma系统的调度模拟系统，可以模拟在线1:1的机器资源，在没有真实主机的情况下，以最小的成本和最快的速度请求完成调度需求，从Evaluatescalingalgorithmfrom各种角度。在与系统资源碎片化、资源有限条件下的大规模扩容、超预期超卖的斗争过程中，系统逐渐发展成今天的样子。 2017年双十一期间，依托cerebro进行预处理，Sigma成功完成双11一键建站，30分钟内完成建站任务，系统静态分配率从66%到95%，大大提高了资源的使用效率。 什么是好的作息时间？什么是理想情况？ 我认为在容器的资源运行时尽量减少相互干扰的前提下，越能节省集群的整体资源，提高利用率，在内部完成分配的调度系统固定时间更符合理想的调度系统。 那么一个调度算法仿真评估系统应该走多远呢？需要能够真实模拟生产的大规模环境和复杂需求；需要尽可能节省模拟成本，规避模拟风险；可以从静态和动态的角度对第一个问题给出定性和定量的回答。 在此基础上，再来看Sigma的衍生产品，Sigma-脑电调度模拟器。 调度模拟器设计 总的来说，目前的模拟器是一个利用1:1生产环境数据进行调度分配模拟的工具平台。 模拟目前纯粹是数据层面的，动态预测也是基于静态数据。原因是1:1模拟在线，在线的主机有几万台，不可能真正用到这么多资源。此外，还计划建设一个小型池，用于全动态运行时模拟和评估。 模拟器需要同时满足很多需求，所以分为多套环境，有一个环境池。每个环境池只需要3个容器即可完成全套任务。 后台数据存储在OSS中，因为一组后台数据可能非常大，解耦和在线依赖将风险降到最低，所以仿真时只需要从OSS中取数据即可。在各种模拟下，用户需要不同的服务，所以模拟器设计了几种不同的模式来支持。这些模式可以对应前面的四个要求。 目前存在的模式包括：扩缩容算法评估模式、预分配模式、问题复现模式。 针对如何衡量调度分配结果质量的问题，模拟器支持揭示算法配置，支持用户自定义水位配置和调度器。模拟器会负责一套线上1:1主机数据，应用需要配置等写入环境，用户的算法配置写入，然后每隔一段时间向环境发送相同的请求时间，完成后同法计分。 对于相同的背景数据，不同的算法配置和版本会产生不同的分数，因此我们可以观察它们的优劣。如下图： 另外可以在模拟器环境中快速预分配资源，然后准确的按照这个预分配，预热少量镜像到宿主机，使用affinitytarget方式解决如何解决宿主机IO受限的问题，以应对特定情况下多个容器快速扩容的需求。 为什么需要调度模拟器？ 容器调度存在几个业务问题：如何衡量调度分配结果的好坏？大量应用一键建站时，如何解决图片抓取慢的问题？一次性建站大量应用同时分配，如何准确评估资源？如何在测试环境重现线上调度问题？ Sigma调度模拟器可以以最低的成本和风险为上述问题提供可行的答案。 每个业务问题解释如下。 如何衡量调度和分配结果的优劣 首先，容器调度过程中肯定存在一定的碎片化。 让我们从一个单维的CPU核心分配开始。想象如下简化的场景： 我们的总资源池只有2台主机，每台主机有4个空闲CPU可以分配。示意图如下： 我们要分配给3个容器：2核容器A，2核容器B，4核容器C。 假设A和B的请求先到。如果我们的分配算法不够好，可能会出现以下分配场景。可以明显看出应用C无法获取到相应的资源，整个系统的静态分配率只有50%，这是一个很大的浪费。 理想的分配结果当然是如下图：3个容器全部分配成功，总静态分配率为100%。如果容器本身的资源需求是合理的，那么浪费就会最小。 当然大家都知道上面的例子只是最简单的背包问题。 我们现在将这个场景进一步复杂化。 系统需要分配不止一种资源，CPU，PouchwithSigma可以支持多种资源的隔离，包括内存。多资源添加一个可能错误的背包问题解，如下图： 从上图可以看出，部分主机的CPU资源已经耗尽。虽然内存和磁盘资源还剩下，但它们不能被分配。另外，有些主机的CPU资源还是比较多的，但是由于内存或者硬盘资源不足，无法利用。可见，必然存在部署不合理，造成相当大的资源浪费。 让我们把这个场景复杂化一步。 为保证被调度容器内服务的容灾等运行时状态需求，调度系统允许业务应用在调度时设置自己独有的模型需求、独占需求、互斥亲和需求等.这些强度规则无疑使背包问题复杂化了一点。 让我们把这个场景复杂化一步。 在线和离线任务混合。如果在线任务根据当前的业务服务需求决定丢弃一些容器来释放资源供离线任务运行，哪些实例缩容更合理和最优？当然要考虑去产能，那么我们在扩容配置的时候需要考虑这种情况吗？ 让事情变得更复杂了。 在满足上述条件的前提下，分配是有时间限制的，虽然不是很关键。一般每个请求最多需要在180s内返回，控制的主机规模在几万台。 同时还要考虑请求的并发度，可能会高一些。 使用Sigma调度模拟器，提供模拟生产后台环境数据和需求请求，可以对静态资源的部署进行比较清晰的评估。 如何应对主机IO有限的情况下多个容器快速扩容的需求下载和解压时间，根据历史经验，可能会占一半以上的耗时。如果有特别长的耗时，一般是卡在这个阶段造成的。一键建站场景，要求30分钟内完成1.6k容器的创建；快上快下场景，要求5分钟内完成5k个容器的创建。 阿里的Pouch采用基于P2P技术的Dragonfly进行图片分发，因此在大规模图片下载方面具有优势。此外，还有一种镜像的预加载方式，可以缩短实际容器创建时相应的时间。 但是有时候宿主机磁盘容量小，阿里富容器镜像比较大。当一键建站的应用类型过多时，如果所有图片类型都预热到相应的机器上，磁盘就不够用了。 有些主机磁盘IO能力弱。即使Dragonfly超级节点充分预热，解决了网络IO时间长的问题，仍然会长时间卡在宿主机磁盘层面，甚至超时无法Finish。 因此，如果能够提前准确知道宿主机上会使用哪些容器，就可以精确预热少量容器来解决上述问题。这个问题可以通过预分配模拟器来解决。 当然还有其他更优雅的方案，这里不再赘述。 如何预估资源需求和预算 前面介绍了资源的碎片化。如果算法没有完全优化，碎片率可能会很高。所以，是否加主机，建站需要加多少台主机，并不是直接资源叠加的简单问题。如果估算过多，可能会浪费预算。如果估计太小，会影响使用。如何估算合适的数量是个问题。 如何在测试环境重现线上调度问题 生产环境有很多场景，测试环境可能会出现一些无法预料的场景和一些意想不到的问题。为了在不影响生产的情况下稳定地在生产环境中重现问题，您可以给出更明确的问题修复指南。 后续计划 如上所述，目前所有模拟都是静态的。这里还有两个问题：如果满足了静态需求，各种微服务是否能够和谐共处、完美运行？哪种应用组合最有效？通过cpushare等方式，是不是更好的削峰填谷，有效利用资源？ 目前的静态模拟都无法回答这些问题。因此，后续计划进行一些尝试，进行理想化的正交动态仿真和静态互补，以促进调度算法的发展。 未来，这种混合能力的混合云弹性能力将通过阿里云打通，让用户以更低的成本获得更强的计算能力，从而帮助整个社会提高资源效率。
