大规模分布式系统资源管理(二)

2019-09-10 15:59:18 采集侠

上一期我们分享了《大规模分布式系统资源管理(一) 》,介绍了云游戏中的资源管理;

本期将继续介绍搜索引擎中的资源管理和AI 在资源管理中的应用。

前期回顾 上一期介绍了云游戏中的资源管理:

云游戏:Server 端运行游戏,并将压缩的视频传给 Client;Client 只负责解压、显示视频。

云游戏的挑战:延时、带宽、成本

研究目标:优化成本、请求调度如何调度游戏请求,使得总的 server 运行时间最少。

研究工作经典算法:Any Fit、First Fit、Best Fit新算法:基于请求结束时间预测的调度算法

问题延伸:游戏部署开销

本期我们继续介绍:

搜索引擎中的资源管理

AI 在资源管理中的应用

搜索引擎中的资源管理 实例分布调整

问题描述

1、IDC 中有多种 service,每个 service 有很多实例

2、对已有实例的分布进行调整,达到负载均衡

3、约束条件

Resource Constraints (CPU, Memory, SSD)这个约束条件是关于资源的条件。调整过程中还有调整结束之前,都不能违反容量的限制。不能调整之后每台服务器加起来的容量超过了服务器的容量。

Conflict Constraints为了容错或者备份等,有一些实例是不可以放在同一台服务器上的。比如来自同一个service的实例。

No Service Interruption (Online)调整过程中是不能影响线上服务的。这是一个比较苛刻的条件。

搜索引擎

挑战

大规模调整复杂度高、小规模调整效果差

如果用数学来描述的话其实这是一个带约束条件的整数规划问题。这个问题的变量非常多,如果用数学传统的解方程的方法解出来的话是不太可能的。

线上调整对安全性、可靠性有极高要求

不光不能影响正常的服务,也不能带来任何的风险。调整的过程中不能使服务器超过安全线等有非常多的限制。

调整过程约束条件多

服务器

如果想把一个实例从一台服务器挪到另一台服务器上,在这个实例在新的服务器上能正常工作之前,旧的实例是不能删除的。所以这个实例在这段时间其实在新的服务器和旧的服务器上占了2份资源。而这段时间正好是调整的过程。所以说这个资源并没有被释放掉。

调整算法

局部搜索

局部搜索有几种搜索的策略。

1、Shift: 移动一个实例到另一台 server

如果移动完之后,负载变得更均衡了,那么这个方法就是可行的。

server

2、Swap: 交换位于不同 server 上的两个实例

如果负载变均衡了,那么这个操作是可接受的。

大规模分布式系统资源管理(二)

3、BigMove:移动实例到一台 server, 同时移走 server 上若干实例

server

这个会比前2种操作更有效。尤其在移动比较大的实例,系统资源比较紧张的时候,这个策略非常有效。 例子:

大规模分布式系统资源管理(二)

开始时有三台服务器,数字表示它的CPU所占用的比例。每台服务器的容量如果是100的话,左边的是60,中间的是100,右边的是50。那么我们通过BigMove移动之后,先把右边 的50移动到左边这台机器上,再把20挪到右边的机器上,30挪到中间的机器上,整个的balance就会好很多。

大规模分布式系统资源管理(二)

刚刚讲的Transient Constraint在移动过程中有可能会超过容量的限制,那怎么办呢?有可能移动是有顺序的。比如想移动50过来,如果20不挪出去的话它是进不来的,那么这会分为两轮算法。

整个算法的描述是这样的。

以server为单位多轮迭代,直到所有server变为不可调状态
(1) 每次迭代选取当前cpu使用率最高的server进行调整
(2) 依次对server上的每一个实例进行如下操作:
(a) 依次尝试shift, swap和BigMove调整
(b) 如果上述任意一个尝试成功,本次迭代结束,跳至步骤(1)
(c) 如果全部尝试失败,标记此实例为失败
(3) 如果server上所有的实例都失败,标记此server为不可调(以后不参与调
整),结束本次迭代,跳至步骤(1)

调整效果

CPU

CPU-Idle=1-CPU的利用率