国家 / 地区

ISSU技术白皮书-6W100

手册下载

ISSU技术白皮书

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2019 新华三技术有限公司 版权所有,保留一切权利。

非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。

除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。

本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。



概述

ISSUIn-Service Software Upgrade,不中断业务升级)是一种可靠性高的升级设备启动软件的方式,保证升级过程中业务不中断。

随着网络在生活中的作用越来越大,在一些关键的网络中,短暂的网络中断也会造成巨大的损失。因此用户对网络设备操作系统可靠性的要求越来越高,需要网络设备具有更长的持续运行时间。而软件升级又是网络设备的常用操作,保证软件升级时业务不中断对网络设备至关重要。

Comware V7根据不同的升级需要,支持多种升级策略,本文将介绍各种升级策略在软件升级时的实现原理。

软件升级

2.1  软件包

2.1.1  基本概念

·     BIN包:是软件特性的基本单元,每个BIN包均提供特定的功能。用户通过操作BIN包来完成业务的新增、删除以及版本更新。

·     IPE文件(Image Package Envelope复合软件包套件):是多个BIN包的集合。将多个BIN包整合成一个IPE文件对外发布,以减少不同类型BIN包之间的版本管理问题。用户获取IPE文件后,用户可直接使用IPE文件更新设备软件,也可以使用display install ipe-info命令查看该IPE文件中包含了哪些BIN包,然后通过install add命令将IPE文件解压生成BIN包,再利用BIN包更新设备软件。

2.1.2  BIN类型

BIN包按功能可以分为以下几种:

·     Boot软件包:包含操作系统内核的包,提供进程管理、内存管理、文件系统、应急shell等功能。

·     System软件包:软件基础包,包含设备运行必须的模块和基本功能模块,比如设备管理、接口管理、配置管理和路由模块等。

·     Feature软件包:用于业务定制的软件包,能够提供更丰富的业务。是否支持Feature包以及支持哪些Feature包与设备的型号有关。

·     补丁包(Patch包):用于在不重启设备的情况下快速修复系统Bug。补丁包只能修复启动软件包的缺陷,不涉及功能的添加和删除。所以补丁包只有安装而没有升级的说法。补丁包分为叠加补丁包和非叠加补丁包,具体定义如下:

¡     叠加补丁包:两个版本的叠加补丁包之间所解决的问题可以是包含、不包含或不完全包含的关系。只有当两个版本的叠加补丁包之间所解决的问题为不包含的关系时,设备才可以同时安装这两个补丁包。

¡     非叠加补丁包:新版本的补丁包包含旧版本的补丁包所解决的所有问题,每个BootSystemFeature包只能安装一个非叠加补丁。为同一个BootSystemFeature包安装新版本补丁包的同时,设备会卸载旧版本的补丁包。BootSystemFeature包安装的非叠加补丁包可以同时安装在设备上。

说明: 说明

·     叠加补丁包和非叠加补丁包可以同时安装到设备上。

·     设备必须具有Boot包和System包才能正常运行。

 

引入软件包概念,便于软件的管理和维护。将系统软件中比较稳定的基础进程和相对比较活跃的业务进程分离。通常情况下,不需要升级基础进程,只需升级部分业务进程,而且,业务进程之间互相独立,当某业务需要版本更新时,只需升级该业务对应的软件包即可,不用升级所有模块,从而不会对其它业务造成影响。

2.2  ISSU升级策略

软件在发布的时候,开发会根据当前版本和历史版本是否兼容以及兼容的程度,制定升级策略。ISSU升级策略分为兼容升级和不兼容升级。兼容升级又分为:增量升级、软重启升级和重启升级。

进行ISSU升级时,设备会根据新、旧软件版本差异自动选择一种升级策略。如果选择的是兼容升级,则能实现升级过程中业务不中断;如果选择的是不兼容升级,虽然升级过程中不可避免业务中断,但可以减少中断时间。本文重点讨论兼容版本的ISSU升级。

1. 增量升级

增量升级是通过分析升级前后版本间的差异,仅对差异部分的进程实施升级。该升级方式对系统影响最小、升级速度最快,为ISSU升级的最佳方式。

2. 软重启升级

软重启升级的实质为将系统运行瞬间的数据(运行数据、配置数据、硬件数据)和状态全部保存在内存中,再使用新软件重启CPU,重启期间硬件继续提供转发能力。CPU重启后使用上次保存的数据、状态继续运行。对于需要实时和对端交互协议报文来保持连接的,则通过协议代理进程来确保在软重启升级过程中连接和协议状态不受影响。相比增量升级而言,软重启影响了本CPU上运行的所有模块,升级时间较长。软重启升级一般在新旧版本软件差异较大时实施。

3. 重启升级

重启升级是通过重启本主控板(包括CPU和转发芯片)加载新软件的方式完成升级。重启升级只有在设备同时具有主用主控板和备用主控板时才能做到ISSU,如果设备只有主用主控板没有备用主控板,则该方式无法保证在升级过程中业务不中断。重启升级一般在新旧版本软件无法完全兼容时实施。

2.3  ISSU技术

ISSU是一种复杂的综合技术,每种ISSU的升级策略,都需要多种技术配合,才能达到ISSU的效果。下面几章将分别介绍每种ISSU升级策略相关的主用技术,以及在各种场景下,这些技术如何配合做到ISSU

增量升级

3.1  相关技术

3.1.1  模块化

Comware V7系统采用了模块化的设计,各个网络服务功能分别运行各自的进程,每个进程可以单独启动、终止。进程间运行空间隔离,单个进程的重启不会影响系统其他部分。

模块化后,单个特性在系统运行过程中以新版本重启进程完成本特性的升级,而不需要重启整个系统软件。

模块化对系统的扩展性也有很大好处,很容易在不影响系统运行的情况下添加新功能。

图1 Comware V7模块化体系结构

 

3.1.2  进程级GR

Comware V7采用进程级的GR技术,实现进程级的重启恢复。即每个进程运行过程中进行备份,重启时,与此进程相关的软硬件均不删除此进程的相关数据,待进程重新运行,恢复自身数据后,与相关软、硬件进行数据平滑,保证运行状态一致,继续运行。整个重启过程中业务不中断,系统其他部分功能不受影响,邻居设备不感知此过程。重启的服务只在重启期间不提供服务,重启后马上恢复服务,且不影响重启前正在进行中的服务。

进程级GR的冗余备份有两种方式,一种是数据的备份,另一种是进程的备份。根据备份方式不同,有两种进程级的GR,单进程的GR和主备进程的GR

·     单进程的GR时,进程运行过程中将必要的数据进行备份,备份数据保存在本地的内存数据库中。当系统发现进程故障时,自动重启,进程重新启动后使用备份的数据恢复运行,最后与系统中其他相关进程交互数据,以弥补重启期间可能缺失的变化事件,完成整个恢复过程。这种方式对系统的要求少,占用资源少,一般用在盒式设备的进程或分布式设备接口板的进程上。

图2 单进程GR

 

·     主备进程的GR时,开启服务时会同时启动主备进程,备进程会实时接收主进程的状态,以随时准备接替主进程运行。当系统发现主进程故障后自动重启主进程,但无需等待其重启,备进程将升级为主进程,直接接替工作。当故障进程重启完成后,将工作在备状态,以备进程身份运行。这种方式相对于单进程的GR,恢复时间更短,可用性更高,但占用资源稍多,一般分布式系统的主控板进程使用此方式。

图3 主备进程的GR

 

通过支持进程级的GR,使得特性升级时可以进行平滑的重启恢复,升级时其他特性不受影响,业务不中断,而且不会对网络上其他设备的协议运行造成影响。

3.2  技术应用

3.2.1  增加特性

加载新的功能包或者进行版本升级时,经常会增加一些新的特性。在Comware V7模块化的架构下,只有用户使用的功能才会运行,未使用的功能并不运行,因此多数情况下这些新增的特性在升级后并不会立即运行。这样增加新的特性对系统的运行没有任何影响,只是增加了一些功能,供用户在升级后使用。而在用户使用这些新特性前,系统的运行与升级前完全一样。

个别特性是缺省运行的,即不需要用户使能就开始运行,如果升级增加这些特性,会在升级完成后将新增加的特性自动运行,同样不会对当前业务造成影响。

3.2.2  删除特性

功能包卸载或降级时,往往会删除一些特性,这些特性在降级后将不再提供。如果在降级前这些特性并未运行,那么降级的操作仅仅影响系统可使用的功能范围,对系统的运行没有任何影响。如果待删除的特性正在运行,会在降级时停止运行,但对其他特性不会有影响,即降级后版本中仍然提供的特性业务不会中断。为了避免用户不必要的疑惑及减少对网络的影响,建议用户在降级前有步骤的逐一停止这些降级后不再支持的特性。

3.3  技术实现

3.3.1  未运行特性的升级

功能包升级时有时是对当前未使用的功能进行升级,由于Comware V7中这些不使用的功能并不运行,因此对这些特性进行升级,对系统运行没有任何影响,可以做到ISSU

3.3.2  运行特性的升级

(1)     对正在运行的特性进行升级,需要利用进程级的GR功能,平滑的终止当前运行的进程,启动新版本的进程。

如果升级特性在系统中存在主备进程,则需要分别先后对备进程、主进程进行升级。一般来说,在分布式双主控的设备上运行在主控板的程序,以及IRF中运行在各逻辑主控板的程序有主备进程。

¡     备进程的终止重新运行对系统功能没有影响,可以直接在不影响系统的情况下完成升级。

图4 备进程升级

 

¡     主进程的升级使用主备进程的GR功能,通过主备进程倒换完成平滑的重启,升级后的进程以备进程状态运行。

图5 主进程升级

 

(2)     在分布式单主控设备运行在主控板的程序、集中式设备及分布式设备接口板上运行的程序没有备进程保护。这些进程升级需要利用单进程的GR技术做到ISSU

图6 单进程GR

 

软重启升级

Comware V7的大部分功能升级都可以使用增量升级方式在系统运行过程中完成升级,但是如果升级涉及软件核心部分,对每个单板还是涉及停止整个软件运行,再运行新版本软件的过程。为了让这个过程中业务不中断,Comware V7提供了软重启的升级方式。在软件升级过程中,只终止原有版本的软件运行,重启运行新的版本,而硬件不复位,一直保持升级前状态不变,转发芯片仍然按照原有转发表项进行数据转发。新版本运行后恢复重启前的配置、状态数据,直接接管对硬件的控制,继续设备运行,整个升级过程中业务不中断。

Comware V7通过以下一系列相关技术的配合来完成各种场景下的软重启升级。

4.1  相关技术

4.1.1  软重启恢复

在软重启中首先要做到升级后各进程可以继续运行,而不是重新以初始状态开始运行,即进行软重启恢复。

Comware V7支持进程级的GR,各进程运行过程中会根据需要将运行状态数据实时保存在内存数据库中。但由于软件的重启,内存数据库中的数据无法在重启后仍然保有重启前的数据,因此在软重启升级前,当各进程终止运行后,会将内存数据库中需要在重启后继续使用的数据进行持久化保存,既将数据保存到非易失存储介质中。新版本软件启动后,在其他进程运行前,内存数据库恢复先期保存到非易失存储介质中的数据。这样各进程启动时,可以从数据库恢复数据,继续程序运行。

图7 软重启恢复过程

 

4.1.2  协议代理

一些控制协议会定时发送Hellokeepalive等保活报文,如果在一定时间内不能接收,会认为控制中断而改变协议状态。为了防止升级过程中,由于控制程序短暂停止工作,使得保活报文不能及时发出,造成不必要的网络动荡,Comware V7增加了协议代理功能。在整个系统中选择一个正常运行的单板启动协议代理服务,对升级软件中时间敏感的控制逻辑,临时交由代理服务帮助处理。

其过程为:在软重启前启动代理服务,通知代理接管部分控制功能。在软件重启过程中,协议代理完成重启板协议保活,发送所需报文。新版本启动后通知代理不再接管处理,各控制协议继续正常运行。如8所示。

图8 协议代理处理过程

 

4.1.3  报文重定向

当对系统中一个单板进行升级时要保证其他单板的运行不受影响,这一方面通过进程级的GR,保证在升级时,不影响其他进程的运行;另一方面还要保证其他正常运行的单板可以正常收发报文,即使此报文需要经过正在进行升级重启的单板,既做到本机通信不中断。

对于发送报文,由于各板均有转发能力,而软重启时硬件仍然可以正常转发,因此可以直接将报文通过硬件发送,升级时不会有影响。

对于接收报文,Comware V7会在单板软重启前,将从此单板接口接收的目的地为本设备的报文,重定向到当前未进行升级操作的一个主控板,这样保证到本设备的所有报文都可以被接收,正常运行的进程均不会丢失接收报文。当升级结束后,再取消重定向,将报文正常上送到单板本地CPU处理。

4.1.4  系统级倒换

对于有多个主控板的系统,可以通过逐板升级,保证至少有一个主用主控板对整个系统进行控制。由于每个主控板都具有相同的全局控制功能,这样可以保证升级过程中这些对整个系统的控制功能不中断。而各主控板控制权的平滑倒换,则依靠系统级的高可用性功能实现,以保证倒换的过程中业务不中断。Comware V7保留了整板倒换的系统级高可用性功能,可以保证主、备主控板倒换时业务不中断。

4.1.5  协议GR

当系统只有单一主控板、无法通过设备内协议的状态备份做到升级时的协议不中断,这时就需要使用协议GR技术,以确保协议进程升级时的转发不中断,以及升级后进程数据的恢复。

协议GR是一种保证转发业务在设备进行IP/MPLS转发协议(如BGPIS-ISOSPFLDPRSVP-TE等)重启或主备倒换时不中断的技术。它需要周边设备的配合来完成路由等信息的备份与恢复。

各种协议均有各自的GR协议标准,但原理都是类似的。首先和邻居设备协商GR能力,均具有GR能力,才在一方重启时启动GR恢复功能。GR过程如下:

(1)     当一方设备的协议重启时,此设备不会删除转发表项,仍然按照原有的转发表项转发报文。邻居设备发现对端协议重启后,也不会删除从该设备学习到的路由,只将这些路由进行标记,仍按照这些路由转发报文,从而确保协议重启时,报文转发不会中断。

(2)     协议正常重启后,会重新与邻居建立会话,并进行信息交互。通过交互的信息,重启的协议恢复路由信息;邻居设备确定哪些标记的路由可以恢复正常,而哪些需要删除。

如果协议不能正常重启,邻居设备会在一定时间后删除所有标记的路由。

4.2  技术应用

4.2.1  接口板软重启

接口板软重启时,由当前主控板启动代理功能完成重启接口板的保活,所有此接口板接口接收的到本机的报文重定向到主控板处理。再配合接口板各进程的软重启恢复,做到业务不中断。软重启过程如下:

(1)     运行时各进程根据需要将运行状态数据实时保存在内存数据库中。

(2)     软重启前将数据持久化,既将数据保存到非易失存储介质中。启动代理服务,通知代理接管部分控制功能。完成数据接收位置的切换,将本板硬件接收的到本机的数据报文重定向到主控板,以保证重启过程中未重启部分能正常收发报文。

(3)     进行软件重启,停止老版本软件运行,加载运行新版本软件。重启过程中由于硬件未复位,因此流量不中断。重启前的准备保证了其他板控制协议不中断,协议代理完成重启板协议保活。

(4)     新版本启动后数据库恢复先期保存到非易失存储介质中的数据。

(5)     各进程启动,从数据库恢复数据,通知代理不再接管处理,继续重启前的运行。应该本地接收的数据切换回本板CPU处理。

图9 接口板软重启过程

 

通过以上软重启技术,使得整个升级过程转发业务不中断,未重启单板控制不中断,重启单板控制协议可恢复。

4.2.2  双主控板软重启

双主控板进行软重启升级时,通常采用主备板的倒换使运行在主控板的各种业务不中断,但是主控板也有一些只在单个板运行的本地功能,这在IRF中更为明显,IRF中的每个逻辑主控板通常也会有业务口,因此包含接口板的全部功能。这些本地功能没有备份的进程,需要采用类似于接口板软重启的方式进行软重启恢复。因此双主控升级时软重启技术与主备倒换技术同时发挥作用,保证各业务不中断。

图10 双主控环境主用主控板软重启过程

 

10所示,456进程为本地功能,通过软重启恢复实现ISSU123进程为全局功能,当主用主控板升级软重启时立即进行主备倒换,备用主控板进程变为主进程接替工作。

备用主控板升级时相对简单,因为备进程不参与系统运行,因此重启升级时对业务完全没有影响,只需要重启后重新接收备份数据即可完成升级。这样备用主控板上只需要保证本地业务的ISSU,即类似于接口板软重启的恢复过程。

图11 双主控环境备用主控板软重启过程

 

由于备用主控板的升级对系统的影响小于主用主控板升级,因此在双主控升级时一般先升级备用主控板,再升级主用主控板。

4.2.3  集中式软重启

集中式设备软件升级时,因为没有其他主控板参与ISSU,因此软重启时无法借助主控板完成代理功能,需要在ISSU前做好准备工作。对于有保活机制的协议适当延长保活报文的间隔时间,或关闭相关功能。另外路由等三层协议需要启用协议GR功能,以便在软重启后与周边设备配合恢复表项。

软重启过程如下图:

(1)     运行时各进程根据需要将运行状态数据实时保存在数据库中。

(2)     软重启前将数据持久化,既将数据保存到非易失存储介质中。

(3)     进行软件重启,停止老版本软件运行,加载运行新版本软件。重启过程中由于硬件未复位,因此流量不中断。

(4)     新版本启动后数据库恢复先期保存到非易失存储介质中的数据。

(5)     各进程启动,从数据库恢复数据。

图12 集中式软重启过程

 

如果升级前进行了前面介绍的准备工作,修改了配置,那么软重启完成后需要恢复原有配置。

4.2.4  单主控板软重启

单主控板的软重启过程与集中式软重启相同,由于没有备进程保护,因此所有进程均需要通过软重启进行恢复。而路由、MPLS等协议需要在重启后通过协议GR完成数据的恢复。

重启升级

重启升级是在版本差异较大时的一种升级方式,由于版本差异较大无法进行软重启恢复时,采用重启升级方式。重启升级在一些特定的场景也能做到ISSU。即当升级不涉及接口板,且为双主控板设备时可以通过主控板的倒换做到ISSU

图13 重启过程

 

升级过程如13所示,先将备用主控板软件重启升级,再将主用主控板软件重启升级,重启主用主控板时会造成主备倒换,由已经升级成新版本的备用主控板接替工作。由于普通的分布式设备主控板没有业务口,因此重启主控板不会造成流量的中断,可以通过重启升级方式做到ISSU

ISSU操作过程

6.1  集中式设备或单主控板设备升级

对于独立运行的集中式设备或单主控板设备,只有一个主控板需要升级,因此升级步骤简单,只需要对此主控板进行升级即可。但是由于没有其他主控板的保护,因此需要进行更多的升级前的准备工作,以帮助升级更加平滑的完成。

6.1.1  升级前准备

1. 关闭新版本中不支持的功能(可选)

新的版本比原有版本功能少一般出现在降级的场合。用户进行升降级操作之前,首先需要确定当前设备使用的功能是否在新版本里仍然支持。如果不能支持,就意味着升降级操作后会有一些功能缺失,因此需要判断是否可以不再使用这些功能,以决定是否进行升降级操作。如果仍然决定进行升降级操作,则应该首先手动关闭这些功能,一旦发现关闭后网络功能异常,尽快恢复配置,停止升降级操作。这样慎重的操做可以有效的减少错误的升降级,并可以在错误发生时及时发现并纠正。

2. 保存配置(可选)

对待升级的设备使用save命令保存当前配置。如果不保存配置,当前配置会在设备重启后丢失。

3. 确认有足够的存储空间

各种升级都要确保存储介质有足够的空间保存需要升级的版本。因此升级前需要查看剩余的存储空间是否足够保存待升级的IPE文件及其解压出的软件包。

4. 下载IPE文件

FTPTFTP将软件包下载到设备存储介质的根目录。

5. 系统状态检查

检查系统状态,保证各部分均为稳态运行,没有正在进行中的单板插拔处理。

6. 升级策略检查

可以通过display version comp-matrix命令检查待升级版本的兼容情况,同时预测待升级软件包将使用的升级策略,根据不同的升级策略,决定后面的操作步骤。

7. 其它准备(可选)

如果升级涉及路由、MPLS等有GR机制协议进程的重新运行,则要保证升级时GR功能开启。通过升级策略检查可以确定是否涉及这些协议的重新运行,如果是软重启策略则涉及所有当前运行的协议重新运行;如果是增量升级,升级预测命令会显示涉及的服务,如果涉及路由、MPLS协议且此协议正在运行,则也需要保证GR功能开启。缺省情况下,设备上的GR功能都是开启的。但也不排除某些可靠性要求比较低的场合没有开启GR功能,或者由于误操作将GR功能关闭。因此升级前请检查GR功能是否开启。

如果为软重启升级、只有单个主控板时,需要额外考虑协议的保活。既手工延长保活时间或临时停止保活检测。此操作还有可能需要修改网络上其他设备的配置,以MSTP为例,需要修改其他设备的时间参数,以延长超时时间。

如果以上准备工作修改了待升级设备的配置,请使用save命令进行配置保存。

6.1.2  升级过程

1. 升级软件

这一步是真正的升级动作,会终止相关进程,使用新版本进程重新运行,使用issu load file ipe filename命令进行软件升级。

如果升级涉及接口板软件,则此步会将主控板及所有接口板一起升级。

2. 提交完成

软件升级后通过issu commit命令完成升级过程。

未提交的升级会在一定时间后自动回退到升级前版本,取消本次升级。

6.1.3  升级完成

ISSU完成以后,可以开始使用新版本软件的各种功能。如果升级前准备时对系统配置进行了修改,可以根据需要恢复原有设置,再使用save命令重新保存配置。

6.2  双主控板升级

6.2.1  升级前准备

请检查两主控板当前运行的版本及ISSU状态,保证各板均使用相同版本正常运行,且不在ISSU的中间状态。其它准备请参见“6.1  集中式设备或单主控板设备升级”。

6.2.2  升级过程

按照以下步骤完成升级。在升级过程中不要修改设备配置,以及对设备进行其他操作,以减少对ISSU过程的影响。

图14 双主控板升级过程

 

1. 升级备用主控板

Comware V7上实现了控制平面分布式,各个主控板采用负载分担方式运行,每个主控板都可以运行一些协议的主进程,但系统中仍然有主用主控板与备用主控板的区分,一些基础功能一直在主用主控板上运行主进程。首先升级备用主控板对系统影响相对较小,并且可以在出现异常时及时回退。因此首先使用issu load file ipe filename slot slot-number命令进行备用主控板软件升级。

2. 主备倒换

使用issu run switchover命令进行主备倒换,使得已经进行软件升级的主控板成为系统的主用主控板,接管对设备的控制。

3. 升级确认

为了提高ISSU过程的可靠性,在升级过程中会启动回滚定时器,如果用户不对升级结果进行确认,系统将自动回退到升级前的软件版本。因此需要使用issu accept命令对升级进行确认,以表示升级过程正常,无需回滚。

4. 提交完成

最后通过issu commit命令完成升级过程,将系统中其他未升级的备用主控板、接口板进行软件升级。

6.2.3  升级完成

ISSU完成以后,可以开始使用新版本软件的各种功能。如果升级前准备时对系统配置进行了修改,可以根据需要恢复原有设置,再使用save命令重新保存配置。

6.3  IRF升级

只有一台集中式设备的IRF、只有一块主控板的分布式设备的IRF升级操作过程同“6.1  集中式设备或单主控板设备升级”。其它情况的IRF均能虚拟成多块主控板的分布式设备,其中一块主控板为全局主用主控板,其它主控板为全局备用主控板,因此升级过程与双主控设备升级类似。区别如下:

·     对于分布式设备组成的IRF系统,升级IRF系统过程中只需以框为单位进行升级操作。在升级每个框时,系统会按照框内主用主控板、备用主控板的情况,依次自动完成升级。

·     由于通常情况下,IRF中存在多个从设备,因此需要依次针对各个从设备使用issu commit命令进行升级提交。

6.4  卸载功能包

卸载功能包可以认为是一种简化的软件包降级过程,由于只是删除功能,没有新的功能需要运行,也不存在有正在运行功能的变化,因此过程比较简单。

1. 关闭卸载报对应的功能(可选)

在卸载功能包之前,请先手工关闭卸载包对应的功能,并删除该功能对应的配置。

2. 保存配置(可选)

对待升级的设备使用save命令保存当前配置。如果不保存配置,当前配置会在设备重启后丢失。

3. 卸载各板的软件包

使用install deactivat命令依次卸载各主控板的软件包,卸载顺序的总体原则是先备用主控板后主用主控板,先从设备后主设备。

4. 降级确认

通过install commit命令确认软件包的卸载结果。

6.5  支持MDC

一个设备上的所有逻辑设备必须运行相同的版本,因此在运行MDCmultitenant device contexts,多租户设备环境)功能的设备上进行升级时,相当于所有的逻辑设备一起升级。升级操作只在缺省MDC进行,升级步骤与没有启用MDC时完全相同,一旦升级成功,各个逻辑设备均完成升级。

在存储介质中只会保存一份版本文件,因此升级前无需预留更多的存储空间。但是与设备运行相关的升级前准备工作需要在各个逻辑设备进行。这包括关闭新版本不再提供的功能,以及单主控升级时的延迟保活时间等。