首页> 中国专利> 云数据中心计算能力管理系统

云数据中心计算能力管理系统

摘要

一种应用于云数据中心内、基于虚拟资源池管理模式的计算能力管理系统。系统采用客户端/服务器模式,将用户对平台计算能力的需求抽象成以CU为单位的计算能力值,并以此度量云数据中心内所有计算平台(物理机或虚拟机)的计算能力、构建计算能力数据库。客户端负责收集所在计算平台的静态信息(CPU信息、IP、侦听端口)、进行计算能力测试;服务器端接收每个客户端发来的报告,构建并计算能力数据库,同时管理用户对计算能力的需求,依据当前分配策略和现有计算资源得出最优分配方案。该系统依据计算能力对云数据中心的计算资源进行了抽象,向用户屏蔽了云数据中心和分配过程细节,同时所制定的分配策略在保障用户需求前提下可以提高计算资源利用率。

著录项

  • 公开/公告号CN103095853A

    专利类型发明专利

  • 公开/公告日2013-05-08

    原文格式PDF

  • 申请/专利权人 北京航空航天大学;

    申请/专利号CN201310061503.5

  • 申请日2013-02-27

  • 分类号H04L29/08(20060101);G06F9/50(20060101);

  • 代理机构

  • 代理人

  • 地址 100191 北京市海淀区学院路37号

  • 入库时间 2024-02-19 19:28:57

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2016-08-03

    授权

    授权

  • 2013-06-12

    实质审查的生效 IPC(主分类):H04L29/08 申请日:20130227

    实质审查的生效

  • 2013-05-08

    公开

    公开

说明书

技术领域

本发明涉及计算机科学中的云计算、数据中心领域,特别是涉及云计算环境 中根据计算能力需求进行资源管理分配的机制。

背景技术

云计算是一种基于互联网的计算方式,通过这种方式,共享的软硬件资源和 信息可以按需提供给计算机和其他设备。云计算描述了一种IT应用、服务的部 署、使用和交付模式,涉及通过互联网来提供动态、易扩展而且经常是虚拟化的 计算资源。云计算中的“计算资源”包括存储、处理器、内存和网络带宽等,它 们是由云数据中心内的所有物理机和虚拟机提供的;这些资源的总和经过统一管 理、调度,称为“虚拟资源池”或“计算资源池”。

云数据中心是为云计算安置计算机系统及相关部件的设施,在大多数情况下 表现为“服务器农场”,即安置有大量服务器的场所。对于云计算中应用、服务 的部署,最终表现为将这些应用、服务分配到不同的一台或多台服务器上运行。 本发明主要针对这一分配过程。

现有云数据中心计算资源管理系统的工作模式主要有:

(1)手动管理模式:

这是一种对用户不透明的管理方式。在云数据中心中,云计算提供商将根据 用户需求,分配固定的服务器或虚拟机给用户,由用户自行完成应用、服务的部 署。这样的部署方式常见于企业内部的私有云,并且较为落后,不利于资源统一 管理。

(2)基于虚拟资源池的管理模式:

云计算提供商将其云数据中心内的资源整合成虚拟资源池,对用户屏蔽了云 数据中心细节,使得在用户看起来就像是一台计算机一样。通过云计算提供商提 供的工具软件,用户可以随时随地提交自己的应用、服务,由计算平台自动分配 相应的物理机或虚拟机来运行。整个部署过程对用户透明,即用户根本不知道、 也不需要知道他的应用、服务最终是由哪些物理机或虚拟机来运行。

这两种管理模式有其各自有缺点。在手动管理模式中,用户几乎参与了应用 和服务的部署全过程。由于用户知道自己应用或服务的对计算资源的需求(即明 确知道运行这些应用或服务需要的服务器、虚拟机的性能),因此这样的方式一 般可以保障用户得到的应用、服务可以良好的运行。不足在于部署过程复杂,并 且用户通常会在申请计算资源过程中要求最新的计算平台,从而造成大量旧的计 算平台浪费,尽管它们也可满足需求。

而在基于虚拟资源池的部署模式中,用户的应用、服务的部署往往是根据用 户付费的多少来决定。付费多的用户可用的计算资源更多,其所部署的应用、服 务的运行效果相对就更好,但是这样往往造成资源的浪费,即用户虽然拥有很多 计算资源,但其应用、服务的正常运行可能并不需要这么多的资源。这在无形中 造成计算资源和用户资金的浪费。因此,本申请针对两种部署模式的不足,发明 了一种依据计算能力进行云数据中心计算资源整合、分配的方法。

发明内容

本发明以充分利用云数据中心计算能力为目标,设计并实现了一种云数据中 心计算能力管理系统,应用于一个或多个云数据中心中,可以克服现有管理分配 方式的不足。具体内容包括:

1.客户端计算能力收集

在云数据中心内,所有最终可用来运行用户应用或服务的物理机和虚拟机称 为该系统的全部客户端,即云数据中心内除去担任“服务器端”(服务器端定义 见下文)的所有物理机和虚拟机。在每个客户端上运行一个负责测试计算能力的 守护进程(使用Windows系统的客户端则为Windows Service,以下统称守护进 程),该进程负责在服务器端的管理下测试客户端计算能力,并向服务器端汇报 最终结果,同时,该进程还负责搜集客户端的计算机名称、IP地址等静态信息。

2.服务器端计算能力数据库维护与计算资源分配

在云数据中心内,该管理系统需要分配一台物理机或虚拟机作为该系统的服 务器端。服务器端负责收集客户端计算测试结果报告,并根据这些报告创建、维 护云数据中心的计算能力数据库。计算能力数据库包含当前计算能力总和、全部 客户端——计算能力映射表、已分配的计算能力——客户端映射表、客户端分配 频度记录表。对于用户提出的计算能力需求,该系统负责维护用户请求响应队列、 根据相关匹配策略分配满足用户需要的计算资源。整个分配过程对用户透明,分 配结果既能满足用户的计算能力需求,又可以最大程度利用计算资源。

3.计算能力的度量表示

计算能力的度量单位称作“计算单元(Computing Unit,以下简称CU)”, 1CU的计算能力被定义为当前云数据中心内计算能力最小的客户端所能提供的 计算能力,也称“CU基准分值”。客户端的守护进程对客户端进行整型数计算 能力测试(Integer Benchmark)和浮点数计算能力测试(Floating Point  Benchmark),将结果乘以相应权值并加和得出计算能力分值:

计算能力分值=浮点数计算能力得分×浮点数计算能力权值+整型数计算能 力得分×整型数计算能力权值,其中浮点数计算能力得分、整型数计算能力得分 分别为进行浮点数计算能力测试和整型数计算能力测试的结果,下同。

并且,

浮点数计算能力权值+整型数计算能力权值=1、0<浮点数计算能力权值,整 型数计算能力权值<1

则,

当前客户端的计算能力=[CPU测试得分/CU基准分值」·CUs

假设当前客户端计算能力分值为m,CU基准分值为k,则当前客户端计算 能力为[m/k」CUs。

4.计算能力分配策略

服务器端根据用户提出的计算能力需求,结合计算能力数据库和计算分配策 略进行最终的资源分配。这些分配策略旨在满足用户需求的同时尽可能充分利用 所有资源,包括如下:

(1)最小集合策略

该策略定义为:在满足用户需求的前提下,取所有可能的分配方案中包含的 物理机和服务器数量总和最小的分配方案作为分配结果。

(2)旧服务器优先策略

该策略定义为:在满足用户需求的前提下,在所有可能的分配方案中优先选 择包含旧服务器最多的方案作为分配结果。

(3)均匀分配策略

该策略定义为:在满足用户需求的前提下,查询客户端分配频度记录表,在 所有可能的分配方案中优先选择使用频度和最小的方案作为分配结果。

5.用户请求响应队列的管理

服务器端负责维护用户请求响应队列,即根据响应策略组织、调整对用户请 求的响应顺序。具体的响应策略包括:

(1)先来先服务策略

该策略定义为:依据用户请求到达服务器端的先后次序响应用户请求,优先 响应先到达的请求。

(2)优先级响应策略

该策略定义为:根据用户的优先级高低来处理请求响应次序,用户的优先级 越高,其请求就越早得到响应。

与现有技术相比,本系统发明的创新之处在于:能够根据计算能力组织、维 护云数据中心计算资源池;能够根据用户对计算能力的要求进行计算资源的分 配;分配过程对用户透明,并通过一系列分配策略提高计算资源的利用率。具体 体现为:

1.本发明中,依据整型数和浮点数计算能力测试结果,在服务器端维护计算 能力数据库,从而完成对云数据中心的计算能力整合,形成计算资源池。

2.本发明中,根据用户提出的计算能力需求来进行资源分配。并且在这一过 程中,用户并不知道资源的具体细节,如所处位置、处理器型号等。避免手动管 理模式中用户对全过程的参与,提升管理效率,同时,解决传统的基于虚拟资源 池模式对计算能力的浪费问题。

3.本发明中,根据一系列分配策略来提高资源利用率,避免手动管理模式中 旧服务器利用率不高问题,同时解决传统的基于虚拟资源池模式下的部分资源被 频繁分配问题。

附图说明

图1:系统结构图

图2:系统基本工作流程

图3:客户端/服务器通信过程

图4:通信消息格式

图5:用户请求队列设计

图6:计算能力数据库设计

具体实施方式

如图1所示,云数据中心计算能力管理系统采用客户端/服务器模式,由两 大主要部分构成:(1)在服务器端,如图1(a),服务器端由各模块和计算能力 数据库两部分构成,包括以下5个模块:服务器端管理模块负责调度其他模块, 当收到客户端发送的测试结果报告时,调用计算能力数据库访问模块执行对数据 库信息的更新;当有新的用户请求到达时,则调用用户请求队列管理模块更新请 求队列;通信模块,负责与客户端的通信,包括消息的收发、封装、解析等;计 算能力数据库管理模块,负责维护和执行对计算能力数据库的访问,如对数据库 中记录的增加、删除、查询、修改;用户请求队列管理模块,负责将用户的请求 组织成队列形式,并在队列不为空时将队列首个用户请求传送给计算资源分配模 块;计算资源分配模块,负责解析用户请求队列管理模块发来的队列元素,通过 计算能力数据库管理模块查询相关记录,根据既定策略做出分配结果。计算能力 数据库存储信息包括:当前云数据中心内所有客户端的计算能力表;客户端分配 表,记录每个客户端当前处于空闲还是分配状态;客户端分配频度表,记录每个 客户端的分配频度(次数)。(2)客户端由以下4个模块组成:通信模块,负责 与服务器端的通信,包括消息的收发、封装、解析;信息收集模块,负责收集客 户端静态信息,如CPU基本信息(使用汇编指令获得,根据得到的结果判断处 理器架构等基本信息)、IP地址,端口号(该系统默认使用8887端口进行通信) 等;客户端管理模块负责根据收到的服务器端消息调用不同模块,在收到服务器 端要求进行计算能力测试(即收到下文所述req消息)时,该模块调用计算能力 测试模块和信息收集模块进行计算能力测试、收集客户端静态信息;计算能力测 试模块负责测试客户端的浮点数计算能力和整型数计算能力,计算能力测试模块 汇总这两个测试结果并根据上文公式计算客户端计算能力。

如图2所示,系统的工作流程主要有两种情况,图2(a)是系统部署后初 始化流程:服务器端对所有客户端发出广播信息,要求上报计算能力测试结果, 此后根据收到的报告向数据库中添加相关记录,完成初始化过程。在其他服务器 端主动发起管理请求的工作场景中,其工作流程与此类似。不同之处在于服务器 端根据需要,向一个或多个客户端发送消息、或者向全部客户端发出广播消息。

如图2(b),用户请求处理的流程如下:若用户请求队列非空,则用户请求 队列管理模块取出队首元素,解析相关计算能力需求,随后传送到分配模块;分 配模块首先查阅计算能力数据库中相关记录,主要是剩余计算能力,以此做出包 含所有可行的分配方案的集合;若该集合非空,则根据分配策略做出最优选择并 返回结果,结束分配流程;若方案集合为空,则返回错误信息(用户需求不能得 到满足),结束分配流程。

图3描述了客户端和服务器端的一次完整通信过程的交互过程。本系统发明 中所有通信基于TCP套接字,且消息的基本格式遵循图4(a)所给出的结构, 不同之处在于不同消息的消息体有区别,所有消息的头部为4个字节,包括3 字节的消息魔数(魔数由ASCII码0x4D,0x47,0x54组成,即“MGT”的ASCII 编码),下1字节表述消息的类型码,不同消息的类型码不同。通信过程如下:

(1)TCP连接建立完成后,服务器端首先向客户端发出req消息,该消息 类型码为0x00,消息主体为空,表示要求收到消息的客户端上报计算能力测试 结果;

(2)随后,目的客户端返回announce消息,该消息的类型码为0x10,消息 主体格式参见图4(b),主要由16字节的客户端HASH值,2字节侦听端口号, 2字节所属云数据中心编号,3字节CPU标识,1字节IP地址类型(0x00表示 为IPv4地址,0x01表示为IPv6地址),16字节IP地址(若为ipv4地址,则前 12字节均用0x00填充,后四字节表示地址;若为IPv6地址,则16字节全部表 示地址),客户端HASH值由端口号、所属云数据中心编号、CPU标志、IP地址 类型、IP地址通过MD5算法得出;

(3)服务器端收到announce消息后,返回ready消息,该消息类型码为0x02, 消息主体见图4(c),主要由announce消息中的客户端HASH值,16字节的服 务器端标志(由服务器IP地址,所示云数据中心编号经MD5算法生成),以及 4字节确认码(0x00000000表示正常,可接受消息,0x00000001表示出错,这 时双方断掉TCP连接,一段时间后重新建立通信,重复以上步骤);

(4)客户端收到正常的ready消息后,发出report消息,该消息类型码为 0x11,消息主体由客户端HASH值、服务器端标志、4字节填充码(随机生成), 以及8字节计算结果组成,计算结果是客户端计算能力数值(例如计算能力为 22CUs,则该8字节数据内容表示整数22);

(5)report消息发送完毕,紧接着客户端发送report_complete消息,该消 息类型码为0x12,消息主体由客户端HASH值、服务器端标志、4字节结束标 志(0x00000000)组成;

(6)服务器端收到report消息后,紧接着对report_complete消息进行确认, 发送ack_report消息给客户端,该消息类型码为0x01,消息主体由客户端HASH 值、服务器端标志、4字节确认标识(0x00010000)组成;

(7)客户端收到ack_report消息后,得知服务器端已收到report消息且解 析无误,这时可以进入通信结束阶段,客户端向服务器连续发送两次offline消 息,该消息类型码为0x20,消息主体由客户端HASH值、服务器端标志、4字 节离线标志(0x11111111)组成,若服务器端在30秒内无回复,则断开TCP连 接。

图5表示用户请求管理的队列组成形式,图中标出三个队列元素作为示意。 其中,队首指针指向当前可以读取的元素,队尾指针指向当前可以写入的元素, 每个队列元素由用户名、优先级、计算能力需求组成,在默认情况下,队列根据 先来先服务原则组织,亦可调整根据优先级来重新组织队列。

计算能力数据库结构如图6所示,图6(a)表示计算能力资源表的结构设 计,其中客户端HASH值为该表主键,包含信息由客户端所属云数据中心编号、 IP地址类型、IP地址、端口号、CPU标志和计算能力值;图6(b)为分配频度 表,客户端HASH值为主键,并记录该客户端已分配次数;图6(c)为已分配 客户端表,客户端HASH值为主键,分配码为0表示尚未分配,分配码为1表 示当前已分配。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号