Single board upgrade method, single board device and computer readable storage medium

By analyzing and activating the patch package, confirming the setting slots of the board to be upgraded and upgrading, the problems of complex patch upgrade process and high professional requirements of the operator are solved, and the degree of automation and operation efficiency are improved.

CN114518891BActive Publication Date: 2025-04-18ZTE CORP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202011302415.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-11-19
Publication Date
2025-04-18
Estimated Expiration
2040-11-19

AI Technical Summary

Technical Problem

In the prior art, patch upgrades have high professional requirements for on-site upgrade operators and the upgrade process is complicated.

Method used

Provide a single board upgrade method, including activating the obtained patch package, analyzing the patch package to obtain single board parameters, confirming the setting slots of the single board to be upgraded, and upgrading the single board to be upgraded.

Benefits of technology

It improves the automation of patch package upgrades, reduces the operation work of on-site upgrade operators, and achieves a more accurate identification and control of the scope of patch package effectiveness.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114518891B_ABST
    Figure CN114518891B_ABST
Patent Text Reader

Abstract

The embodiment of the present invention provides a single board upgrade method, a single board device and a computer-readable storage medium. The single board upgrade method activates an acquired patch package; parses the patch package to obtain single board parameters corresponding to the patch package; confirms the setting slot of the single board to be upgraded corresponding to the patch package according to the single board parameters; upgrades the single board to be upgraded according to the setting slot, accurately identifies the effective scope of the patch package, and executes the upgrade operation. In some implementation processes, it has the technical effect of improving the automation level of patch package upgrades and reducing the operation work of on-site upgrade operators.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present invention relate to, but are not limited to, the field of communication equipment, and specifically, relate to, but are not limited to, a single-board upgrading method, a single-board device, and a computer-readable storage medium. Background Art

[0002] With the continuous development of communication technology, all walks of life have higher requirements for the stability of communication services and the friendliness of operation and maintenance operations. In related technologies, the overall software version upgrade process of communication equipment can achieve lossless or minimally damaged upgrades, with little impact on business functions. However, in actual applications, the upgrade cycle of the entire network element basic software version is still relatively long. The more frequent upgrade scenario is to patch the network element basic version problems through patching. However, in related technologies, patching upgrades have high professional requirements for on-site upgrade operators. At the same time, the confirmation of the effectiveness of cold patches is relatively complicated, especially when there are multiple cold patches in the engineering environment. Each cold patch may involve different boards but all require maintenance, so engineering personnel are required to ensure the actual operation and maintenance level. Summary of the invention

[0003] The single board upgrade method, single board device and computer readable storage medium provided by the embodiments of the present invention mainly solve the technical problem that patch upgrade in related technologies has high professional requirements for on-site upgrade operators and the upgrade process is complicated.

[0004] In order to solve the above technical problems, an embodiment of the present invention provides a single board upgrade method, comprising:

[0005] Activate the obtained patch package;

[0006] Parsing the patch package to obtain the board parameters corresponding to the patch package;

[0007] According to the single board parameters, confirm the setting slot of the single board to be upgraded corresponding to the patch package;

[0008] The board to be upgraded is upgraded according to the set slot.

[0009] The embodiment of the present invention also provides a single board device, a processor, a memory and a communication bus;

[0010] The communication bus is used to realize the connection and communication between the processor and the memory;

[0011] The processor is used to execute one or more computer programs stored in the memory to implement the steps of the single board upgrade method as described above.

[0012] An embodiment of the present invention further provides a computer-readable storage medium, which stores one or more programs. The one or more programs can be executed by one or more processors to implement the steps of the single board upgrade method as described above.

[0013] According to the single board upgrade method, single board device and computer-readable storage medium provided by the embodiments of the present invention, the acquired patch package is activated; the patch package is parsed to obtain the single board parameters corresponding to the patch package; according to the single board parameters, the setting slot of the single board to be upgraded corresponding to the patch package is confirmed, and the single board to be upgraded is upgraded; the effective scope of the patch package is accurately identified, and the upgrade operation is performed. In certain implementation processes, technical effects can be achieved, including but not limited to improving the automation level of patch package upgrades and reducing the operation work of on-site upgrade operators.

[0014] Other features and corresponding beneficial effects of the present invention are described in the latter part of the specification, and it should be understood that at least part of the beneficial effects become obvious from the description in the specification of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A schematic diagram of a flow chart of a single board upgrade method according to Embodiment 1 of the present invention;

[0016] Figure 2 This is a schematic diagram of a version directory installed in a network element device according to Embodiment 2 of the present invention;

[0017] Figure 3 This is a schematic diagram of a version directory currently activated and running in the memory of a network element device according to Embodiment 2 of the present invention;

[0018] Figure 4 A schematic diagram of a version directory in the memory of a network element device after activating a cold patch package according to Embodiment 2 of the present invention;

[0019] Figure 5 This is a schematic diagram of configuration information of boards in each slot according to the second embodiment of the present invention;

[0020] Figure 6 A detailed flow chart of a single board upgrade method according to Embodiment 2 of the present invention;

[0021] Figure 7 This is a schematic diagram of a process of obtaining and installing a cold patch according to Embodiment 2 of the present invention;

[0022] Figure 8 A schematic diagram of the relationship between service protection groups in the boards in each slot according to the second embodiment of the present invention;

[0023] Fig. 9 This is a schematic diagram of the single board upgrade priority configuration in each slot of the second embodiment of the present invention;

[0024] Fig.10 A schematic diagram of calculating the remaining estimated time according to the second embodiment of the present invention;

[0025] Fig.11 This is a schematic diagram of displaying the upgrade progress at startup of the second embodiment of the present invention;

[0026] Fig.12 This is a schematic diagram showing the upgrade progress during the upgrade of the second embodiment of the present invention;

[0027] Fig.13 This is a schematic diagram showing the upgrade progress after the upgrade is completed in the second embodiment of the present invention;

[0028] Fig.14 This is a schematic diagram of the structure of a single-board device according to Embodiment 3 of the present invention. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the following is a further detailed description of the embodiments of the present invention through specific implementation methods combined with the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0030] Embodiment 1:

[0031] In order to reduce the complexity of the operation when upgrading the single board. The embodiment of the present invention provides a single board upgrade method, see Figure 1 ,include:

[0032] S101, activating the obtained patch package;

[0033] It should be noted that the patch package in this embodiment may also include but is not limited to an incremental package and a full package in other implementations, or other patch packages that can be upgraded using the single board upgrade method of this embodiment.

[0034] The patch package may be downloaded in advance, and the patch package includes a software package that can be used to upgrade the version software running in some or all boards in the single-board device. As a specific example, the patch package can be stored in the hard disk of the main control board. In this example, the directory into which the patch package is transferred is an independent directory, which is parallel to the storage directory of the basic version package; in some embodiments, if there is a backup machine (i.e., a backup main control board), the patch package file can be synchronized between the main control board and the backup main control board to ensure that the patch package can still take effect normally after the main and backup switchover.

[0035] It should be noted that the activation of the patch package in this embodiment refers to replacing the files of the version package that is effective in the system of the current single-board device with the files in the patch package. In a specific example, the replacement refers to the soft linking of the version files expected to be effective in the current system to the files in the patch package, that is, the activation operation is only to soft link all the version files on the version server to the files in the patch package. It should be understood that after the patch package is activated, it is not actually updated into the corresponding single board. After the patch package is activated, it is usually necessary to reset and restart the single board. During the reset and restart process of the single board, the currently activated version file will be requested to be loaded. At this time, the files in the activated patch package are loaded by the single board, and the update of the patch package is equivalent to the actual application.

[0036] S102, parsing the patch package to obtain the board parameters corresponding to the patch package;

[0037] In actual applications, the patch package may carry a configuration file, and parsing the patch package may include reading the configuration information in the configuration file. By parsing the patch package, the single board parameters can be obtained. In this embodiment, the single board parameters can reflect the information of the single board targeted by this patch package. For example, the single board parameters include but are not limited to the CPU (central processing unit) model of the single board.

[0038] S103, confirming the setting slot of the board to be upgraded corresponding to the patch package according to the board parameters;

[0039] In actual applications, the slot configuration of the single board is recorded. For example, the information of the single board set in each cabinet frame slot can be obtained by reading the cabinet frame slot static configuration information of the single board. By parsing the single board parameters obtained by the patch package, the single board matching the single board parameters and the slot information set therein can be found from the cabinet frame slot static configuration. In this embodiment, these single boards are the single boards to be upgraded corresponding to the patch package. Exemplarily, the single board parameters are the CPU models of the single board. The single boards using these CPU models are found from the cabinet frame slot static configuration, and the slots set therein are known.

[0040] S104. Upgrade the board to be upgraded according to the set slot.

[0041] Under normal circumstances, the patch package file can be loaded and upgraded by resetting and restarting the single boards to be upgraded. In this embodiment, the single board to be upgraded can be reset and restarted by issuing an instruction to it. Since the single board to be upgraded and the slots thereof have been confirmed in the aforementioned step S103, accurate upgrade control can be achieved in this embodiment, and only the single boards in these slots (i.e., the single boards to be upgraded) can be issued reset and restart instructions for upgrading.

[0042] It should be understood that the single-board upgrade method of the embodiment of the present invention can be applied to other control modules including but not limited to the main control board or single-board equipment or devices dedicated to upgrading single-board equipment. In the process of single-board upgrade, the single-board parameters are obtained by parsing the patch package, and the setting slot of the single board to be upgraded corresponding to the patch package is confirmed, and the single board in the slot is upgraded. In some implementation processes, automatic and accurate identification and upgrade control of the effective scope of the patch package can be achieved, thereby reducing the operating work of on-site upgrade operators and improving the degree of automation of patch package upgrades.

[0043] In some implementations, upgrading the board to be upgraded includes:

[0044] If the update files in the patch package do not include update files other than process update files, that is, the upgrade only involves process files in the single board to be upgraded, the single board to be upgraded may not be restarted, and only the process or virtual process group corresponding to the upgrade in the single board to be upgraded may be restarted to complete the upgrade. If the update files in the patch package include files other than corresponding process files, the single board to be upgraded may be reset and restarted to complete the upgrade. It should be noted that the process update files referred to here are update files related only to the processes in the single board to be upgraded. The upgrade here refers to the upgrade in a patch package, that is, all the upgrade files in a patch package are for the upgrade of process files in the single board to be upgraded, and only the corresponding processes may be restarted. Similar to the way the single board to be upgraded is restarted, the process in the single board to be upgraded may be restarted and upgraded by issuing a process restart instruction. During the restart of the process, the activated related process files are reloaded, and the process update files in the update files are loaded and activated in this process. If the upgrade not only involves the replacement of process files (replacement with process update files), but also involves some resource files in XML (Extensible Markup Language) format, then simply restarting the process or virtual process group cannot fully achieve the upgrade, and the board to be upgraded should be restarted.

[0045] In some implementations, restarting the process or virtual process group corresponding to the upgrade in the board to be upgraded to complete the upgrade includes:

[0046] Get the configuration information in the patch package;

[0047] Confirm the process file name involved in the upgrade based on the configuration information;

[0048] After obtaining the process file in the patch package, the board to be upgraded restarts the corresponding process or virtual process group.

[0049] In one example, the configuration file in the patch package is read, and from the configuration file it can be confirmed which process files the patch package specifically involves. After the single board obtains the corresponding upgraded process files in the patch package, these processes or virtual process groups can be restarted through corresponding instructions.

[0050] In this embodiment, the virtual process group can also be restarted. In actual applications, whether to restart the process or the virtual process group can be flexibly selected. For example, in one example, if multiple processes in a virtual process group need to be updated, you can choose to directly restart all virtual process groups. At this time, you only need to send an instruction to restart the virtual process group, avoiding sending a restart instruction for each process that needs to be updated in the virtual process group.

[0051] Due to the analysis of the files in the patch package, not only can the upgrade board involved in the upgrade be confirmed, but also the related processes involved in the upgrade can be accurately identified in some implementation processes. Therefore, in these scenarios, when the upgrade only involves the process files in the upgrade board, the upgrade process of the upgrade board can be completed only by restarting the process or virtual process group, achieving a smaller upgrade granularity and improving the upgrade efficiency. In addition, during the restart of the process or virtual process group, there may still be non-upgraded processes or virtual process groups in the upgrade board that can run normally, which is conducive to reducing the impact of the upgrade process.

[0052] In some implementations, before activating the acquired patch package, the process further includes:

[0053] When it is verified that the current board configuration does not meet the lossless upgrade conditions, the user is prompted that the current board configuration does not meet the lossless upgrade conditions;

[0054] If it is verified that the current board configuration meets the lossless upgrade conditions, or if a continue upgrade instruction is received from the user after prompting the user that the current board configuration does not meet the lossless upgrade conditions, the board to be upgraded will continue to be upgraded; if no continue upgrade instruction is received, the board to be upgraded will not be upgraded.

[0055] It is understandable that after receiving a prompt that the current single-board configuration does not meet the conditions for lossless upgrade, the user can choose to issue a continue upgrade instruction (for example, the user believes that the impact of the current upgrade on the business is within an acceptable range). At this time, if the upgrade continues, it may cause business loss or interruption during the upgrade process. In some scenarios, the user can also choose to adjust the configuration of the single board after receiving a prompt that the current single-board configuration does not meet the conditions for lossless upgrade, adjust the single-board configuration to a state that can achieve lossless upgrade, and then perform the upgrade operation again, at which time it can pass the verification and start the subsequent upgrade process.

[0056] In some implementations, the lossless upgrade conditions include:

[0057] Each service-carrying single board to be upgraded has a master-slave single board relationship and / or a protection group relationship;

[0058] Patches for the boards to be upgraded include:

[0059] Generate upgrade priority according to the relationship between the master and standby boards and / or the relationship between the protection groups;

[0060] The boards to be upgraded are upgraded in descending order of upgrade priority, and services are performed by boards that are not currently being upgraded during the upgrade process;

[0061] If the main control board needs to be upgraded, the upgrade priority of the main control board is the highest priority, and the upgrade priority of the standby main control board is second only to the main control board;

[0062] If the non-main control board needs to be upgraded, an upgrade priority is generated for the non-main control board based on the protection group relationship, and at least two of the non-main control boards with a direct protection group relationship are set to different upgrade priorities;

[0063] The services currently executed by the board that is not being upgraded include at least one of the following:

[0064] There is currently no service corresponding to the board being upgraded;

[0065] The services corresponding to the boards being upgraded that have a master-slave board relationship and / or a protection group relationship with the boards not currently being upgraded.

[0066] In practical applications, whether lossless upgrade is possible mainly considers the single board to be upgraded that currently has business. Therefore, in some implementations, it is judged whether each single board to be upgraded that has business can be temporarily or completely replaced, for example, there is a spare single board and / or there is a protection group relationship with other single boards. It can be seen that the single board to be upgraded in this embodiment can be a main control single board (including a spare main control single board) and a non-main control single board. It should be noted that the lossless upgrade condition referred to in this embodiment is only a preset judgment condition that may achieve lossless or low-loss upgrade, but in practical applications, meeting the lossless upgrade condition does not mean that lossless upgrade is necessarily possible. For example, although some single boards to be upgraded have a protection group relationship, the protection group relationship only covers some of the business, and some of the business does not have an effective protection group relationship (that is, some business cannot be replaced); or there may be unpredictable effects during the upgrade process. In some other implementations, the lossless upgrade condition can also be adjusted to other conditions according to actual conditions, and is not limited to those shown in this embodiment.

[0067] Meanwhile, in the above-mentioned upgrading process, services are executed by boards that are not currently being upgraded, including not only boards to be upgraded that have not yet been upgraded, but also boards that are not being upgraded this time can continue to execute corresponding services under certain conditions.

[0068] If there is a spare single board relationship, such as a main control single board and a spare main control single board, the two are set to different upgrade priorities; if there is a direct protection group relationship between the single boards to be upgraded, these single boards to be upgraded are not all of the same upgrade priority. In this embodiment, the single boards to be upgraded with the same upgrade priority are restarted and reset at the same time. After the upgrade of the single boards to be upgraded with the current upgrade priority is completed, the upgrade operation of the single boards to be upgraded with the next upgrade priority is performed in sequence. By dividing the upgrade priority, the execution of the upgrade can be carried out in batches. It can be understood that when the single boards are upgraded in batches, the single boards that have not been upgraded can continue to execute their configured services if necessary, which reduces the impact of the upgrade on the business to a certain extent. At the same time, by setting at least two of the single boards in the main-backup relationship or the non-main control single boards with a direct protection group relationship to different upgrade priorities, at least a part of the business or function can always keep working during the upgrade process, further reducing the impact on the business, and when the single board configuration is reasonable, lossless upgrade can be achieved. As an example, when the main control board and the standby main control board are upgraded, one of them (such as the standby main control board) is upgraded first. During the upgrade process, the one that has not been upgraded continues to perform the main control. After the upgrade of the board that was upgraded first is completed, the board that has completed the upgrade is the main control, and the other board starts to be upgraded. In this process, there is always a function of the board executing the main control, and the business is not affected. Of course, as an example, the main control board and the standby main control board can be set to the same upgrade priority (the highest upgrade priority), but during the upgrade process, the main control board and the standby main control board are specially processed and upgraded in the order of the previous example. It can be understood that in this example, although the main control board and the standby main control board can be set to the highest priority in parameter setting, the standby main control board is still upgraded first in actual processing, that is, the actual upgrade priority of the standby main control board is still the highest. It can be seen that the upgrade priority mentioned in this application should not be limited to the data such as software parameters configured during the implementation process, but should consider the order in which the upgrade is actually performed.

[0069] In some implementations, upgrading the board to be upgraded further includes:

[0070] If the upgrade of the board to be upgraded fails during the upgrade process, a prompt will be issued to the user;

[0071] After the user is prompted that the upgrade of the board to be upgraded has failed, when an instruction to continue the upgrade is received, the patch upgrade will continue. If no instruction to continue the upgrade is received, the upgraded board will be rolled back to the state before the upgrade. It should be noted that the above-mentioned lossless upgrade process is a process of upgrading after verifying that the current board configuration meets the lossless upgrade conditions. Due to the existence of the master-slave board and / or protection group relationship, the user can choose whether to continue the upgrade. For example, the user believes that the impact caused by the failure of the current upgrade of the board to be upgraded is acceptable. Of course, the user can also choose not to continue the upgrade. If no instruction to continue the upgrade is received, the upgrade will be stopped and the upgraded board will be rolled back to the state before the upgrade. The upgrade can be performed again after the problem that causes the upgrade failure of the board to be upgraded is resolved.

[0072] In some implementations, the progress of the upgrade is displayed. For example, the progress can be displayed after receiving the user's instructions, and by presenting the progress of the upgrade process and / or the expected remaining time for the upgrade, etc., the upgrade operation can be visualized, the user's expectations of the upgrade results can be improved, and the experience during the upgrade process can be improved. As a more specific example, the displayed content may include but is not limited to: the upgraded version, the upgrade start time, the upgrade end time, the remaining estimated time, and the upgrade status of each batch of upgrade priority boards (waiting for upgrade, upgrading, upgrade completed, and upgrade success or upgrade failure, etc.).

[0073] In some implementations, before the upgrade of the patch package is completed, the access of new services is stopped. The upgrade of the patch package referred to here refers to the upgrade of all boards to be upgraded involved in the patch package. If the boards to be upgraded have upgrade priorities, the upgrade of the patch package is completed after all boards to be upgraded with upgrade priorities have completed the update. Avoid access to new services during the upgrade process, thereby ensuring the stability of the upgrade process and avoiding interruption of newly accessed services or interruption of existing services.

[0074] The single board upgrade method provided by the embodiment of the present invention activates the acquired patch package, parses the patch package to obtain the single board parameters corresponding to the patch package, and confirms the setting slot of the single board to be upgraded corresponding to the patch package according to the single board parameters, and upgrades the single board to be upgraded; accurately identifies the effective scope of the patch package and executes the upgrade operation, thereby improving the automation level of the patch package upgrade and reducing the operation work of on-site upgrade operators.

[0075] Furthermore, in some implementations, the processes involved in the upgrade can be identified, and only the processes or virtual process groups are restarted, thereby achieving a smaller upgrade granularity, improving the efficiency of the upgrade, and helping to reduce the impact during the upgrade process.

[0076] Furthermore, in some implementations, upgrades can be performed in batches by dividing upgrade priorities, thereby achieving lossless or low-loss upgrades with a high degree of automation.

[0077] Embodiment 2:

[0078] In order to better illustrate the single-board upgrade method of an embodiment of the present invention, a specific lossless automatic upgrade process is taken as an example for further explanation in this embodiment. In the example of this embodiment, the patch package is a cold patch package (hereinafter referred to as a cold patch), and the single-board device is a network element (or network element device).

[0079] See also Figure 2 , indicating the directory in the network element. The versions installed in the network element include: network element basic version (baseset1, baseset2) and cold patch version (coldpatch). Among them, the network element basic version is the basis for the operation of the network element system; the cold patch version is used to repair some functions of the network element running software version, and must be reloaded to take effect; Figure 2 As shown, the cold patch version directory is a parallel directory with the network element basic version directory, but the cold patch depends on a specific network element basic version, and the cold patch must match the network element basic version to take effect.

[0080] See also Figure 3 , indicating the files in the version directory used in the network element memory when the current network element is activated and runs the basic version package baseset1. This directory is a soft link to the basic version package baseset1 in the hard disk directory.

[0081] See also Figure 4 , indicating the files in the version directory used in the network element memory when the cold patch coldpatch is activated in the current network element. At this time, the files in this directory with the same name as the cold patch directory are all soft links to the cold patch coldpatch in the hard disk.

[0082] See also Figure 5 In the embodiment of the present invention, the boards actually running in each slot in the network element, except for the main control board which is the default configuration of the minimum version of the basic version, all other boards are configured by the user. From the configuration, it can be seen that the unique information such as the CPU model of the physical board actually running in each slot.

[0083] See also Figure 6 In the example of this embodiment, the single board upgrade method includes:

[0084] S201, obtain and install cold patches;

[0085] See also Figure 7 Step S201 may include:

[0086] S2011. Build a cold patch and configure the version information corresponding to the cold patch;

[0087] The cold patch may be produced offline locally. The production of the cold patch includes but is not limited to the following key information:

[0088] Network element basic version information, which can be used to match cold patches to take effect in a specified basic version;

[0089] Board CPU model information, which can be used to match cold patches to take effect on a specific board;

[0090] In this embodiment, the cold patch applied to the network element may be a patch package containing multiple single patches, or may be a single patch. Different CPU types correspond to different single patches.

[0091] S2012, verify the version information of the cold patch, if the verification is successful, execute step S2013;

[0092] S2013, download and install cold patches;

[0093] After the cold patch is produced locally, it is loaded in the current network element environment through the network element version installation operation. Before loading the cold patch, the legality of the cold patch needs to be verified, mainly including: whether there is a cold patch with the same name in the current system, whether the cold patch format is legal, etc.

[0094] When a cold patch is loaded into a network element, it is not required that the basic version that the cold patch depends on must exist or be running in the network element. In theory, a cold patch is also a special version, but the activation of the cold patch must require that the basic version that the cold patch depends on must be in a running state.

[0095] Exemplarily, after the cold patch is installed, a subsequent lossless upgrade can be triggered by an instruction, and after the triggering, an automated upgrade operation can be performed.

[0096] S202, check whether the lossless upgrade condition is met, if not, execute step S203, if yes, execute step S204;

[0097] In this example, the main verification contents include: for cold patch upgrades involving the main control board, whether there is a standby main control board that is operating normally; for cold patch upgrades involving ordinary boards (non-main control boards), whether there is a protection group relationship or a similar protection group relationship for the boards to be upgraded of the same CPU type. If, when a cold patch upgrade of the main control board is involved, there is a standby main control board that is operating normally; and when a cold patch upgrade of ordinary boards is involved, a protection group relationship or a similar protection group relationship exists for the ordinary boards, then the lossless upgrade conditions are met. If the board to be upgraded does not meet the above conditions, the upgrade priority of the board to be upgraded is an invalid priority (in some implementation processes, these invalid priorities can be configured as the lowest priority by default). It should also be noted that, in some implementation processes, the upgrade priority of a board to be upgraded that currently has no business can also be set to an invalid priority.

[0098] S203, popping up a prompt to the user that the current board configuration does not meet the lossless upgrade conditions;

[0099] If the user confirms that the same batch of upgraded boards with invalid priority levels have no impact or are acceptable, the user can choose to continue upgrading. If a continue upgrading instruction from the user is received, the upgrade is continued and step S204 is executed.

[0100] S204, activating the obtained cold patch;

[0101] It is understandable that cold patch activation is a separate process. It is understandable that cold patch activation is just an update of the soft link of the hard disk version running file.

[0102] It should be noted that if the cold patch modification is relatively large, there may be compatibility issues between the basic version and the cold patch version. At the same time, since the lossless upgrade of the cold patch in this example is carried out in batches according to the upgrade priority order of the boards to be upgraded in the network element, or there are boards that do not need to be upgraded with cold patches, these situations lead to the coexistence of boards running the basic version and boards running the basic version + cold patch. At this time, the incompatible cold patch should include a compatible list whitelist of cross-version messages (i.e., a list of cross-version message IDs and the correspondence between the old and new structures of the message) to ensure that during the upgrade process, the boards running in the entire network element can perform message compatibility processing according to the compatible list whitelist. At this time, it should be checked whether there is a compatible list for the cold patch. If so, the compatible list should be first sent to each board of the network element for each board to perform compatible processing of the compatible list whitelist.

[0103] S205, parsing the cold patch, obtaining the CPU model of the board corresponding to the cold patch; S206, obtaining the static configuration of the cabinet slot of the board in the network element, confirming which slot boards are involved in the cold patch and setting the slots;

[0104] According to the CPU model of the single board obtained in the above step S205 and the record in the static configuration of the cabinet frame slot, it is possible to know which slot single boards are involved in the cold patch and the setting slots.

[0105] S207, generating an upgrade priority;

[0106] To better understand how the upgrade priority is set in this example. Figure 8 As shown, in the network element environment, the main control board and the backup main control board are operating normally in their respective positions, and the main control board is the hub for communication with each board. Due to the special existence of the main control board, the main control board and the backup main control board should be upgraded first. In this example, the backup main control board is upgraded first. After the master-slave switch (that is, the master-slave relationship of the main control board and the backup main control board is swapped), the original main control board is upgraded. It should be noted that after the master-slave switch, the cold patch files between the main control board and the backup main control board can be synchronized to ensure that the cold patch can still take effect normally after the master-slave switch. For example, a numerical value can be set to represent the upgrade priority. For example, the numerical range is 0-255. In this example, the smaller the value, the higher the upgrade priority, that is, the earlier the upgrade operation is performed. In one example, the upgrade priority of the main control board can be set to 0 by default, and the upgrade of the main control board and the backup main control board can be completed in the above manner. The range of ordinary non-main control boards is selected between 1-254. For boards with no business or boards with business but no business protection group relationship configured, the upgrade priority can be set to 255 by default.

[0107] Figure 8 In the example, service A on the board in slot 1 is in a protection group with service A on the board in slot 5, service B on the board in slot 3 is in a protection group with service B on the board in slot 5, and service C on the board in slot 3 is in a protection group with service C on the board in slot 7. The three are in a direct protection group relationship. Multiple boards that are in a direct protection group relationship cannot all be configured to use the same upgrade priority. If there is no direct protection group relationship between the boards, they can be configured to use the same upgrade priority. In actual applications, considering that batches with different upgrade priorities are completely upgraded serially, in order to ensure that the upgrade is completed as soon as possible, the number of configured upgrade priorities can be kept to a minimum.

[0108] In this example, the boards in slots 1 and 5 are not configured with the same upgrade priority, the boards in slots 3 and 7 are not configured with the same upgrade priority, and the boards in slots 3 and 5 are not configured with the same upgrade priority. Therefore, when there is such a protection group relationship in the service, the calculated upgrade priority result can be that when the priority of the board in slot 1 is 1, the priority of the board in slot 5 in the direct protection group relationship is 2. Since the boards in slots 3 and 5 are also in the direct protection group relationship, the board in slot 3 cannot be configured as 2. In order to ensure the minimum number of configuration upgrade priorities, it is configured as 1 first. At this time, only the priority of the board in slot 7 is not configured. Since the board in slot 7 is only in the direct protection group relationship with the board in slot 3, the priority of the board in slot 7 is configured as 2 to meet the requirements. When the first batch of boards in slots 1 and 3 are reset and upgraded at the same time, services A, B, and C can run normally on the boards in slots 5 and 7 without interruption. After the cold patch upgrade of the boards in slots 1 and 3 is started, the second batch of boards in slots 5 and 7 are reset and upgraded. Services A, B, and C can run normally on the boards in slots 1 and 3 without interruption. It can be seen that the upgrade is carried out in batches according to the above upgrade priorities, realizing lossless upgrade.

[0109] It should be noted that in lossless upgrade scenarios based on protection group relationships or master-slave relationships similar to this example, the upgrade priority is dynamically calculated based on actual conditions, and generally no static configuration is performed in advance or the upgrade priority is written to disk.

[0110] S208, completing the upgrade in descending order of upgrade priority;

[0111] See also Fig. 9 In this embodiment, when the network element is running with services, the upgrade priority configuration of each board can be viewed. The upgrade priority of each slot is dynamically calculated based on the protection group relationship of the service. Generally, it is not statically configured, and the dynamically calculated upgrade priority of each slot cannot be written to the disk. The upgrade priority generated by each slot based on the protection group relationship is a necessary condition for cold patch lossless upgrade. For boards without services, the default upgrade priority is configured as 255 by default, but this default priority may also be that the board has services but no service protection group relationship is configured. In this case, when performing a cold patch upgrade, if the upgrade priorities of all boards involved in the upgrade are not all valid, the one-click upgrade will prompt. If the user confirms that the same batch of reset upgrades of these boards with invalid priorities have no impact or are acceptable with minimal impact, the user can also choose to continue the upgrade.

[0112] If the upgrade of the main control board is involved, the main control board and the standby main control board are upgraded according to the strategy in S207. The remaining boards to be upgraded are upgraded in batches according to the upgrade priority, and multiple boards to be upgraded with the same batch upgrade priority are upgraded simultaneously.

[0113] When upgrading a cold patch of a non-main control board, it is also possible to determine whether the files in the cold patch are only files of process software (i.e., whether this update only involves processes). For example, the determination method in this example is to check whether the suffixes of the cold patch files are all so type files (or other file types with other process characteristics).

[0114] If the current cold patches are all process cold patches, then the cold patch upgrade of the non-master control board can be achieved simply by reloading the corresponding process. For example, a specific processing method may include: reading the configuration file in the cold patch file, confirming the specific process file name involved in the cold patch, and then obtaining the slots of the boards to be upgraded in the batch with the smallest upgrade priority, and sending process upgrade notification messages to these boards to be upgraded. The message content carries a list of process files that need to be requested. After the boards to be upgraded receive the notification messages, the boards to be upgraded download the corresponding process files to the local computer via the File Transfer Protocol (FTP) or other transfer protocols. After the boards to be upgraded successfully download, they each respond to the master control board. After receiving the responses, the master control board sends the designated process restart message corresponding to the boards to be upgraded, and the boards to be upgraded perform process restart actions. Furthermore, if the cold patch involves many processes, these processes logically belong to one or several virtual process groups. At this time, after the main control board receives the successful response of the cold patch file download of the board to be upgraded, the main control board can send a message to restart the virtual process group corresponding to the board to be upgraded, without sending process restart messages to multiple processes in the same virtual process group separately.

[0115] It can be seen that the upgrade in this step includes not only resetting the single board to complete the upgrade, but also reloading only some or all processes and virtual process groups in the single board to complete the upgrade. In actual applications, at least part of the above steps S202 to S208 can be automatically executed, and the effective range of the cold patch can be automatically identified to perform precise control. The user only needs to make decisions based on the prompts and issue simple instructions, which greatly simplifies the operation of on-site upgrades and reduces the requirements for on-site upgrade personnel.

[0116] When the main control board confirms that all the boards to be upgraded in the current upgrade priority batch have restarted normally, the main control board will start processing the next upgrade priority batch until all the upgrade priority batches have been processed. Alternatively, when the main control board receives the process restart response message of all the boards to be upgraded in the current upgrade priority batch, and all the processes have restarted normally, the main control board will start processing the next upgrade priority batch until all the upgrade priority batches have been processed. When all the upgrade priority batches have been processed, the upgrade of the patch package is completed.

[0117] In this example, if the upgrade of individual boards fails, due to the existence of protection group relationships, users can choose whether to continue the upgrade or avoid affecting the business without loss or must complete the upgrade according to the current upgrade strategy. If no instruction to continue the upgrade is received, the upgrade rollback can be triggered and the upgrade can be continued after the problem is resolved. In addition, after the cold patch upgrade is started, new business access is generally blocked or prohibited, otherwise the new access business or the original business may be interrupted during the upgrade process. During the upgrade process, priority is given to ensuring that the current business is not interrupted.

[0118] In actual applications, since the upgrade process is generally quite long (tens of minutes or longer), you can also choose to add a display of the upgrade progress during the upgrade process to visualize the upgrade operation and improve the user's expectations of the upgrade results. The following example illustrates the display of the upgrade progress.

[0119] In this example, the user can be provided with commands such as "show" to display the upgrade progress. The upgrade progress display content includes but is not limited to: the upgraded version, upgrade start time, upgrade end time, remaining estimated time, and upgrade status of each batch of upgrade priority boards (waiting for upgrade, upgrading, upgrade completed, and upgrade success or upgrade failure, etc.). Except for the remaining estimated time, the other contents are real-time results of the actual stage of the upgrade. The remaining estimated time is an estimated time.

[0120] like Fig.10 , the actual operation process of the remaining estimated time algorithm is illustrated and the upgrade process is divided into several key stages. Each stage is configured with an estimated time by default. Specifically, there may be multiple boards for the same batch priority upgrade. The board with the largest estimated time value can be taken. Therefore, after the upgrade process is subdivided, the overall remaining estimated time has a benchmark estimated time: the estimated time of each stage involved in this upgrade + the estimated time of each batch upgrade priority upgrade. However, this empirical value may differ in different business models or scenarios. To be more precise, a learning and adjustment process for network element upgrade time consumption can be introduced. During the actual upgrade process, the actual time consumption is calculated after each stage of upgrade and compared with the estimated time consumption of the current stage (if the estimated time consumption is longer than the actual time consumption, the estimated overall time consumption displayed to the outside is subtracted from the deviation value; otherwise, the deviation value is increased). In this way, the overall remaining estimated time displayed to the outside can be dynamically adjusted. At the same time, the actual upgrade time consumption of each stage is written into the database. During the next upgrade, the estimated time consumption in the database is read first as the estimation benchmark (the database does not exist for the first upgrade or only the estimated time consumption is recorded in the database. At this time, only the estimated time consumption configured by default for each stage can be used). In this way, the remaining estimated time will be more accurate.

[0121] As a specific example, the current upgrade process indicates that there are 6 stages, and the estimated time consumption of each stage has a default configuration. The cumulative value of the estimated time consumption of the 6 stages is equal to 78 minutes (minutes), which is used as the initial time for displaying the remaining estimated time when the upgrade is started. When the first stage is actually upgraded, the actual time consumption is 12 minutes. Since the remaining estimated time displayed to the outside is decreasing in real time during the upgrade process, when the actual upgrade of this stage is completed, the remaining estimated time displayed is 78-12=66 minutes, but the estimated time consumption of this stage is 15 minutes. Therefore, after the upgrade of this stage is completed, the next stage begins, and the remaining estimated time presented to the outside needs to compensate for the deviation value (addition or subtraction compensation). Since the estimated time consumption of this stage is greater than the actual time consumption, the remaining estimated time needs to be subtracted from the deviation value of the estimated time consumption of this stage, 66-3=63 minutes. At this time, the display of the remaining estimated time will jump directly from 66 minutes to 63 minutes, without the process of time decreasing.

[0122] Similarly, the second stage starts with the remaining estimated time of 63 minutes after the correction in the first stage as the benchmark. It can be seen from the example that the estimated time in the second stage is less than the actual time, and the deviation value is 5 minutes. However, since the external time display is decreasing in real time, the remaining estimated time just after the end of the second stage, decreases to 63-25=38 minutes. However, after the deviation of the estimated time of this stage is compensated after the end of the second stage, the remaining estimated time jumps, and the remaining estimated time adjusted externally is 38+5=43 minutes.

[0123] The same goes for other stages. After the upgrade is completed, the remaining estimated time will be adjusted to 0 minutes, indicating that the current upgrade has ended.

[0124] See also Fig.11 As shown, an example of displaying the upgrade progress added during the upgrade process is schematically illustrated, so as to visualize the upgrade operation and enhance the user's psychological expectation of the upgrade result. By providing the user with a command for displaying the upgrade progress (such as the "show" command in the aforementioned example), the upgrade progress display content includes but is not limited to: the upgraded version, the upgrade start time, the upgrade end time, the remaining estimated time, and the upgrade status of each batch of upgrade priority boards (waiting for upgrade, upgrading, upgrade completed, and upgrade success or upgrade failure, etc.).

[0125] Should Fig.11It shows the status at the beginning of the upgrade. The current upgrade end time is unknown and is not displayed. The boards to be upgraded with cold patches are displayed in rows according to the upgrade priority. The upgrade status of the priority batches that have been upgraded is displayed as Upgrading, and the upgrade status of the priority batches that have not been upgraded is displayed as Wait-Upgrade. At the same time, it can be seen that the upgrade priority of the main control board is the highest, and the upgrade priority of non-main control boards starts from 1.

[0126] It should also be noted that the upgrade status displayed during the cold patch upgrade process is only the upgrade status of the single board involved in the cold patch upgrade. If the single board involved in the cold patch package is not upgraded, it will not be displayed in the cold patch upgrade status.

[0127] like Fig.12 As shown, it indicates the status of the upgrade in progress. The boards that are currently being cold patched are displayed in separate rows according to the upgrade priority. The upgrade status of the priority batch that has completed the upgrade (Status column) is displayed as Upgraded, and the upgrade status of the priority batch that is being upgraded is displayed as Upgrading. The remaining estimated time is adjusted in real-time decreasing order. For the cold patch upgrade of ordinary boards, multiple boards of the same batch upgrade priority are upgraded at the same time, and the upgrade progress of the batch of boards is displayed as Upgrading. At the same time, the cold patch upgrade process displays the upgrade status of the upgrade that has been completed, including the individual upgrade status of each board of the batch upgrade priority. For example: the upgrade priority of the main control board (priority column) is 0, the main control board has primary and backup slots (slots of the main control board and the backup main control board), the upgrade result is that all upgrades are successful, and the Success column displays ALL, indicating that all upgrades are successful. The ordinary board upgrade priority is 1, including the boards in slots 1 and 3. At the same time, the batch priority has been upgraded, but the upgrade results of the boards in the batch priority may not be exactly the same, so it can be displayed separately that slot 1 is upgraded successfully and slot 3 fails to upgrade. If the upgrade of individual boards fails, at this time, due to the existence of the protection group, the user can choose whether to continue the upgrade or stop the upgrade to avoid affecting the business. If the upgrade is not continued, the upgrade rollback can be triggered, and the non-destructive or minimally damaged upgrade can be continued after the problem is resolved.

[0128] like Fig.13As shown in the figure, it shows the status when the upgrade is finished. The current upgrade end time has been displayed normally, and the estimated remaining time of the upgrade is also adjusted to 0min in real time. At this time, the cold patch upgrade status is all displayed as Upgraded, but the upgrade results are displayed separately in the Success and Fail columns. If the upgrade of individual boards fails, you can confirm the problem of the failed board and restore it separately.

[0129] Embodiment three:

[0130] This embodiment provides a single board device. Fig.14 As shown, it includes a processor 141, a memory 142 and a communication bus 143, wherein:

[0131] The communication bus 143 is used to realize the connection and communication between the processor 141 and the memory 142;

[0132] The processor 141 is used to execute one or more computer programs stored in the memory 142 to implement at least one step in the single board upgrade method in the above-mentioned embodiment 1 and embodiment 2.

[0133] The present embodiment also provides a computer-readable storage medium, which includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), DVD (Digital Versatile Disc) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0134] The computer-readable storage medium in this embodiment can be used to store one or more computer programs, and the one or more computer programs stored therein can be executed by a processor to implement at least one step of the single board upgrade method in the above-mentioned embodiment 1 and embodiment 2.

[0135] It can be seen that those skilled in the art should understand that all or some of the steps, systems, and functional modules / units in the above disclosed methods can be implemented as software (which can be implemented with computer program code executable by a computing device), firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component can have multiple functions, or a function or step can be performed by several physical components in cooperation. Some or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit.

[0136] In addition, it is well known to those skilled in the art that communication media generally contain computer readable instructions, data structures, computer program modules or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery media. Therefore, the present invention is not limited to any specific hardware and software combination.

[0137] The above contents are further detailed descriptions of the embodiments of the present invention in combination with specific implementation methods, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the scope of protection of the present invention.

Claims

1. A single board upgrade method, comprising: Activate the acquired patch package, wherein the patch package is a cold patch package; Parsing the patch package to obtain the board parameters corresponding to the patch package; According to the single board parameters, confirm the setting slot of the single board to be upgraded corresponding to the patch package; Upgrading the board to be upgraded according to the set slot; Wherein, upgrading the single board to be upgraded according to the set slot comprises: If the update files in the patch package do not include update files other than process update files, the single board to be upgraded will not be restarted, and the process or virtual process group corresponding to the upgrade in the single board to be upgraded will be restarted to complete the upgrade; if the update files in the patch package include update files other than process update files, the single board to be upgraded will be reset and restarted to complete the upgrade.

2. The single board upgrade method according to claim 1, characterized in that: The step of restarting the process or virtual process group corresponding to the upgrade in the single board to be upgraded to complete the upgrade includes: Obtaining configuration information in the patch package; Determine the process file name involved in the upgrade according to the configuration information; The single board to be upgraded is enabled to restart the corresponding process or virtual process group after obtaining the process file in the patch package.

3. The single board upgrade method according to claim 1, characterized in that: Before activating the acquired patch package, the method further includes: When it is verified that the current board configuration does not meet the lossless upgrade conditions, the user is prompted that the current board configuration does not meet the lossless upgrade conditions; If it is verified that the current single board configuration meets the lossless upgrade conditions, or if a continue upgrade instruction issued by the user is received after the user is prompted that the current single board configuration does not meet the lossless upgrade conditions, the single board to be upgraded will continue to be upgraded; if no continue upgrade instruction is received, the single board to be upgraded will not be upgraded.

4. The single board upgrade method according to claim 3, characterized in that: The lossless upgrade conditions include: The boards to be upgraded that have services are in a master-slave relationship and / or a protection group relationship; Upgrading the board to be upgraded includes: Generate an upgrade priority according to the master-slave board relationship and / or protection group relationship; The boards to be upgraded are upgraded in order from high to low according to the upgrade priorities, and during the upgrade process, services are executed by boards that are not currently being upgraded; If the main control board needs to be upgraded, the upgrade priority of the standby main control board is the highest priority, and the upgrade priority of the main control board is second only to the standby main control board; If the non-master board needs to be upgraded, an upgrade priority is generated for the non-master board based on the protection group relationship, and at least two of the non-master boards having a direct protection group relationship are set to different upgrade priorities; The service currently executed by the board that is not being upgraded includes at least one of the following: The service corresponding to the board that is not currently being upgraded; The service corresponding to the single board being upgraded that has a master-slave single board relationship and / or a protection group relationship with the single board that is not currently being upgraded.

5. The single board upgrade method according to claim 4, characterized in that: The upgrading of the single board to be upgraded further comprises: If the upgrade of the board to be upgraded fails during the lossless upgrade, a prompt will be issued to the user; After the user is prompted that the upgrade of the board to be upgraded has failed, if an instruction to continue upgrading is received, the patch upgrade is continued. If no instruction to continue upgrading is received, the upgraded board is rolled back to the state before the upgrade.

6. The single board upgrade method according to any one of claims 1 to 5, characterized in that: Also includes: Display the progress of the upgrade.

7. The single board upgrade method according to any one of claims 1 to 5, characterized in that: Also includes: Before completing the upgrade of the patch package, stop the access of new services.

8. A single-board device, comprising a processor, a memory and a communication bus; The communication bus is used to realize the connection and communication between the processor and the memory; The processor is used to execute one or more computer programs stored in the memory to implement the steps of the single board upgrading method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more computer programs, and the one or more computer programs can be executed by one or more processors to implement the steps of the single board upgrading method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • Hotfix implementation method for embedded system

    CN107766069A

  • A batch upgrading method and system of a multi-board device

    CN108958772A