地 址:联系地址联系地址联系地址
电 话:020-123456789
网址:kkkkk1b.twqueen.com
邮 箱:admin@aa.com
本文作者
李雨前
,最新阿里云弹性计算技术专家,干货有 5 年的何深大规模集群资源管理调度实践经验:针对 long-time service 及 co-location 调度具有全面、深入的入集一线实践和解决问题经验,提交 10+ 项相关发明专利;擅长稳定性优先的群调集群调度策略和稳定性架构设计、全局稳定性数据分析实践,度管以及 Java 和 Go 编程语言
。最新
随着企业数字化和全面上云的干货推进,更多的何深企业将在云上生云上长,云计算的入集集群管理调度技术支撑着所有云上业务应用。工程师应该像过去了解操作系统一样了解今天的群调集群管理调度。云时代的度管工程师 ,需要进一步了解这一领域,最新从而更好地理解云、干货利用云 、何深发挥云的优势,赢在云计算时代。
图1 资源视角集群调度与管理
如图 1 所示,集群调度包括任务调度和资源调度 ,集群管理包括资源管理和成本效率管理 。有时候,又可以将其简化为任务调度、资源调度和资源管理,将成本效率管理“淡化”。从另一个层面来讲,任务调度、资源调度和资源管理的最佳实践过程 ,就是成本效率管理的实践过程。按照图 2 所示的关系来理解,也比较自然 。
图2 任务调度、资源调度 、集群管理关系
举个例子,用户从阿里云控制台或者 OpenAPI 发起资源购买下单 ,这个相当于“任务”。当有很多用户在同一时间购买 ECS 计算资源的时候 ,多用户请求就代表了多任务 。每个用户的请求任务需要排队 、进行路由等任务调度处理。后端调度系统收到具体任务后,需要从物理机房 ,众多物理机中,选择最合适的物理机,然后进行资源的分配 、创建计算实例 。这个过程就是资源的调度 。调度的物理资源 :服务器 ,需要采购 、软硬件初始化、上线服务、故障维修等。这个资源供货管理的过程就代表了集群管理。
本文集群调度和管理,可以简化理解表达为集群资源调度和管理。
今天在企业数字化转型 、上云大背景下,企业如果理解了云供应商对于资源服务的工作路径 ,也有助于其更好地上云 、用云,管理并优化好自己的资源。
我从事集群资源调度与管理多年,结合经验认为 : 从 DataCenter as One Computer 开始,大规模集群调度和管理就拉开了序幕 ,曾经一度类似于 Borg 这样的系统 ,被誉为互联网公司的“核武器” ,不轻易对外分享。随着技术的演进与发展 ,特别是近十年来云计算的蓬勃发展,集群调度和管理技术再一次走进大众的视野,典型的代表就是 Google 开源、CNCF 孵化的开源集群调度和管理系统 Kubernetes 。Kubernetes 被称为分布式操作系统,对标 Linux 单机操作系统 ,相关描述如:“Kubernetes is the new Linux” 、“Kubelet is the new Kernel”、“Kubectl is the new GNU base system”、“Helm is the new Yum”、“Operators are the new Config Management tools” 。
从商业化角度来看 ,Kubernetes 只提供了分布式操作系统的“内核态”。商业化所需要的“用户态”内容,正依托社区吸纳全世界程序员来共建共享 。从技术和商业两个角度来看 ,Kubernetes 作为操作系统级别的系统程序,毫无疑问,它的业务抽象、架构设计、接口定义奠定这个系统的基础,也提高了其生命力,特别是生态发展的生命力,以及商业化盈利的概率。
今天,以 Kubernetes 为代表的集群调度和管理系统不再神秘 ,就像搜索引擎技术不再神秘一样。集群调度和管理是企业内部的“节流”,那么搜索引擎广告技术就是企业的“开源” 。企业要生存,开源 、节流必须是并存的 。
在未来很长一段时间内,特别是大规模的集群调度和管理 ,会是大型数字化企业的必备基建能力 ,这个领域的发展值得我们继续探索。集群资源调度和管理的内容非常庞大 ,并且是偏基础的支撑,相当于IT服务的“地基” 。这样的系统 ,一定是需要“设计图纸”的,并且非常依赖设计图纸,因为一但走错,后续“纠正”的代价巨大 。
接下来,我就从数据中心的架构设计继续聊聊。
就在 IaaS 层进行架构设计而言,需清楚以下三个基本原则:
1. 简单化
主要是说在实现资源调度和管理系统 ,主链路足够简单 ,依赖组件尽量简单化。例如性能采集 ,应该足够简单,不需要融入太多数据分析、告警的业务 。将分析 、告警引流到数据系统上集中处理 。
2. 稳定性
服务器资源是 IT 系统的基石,业务运行在服务器资源上 。在云上,客户的业务都运行在云上,等于把自己的身家性命交给云平台 。云平台必须确保服务器稳定。所以 ,资源调度和管理的技术设计,一定要稳定性优先。例如:客户资源的按打散度来调度 ,将客户实例尽可能分散在不同的物理机上。避免某个物理机出故障 ,影响同一个客户的多个实例 。打散就意味着需要更多的物理服务器资源 ,也意味着云平台需要付出更多的成本 。
3. 面向异常设计
硬件故障是客观存在的,软件 bug 也很难说不会出现 。因此 ,面向异常设计是非常必要的。针对异常做架构层面支持 ,例如定义整个系统的异常事件,当出现异常的时候 ,相应异常订阅处理模块就可以快速感知,并执行异常处理。
架构设计是一个很大的话题 。我的理解是 ,一定需要结合业务 ,从不同方面进行设计和取舍。主要有以下几个方面:
1. 业务设计
主要是把客户、问题 、价值梳理清楚,和上下游系统的关系、边界定义清楚,才能在做系统架构设计的时候 ,做最合适的取舍。
2. 数据设计
例如数据的一致性、数据的实时性、数据的安全性 。例如数据的存储 、访问模型。
3. 主链路或者高频链路设计
任何系统都有其核心服务的业务场景 ,这个场景的请求和处理就构成了主链路或者高频链路 。这个链路因为核心、高频 ,往往会不自觉地叠加更多的服务进来 。这里建议做减法,确保主场景的稳定、可控。
4. 稳定性设计
需要综合考虑事前 、事中、事后的整体设计。事前充分预防,事中快速定位、止损、恢复。事后复盘总结 ,故障演练等 。
5. 面向异常设计
总是假设系统会有异常,这些系统在一开始都进行考虑 。这样可以大大降低后续故障的修修补补的复杂性 。
6. 规模化设计
规模也是一个可大可小的考量方面。一般在初始阶段 ,业务刚刚起步阶段 ,不需要关注规模的影响。但是,如果一开始就有一些设计的思考 ,也可以更好地服务规模化的请求 。
7. 组织设计
有一句话说组织决定架构。在实践项目研发过程 ,组织架构的影响 ,也是需要考虑的。
其他还有例如:演练、测试、限流 、微服务、容量规划等架构设计。
任何架构,首先它要能够解决问题。在基础设施领域 ,架构设计还需要支持规模化、稳定性优先,其次是考虑成本效能 。由于基础设施在业务垂直分层链路中处于下层 ,越往下越简单 ,是关键的取舍依据。集群调度架构设计的核心思路是解决问题 ,支持规模化 、稳定性优先且足够简单。
按“多、快、好、省”对集群调度和管理要解决的问题进行描述,如图 3 所示 。
图3 集群调度和管理的“多、快、好 、省”
从宏观上讲 ,集群调度架构支撑解决利用率问题 、效率问题 、产品化问题,并且支持从“可编程基础设施+DevOps”演进到“云原生 Serverless+AIOps”。这中间需要建立体系化的 Insight 能力 。对 Insight 进一步分解 ,其不同发展阶段的侧重点如图 4 所示。
图4 分解 Insight ,其不同发展阶段的侧重点
面向过程的调度架构设计和实践
资源请求处理过程如图 5 所示。首先是提交请求,通过后进入分配队列,然后进行调度,接下来是实例资源分配 ,最后是实例启动、实例运行 。如果请求被拒绝 ,则可能是因为额度限制、权限限制、参数不符合要求、资源库存不足等。
图5 资源请求处理过程
面向过程最直接的体现是:在用户侧可以看到整个链路的关键信息 ,并需要主动关注异常结果,对异常进行处理 。对于研发来说,就需要针对下游 API 返回状态做正确 、异常的感知,并做正确的资源清理处理,避免资源泄漏。另外,面向过程也是相对的 ,业务需求由更多的步骤构成 ,如果从其中一个步骤来看,则可以被看作是面向服务的 。
面向终态的调度架构设计和实践
面向终态抽象如图 6 所示 。相对于面向过程来说,面向终态进一步屏蔽了过程细节,过程中的失败对用户无感 ,使得基础设施可编程——编程每一个场景 、需求的终态 ,等于编程了整个基础设施。
图6 面向终态抽象
面向终态表明不是一次性的 ,而是要持续不断地维持目标状态。终态代表一个概念、需求 ,实现这个概念、需求的具体错误被透明化了 ,更贴近人的行为习惯,所想即所得 ,所见即所得。为了实现业务视角的终态,一种策略是将业务一致性 、终态的需求转换为存储一致性的需求 ,或者说依托存储一致性的需求来大大简化业务一致性的需求 。
例如,基于工作流的状态变化机制支持需求的拆分以及子任务可重入 、可并发 ,最终实现一组状态的持续变化 ,从而实现业务走向目标状态。比如资源视图的一致性,就是通过分布式存储、锁、消息订阅等实现的。无论是 Paxis 协议还是 Raft 协议及其改进版本,都大大降低了业务的复杂性 。
面向服务的调度架构设计和实践
面向服务抽象如图 7 所示。用户只需关心业务逻辑部分,业务需要的服务器资源、服务器交付的过程 、服务器编排调度等全部由基础设施完成 ,交付的是服务 ,或者简单理解为抽象的算力 。
图7 面向服务抽象
Hadoop、YARN 调度以及大数据算力服务 ,都将走向面向服务的调度。特别是云计算对基础设施的逐步收敛,共性的、基础性工作一步步被屏蔽 。毫无疑问,对于一般用户来说,集群调度逐渐没有了 ,集群管理也会被第三方 ISV 服务商提供的工具托管维护 。未来用户更多的是关注业务本身的发展 ,新的创新不再受限于基础设施资源的研发 、运维和管理 。
基于 Kubernetes(简称 k8s) 架构设计的案例如图 8 所示 。这个架构设计的核心依然是 k8s 的原生架构。图中多了 Insight 、LBS 等模块,这是实现稳定性的非常重要的手段。Insight 对整个系统进行观察 ,对潜在的风险进行识别、预警,并及时干预 。k8s 是面向终态的 ,需要有人工介入 、一键终止面向终态的部分机制,让系统模块针对性“lock”下,待问题解决后,再 relock 。LBS 确保负载均衡 、流控等。图中还对相关组件做了一些批注 ,这是作者认为非常重要的点,也是区别其他调度架构不同点的体现。
图8 基于 k8s 的架构案例
k8s 的面向终态体现:
k8s 已表现出强大的生态影响力 ,对 k8s 的各种运用和优化的案例太多了 。这里仅仅是一种解读 ,希望我的解读能帮助大家更好地理解什么是面向终态的设计。
总体上架构设计没有最佳,只有最合适。在合适的时间 、支持了业务的发展,依赖规模化服务的进行架构的深度迭代、完善。大型数据中心既要管理大规模的服务器 ,又是业务底层的基础设施,因此对架构、稳定性、性能等都有极高的要求。希望本文对从事相关工作的同学们有所帮助 ,帮助你们在实战中多避坑、少踩雷。