CN107491335A - 一种集群控制器的升级方法及升级*** - Google Patents

Abstract

本申请公开了一种集群控制器的升级方法，包括：控制器接收到升级包；按照预设顺序利用升级包的新软件框架，对控制器的软件框架进行替换操作，得到升级状态控制器；预设数量的升级状态控制器根据升级包的新状态动态库对升级状态控制器的状态动态库进行替换操作，得到新控制器。通过在升级时分别进行升级，以使集群所有控制器在升级时仍然可以对IO业务进行处理，同时在集群***的角度看去，因为升级造成的时间间隔很小，对***的业务处理影响较小，整体的升级效率得到提高。本申请还公开了一种集群控制器的升级***，具有上述有益效果。

Description

一种集群控制器的升级方法及升级***

技术领域

本申请涉及控制器技术领域，特别涉及一种集群控制器的升级方法及升级***。

背景技术

随着存储***集群的发展，越来越多的***集群需要集群中的控制器进行管理，以及控制IO流工作，使集群***的存储效率得到了很大的提升。但是需要对控制器的软件进行升级时，由于升级过程中会造成数据的中断或者产生不可逆的错误，需要将IO流中断。因此在升级中，为了保持统一的升级计划，要先暂停集群工作，解散集群，然后逐一对集群内各个控制器进行软件升级。在所有控制器升级到相同的软件版本后，再进行对集群的重建。等到集群创建成功后，对升级前的数据进行装载，再重新启动IO流的处理。

但是，在上述的升级方法中需要将控制器集群进行解散集群，再进行升级无法发挥出集群多控制器协同工作的优势，同时在升级中必须中断一段时间的IO流，影响正常的储存工作。还由于在升级完成后，需要对集群进行重建同时要需要恢复数据，有一定的操作难度。

因此，如何在保证IO流不中断的情况下进行控制器的软件升级，是本领域技术人员专注的重点问题。

发明内容

本申请的目的是提供一种集群控制器的升级方法及升级***，通过将控制器的软件分为软件框架和状态动态库两个部分，同时升级的软件包也分为两个部分，并且两个部分的升级时长并不相同，因此在升级时可以分别进行升级，以使集群所有控制器在升级时仍然可以对IO业务进行处理，同时在集群***的角度看去，因为升级造成的时间间隔很小，对***的业务处理影响较小，整体的升级效率得到提高。

为解决上述技术问题，本申请提供一种集群控制器的升级方法，包括：

控制器接收到升级包；其中，所述控制器的数量至少为2个；

按照预设顺序利用所述升级包的新软件框架，对所述控制器的软件框架进行替换操作，得到升级状态控制器；

当预设数量的所述升级状态控制器执行替换操作结束后，所述预设数量的所述升级状态控制器根据所述升级包的新状态动态库对所述升级状态控制器的状态动态库进行替换操作，得到新控制器；

其中，将所述控制器中调度数据和使用函数的功能部分作为所述软件框架，将所述控制器中包含所述数据和所述函数的功能部分作为所述状态动态库。

可选的，所述得到所述升级状态控制器之后，还包括：

当所述升级状态控制器接收到IO业务，通过所述新软件框架和所述状态动态库对所述IO业务进行处理。

可选的，所述按照预设顺序利用所述升级包的新软件框架，对所述控制器的软件框架进行替换操作，得到升级状态控制器，包括：

所述控制器接收到所述升级包，按照所述预设顺序中断所述IO业务；

利用所述升级包的所述新软件框架对所述控制器的所述软件框架进行替换操作，得到所述升级状态控制器并恢复所述IO业务。

可选的，所述当预设数量的所述升级状态控制器执行替换操作结束后，所述预设数量的所述升级状态控制器根据所述升级包的新状态动态库对所述升级状态控制器的状态动态库进行替换操作，得到新控制器，包括：

当所述预设数量的所述升级状态控制器执行所述替换操作结束后，所述预设数量的所述升级状态控制器停止接收所述IO业务，并将当前的状态库数据进行保存；

所有所述预设数量的所述升级状态控制器根据所述升级包的所述新新状态动态库进行替换更新，得到新控制器；

将所述状态库数据拷贝到所述新控制器，并恢复接收所述IO业务。

本申请还提供一种集群控制器的升级***，包括：

升级包接收模块，用于控制器接收到升级包；其中，所述控制器的数量至少为2个；

软件框架升级模块，用于按照预设顺序利用所述升级包的新软件框架，对所述控制器的软件框架进行替换操作，得到升级状态控制器；

状态动态库升级模块，用于当预设数量的所述升级状态控制器执行替换操作结束后，所述预设数量的所述升级状态控制器根据所述升级包的新状态动态库对所述升级状态控制器的状态动态库进行替换操作，得到新控制器；

其中，将所述控制器中调度数据和使用函数的功能部分作为所述软件框架，将所述控制器中包含所述数据和所述函数的功能部分作为所述状态动态库。

可选的，还包括：

升级IO处理模块，用于当所述升级状态控制器接收到IO业务，通过所述新软件框架和所述状态动态库对所述IO业务进行处理。

可选的，所述软件框架升级模块包括：

业务中断单元，用于接收到所述升级包，按照所述预设顺序中断所述IO业务；

软件框架替换单元，利用所述升级包的所述新软件框架对所述控制器的所述软件框架进行替换操作，得到所述升级状态控制器并恢复所述IO业务。

可选的，所述状态动态库升级模块包括：

业务停止单元，用于当所述预设数量的所述升级状态控制器执行所述替换操作结束后，所述预设数量的所述升级状态控制器停止接收所述IO业务，并将当前的状态库数据进行保存；

状态库替换单元，用于根据所述升级包的所述新新状态动态库进行替换更新，得到新控制器；

业务恢复单元，用于将所述状态库数据拷贝到所述新控制器，并恢复接收所述IO业务。

本申请所提供的一种集群控制器的升级方法，包括：控制器接收到升级包；其中，所述控制器的数量至少为2个；按照预设顺序利用所述升级包的新软件框架，对所述控制器的软件框架进行替换操作，得到升级状态控制器；当预设数量的所述升级状态控制器执行替换操作结束后，所述预设数量的所述升级状态控制器根据所述升级包的新状态动态库对所述升级状态控制器的状态动态库进行替换操作，得到新控制器；其中，将所述控制器中调度数据和使用函数的功能部分作为所述软件框架，将所述控制器中包含所述数据和所述函数的功能部分作为所述状态动态库。

通过将控制器的软件分为软件框架和状态动态库两个部分，同时升级的软件包也分为两个部分，并且两个部分的升级时长并不相同，因此在升级时可以分别进行升级，以使集群所有控制器在升级时仍然可以对IO业务进行处理，同时在集群***的角度看去，因为升级造成的时间间隔很小，对***的业务处理影响较小，整体的升级效率得到提高。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的一种集群控制器的升级方法的流程图；

图2为本申请实施例提供的一种集群控制器的升级方法的软件框架升级操作的流程图；

图3为本申请实施例提供的一种集群控制器的升级方法的状态动态库升级操作的流程图；

图4为本申请实施例提供的一种集群控制器的升级方法的升级数据流向示意图；

图5为本申请实施例提供的一种集群控制器的升级方法的状态动态库切换的示意图；

图6为本申请实施例提供的一种集群控制器的升级***的结构示意图。

具体实施方式

本申请的核心是提供一种集群控制器的升级方法及升级方法，通过将控制器的软件分为软件框架和状态动态库两个部分，同时升级的软件包也分为两个部分，并且两个部分的升级时长并不相同，因此在升级时可以分别进行升级，以使集群所有控制器在升级时仍然可以对IO业务进行处理，同时在集群***的角度看去，因为升级造成的时间间隔很小，对***的业务处理影响较小，整体的升级效率得到提高。

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

请参考图1，图1为本申请实施例提供的一种集群控制器的升级方法的流程图。

本实施例提供一种集群控制器的升级方法，可以包括：

S101，控制器接收到升级包；其中，控制器的数量至少为2个；

本步骤旨在使控制器接收到升级所需要的升级包，在本实施例中升级包是通过配置节点向所有控制器发送升级包，其中，配置节点可以是特殊的配置控制器，也可以是一般的控制器，只要配置节点可以完成收发升级包的任务，在此不再做赘述。

其中，升级包是控制器可以从中获取到用于升级的数据及内容的组件的集合，可以是一般的升级包的组成方式，也可以是其他的升级包的组成方式，应视具体解决问题的环境和应用的方式选择不同的升级包的组成方式，在此不再做赘述。

当然，在配置节点接收到外界发送来的升级包时，还会存在一些其他操作，例如，对升级包进行特征码检查，安全性检查以及可用性检查，主要是确保升级包的内容对于控制器是无害可用的，此外还需要检查当前的集群环境是否符合升级的条件，确保升级可以顺利进行。因此，应视具体升级类型，升级包类型以及升级所在的环境选择如何进行检查操作，具体的在此不再做赘述。

S102，按照预设顺序利用升级包的新软件框架，对控制器的软件框架进行替换操作，得到升级状态控制器；

在步骤S101的基础上，本步骤旨在通过升级包对控制器进行部分升级得到升级状态控制器。

在升级过程中需要按照预设顺序执行升级，其中预设顺序可以是一定数量的控制器按照编号从大到小的顺序或者是按照加入网络的时间顺序执行，升级操作，应视具体的应用环境和需要解决的问题，选择不同的顺序对控制器执行升级操作。

需要说明的是，按照预设顺序依次执行的控制器，可以是多个控制器同时依次执行，也可以是单个控制器依次执行升级操作，应视集群的规模大小、处理事物的紧急性选择合适的同时执行升级操作的控制器的数量，在此不再做赘述。

其中，根据升级包是针对控制器的软件框架进行升级，也就是替换操作，即将升级包中的新软件框架与旧的软件框架进行两两替换。替换升级操作结束后得到含有新软件框架和旧状态动态库的控制器，即升级状态控制器。

在这个时刻，一个集群中可能同时运行新旧两个版本的软件，但是状态动态库为一致的，即都为旧版本的状态动态库，可以保证数据以及控制器状态的一致性。因此新旧的软件框架都可以通过旧的状态动态库完成IO业务，且业务的输出一致，因此从集群角度观察IO业务在升级过程中是正常进行的，保持了升级过程中的业务不中断。

S103，当预设数量的升级状态控制器执行替换操作结束后，预设数量的升级状态控制器根据升级包的新状态动态库对升级状态控制器的状态动态库进行替换操作，得到新控制器；

在步骤S102的基础上，本步骤旨在对升级状态控制器进行升级得到新的控制器。在本步骤中是当预设数量的升级状态控制器完成替换操作后，进行替换操作，其中预设数量可以是全部控制器也可以是一定数量的控制器，可以根据不同的集群环境选择不同数量的控制器进行替换操作，在此不作赘述。

总之，在按照顺序对软件框架进行升级替换操作时，新旧的软件框架都可以保持对状态动态库的兼容，保持了业务的不中断。当所有控制器升级为升级状态控制器之后，对预设数量的升级状态控制器进行整体的升级，后得到新控制器，由于将升级过程拆为两个部分进行升级，总体的业务中断时长减少至只对一部分升级的时长，提升了升级效率，降低了升级操作对于集群业务的影响。

结合上一实施例，本实施例主要针对上一实施例中得到升级状态控制器之后做一个拓展，其他部分大体与上一实施例大体相同，相同部分可以参考上一实施例，在此不再做赘述。

本实施例可以包括：

当升级状态控制器接收到IO业务，通过新软件框架和状态动态库对IO业务进行处理。

本实施例旨在，集群整体的升级过程中，当出现升级状态控制器之后，升级状态控制器可以通过新的软件框架与旧的状态动态库对IO业务进行处理。旧的状态动态库可以保证数据以及控制器状态的一致性，因此在处理使不会对集群整体的IO业务造成影响。

请参考图2，图2为本申请实施例提供的一种集群控制器的升级方法的软件框架升级操作的流程图。

结合上一实施例，本实施例主要针对上一实施例中如何进行软件框架升级操作做一个解释，其他部分大体与上一实施例大体相同，相同部分可以参考上一实施例，在此不再做赘述。

本实施例可以包括：

S201，控制器接收到升级包，按照预设顺序中断IO业务；

本步骤旨在使控制器接收到升级包，并按照预设顺序中断IO业务。在控制器进行升级时如果还进行IO业务的处理，会导致数据出错，集群紊乱的严重后果。因此，在对控制器升级需要先对控制器的IO业务进行中断。

需要说明的是，其中，是对单个的控制器进行IO业务的中断，对于其他的控制器来说仍然继续正常的IO业务处理，对于集群的***影响较小。

S202，利用升级包的新软件框架对控制器的软件框架进行替换操作，得到升级状态控制器并恢复IO业务。

在步骤S201的基础上，本步骤旨在，将中断IO业务的控制器进行替换操作并得到升级状态控制器。

其中，替换操作是将升级包中的新软件框架与控制器中的旧软件框架进行替换操作。一般的升级替换操作，原理也是将旧有的内容与新的内容进行替换得到升级后的功能组件。在升级过后，对升级状态控制器恢复其IO业务。

需要说明的是，新的软件框架可以兼容旧的状态动态库，并且在本实施例步骤中运行的状态动态库为一致的，可以保持数据以及控制器状态的一致性。因此，在本升级的步骤中集群***不会出现紊乱的问题。

请参考图3，图3为本申请实施例提供的一种集群控制器的升级方法的状态动态库升级操作的流程图。

结合上一实施例，本实施例主要针对上一实施例中如何进行状态动态库升级操作做一个解释，其他部分大体与上一实施例大体相同，相同部分可以参考上一实施例，在此不再做赘述。

本实施例可以包括：

S301，当预设数量的升级状态控制器执行替换操作结束后，预设数量的升级状态控制器停止接收IO业务，并将当前的状态库数据进行保存；

本步骤旨在，当预设数量的升级状态控制器完成操作后停止其接收IO业务。其中，预设数量可以是全部也可以是一部分的控制器停止业务，在本实施例中是，停止所有升级状态控制器的IO业务。为了保持集群***的稳定性，由于控制器的状态以及数据的一致性是通过状态动态库实现，因此需要保持集群***中的控制器的一致性，使集群***在稳定状态。

当停止IO业务后需要将当前的状态库的数据进行保存，为了后续可以快速启动IO业务的处理。

此时，在集群***中内所有节点都运行着新版本的软件框架，但是状态动态库还是旧版本的，集群识别的控制器仍然是旧版本的控制器，因此需要对状态动态库进行更新操作。

S302，所有预设数量的升级状态控制器根据升级包的新新状态动态库进行替换更新，得到新控制器；

在步骤S301的基础上，本步骤旨在，对停止IO业务的控制器进行状态动态库的升级替换操作，得到新的控制器。

S303，将状态库数据拷贝到新控制器，并恢复接收IO业务。

在步骤S302的基础上，本步骤旨在将状态库数据拷贝到新控制器，并恢复IO业务的处理。

请参考图4与图5，图4为本申请实施例提供的一种集群控制器的升级方法的升级数据流向示意图，图5为本申请实施例提供的一种集群控制器的升级方法的状态动态库切换的示意图。

本实施例中，通过配饰节点向其他控制器发送软件包，其升级数据在集群中流动传输。按照顺序依次停止IO操作，并使用软件包对控制器的软件框架进行替换操作，得到更新状态控制器。

当所有节点都运行了新版本的软件后，此时配置节点收到了所有节点切换到新软件版本完成的信号，标志着集群内所有节点都运行着新版本软件。

此时进行新旧SDLL(状态动态库)的切换，其步骤可以如下：

步骤一，首先配置节点向所有节点发出静默通知，

步骤二，当收到来自配置节点的静默通知后各节点将不再接收IO处理任务，处理完成现有的任务后将当前的所有数据下刷到磁盘，然后通知配置节点本节点开始实施静默，在此期间不再进行IO处理，只接受来自配置节点的指令。

步骤三，当配置节点收到所有节点开始静默的回复后，发出切换新旧SDLL的通知。

步骤四，当各个节点完成从旧的SDLL切换到新的SDLL后，均向配置节点返回一个切换完成回复。

步骤五，最后配置节点在向各个节点发出一个通知，将旧的状态信息拷贝到新的SDLL，并取消静默。

当所有节点完成这些工作后便完成了整个软件的升级过程，接下来集群便可以跟之前一样正常处理IO业务。

本申请实施例提供了一种集群控制器的升级方法，通过将控制器的软件分为软件框架和状态动态库两个部分，同时升级的软件包也分为两个部分，并且两个部分的升级时长并不相同，因此在升级时可以分别进行升级，以使集群所有控制器在升级时仍然可以对IO业务进行处理，同时在集群***的角度看去，因为升级造成的时间间隔很小，对***的业务处理影响较小，整体的升级效率得到提高。

下面对本申请实施例提供的一种集群控制器的升级***进行介绍，下文描述的一种集群控制器的升级***与上文描述的一种集群控制器的升级方法可相互对应参照。

请参考图6，图6为本申请实施例提供的一种集群控制器的升级***的结构示意图。

本实施例可以包括：

升级包接收模块100，用于控制器接收到升级包；其中，控制器的数量至少为2个；

软件框架升级模块200，用于按照预设顺序利用升级包的新软件框架，对控制器的软件框架进行替换操作，得到升级状态控制器；

状态动态库升级模块300，用于当预设数量的升级状态控制器执行替换操作结束后，预设数量的升级状态控制器根据升级包的新状态动态库对升级状态控制器的状态动态库进行替换操作，得到新控制器；

其中，将控制器中调度数据和使用函数的功能部分作为软件框架，将控制器中包含数据和函数的功能部分作为状态动态库。

可选的，还可以包括：

升级IO处理模块，用于当升级状态控制器接收到IO业务，通过新软件框架和状态动态库对IO业务进行处理。

可选的，软件框架升级模块可以包括：

业务中断单元，用于接收到升级包，按照预设顺序中断IO业务；

软件框架替换单元，利用升级包的新软件框架对控制器的软件框架进行替换操作，得到升级状态控制器并恢复IO业务。

可选的，状态动态库升级模块可以包括：

业务停止单元，用于当预设数量的升级状态控制器执行替换操作结束后，预设数量的升级状态控制器停止接收IO业务，并将当前的状态库数据进行保存；

状态库替换单元，用于根据升级包的新新状态动态库进行替换更新，得到新控制器；

业务恢复单元，用于将状态库数据拷贝到新控制器，并恢复接收IO业务。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种集群控制器的升级方法及升级***进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

Claims (8)

1.一种集群控制器的升级方法，其特征在于，包括：

控制器接收到升级包；其中，所述控制器的数量至少为2个；

按照预设顺序利用所述升级包的新软件框架，对所述控制器的软件框架进行替换操作，得到升级状态控制器；

当预设数量的所述升级状态控制器执行替换操作结束后，所述预设数量的所述升级状态控制器根据所述升级包的新状态动态库对所述升级状态控制器的状态动态库进行替换操作，得到新控制器；

其中，将所述控制器中调度数据和使用函数的功能部分作为所述软件框架，将所述控制器中包含所述数据和所述函数的功能部分作为所述状态动态库。

2.根据权利要求1所述的升级方法，其特征在于，所述得到所述升级状态控制器之后，还包括：

当所述升级状态控制器接收到IO业务，通过所述新软件框架和所述状态动态库对所述IO业务进行处理。

3.根据权利要求2所述的升级方法，其特征在于，所述按照预设顺序利用所述升级包的新软件框架，对所述控制器的软件框架进行替换操作，得到升级状态控制器，包括：

所述控制器接收到所述升级包，按照所述预设顺序中断所述IO业务；

利用所述升级包的所述新软件框架对所述控制器的所述软件框架进行替换操作，得到所述升级状态控制器并恢复所述IO业务。

4.根据权利要求3所述的升级方法，其特征在于，所述当预设数量的所述升级状态控制器执行替换操作结束后，所述预设数量的所述升级状态控制器根据所述升级包的新状态动态库对所述升级状态控制器的状态动态库进行替换操作，得到新控制器，包括：

当所述预设数量的所述升级状态控制器执行所述替换操作结束后，所述预设数量的所述升级状态控制器停止接收所述IO业务，并将当前的状态库数据进行保存；

所有所述预设数量的所述升级状态控制器根据所述升级包的所述新新状态动态库进行替换更新，得到新控制器；

将所述状态库数据拷贝到所述新控制器，并恢复接收所述IO业务。

5.一种集群控制器的升级***，其特征在于，包括：

升级包接收模块，用于控制器接收到升级包；其中，所述控制器的数量至少为2个；

软件框架升级模块，用于按照预设顺序利用所述升级包的新软件框架，对所述控制器的软件框架进行替换操作，得到升级状态控制器；

状态动态库升级模块，用于当预设数量的所述升级状态控制器执行替换操作结束后，所述预设数量的所述升级状态控制器根据所述升级包的新状态动态库对所述升级状态控制器的状态动态库进行替换操作，得到新控制器；

其中，将所述控制器中调度数据和使用函数的功能部分作为所述软件框架，将所述控制器中包含所述数据和所述函数的功能部分作为所述状态动态库。

6.根据权利要求5所述的升级***，其特征在于，还包括：

升级IO处理模块，用于当所述升级状态控制器接收到IO业务，通过所述新软件框架和所述状态动态库对所述IO业务进行处理。

7.根据权利要求6所述的升级***，其特征在于，所述软件框架升级模块包括：

业务中断单元，用于接收到所述升级包，按照所述预设顺序中断所述IO业务；

软件框架替换单元，利用所述升级包的所述新软件框架对所述控制器的所述软件框架进行替换操作，得到所述升级状态控制器并恢复所述IO业务。

8.根据权利要求7所述的升级***，其特征在于，所述状态动态库升级模块包括：

业务停止单元，用于当所述预设数量的所述升级状态控制器执行所述替换操作结束后，所述预设数量的所述升级状态控制器停止接收所述IO业务，并将当前的状态库数据进行保存；

状态库替换单元，用于根据所述升级包的所述新新状态动态库进行替换更新，得到新控制器；

业务恢复单元，用于将所述状态库数据拷贝到所述新控制器，并恢复接收所述IO业务。