小说阅读网站建设,我是做装修的怎么样投资网站,一级a做爰片免费网站视频,网站建设 方案书简介#xff1a;在阿里云十三年的发展历史上#xff0c;重新设计调度系统算得上是一个重要的技术抉择。
在阿里云十三年的发展历史上#xff0c;重新设计调度系统算得上是一个重要的技术抉择。
云计算是一个庞大的技术工程。2009 年#xff0c;阿里云从 0 到 1 自建国产云…简介在阿里云十三年的发展历史上重新设计调度系统算得上是一个重要的技术抉择。
在阿里云十三年的发展历史上重新设计调度系统算得上是一个重要的技术抉择。
云计算是一个庞大的技术工程。2009 年阿里云从 0 到 1 自建国产云计算系统“飞天”为了确保对每一行代码都有控制力阿里云选择了一条艰难的道路自主研发。伏羲调度系统是“飞天”三大服务之一。调度系统作为云计算的核心技术无论是对亚马逊、谷歌还是其他云计算企业来说都是他们最保守的秘密而伏羲凭借自研与优异的性能与 YARN、Mesos 等技术一起成为了调度系统的典型代表之一。
这么多年发展下来很多人认为阿里云战略上最与众不同之处就是坚持自研核心技术。作为全球集群规模最大的云计算平台之一阿里云在技术已然成熟、稳定运行着数量庞大的业务情况下选择了用云原生的标准重新设计和构建云计算的调度系统并在 2021 年“双十一”大促之前将全球几十个数据中心、数百万容器、数千万核的资源统统搬到了新的调度系统之上。
阿里云为什么在十三年之后重构调度系统在不影响业务运行的情况下阿里云是如何更换“引擎”的这种技术思路给我们带来什么启示新调度系统有开源计划吗InfoQ 采访了几位调度系统负责人为大家一一解惑。
发展十三年成绩斐然的老调度系统
资源调度系统可谓是云计算的大脑负责在众多集群内的机器里选择一台最合适的以最佳的资源使用姿势做到最少的相互干扰来运行用户提交的计算作业。云计算最终目的之一是降低 IT 成本最大限度地利用单台 PC 的 CPU 处理能力而调度系统恰恰就决定着基础设施的利用率和整体运作成本。
无论是亚马逊、谷歌、微软还是阿里某种程度上“大脑”代表的是企业技术竞争力。核心技术的重要性不言而喻像谷歌的调度系统 Borg在很长一段时间内一直是谷歌最保守的秘密之一。
艰难起步从 0 到 1 自研伏羲调度系统
2008 年阿里巴巴确定了“云计算”战略决定自主研发大规模分布式计算操作系统“飞天”目标是将几千台乃至上万台普通 PC 服务器连接到一起使其像一台多功能的超级计算机实现超强计算性能。
2009 年 2 月飞天团队在北京写下了第一行代码“飞天”系统也从此成为阿里云的奠基技术平台。伏羲调度系统是十年前飞天成立时创建的三大服务之一另两个是飞天分布式存储盘古和分布式计算 MaxCompute。
2011 年 7 月阿里云作为中国第一个公有云正式对外开放。这之后的十多年里伏羲能调度的单集群规模也从最初的几百台物理机发展到了 10 万台机器。我们知道规模每放大十倍就意味着很多架构设计点都需要重新调整当横向扩展遭遇不可逾越的瓶颈就代表着系统重构的开始伏羲就因此经历了两次重构。
2013 年伏羲在飞天“5K”项目中对系统架构进行了第一次大重构。“5K”顾名思义就是能让调度系统支持单集群 5000 节点并解决大规模单集群下的性能、利用率、容错等问题。
不断扩大单集群的规模到现在依然是业界不同调度系统在做的事情。
如果依靠早期的 Hadoop 开源调度器技术以当时的实践经验来看并不是容易的事情因此伏羲团队选择了架构和代码都是自己构建的自研方式。这个项目在阿里云历史上也是一次非常有里程碑意义的“攻坚战”。 阿里飞天 5K 项目纪念碑
随后历经一年半时间阿里巴巴和蚂蚁金服完成“登月计划”将所有数据存储、计算任务全部迁移至飞天平台。在 2015 年 Sort Benchmark 排序竞赛中飞天用 377 秒完成 100TB 的数据排序打破四项世界纪录。随着阿里云的业务需求变化伏羲的内涵也在不断扩大。最开始是作为一款对标开源 YARN 的单一资源调度器而后扩展成了覆盖数据调度、资源调度、计算调度、单机调度等的核心调度系统伏羲也于 2019 年经历了第二次重构并将单集群规模扩展到了十万台。
双调度系统混部实践
伏羲是负责阿里离线业务的调度系统而于 2015 年正式立项的 ASI 调度器则支撑着阿里搜索、电商等庞大的在线业务。在线调度历史也比较悠久最早起源于 2011 年上线的 T4 系统即阿里早期基于 LXC 和 Linux Kernel 定制的容器调度器。T4 的技术理念与如今云原生领域的核心技术——容器如出一辙。
在线调度最开始是一个简单的资源分配系统而后逐渐演进为 Sigma 调度器、ASI 调度器在发展过程中又进一步吸收并融合了伏羲离线调度系统、搜索团队基于 YARN 的 Hippo 系统的先进经验。 0 层调度器负责全局资源视图和管理并对 1 层调度器 Sigma、伏羲进行仲裁
据称全球服务器平均利用率不到 20%因此提升服务器的资源利用率是很多大厂不断追逐的目标。
2014 年左右阿里巴巴开始大力探索混部技术通过将在线业务和离线大数据计算的负载混部运行在共享的集群中以期可以显著提高数据中心资源利用率。与离线调度不一样的是类似双十一活动中的零点峰值场景它对在线调度 CPU 的集群化编排要求非常高对延迟和抖动敏感离线业务正好相反平时资源使用压力较高业务资源使用较为固定对时延不敏感。所以只要两类负载能跑在共享的集群中使用“分时复用”的策略就可以达到提升利用率的目的。
正是因为在线离线混部对于提高集群利用率非常有意义所以无论是在学术界还是在各大厂商实际落地中都对混部做了深入的研究各大企业中最早做混部实践的是谷歌 Borg。虽然有 Borg、Omega 先例存在但谷歌很少对外分享自己的混部实践仅在 2015 年、2019 年对外发布过两篇论文。这也意味着如果想做好“混部”调度企业都得靠自己去摸索。阿里的混部实践也于 2015 年正式立项并于当年的双十一经历了一次资源调度能力的“考验”。据公开资料显示混部能将阿里云的 CPU 资源利用率从 10% 提升到 40%。
作为自研的调度系统伏羲和 Sigma 运行在一起这种混部系统形式曾存在很多干扰和影响一方面是两个系统之间节点状态不一致造成的干扰另一方面是两个系统所分配的容器互相之间的干扰。然而“混部”带来的收益又不可忽视因此阿里于 2016 年开始重点研发了 Sigma 1.0基于 Docker Swarm 通道创建容器并将演进中的各种语言技术栈统一为 Golang同时在实践层面做了很多隔离、协同的优化工作也将不同等级的任务调度做得更精细化。
整个演进过程中调度团队也曾将实践成果分享为数篇顶会论文得到了学术界和工业界的认可。有意思的是谷歌曾在 2019 年 11 月分享了 Borg 集群运行数据在对应的论文中谷歌特地指出其系统很少在集群中使用超过 50% 的内存但据报道竞争对手阿里巴巴达到了 80% 的利用率。
大船难调头阿里的调度系统发展了十多年成果斐然性能优异运行的业务规模也是数千万级别了但 2021 年阿里云还是决定将伏羲、Sigma 双调度协同系统重构为基于 ACK 的“统一调度系统”。
基于阿里云容器服务 ACK 的调度系统
我们在技术上到达了一个新的临界点。
2020 年 6 月阿里云集结了 100 多位调度团队核心技术人员开始了重构的进程。
经过一年多的研发赶在双十一之前将数千万量级的业务切换到了新一代的“统一调度系统”上。新框架基于阿里云容器服务 Kubernetes 版简称容器服务 ACK通过一套调度协议、一套系统架构统一管理底层的计算、存储、网络资源。ACK 本身提供了一个全托管的 Kubernetes 集群的调度能力对于 IaaS 层不同类型的计算、存储、网络等能力都可以统一调度是统一调度大资源池化生产运行的基座。
2021 年双十一新系统打通并统一了阿里巴巴电商、搜推广、MaxCompute 大数据和蚂蚁业务全面支撑了全球数十个数据中心、数百万容器、数千万核的大规模资源调度。
为什么要重建
Kubernetes 项目始于 2014 年源自谷歌内部的 Borg吸收了 Borg 项目多年的实践经验它超前引入了 Pod 概念将容器分组大量使用了 Sidecar 设计模式为容器化应用提供了自动化的资源调度并具备动态扩容、滚动升级、负载均衡、服务发现等功能受到大厂的大力推崇。
在接下来的两年里与其对应的 Mesos、Docker Swarm 等相比Kubernetes 作为容器编排引擎的采用缓慢却很稳定领先的科技巨头如亚马逊、阿里巴巴、微软 Azure、红帽都开始启动了基于 Kubernetes 的新解决方案。
2019 年Sigma 全面迁移到了基于 ACK 的调度系统。同时在这几年里阿里的技术体系也逐渐全面切向云原生技术去年 9 月阿里云容器服务全面升级为 ACK Anywhere。 据在线调度系统负责人智清回忆在线调度系统最初是完全自研的云原生兴起之后在线调度团队于 2017 年决定将这套技术框架迁移到 Kubernetes消除两者之间的差异并跑在阿里云容器服务 ACK 上。“刚开始是比较艰难的尝试过好多版本包括 Sigma on Kubernetes、Kubernetes on Sigma 等方式最后还是决定用最标准、最原生的、完全基于 Kubernetes 的方式。”后面启动的 ASI 项目它做的事情就是将整个调度框架以非常原生的标准方式搬到 Kubernetes 上在 Kubernetes 基础上做到在线、离线调度的真正融合。而且在业务侧阿里也专门组织了一支云原生团队来推进容器化最终形成一个整体的云原生资源池。
云原生统一调度架构师懿川将这些年调度系统的发展过程总结为三个阶段
第一个阶段是非容器阶段仅有调度的需求并且基础设施还没有完善属于调度的最初期阶段。在这个阶段无论是伏羲还是 T4基本都是借助一些比较简单的隔离概念以及一些内核的能力靠自身的演进来实现对调度的最朴素的需求。
第二个阶段是开始进入容器阶段。容器技术使用场景变多规模变大Sigma 以容器为主进行了改造。在这个阶段需要调度系统既能承接业务的需求又能同时深耕容器技术。
第三个阶段是云原生化调度系统完全基于新一代的容器技术包含阿里自己的安全容器、RunC 以及其他的虚拟化技术同时调度器的实现框架上也需适应整个 Kubernetes 生态。也就是将电商、搜索和大促这种创造洪峰型的业务以及十多年调度系统技术积累再结合 Kubernetes 开源架构的优势整合到一起进行大规模应用。
总而言之阿里重建调度系统的决策是基于业务演进的需要也是希望能有一个全局资源池统一支撑所有业务形态。
云计算的本质是将小的计算碎片变成更大的资源池充分削峰填谷提供极致的能效比。混部技术打破了多资源池的割裂不同计算领域的多调度大脑协同共用资源让业务间峰谷互补的优势发挥到最大但两个调度器由于彼此间无法高效地交互细粒度信息阻碍了混部效果的进一步提升。
另外调度成本、资源的调度效率和业务独占资源池有很大的关系。从过去的调度系统演进经验来推断建设统一资源池是最好的提升效率的方法业务上有很多共同性的调度需求是可以互相配合和优化借鉴的各自演进并不利于发展。无论是搜索还是电商在线还是离线如果作业类型越来越相近的话就可以通过合作和共建作为同一种调度类型去建设和演进集中力量将云原生终态方案一起做到极致并希望最后能做到自研、商用、开源三位一体。
双调度系统协同的方式跟谷歌的 Borg 或微软的系统相比在集群管理模式上有一定的区别那是否是因为双调度系统协同模式存在缺陷才会导致重构回复 InfoQ 的采访时懿川认为调度系统的发展和业务形态密切相关。国内很多企业确实会存在拥有多种调度系统的情况原因是在线业务和离线业务特点有很大的不同性能、吞吐量、任务长短类型等以及对调度业务的需求决定了调度器的架构设计。
“反倒是做成一个统一的调度系统是比较难的做成多种调度系统相对来讲更容易。而且类似谷歌的Borg或微软的Apollo系统一开始也不是所有的调度策略、逻辑以及场景都能支持也有一个在演进过程中逐步增加功能的过程。”
新调度系统对 Kubernetes 的改进和增强
新调度系统需要支持在线离线、低频高频各种调度类型和众多业务种类且要完全兼容 Kubernetes 生态还需要是模块化、组件化形成一个可插拔式的机制。 统一调度团队针对 Kubernetes 社区版在 Pod 和资源安全上做了很多优化围绕 API Server、ETCD、Kubelet 做了不少功能优化和代码修改。统一调度在 Pod 和接口调用上也做了很多安全防御方面的事情例如 ETCD 错配或出现其它问题时如何进行防护从而保证底座平台的安全。但最重要的两方面改造在单集群规模、调度频次性能上。
Kubernetes 早期版本仅支持几百节点的单集群规模与 Mesos 支持的节点数量相去甚远各大厂集合力量一起大幅提升了 Kubernetes 的集群管理规模到 1.9 版本就已可以稳定支持 5000 个节点但远达不到阿里原来调度系统单集群上万节点的性能要求。并且 Kubernetes 以 API Server 为中心的消息同步机制更适用于调度频度较低的在线服务场景对于阿里系统中的大数据计算场景可达每秒 10 万次的调度频度。所以“尽管 Kubernetes 已经演进很久了但是在我们的调度器上仍然需要投入大量的工作来改造才能够满足我们的要求。”
如果要问哪些历史经验有助于新系统重构的话集群管理规模的突破必定是其中之一。
2013 年的飞天 5K 项目已经早早突破了单集群 5000 节点的规模。在后面的演进中伏羲再次经历了第二次重构据伏羲分布式调度负责人李超回忆说当时主要考虑到“现在集群的规模可能动不动就过万台不光是物理节点在增加CPU 的处理能力也在不断增强。5 年前一台物理机上一般二三十个 CPU core现在一台物理机节点里已经变成了一百多个 CPU core 了。相当于即便物理机节点不增加可调度的总资源扩大了五六倍甚至扩大了一个数量级这对调度的挑战是很大的。”
“如果规模无限扩展下去在架构和设计上也要有一个应对的方案。随着规模继续变大我们也要 Hold 得住。”
在伏羲 2.0 资源调度的重构里伏羲团队提出了一些比较新颖的观点在混部中引入去中心化的多调度器架构基于悲观锁这种 Partition 策略解决调度之间的冲突保证调度 latency 性能达到与小规模下的系统相同的水平。
但 Kubernetes 单集群规模有限远不能满足今天的诉求。统一调度团队通过对 API Server 和 ETCD 的算法优化、在服务端进行数据压缩以及链路治理的方式将集群规模从8千台2020年扩展到1.2 万台2021年节点而业界一般达到8千台就已经是超大规模。
此外由于 Kubernetes 容器拉起的时间在几秒甚至几十秒如果需要做到一秒钟有十万次的调度也必须对其进行大量改造。
统一调度团队参考了 Kubernetes 社区 scheduler framework 插件化和多调度机制通过灵活的调度框架让不同的调度团队可以定制各自的调度需求从而让 Kubernetes 能够很好的去支持一些场景下的大规模高并发的调度需求。比如在阿里大数据场景下对调度系统的要求是每秒钟能发生十万次调度。
飞行中更换引擎
2021 年双十一之前伏羲和 ASI 调度系统中的机器和计算资源已迁移到了统一调度系统仅伏羲就包含几万台机器、数百万核计算资源迁移过程需全程对业务和用户透明无感。
同时这个系统本身是一个涉及非常多人的协同项目中间涉及到一次完整的系统重新设计和实现还要将原有积累的伏羲、Sigma、ASI 以及 Hippo 的设计经验融合进来且保持对业务的兼容性和对开源框架的兼容性。
可以说整体设计非常复杂代码开发涉及的耦合也很高各个系统之间还存在各种对接。
以伏羲为例在阿里 MaxCompute 技术体系中伏羲一方面是分布式系统的资源管理和调度组件需要与上层作业执行引擎进行资源交互另一方面也是各种运维管控的数据源复杂的模块依赖决定了系统升级是一件非常艰巨的事情。如果将 MaxCompute 比作一架高速飞行的飞机统一调度升级就是要给这架飞行中的飞机更换引擎难度可想而知。
“留给我们上线的时间窗口很小但整体的业务要求却很高。双十一的时间点是摆在那里的一个硬性指标我们不可能错过。”懿川介绍项目背景时讲到。
在这种情况下要让新系统在“双十一”大促中表现得更有保障李超表示主要有两大技术举措
第一是灰度上线之前有专门的风洞测试机制它能把历史上真实生产的一些需求、请求在测试环境去做回放Replay从而验证经过新一轮的修改或者新的功能后系统是否能稳定上线。
第二是在稳定性上在状态的可恢复上传统的方式是基于 Kubernetes ETCD 的持久化机制但是因为大数据的调度频率达到每秒十万次的调度这种状态要做持久化保障是比较困难的。新系统引入了软硬状态 fail over 机制简单来说是基于这个状态的重新收集而不是完全依赖于状态的持久化。在不同的角色上去收集状态重建调度器当时的状态。
另外在工程上也需要一套很严格的实施和上线机制
保证代码高质量和低缺陷率并做好全面的单元测试平时基本功扎实才能保证最终的工程质量。上线之前用接近真实生产的环境进行测试和验证确保能够跑通如果出现问题及时解决和处理符合整体的上线进度。“我们最后上伏羲集群的过程中出现的问题都是日清日结让问题快速收敛保证整个集群的交付可以符合要求。”分阶段灰度测试。第一阶段用小规模的迁移“当时只是用几十台节点机器统一调度跑起来再到后面就逐渐放大规模”而且还需要先从重要程度相对低的业务开始切换并保证足够长的灰度时间最后才在线全面铺开没问题后再将更复杂的离线调度引入混部运行。保证每天有一定的切换量最终将系统按时切完。“当然这也有一定运气成分在我们没有出现特别严重的问题这也非常考验整个项目成员的设计和实现的功底。当然也需要我们有整体的机制和流程的保障。”系统需要一个完善的监控机制。“上线一个系统之前我们先得想好怎么去监测它。观测方方面面的上百个维度的元数据是不是正常通过完善的监测系统一旦出现问题我们能第一时间发现做一些回滚动作或者提前准备好一些处理机制来保证用户受到影响之前系统能够恢复到一个正常的状态。”
未来规划
每个技术都有自己的生命周期十多年前大家很难想到 Kubernetes 会成为当今技术界的扛把子而技术演进过程中开发者的使命就是用最合适的技术来构建我们的系统。使用新技术不代表过去的经验和成果不再有价值统一调度系统也是吸取了伏羲和 Sigma 系统构建中的精华。
开源技术影响着调度系统的演进而部署在大型企业生产环境中的系统无论是谷歌的Borg、微软的Apollo 还是脸书的 Twine反过来也在影响开源项目的系统演进。统一调度团队表示未来会进一步提升和完善整个调度器的功能和能力继续往2.0推进另一方面要完成自研、商用、开源三位一体的目标作为战略计划推进项目的开源包括开源关键能力和标准、框架。建设这样一个超级系统投入和挑战都非常大而开源能够将更多的人聚集起来一起把这套系统做得更好。
采访嘉宾简介
懿川阿里巴巴研究员云原生统一调度架构师。全面负责统一调度项目在分布式领域和资源管理领域有多年的经验积累。
李超阿里云智能计算平台事业部资深技术专家飞天平台伏羲分布式调度负责人拥有十多年分布式系统与大数据研发经验。
智清阿里云智能容器服务资深技术专家ASI 调度系统负责人负责了阿里巴巴在线调度从 Sigma、ASI、到全面统一调度的迭代演进。
原文链接
本文为阿里云原创内容未经允许不得转载。
