没有合适的资源?快使用搜索试试~ 我知道了~
混部数据中心在线离线服务特征分析.docx
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 190 浏览量
2022-11-28
20:30:38
上传
评论
收藏 1.04MB DOCX 举报
温馨提示
试读
26页
混部数据中心在线离线服务特征分析.docx
资源推荐
资源详情
资源评论
随着云计算技术的日益发展和云服务能力的进一步提升,越来越多的企业
倾向于将自已的业务部署到云平台上。然而,最近的一些研究显示大多数商业
化集群的资源利用率都较低
[1,2,3,4]
。根据盖特纳和麦肯锡的研究数据,从全球范
围来看,服务器利用率仅达到 6%~12%。即使通过服务聚合技术进行优化,服务
器的利用率仍然只有 7%~17%。因此如何有效地对各类资源进行管理,保证资
源的高利用率和服务的高可用性成为了云平台管理者的一大挑战。
为了进一步提高资源利用率,可以通过更加细粒度的资源调度
[5,6,7]
以及借助
虚拟机和容器等虚拟化技术
[8,9,10,11]
将不同的服务实例整合在一起(比如将在线
服务和离线任务进行混合部署)
[12,13,14]
,使得工作负载分布的密度更高。但是这
种模式可能会对在线服务产生重大影响,例如由于在线服务和离线任务之间共
享资源 ,高密度部署会 引起严 重的资 源竞争,从而增 加在线 服务的 延迟,尤其是
长尾请求的延迟
[15,16]
。因此分析数据中心中服务器真实的资源利用率和各类工
作负载实际的运行状况有助于更好地了解各类资源的分配情况,还可以对目前
的调度算法提供有效的改进建议。
本文深入分析了阿里巴巴数据中心中某一个含有 4 034 台服务器的集群在
8 天时 间内所有服务器 的资 源利用情况以及 在线服务和离线任务 的运行状况。
通过对该数据集的分析,主要贡献有:
(1)通过对整个集群中所有在线任务以及离线任务资源使用情况的分析,
总结了工作负载资源使用的一些特点,包括:①从在线服务的运行情况来看,所
有容器的平均 CPU 利用率存在周期性变化,从每天的早 8 点到晚 9 点维持在一
个较高水平,并且在每天凌晨 4 点回落到最低点;②对离线任务来说,发现除去第
一天和第八天,剩下 6 天中任务提交峰值都集中在每天的同一时刻。其次 95%
实例的运行时间都在 199 s 以内,但是有 0.052%的实例运行时间在 1 h 以上甚
至会持续几天。
(2)对集群中的批处理作业和在线服务进行了聚类分析,并确定工作负载
模式,发现相对高资源利用率的容器占了所有容器的绝大部分,而低资源利用率、
短执行时间的实例则占了总实例的绝大部分。首先选择有效的特征指标作为聚
类的维度,然后使用 K-means 算法识别每个维度的聚类边界,并对其进行聚类
分析。
1 背景介绍
1.1 阿里 巴巴 任 务 调 度体 系
如图 1 所示,阿里巴巴通过两个调度器 Sigma
[17]
和 Fuxi
[18]
来调度集群中的
在线服务和离线任务,其中 Sigma 负责在线服务的调度,Fuxi 负责离线任务的调
度。
图 1
图 1 混部集群架构
Fig.1 Mixed cluster architecture
阿里巴巴的在线服务都由其自建的 Pouch 容器
[19]
进行托管并由 Sigma 负
责 Pouch 容器的部署决策。这些在线服务都是面向用户的,因此要求满足低延
迟和高性能的需求。通过阿里巴巴内部几年的实践以及多次双十一流量高峰的
考验,Sigma 已经证明了其大规模容器调度的能力。
Sigma 由 Alikenel、SigmaSlave、SigmaMaster 三层大脑联动协作。其
中,Alikenel 部署在每一台物理机上,它能够增强内核,在资源分配和时间片分配
上按优先级以及分配策略进行灵活调整。SigmaSlave 可以在本机对容器进行
CPU 分配、应急场景处理等。本机 Slave 会对时延敏感型任务的干扰快速做
出 决 策 和 响 应 , 从 而 避 免 因 全 局 决 策 处 理 时 间 延 长 带 来 的 业 务 损 失 。
SigmaMaster 是一个中心大脑,负责统揽全局,能够为大量物理机上容器部署进
行资源的调度和分配以及算法的优化决策。
Fuxi 负责管理非容器化的离线任务,而离线任务主要是复杂的大规模计算
类 应 用 程 序 , 因 此 Fuxi 采 用 数 据 驱 动 的 多 级 流 水 线 并 行 计 算 框 架 , 与 Map-
Reduce、Map-Reduce-Merge 等批处理编程模型兼容。
最终,整个系统通过 Level-0 策略机制来协调和管理两种类型的工作负载,
使其能够尽可能合理地部署在同一集群中。
1.2 数据 集基 本 介 绍
cluster-trace-v2018 数据集记录了 4 034 台服务器在 8 天时间内的运行状
况
[20]
。在后续计算中假设该数据采集时间从每一天的 0 点开始。该数据集一共
由 6 个文件组成(大约 270 GB),具体信息如表 1 所示。
表 1 阿里巴巴数据集记录行数
Table 1 Alibaba dataset record line number
表名
记录数
文件大小
machine meta
17 592
0.56 MB
machine usage
246 637 252
8.38 GB
container meta
370 540
22.26 MB
container usage
4 015 763 787
164.09 GB
batch task
14 295 731
0.98 GB
batch instance
1 351 255 775
103.69 GB
新窗口打开| 下载 CSV
该数据集主要记录了服务器、在线服务和离线任务的资源配置以及资源使
用情况,每个计算节点都配置了一定的资源,监控程序每过 60 s 就会采样一次实
际的资源使用情况,最后将 300 s 内采样值的平均值作为实际值记录到数据文
件中
[20]
。从这些文件介绍中可以得知,对离线任务而言,一个批处理作业就代表
一个离线任务,每个批处理作业都运行在物理机上,离线任务上的三级任务模式
关系图如图 2 所示,每个批处理作业(job)由多个任务(task)构成,而每个任
务由多个实例(instance)构成,每个实例都配有一定数量的资源(例如 CPU、
内存等)。实例是批处理作业的最小调度单位并在某一个特定节点上运行。每
个实例的资源配置和实际运行情况都会在数据文件中有相应的记录,例如开始
时间、结束时间、运行状态(成功或者失败)、平均 CPU 使用核数和最大 CPU
使用核数等。对在线服务而言,其应用程序都是运行在容器中,因此可以通过容
器的资源使用情况来分析应用程序的性能。容器的数据包括请求的资源量、实
际的资源使用率、cpi 和 mpki 等。分析这份数据将有助于解决大型 IDC 所面
临的在线服务和离线任务混合部署的问题,同时还可以对在线服务和离线任务
之间的协同调度提供合理的建议。
图 2
图 2 离线任务上三级任务模式关系图
Fig.2 Three-level task mode relationship diagram on offline tasks
2 在线任务基本 情况
2.1 服务 器上 容 器 基 本分 配情 况
首先根据 container_meta.csv 文件统 计了每台服务器 上容器数量 的分布
情况。container_meta.csv 中显示有 4 005 台服务器部署了容器,整个集群中所
有服务器一共部署了 71 476 个容器。具体统计信息如图 3、图 4 所示,在一台
服务器上最多部署 35 个容器,最少只部署 1 个容器,80%的服务器部署的容器数
量在 23 个以内,大部分服务器部署的容器数量集中在 8~25。
图 3
图 3 每台服务器包含的容器数量
Fig.3 Container amount of server
图 4
剩余25页未读,继续阅读
资源评论
罗伯特之技术屋
- 粉丝: 3692
- 资源: 1万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功