CN107589955B - 一种双cmc固件版本的升级方法及系统 - Google Patents

Abstract

本申请公开了一种双CMC固件版本的升级方法，包括：判断双CMC是否满足固件版本升级条件；其中，所述双CMC具体包括完全相同的第一CMC和第二CMC，且所述第一CMC为主CMC、所述第二CMC为备CMC；若是，则按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级。该升级方法应用于双CMC存储设备，能够始终保持有一个CMC承担该存储设备的管理工作，使得该存储设备正常工作，消除对存储服务的影响，提升客户体验。本申请还同时公开了一种双CMC固件版本的升级系统，具有上述有益效果。

Description

一种双CMC固件版本的升级方法及系统

技术领域

本申请涉及机箱管理控制器技术领域，特别涉及一种双CMC固件版本的升级方法及系统。

背景技术

随着数据存储领域的蓬勃发展，在保证数据存储的同时对网络通信和网络管理也越来越关注，一台存储设备是否更加利于网络管理也成为了评价一个存储设备性能的标志之一。

为使存储设备更加方便的同时保证其拥有高可用性，采用了双CMC(CanisterManagement Controller，机箱管理控制器)，遵循工作时一主一从的思想，主CMC承担所有的工作，从CMC作用备用控制器当主CMC发生故障的时接替主CMC的工作。而发生故障的主CMC进行重启试图恢复故障，并在重启完成后变成从CMC，进而保证一直是双CMC来共同管理存储设备。

而每个CMC通过安装于其上的固件控制着CMC的动作和行为，以及应对各种发给CMC的IPMI(Intelligent Platform Management Interface，智能平台管理接口)命令，且固件也跟操作系统一样会存在漏洞以及问题，同时也随着新的需求的到来，需要改变CMC的行为，这时就需要对CMC通过固件版本升级的方式更改原固件信息或增加新固件信息，以满足新的需求以及解决已存在的Bug。

由于CMC承接的是用户网络管理的功能，无法简单的复制单CMC存储设备的固件版本升级方式，因为两个CMC同时升级会使得两个CMC同时不工作，用户可以明显感知到这一过程，首先会严重影响存储服务的进程，同时也会降低用户体验。

所以，如何提供一种应用于双CMC存储设备的CMC固件版本升级机制是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种双CMC固件版本的升级方法及系统，其应用于双CMC存储设备，能够始终保持有一个CMC承担该存储设备的管理工作，使得该存储设备正常工作，消除对存储服务的影响，提升客户体验。

为解决上述技术问题，本申请提供一种双CMC固件版本的升级方法，该升级方法包括：

判断双CMC是否满足固件版本升级条件；其中，所述双CMC具体包括完全相同的第一CMC和第二CMC，且所述第一CMC为主CMC、所述第二CMC为备CMC；

若是，则按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级。

可选的，判断双CMC是否满足固件版本升级条件，包括：

获取所述第一CMC和所述第二CMC的固件版本信息，得到两个CMC各自的固件版本号；

根据最新固件版本号判断两个所述固件版本号各自对应的CMC是否需要进行固件更新。

可选的，若是，则按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级，包括：

若所述第一CMC和所述第二CMC均需要进行固件更新，则按所述预设升级规则先使用Node1对所述第一CMC进行固件更新，再使用Node2对所述第二CMC进行固件更新。

可选的，按所述预设升级规则先使用Node1对所述第一CMC进行固件更新，再使用Node2对所述第二CMC进行固件更新，包括：

判断所述第一CMC或所述第二CMC上是否存在升级中标识；

若所述第一CMC和所述第二CMC均不存在所述升级中标识，

则利用Node1对所述第一CMC执行固件信息升级操作，并得到所述第一CMC返回的第一升级完成信号；

根据所述第一升级完成信号利用Node2对所述第二CMC执行所述固件信息升级操作，并得到所述第二CMC返回的第二升级完成信号；

根据所述第二升级完成信息确定所述第一CMC和所述第二CMC均处于固件版本升级完毕状态。

可选的，利用Node1对所述第一CMC执行固件信息升级操作，包括：

利用IPMI命令获取所述第一CMC的IP地址；

将处于主CMC状态的第一CMC执行主备切换操作，得到处于备CMC状态的第一CMC；

通过所述IP地址对处于所述备CMC状态的第一CMC发送所述最新固件版本号对应的固件信息；

处于所述备CMC状态的第一CMC利用所述固件信息执行替换操作。

可选的，得到所述第一CMC返回的第一升级完成信号，包括；

判断所述替换操作是否执行完毕；

若是，则将处于所述备CMC状态的第一CMC执行主备切换逆操作，得到处于所述主CMC状态的第一CMC；

处于所述主CMC状态的第一CMC向所述Node1返回所述第一升级完成信号。

可选的，该升级方法还包括：

当所述第一CMC和所述第二CMC均完成固件版本升级时，通过预设路径发送均升级完毕的通知信号。

本申请还提供了一种双CMC固件版本的升级系统，该升级系统包括：

升级条件判断单元，用于判断双CMC是否满足固件版本升级条件；其中，所述双CMC具体包括完全相同的第一CMC和第二CMC，且所述第一CMC为主CMC，所述第二CMC为备CMC；

CMC固件升级单元，用于按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级。

可选的，所述升级条件判断单元包括：

固件版本号获取子单元，用于获取所述第一CMC和所述第二CMC的固件版本信息，得到两个CMC各自的固件版本号；

版本号判断子单元，用于根据最新固件版本号判断两个所述固件版本号各自对应的CMC是否需要进行固件更新。

可选的，所述CMC固件升级单元包括：

优选更新子单元，用于按所述预设升级规则先使用Node1对所述第一CMC进行固件更新，再使用Node2对所述第二CMC进行固件更新。

本申请所提供的一种双CMC固件版本的升级方法，通过判断双CMC是否满足固件版本升级条件；其中，所述双CMC具体包括完全相同的第一CMC和第二CMC，且所述第一CMC为主CMC、所述第二CMC为备CMC；若是，则按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级。

显然，本申请所提供的技术方案，根据满足的固件版本升级条件，按预设升级规则分别使用不同的Node对不同的CMC进行固件版本升级，使得两个CMC不同时进行固件版本升级。该升级方法能够始终保持有一个CMC承担该存储设备的管理工作，使得该存储设备正常工作，消除对存储服务的影响，提升客户体验。本申请同时还提供了一种双CMC固件版本的升级系统，具有上述有益效果，在此不再赘述。

附图说明

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

图1为本申请实施例所提供的一种双CMC固件版本的升级方法的流程图；

图2为本申请实施例所提供的另一种双CMC固件版本的升级方法的流程图；

图3为本申请实施例所提供的又一种双CMC固件版本的升级方法的流程图；

图4为本申请实施例所提供的再一种双CMC固件版本的升级方法的流程图；

图5为本申请实施例所提供的一种双CMC固件版本的升级系统的结构框图。

具体实施方式

本申请的核心是提供一种双CMC固件版本的升级方法及系统，其应用于双CMC存储设备，能够始终保持有一个CMC承担该存储设备的管理工作，使得该存储设备正常工作，消除对存储服务的影响，提升客户体验。

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

以下结合图1，图1为本申请实施例所提供的一种双CMC固件版本的升级方法的流程图。

其具体包括以下步骤：

S101：判断双CMC是否满足固件版本升级条件；

本步骤旨在判断双CMC是否满足固件版本升级条件。其中，针对双CMC能够满足的固件版本升级条件表现形式存在以下几种：其一，两个CMC各自的固件版本均不是最新的，即均需要进行固件版本升级；其二，两个CMC中的一个CMC的固件版本已经是最新的，即只有另一个CMC单独需要进行固件版本升级；其三，两个CMC各自的固件版本均已经是最新的，即第三种情况不满足固件版本升级条件。

在实际情况中，一般两个CMC为保持良好的主备机制，通常情况下两个CMC会保持相同的固件版本，也就是说上面提及的情况二其实与情况三相同，均不满足固件版本升级条件，即本步骤就是判断在双CMC控制的存储设备当中的两个CMC是否同时满足固件版本升级条件，只存在两个同时满足和两个不同时满足两种情况下的判别。

当然，如何判断双CMC是否同时满足固件版本升级条件的方式有很多，例如，通过能够在CMC上读取到的固件版本号与最新版本号做对比；也可以采用特征比对的方式做判断或者其它方式等等，此处并不对具体如何判断做限定，只需能够依据信息判断出目的即可，可以根据实际情况结合实现难度、运算性能、是否需要加密等各影响因素或特殊要求灵活地做出选择。

S102：按预设升级规则使用相应Node对满足固件版本升级条件的CMC进行固件版本升级。

在S101的基础上，本步骤旨在按预设升级规则使用相应的Node(节点)对满足固件版本升级条件的CMC进行固件版本升级。

其中，双CMC的设置方式为一主一从或一主一备，即相同时间只有主CMC承担该存储设备的管理控制工作，而备CMC则闲置待机以在该主CMC出现故障无法很好的承担起管理控制工作时与该主CMC进行主备关系的切换，且由于主备关系的切换需要先将该主CMC所承担的工作都释放掉，先进行由主CMC到备CMC状态的切换，使得原CMC变为新备CMC，再对原备CMC进行主备关系逆切换，使得原备CMC变为新主CMC。这一过程无法同步进行，即只能通过异步进行，故一定存在一个先后切换的流程。

所以为了加快切换速度，使用两个Node各自负责一个CMC的切换工作，并负责接下来的固件版本升级工作，这样可以尽可能的减少仅由一个Node完成情况下的耗时以及加快工作效率，各司其职也能降低模块间的耦合性。

其中，该预设升级规则在结合上面的说明的情况下，可以得到在S101判断的结果为双CMC均需要进行固件版本更新的情况下，一定会有一个固件版本升级的先后顺序。且升级的一个基本原则就是尽量不能中断CMC对存储设备的管理控制、不能为用户存储服务造成影响，也正是在这个原则的指导下，可以得到先在第一CMC进行升级时，一定要使其处于备CMC状态，即若该第一CMC为主CMC时，要进行主备切换操作，并必须待第二CMC切换至新主CMC时完全解体了原主CMC的工作的情况下，才是用Node1对第一CMC进行固件版本升级操作。

第二CMC的升级以此类推，只不过使用的是Node2而已，但需要注意的是，对第二CMC的升级也一定需要保持在该第一CMC升级完毕的情况下再进行。

至于如何判断第一CMC是否切换完毕、升级完毕以及第二CMC相关状态的确认方式有很多，例如，在完成相关操作后由执行主体发送一个状态确认信号，以便于进行状态的确认；或者在执行完毕的最后一步激活一个警示信息以作为状态显示信号等等，此处并不对如何进行状态的确认做具体限定，可以根据实际情况结合存储设备型号、CMC型号、周边配套元器件等等综合考虑并做出选择。

进一步的，在双CMC均完成了固件版本升级操作后，还可以通过预设路径发送均升级完毕的通知信号，更进一步的，还可以记录每次升级开始和结束的时间，以备后用。

基于上述技术方案，本申请实施例提供的一种双CMC固件版本的升级方法，根据满足的固件版本升级条件，按预设升级规则分别使用不同的Node对不同的CMC进行固件版本升级，使得两个CMC不同时进行固件版本升级。该升级方法能够始终保持有一个CMC承担该存储设备的管理工作，使得该存储设备正常工作，消除对存储服务的影响，提升客户体验。

以下结合图2，图2为本申请实施例所提供的另一种双CMC固件版本的升级方法的流程图。

其具体包括以下步骤：

S201：获取第一CMC和第二CMC的固件版本信息，得到两个CMC各自的固件版本号；

S202：根据最新固件版本号判断两个固件版本号各自对应的CMC是否需要进行固件更新；

S201和S202通过获取第一CMC和第二CMC的固件版本信息，得到两个CMC各自的固件版本号，并利用获取到的各自的固件版本号与最新固件版本号做比对，就能够很容易的判断出是否需要进行固件版本的升级。

进一步的，还可以结合固件版本号的更改规则判断出现有固件版本与最新固件版本相差几个版本，并根据设定的升级方式决定是逐个版本依次升级还是可以直接升级到最新的固件版本，此处并不做具体限定，可以根据固件版本的升级方式、是否允许跨版本升级以及其它特殊要求等综合选择。

S203：按预设升级规则先使用Node1对第一CMC进行固件更新，再使用Node2对第二CMC进行固件更新。

本步骤建立在S202的判断结果为两个CMC均需要进行固件版本升级的基础上，旨在按照预设的升级方式先使用Node1对第一CMC进行固件更新，并在完成对第一CMC的固件更新完成后，再使用Node2对第二CMC进行固件更新。详细的解释内容可以参见S102中的相关部分，与本步骤大体相同，在此不再赘述。

以下结合图3，图3为本申请实施例所提供的又一种双CMC固件版本的升级方法的流程图。

本实施例是针对上一实施例中S203可能具体如何进行所做出的一个具体限定，其它步骤与上一实施例大体相同，相同部分可参见上一实施例相关部分，在此不再赘述。

其具体包括以下步骤：

S301：判断第一CMC或第二CMC上是否存在升级中标识；

本步骤旨在判断第一CMC或第二CMC上是否存在升级中标识，即其它实施例中所提及的升级或更新过程，因为固件版本的更新是需要消耗一定的时间的，而在未完成升级时查询到的固件版本号会依旧为之前的固件版本号，只有在彻底完成升级后才会更改版本号，以免升级一般时出现异常导致明明为完成更新却在版本号上显示了最新的版本信息，导致CMC无法正常工作。

S302：利用Node1对第一CMC执行固件信息升级操作，并得到第一CMC返回的第一升级完成信号；

S303：根据第一升级完成信号利用Node2对第二CMC执行固件信息升级操作，并得到第二CMC返回的第二升级完成信号；

S302和S303旨在分别利用各CMC对应的Node依次完成固件版本升级，并在第一CMC升级完成后得到由第一CMC返回的第一升级完成信号，以此信号作为开启第二CMC的固件版本升级的开始信号。

S304：根据第二升级完成信息确定第一CMC和第二CMC均处于固件版本升级完毕状态。

在S303的基础上，本步骤旨在根据收到的第二升级完成信息判定第一CMC和第二CMC均完成了固件版本升级，处于升级完毕状态。

以下结合图4，图4为本申请实施例所提供的再一种双CMC固件版本的升级方法的流程图。

本实施例是针对上一实施例中S302如何利用Node1对第一CMC执行固件进行升级操作，并得到第一升级完成信号所做出的一个具体限定，其它步骤与上一实施例大体相同，相同部分可参见上一实施例相关部分，在此不再赘述。

其具体包括以下步骤：

S401：利用IPMI命令获取第一CMC的IP地址；

本步骤旨在利用IPMI命令使得Node1获取到第一CMC的IP地址。

S402：将处于主CMC状态的第一CMC执行主备切换操作，得到处于备CMC状态的第一CMC；

在S401的基础上，本步骤旨在将处于主CMC状态的第一CMC执行主备切换操作，以得到切换操作完成后的处于备CMC状态的第一CMC。

S403：通过IP地址对处于备CMC状态的第一CMC发送最新固件版本号对应的固件信息；

S404：处于备CMC状态的第一CMC利用固件信息执行替换操作；

在S402的基础上，本步骤旨在通过该IP地址将获取到的最新固件版本发送至该第一CMC，并直接执行固件信息替换操作，即先删除该第一CMC上原有的固件信息，在安装最新固件版本。

S405：判断替换操作是否执行完毕；

S406：将处于备CMC状态的第一CMC执行主备切换逆操作，得到处于主CMC状态的第一CMC；

S407：处于主CMC状态的第一CMC向Node1返回第一升级完成信号。

S406和S407建立在判断替换操作执行完毕的基础上，旨在将处于备CMC状态的第一CMC执行主备切换逆操作，使得该第一CMC重新回归至主CMC状态，其实等同于由处于主CMC状态的第一CMC执行主备切换操作，将自身置于备CMC状态。

基基于上述技术方案，本申请实施例提供的一种双CMC固件版本的升级方法，根据满足的固件版本升级条件，按预设升级规则分别使用不同的Node对不同的CMC进行固件版本升级，使得两个CMC不同时进行固件版本升级。该升级方法能够始终保持有一个CMC承担该存储设备的管理工作，使得该存储设备正常工作，消除对存储服务的影响，提升客户体验。

因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到更具本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。

下面请参见图5，图5为本申请实施例所提供的一种双CMC固件版本的升级系统的结构框图。

该升级系统可以包括：

升级条件判断单元100，用于判断双CMC是否满足固件版本升级条件；其中，双CMC具体包括完全相同的第一CMC和第二CMC，且第一CMC为主CMC，第二CMC为备CMC；

CMC固件升级单元200，用于按预设升级规则使用相应Node对满足固件版本升级条件的CMC进行固件版本升级。

其中，升级条件判断单元100包括：

固件版本号获取子单元，用于获取第一CMC和第二CMC的固件版本信息，得到两个CMC各自的固件版本号；

版本号判断子单元，用于根据最新固件版本号判断两个固件版本号各自对应的CMC是否需要进行固件更新；

其中，CMC固件升级单元200包括：

优选更新子单元，用于按预设升级规则先使用Node1对第一CMC进行固件更新，再使用Node2对第二CMC进行固件更新。

其中，优选更新子单元包括：

标识判断模块，用于判断第一CMC或第二CMC上是否存在升级中标识；

第一升级模块，用于利用Node1对第一CMC执行固件信息升级操作，并得到第一CMC返回的第一升级完成信号；

第二升级模块，没用于根据第一升级完成信号利用Node2对第二CMC执行固件信息升级操作，并得到第二CMC返回的第二升级完成信号；

升级状态判定模块，用于根据第二升级完成信息确定第一CMC和第二CMC均处于固件版本升级完毕状态。

其中，第一升级模块包括：

IP地址获取子模块，用于利用IPMI命令获取第一CMC的IP地址；

主备切换子模块，用于将处于主CMC状态的第一CMC执行主备切换操作，得到处于备CMC状态的第一CMC；

最新固件信息发送子模块，用于通过IP地址对处于备CMC状态的第一CMC发送最新固件版本号对应的固件信息；

替换操作执行子模块，用于处于备CMC状态的第一CMC利用固件信息执行替换操作；

替换判断子模块，用于判断替换操作是否执行完毕；

主备逆切换子模块，用于将处于备CMC状态的第一CMC执行主备切换逆操作，得到处于主CMC状态的第一CMC；

完成信息发送子模块，用于处于主CMC状态的第一CMC向Node1返回第一升级完成信号。

进一步的，该升级系统还可以包括：

完成通知信号发送单元，用于当第一CMC和第二CMC均完成固件版本升级时，通过预设路径发送均升级完毕的通知信号。

在传统双控中对于双CMC的升级需要主要解决中管理不受影响和存储服务不中断两个主要的问题，本申请采取的策略是Node1升级第一CMC，而Node2升级第二CMC的策略，同时第一CMC升级的时候，第二CMC作为主CMC对外提供服务，而在第二CMC的时候，第一CMC作为主CMC对外提供服务，这样就解决了网络管理不中断的问题；而在Node1升级第一CMC时，Node2不能进行升级，同时对外提供存储服务，当然反之亦然，在Node2升级第二CMC时，Node1不能进行升级，同时对外提供存储服务。

以上各单元可以应用于以下的一个具体的实际例子中，主要包括以下步骤：

(1)获取第一CMC和第二CMC的版本信息：

a)如果第一CMC或者第二CMC没有获取到版本信息，就认为其中一个故障，这个时候不要进行升级，会造成服务中断，转到步骤10；

b)获取到第一CMC和第二CMC版本后，正常转入下一步。

(2)判断第一CMC和第二CMC的版本是否已经是最新的：

a)如果最新的，转到步骤10；

b)如果不是最新的，正常转入下一步。

(3)判断另一个CMC是否在升级，比如升级第一CMC，需要判断第二CMC是否在升级：

a)如果另一个CMC在升级，直接跳过此次升级，转到步骤10；

b)如果不在升级，正常转入下一步。

(4)设定待升级的CMC升级标志，这个标志，两个Node都可以获取，并且步骤3的判断就是判断此标志。

(5)获取待升级CMC的IP地址，例如：通过IPMI命令获取第一CMC的IP地址。

(6)切换CMC的主备关系；例如升级第一CMC，将第一CMC切换成备CMC，第二CMC切换成为主CMC。

(7)等待CMC切换完成；由于CMC切换是一个异步过程，需要等待CMC切换完成。

(8)升级待升级的CMC。

(9)清除待升级CMC的升级标志。

(10)结束。

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

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

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

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (7)

1.一种双CMC固件版本的升级方法，其特征在于，包括：

判断双CMC是否同时满足固件版本升级条件；其中，所述双CMC具体包括完全相同的第一CMC和第二CMC，且所述第一CMC为主CMC、所述第二CMC为备CMC；

若是，则按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级；

若是，则按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级，包括：

若所述第一CMC和所述第二CMC均需要进行固件更新，则按所述预设升级规则先使用Node1对所述第一CMC进行固件更新，再使用Node2对所述第二CMC进行固件更新；

按所述预设升级规则先使用Node1对所述第一CMC进行固件更新，再使用Node2对所述第二CMC进行固件更新，包括：

判断所述第一CMC或所述第二CMC上是否存在升级中标识；

若所述第一CMC和所述第二CMC均不存在所述升级中标识，则利用Node1对所述第一CMC执行固件信息升级操作，并得到所述第一CMC返回的第一升级完成信号；

根据所述第一升级完成信号利用Node2对所述第二CMC执行所述固件信息升级操作，并得到所述第二CMC返回的第二升级完成信号；

根据所述第二升级完成信息确定所述第一CMC和所述第二CMC均处于固件版本升级完毕状态。

2.根据权利要求1所述的升级方法，其特征在于，判断双CMC是否满足固件版本升级条件，包括：

获取所述第一CMC和所述第二CMC的固件版本信息，得到两个CMC各自的固件版本号；

根据最新固件版本号判断两个所述固件版本号各自对应的CMC是否需要进行固件更新。

3.根据权利要求1所述的升级方法，其特征在于，利用Node1对所述第一CMC执行固件信息升级操作，包括：

利用IPMI命令获取所述第一CMC的IP地址；

将处于主CMC状态的第一CMC执行主备切换操作，得到处于备CMC状态的第一CMC；

通过所述IP地址对处于所述备CMC状态的第一CMC发送最新固件版本号对应的固件信息；

处于所述备CMC状态的第一CMC利用所述固件信息执行替换操作。

4.根据权利要求3所述的升级方法，其特征在于，得到所述第一CMC返回的第一升级完成信号，包括；

判断所述替换操作是否执行完毕；

若是，则将处于所述备CMC状态的第一CMC执行主备切换逆操作，得到处于所述主CMC状态的第一CMC；

处于所述主CMC状态的第一CMC向所述Node1返回所述第一升级完成信号。

5.根据权利要求1至4任一项所述的升级方法，其特征在于，还包括：

当所述第一CMC和所述第二CMC均完成固件版本升级时，通过预设路径发送均升级完毕的通知信号。

6.一种双CMC固件版本的升级系统，其特征在于，包括：

升级条件判断单元，用于判断双CMC是否同时满足固件版本升级条件；其中，所述双CMC具体包括完全相同的第一CMC和第二CMC，且所述第一CMC为主CMC，所述第二CMC为备CMC；

CMC固件升级单元，用于按预设升级规则使用相应Node对满足所述固件版本升级条件的CMC进行固件版本升级；

所述CMC固件升级单元包括：

优选更新子单元，用于按所述预设升级规则先使用Node1对所述第一CMC进行固件更新，再使用Node2对所述第二CMC进行固件更新；

所述优选更新子单元包括：

标识判断模块，用于判断所述第一CMC或所述第二CMC上是否存在升级中标识；

第一升级模块，用于若所述第一CMC和所述第二CMC均不存在所述升级中标识，则利用Node1对所述第一CMC执行固件信息升级操作，并得到所述第一CMC返回的第一升级完成信号；

第二升级模块，用于根据所述第一升级完成信号利用Node2对所述第二CMC执行所述固件信息升级操作，并得到所述第二CMC返回的第二升级完成信号；

升级状态判定模块，用于根据所述第二升级完成信息确定所述第一CMC和所述第二CMC均处于固件版本升级完毕状态。

7.根据权利要求6所述的升级系统，其特征在于，所述升级条件判断单元包括：

固件版本号获取子单元，用于获取所述第一CMC和所述第二CMC的固件版本信息，得到两个CMC各自的固件版本号；

版本号判断子单元，用于根据最新固件版本号判断两个所述固件版本号各自对应的CMC是否需要进行固件更新。

Images