一种业务系统的容量管理方法、装置、设备及业务系统与流程
本申请涉及互联网技术领域，具体涉及一种业务系统的容量管理方法、装置、容量管理设备、业务系统及计算机可读存储介质。
背景技术：
随着互联网的快速发展，各种互联网业务层出不穷，为支持业务的正常运行，业务提供商通常都会设置互联网数据中心(internetdatacenter，简称为idc)，idc中通常包括多个服务器，idc的容量与服务器中的硬件资源息息相关，当然，业务对容量的需求增大时，可以对idc进行扩容。
针对一个业务的业务系统可能有多个idc，为了保障业务的正常运行，需要对业务系统进行容量管理，现有的容量管理通常会针对业务系统接口层、逻辑层、数据层采用同一标准来衡量容量，而忽略各种因素导致的差异性，如机型配置等。为了得到系统各层较准确的压测结果，一般会采用离线单机性能压测或者在线压测方式。在离线单机压测时，因机型硬件配置各异和业务实际应用不同，通常需要遍历覆盖多种测试场景；而使用在线压测时，则要求业务系统本身需要做好过载拒绝等保护策略，否则容易直接影响到线上正常服务运行。同时为了容灾和应对业务流量高峰所需，一般业务系统可用容量都会预留较多，因此很容易就出现了系统整体资源利用率偏低的情况。
随着设备更新换代，新旧设备共存、单机复用部署等现网复杂情况时常出现，现有的容量管理系统较少会考虑到各机型配置的差异性。在离线单机压测性能较准确的情况下，采用统一标准来衡量容量，会造成高配置性能的机型实际使用负载不高。现有的容量管理系统侧重于容量监控环节，在容量超载预警后倾向于依赖一线运营人员根据经验进行定性扩容，缺乏量化指标，这往往导致资源得不到最优化配置。
技术实现要素：
本申请实施例提供一种业务系统的容量管理方法，可以根据历史监测数据和当前监测周期的检测数据定量预估出预期时间的负载参考数据，该负载参考数据可以用于指示该业务系统的定量扩容，提高了业务系统扩容的精确度。本申请实施例还提供了相应的容量管理装置、容量管理设备、业务系统及计算机可读存储介质。
本申请第一方面提供一种业务系统的容量管理方法，包括：
周期性从数据库中获取目标维度的第一负载数据，所述数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，所述每个业务服务器上都部署有用于信息采集的所述客户端，所述每个业务服务器为所述业务系统中多个业务服务器中的一个；
根据所述目标维度的所述第一负载数据确定所述业务系统在所述目标维度命中高负载规则，则获取所述目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，所述第一业务指标数据和所述第一负载数据为当前监测周期的监测数据，所述第二业务指标数据和所述第二负载数据为历史监测数据；
根据所述第一业务指标数据和所述第一负载数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，所述负载参考数据用于指示对所述业务系统的容量进行管理。
本申请第二方面提供一种业务系统的容量管理装置，包括：
第一获取程序模块，用于周期性从数据库中获取目标维度的负载数据，所述数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，所述每个业务服务器上都部署有用于信息采集的所述客户端，所述每个业务服务器为所述业务系统中多个业务服务器中的一个；
第一确定程序模块，用于根据所述第一获取程序模块获取的所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则；
第二获取程序模块，用于在所述第一确定程序模块确定命中高负载规则后，获取所述目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，所述第一业务指标数据和所述第一负载数据为当前监测周期的监测数据，所述第二业务指标数据和所述第二负载数据为历史监测数据；
第二确定程序模块，用于根据所述第一获取程序模块获取的所述第一负载数据、所述第二获取程序模块获取的所述第一业务指标数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，所述负载参考数据用于指示对所述业务系统的容量进行管理。
本申请第三方面提供一种容量管理设备，包括：输入/输出(i/o)接口、处理器和存储器，所述存储器中存储有上述第一方面所述的业务系统的容量管理的指令；
所述处理器用于执行存储器中存储的业务系统的容量管理的指令，执行如上述第一方面所述的业务系统的容量管理方法的步骤。
本申请第四方面提供一种业务系统，包括：容量管理设备和多个业务服务器，所述多个业务服务器中的每个业务服务器上都分别部署有用于信息采集的客户端，每个所述客户端周期性向所述容量管理设备上报所在业务服务器的业务指标数据和负载数据；
所述容量管理设备为上述第二方面所述的容量管理装置。
本申请的又一方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面所述的容量管理方法。
本申请的又一方面提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面所述的方法。
本申请实施例采用周期性获取目标维度的第一负载数据，根据该第一负载数据确定是否命中高负载规则，若命中高负载规则，则根据历史监测数据和当前监测周期的检测数据定量预估出预期时间的负载参考数据，该负载参考数据可以用于指示该业务系统的定量扩容。与现有技术中在高负载告警后，通过个人经验进行扩容相比，本申请实施例提供的业务系统的容量管理方法，可以定量计算出预期时间的负载参考数据，从而为定量扩容提供参考建议，提高了业务系统扩容的精确度，优化了资源配置。
附图说明
图1是本申请实施例中业务系统的一实施例示意图；
图2是本申请实施例中业务系统的另一实施例示意图；
图3是本申请实施例中业务系统的容量管理方法的一实施例示意图；
图4是本申请实施例中可视化配置界面的一示例示意图；
图5是本申请实施例中业务系统的容量管理方法的另一实施例示意图；
图6是本申请实施例中业务系统的容量管理装置的一实施例示意图；
图7是本申请实施例中业务系统的容量管理装置的另一实施例示意图；
图8是本申请实施例中业务系统的容量管理设备的一实施例示意图；
图9是本申请实施例中容量管理设备的虚拟化形式的一实施例示意图。
具体实施方式
下面结合附图，对本申请的实施例进行描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。本领域普通技术人员可知，随着容量管理技术的发展，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
本申请实施例提供一种业务系统的容量管理方法，可以根据历史监测数据和当前监测周期的检测数据定量预估出预期时间的负载参考数据，该负载参考数据可以用于指示该业务系统的定量扩容，提高了业务系统扩容的精确度。本申请实施例还提供了相应的容量管理装置、容量管理设备、业务系统及计算机可读存储介质。以下分别进行详细说明。
图1为本申请实施例中业务系统的一实施例示意图。
如图1所示，本申请实施例中的业务系统包括容量管理设备10、网络20、多个业务服务器30和数据库40，数据库40可以是容量管理设备10上的内置存储设备，也可以是独立于容量管理设备10的存储设备。容量管理设备10、多个业务服务器30和数据库40通过网络通信连接。
每个业务服务器上都部署有用于信息采集的客户端，每个客户端可以实时采集各业务服务器的业务指标数据和负载数据，并向数据库40发送，若数据库40内置于容量管理设备10，则向容量管理设备10发送，由容量管理设备10存入数据库40。
当然，为了节省业务服务器上的监测资源和网络的传输资源，每个客户端可以是周期性上报各业务服务器的业务指标数据和负载数据。
本申请实施例中的业务指标数据可以是客户端长连接数、延时等。负载数据可以是业务服务器的中央处理器(英文全称：centralprocessingunit，英文简称：cpu)、内存、网卡和磁盘的使用情况，如：使用量或者使用比率等。
每个业务服务器上在接入业务系统前可以通过离线单机压测方式进行测试，当然也可以在接入系统后通过在线的方式进行压测，本申请实施例中以离线单机压测为例进行介绍。
离线单机压测可以为标准机型作基线化的性能配置。例如，当接收10000个/s业务指标请求时，统计该被测试单机的cpu、内存、流量各消耗多少百分比资源；找到该机型资源瓶颈之后，按照瓶颈例如80％的使用量支撑去逐步提升以求得业务指标请求数最大值。随着设备更新换代，即使同一种机型也有可能会作硬件版本配置升级，因此对于同一种机型也需要对不同硬件版本进行测试。经过一系列基线化压测之后，本方案可以得到类似如下所示的配置链信息：系统名称-子模块名称-机型-硬件版本-cpu资源-内存资源-流量资源-磁盘资源-最大请求连接数-瓶颈标记。其中，系统名称就是业务系统的名称，子模块名称可以是idc的名称，也可以是idc中再划分的子集群的名称，机型就是被测试单机的型号，硬件版本就是硬件版本号，cpu资源-内存资源-流量资源-磁盘资源都是单机中的资源可用量信息，最大请求连接数指的是agent请求连接数量，瓶颈指的是硬件资源中最先出现满载的硬件资源，例如：cpu最先出现满载，则该cpu为该单机的瓶颈，则瓶颈标记为cpu。
每个业务服务器都可以配置有一条配置链信息，配置链信息会上传到数据库中，若业务服务器上的硬件资源发生变化，则要对应更新相应配置链信息。
以上图1所示出的业务系统中只有一个互联网数据中心(英文全称：internetdatacenter，英文简称：idc)的情况，实际上，本申请实施例中的业务系统可以包括多个idc，如图2所示，每个idc中都包括多个业务服务器30，各idc可以位于同一个城市，也可以位于不同城市，如很多大型网络游戏在各大城市都会部署独立的idc，以保障游戏的稳定性。
图2与图1相比，只是多idc，每个idc中各业务服务器的测试和数据上报方面都与图1基本相同，可以参阅上面的描述进行理解。
基于上面描述的性能配置链，业务系统在各idc、各子集群的整体负载可以根据该idc或者子集群中的单机实际负载计算推导得出。本申请实施例中的单机指的是业务服务器。
本申请实施例中，容量管理设备10可以对业务系统的容量进行管理，参阅图3，业务系统的容量管理方法的一实施例可以包括：
101、周期性从数据库中获取目标维度的第一负载数据，所述数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，所述每个业务服务器上都部署有用于信息采集的所述客户端，所述每个业务服务器为所述业务系统中多个业务服务器中的一个。
周期的长度可以设定，例如可以五分钟为一个周期，也可以设定其他时间长度。
数据库中会存储有每个客户端每次上报的业务指标数据和负载数据。
容量管理设备还可以对数据库中的业务指标数据和负载数据进行管理，例如：以每5分钟上报一次为例，可以将每5分钟上报的数据进行聚合，以得到1小时的数据，或者其他时间长度的数据。
目标维度可以是单机维度、子集群维度或者业务系统维度，其中，子集群维度可以是idc维度，还可以是idc中再划分的子集群的维度。
102、根据所述目标维度的所述第一负载数据确定所述业务系统在所述目标维度命中高负载规则，则获取所述目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，所述第一业务指标数据和所述第一负载数据为当前监测周期的监测数据，所述第二业务指标数据和所述第二负载数据为历史监测数据。
高负载规则可以与目标维度对应，高负载规则指的是达到在该目标维度达到了资源的承受能力的警戒线。
历史监测数据通常是与当前监测周期的监测数据有一段时间长度的数据，例如：上一年同期的历史监测数据，也可以是几个月之前的历史监测数据。
103、根据所述第一业务指标数据和所述第一负载数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，所述负载参考数据用于指示对所述业务系统的容量进行管理。
负载参考数据可以是在于预期时间负载会增长到的数据，也可以是当前目标维度的资源缺口建议、现网各目标维度的负载明细、未来一月内目标维度的负载预估等信息。
本申请实施例采用周期性获取目标维度的第一负载数据，根据该第一负载数据确定是否命中高负载规则，若命中高负载规则，则根据历史监测数据和当前监测周期的检测数据定量预估出预期时间的负载参考数据，该负载参考数据可以用于指示该业务系统的定量扩容。与现有技术中在高负载告警后，通过个人经验进行扩容相比，本申请实施例提供的业务系统的容量管理方法，可以定量计算出预期时间的负载参考数据，从而为定量扩容提供参考建议，提高了业务系统扩容的精确度，优化了资源配置。
本申请实施例中在容量管理设备中可以提供可视化的界面来显示当前业务系统的负载和可用容量，容量管理人员可以自行选择以城市级、同城idc级、子集群级、单机负载等空间维度来了解系统当前负载情况，也可以选择按5分钟、按小时、按天、按周、按月等时间维度来了解系统历史负载情况。在当前监控周期内(默认按5分钟统计)，若某一空间维度的负载刚好命中高负载规则时，则会触发容量超载预警邮件给到业务系统业务运营人员，同时附带上负载参考数据。
可视化的界面可以参阅图4进行理解，如图4所示，可以根据需求选择，在可视化界面上查看不同维度的负载数据和业务指标数据。业务运营人员可以通过图4的可视化界面修改提交更新性能匹配链。
本申请实施例中数据库可以是容量管理设备中的存储资源，该容量管理设备中可以包括压测配置模块、单机资源信息采集接收模块、负载定时计算模块、资源超载预警模块和容量预估模块几个功能模块。业务系统的每个业务服务器上包括一个用于信息采集的客户端，下面结合图5进行介绍。
用于信息采集的客户端201会监测并周期性采集该监测周期的业务指标数据和负载数据，并向容量管理设备上报，单机资源信息采集模块202会接收该业务指标数据和负载数据。
单机资源信息采集模块202会接收业务指标数据和负载数据，并将接收的业务指标数据和负载数据存入数据库203。
压测配置模块204在基线化性能配置前台页面完成对应的配置链信息录入和提交更新。在提交动作执行后，容量管理系统后台会同步更新数据库203中配置链信息，配置链信息是一张基础数据表，其主要包括：系统名称、子模块、机型、硬件版本、cpu、内存、流量、磁盘、请求连接数、延时、瓶颈标记等字段。例如在前端接入模块压测过程中，以请求连接数为输入变量，当处理响应不超过最大容忍延迟时，容量管理设备判定首先达到例如80％消耗量的资源会成为该子模块的性能瓶颈，并记为瓶颈标记。
在设备又更新时，所述容量管理方法还包括：
接收到所述业务系统的设备更新请求时，更新所述数据库中的配置链信息，所述配置链信息为对所述每个业务服务器进行测试时所建立的，所述配置链信息包括所述每个业务服务器的各硬件资源的可用信息和瓶颈硬件资源信息。
本申请实施例中在各业务服务器上统一部署资源监控采集agent用来周期性定时上报cpu使用率、内存使用量、网卡流量、磁盘使用率等负载数据，同时还会上报agent请求连接数、延时等业务指标数据。以一天抽样采集时间点1440次，业务服务器总量1000台，单机负载数据和业务指标数据共有6个属性，数据持久化存储周期3年来计算，若采用mysql单表存储，则表的记录数将达到1440*1000*6*365*3＝94.608亿条，显然此时对数据单表作任意增删改查操作都会十分缓慢。为了提高数据库并发处理性能，减少锁表操作，本申请实施例中选择以表名_ip_月份为innodb分表命名格式，表的主要字段包括：ip、cpu利用率、内存使用量、网卡流量、磁盘利用率、抽样时间点等。
负载定时计算模块205可采用定时方式完成以5分钟、小时、天、周、月等时间维度的负载汇总计算。在业务系统负载均衡的前提下，以业务系统idc这一维度为例，同一idc在某一时间跨度下的各资源因子平均负载将分别取该idc名下业务服务器在该段时间范围内的负载平均值。
对于以城市级为接入集(set)、同城异idc容灾的业务系统来说，单idc这一维度来分析系统的现网整体负载和容量现状，还是不够精准。由于当前业务系统实际接入逻辑是会对agent连接请求按就近原则接入到最近的城市set，同时根据同城各idc机器请求成功率和延时上报情况再作均衡调度。因此，容量管理设备可以依赖于一张原始数据基础表，该表用来存储如下连接关系：系统名称–子集群-城市归属-idc归属-ip)，就可以通过多表联合查询和匹配计算生成一张中间表用来表示如下连接关系：系统名称-子集群-城市归属-idc归属-cpu平均负载-内存平均负载-平均流量-磁盘平均负载-瓶颈标记-计算时间点。
原始数据基础表在业务系统未进行扩缩容的时候可以认为是保持不变的，为了减少查表操作以加快匹配计算速度，容量管理设备开辟了一片4mb的缓存用来加载原始数据基础表信息，同时开辟了一片8mb的缓存将业务服务器5分钟内上报的负载数据和业务指标数据做聚合，求得负载平均值后将连接关系信息插入到以5分钟为统计维度的一张中间表以作记录存储。同理，当时间点每满1小时后，系统会生成一个子进程，该子进程用于对上一小时内每5分钟的存储统计记录作查询聚合，以求得负载均值。将新的连接关系信息插入到以小时为统计维度的中间表以作记录存储，同理，依次得到负载数据在以按天、周、月统计的中间表记录存储。
可选地，本申请实施例中，所述容量管理方法还包括：
对所述每个业务服务器的客户端周期性上报的业务指标数据和负载数据进行聚合处理，得到各种所述目标维度的业务指标数据和负载数据。
资源超载预警模块206主要用来跟踪观察业务系统目标维度的负载是否命中高负载规则，若有，则触发超载预警邮件给到业务运营人员。目前制定的高负载规则主要包括如下：(1)单机资源使用率超过80％，如cpu、内存、硬盘、网卡流量等；(2)业务系统各子模块汇总得到的资源平均使用率超过80％，且以按天为周期统计资源高负载状态持续超过3天；(3)因业务系统采用同城异idc容灾方案，容量管理系统还需要确保即使损失单idc的容量也能保障安全业务系统正常服务，此时需要满足条件：load(idc1)<(1-load(idc2))+...(1-load(idcn))，n为大于2的整数，当业务系统各idc负载不满足上述条件时也会触发超载预警邮件。
可选地，本申请实施例中，所述目标维度为单机维度时，所述高负载规则为单机中瓶颈硬件资源的使用量达到瓶颈；
所述根据所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则，包括：
根据所述第一负载数据确定所述单机中瓶颈硬件资源的使用量是否达到瓶颈，所述第一负载数据中包括所述单机中各硬件资源的使用量；
若达到瓶颈，则确定所述业务系统在所述单机维度命中高负载规则。
可选地，本申请实施例中，所述目标维度为子集群维度时，所述高负载规则为所述子集群中的各硬件资源的总体使用率超过使用率阈值；
所述根据所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则，包括：
根据所述目标维度的第一负载数据确定所述子集群中各硬件资源的总体使用率是否超过所述各硬件资源的使用率阈值，所述各硬件资源的总体使用率为所述子集群中各单机硬件资源的使用量与所述子集群总体可用容量的比值，所述第一负载数据根据所述子集群中各单机的负载数据汇总得到；
若超过所述各硬件资源的使用率阈值，则确定所述业务系统在所述子集群维度命中高负载规则。
可选地，本申请实施例中，所述目标维度为业务系统维度，且所述业务系统包括n个互联网数据中心idc时，所述高负载规则为不满足如下各idc的负载关系：
load(idc1)<(1-load(idc2))+...(1-load(idcn))，n为大于2的整数；
所述根据所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则，包括：
根据所述第一负载数据确定所述各idc的负载数据，所述第一负载数据包括所述各idc的负载数据；
确定所述各idc的负载数据是否满足所述各idc的负载关系；
若不满足，则确定所述业务系统在所述业务系统维度命中高负载规则。
可选地，本申请实施例中，所述容量管理方法还包括：
输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述负载参考数据。
可选地，本申请实施例中，所述容量管理方法还包括：
根据所述负载参考数据确定所述业务系统的扩容参考建议信息；
输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述扩容参考建议信息。
容量预估模块207通过历史监测数据和当前监测周期的监测数据来预估负载参考数据，可以通过如下公式来确定：
其中，l△t为在预期时间的负载参考数据，c△t为在所述预期时间的预估业务指标，cb为第二业务指标数据，cn为第一业务指标数据，ln为第一负载数据，lb为第二负载数据。
资源供应系统208可以将供货周期等数据存储数据库中，这样容量预估模块207在做容量预估时可以根据供货周期进行计算。
由于对内部服务器资源作精准调度和各功能模块扩容上线还需要花销一定的时间r(以自然天为单位)，因此方案还另外刻画定义一个高负载风险指数w，定义公式如下：
本申请实施例所提供的容量管理方法可以有效地根据业务系统现网负载情况对系统容量作动态管理以适应当前需求，可以精细化度量设备资源使用合理性，减少了设备使用低利用率情况的出现。同时可以较前瞻性地定量预估出未来安全系统容量和负载增长趋势，为项目运营人员提供一种扩缩容和设备调度采购参考决策，切实达到合理控制项目预算和运营成本目的，减少服务器资源浪费。
本技术方案的基线化性能配置离线压测步骤可替换改为在线压测以得到更真实的资源性能瓶颈判断，考虑到现网实际会有多种环境因素影响(如网络延时、丢包乱序等)，在线压测的基线化性能匹配链可取不同时刻多次抽样得到的平均值为准。本技术方案对于系统高负载采用了较通用的定义规则，实际上除了考察资源使用率之外，还可以利用请求成功率、网络丢包率、响应延时等不同维度数据来自定义高负载匹配规则以更精细化衡量系统容量状况和高负载风险指数。
参阅图6，本申请实施例提供的业务系统的容量管理装置30包括：
第一获取程序模块301，用于周期性从数据库中获取目标维度的负载数据，所述数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，所述每个业务服务器上都部署有用于信息采集的所述客户端，所述每个业务服务器为所述业务系统中多个业务服务器中的一个；
第一确定程序模块302，用于根据所述第一获取程序模块301获取的所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则；
第二获取程序模块303，用于在所述第一确定程序模块302确定命中高负载规则后，获取所述目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，所述第一业务指标数据和所述第一负载数据为当前监测周期的监测数据，所述第二业务指标数据和所述第二负载数据为历史监测数据；
第二确定程序模块304，用于根据所述第一获取程序模块303获取的所述第一负载数据、所述第二获取程序模块获取的所述第一业务指标数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，所述负载参考数据用于指示对所述业务系统的容量进行管理。
本申请实施例采用周期性获取目标维度的第一负载数据，根据该第一负载数据确定是否命中高负载规则，若命中高负载规则，则根据历史监测数据和当前监测周期的检测数据定量预估出预期时间的负载参考数据，该负载参考数据可以用于指示该业务系统的定量扩容。与现有技术中在高负载告警后，通过个人经验进行扩容相比，本申请实施例提供的业务系统的容量管理装置，可以定量计算出预期时间的负载参考数据，从而为定量扩容提供参考建议，提高了业务系统扩容的精确度，优化了资源配置。
可选地，参阅图7，本申请实施例提供的容量管理装置30的另一实施例中，容量管理装置30还包括输出程序模块305，
输出程序模块305用于输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述负载参考数据。
或者，在第二确定程序模块304还用于根据所述负载参考数据确定所述业务系统的扩容参考建议信息后，输出程序模块305用于输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述扩容参考建议信息。
可选地，本申请实施例提供的容量管理装置30的另一实施例中，
第二确定程序模块304用于：
根据如下公式确定所述负载参考数据；
其中，l△t为在预期时间的负载参考数据，c△t为在所述预期时间的预估业务指标，cb为第二业务指标数据，cn为第一业务指标数据，ln为第一负载数据，lb为第二负载数据。
可选地，本申请实施例提供的容量管理装置30的另一实施例中，
第一确定程序模块302用于在所述目标维度为单机维度时，所述高负载规则为单机中瓶颈硬件资源的使用量达到瓶颈时：
根据所述第一负载数据确定所述单机中瓶颈硬件资源的使用量是否达到瓶颈，所述第一负载数据中包括所述单机中各硬件资源的使用量；
若达到瓶颈，则确定所述业务系统在所述单机维度命中高负载规则。
可选地，本申请实施例提供的容量管理装置30的另一实施例中，
第一确定程序模块302用于在所述目标维度为子集群维度时，所述高负载规则为所述子集群中的各硬件资源的总体使用率超过使用率阈值时：
根据所述目标维度的第一负载数据确定所述子集群中各硬件资源的总体使用率是否超过所述各硬件资源的使用率阈值，所述各硬件资源的总体使用率为所述子集群中各单机硬件资源的使用量与所述子集群总体可用容量的比值，所述第一负载数据根据所述子集群中各单机的负载数据汇总得到；
若超过所述各硬件资源的使用率阈值，则确定所述业务系统在所述子集群维度命中高负载规则。
可选地，本申请实施例提供的容量管理装置30的另一实施例中，
第一确定程序模块302用于在所述目标维度为业务系统维度，且所述业务系统包括n个互联网数据中心idc时，所述高负载规则为不满足如下各idc的负载关系load(idc1)<(1-load(idc2))+...(1-load(idcn))，n为大于2的整数时：
根据所述第一负载数据确定所述各idc的负载数据，所述第一负载数据包括所述各idc的负载数据；
确定所述各idc的负载数据是否满足所述各idc的负载关系；
若不满足，则确定所述业务系统在所述业务系统维度命中高负载规则。
可选地，本申请实施例提供的容量管理装置30的另一实施例中，
第一获取程序模块301，还用于接收到所述业务系统的设备更新请求时，更新所述数据库中的配置链信息，所述配置链信息为对所述每个业务服务器进行测试时所建立的，所述配置链信息包括所述每个业务服务器的各硬件资源的可用信息和瓶颈硬件资源信息。
可选地，本申请实施例提供的容量管理装置30的另一实施例中，
第一确定程序模块302还用于对所述每个业务服务器的客户端周期性上报的业务指标数据和负载数据进行聚合处理，得到各种所述目标维度的业务指标数据和负载数据。
以上对容量管理装置30的描述可以参阅前面图1至图5的相应部分进行理解，本处不做过多赘述。
图8是本发明实施例提供的容量管理设备40的结构示意图。所述容量管理设备40包括处理器410、存储器450和收发器430，存储器450可以包括只读存储器和随机存取存储器，并向处理器410提供操作指令和数据。存储器450的一部分还可以包括非易失性随机存取存储器(nvram)。
在一些实施方式中，存储器450存储了如下的元素，可执行模块或者数据结构，或者他们的子集，或者他们的扩展集:
在本发明实施例中，通过调用存储器450存储的操作指令(该操作指令可存储在操作系统中)，
周期性从数据库中获取目标维度的第一负载数据，所述数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，所述每个业务服务器上都部署有用于信息采集的所述客户端，所述每个业务服务器为所述业务系统中多个业务服务器中的一个；
根据所述目标维度的所述第一负载数据确定所述业务系统在所述目标维度命中高负载规则，则获取所述目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，所述第一业务指标数据和所述第一负载数据为当前监测周期的监测数据，所述第二业务指标数据和所述第二负载数据为历史监测数据；
根据所述第一业务指标数据和所述第一负载数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，所述负载参考数据用于指示对所述业务系统的容量进行管理。
本申请实施例采用周期性获取目标维度的第一负载数据，根据该第一负载数据确定是否命中高负载规则，若命中高负载规则，则根据历史监测数据和当前监测周期的检测数据定量预估出预期时间的负载参考数据，该负载参考数据可以用于指示该业务系统的定量扩容。与现有技术中在高负载告警后，通过个人经验进行扩容相比，本申请实施例提供的业务系统的容量管理设备，可以定量计算出预期时间的负载参考数据，从而为定量扩容提供参考建议，提高了业务系统扩容的精确度，优化了资源配置。
处理器410控制容量管理设备40的操作，处理器410还可以称为cpu(centralprocessingunit，中央处理单元)。存储器450可以包括只读存储器和随机存取存储器，并向处理器410提供指令和数据。存储器450的一部分还可以包括非易失性随机存取存储器(nvram)。具体的应用中容量管理设备40的各个组件通过总线系统420耦合在一起，其中总线系统420除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线系统420。
上述本发明实施例揭示的方法可以应用于处理器410中，或者由处理器410实现。处理器410可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器410中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器410可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器450，处理器410读取存储器450中的信息，结合其硬件完成上述方法的步骤。
可选地，收发器430用于输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述负载参考数据。
可选地，处理器410用于：根据所述负载参考数据确定所述业务系统的扩容参考建议信息；
收发器430用于输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述扩容参考建议信息。
可选地，处理器410用于根据如下公式确定所述负载参考数据；
其中，l△t为在预期时间的负载参考数据，c△t为在所述预期时间的预估业务指标，cb为第二业务指标数据，cn为第一业务指标数据，ln为第一负载数据，lb为第二负载数据。
可选地，处理器410用于在所述目标维度为单机维度时，所述高负载规则为单机中瓶颈硬件资源的使用量达到瓶颈时：
根据所述第一负载数据确定所述单机中瓶颈硬件资源的使用量是否达到瓶颈，所述第一负载数据中包括所述单机中各硬件资源的使用量；
若达到瓶颈，则确定所述业务系统在所述单机维度命中高负载规则。
可选地，处理器410用于在所述目标维度为子集群维度时，所述高负载规则为所述子集群中的各硬件资源的总体使用率超过使用率阈值时：
根据所述目标维度的第一负载数据确定所述子集群中各硬件资源的总体使用率是否超过所述各硬件资源的使用率阈值，所述各硬件资源的总体使用率为所述子集群中各单机硬件资源的使用量与所述子集群总体可用容量的比值，所述第一负载数据根据所述子集群中各单机的负载数据汇总得到；
若超过所述各硬件资源的使用率阈值，则确定所述业务系统在所述子集群维度命中高负载规则。
可选地，处理器410用于在所述目标维度为业务系统维度，且所述业务系统包括n个互联网数据中心idc时，所述高负载规则为不满足如下各idc的负载关系load(idc1)<(1-load(idc2))+...(1-load(idcn))，n为大于2的整数时：
根据所述第一负载数据确定所述各idc的负载数据，所述第一负载数据包括所述各idc的负载数据；
确定所述各idc的负载数据是否满足所述各idc的负载关系；
若不满足，则确定所述业务系统在所述业务系统维度命中高负载规则。
可选地，收发器430用于接收到所述业务系统的设备更新请求时，更新所述数据库中的配置链信息，所述配置链信息为对所述每个业务服务器进行测试时所建立的，所述配置链信息包括所述每个业务服务器的各硬件资源的可用信息和瓶颈硬件资源信息。
可选地，处理器410还用于对所述每个业务服务器的客户端周期性上报的业务指标数据和负载数据进行聚合处理，得到各种所述目标维度的业务指标数据和负载数据。
上对容量管理设备60的描述可以参阅图1至图5部分的描述进行理解，本处不再重复赘述。
以上容量管理设备还可以是虚拟化的系统，该容量管理设备在虚拟化场景下的表现形式如图9所示，该虚拟化场景下的容量管理设备包括硬件层和运行在硬件层之上的虚拟机监控器(vmm)1001，以及多个虚拟机1002。可以选择一个或者多个虚拟机作为主控节点，以及多个虚拟机作为工作节点。
具体的，虚拟机1002：通过虚拟机软件在公共硬件资源上模拟出的一台或者多台虚拟的计算机，而这些虚拟机就像真正的计算机那样进行工作，虚拟机上可以安装操作系统和应用程序，虚拟机还可访问网络资源。对于在虚拟机中运行的应用程序而言，虚拟机就像是在真正的计算机中进行工作。
硬件层：虚拟化环境运行的硬件平台，可以由一个或多个物理主机的硬件资源抽象得到的。其中，硬件层可包括多种硬件，例如包括处理器1004(例如cpu)和存储器1005，还可以包括网卡1003(例如rdma网卡)、高速/低速输入/输出(i/o，input/output)设备，及具有特定处理功能的其它设备。
另外，该虚拟化场景下的分布式系统还可以包括宿主机(host)：作为管理层，用以完成硬件资源的管理、分配；为虚拟机呈现虚拟硬件平台；实现虚拟机的调度和隔离。其中，host可能是虚拟机监控器(vmm)；此外，有时vmm和1个特权虚拟机配合，两者结合组成host。其中，虚拟硬件平台对其上运行的各个虚拟机提供各种硬件资源，如提供虚拟处理器(如vcpu)、虚拟内存、虚拟磁盘、虚拟网卡等等。其中，该虚拟磁盘可对应host的一个文件或者一个逻辑块设备。虚拟机运行在host为其准备的虚拟硬件平台上，host上运行一个或多个虚拟机。
特权虚拟机：一种特殊的虚拟机，亦可称为驱动域，例如这种特殊的虚拟机在xenhypervisor平台上被称作dom0，在该虚拟机中安装了例如网卡、scsi磁盘等真实物理设备的驱动程序，能检测和直接访问这些真实物理设备。其他虚拟机利用hypervisor提供的相应机制通过特权虚拟机访问真实物理设备。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：rom、ram、磁盘或光盘等。
以上对本申请实施例所提供的业务系统中容量管理方法、容量管理装置、容量管理设备、业务系统以及计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
- 还没有人留言评论。精彩留言会获得点赞！