大规模分布式系统资源管理(一)
女主宣言
如今大火的机器学习和人工智能等技术如何应用在资源管理方面?我们请到了南开大学的王刚和李雨森教授前来360,分享他们以及所在课题组在大规模分布式系统资源管理方面的研究工作,内容包括云游戏系统中的请求调度、资源分配,以及搜索引擎数据中心的负载均衡、配额管理等。
PS:丰富的一线技术、多元化的表现形式,尽在“HULK一线技术杂谈”,点关注哦!
主要内容
云游戏中的资源管理
2
搜索引擎中的资源管理
3
AI 在资源管理中的应用
1
云游戏中的资源管理
云游戏
概念:Server 端运行游戏,并将压缩的视频传给 Client;Client 只负责解压、显示视频
优点: 将 load 从客户端转移到 Cloud端。显然用户就不用安装游戏,也不用很好的设备,普通的电脑就可以运行大型的游戏,从而实现
Gaming anywhere, anytime, on any device
挑战
完成高质量的游戏。比如,有的游戏玩家对游戏的反映时间和灵敏度有很高的要求,这一方面其实是很大的挑战。
延迟
双倍网络延迟 (Client - Server - Client)
有的游戏玩家对游戏的反映时间和灵敏度有很高的要求,使用时要把指令发送过去,再把指令传回来,同时还有视频压缩,这是一个很耗时的过程。
带宽
最低要求: 3~5 Mbps
传数值并不是一个小事情,如果传高质量的视频,最低要求是3-5Mbps的带宽。
成本
每台 server 同时只能运行几个游戏。
如果用户比较多的话,那么运营商就要提供很多的服务器。服务器的成本很高,包括它的运营成本维护成本等。云游戏收用户的钱可能还抵不过服务器的钱或者网络的钱。所以成本一直是云游戏里一个很大的挑战。
研究目标
优化成本
所有 server 的总运行时间最短
一般来说是用越少的服务器越好,也可以理解为,我们使用服务器的总运行时间最短。服务器的数量可能有的时候不太合理,如果这个机房有一万台服务器,它们可能不需要同时运行.如果这台服务器是空闲的,我们可以把它关掉或者是转化到一种低能耗的模式。所以我们的优化目标并不是单单的使所用的服务器数量最少,而是在满足用户条件的情况下使得所有服务器的运行时间最短。
请求调度
这里有一个假设,假设所有的服务器都是重构的,如果其他条件都没有变化的情况下,运行时间基本上是由请求调度算法来决定的。
Example
假如现在有三个请求,r1,r2,r3。它们是同时到来的,横轴表示时间,假设在0时刻三个请求都到了,r1和r3的结束时间是10分钟,可以理解为玩游戏的时间停留在系统里的时间是10分钟。r2很快就离开了,它的停留时间是1分钟,假如每台服务器只能服务两个请求,那么希望有2种策略。
左边是一种,把r1和r2放在一台服务器上,r3另开一台服务器,那么如果要完成3个请求的话这2台服务器都要运行10分钟。总时间就是20分钟。
右边的策略是,把r1和r3放在一起,r2单独放在一台服务器上,那么r1和r3需要运行10分钟,而r2在1分钟之后就可以把它调为低能耗的模式或者关掉它。
所以这个例子可以说明,采用不同的调度策略,服务器总的运行时间,某种程度上可以理解为总的成本,是有很大差别的。
问题定义
目标
如何调度游戏请求,使得总的 server 运行时间最少。
挑战
Online,请求到达后需马上做出决定
请求结束时间未知
运行中的游戏不能移动
相似问题
有一个和上面所讲的云游戏的请求调度问题非常相似的问题,叫动态装箱问题。
普通装箱问题:我有一些请求,那么我希望用最少的箱子即最少的服务器,来装下这些请求。
动态装箱问题:请求是有来的时间和结束的时间的。目标是,要有一个策略,使得整个过程中所用的顺时的服务器的最大的数量最小。
区别:我们的问题是使所有服务器开着的时间总和最小。
比如,图上每个绿色的条代表一个服务器开着的时间段的话,我们的目标是使所有这些加起来最小。
研究工作
可以说它是动态装箱问题的一个变形。我们就要研究经典的装箱问题的算法在这个问题上的表现如何。我们的研究工作主要集中在三个方面。
经典算法
经典调度算法在云游戏请求调度上的表现
二
新算法
预测请求结束时间,优化请求调度算法
三
问题延伸
考虑游戏部署开销
下面简要介绍一下这三个部分
一、经典算法
Any Fit
只有当前正在运行的 server 都满负载时,才开一台新的。
First Fit
在所有有空闲的 server 中,选择最早开始运行的那台 server。
Best Fit
在所有有空闲的 server 中,选择空闲最少的那台 server。目标是尽量使满的sever更满。
经典算法主要研究两个部分。
Worst Case Ratio 分析
主要研究最坏情况下这几种算法是最优解的多少倍。
对于1.3版本之前的Elasticsearch,fielddata cache大小是没有限制的。 从1.3版本开始,Elasticsearch添加了一个fielddata断路器,如果查询试图加载需要占用60%以上堆栈内存的fielddata,则会触发该断路器。
结论:通常情况下, Best Fit和First Fit的平均性能是差不多的。在最坏情况下,First Fit是有上界的,即First Fit在最坏情况下它不是很坏,但Best Fit在最坏情况下可以无限坏,没有上界。
Stochastic 分析
调度算法统计学上的平均性能。这里涉及到一些马尔可夫理论还有其他一些随机过程的理论。
二、新算法
游戏请求的 Daily Pattern
从早上七八点开始到12点左右请求一直是增加的。12点过后请求开始下降。
黄色的线是一个最优解,代表需要的使用服务器数量的下界。还有一条红色的线和灰色的线,它们俩是重合的,代表Best Fit和First Fit算法,说明它俩的表现是一样的,在下坡阶段即图中的0点-7点,比最优解还相差较多。可以得出结论:First Fit和Best Fit 在“下坡阶段”浪费大量服务器。
原因其实很简单。在上坡阶段,因为请求是不断地来的,不断开新的服务器,那么请求数量不断增加,每台服务器利用率就很高。在高峰比如11点,开了很多服务器,12点开始这些游戏请求就走了,进入了下坡阶段。这时每台服务器都都不是很满,这样浪费的服务器就比较多。如果游戏请求可以来回不断地发,那么这个问题就很好解决了。主要的问题是不满的这些服务器,这些请求是不能汇总到一台服务器上的。
请求结束时间预测
核心:游戏玩家的游戏时间是否可预测的。
如果是可预测的,请求到来时就能知道它大概什么时候走。如果不可预测那么整个算法就不可行。
我们对一些游戏进行了试验。其中后两个DotAlicious和WOT是组队式的。每一场游戏里面都有两队,每队里有几个队员。前面WoWAH是个人游戏。图纵坐标表示的是预测的错误率。
错误率越小说明预测的越准确。这里可以看到,组队的游戏比如DotAlicious和WOT,尤其是WOT,预测的是非常准确的。也就是说每个游戏section的时间是非常固定的。基于这个结论我们提出了一个新的调度算法。
基于请求结束时间预测的调度算法
当请求到来时,把差不多同一时间结束的请求放在一台服务器上。比如r1,r2和r3,这3个请求同时到来时,把r1和r3放在一起,因为预测r1和r3会差不多时间结束。
如图为DotAlicious游戏的结果。中间绿色的线表示用新的调度算法所用的服务器的数量,显然是在最优解和Best Fit,First Fit中间的,且更偏近最优解一些。
三、问题延伸
游戏部署开销
如果运行游戏的话服务器上肯定是要安装游戏的。有一个办法,就是一个数据中心所有的服务器共享,即把游戏都装在一个网络硬盘上,所有服务器需要它的时候通过网络访问它。但是这个办法被云游戏的公司证明是不可行的。
所以当前的云游戏公司采用的办法是每个服务器都自己装自己的游戏。这样就存在一个问题:每台服务器到底要装哪些游戏呢?
通常游戏的数量是很多的,比如200多个。如果每台服务器上都装了所有的游戏,那么开销是很大的。需要很大的硬盘,而且一个系统如果要装200多个游戏也不太可行。
那么如果不装200个游戏,而是每台服务器放一个游戏,这样会有一个问题:当一个游戏请求来的时候,一台服务器是空闲的但是它没有装所需要的游戏。这样可能就需要另外开一台服务器。那么同时需要的服务器数量就会增加。
如果规划目标是使开销最小,那么就需要一个合理的安装策略。
目标:如何部署游戏使得总开销最小
简化:服务器所安装的游戏是不交叉的。即同一类服务器只安装比如A,B,C这三个游戏,另外一些服务器装D和E这两个游戏,它们之间没有交叉,这个问题就变简单了。
分析
Stochastic, Markov models
算法
Simple Algorithms
Dynamic Programming Algorithms
Heuristic Algorith
总结
本期介绍了云游戏中的资源管理:
云游戏概念
挑战
研究目标
问题定义
相似问题
研究工作
下期我们将继续介绍剩下的两部分:
搜索引擎中的资源管理
AI 在资源管理中的应用
敬请期待~
HULK一线技术杂谈
由360云平台团队打造的技术分享公众号,内容涉及云计算、数据库、大数据、监控、泛前端、自动化测试等众多技术领域,通过夯实的技术积累和丰富的一线实战经验,为你带来最有料的技术分享
大规模分布式系统资源管理(一)相关推荐
- 大规模分布式系统资源管理(二)
女主宣言 上一期我们分享了<大规模分布式系统资源管理(一) >,介绍了云游戏中的资源管理: 本期将继续介绍搜索引擎中的资源管理和AI 在资源管理中的应用. PS:丰富的一线技术.多元化的表 ...
- 《大规模分布式系统架构与设计实战》
<大规模分布式系统架构与设计实战> 基本信息 作者: 彭渊 丛书名: 大数据技术丛书 出版社:机械工业出版社 ISBN:9787111455035 上架时间:2014-2-21 出版日期: ...
- 飞天5K实战经验:大规模分布式系统运维实践
摘要:随着阿里体量越来越大,数据也在呈几何倍数增长.因此,在运维工作上已很难找到其他企业的成功经验来借鉴,但又不能凭空揣测解决方案.本文详解了阿里飞天5K实战经验,带你了解大规模分布式系统运维实践. ...
- Dapper,大规模分布式系统的跟踪系统
文章目录 Dapper,大规模分布式系统的跟踪系统 概述 1.介绍 1.1 文献的总结 2.Dapper的分布式跟踪 2.1 跟踪树和span 2.2 植入点 2.3 Annotation 2.4 采 ...
- 论大规模分布式系统缓存设计策略
声明:本文为本人在软考系统架构设计师备考期间的练手写作,不保证内容的原创性与正确性,仅供参考,请勿照抄和用于学术论文等正规场合,因不当使用产生后果一律自负. 摘要 2019年3月,我单位联合某 ...
- 【转载】专访阿里陶辉:大规模分布式系统、高性能服务器设计经验分享
关注陶辉很长时间,初次对陶辉的了解还是在我们CSDN的博客上,从2007年开始写博客,一直到现在,如果不是对技术的追求和热爱,以及热爱分享的精神,我想不是很多人能坚持下来,拥有多年大型互联网公司的从业 ...
- 专访阿里陶辉:大规模分布式系统、高性能服务器设计经验分享
专访阿里陶辉:大规模分布式系统.高性能服务器设计经验分享 发表于2014-06-27 16:25|18197次阅读| 来源CSDN|55 条评论| 作者魏伟 云计算Nginx开源 摘要:先后就职于在国 ...
- 专訪阿里陶辉:大规模分布式系统、高性能server设计经验分享
http://www.csdn.net/article/2014-06-27/2820432 摘要:先后就职于在国内知名的互联网公司,眼下在阿里云弹性计算部门做架构设计与核心模块代码的编写,主要负责云 ...
- Dapper,大规模分布式系统的跟踪系统--转
原文地址:http://bigbully.github.io/Dapper-translation/ 概述 当代的互联网的服务,通常都是用复杂的.大规模分布式集群来实现的.互联网应用构建在不同的软件模 ...
最新文章
- 《C++ Primer Plus》第8章 函数探幽 学习笔记
- 【题解】CF1070E Getting Deals Done(二分+思维)难度⭐⭐⭐
- 《强化学习周刊》第10期:强化学习应用之计算机视觉
- 要求输入框里面必须同时含有字母,数字,特殊字符,且不小于8位
- 10以内数的组成分解图_学前儿童如何学习20以内的加减法,收藏了
- php实现按时间排序_按时间排序的问题?
- 【Network】协议栈
- 从零开始学 iOS 开发的15条建议
- swustoj水王C语言,swust西南科技大学OJ数据结构80题答案
- 2021爱分析·快消品牌商数字化厂商全景报告
- uploadify php完整,uploadify.php
- python宣传视频 抖音_python下载抖音无水印视频
- 提取Blast2go blast结果中的一部分
- 艾米丽Java游戏_艾米丽玩闹鬼 Emily Wants To Play中文游戏介绍_游戏库_巴士单机游戏...
- qt textbrowser的边界框怎样改变颜色_专访天使投资人续沛川:用深度思考打破人生边界,拥有张力一生...
- 使用k3s部署轻量Kubernetes集群快速教程
- Telnet - 访问8080端口并发送数据
- matlab学习教程,数模比赛入门速成
- 【推荐系统】召回模型线下评价指标
- StandardServer.await: create[8005]: java.net.BindException问题原因分析
热门文章
- Setting Expires and Cache-Control: max-age headers for static resources in ASP.NET
- Python 学习手记 pt5 模块
- 集成 Tomcat、 Servlet 的生命周期
- /etc/resolv.conf文件详解
- Apache Kafka 2.7.0 稳定版发布
- android 点击热区,增大UIButton的点击热区
- tampermonkey怎么不能用了_iPhone12无线充电不能用怎么办-苹果12无线充电失效原因...
- JS实现前端动态分页码
- 小知识:vue中的name的作用
- OPPO R17引领渐变色手机潮流,15步技术处理工艺出众