CN116866180A - 集群升级的测试方法及系统 - Google Patents

Abstract

本申请提出了一种集群升级的测试方法及系统，该种集群升级的测试方法包括：根据集群升级需求，设置集群升级方式，升级方式包括迭代升级或一对一升级；根据升级方式来执行集群升级测试操作，获取测试升级版本；对测试升级后的集群的功能和/或配置进行检查。通过本申请的集群升级测试方法使得不用再使用手工的方式来人为的盯着或手工操作执行升级操作，并且在升级执行完成后检查集群的一些状态进行基础的功能和配置的验证，能够更好的保证升级后的集群功能的正确性和可靠性，节省集群升级的时间。

Description

集群升级的测试方法及系统

技术领域

本发明涉及集群软件升级技术领域，尤其涉及一种集群升级的测试方法及系统。

背景技术

当今分布式系统中集群的升级是很常见的功能，集群维护需要进行升级，对大型集群进行升级是分布式系统必须要实现的功能。升级的验证会通过模拟人工操作来执行升级并判断升级成功即可。升级方式单一且升级后不会执行太多的验证。

发明内容

为了解决现有技术中集群升级方式比较单一且人为的盯着或手工操作执行升级操作，同时对集群升级后的功能的正确性和可靠性验证比较缺乏的情况下，本申请提出了一种集群升级的测试方法：

在本申请的第一方面提供了一种集群升级的测试方法，所述测试方法包括：

根据集群升级需求，设置集群升级方式，所述升级方式包括迭代升级或一对一升级；

根据所述升级方式来执行集群升级测试操作，获取测试升级版本；

对测试升级后的集群的功能和/或配置进行检查。

于上述第一方面的一种可能实现方式中，根据集群升级需求，设置所述升级方式包括：

在所述升级方式为一对一升级的情况下，获取待升级版本列表中的版本值，

根据所述版本值的数量创建若干集群或者若干嵌套集群执行集群升级测试操作。

于上述第一方面的一种可能实现方式中，设置所述升级方式包括：

在所述升级方式迭代升级的情况下，根据输入的升级路径依次执行集群升级测试操作。

于上述第一方面的一种可能实现方式中，根据所述升级方式来执行集群升级测试操作包括：

在嵌套环境不符合升级测试的情况下，创建嵌套集群；

将ISO映像配置文件和json文件上传至嵌套集群中的升级控制节点的指定目录下；

创建并配置用于挂载ISO映像配置文件的ISO文件夹为Yum源；

配置Yum源为smartxos.repo文件；

通过执行Yum安装指令，更新对应的rpm包，执行升级脚本。

于上述第一方面的一种可能实现方式中，根据所述升级方式来执行集群升级测试操作包括：

若待测试升级版本的集群已存在，输入所述待测试升级版本的集群IP；

根据升级路径中输入的所述集群IP对应的版本号依次执行升级测试。

于上述第一方面的一种可能实现方式中，根据所述升级方式来执行集群升级测试操作包括：

在集群存在不同的节点数的情况下，判断待测试升级版本的集群的节点个数是否相同；

若待测试升级版本的集群的节点个数不相同；根据所述节点个数创建对应若干个嵌套集群，并根据升级路径来调用升级脚本对所述嵌套集群执行升级测试。

于上述第一方面的一种可能实现方式中，将集群升级后的所述升级版本进行测试还包括：

在按照预设升级次数完成升级测试的情况下，根据输入参数来执行升级测试的若干循环测试。

于上述第一方面的一种可能实现方式中，对升级后的集群的功能和/或配置进行检查包括：

对升级后的集群状态、集群服务、集群安装的rpm包是否符合预期进行验证；

和/或，

对集群节点的cgroup服务是否符合预期进行验证；

和/或，

对集群节点的预留内存和大页是否符合预期进行验证。

本申请的第二方面提供了一种集群升级的测试系统，应用于如前述第一方面所述的集群升级的测试方法中，测试系统包括：

升级方式设置单元，用于根据集群升级需求，设置集群升级方式，所述升级方式包括迭代升级或一对一升级；

测试单元，用于根据所述升级方式来执行集群升级测试操作，获取测试升级版本；验证单元，用于对测试升级后的集群的功能和/或配置进行检查

本发明至少具备以下有益技术效果：

不用再使用手工的方式来人为的盯着或手工操作执行升级操作。并且在升级执行完成后检查集群的一些状态进行基础的功能和配置的验证，能够更好的保证升级后的集群功能的正确性和可靠性，节省集群升级的时间。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1根据本申请的实施例，示出了一种集群升级的测试方法的流程示意图；

图2根据本申请的实施例，示出了一种集群升级的测试系统框图。

具体实施方式

本发明的核心是提供一种集群升级的测试方法及系统，避免使用手工的方式来人为的盯着或手工操作执行升级操作。并且在升级执行完成后检查集群的一些状态进行基础的功能和配置的验证，能够更好的保证升级后的集群功能的正确性和可靠性，能够节省很多时间。

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供了一种集群升级的测试方法，集群内同一节点内的代理模块和控制模块在每次升级完毕后具有对应的版本号；参见图1所示，图1为本发明提供的集群升级过程中的测试方法过程的流程图；该方法包括：

步骤100：根据集群升级需求，设置集群升级方式，所述升级方式包括迭代升级或一对一升级。可以理解的是，集群的升级通过采用jenkins执行在K8S部署集群项目，采用包括集群升级需求的若干输入参数可以实现根据传入的参数来执行不同的功能，调用脚本比较灵活、并且执行脚本会比较有效率。

于本申请的一些实施例中，Jenkins的执行需要输入的主要参数包括升级方式、升级路径、升级迭代的版本、最终升级到的版本、升级可以需要开启vHost、升级时需要创建的新的集群、集群节点数、缓存盘个数、执行升级次数等，本领域技术人员也可以根据实际需求对输入参数进行设定，在此不做限定。

于本申请的一些实施例中，Jenkins的执行输入的相关参数也可以以在jenkins中安装插件的形式实现，该插件包括了包括升级方式、升级路径、升级迭代的版本、最终升级到的版本、升级可以需要开启vHost、升级时需要创建的新的集群、集群节点数、缓存盘个数、执行升级次数等的功能插件，通过该插件生成docker镜像,并推送到docker仓库中，以最终实现集群的升级。

步骤200：根据所述升级方式来执行集群升级测试操作，获取测试升级版本。可以理解的是，对于集群升级测试的操作需要根据预设的集群升级方式，采用对应的enkins方式执行升级集群的升级脚本，该种集群升级测试可以包括：根据版本列表，可以测试需要执行的升级路径，通过输入不通的版本列表，可以测试不同版本、不同升级路径下的升级功能是否正常；升级可以分为UI升级和cli升级两种方式，通过输入不同的参数，升级脚本会调用不通的接口来进行升级，可以测试不同的升级方式功能是否正常；以及在部署集群的时候可以选择开启vHost(boot)功能，也可以选择不开启vHost功能，可以测试这两种情况下升级功能是否正常；可以控制新建嵌套集群节点个数，可以测试不通节点数的集群升级功能是否正常等，在此不做限定。

步骤300：对测试升级后的集群的功能和/或配置进行检查。可以理解的是，需要传入目标版本；传入要升级的版本的列表数，即初始版本及迭代的中间版本；选择升级的方式：迭代升级、一对一的升级；传入升级后检查节点安装的rpm包的值，用于升级后做比较。

于上述步骤根据集群升级需求，设置升级方式包括：

在升级方式为一对一升级的情况下，获取待升级版本列表中的版本值，

根据版本值的数量创建若干集群或者若干嵌套集群执行集群升级测试操作。

具体地，根据输入的版本列表，从低版本依次迭代升级到最终版本，升级版本成功后执行升级后的检查和验证测试。根据输入的版本列表，例如：4.0.10；4.0.13；5.0.5，集群升级顺序是，先升级集群到4.0.10，成功升级4.0.10后再升级版本到4.0.13；升级4.0.13成功后再把集群升级到5.0.5版本

根据集群升级需求，设置升级方式包括：在升级方式迭代升级的情况下，根据输入的升级路径依次执行集群升级测试操作。可以理解的是，根据输入的版本列表，把版本列表中的每个值都执行升级测试到最终版本，版本列表中有多少个值，需要新建多少个集群升级到最终版本，升级成功后执行升级后的检查和验证测试，这样执行一个jenkins任务就可以验证多个版本的升级测试。

于本申请的一些实施例中，根据所述升级方式来执行集群升级测试操作包括：

若待测试升级版本的集群已存在，输入所述待测试升级版本的集群IP；

根据升级路径中输入的所述集群IP对应的版本号依次执行升级测试。

于本申请的一些实施例中，根据所述升级方式来执行集群升级测试操作包括：

在集群存在不同的节点数的情况下，判断待测试升级版本的集群的节点个数是否相同；

若待测试升级版本的集群的节点个数不相同；根据所述节点个数创建对应若干个嵌套集群，并根据升级路径来调用升级脚本对所述嵌套集群执行升级测试。

于本申请的一些实施例中，迭代升级版本列表，脚本可以根据升级路径来进行依次升级操作，脚本根据输入的升级路径依次进行版本升级，例如：4.0.10；4.0.13；5.0.5，集群升级顺序是，先升级集群到4.0.10，成功升级4.0.10后再升级版本到4.0.13；升级4.0.13成功后再把集群升级到5.0.5版本。

于本申请的一些实施例中，在部署新集群的时候可以选择开启vHost功能，创建嵌套集群，在部署集群时，可以勾选是否开启vHost(boot)功能，开启vHost功能后，集群中的内存是通过大页的方式来被使用。

于本申请的一些实施例中，根据所述升级方式来执行集群升级测试操作包括：

在嵌套环境不符合升级测试的情况下，创建嵌套集群；将ISO映像配置文件和json文件上传至嵌套集群中的升级控制节点的指定目录下；创建并配置用于挂载ISO映像配置文件的ISO文件夹为Yum源；配置Yum源为smartxos.repo文件；通过执行Yum安装指令，更新对应的rpm包包，执行升级脚本。ISO

可以理解的是，集群升级的步骤可以包括：上传ISO映像配置文件和json文件到升级控制节点包括在新建的嵌套集群，选择一个节点作为升级控制节点，脚本会在ftp服务器找到对应的ISO和json文件把ISO和json文件下载到升级控制节点的/home/smartx/目录下；之后挂载映像配置文件，并配置Yum源为smartxos.repo；

创建/mnt/ISO目录，mkdir/mnt/ISO；

挂载映像配置文件到/mnt/ISO目录：mount-o loop new_ISO_file_name.ISO

/mnt/ISO

创建/etc/Yum.repos.d/bk目录：mkdir/etc/Yum.repos.d/bk

将/etc/Yum.repos.d/目录下所有repo文件移动到/etc/Yum.repos.d/bk/目录下：

mv/etc/Yum.repos.d/*.repo/etc/Yum.repos.d/bk/

向/etc/Yum.repos.d/smartxos.repo文件写入：

[smartxos-local-ISO]name＝smartxos

baseurl＝file:///mnt/ISO,gpgcheck＝0,enabled＝1

安装对应的smartx-upgrade rpm包包执行命令：Yuminstall smartx-upgrade；

进入到/usr/share/upgrade/runner/目录下，执行以下脚本：

nohup python cluster_upgrader.py--ISO_path<ISO path>--metadata_path<metadata path>&。

可以理解的是，Yum源的包括Base类为光盘镜像里面的ISO映像配置文件，挂载至系统上的后包括存储rpm包的packages目录，配置Yum源为通过寻找镜像站点，根据选择的系统，选择对应的目录进入，目录下包括Packages和repodata，Packages目录是Yum安装时的rpm包，repodata目录里面包含了以.xml结尾的文件,这个文件是Yum索引文件,包含了rpm包的一些信息,比如依赖关系这些的信息。

具体地，对于存放目录的repo文件，创建一个新的repo文件，可以把记录下来的地址放进去，使得执行Yum时通过读取Yum.repo.d下这个目录下的所有以.repo结尾的文件。

于本申请的一些实施例中，根据所述升级方式来执行集群升级测试操作包括：若待测试升级版本的集群已存在，输入所述待测试升级版本的集群IP；根据升级路径中输入的所述集群IP对应的版本号依次执行升级测试。可以理解的是，若需要测试升级，并且现在没有可用且符合初始版本的嵌套环境，可以通过先创建一个嵌套集群，然后在这个嵌套集群上做升级验证。通过在参数server_ip中填写：need_create，脚本获取到这个参数后会先创建一个嵌套集群，新建集群的版本和版本列表中的第一个版本号一致。因为server_ip的值为need_creat，脚本会拿到版本列表的第一个值，根据版本列表的值寻找ftp服务器地址查找版本查找对应的ISO用来创建新的集群。

于本申请的一些实施例中，根据所述升级方式来执行集群升级测试操作包括：在集群存在不同的节点数的情况下，判断待测试升级版本的集群的节点个数是否相同；若待待测试升级版本的集群的节点个数不相同；根据所述节点个数创建对应若干个嵌套集群，并根据升级路径来调用升级脚本对所述嵌套集群执行升级测试。

于本申请的一些实施例中，如果想要验证升级的版本的集群已经存在，可以直接在参数server_ip中输入要升级的集群IP地址，脚本会根据升级路径中输入的集群的版本号依次来对集群进行升级。升级版本测试是按照升级文档的说明步骤来执行的，根据版本列表中给出的版本号依次进行升级。例如版本列表：4.0.13；5.0.5，会先在已有集群升级4.0，13版本，升级成功后再升级5.0.5版本。脚本根据版本号4.0.13可以在公司的ftp服务器上找到4.0.13对应的ISO和json文件，把对应的ISO和json文件下载到已经存在的集群中，调用升级脚本，可以执行升级版本测试，升级至4.0.13成功后，再继续调用升级脚本继续升级5.0.5版本。

于本申请的一些的实施例中，可以输入选择创建几个几节点的集群来进行升级测试，对于集群存在不同的节点数，集群的master和storage节点个数可能会不一致，如果需要验证不同节点个数的集群的升级测试，可以根据需要输入要新建嵌套集群的节点个数，在创建嵌套集群的时候会根据填写的集群节点个数来创建对应节点个数的集群，并根据升级路径来调用升级脚本来对这个集群做升级操作。

于本申请的一些实施例中，将集群升级后的所述升级版本进行测试还包括：在按照预设升级次数完成升级测试的情况下，根据输入参数来执行升级测试的若干循环测试。

可以理解的是，升级执行次数：输入升级执行次数之后，可以根据输入来执行升级的循环次数，多次执行升级可以验证升级的稳定性。如果需要验证升级的稳定性，要多次执行一个升级路径验证集群升级可以成功，可以设置升级执行的次数。例如升级执行的次数设置：设置为2次，会根据版本列表新建一个嵌套集群并根据版本列表进行版本升级，升级执行完成后会再次新建一个嵌套集群，并根据版本列表进行版本升级。

于本申请的一些实施例中，对升级后的集群的功能和/或配置进行检查包括：对升级后的集群状态、集群服务、集群安装的rpm包是否符合预期进行验证；和/或，对集群节点的cgroup服务是否符合预期进行验证；和/或，对集群节点的预留内存和大页是否符合预期等状态进行验证。

于本申请的一些实施例中，版本升级成功后执行验证集群状态、集群服务、集群安装的rpm包是否符合预期、集群节点的cgroup服务是否符合预期、集群节点的预留内存和大页是否符合预期等功能的脚本。来检查升级后集群的功能和配置。

集群服务状态的检查具体包括：通过结果获取要检查的服务和状态可以通过接口http://节点IP/api/v2/services获取节点服务信息，running_state:服务运行状态，正常为active；service_state：服务状态，正常为enabled

{

"data":[

{

"current_pid":12872,

"exec_path":"/usr/bin/job-center",

"last_pid":12872,

"running_state":"active",

"service_name":"job-center-scheduler.service",

"service_state":"enabled",

"state_duration":101843.319651

},

......

}

根据集群现有的rpm包在节点进行检查并和升级的json文件中的rpm包版本进行比对包括：在节点查看使用的rpm包然后和json文件中的对比是否一致。例如在节点查看mongod服务的rpm包，返回mongodb-server-5.0.13-3.smartx.x86_64在json中查看rpm包是否有一致的，可以通过以下命令实现rpm包的验证：

$rpm-qa|grepmongod

mongodb-server-5.0.13-3.smartx.x86_64

根据节点特性(是否开启vHost、RDMA等)判断节点预留内存和大页是否符合预期，如果集群节点/etc/zbs/.boostenabled文件中的值为true，即开启vHost功能，集群内存会以大页的形式来给虚拟机使用并且会留一部分普通内存预留给系统服务；大页内存可以通过cat/proc/meminfo|grepHugePages_Total查看节点可以分配给虚拟机使用的大页内存总数，通过cat/etc/zbs/os_memory_used查看节点预留内存值，集群总内存＝大页内存+节点预留内存。

如果集群节点/etc/zbs/rdma_enabled文件中的值为true，开启RDMA功能，集群会留3GiB大页给系统预留，通过cat/etc/zbs/os_normal_memory_used查看节点预留普通内存值符合预期，cat/etc/zbs/os_memory_used查看到的值为系统预留内存＝节点预留普通内存+3GiB大页内存。

具体地，判断节点服务的cgroup是否符合预期，登录节点,通过servicecgconfigstatus查看cgroup机制已经启动，挂载点为/cgroup目录，通过脚本检查服务的cgroup的配置是否符合预期，使用systemctlstatusxxx命令可以确认服务的cgroup配置是否符合预期，以及对应的线程是否运行在对应的cgroup上等来验证cgroup服务。

于本申请的一些实施例中，升级后集群的处理包括：在集群升级参数选择时，参数选择时可以选择执行成功后是否删除集群具体包括：如果选择的话升级任务执行成功，集群会被直接删除，如果执行失败，集群不会被删除，会被保留用于后续问题的定位；若不选择删除集群的选项，执行成功后集群不会被删除。

于本申请的一些实施例中，脚本执行完成后会把升级结果通过邮件方式或slack的方式发送给至前端页面，以便获取升级测试结果。

在本申请的一些实施例中，图2示出了一种集群升级的测试系统框图，应用于前述实施例所提供的集群升级的测试方法中，该种集群升级的测试系统具体可以包括：

升级方式设置单元001，用于根据集群升级需求，设置集群升级方式，所述升级方式包括迭代升级或一对一升级；

测试单元002，用于根据所述升级方式来执行集群升级测试操作，获取测试升级版本；

验证单元003，用于对测试升级后的集群的功能和/或配置进行检查。

可以理解的是，上述集群升级的测试系统各个功能模块执行与前述集群升级的测试方法相同的步骤流程，在此不做赘述。

在本申请的一些实施例中，还提供了一种电子设备。该种电子设备中包含存储器和处理器，其中存储器用于对处理程序进行存储，处理器则根据指令对处理程序进行执行。当处理器对处理程序进行执行时，使得前述实施例中的集群升级的测试方法得以实现。

本申请提出的技术方案涉及方法、装置、系统、电子设备、计算机可读存储介质和/或计算机程序产品。计算机程序产品可以包括用于执行本公开的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (9)

1.一种集群升级的测试方法，其特征在于，所述测试方法包括：

根据集群升级需求，设置集群升级方式，所述升级方式包括迭代升级或一对一升级；

根据所述升级方式来执行集群升级测试操作，获取测试升级版本；

对测试升级后的集群的功能和/或配置进行检查。

2.根据权利要求1所述的一种集群升级的测试方法，其特征在于，根据集群升级需求，设置所述升级方式包括：

在所述升级方式为一对一升级的情况下，获取待升级版本列表中的版本值，

根据所述版本值的数量创建若干集群或者若干嵌套集群执行集群升级测试操作。

3.根据权利要求1所述的一种集群升级的测试方法，其特征在于，根据集群升级需求，设置所述升级方式包括：

在所述升级方式迭代升级的情况下，根据输入的升级路径依次执行集群升级测试操作。

4.根据权利要求2或3所述的一种集群升级的测试方法，其特征在于，根据所述升级方式来执行集群升级测试操作包括：

在嵌套环境不符合升级测试的情况下，创建嵌套集群；

将ISO映像配置文件和json文件上传至所述嵌套集群中的升级控制节点的指定目录下；

创建并配置用于挂载所述ISO映像配置文件的ISO文件夹为Yum源；

配置所述Yum源为smartxos.repo文件；

通过执行Yum安装指令，更新对应的rpm包，执行升级脚本。

5.根据权利要求1所述的一种集群升级的测试方法，其特征在于，根据所述升级方式来执行集群升级测试操作包括：

若待测试升级版本的集群已存在，输入所述待测试升级版本的集群IP；

根据升级路径中输入的所述集群IP对应的版本号依次执行升级测试。

6.根据权利要求1所述的一种集群升级的测试方法，其特征在于，根据所述升级方式来执行集群升级测试操作包括：

在集群存在不同的节点数的情况下，判断待测试升级版本的集群的节点个数是否相同；

若待测试升级版本的集群的节点个数不相同；根据所述节点个数创建对应若干个嵌套集群，并根据升级路径来调用升级脚本对所述嵌套集群执行升级测试。

7.根据权利要求1所述的一种集群升级的测试方法，其特征在于，将集群升级后的所述升级版本进行测试还包括：

在按照预设升级次数完成升级测试的情况下，根据输入参数来执行升级测试的若干循环测试。

8.根据权利要求1所述的一种集群升级的测试方法，其特征在于，对升级后的集群的功能和/或配置进行检查包括：

对升级后的集群状态、集群服务、集群安装的rpm包是否符合预期进行验证；

和/或，

对集群节点的cgroup服务是否符合预期进行验证；

和/或，

对集群节点的预留内存和大页是否符合预期进行验证。

9.据权利要求1所述的一种集群升级的测试系统，应用于如权利要求1-8任一所述的集群升级的测试方法中，其特征在于，所述测试系统包括：

升级方式设置单元，用于根据集群升级需求，设置集群升级方式，所述升级方式包括迭代升级或一对一升级；

测试单元，用于根据所述升级方式来执行集群升级测试操作，获取测试升级版本；

验证单元，用于对测试升级后的集群的功能和/或配置进行检查。