CN110019110A - 一种业务系统的容量管理方法、装置、设备及业务系统 - Google Patents

一种业务系统的容量管理方法、装置、设备及业务系统 Download PDF

Info

Publication number
CN110019110A
CN110019110A CN201710633168.XA CN201710633168A CN110019110A CN 110019110 A CN110019110 A CN 110019110A CN 201710633168 A CN201710633168 A CN 201710633168A CN 110019110 A CN110019110 A CN 110019110A
Authority
CN
China
Prior art keywords
data
load
operation system
operational indicator
capacity management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201710633168.XA
Other languages
English (en)
Other versions
CN110019110B (zh
Inventor
冯松佳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201710633168.XA priority Critical patent/CN110019110B/zh
Publication of CN110019110A publication Critical patent/CN110019110A/zh
Application granted granted Critical
Publication of CN110019110B publication Critical patent/CN110019110B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases

Abstract

本申请公开了一种业务系统的容量管理方法，包括：周期性从数据库中获取目标维度的第一负载数据，数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，根据目标维度的第一负载数据确定业务系统在目标维度命中高负载规则，则获取目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，根据第一业务指标数据和第一负载数据、第二业务指标数据和第二负载数据，确定业务系统在预期时间的负载参考数据，负载参考数据用于指示对业务系统的容量进行管理。本申请实施例提供的业务系统的容量管理方法，可以定量计算出预期时间的负载参考数据，从而为定量扩容提供参考建议，提高了业务系统扩容的精确度，优化了资源配置。

Description

一种业务系统的容量管理方法、装置、设备及业务系统
技术领域
本申请涉及互联网技术领域，具体涉及一种业务系统的容量管理方法、装置、容量管理设备、业务系统及计算机可读存储介质。
背景技术
随着互联网的快速发展，各种互联网业务层出不穷，为支持业务的正常运行，业务提供商通常都会设置互联网数据中心(internet data center，简称为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。
当然，为了节省业务服务器上的监测资源和网络的传输资源，每个客户端可以是周期性上报各业务服务器的业务指标数据和负载数据。
本申请实施例中的业务指标数据可以是客户端长连接数、延时等。负载数据可以是业务服务器的中央处理器(英文全称：central processing unit，英文简称：CPU)、内存、网卡和磁盘的使用情况，如：使用量或者使用比率等。
每个业务服务器上在接入业务系统前可以通过离线单机压测方式进行测试，当然也可以在接入系统后通过在线的方式进行压测，本申请实施例中以离线单机压测为例进行介绍。
离线单机压测可以为标准机型作基线化的性能配置。例如，当接收10000个/s业务指标请求时，统计该被测试单机的CPU、内存、流量各消耗多少百分比资源；找到该机型资源瓶颈之后，按照瓶颈例如80％的使用量支撑去逐步提升以求得业务指标请求数最大值。随着设备更新换代，即使同一种机型也有可能会作硬件版本配置升级，因此对于同一种机型也需要对不同硬件版本进行测试。经过一系列基线化压测之后，本方案可以得到类似如下所示的配置链信息：系统名称-子模块名称-机型-硬件版本-CPU资源-内存资源-流量资源-磁盘资源-最大请求连接数-瓶颈标记。其中，系统名称就是业务系统的名称，子模块名称可以是IDC的名称，也可以是IDC中再划分的子集群的名称，机型就是被测试单机的型号，硬件版本就是硬件版本号，CPU资源-内存资源-流量资源-磁盘资源都是单机中的资源可用量信息，最大请求连接数指的是agent请求连接数量，瓶颈指的是硬件资源中最先出现满载的硬件资源，例如：CPU最先出现满载，则该CPU为该单机的瓶颈，则瓶颈标记为CPU。
每个业务服务器都可以配置有一条配置链信息，配置链信息会上传到数据库中，若业务服务器上的硬件资源发生变化，则要对应更新相应配置链信息。
以上图1所示出的业务系统中只有一个互联网数据中心(英文全称：internetdata center，英文简称：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，定义公式如下：当W越大，可认为系统未来高负载风险越高，容量系统认为W<＝1为相对安全经验值。有了未来一段时间的agent在线增量预估值，参照基线化性能匹配链，管理系统在高负载预警邮件发出的同时，还能提供安全资源精准化扩容参考建议，如建议在哪个IDC使用哪种机型的哪种硬件版本扩容多少台设备。
本申请实施例所提供的容量管理方法可以有效地根据业务系统现网负载情况对系统容量作动态管理以适应当前需求，可以精细化度量设备资源使用合理性，减少了设备使用低利用率情况的出现。同时可以较前瞻性地定量预估出未来安全系统容量和负载增长趋势，为项目运营人员提供一种扩缩容和设备调度采购参考决策，切实达到合理控制项目预算和运营成本目的，减少服务器资源浪费。
本技术方案的基线化性能配置离线压测步骤可替换改为在线压测以得到更真实的资源性能瓶颈判断，考虑到现网实际会有多种环境因素影响(如网络延时、丢包乱序等)，在线压测的基线化性能匹配链可取不同时刻多次抽样得到的平均值为准。本技术方案对于系统高负载采用了较通用的定义规则，实际上除了考察资源使用率之外，还可以利用请求成功率、网络丢包率、响应延时等不同维度数据来自定义高负载匹配规则以更精细化衡量系统容量状况和高负载风险指数。
参阅图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(CentralProcessing Unit，中央处理单元)。存储器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)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。
以上对本申请实施例所提供的业务系统中容量管理方法、容量管理装置、容量管理设备、业务系统以及计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (14)

1.一种业务系统的容量管理方法，其特征在于，包括：
周期性从数据库中获取目标维度的第一负载数据，所述数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，所述每个业务服务器上都部署有用于信息采集的所述客户端，所述每个业务服务器为所述业务系统中多个业务服务器中的一个；
根据所述目标维度的所述第一负载数据确定所述业务系统在所述目标维度命中高负载规则，则获取所述目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，所述第一业务指标数据和所述第一负载数据为当前监测周期的监测数据，所述第二业务指标数据和所述第二负载数据为历史监测数据；
根据所述第一业务指标数据和所述第一负载数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，所述负载参考数据用于指示对所述业务系统的容量进行管理。
2.根据权利要求1所述的容量管理方法，其特征在于，所述容量管理方法还包括：
输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述负载参考数据。
3.根据权利要求1所述的容量管理方法，其特征在于，所述容量管理方法还包括：
根据所述负载参考数据确定所述业务系统的扩容参考建议信息；
输出容量超载告警提示信息，所述容量超载告警提示信息中携带所述扩容参考建议信息。
4.根据权利要求1-3任一所述的容量管理方法，其特征在于，所述根据所述第一业务指标数据和所述第一负载数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，包括：
根据如下公式确定所述负载参考数据；
其中，L△t为在预期时间的负载参考数据，C△t为在所述预期时间的预估业务指标，Cb为第二业务指标数据，Cn为第一业务指标数据，Ln为第一负载数据，Lb为第二负载数据。
5.根据权利要求1-3任一所述的容量管理方法，其特征在于，所述目标维度为单机维度时，所述高负载规则为单机中瓶颈硬件资源的使用量达到瓶颈；
所述根据所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则，包括：
根据所述第一负载数据确定所述单机中瓶颈硬件资源的使用量是否达到瓶颈，所述第一负载数据中包括所述单机中各硬件资源的使用量；
若达到瓶颈，则确定所述业务系统在所述单机维度命中高负载规则。
6.根据权利要求1-3任一所述的容量管理方法，其特征在于，所述目标维度为子集群维度时，所述高负载规则为所述子集群中的各硬件资源的总体使用率超过使用率阈值；
所述根据所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则，包括：
根据所述目标维度的第一负载数据确定所述子集群中各硬件资源的总体使用率是否超过所述各硬件资源的使用率阈值，所述各硬件资源的总体使用率为所述子集群中各单机硬件资源的使用量与所述子集群总体可用容量的比值，所述第一负载数据根据所述子集群中各单机的负载数据汇总得到；
若超过所述各硬件资源的使用率阈值，则确定所述业务系统在所述子集群维度命中高负载规则。
7.根据权利要求1-3任一所述的容量管理方法，其特征在于，所述目标维度为业务系统维度，且所述业务系统包括n个互联网数据中心IDC时，所述高负载规则为不满足如下各IDC的负载关系：
Load(IDC1)<(1-Load(IDC2))+...(1-Load(IDCn))，n为大于2的整数；
所述根据所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则，包括：
根据所述第一负载数据确定所述各IDC的负载数据，所述第一负载数据包括所述各IDC的负载数据；
确定所述各IDC的负载数据是否满足所述各IDC的负载关系；
若不满足，则确定所述业务系统在所述业务系统维度命中高负载规则。
8.根据权利要求1-3任一所述的容量管理方法，其特征在于，所述容量管理方法还包括：
接收到所述业务系统的设备更新请求时，更新所述数据库中的配置链信息，所述配置链信息为对所述每个业务服务器进行测试时所建立的，所述配置链信息包括所述每个业务服务器的各硬件资源的可用信息和瓶颈硬件资源信息。
9.根据权利要求1-3任一所述的容量管理方法，其特征在于，所述容量管理方法还包括：
对所述每个业务服务器的客户端周期性上报的业务指标数据和负载数据进行聚合处理，得到各种所述目标维度的业务指标数据和负载数据。
10.一种业务系统的容量管理装置，其特征在于，包括：
第一获取程序模块，用于周期性从数据库中获取目标维度的负载数据，所述数据库中包括每个业务服务器的客户端所上报的业务指标数据和负载数据，所述每个业务服务器上都部署有用于信息采集的所述客户端，所述每个业务服务器为所述业务系统中多个业务服务器中的一个；
第一确定程序模块，用于根据所述第一获取程序模块获取的所述目标维度的第一负载数据确定所述业务系统在所述目标维度命中高负载规则；
第二获取程序模块，用于在所述第一确定程序模块确定命中高负载规则后，获取所述目标维度的第一业务指标数据、第二业务指标数据和第二负载数据，所述第一业务指标数据和所述第一负载数据为当前监测周期的监测数据，所述第二业务指标数据和所述第二负载数据为历史监测数据；
第二确定程序模块，用于根据所述第一获取程序模块获取的所述第一负载数据、所述第二获取程序模块获取的所述第一业务指标数据、所述第二业务指标数据和所述第二负载数据，确定所述业务系统在预期时间的负载参考数据，所述负载参考数据用于指示对所述业务系统的容量进行管理。
11.根据权利要求10所述的容量管理装置，其特征在于，
所述第二确定程序模块用于：
根据如下公式确定所述负载参考数据；
其中，L△t为在预期时间的负载参考数据，C△t为在所述预期时间的预估业务指标，Cb为第二业务指标数据，Cn为第一业务指标数据，Ln为第一负载数据，Lb为第二负载数据。
12.一种容量管理设备，其特征在于，包括：输入/输出(I/O)接口、处理器和存储器，所述存储器中存储有权利要求1-9任一所述的业务系统的容量管理的指令；
所述处理器用于执行存储器中存储的业务系统的容量管理的指令，执行如权利要求1-9任一所述的业务系统的容量管理方法的步骤。
13.一种业务系统，其特征在于，包括：容量管理设备和多个业务服务器，所述多个业务服务器中的每个业务服务器上都分别部署有用于信息采集的客户端，每个所述客户端周期性向所述容量管理设备上报所在业务服务器的业务指标数据和负载数据；
所述容量管理设备为上述权利要求10或11所述的容量管理装置。
14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述权利要求1-9任一所述的容量管理方法。
CN201710633168.XA 2017-07-28 2017-07-28 一种业务系统的容量管理方法、装置、设备及业务系统 Active CN110019110B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710633168.XA CN110019110B (zh) 2017-07-28 2017-07-28 一种业务系统的容量管理方法、装置、设备及业务系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710633168.XA CN110019110B (zh) 2017-07-28 2017-07-28 一种业务系统的容量管理方法、装置、设备及业务系统

Publications (2)

Publication Number Publication Date
CN110019110A true CN110019110A (zh) 2019-07-16
CN110019110B CN110019110B (zh) 2022-11-18

Family

ID=67186006

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710633168.XA Active CN110019110B (zh) 2017-07-28 2017-07-28 一种业务系统的容量管理方法、装置、设备及业务系统

Country Status (1)

Country Link
CN (1) CN110019110B (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110737593A (zh) * 2019-09-19 2020-01-31 平安科技（深圳）有限公司 智能容量管理方法、装置及存储介质
CN110913033A (zh) * 2019-11-19 2020-03-24 广东电力信息科技有限公司 基于cnn卷积神经网络学习的idcip地址分配方法
CN110932935A (zh) * 2019-11-26 2020-03-27 深圳前海微众银行股份有限公司 资源控制方法、装置、设备及计算机存储介质
CN113220749A (zh) * 2021-05-25 2021-08-06 中国农业银行股份有限公司 业务数据的处理方法、装置和电子设备
CN113297110A (zh) * 2021-05-17 2021-08-24 阿里巴巴新加坡控股有限公司 数据采集系统、方法以及装置
CN113419825A (zh) * 2021-04-01 2021-09-21 阿里巴巴新加坡控股有限公司 资源性能预估方法和装置、系统、电子设备及计算机可读存储介质
CN113489803A (zh) * 2021-07-15 2021-10-08 深圳竹云科技有限公司 负载均衡方法、终端以及网关服务器
CN113656174A (zh) * 2021-08-18 2021-11-16 河北幸福消费金融股份有限公司 资源分配方法、系统、计算机设备和存储介质
CN114787791A (zh) * 2019-11-25 2022-07-22 谷歌有限责任公司 规则违规检测

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1460966A (zh) * 2003-06-18 2003-12-10 清华大学 一种基于模糊逻辑的计算机性能指标量化方法
CN102711177A (zh) * 2012-04-26 2012-10-03 北京邮电大学 基于业务预测的负载均衡方法
CN103973759A (zh) * 2013-02-06 2014-08-06 腾讯科技（深圳）有限公司 负载调节的方法及装置
US20140289735A1 (en) * 2012-03-02 2014-09-25 Nec Corporation Capacity management support apparatus, capacity management method and program
CN104486255A (zh) * 2014-12-30 2015-04-01 杭州华三通信技术有限公司 业务资源调度方法和装置
CN105471938A (zh) * 2014-08-19 2016-04-06 腾讯科技（深圳）有限公司 服务器负载管理方法及装置
CN106549772A (zh) * 2015-09-16 2017-03-29 华为技术有限公司 资源预测方法、系统和容量管理装置
CN106557407A (zh) * 2016-11-14 2017-04-05 腾讯科技（深圳）有限公司 一种设备负载的监控方法和装置
CN106790636A (zh) * 2017-01-09 2017-05-31 上海承蓝科技股份有限公司 一种云计算服务器集群的均衡负载系统及方法
CN106874099A (zh) * 2015-12-10 2017-06-20 中国电信股份有限公司 基于业务处理能力的负载调度方法、装置及云计算系统

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1460966A (zh) * 2003-06-18 2003-12-10 清华大学 一种基于模糊逻辑的计算机性能指标量化方法
US20140289735A1 (en) * 2012-03-02 2014-09-25 Nec Corporation Capacity management support apparatus, capacity management method and program
CN102711177A (zh) * 2012-04-26 2012-10-03 北京邮电大学 基于业务预测的负载均衡方法
CN103973759A (zh) * 2013-02-06 2014-08-06 腾讯科技（深圳）有限公司 负载调节的方法及装置
CN105471938A (zh) * 2014-08-19 2016-04-06 腾讯科技（深圳）有限公司 服务器负载管理方法及装置
CN104486255A (zh) * 2014-12-30 2015-04-01 杭州华三通信技术有限公司 业务资源调度方法和装置
CN106549772A (zh) * 2015-09-16 2017-03-29 华为技术有限公司 资源预测方法、系统和容量管理装置
CN106874099A (zh) * 2015-12-10 2017-06-20 中国电信股份有限公司 基于业务处理能力的负载调度方法、装置及云计算系统
CN106557407A (zh) * 2016-11-14 2017-04-05 腾讯科技（深圳）有限公司 一种设备负载的监控方法和装置
CN106790636A (zh) * 2017-01-09 2017-05-31 上海承蓝科技股份有限公司 一种云计算服务器集群的均衡负载系统及方法

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110737593A (zh) * 2019-09-19 2020-01-31 平安科技（深圳）有限公司 智能容量管理方法、装置及存储介质
CN110737593B (zh) * 2019-09-19 2022-03-29 平安科技（深圳）有限公司 智能容量管理方法、装置及存储介质
CN110913033A (zh) * 2019-11-19 2020-03-24 广东电力信息科技有限公司 基于cnn卷积神经网络学习的idcip地址分配方法
CN114787791A (zh) * 2019-11-25 2022-07-22 谷歌有限责任公司 规则违规检测
CN110932935A (zh) * 2019-11-26 2020-03-27 深圳前海微众银行股份有限公司 资源控制方法、装置、设备及计算机存储介质
CN113419825A (zh) * 2021-04-01 2021-09-21 阿里巴巴新加坡控股有限公司 资源性能预估方法和装置、系统、电子设备及计算机可读存储介质
CN113419825B (zh) * 2021-04-01 2023-09-29 阿里巴巴新加坡控股有限公司 资源性能预估方法和装置、系统及电子设备
CN113297110A (zh) * 2021-05-17 2021-08-24 阿里巴巴新加坡控股有限公司 数据采集系统、方法以及装置
CN113220749A (zh) * 2021-05-25 2021-08-06 中国农业银行股份有限公司 业务数据的处理方法、装置和电子设备
CN113220749B (zh) * 2021-05-25 2024-02-27 中国农业银行股份有限公司 业务数据的处理方法、装置和电子设备
CN113489803A (zh) * 2021-07-15 2021-10-08 深圳竹云科技有限公司 负载均衡方法、终端以及网关服务器
CN113656174A (zh) * 2021-08-18 2021-11-16 河北幸福消费金融股份有限公司 资源分配方法、系统、计算机设备和存储介质

Also Published As

Publication number Publication date
CN110019110B (zh) 2022-11-18

Similar Documents

Publication Publication Date Title
CN110019110A (zh) 一种业务系统的容量管理方法、装置、设备及业务系统
US10489215B1 (en) Long-range distributed resource planning using workload modeling in hyperconverged computing clusters
US10333791B2 (en) Modeling computer network topology based on dynamic usage relationships
CN104854563B (zh) 资源使用的自动分析
US20060025984A1 (en) Automatic validation and calibration of transaction-based performance models
US20120011378A1 (en) Power profiling and auditing consumption systems and methods
US20030046615A1 (en) System and method for adaptive reliability balancing in distributed programming networks
CN106452933B (zh) 一种业务数据的统计方法、装置及系统
EP2515233A1 (en) Detecting and diagnosing misbehaving applications in virtualized computing systems
Bermbach et al. Towards comprehensive measurement of consistency guarantees for cloud-hosted data storage services
US10708142B2 (en) Methods, systems, and computer readable media for providing cloud visibility
US20150278066A1 (en) Cloud computing benchmarking
WO2015179575A1 (en) Load generation application and cloud computing benchmarking
US10862984B2 (en) Methods and apparatus to monitor usage of virtual computing environments
US20200371896A1 (en) Exponential decay real-time capacity planning
US9787549B2 (en) Server virtualization
US9525599B1 (en) Modeling distributed systems
CN110209467A (zh) 一种基于机器学习的弹性资源扩展方法和系统
CN112085535A (zh) 资源计量计费方法、装置、集群及存储介质
CN109905261A (zh) 故障诊断方法及装置
US20120233321A1 (en) Network structure and method of its use for tenant specific measurement of resource utilization in a multi-tenant system for the purposes of reporting, rating and access control
CN109992408A (zh) 一种资源分配方法、装置、电子设备和存储介质
US20140196035A1 (en) Management system, recording medium and method for managing virtual machines
Su et al. Understanding the latency distribution of cloud object storage systems
CN108418730A (zh) 网络流量测试方法、装置、设备以及计算机可读存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant