WO2017028375A1

WO2017028375A1 - Version upgrading method and system

Info

Publication number: WO2017028375A1
Application number: PCT/CN2015/092850
Authority: WO
Inventors: 董圣男
Original assignee: 中兴通讯股份有限公司
Priority date: 2015-08-17
Filing date: 2015-10-26
Publication date: 2017-02-23
Also published as: CN106469069A; CN106469069B

Abstract

A version upgrading method and system. The method comprises: during a device upgrading process, each device client receiving a new version activation instruction reboots a central processing unit (CPU) and applies a new version (41); and when the new version is successfully activated, each device client receiving a submitted new version instruction uses underlying chip data backed-up in advance to update the underlying chip data of the current client (42).

Description

Version upgrade method and system

Technical field

This application relates to, but is not limited to, the field of communication technology.

Background technique

Version upgrade is a relatively mature technology. There are many upgrade methods. The most common one is ISSU (In-Service Software Upgrade), which is a guarantee that can be guaranteed during the upgrade process. In view of this advantage, this upgrade method is widely used because of the uninterrupted service or the short-term upgrade mode.

The basic principle of ISSU is to upgrade the standby main control board when the main control board is running normally. After the upgrade of the standby main control board is completed, the active/standby switchover is performed, so that the original standby main control board is upgraded as the main control. After the active/standby switchover is complete, the other boards are upgraded to the new version. The upgrade is complete. The whole process is shown in Figure 1.

The ISSU upgrade requires that the upgraded version be a compatible version and the system is the active/standby environment. The device has at least two main control boards, which serve as the primary and backup masters. During the upgrade process, the two boards are alternately used as the main control to ensure the normal operation of the system. The working principle is shown in Figure 2.

As can be seen from the above, the ISSU upgrade mode has certain limitations. First, the device requires at least two main control boards. When a board is upgraded with a hot patch, the board may restart. This will result in a short-term service interruption.

Summary of the invention

The following is an overview of the topics detailed in this document. This Summary is not intended to limit the scope of the claims.

This document provides a version upgrade method and system to solve the limitations of the related technology ISSU upgrade method.

A version upgrade method, the method comprising:

During the device upgrade process, each device client that receives the new version activation command restarts the central office. Manage the unit CPU and apply the new version;

After the new version is successfully activated, each device client that receives the new version command receives the underlying chip data of the client by using the pre-backed underlying chip data.

Optionally, in the foregoing method, before the device client receives the new version activation command, the method further includes:

After receiving the new version upgrade command, the device server sends a save data request to each device client.

Receiving, by the device client, the device that saves the data, reporting the underlying chip data of the device to the device server;

The device server backs up the received underlying chip data of each device client to the device hard disk.

Optionally, in the foregoing method, the process of updating the underlying chip data of the client by using the pre-backed underlying chip data by receiving the new version instruction by each device client includes:

When receiving the new version command, the device client compares the pre-backed underlying chip data with the new version data, and restores the same data according to the pre-backed up underlying chip data, and compares the different data according to the comparison. The new version of the data is updated.

Optionally, the foregoing method further includes:

After the new version fails to activate, roll back to the old version and terminate the upgrade.

A version upgrade system, the system comprising:

The upgrade unit is set to: when the new version activation command is received during the device upgrade process, restart the central processing unit CPU and apply the new version;

The data recovery unit is configured to: after the new version is successfully activated, when the new version command is received, the underlying chip data of the client is updated by using the pre-backed underlying chip data.

Optionally, the above system further includes:

The data transmission unit is configured to report the underlying chip data to the server when receiving the data save request sent by the server.

Optionally, in the above system, the data recovery unit is configured to:

Use pre-backup of underlying chip data and new version data when receiving a new version of the command For comparison, the same data is compared, and the underlying chip data is backed up for recovery, and the updated data is updated according to the new version data.

Optionally, the above system further includes:

The fallback unit is set to: After the new version fails to activate, roll back to the old version and terminate the upgrade.

A computer readable storage medium storing computer executable instructions for performing the method of any of the above.

The technical solution of the present application is used for the upgrade of the compatible version. When the version is updated, only the CPU of the board is restarted, and the underlying forwarding chip is not restarted, so that the underlying communication can be ensured smoothly, thereby solving the related requirements of the ISSU upgrade mode. And the problem of business interruption in a short period of time.

Other aspects will be apparent upon reading and understanding the drawings and detailed description.

BRIEF abstract

1 is a flowchart of a related art ISSU upgrade;

2 is a schematic diagram showing the principle of alternately using two boards as the main control board in the ISSU upgrade process of the related art;

Figure 3 is a schematic diagram of the principle of the embodiment of the present invention;

4 is a flowchart of a method for implementing version upgrade according to an embodiment of the present invention;

FIG. 5 is a flowchart of an operation process of implementing version upgrade according to an embodiment of the present invention; FIG.

FIG. 6 is a schematic diagram of a system for implementing version upgrade according to an embodiment of the present invention.

Embodiments of the invention

Embodiments of the present invention will be described below with reference to the accompanying drawings. It should be noted that, in the case of no conflict, the features in the embodiments and the embodiments of the present application may be combined with each other arbitrarily.

Example 1

The inventor of the present application proposes that the underlying chip data can be backed up before the upgrade, and the underlying chip data is restored and updated after the upgrade, that is, only the CPU can be restarted during the upgrade without resetting the underlying chip. The device client may trigger the checkpoint (checkpoint) to collect and save the underlying chip data and upload it to the device server. The device server saves the file to the server hard disk in the file format. The upgrade process is incorrect. The underlying chip is reset. After the upgrade is completed, the client and the server can exchange and update data through checkpoint. The principle is shown in Figure 3.

As shown in FIG. 4, this embodiment provides a version upgrade method, which mainly includes the following operations:

Step 41: During the device upgrade process, each device client that receives the new version activation command restarts only the CPU and applies the new version;

Step 42: After the new version is successfully activated, each device client that receives the new version instruction receives the underlying chip data of the client by using the pre-backed underlying chip data.

The underlying chip data of the device client that is backed up may be that after the device server receives the new version upgrade command, the device server forwards the data to each device client, and each device client reports the underlying chip data to the device server. The device server backs up the acquired underlying chip data of each device client to the device hard disk. Certainly, the embodiment is not limited to this manner, and each device client may actively report the underlying chip data to the device server, or periodically report the underlying chip data, etc., to ensure that the device hard disk has the bottom layer of each device client. Chip data can be used after the new version is activated.

In addition, when the version is upgraded according to the above method, if the new version fails to be activated, it will fall back to the old version and terminate the upgrade.

FIG. 5 shows an operation process of performing version upgrade in the embodiment, and the process includes the following operations:

Step S501: Making a new version. Use the tool on the computer to create a version to be upgraded that is compatible with the current running version of the device.

Step S502: The user inputs an add command (that is, a new version upgrade command), uploads the version to the device hard disk through ftp, and adds a new version.

Step S503: The device server sends a save data request to each client of the device, and the client triggers a checkpoint to collect the underlying chip data.

The underlying chip data includes electrical signals, data codes, and lines required for transmission and reception. State, etc., different chip types select different data content.

Step S504: The device client uploads the collected data to the device server.

Step S505: The device server saves the data to the device hard disk in a file format.

In step S506, the device prints a prompt to confirm that the version is added. If the user inputs a new version activation command, the device server sends a new version activation command to each device client, and each device client CPU restarts the application. new version.

Step S507: After the new version is up, the user inputs a query command to check the status of the new version, and confirms whether the version upgrade is successful. If the step S408 is successfully performed, otherwise step S411 is performed.

Step S508: The user inputs a new version instruction.

Step S509: After receiving the new version command, the device server sends the new version command to each device client, and the device client triggers a checkpoint to update the underlying chip data by using the underlying chip data of the device client in the device hard disk. .

The device client triggers the checkpoint, compares the underlying chip data in the device hard disk (that is, the underlying chip data pre-backed up) with the new version data, and restores the same data according to the pre-backed up underlying chip data for comparison. Different data is updated according to the new version data to ensure that the device can run normally after the upgrade.

Step S510: Check the device to print a prompt to confirm that the new version is submitted, and the process ends.

Step S511: The user inputs a rollback command, the device client CPU restarts, rolls back to the old version, and ends the process.

Example 2

This embodiment provides a version upgrade system, as shown in FIG. 6, which includes at least the following units:

The upgrading unit 61 is configured to: when the new version activation command is received during the device upgrade process, only restart the CPU and apply the new version;

The data recovery unit 62 is configured to: after the new version is successfully activated, when the new version command is received, the underlying chip data of the client is updated by using the pre-backed underlying chip data.

The above data recovery unit is configured to: trigger a checkpoint when receiving a new version of the instruction, and use the pre-backed underlying chip data to compare with the new version data, for comparison The same data is output, and the original chip data is restored according to the pre-backed up data, and the updated data is updated according to the new version data.

In addition, the above system may further include: a data transmission unit, configured to: report the underlying chip data of the own to the server when receiving the data storage request sent by the server. After the device terminal activates and submits a new version, the device server sends the information to the device client.

It should also be noted that a fallback unit can be added, set to: After the new version fails to activate, roll back to the old version and terminate the upgrade. The system provided in this embodiment can implement the method in the foregoing Embodiment 1, and the detailed working principle of the system can be referred to the corresponding content in the foregoing Embodiment 1, and details are not described herein again.

As can be seen from the foregoing embodiments, the technical solution of the present application can upgrade a new version without interrupting the service, and the service upgrade can be performed without only one main control board. The technical solution of the present application can be used in the current multiple version upgrade manners.

One of ordinary skill in the art will appreciate that all or a portion of the steps of the above-described embodiments can be implemented using a computer program flow, which can be stored in a computer readable storage medium, such as on a corresponding hardware platform (eg, The system, device, device, device, etc. are executed, and when executed, include one or a combination of the steps of the method embodiments.

Alternatively, all or part of the steps of the above embodiments may also be implemented by using an integrated circuit. These steps may be separately fabricated into individual integrated circuit modules, or multiple modules or steps may be fabricated into a single integrated circuit module. achieve.

The devices/function modules/functional units in the above embodiments may be implemented by a general-purpose computing device, which may be centralized on a single computing device or distributed over a network of multiple computing devices.

When the device/function module/functional unit in the above embodiment is implemented in the form of a software function module and sold or used as a stand-alone product, it can be stored in a computer readable storage medium. The above mentioned computer readable storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

Industrial applicability

In the embodiment of the present invention, the new version can be upgraded without interrupting the service, and the service upgrade can be performed without interrupting only one main control board. The embodiments of the present invention can be used in the current multiple version upgrade manners.

Claims

A version upgrade method, the method comprising:

During the device upgrade process, each device client that receives the new version activation command restarts the central processing unit CPU and applies the new version;

After the new version is successfully activated, each device client that receives the new version command receives the underlying chip data of the client by using the pre-backed underlying chip data.
The method of claim 1 wherein before each device client receives a new version activation command, the method further comprises:

After receiving the new version upgrade command, the device server sends a save data request to each device client.

Receiving, by the device client, the device that saves the data, reporting the underlying chip data of the device to the device server;

The device server backs up the received underlying chip data of each device client to the device hard disk.
The method according to claim 1 or 2, wherein the process of updating the underlying chip data of the client by using the pre-backupped underlying chip data by receiving the new version instruction by each device client includes:

When receiving the new version command, the device client compares the pre-backed underlying chip data with the new version data, and restores the same data according to the pre-backed up underlying chip data, and compares the different data according to the comparison. The new version of the data is updated.
The method of claim 3, the method further comprising:

After the new version fails to activate, roll back to the old version and terminate the upgrade.
A version upgrade system, the system comprising:

The upgrade unit is set to: when the new version activation command is received during the device upgrade process, restart the central processing unit CPU and apply the new version;

The data recovery unit is configured to: after receiving the new version command, use the pre-backed underlying chip data to restore and update the underlying chip data of the client.
The system of claim 5, the system further comprising:

The data transmission unit is configured to report the underlying chip data to the server when receiving the data save request sent by the server.
The system according to claim 5 or 6, wherein said data recovery unit is configured to:

When receiving the new version of the instruction, the pre-backup of the underlying chip data is compared with the new version of the data, and the same data is compared, and the underlying chip data is backed up according to the pre-backup, and the new version is compared according to the different data compared. The data is updated.
The system of claim 7 further comprising:

The fallback unit is set to: After the new version fails to activate, roll back to the old version and terminate the upgrade.
A computer readable storage medium storing computer executable instructions for performing the method of any of claims 1-4.