CN114884901A - 一种资源调度方法和装置 - Google Patents
一种资源调度方法和装置 Download PDFInfo
- Publication number
- CN114884901A CN114884901A CN202210391277.6A CN202210391277A CN114884901A CN 114884901 A CN114884901 A CN 114884901A CN 202210391277 A CN202210391277 A CN 202210391277A CN 114884901 A CN114884901 A CN 114884901A
- Authority
- CN
- China
- Prior art keywords
- resource
- server
- service
- cpu
- memory
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000012423 maintenance Methods 0.000 claims abstract description 61
- 238000013468 resource allocation Methods 0.000 claims abstract description 29
- 238000004422 calculation algorithm Methods 0.000 claims description 18
- 238000012163 sequencing technique Methods 0.000 claims description 16
- 230000001174 ascending effect Effects 0.000 claims description 8
- 238000013528 artificial neural network Methods 0.000 claims description 7
- 238000013480 data collection Methods 0.000 claims description 6
- 230000000306 recurrent effect Effects 0.000 claims description 6
- 238000012545 processing Methods 0.000 claims description 5
- 230000008569 process Effects 0.000 description 16
- 238000012544 monitoring process Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000001502 supplementing effect Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 2
- 238000010801 machine learning Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 239000013589 supplement Substances 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000013135 deep learning Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000007637 random forest analysis Methods 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/83—Admission control; Resource allocation based on usage prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
- H04L47/781—Centralised allocation of resources
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请提供了资源调度方法和装置，方法包括：若监管报送业务为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据；根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值；基于监管报送业务的重要程度为监管报送业务分配数据库资源，基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果；根据资源分配结果，确定第一服务器集群的启停时间。本申请缩短了第一服务器集群的待机时间，减少了资源消耗。
Description
技术领域
本申请涉及计算机领域，特别是涉及一种资源调度方法和装置。
背景技术
根据我国监管部门对金融业的监管要求，银行各系统需要向各类监管机构主动报送业务数据，其中将业务数据按照要求报送给监管机构所搭建的系统称为监管报送系统。
由于统计报表种类繁多、统计规则变化频发、监管机构对报送数据质量要求不断提升等问题，金融机构通常会通过搭建统一的平台实现数据统筹、报表处理、数据报送等功能。其中，监管报送业务与常见的Web业务不同，不是7×24小时服务，而往往是将数据处理加工之后，根据监管机构下达的时间窗口，周期性进行监管数据的报送，例如，报送频率包括日报、周报、月报、季度报、年报等。
目前，在平台不进行数据报送时，监管报送业务所在的服务器集群会处于待机状态，超长的待机时间，使得资源消耗巨大。
发明内容
有鉴于此，本申请提供了一种资源调度方法和装置，用于缩短监管报送业务所需服务器集群的待机时间，减少资源消耗，其技术方案如下：
一种资源调度方法，包括：
若监管报送业务不为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据；
根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值；
基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果；
根据资源分配结果，确定第一服务器集群的启停时间。
可选的，还包括：
若监管报送业务为新建业务，则获取监管报送业务所需的服务器个数和报送窗口时长；
根据服务器个数，确定监管报送业务对应的第二服务器集群；
根据报送窗口时长，确定第二服务器集群的启停时间。
可选的，根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，包括：
确定历史运维数据的数据量；
若历史运维数据的数据量小于预设阈值，则基于支持向量回归算法和历史运维数据，对监管报送业务未来需要的CPU资源和内存资源进行预测；
若历史运维数据的数据量大于或等于预设阈值，则基于RNN循环神经网络和历史运维数据，对监管报送业务未来需要的CPU资源和内存资源进行预测。
可选的，基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，包括：
根据第一服务器集群中每个服务器的CPU总资源和CPU已消耗资源，确定第一服务器集群中每个服务器的CPU剩余资源，并根据第一服务器集群中每个服务器的内存总资源和内存已消耗资源，确定第一服务器集群中每个服务器的内存剩余资源；
根据第一服务器集群中每个服务器的CPU剩余资源和监管报送业务包含的每个报送业务对应的CPU资源预测值，从第一服务器集群中确定监管报送业务包含的每个报送业务对应的服务器，作为目标服务器；
对于每个目标服务器，若该目标服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，则将该目标服务器分配给对应的报送业务。
可选的，根据第一服务器集群中每个服务器的CPU剩余资源和监管报送业务包含的每个报送业务对应的CPU资源预测值，从第一服务器集群中确定监管报送业务包含的每个报送业务对应的服务器，包括：
从监管报送业务包含的报送业务中确定第一目标报送业务，第一目标报送业务为未确定对应服务器的报送业务中对应的CPU资源预测值最小的报送业务；
从第一服务器集群中，CPU剩余资源满足第一目标报送业务对应的CPU资源预测值的服务器中，确定第一目标报送业务对应的服务器；
根据第一目标报送业务对应的CPU资源预测值更新，对应第一目标报送业务对应的服务器的CPU剩余资源；
判断监管报送业务中是否还有未确定对应服务器的报送业务，若是，则返回执行从监管报送业务包含的报送业务中确定第一目标报送业务，直至监管报送业务包含的报送业务均已确定对应服务器。
可选的，从第一服务器集群中，CPU剩余资源满足第一目标报送业务对应的CPU资源预测值的服务器中，确定第一目标报送业务对应的服务器，包括：
将第一服务器集群按照CPU剩余资源的升序顺序进行排序，得到第一排序后的第一服务器集群；
将第一排序后的第一服务器集群中，首个CPU剩余资源满足第一目标报送业务对应的CPU资源预测值的服务器，作为第一目标报送业务对应的服务器。
可选的，还包括：
对于每个目标服务器，若该目标服务器的内存剩余资源小于该目标服务器对应的所有报送业务所对应的内存资源预测值之和，则从该目标服务器对应的所有报送业务中逐个取出报送业务，直至该服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，以得到由从各目标服务器中取出的报送业务组成的报送业务集；
根据报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，更新第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源；
在更新后，根据第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源，以及报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，为报送业务集中的报送业务分配服务器。
可选的，根据第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源，以及报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，为报送业务集中的报送业务分配服务器，包括：
从报送业务集中确定第二目标报送业务，第二目标报送业务为报送业务集中未分配服务器的报送业务中对应的内存资源预测值最小的报送业务；
从第一服务器集群中，内存剩余资源满足第二目标报送业务对应的内存资源预测值，且，CPU剩余资源满足第二目标报送业务对应的CPU资源预测值的服务器中，为第二目标报送业务分配服务器；
根据第二目标报送业务对应的内存资源预测值，对为第二目标报送业务分配的服务器的内存剩余资源进行更新；
判断报送业务集中是否还有未分配服务器的报送业务，若是，则返回执行从报送业务集中确定第二目标报送业务，直至报送业务集包含的报送业务均已分配服务器。
可选的，从第一服务器集群中，内存剩余资源满足第二目标报送业务对应的内存资源预测值，且，CPU剩余资源满足第二目标报送业务对应的CPU资源预测值的服务器中，为第二目标报送业务分配服务器，包括：
将第一服务器集群按照内存剩余资源的升序顺序进行排序，得到第二排序后的第一服务器集群；
将第二排序后的第一服务器集群中，首个CPU剩余资源满足第二目标报送业务对应的CPU资源预测值，且，内存剩余资源满足第二目标报送业务对应的内存资源预测值的服务器，作为为第二目标报送业务分配的服务器。
一种资源调度装置，包括：数据收集模块、数据预测模块、资源分配模块和启停时间确定模块；
数据收集模块，用于若监管报送业务不为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据；
数据预测模块，用于根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值；
资源分配模块，用于基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果；
启停时间确定模块，用于根据资源分配结果，确定第一服务器集群的启停时间。
经由上述的技术方案可知，本申请提供的资源调度方法，若监管报送业务为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据，然后根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值，接着基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果，最后根据资源分配结果，确定第一服务器集群的启停时间。由此可见，本申请能够确定出第一服务器集群的启停时间，使得第一服务器集群不会长期处于待机状态，缩短了第一服务器集群的待机时间，减少了资源消耗。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请实施例提供的一种资源调度方法的流程示意图；
图2为本申请实施例提供的一种资源调度装置的结构示意图；
图3为本申请实施例提供的一种资源调度设备的硬件结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请提供了一种资源调度方法，接下来通过下述实施例对本申请提供的资源调度方法进行详细介绍。
请参阅图1，示出了本申请实施例提供的资源调度方法的流程示意图，该资源调度方法可以包括：
步骤S101、若监管报送业务不为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据。
可以理解的是，对于目前已经存在的监管报送业务，已经可以通过第一服务器集群运行报送业务，并将运行时产生的业务数据上报给监管机构，基于此，本步骤可以获取到第一服务器集群在针对监管报送业务上报数据时的历史运维数据。这里，第一服务器集群是指非新建的监管报送业务所需的服务器组成的服务器集群。
例如，为了保证监管报送业务的服务质量(Quality of Service，QoS)，可以人工试运行报送业务一段时间，以获取人工试运行期间的历史运维数据。
可选的，在本步骤中，历史运维数据可以包括第一服务器集群的种类、个数、报送业务量和资源使用量。当然，历史运维数据也可以为其他，本申请对此不进行限定。
可选的，在保证服务可靠性、安全性以及业务的可持续性的基础上，本步骤可以在第一服务器集群中的每个服务器上部署运维监控工具，以通过运维监控工具对服务器进行监控，以将按照秒级或分钟级监控到的历史运维数据记录下来；可选的，还可以对运维监控工具记录的历史运维数据进行预处理，以得到本步骤中的历史运维数据。
步骤S102、根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值。
考虑到在实际的资源使用情况中，CPU资源需求量和内存资源需求量往往为非线性的时间序列数据，可以使用现代的时间序列预测算法，基于历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测。
这里，现代的时间序列预测算法涉及到机器学习、深度学习等算法，例如，该现代的时间序列预测算法可以基于循环神经网络RNN和长短期记忆LTSM神经网络进行预测，该种预测方式可以以较高算法复杂度换取预测的精度；该现代的时间序列预测算法还可以基于支持向量回归通过核函数将非线性数据映射到多维空间，以此进行预测；此外，该现代的时间序列预测算法还可以基于极端梯度提升树和随机森林等增强学习算法结合其他的机器学习算法进行预测，等等。
对于不同的场景中，训练集的量级、资源的大小，模型建立的时间要求等方面的不同，基于此，可选的，本步骤可以采用双模式预测方案对CPU资源和内存资源进行预测，其中，模式一通过支持向量回归算法(SVR)进行资源需求量预测，具备低复杂度和良好的非线性时间序列数据预测精度，模式二通过RNN循环神经网络进行资源需求量预测，具备高复杂度和较好的非线性时间序列数据预测精度。
例如，可选的，对于平稳运行的旧系统，可收集的数据集大，监管报送业务需求稳定，此时可以采用模式二进行预测，获得高精度的预测模型；而对于新建的监管报送业务系统，监管报送业务的需求不稳定，存在需求的增删，可收集处理的数据集小，此时可以选择模式一进行预测，也即，本步骤可以首先确定历史运维数据的数据量，若历史运维数据的数据量小于预设阈值，则基于支持向量回归算法和历史运维数据，对监管报送业务未来需要的CPU资源和内存资源进行预测，若历史运维数据的数据量大于或等于预设阈值，则基于RNN循环神经网络和历史运维数据，对监管报送业务未来需要的CPU资源和内存资源进行预测。
需要说明的是，监管报送业务包括至少一个报送数据，本步骤得到的监管报送业务对应的CPU资源预测值和内存资源预测值是指，监管报送业务包含的每个报送业务对应的CPU资源预测值和内存资源预测值。
另外，可选的，本步骤还可以根据历史运维数据对监管报送业务未来的报送业务量进行预测。
步骤S103、基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果。
本步骤可以为监管报送业务分配资源。可选的，监管报送业务涉及到数据处理和数据报送，基于此，本步骤为监管报送业务分配的资源可以包括数据库资源、CPU资源和内存资源。这里，考虑到监管报送业务和服务器映射关系的切换，可以以天为频率，进行数据库资源、CPU资源和内存资源的分配。
其中，数据库资源的分配方法为：根据监管报送业务的重要程度为监管报送业务分配数据库资源。这里，监管报送业务的重要程度为人为设置的值，可以以此作为权重，根据权重大小依次分配数据库资源。
CPU资源和内存资源的分配方法为：基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源。
上述数据库资源、CPU资源和内存资源均可以定义为平台共享资源，即监管报送业务包含的各报送业务共享数据库资源、CPU资源和内存资源。
可选的，本步骤还可以为监管报送业务分配网络资源，考虑到监管的业务数据的安全性，在上报时可以采用VPN、专线、金融专网来实现，那么，本申请可以在系统上线之前，和监管机构协商完成网络资源的分配，为固定分配资源，因此为独占资源。
步骤S104、根据资源分配结果，确定第一服务器集群的启停时间。
本步骤中的资源分配结果是指数据库资源、CPU资源和内存资源的分配结果，根据该分配结果，即可以确定出第一服务器集群的启停时间(即开启和关闭时间)，从而可以根据确定的启停时间，在需要对业务数据进行处理和报送时，开启第一服务器集群中的相应服务器，在不需要对业务数据进行处理和报送时，关闭第一服务器集群中的相应服务器。
本申请提供的资源调度方法，若监管报送业务为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据，然后根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值，接着基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果，最后根据资源分配结果，确定第一服务器集群的启停时间。由此可见，本申请能够确定出第一服务器集群的启停时间，使得第一服务器集群不会长期处于待机状态，缩短了第一服务器集群的待机时间，减少了资源消耗。
同时，在不对业务数据进行处理和报送时，第一服务器集群的相应服务器可以处于关机状态，节省了运维成本；并且，本申请会对监管报送业务进行资源分配，提高了资源利用率，相比于现有技术，本申请提供资源分配方案使得，对于相同数量的监管报送数据，本申请所需的服务器个数可能小于现有技术所需的服务器个数，进一步节省了运维成本；此外，本申请可以根据历史运维数据，对未来的CPU资源和内存资源需求量进行预测，从而可以提前获知异常的资源需求，做到提前发现，提前预防。
前述实施例是针对监管报送业务不为新建业务的场景下，如何确定监管报送业务所需的第一服务器集群的启停时间的方案，可以理解的是，可能存在一些新建的监管报送业务，由于无法获取新建的监管报送业务对应的历史运维数据，从而无法进行资源预测，因此无法采用前述实施例确定服务器启停时间。
为此，提出了本实施例，以通过本实施例确定新建的监管报送业务所需服务器集群的启停时间。为了与上述第一服务器集群进行区分，本实施例将新建的业务数据所需的服务器集群称为第二服务器集群，也即，第二服务器集群是指新建的监管报送业务所需的服务器组成的服务器集群。
本实施例确定第二服务器集群的启停时间的过程可以包括：若监管报送业务为新建业务，则获取监管报送业务所需的服务器个数和报送窗口时长，根据服务器个数，确定监管报送业务对应的第二服务器集群，并根据报送窗口时长，确定第二服务器集群的启停时间。
具体来说，对于新建的监管报送业务，可以由人工根据经验值确定监管报送业务所需的服务器个数和报送窗口时长，从而本实施例可以提供人工补录的接口，以通过该接口获取人工补录的服务器个数和报送窗口时长，根据该服务器个数，就可以确定出监管报送业务对应的第二服务器集群，值得注意的是，对于新建业务，由于采用了人工补录服务器个数和报送窗口的方式，为了与非新建的监管报送业务区分，可以采用独占服务器的方式进行资源分配，也即，为新建业务单独分配第二服务器集群(该第二服务器集群和第一服务器集群为不同的服务器集群，两者之间没有交集)。
当确定出第二服务器集群后，即可以根据报送窗口时长，确定出第二服务器集群的启停时间(即开启和关闭时间)。
在一可选实施例中，在本实施例的基础上，考虑到监管报送业务不为新建业务时，若监管报送业务为小样本量的报送业务，则上述步骤S101获取的历史运维数据的数据量可能很小，此时即使采用支持向量回归算法进行CPU资源和内存资源预测，可能预测值也会不准确，基于此，对于小样本量的报送业务，也可以采用本实施例提供的方法确定服务器启停时间。
综上，对于新建业务和/或小样本量的报送业务，可以采用本实施例提供的方法确定服务器启停时间。将本实施例作为前述实施例的补充，使得本申请可以覆盖任何报送业务，实用性更好。
本申请的一个实施例，对步骤S103中的“基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源”的过程进行详细介绍。
对于CPU和内存资源的分配，可以理解为二维装箱问题、NP-hard问题，本实施例设计两阶段最佳适应递减算法，进行CPU和内存资源的分配。
其中，第一阶段为根据第一服务器集群中每个服务器的CPU使用情况使用最佳适应递减算法，初步确定监管报送业务包含的每个报送业务和第一服务器集群的对应关系；在本实施例中，第一个阶段分配结束时，第一服务器集群中每个服务器可能对应一个或多个报送业务。
由于第一阶段是基于服务器的CPU资源进行分配，未考虑服务器的内存资源，那么就可能出现服务器的CPU资源满足对应报送业务的需求，而内存资源不满足对应报送业务的需求的情况，此时可以通过第二阶段对内存资源不满足的部分报送业务进行补偿分配，以使得服务器的CPU资源和内存资源同时满足对应报送业务的需求；当然，如果第一阶段分配结束时，服务器的内存资源满足对应报送业务的需求，则无需再进行第二阶段。
具体来说，“基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源”的过程至少可以包括以下步骤S1～S3：
步骤S1、根据第一服务器集群中每个服务器的CPU总资源和CPU已消耗资源，确定第一服务器集群中每个服务器的CPU剩余资源，并根据第一服务器集群中每个服务器的内存总资源和内存已消耗资源，确定第一服务器集群中每个服务器的内存剩余资源。
可选的，对于第一服务器集群中的每个服务器，可以计算该服务器的CPU总资源的80％与CPU已消耗资源的差值，将计算出的差值作为该服务器的CPU剩余资源；同理，可以计算该服务器的内存总资源的80％与内存已消耗资源的差值，将计算出的差值作为该服务器的内存剩余资源。
需要说明的是，对于CPU资源和内存资源来说，上述“80％”均为示例，除此之外，还可以为其他数据，具体可以根据实际情况确定，本申请对此不进行限定。
步骤S2、根据第一服务器集群中每个服务器的CPU剩余资源和监管报送业务包含的每个报送业务对应的CPU资源预测值，从第一服务器集群中确定监管报送业务包含的每个报送业务对应的服务器，作为目标服务器。
例如，假设监管报送业务包括报送业务1～10，若经由本步骤的确定过程使得，报送业务1～4对应服务器1，报送业务5～7对应服务器2，报送业务8对应服务器3，报送业务9和10对应服务器4，则服务器1～4均为目标服务器。
在一可选实施例中，该过程可以包括以下步骤S21～S24：
步骤S21、从监管报送业务包含的报送业务中确定第一目标报送业务，第一目标报送业务为未确定对应服务器的报送业务中对应的CPU资源预测值最小的报送业务。
步骤S21～S24用于为监管报送业务包含的每个报送业务确定对应的服务器，由于步骤S21～S24无法执行一次便为监管报送业务包含的所有报送业务均确定对应的服务器，那么需要多次执行步骤S21～S24。对于每次执行步骤S21时，均需要从监管报送业务包含的未确定对应服务器的报送业务中，选择CPU资源预测值最小(记为ymin,c)的报送业务，作为第一目标报送业务。
步骤S22、从第一服务器集群中，CPU剩余资源满足第一目标报送业务对应的CPU资源预测值的服务器中，确定第一目标报送业务对应的服务器。
应当理解，一服务器的CPU剩余资源满足第一目标报送业务对应的CPU资源预测值，即一服务器的CPU剩余资源大于或等于第一目标报送业务对应的CPU资源预测值，才可能会将第一目标报送业务分配给该服务器。基于此，在一可选实施例中，本步骤的过程可以包括：从第一服务器集群中，确定CPU剩余资源满足第一目标报送业务对应的CPU资源预测值的服务器，从确定出的服务器中选择一个服务器作为第一目标报送业务对应的服务器。例如，本步骤可以从确定出的服务器中选择CPU剩余资源最小的服务器，作为第一目标报送业务对应的服务器。
在另一可选实施例中，本步骤的过程还可以包括：将第一服务器集群按照CPU剩余资源的升序顺序进行排序，得到第一排序后的第一服务器集群；将第一排序后的第一服务器集群中，首个CPU剩余资源满足第一目标报送业务对应的CPU资源预测值ymin,c的服务器，作为第一目标报送业务对应的服务器。
步骤S23、根据第一目标报送业务对应的CPU资源预测值，更新第一目标报送业务对应的服务器的CPU剩余资源。
具体来说，本步骤可以将更新前第一目标报送业务对应的服务器的CPU剩余资源与第一目标报送业务对应的CPU资源预测值的差值，作为更新后第一目标报送业务对应的服务器的CPU剩余资源。
步骤S24、判断监管报送业务中是否还有未确定对应服务器的报送业务，若是，则返回执行从监管报送业务包含的报送业务中确定第一目标报送业务，直至监管报送业务包含的报送业务均已确定对应服务器。
步骤S3、对于每个目标服务器，若该目标服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，则将该目标服务器分配给对应的报送业务。
经由上述步骤S21～S24的确定过程，每个目标服务器对应一个或多个报送业务，例如，目标服务器1对应报送业务1～4，目标服务器2对应报送业务5～7，目标服务器3对应报送业务8，目标服务器4对应报送业务9和10。
那么，对于每个目标服务器，需要判断该目标服务器的内存剩余资源是否满足该目标服务器对应的报送业务所对应的内存资源预测值，即需要判断该目标服务器的内存剩余资源是否大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，若是，说明该目标服务器的CPU资源和内存资源均满足对应报送业务的需求，此时可以将目标服务器分配给对应的报送业务。
例如，对于上述目标服务器1，若目标服务器1的内存剩余资源大于或等于报送业务1～4对应的内存资源预测值之和，则可以将目标服务器1分配给报送业务1～4。
在一可选实施例中，在步骤S2之后，还可能包括以下步骤S4～S6：
步骤S4、对于每个目标服务器，若该目标服务器的内存剩余资源小于该目标服务器对应的所有报送业务所对应的内存资源预测值之和，则从该目标服务器对应的所有报送业务中逐个取出报送业务，直至该服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，以得到由从各目标服务器中取出的报送业务组成的报送业务集。
举例说明本步骤：假设目标服务器1对应报送业务1～4，若目标服务器1的内存剩余资源小于报送业务1～4对应的内存资源预测值之和，则取出一个报送业务，例如取出报送业务1，然后再判断目标服务器1的内存剩余资源是否大于或等于报送业务2～4对应的内存资源预测值之和，若是，则对下一个目标服务器执行该过程；若否，则再取出一个报送业务，例如取出报送业务2，然后再判断目标服务器1的内存剩余资源是否大于或等于报送业务3～4对应的内存资源预测值之和，若是，则对下一个目标服务器执行该过程；若否，则再取出一个报送业务，以此类推，直至目标服务器1的内存剩余资源大于或等于目标服务器1对应的所有报送业务所对应的内存资源预测值之和。
经由本步骤的操作，可以从各目标服务器中取出报送业务，并由从各目标服务器中取出的报送业务组成报送业务集。
可选的，本步骤在每次取出报送业务时，可以随机取出报送业务，也可以将目标服务器对应的报送业务中，CPU资源预测值最小的报送业务取出。
步骤S5、根据报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，更新第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源。
具体来说，本步骤是根据报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，更新各目标服务器的CPU剩余资源和内存剩余资源。
步骤S6、在更新后，根据第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源，以及报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，为报送业务集中的报送业务分配服务器。
可选的，本步骤可以采用改进最佳适应递减算法进行CPU资源和内存资源的分配。具体来说，本步骤可以包括以下步骤S61～S64：
步骤S61、从报送业务集中确定第二目标报送业务，第二目标报送业务为报送业务集中未分配服务器的报送业务中对应的内存资源预测值最小的报送业务。
步骤S61～S64用于为报送业务集包含的每个报送业务分配服务器，由于步骤S61～S64无法执行一次便为报送业务集包含的所有报送业务均分配服务器，那么需要多次执行步骤S61～S64。对于每次执行步骤S61时，均需要从报送业务集包含的未分配服务器的报送业务中，选择内存资源预测值最小(记为ymin,m)的报送业务，作为第二目标报送业务。
步骤S62、从第一服务器集群中，内存剩余资源满足第二目标报送业务对应的内存资源预测值，且，CPU剩余资源满足第二目标报送业务对应的CPU资源预测值的服务器中，为第二目标报送业务分配服务器。
应当理解，一服务器的CPU剩余资源满足第二目标报送业务对应的CPU资源预测值，且，内存剩余资源满足第二目标报送业务对应的内存资源预测值，即一服务器的CPU剩余资源大于或等于第二目标报送业务对应的CPU资源预测值，且，内存剩余资源大于或等于第二目标报送业务对应的内存资源预测值，才可以将第二目标报送业务分配给该服务器。基于此，在一可选实施例中，本步骤的过程可以包括：从第一服务器集群中，确定内存剩余资源满足第二目标报送业务对应的内存资源预测值，且，CPU剩余资源满足第二目标报送业务对应的CPU资源预测值的服务器，从确定出的服务器中选择一个服务器作为第二目标报送业务对应的服务器。例如，本步骤可以从确定出的服务器中选择内存剩余资源最小或者CPU剩余资源最小的服务器，作为第二目标报送业务对应的服务器。
在另一可选实施例中，本步骤的过程还可以包括：将第一服务器集群按照内存剩余资源的升序顺序进行排序，得到第二排序后的第一服务器集群；将第二排序后的第一服务器集群中，首个CPU剩余资源满足第二目标报送业务对应的CPU资源预测值，且，内存剩余资源满足第二目标报送业务对应的内存资源预测值ymin,m的服务器，作为为第二目标报送业务分配的服务器。
步骤S63、根据第二目标报送业务对应的内存资源预测值，对为第二目标报送业务分配的服务器的内存剩余资源进行更新。
步骤S64、判断报送业务集中是否还有未分配服务器的报送业务，若是，则返回执行从报送业务集中确定第二目标报送业务，直至报送业务集包含的报送业务均已分配服务器。
与此同时，对于每个目标服务器，本实施例还会将该目标服务器对应的报送业务中未取出的报送业务分配给该目标服务器，由此完成整个分配过程。
本申请实施例还提供了一种资源调度装置，下面对本申请实施例提供的资源调度装置进行描述，下文描述的资源调度装置与上文描述的资源调度方法可相互对应参照。
请参阅图2，示出了本申请实施例提供的资源调度装置的结构示意图，如图2所示，该资源调度装置可以包括：数据收集模块201、数据预测模块202、资源分配模块203和启停时间确定模块204。
数据收集模块201，用于若监管报送业务不为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据。
数据预测模块202，用于根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值。
资源分配模块203，用于基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果。
启停时间确定模块204，用于根据资源分配结果，确定第一服务器集群的启停时间。
本申请提供的资源调度装置，若监管报送业务为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据，然后根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值，接着基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果，最后根据资源分配结果，确定第一服务器集群的启停时间。本申请能够确定出第一服务器集群的启停时间，使得第一服务器集群不会长期处于待机状态，缩短了第一服务器集群的待机时间，减少了资源消耗。
在一种可能的实现方式中，本申请提供的资源调度装置还可以包括：人工需求资源补录模块。
该人工需求资源补录模块，具体可以用于若监管报送业务为新建业务，则获取监管报送业务所需的服务器个数和报送窗口时长，根据服务器个数，确定监管报送业务对应的第二服务器集群，根据报送窗口时长，确定第二服务器集群的启停时间。
在一种可能的实现方式中，数据预测模块202具体可以用于确定历史运维数据的数据量，若历史运维数据的数据量小于预设阈值，则基于支持向量回归算法和历史运维数据，对监管报送业务未来需要的CPU资源和内存资源进行预测，若历史运维数据的数据量大于或等于预设阈值，则基于RNN循环神经网络和历史运维数据，对监管报送业务未来需要的CPU资源和内存资源进行预测。
在一种可能的实现方式中，上述资源分配模块203在基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源时，可以包括：剩余资源确定模块、目标服务器确定模块和第一分配模块。
其中，剩余资源确定模块，用于根据第一服务器集群中每个服务器的CPU总资源和CPU已消耗资源，确定第一服务器集群中每个服务器的CPU剩余资源，并根据第一服务器集群中每个服务器的内存总资源和内存已消耗资源，确定第一服务器集群中每个服务器的内存剩余资源。
目标服务器确定模块，用于根据第一服务器集群中每个服务器的CPU剩余资源和监管报送业务包含的每个报送业务对应的CPU资源预测值，从第一服务器集群中确定监管报送业务包含的每个报送业务对应的服务器，作为目标服务器。
第一分配模块，用于对于每个目标服务器，若该目标服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，则将该目标服务器分配给对应的报送业务。
在一种可能的实现方式中，上述目标服务器确定模块可以包括：第一目标报送业务确定模块、服务器对应模块、第一更新模块和第一判断模块；
其中，第一目标报送业务确定模块，用于从监管报送业务包含的报送业务中确定第一目标报送业务，第一目标报送业务为未确定对应服务器的报送业务中对应的CPU资源预测值最小的报送业务。
服务器对应模块，用于从第一服务器集群中，CPU剩余资源满足第一目标报送业务对应的CPU资源预测值的服务器中，确定第一目标报送业务对应的服务器。
第一更新模块，用于根据第一目标报送业务对应的CPU资源预测值更新，对应第一目标报送业务对应的服务器的CPU剩余资源；
第一判断模块，用于判断监管报送业务中是否还有未确定对应服务器的报送业务，若是，则返回执行第一目标报送业务确定模块，直至监管报送业务包含的报送业务均已确定对应服务器。
在一种可能的实现方式中，上述服务器对应模块可以包括：第一排序模块和CPU剩余资源参考模块。
其中，第一排序模块，用于将第一服务器集群按照CPU剩余资源的升序顺序进行排序，得到第一排序后的第一服务器集群；
CPU剩余资源参考模块，用于将第一排序后的第一服务器集群中，首个CPU剩余资源满足第一目标报送业务对应的CPU资源预测值的服务器，作为第一目标报送业务对应的服务器。
在一种可能的实现方式中，本申请提供的资源调度装置还可以包括：报送业务集确定模块、第二更新模块和第二分配模块。
其中，报送业务集确定模块，用于对于每个目标服务器，若该目标服务器的内存剩余资源小于该目标服务器对应的所有报送业务所对应的内存资源预测值之和，则从该目标服务器对应的所有报送业务中逐个取出报送业务，直至该服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，以得到由从各目标服务器中取出的报送业务组成的报送业务集。
第二更新模块，用于根据报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，更新第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源。
第二分配模块，用于在更新后，根据第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源，以及报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，为报送业务集中的报送业务分配服务器。
在一种可能的实现方式中，上述第二分配模块可以包括：第二目标报送业务确定模块、服务器分配模块、第三更新模块和第二判断模块。
其中，第二目标报送业务确定模块，用于从报送业务集中确定第二目标报送业务，第二目标报送业务为报送业务集中未分配服务器的报送业务中对应的内存资源预测值最小的报送业务。
服务器分配模块，用于从第一服务器集群中，内存剩余资源满足第二目标报送业务对应的内存资源预测值，且，CPU剩余资源满足第二目标报送业务对应的CPU资源预测值的服务器中，为第二目标报送业务分配服务器。
第三更新模块，用于根据第二目标报送业务对应的内存资源预测值，对为第二目标报送业务分配的服务器的内存剩余资源进行更新。
第二判断模块，用于判断报送业务集中是否还有未分配服务器的报送业务，若是，则返回执行从报送业务集中确定第二目标报送业务，直至报送业务集包含的报送业务均已分配服务器。
在一种可能的实现方式中，服务器分配模块可以包括：第二排序模块和内存剩余资源参考模块。
其中第二排序模块，用于将第一服务器集群按照内存剩余资源的升序顺序进行排序，得到第二排序后的第一服务器集群。
内存剩余资源参考模块，用于将第二排序后的第一服务器集群中，首个CPU剩余资源满足第二目标报送业务对应的CPU资源预测值，且，内存剩余资源满足第二目标报送业务对应的内存资源预测值的服务器，作为为第二目标报送业务分配的服务器。
本申请实施例还提供了一种资源调度设备。可选的，图3示出了资源调度设备的硬件结构框图，参照图3，该资源调度设备的硬件结构可以包括：至少一个处理器301，至少一个通信接口302，至少一个存储器303和至少一个通信总线304；
在本申请实施例中，处理器301、通信接口302、存储器303、通信总线304的数量为至少一个，且处理器301、通信接口302、存储器303通过通信总线304完成相互间的通信；
处理器301可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路等；
存储器303可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)等，例如至少一个磁盘存储器；
其中，存储器303存储有程序，处理器301可调用存储器303存储的程序，所述程序用于：
若监管报送业务不为新建业务，则获取第一服务器集群在针对监管报送业务上报数据时的历史运维数据；
根据历史运维数据对监管报送业务未来需要的CPU资源和内存资源进行预测，得到监管报送业务对应的CPU资源预测值和内存资源预测值；
基于监管报送业务的重要程度为监管报送业务分配数据库资源，并基于监管报送业务对应的CPU资源预测值和内存资源预测值以及第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为监管报送业务分配CPU资源和内存资源，得到资源分配结果；
根据资源分配结果，确定第一服务器集群的启停时间。
可选的，所述程序的细化功能和扩展功能可参照上文描述。
本申请实施例还提供一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上述资源调度方法。
可选的，所述程序的细化功能和扩展功能可参照上文描述。
最后，还需要说明的是，在本文中，诸如和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种资源调度方法，其特征在于，包括：
若监管报送业务不为新建业务，则获取第一服务器集群在针对所述监管报送业务上报数据时的历史运维数据；
根据所述历史运维数据对所述监管报送业务未来需要的CPU资源和内存资源进行预测，得到所述监管报送业务对应的CPU资源预测值和内存资源预测值；
基于所述监管报送业务的重要程度为所述监管报送业务分配数据库资源，并基于所述监管报送业务对应的CPU资源预测值和内存资源预测值以及所述第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为所述监管报送业务分配CPU资源和内存资源，得到资源分配结果；
根据所述资源分配结果，确定所述第一服务器集群的启停时间。
2.根据权利要求1所述的资源调度方法，其特征在于，还包括：
若所述监管报送业务为所述新建业务，则获取所述监管报送业务所需的服务器个数和报送窗口时长；
根据所述服务器个数，确定所述监管报送业务对应的第二服务器集群；
根据所述报送窗口时长，确定所述第二服务器集群的启停时间。
3.根据权利要求1所述的资源调度方法，其特征在于，所述根据所述历史运维数据对所述监管报送业务未来需要的CPU资源和内存资源进行预测，包括：
确定所述历史运维数据的数据量；
若所述历史运维数据的数据量小于预设阈值，则基于支持向量回归算法和所述历史运维数据，对所述监管报送业务未来需要的CPU资源和内存资源进行预测；
若所述历史运维数据的数据量大于或等于所述预设阈值，则基于RNN循环神经网络和所述历史运维数据，对所述监管报送业务未来需要的CPU资源和内存资源进行预测。
4.根据权利要求1所述的资源调度方法，其特征在于，所述基于所述监管报送业务对应的CPU资源预测值和内存资源预测值以及所述第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为所述监管报送业务分配CPU资源和内存资源，包括：
根据所述第一服务器集群中每个服务器的CPU总资源和CPU已消耗资源，确定所述第一服务器集群中每个服务器的CPU剩余资源，并根据所述第一服务器集群中每个服务器的内存总资源和内存已消耗资源，确定所述第一服务器集群中每个服务器的内存剩余资源；
根据所述第一服务器集群中每个服务器的CPU剩余资源和所述监管报送业务包含的每个报送业务对应的CPU资源预测值，从所述第一服务器集群中确定所述监管报送业务包含的每个报送业务对应的服务器，作为目标服务器；
对于每个目标服务器，若该目标服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，则将该目标服务器分配给对应的报送业务。
5.根据权利要求4所述的资源调度方法，其特征在于，所述根据所述第一服务器集群中每个服务器的CPU剩余资源和所述监管报送业务包含的每个报送业务对应的CPU资源预测值，从所述第一服务器集群中确定所述监管报送业务包含的每个报送业务对应的服务器，包括：
从所述监管报送业务包含的报送业务中确定第一目标报送业务，所述第一目标报送业务为未确定对应服务器的报送业务中对应的CPU资源预测值最小的报送业务；
从所述第一服务器集群中，CPU剩余资源满足所述第一目标报送业务对应的CPU资源预测值的服务器中，确定所述第一目标报送业务对应的服务器；
根据所述第一目标报送业务对应的CPU资源预测值，更新对应所述第一目标报送业务对应的服务器的CPU剩余资源；
判断所述监管报送业务中是否还有未确定对应服务器的报送业务，若是，则返回执行所述从监管报送业务包含的报送业务中确定第一目标报送业务，直至所述监管报送业务包含的报送业务均已确定对应服务器。
6.根据权利要求5所述的资源调度方法，其特征在于，所述从所述第一服务器集群中，CPU剩余资源满足所述第一目标报送业务对应的CPU资源预测值的服务器中，确定所述第一目标报送业务对应的服务器，包括：
将所述第一服务器集群按照CPU剩余资源的升序顺序进行排序，得到第一排序后的第一服务器集群；
将所述第一排序后的第一服务器集群中，首个CPU剩余资源满足所述第一目标报送业务对应的CPU资源预测值的服务器，作为所述第一目标报送业务对应的服务器。
7.根据权利要求4所述的资源调度方法，其特征在于，还包括：
对于每个目标服务器，若该目标服务器的内存剩余资源小于该目标服务器对应的所有报送业务所对应的内存资源预测值之和，则从该目标服务器对应的所有报送业务中逐个取出报送业务，直至该服务器的内存剩余资源大于或等于该服务器对应的所有报送业务所对应的内存资源预测值之和，以得到由从各目标服务器中取出的报送业务组成的报送业务集；
根据所述报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，更新所述第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源；
在更新后，根据所述第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源，以及所述报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，为所述报送业务集中的报送业务分配服务器。
8.根据权利要求7所述的资源调度方法，其特征在于，所述根据所述第一服务器集群中每个服务器的CPU剩余资源和内存剩余资源，以及所述报送业务集中报送业务对应的CPU资源预测值和内存资源预测值，为所述报送业务集中的报送业务分配服务器，包括：
从所述报送业务集中确定第二目标报送业务，所述第二目标报送业务为所述报送业务集中未分配服务器的报送业务中对应的内存资源预测值最小的报送业务；
从所述第一服务器集群中，内存剩余资源满足所述第二目标报送业务对应的内存资源预测值，且，CPU剩余资源满足所述第二目标报送业务对应的CPU资源预测值的服务器中，为所述第二目标报送业务分配服务器；
根据第二目标报送业务对应的内存资源预测值，对为第二目标报送业务分配的服务器的内存剩余资源进行更新；
判断所述报送业务集中是否还有未分配服务器的报送业务，若是，则返回执行所述从所述报送业务集中确定第二目标报送业务，直至所述报送业务集包含的报送业务均已分配服务器。
9.根据权利要求7所述的资源调度方法，其特征在于，所述从所述第一服务器集群中，内存剩余资源满足所述第二目标报送业务对应的内存资源预测值，且，CPU剩余资源满足所述第二目标报送业务对应的CPU资源预测值的服务器中，为所述第二目标报送业务分配服务器，包括：
将所述第一服务器集群按照内存剩余资源的升序顺序进行排序，得到第二排序后的第一服务器集群；
将所述第二排序后的第一服务器集群中，首个CPU剩余资源满足所述第二目标报送业务对应的CPU资源预测值，且，内存剩余资源满足所述第二目标报送业务对应的内存资源预测值的服务器，作为为所述第二目标报送业务分配的服务器。
10.一种资源调度装置，其特征在于，包括：数据收集模块、数据预测模块、资源分配模块和启停时间确定模块；
所述数据收集模块，用于若监管报送业务不为新建业务，则获取第一服务器集群在针对所述监管报送业务上报数据时的历史运维数据；
所述数据预测模块，用于根据所述历史运维数据对所述监管报送业务未来需要的CPU资源和内存资源进行预测，得到所述监管报送业务对应的CPU资源预测值和内存资源预测值；
所述资源分配模块，用于基于所述监管报送业务的重要程度为所述监管报送业务分配数据库资源，并基于所述监管报送业务对应的CPU资源预测值和内存资源预测值以及所述第一服务器集群中每个服务器的CPU总资源、CPU已消耗资源、内存总资源和内存已消耗资源，为所述监管报送业务分配CPU资源和内存资源，得到资源分配结果；
所述启停时间确定模块，用于根据所述资源分配结果，确定所述第一服务器集群的启停时间。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210391277.6A CN114884901A (zh) | 2022-04-14 | 2022-04-14 | 一种资源调度方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210391277.6A CN114884901A (zh) | 2022-04-14 | 2022-04-14 | 一种资源调度方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114884901A true CN114884901A (zh) | 2022-08-09 |
Family
ID=82669394
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210391277.6A Pending CN114884901A (zh) | 2022-04-14 | 2022-04-14 | 一种资源调度方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114884901A (zh) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108566424A (zh) * | 2018-04-11 | 2018-09-21 | 深圳市腾讯网络信息技术有限公司 | 基于服务器资源消耗预测的调度方法、装置和系统 |
| CN111142647A (zh) * | 2019-12-27 | 2020-05-12 | 亚信科技（南京）有限公司 | 一种it系统的节能方法及系统 |
| CN113282395A (zh) * | 2021-06-09 | 2021-08-20 | 中国农业银行股份有限公司 | 基于Redis的作业请求调度方法、装置、设备及介质 |
-
2022
- 2022-04-14 CN CN202210391277.6A patent/CN114884901A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108566424A (zh) * | 2018-04-11 | 2018-09-21 | 深圳市腾讯网络信息技术有限公司 | 基于服务器资源消耗预测的调度方法、装置和系统 |
| CN111142647A (zh) * | 2019-12-27 | 2020-05-12 | 亚信科技（南京）有限公司 | 一种it系统的节能方法及系统 |
| CN113282395A (zh) * | 2021-06-09 | 2021-08-20 | 中国农业银行股份有限公司 | 基于Redis的作业请求调度方法、装置、设备及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10942781B2 (en) | Automated capacity provisioning method using historical performance data | |
| US10789102B2 (en) | Resource provisioning in computing systems | |
| CN110297711A (zh) | 批量数据处理方法、装置、计算机设备及存储介质 | |
| US7552152B2 (en) | Risk-modulated proactive data migration for maximizing utility in storage systems | |
| US6125105A (en) | Method and apparatus for forecasting future values of a time series | |
| CN102037681A (zh) | 对于管理系统的计算资源进行管理的方法和装置 | |
| US11726836B2 (en) | Predicting expansion failures and defragmenting cluster resources | |
| CN107145975A (zh) | 光传输设备备件数量的预测方法 | |
| US20190163528A1 (en) | Automated capacity management in distributed computing systems | |
| CN109460301B (zh) | 一种流数据负载的弹性资源配置方法及系统 | |
| CN111752706A (zh) | 资源配置方法、装置及存储介质 | |
| US11310125B2 (en) | AI-enabled adaptive TCA thresholding for SLA assurance | |
| CN115297112A (zh) | 一种基于Kubernetes的动态资源配额及调度组件 | |
| CN105022823B (zh) | 一种基于数据挖掘的云服务性能预警事件生成方法 | |
| CN115658311A (zh) | 一种资源的调度方法、装置、设备和介质 | |
| CN110196773B (zh) | 统一调度计算资源的多时间尺度安全校核系统及方法 | |
| CN111105050B (zh) | 风机维护计划的生成方法、装置、设备及存储介质 | |
| CN114884901A (zh) | 一种资源调度方法和装置 | |
| CN114844791B (zh) | 基于大数据的云服务自动管理分配方法、系统及存储介质 | |
| CN114978913B (zh) | 一种基于切链的服务功能链跨域部署方法及系统 | |
| Martinez-Julia et al. | Explained intelligent management decisions in virtual networks and network slices | |
| CN112783637A (zh) | 一种资源调控方法和装置 | |
| CN113988769B (zh) | 一种智能匹配分布式资源的方法、装置和计算机设备 | |
| DE202022104275U1 (de) | System für intelligentes Ressourcenmanagement für verteilte Maschinenlernaufgaben | |
| CN111738582B (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 |