CN111752701A - 一种系统集群及其资源调度方法 - Google Patents

Abstract

本文公开了一种系统集群及其资源调度方法，涉及软件业务集群技术。本发明公开的系统集群的资源调度方法，包括：系统集群获取数据资源中心提供的包含存活可用主机资源列表的应用程序编程接口API信息；所述系统集群从所获取的API信息中读取存活可用主机资源列表，并对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务。本申请技术方案解决了现有技术数据中心自主的对系统集群进行资源调度时对业务主机过度依赖及容易造成故障的问题。

Description

一种系统集群及其资源调度方法

技术领域

本发明涉及软件业务集群技术，特别涉及一种响应式的系统集群的资源调度的解决方案。

背景技术

软件业务的正常运行往往需要多台系统资源形成集群来支撑，充分利用数据中心给予的资源是每一个软件业务都需要考虑的问题。当前技术所用的自动扩缩容多为数据中心监控业务主机数据(如cpu、内存等性能数据)，由数据中心自主的对软件业务集群进行扩缩容。

并且，传统的自动化扩缩容由于多依赖数据资源中心对软件业务主机的监控，通过对监控数据设置瓶颈值，达到瓶颈值后，数据资源中心主动向业务主机扩容的方式明显存在以下缺点：

1)数据资源中心需要基于软件业务集群的框架进行开发，双方需要协作沟通，人力成本大。

2)如果数据资源中心方与软件业务集群方各自具有保密性且不属于同一方，这种传统的扩缩容方式将无法解决需求。

3)当扩缩容时，数据资源中心是主动进行扩缩容，因跨平台进行干预操作，将可能更大概率对软件业务方造成故障，且故障时间过长。

发明内容

本申请提供一种系统集群及其资源调度方法，可以解决数据中心自主的对系统集群进行资源调度时对业务主机过度依赖及容易造成故障的问题。

本申请公开了一种系统集群的资源调度方法，该方法包括：

系统集群获取数据资源中心提供的包含存活可用主机资源列表的应用程序编程接口API信息；

所述系统集群从所获取的API信息中读取存活可用主机资源列表，并对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务。

可选地，上述方法中，所述存活可用主机资源列表的API信息至少包括存活可用主机列表及主机登录方式。

可选地，上述方法中，所述主机登录方式包括ssh协议登录信息，所述ssh协议登录信息至少包括如下一种或几种信息：ssh协议的远端端口，用户名、登录密码。

可选地，上述方法中，所述系统集群从对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务包括：

向存活可用主机下发系统资源统计脚本，计算存活可用主机的可用资源；

通过计算得到的存活可用主机的可用资源计算每个组件的可用资源，使用资源分配脚本基于资源统计脚本统计的可用资源修改组件分配表，按照修改后的组件分配表，确定的业务架构中各个组件与存活可用主机之间的对应关系，分配各组件的可用资源，修改各组件的配置文件。

在所有组件的配置文件修改完成后，顺序重启各组件。

可选地，上述方法中，所述系统集群获取数据资源中心提供的包含存活可用主机资源列表的API信息的方式为周期性获取所述API信息。

可选地，上述方法中，所述系统集群对组件分配表进行修改之前，还包括：

所述系统集群判断所读取的存活可用主机资源列表与最近一次获取的API信息中读取的存活可用主机资源列表是否一致，当所述系统集群判断所读取的存活可用主机资源列表与最近一次获取的API信息中读取的存活可用主机资源列表不一致时，才对组件分配表进行修改。

本文还公开了一种系统集群，包括：

获取模块，获取数据资源中心提供的包含存活可用主机资源列表的应用程序编程接口API信息；

资源调度模块，从所获取的API信息中读取存活可用主机资源列表，并对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务。

可选地，上述系统集群中，所述存活可用主机资源列表的API信息至少包括存活可用主机列表及主机登录方式。

可选地，上述系统集群中，所述主机登录方式包括ssh协议登录信息，所述ssh协议登录信息至少包括如下一种或几种信息：ssh协议的远端端口，用户名、登录密码。

可选地，上述系统集群中，所述资源调度模块，对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，包括：

向存活可用主机下发系统资源统计脚本，计算存活可用主机的可用资源；

通过计算得到的存活可用主机的可用资源计算每个组件的可用资源，使用资源分配脚本基于资源统计脚本统计的可用资源修改组件分配表，按照修改后的组件分配表，确定的业务架构中各个组件与存活可用主机之间的对应关系，分配各组件的可用资源，修改各组件的配置文件。

在所有组件的配置文件修改完成后，顺序重启各组件。

本申请技术方案提出一种响应式资源调度方案，明确了数据资源中心及系统集群的分工，数据资源中心只需提供API接口给系统集群的主机调用，就可以由系统集群自动完成资源调度任务，从而解决现有技术数据中心自主的对系统集群进行资源调度时对业务主机过度依赖及容易造成故障的问题。

附图说明

图1是本发明实施例中系统集群的资源调度流程图；

图2是本发明实施中实现资源调度的系统架构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文将结合附图对本发明技术方案作进一步详细说明。需要说明的是，在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

实施例1

本实施例提供一种系统集群的资源调度方法，主要包括：

系统集群周期性获取数据资源中心提供的包含存活可用主机资源列表的API信息；

所述系统集群根据所获取的API信息，对组件分配表进行修改，按照修改后的组件分配表进行主机资源配置操作，使用所述数据资源中心提供的存活可用主机资源运行软件业务。

其中，存活可用主机资源列表的API信息至少包括存活可用主机列表及主机登录方式。

所述系统集群根据所获取的API信息，对组件分配表进行修改，按照修改后的组件分配表进行主机资源配置操作的过程，包括：

向存活可用主机下发系统资源统计脚本，计算存活可用主机的可用资源；

通过计算得到的存活可用主机的可用资源计算每个组件的可用资源，使用资源分配脚本基于资源统计脚本统计的可用资源修改组件分配表，按照修改后的组件分配表，确定的业务架构中各个组件与存活可用主机之间的对应关系，分配各组件的可用资源，修改各组件的配置文件。

在所有组件的配置文件修改完成后，顺序重启各组件。

下面结合具体应用及附图，从解决实际业务需求的角度介绍本申请技术方案的实际实施情况。

本场景中，将软件业务集群作为一种系统集群的示例，说明此类系统集群采用本申请技术方案实现资源调度的过程。本文中涉及的软件业务集群，可以理解为软件正常运行时所基于的多个组件形成的架构以及支撑软件业务的多台主机。

考虑到，软件业务具有业务高低峰期的周期性行为，为了能抗住业务高峰期的压力且又不在业务低峰期时浪费主机资源，可以和数据中心合作对软件业务集群在业务高峰期时进行扩容及在业务低峰期时进行缩容，相当于软件业务集群实现资源动态调度。

假设，软件业务集群是A企业的软件业务集群，数据资源中心是B企业的集群，B企业不了解A企业的软件业务集群的组件架构，也未对A企业的软件业务集群在数据中心做自动化开发，则可以采用本申请方案进行软件业务集群的资源动态调度,具体操作如图1所示，包括以下步骤：

步骤100)数据资源中心B编写API(Application Programming Interface，应用程序编程接口)信息，其中，API接口逻辑中含有分配给软件业务集群A的存活可用主机资源列表；

该步骤中，A企业有为软件业务集群扩缩容的需求，但是用于扩缩容的资源是由B企业的数据资源中心管理的，因此，可以由A企业为软件业务集群提供服务而不管理资源，所以需要A企业与B企业合作。当A企业软件业务集群需要扩缩容时，A企业与B企业可以预先协商，由B企业管理的数据资源中心提前扩充资源或延后释放资源用于A企业的软件业务集群，由数据资源中心提供一个资源扩缩容后含有存活可用主机资源列表的API信息。

本实施例中涉及的API信息至少包括存活可用主机列表及主机登录方式。其中，主机登录方式可以包括ssh协议登录信息。例如，ssh协议登录信息可以包括ssh协议的远端端口，用户名及登录密码中一种或几种信息等。

另外，数据资源中心为软件业务集群分配API接口数据的方式可以是周期性的，也可以是随机性的。例如，采用周期性的分配方式时，即可以设置修改存活可用主机资源列表的API接口数据的时间间隔(例如可以设置为5分钟及以上)。

步骤200)软件业务集群A获取数据资源中心B提供的时包含存活可用主机资源列表的API(Application Programming Interface，应用程序编程接口)信息，获取存活可用主机列表及主机登录方式；

该步骤中，软件业务集群可以周期性的获取数据资源中心提供的API接口。

另外，该步骤中还可以进行比对操作，即软件业务集群可以从当前获取的API信息中读取到的存活可用主机列表与最近一次获取的API信息中读取到的存活可用主机列表进行对比，对比结果发现存活可用主机列表未发生变化，则表明分配的可用资源没有变化，无需进行任何操作，对比结果发现存活可用主机列表发生了变化，则表明分配的可用资源可能有变化，则需要重新分配集群架构的资源，即进行后续步骤300的操作。

步骤300)对软件业务集群的组件分配表进行修改，按照修改后的组件分配表进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务。

其中，组件分配表记录着存活可用主机的登录信息，该表为整个软件业务架构的各个组件分配到所有可用的主机资源提供了划分，即利用该组件分配表，可通过脚本或自动运维工具把各个组件分别安装在对应的可用主机上，并控制组件的配置文件。

在本实施例中，步骤300的操作，可以通过软件业务集群自动运维工具实现，即自动运维工具开始自动化运维整个软件业务集群，运维流程可以设置为由许多的tasks组成，task依次运行下发命令到整个集群内的主机上，由tas ks运维整个集群各组件。

具体地，上述步骤300的操作可分为如下几个步骤：

步骤300-1)运维task1，向集群内各主机分别下发系统资源统计脚本，计算存活可用主机的可用资源(即API接口对应的计算机可用资源)，如cpu,内存，磁盘容量，为集群的组件分配做参考。

步骤300-2)运维task2，通过系统资源统计脚本统计的存活可用主机的可用资源计算每个组件的可用资源，使用资源分配脚本基于资源统计脚本统计的可用资源修改组件分配表，按照修改后的组件分配表，确定的业务架构中各个组件与存活可用主机之间的对应关系，合理分配各组件可用资源，修改各组件的配置文件。

其中，本文涉及的资源分配脚本为存活可用主机中的一台主机上所保存的资源分配脚本。

步骤300-3)运维task3，等待所有组件修改项(即组件的配置文件)修改完毕，统一顺序重启组件，使修改后的各组件的配置文件生效。

步骤300-4)运维task4，检查软件业务运行是否正常。

从上述操作步骤，可以看出本申请在资源调度时可以对软件业务集群的业务架构进行重新规划，该规划操作可以结合实际软件业务利用合理的算法(即上述方法步骤中通过系统资源统计脚本统计的存活可用主机的可用资源计算每个组件的可用资源所采用的算法)对各组件消耗的资源结构进行重新规划，让系统平滑的进行资源调度。

其中，资源统计脚本开发可结合实际架构制定相应的算法，对软件业务架构进行重构，以下将以大数据分析平台为例进行说明。

大数据分析平台的基础架构为采用消息队列kafka收集数据，大数据分析器storm与深度学习引擎向kafka拉取数据进行数据分析以及数据学习，产生的结果吐给数据存储软件elasticsearch，展示数据控制台向elasticsearch拉取数据进行展示。由于kafka、elasticsearch以及数据展示平台类的数据存储样例存储了数据，不应放到组件可扩充资源的集群列表里，而是固定几台不参与资源调度的主机供数据存储组件使用。本申请中，资源调度的目标就可以设置为大数据分析器storm以及深度学习引擎，因为它们都不涉及数据存储，那么在资源调度的过程中就不涉及数据丢失，而只需在资源调度完成后，重新提交一次它们的配置即可，它们就可以做到新配置的自适应，完成资源调度操作。

基于上述思想实施的资源调度架构如图2所示。

实际资源调度的具体操作步骤可以参考如下描述。

1)样例中的软件业务集群有扩容的需求，在业务高峰期时storm,elasticsearch,kafka，深度学习引擎等会占用系统过高的cpu及内存，导致主机出问题，该软件业务集群由A公司管理。所以A公司向管理数据资源中心的B公司请求能在业务高峰期时扩容，在业务低谷期缩容，即需要B公司动态调度资源。而B公司按照传统的扩缩容解决方案进行规划，发现需要了解A公司管理的该软件业务集群架构，也需要对软件业务集群的数据进行采集，这样需要大量人力成本及沟通成本，故放弃了传统的扩缩容方式，而选用本申请的方案，可以让B公司在数据资源中心处进行主机资源释放，并提供一个包括了软件业务集群可用于扩充集群资源的列表的API给软件业务集群调用，软件业务集群可通过该接口动态获取资源，即动态地知道有哪些资源可以使用。

2)软件业务集群可以周期性(例如每1-5分钟)调用一次B公司在数据资源中心开发的API接口，对比接口中数据与软件业务集群的组件分配表中数据(即最近一次获取的API信息)是否相符(即是否一致)，如果相符(即对比结果为一致)，不做操作，如果不相符(即对比结果为不一致)，做扩缩容操作(即资源重分配操作)，重新规划业务结构，该软件业务集群会扩缩容storm-supervisor以及深度学习引擎组件的可利用主机来实现整体集群的扩缩容。

3)当软件业务集群从API接口中读到了新的列表时，会修改组件分配表，根据该组件分配表对整个集群的组件进行扩缩容(即资源重分配)，如该集群storm-supervisor及深度学习引擎。

其中，对软件业务集群的组件进行资源重分配的流程如下：

a)下发系统资源统计脚本，计算机器可用的资源，如cpu，内存，磁盘容量，为集群的组件分配做数据参考；

b)通过系统资源统计脚本的主机资源计算可以分配N台storm-supervisor和深度学习引擎，在组件分配表上的storm-supervisor和深度学习选项里添加N台主机，表示这两个组件进行扩容。这是考虑到其他的组件可能会有数据存储的情况，重新分配资源可能会导致数据丢失，因此只对这两个组件进行资源分配，对其他组件不进行资源再分配。

c)等待新添加storm-supervisor和深度学习组件的主机已经获取这两个组件的配置，统一重启需要重启的组件，使修改项在整个集群中生效。

d)检查该软件业务集群的组件运行是否正常，检查分析的业务是否平滑正常，如正常，则扩缩容(即资源重分配)成功。

实施例2

本实施例提供一种系统集群，可以实现上述实施例1的资源调度方法，该系统集群主要包括获取模块和资源调度模块。

获取模块，主要获取数据资源中心提供的包含存活可用主机资源列表的API信息；

其中，获取API信息的方式可以是周期性的或随机性的，本实施例对此不做特别限制。

资源调度模块，从所获取的API信息中读取存活可用主机资源列表，并对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务。

本实施例中，所涉及的存活可用主机资源列表的API信息至少包括存活可用主机列表及主机登录方式。

主机登录方式一般可以包括ssh协议登录信息。ssh协议登录信息至少包括如下一种或几种信息：

ssh协议的远端端口，用户名、登录密码。

实际应用中，资源调度模块修改组件分配表并对系统集群的各组件进行主机资源重新分配的过程可以参考如下操作：

向存活可用主机下发系统资源统计脚本，计算存活可用主机的可用资源；

通过计算得到的存活可用主机的可用资源计算每个组件的可用资源，使用资源分配脚本基于资源统计脚本统计的可用资源修改组件分配表，按照修改后的组件分配表，确定的业务架构中各个组件与存活可用主机之间的对应关系，分配各组件的可用资源，修改各组件的配置文件。

在所有组件的配置文件修改完成后，顺序重启各组件。由于本实施例提供的系统集群可以实现上述实施例1中所述的资源调度方法，故上述系统集群的其他具体描述可以参考上述实施例1的相应内容，在此不再赘述。

从上述实施例可以看出，本申请技术方案具有如下有优点：

(1)在资源调度过程中，数据资源中心只需提供API接口给软件业务主机调用，即数据资源中心不主动干预软件业务集群，而是释放资源，由软件业务集群自身去获取可用资源信息，从而降低数据资源中心与软件业务集群之间的依赖性。并且，可以轻松实现一个数据资源中心多个软件业务集群扩缩容的关系。

(2)对软件业务集群架构调度进行重新规划的创新，保证资源调度的精确化，并且减少扩缩容(即资源动态调度)的人力成本，保证软件业务运行的稳定性。

(3)可针对软件业务集群的具体业务的特点，制定灵活合理的算法及运维流程，让扩缩容(即资源动态调度)能够适应更多的业务场景需求，让系统更平滑的进行自动扩缩容。

本领域技术人员应明白，本发明的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质,包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质等。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

本发明是参照根据本发明实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的物品或者设备中还存在另外的相同要素。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明的意图也包含这些改动和变型在内。

Claims (10)

1.一种系统集群的资源调度方法，其特征在于，该方法包括：

系统集群获取数据资源中心提供的包含存活可用主机资源列表的应用程序编程接口API信息；

所述系统集群从所获取的API信息中读取存活可用主机资源列表，并对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务。

2.如权利要求1所述的方法，其特征在于，所述存活可用主机资源列表的API信息至少包括存活可用主机列表及主机登录方式。

3.如权利要求2所述的方法，其特征在于，所述主机登录方式包括ssh协议登录信息，所述ssh协议登录信息至少包括如下一种或几种信息：ssh协议的远端端口，用户名、登录密码。

4.如权利要求1至3任一项所述的方法，其特征在于，所述系统集群从对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务包括：

向存活可用主机下发系统资源统计脚本，计算存活可用主机的可用资源；

通过计算得到的存活可用主机的可用资源计算每个组件的可用资源，使用资源分配脚本基于资源统计脚本统计的可用资源修改组件分配表，按照修改后的组件分配表，确定的业务架构中各个组件与存活可用主机之间的对应关系，分配各组件的可用资源，修改各组件的配置文件。

在所有组件的配置文件修改完成后，顺序重启各组件。

5.如权利要求4所述的方法，其特征在于，

所述系统集群获取数据资源中心提供的包含存活可用主机资源列表的API信息的方式为周期性获取所述API信息。

6.如权利要求4所述的方法，其特征在于，所述系统集群对组件分配表进行修改之前，还包括：

所述系统集群判断所读取的存活可用主机资源列表与最近一次获取的API信息中读取的存活可用主机资源列表是否一致，在判断结果为不一致时，才对所述组件分配表进行修改。

7.一种系统集群，其特征在于，包括：

获取模块，获取数据资源中心提供的包含存活可用主机资源列表的应用程序编程接口API信息；

资源调度模块，从所获取的API信息中读取存活可用主机资源列表，并对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，使用所配置的主机资源运行所述系统集群的业务。

8.如权利要求7所述的系统集群，其特征在于，所述存活可用主机资源列表的API信息至少包括存活可用主机列表及主机登录方式。

9.如权利要求8所述的系统集群，其特征在于，所述主机登录方式包括ssh协议登录信息，所述ssh协议登录信息至少包括如下一种或几种信息：ssh协议的远端端口，用户名、登录密码。

10.如权利要求7至9任一项所述的系统集群，其特征在于，所述资源调度模块，对组件分配表进行修改，按照修改后的组件分配表对系统集群的各组件进行主机资源配置操作，包括：

向存活可用主机下发系统资源统计脚本，计算存活可用主机的可用资源；

通过计算得到的存活可用主机的可用资源计算每个组件的可用资源，使用资源分配脚本基于资源统计脚本统计的可用资源修改组件分配表，按照修改后的组件分配表，确定的业务架构中各个组件与存活可用主机之间的对应关系，分配各组件的可用资源，修改各组件的配置文件。

在所有组件的配置文件修改完成后，顺序重启各组件。

Images