Distributed system upgrading method, electronic equipment and readable medium

Abstract

The invention discloses a distributed system upgrading method, electronic equipment and a readable medium. The method comprises the following steps: unloading a process of an old version deployment unit DU; wherein the process of the old-version DU is the currently running process of the to-be-upgraded DU; loading the process of the new version DU; wherein the process of the new-version DU is a process expected to run by the to-be-upgraded DU. According to the technical scheme, reliable support is provided for rapid switching of the new version process and the old version process in the component upgrading process.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to an upgrade method for a distributed system, an electronic device, and a readable medium. Background Art

[0002] In a distributed system under a microservices architecture, business components are modularized, achieving isolation in business deployment, that is, having the ability to be independently installed, uninstalled, and upgraded, which greatly facilitates business function scaling, online business software upgrades, and business software fault repairs. Therefore, business componentization has gradually become the evolution direction of data communication systems. However, after business componentization, higher requirements are placed on the reliability of component upgrades in the distributed system. Summary of the Invention

[0003] The main purpose of the embodiments of this application is to propose an upgrade method for a distributed system, an electronic device, and a readable medium, which can improve the reliability of component upgrades.

[0004] In a first aspect, an embodiment of this application provides an upgrade method for a distributed system, which is applied to an agent side, and the method includes:

[0005] Uninstall the process of the old version deployment unit DU; wherein, the process of the old version DU is the process that the DU to be upgraded is currently running;

[0006] Load the process of the new version DU; wherein, the process of the new version DU is the process that the DU to be upgraded is expected to run.

[0007] In a second aspect, an embodiment of this application provides an upgrade method for a distributed system, which is applied to an agent side, and the method includes:

[0008] Uninstall the resources of the old version deployment unit DU;

[0009] Load the resources of the new version DU; wherein, the resources of the old version DU and the resources of the new version DU are both business operation and maintenance management interfaces for providing usage capabilities externally.

[0010] In a third aspect, an embodiment of this application provides an electronic device, including:

[0011] One or more processors;

[0012] A storage device, on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the upgrade method for the distributed system provided by the embodiments of this application;

[0013] One or more I / O interfaces, connected between the processor and the memory, configured to implement information interaction between the processor and the memory.

[0014] In a fourth aspect, an embodiment of the present application provides a storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the upgrade method of the distributed system provided by the embodiment of the present application.

[0015] For the upgrade method of the distributed system provided by the embodiment of the present application, the process of the old version DU is uninstalled first, and then the process of the new version DU is loaded, which shortens the power-on and power-off switching time of the old and new version processes during the upgrade process, and provides reliability support for the fast switching of the old and new version processes during the component upgrade process without interrupting the service.

[0016] The embodiment of the present application provides another upgrade method for the distributed system. Before uninstalling the process of the old version DU, the resources of the old version DU are uninstalled first; after loading the process of the new version DU, the resources of the new version DU are loaded. By introducing the steps of dynamic unloading and loading of resources, not only the upgrade of business characteristics is realized, but also the upgrade of the business OAM interface is realized, ensuring the integrity of component upgrade. Description of the Drawings

[0017] Figure 1 It is a relational diagram of the composition of component packages in an embodiment of the present application;

[0018] Figure 2 It is a constituent element diagram of a deployment unit in an embodiment of the present application;

[0019] Figure 3 It is an application scenario diagram of the upgrade method of the distributed system provided by the embodiment of the present application;

[0020] Figure 4 It is a flowchart of the upgrade method of the distributed system provided by the embodiment of the present application;

[0021] Figure 5 It is a flowchart of another upgrade method of the distributed system provided by the embodiment of the present application;

[0022] Figure 6 It is an installation schematic diagram of the deployment unit provided by the embodiment of the present application;

[0023] Figure 7 It is a flowchart of information interaction between the server, the proxy and the software repository during the component upgrade provided by the embodiment of the present application;

[0024] Figure 8 It is a flowchart of the proxy component upgrade method provided by the embodiment of the present application;

[0025] Figure 9 It is a block diagram of an electronic device provided by the embodiment of the present application. Detailed Embodiments

[0026] To enable those skilled in the art to better understand the technical solutions of this application, the server provided by this application will be described in detail below with reference to the accompanying drawings.

[0027] In the following, example embodiments will be described more fully with reference to the accompanying drawings. However, the example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. On the contrary, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of this application to those skilled in the art.

[0028] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0029] The terms used herein are only for describing specific embodiments and are not intended to limit this application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms unless the context clearly indicates otherwise. It will also be understood that when the terms "comprises" and / or "consists of" are used in this specification, the specified features, wholes, steps, operations, elements, and / or components are present, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their groups.

[0030] The embodiments described herein may be described with reference to plan views and / or cross-sectional views by means of ideal schematic diagrams of this application. Therefore, the example illustrations may be modified according to manufacturing techniques and / or tolerances. Therefore, the embodiments are not limited to the embodiments shown in the drawings, but include modifications of configurations formed based on manufacturing processes. Therefore, the regions illustrated in the drawings have schematic properties, and the shapes of the regions shown in the drawings illustrate the specific shapes of the regions of the elements, but are not intended to be restrictive.

[0031] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0032] The distributed system in the embodiments of this application may be a distributed system in the field of communication or a distributed system in other fields. From the perspective of user operations, the installation, uninstallation, and upgrade of components in a distributed system are usually at the granularity of component packages (also known as feature packages); from the perspective of internal implementation, the installation, uninstallation, and upgrade processing of components in a distributed system are at the granularity of deployment units (abbreviated as DUs).

[0033] Figure 1This is a relational diagram of the component packages in the embodiments of this application. As Figure 1 shown, the component package 10 includes one or more deployment units (DU for short) 20. For example, the ratio of the component package 10 to the DU 20 can be 1:M, and the DU 20 includes one or more closely related business components 30. For example, the ratio of the DU 20 to the business component 30 is 1:N, where both N and M are positive integers. A DU is a complete and independently deployable minimum unit and a complete deployment entity. Each DU is uniquely identified by a name and a version number.

[0034] As Figure 2 shown, logically, a DU includes component processes and their dependent files, and component operation administration and maintenance (OAM for short) resource files. Among them, the component processes and their dependent files include one or more business binary files, software development kit (SDK for short) files on which the process depends, and private resource files; the OAM resource files include cli files, netconf files, mib files, alarm files, etc.

[0035] In the embodiments of this application, the provider of the OAM resource files is called the resource publisher, and the user of the OAM resources is called the resource subscriber. The internal implementation process of component upgrade is based on the granularity of DUs. After the component process restarts, it supports lossless rebirth, that is, neighboring devices are not aware, the master control and service single boards of the local device do not restart, the forwarding plane does not lose packets or break the flow, the component service configuration is not lost, and the states of the upstream and downstream components remain consistent after restart.

[0036] Figure 3 This is an application scenario diagram of the distributed system upgrade method provided in the embodiments of this application. As Figure 3 shown, the distributed system corresponding to the component upgrade method includes a main processing unit (MPU for short) 1, a standby MPU 2, and one or more service single boards 3. The main MPU 1 is used for system-level control of in-service software upgrade (ISSU). The standby MPU 2 replaces the main MPU 1 to perform corresponding operations (such as performing a rollback operation) when the main MPU 1 fails (such as abnormal restart or power-off). The service single board 3 is used for forwarding services.

[0037] In some embodiments, the primary master controller 1 includes a Deployment Unit Management Server (DUM_SVR) 11 and a SoftWare Repository (SWR) 12. For the convenience of description, the Deployment Unit Management Server is abbreviated as the server. The server 11 is responsible for the system-level control of component upgrades, such as component upgrade control, rollback control, etc. When a user downloads a component package to the storage device of the distributed system and performs an operation of component installation or upgrade, the server 11 will trigger the SWR 12 to parse the descriptive configuration file in the component package, construct software deployment rules, and store them in the global database (DataBase, abbreviated as DB) 13 in the form of key-value, and provide a key-value query service. Among them, the key is used to represent the software deployment request conditions, that is, the query conditions of the software file list, such as the combination of multiple information such as the name of the DU, the resource type of the DU, the type of the central processing unit (CPU), and the logical type of the service board. The value is used to represent the software file list information.

[0038] The software repository 12 includes a global DB 13 and an FTP service 14. The global DB 13 is used to store software deployment rules, as well as the status information of component packages, the status information of DUs, the interaction information between the server and the proxy node, etc. The FTP service 14 is used to provide the cross-board download ability of files within the distributed system.

[0039] The service board 3 can generate software deployment request conditions according to its own needs. For example, by information such as the name of the DU, the CPU type, and the logical type of the service board, query or download the processes of the specified DU and their dependent files; or, by information such as the name of the DU and the resource type of the DU, query or download a certain type of resource file of the specified DU.

[0040] In some embodiments, the global DB 23 in the standby master controller 2 is used to mirror and back up the global DB 13 in the primary master controller 1, that is, the standby master controller 2 stores a copy of the data in the global DB 13 in the primary master controller 1 through primary and standby database synchronization.

[0041] The service board 3 includes a local DB 31 and a file system 32. Among them, the local DB 31 is used to store the status information of DUs and their resources on this node, as well as the resource subscription information registered by resource subscribers, etc. The status information of local DU resources includes but is not limited to resource name, resource location, resource status, etc. The resource status includes statuses such as waiting to be loaded, waiting to be unloaded, loaded, and unloaded. The file system 32 is used to manage the software file list downloaded to this node. During the component upgrade process, it is necessary to manage the software file lists of the old and new versions of the components. After the old version of the component is uninstalled, the corresponding software files and memory records can be deleted.

[0042] In some embodiments, each service board 3 corresponds to one or more Deployment Unit Management Agents (DUM_AGENT for short) 21. For ease of description, this application abbreviates the Deployment Unit Management Agent as the Agent. The Agent 21 is used for board-level control, including the orchestration and execution of the upgrade process on the node where it is located.

[0043] The server 11 and the Agent 21 complete the information interaction of the installation, uninstallation, and upgrade processes of the DU through the Pub / Sub mechanism and read / write interfaces of the global DB 13 on the primary master control 11. Between the Agent 21 and the resource subscribers on this node, the installation, uninstallation, and upgrade processes of the resources of the DU are completed through the Pub / Sub mechanism and read / write interfaces of the local DB 31.

[0044] In the embodiments of this application, the server 11 and the Agent 21 perform information interaction through the global DB 13, and the Agent and the resource subscribers on this node perform information interaction through the local DB 24, which can decouple the server and the Agent, and the Agent and the resource subscribers on this node.

[0045] During the upgrade process, the server and the Agent execute the upgrade steps provided in the embodiments of this application according to the actual situation, which can achieve the reliability of the upgrade. The following separately introduces the specific processes of the system upgrade of the server and the Agent.

[0046] First, the upgrade method of the distributed system provided in the embodiments of this application. Figure 4 It is the flowchart of the upgrade method of the distributed system provided in the embodiments of this application. As Figure 4 shown, for the upgrade method of the distributed system, which is applied to the Agent and includes:

[0047] Step S401, uninstall the process of the old version DU.

[0048] Among them, the process of the old version DU is the process that the DU to be upgraded is currently running.

[0049] It should be noted that in the embodiments of this application, the DU to be upgraded includes one or more processes. When including multiple processes, batch uninstallation of the old version processes and batch loading of the new version processes are supported.

[0050] In some embodiments, uninstalling the process of the old version DU includes: sending a power-down preprocessing message to the process of the old version DU; after receiving the confirmation messages returned by all the processes of the old version DU indicating that the power-down preprocessing is completed, perform power-down processing on the process of the old version DU.

[0051] To improve the reliability of the power-on and power-off switching of the old and new version processes, that is, to reduce the time-consuming of the process power-off and ensure data consistency, before uninstalling the process of the old version DU, the proxy first triggers power-off preprocessing, that is, sends a power-off preprocessing message to the process of the old version DU and waits for the confirmation message of the power-off preprocessing. After the proxy receives the response message indicating that the power-off preprocessing of all processes of the old version DU is completed, it performs power-off processing on the processes of the old version DU. It should be noted that if there are multiple processes of the old version DU, batch power-off processing can be performed on the processes of the old version DU.

[0052] In the embodiment of the present application during the DU upgrade process, power-off preprocessing is introduced. That is, the process of uninstalling the old version DU includes two steps: power-off preprocessing and power-off processing. Performing power-off preprocessing before power-off processing can shorten the power-on and power-off switching time of the old and new version processes, and at the same time ensure the consistency of the service process data, providing reliability support for realizing non-interruptible service upgrade.

[0053] In some embodiments, performing power-off preprocessing on the processes of the old version DU includes: after the key data of the service process is processed, clearing the critical area data; removing the non-critical message processing logic in the processes of the old version DU and only retaining the necessary keep-alive messages.

[0054] Among them, the critical area data refers to the data associated with the service process, and the critical area data includes one or more of service database control plane data, cross-process shared memory data, inter-process semaphores, and lock resources.

[0055] The non-critical message processing logic refers to the processing logic that has no impact on the rebirth of the service process, and the non-critical message processing logic includes: one or more of events for processing based on the synchronization status of the service database, status query messages between upstream and downstream services, user operation command events, and telemetry / alarm reporting events.

[0056] After clearing the critical area data and removing the non-critical messages, then performing batch power-off of the DU process can achieve the time performance and data reliability of the DU process power-off.

[0057] Step S402, loading the process of the new version DU.

[0058] Among them, the process of the new version DU is the process that the DU to be upgraded is expected to run.

[0059] The upgrade method of the distributed system provided by the embodiment of the present application first uninstalls the process of the old version DU and then loads the process of the new version DU, realizing the upgrade of service characteristics, and providing reliability support for non-interruption of services during the upgrade process by shortening the power-on and power-off switching time of the old and new version processes.

[0060] In some embodiments, before the process of uninstalling the old version of DU, it further includes: uninstalling the resources of the old version of DU; after the process of loading the new version of DU, it further includes: loading the resources of the new version of DU, that is, first uninstalling the resources of the old version of DU, and then uninstalling the process of the old version of DU; then, loading the process of the new version of DU, and then loading the resources of the new version of DU.

[0061] Among them, the resources of the old version of DU and the resources of the new version of DU are both operation administration and maintenance (OAM) interfaces for providing usage capabilities externally.

[0062] Before the process of uninstalling the old version of DU, uninstalling the resources of the old version of DU first avoids the impact of OAM services on the upgrade. After the process of loading the new version of DU, loading the resources of the new version of DU again does not require restarting the service single board or the resource subscriber process, realizing the dynamic loading and unloading of resources. While the service characteristics are upgraded, the upgrade of the service OAM interface is realized, ensuring the integrity of component upgrade.

[0063] In some embodiments, when uninstalling the resources of the old version of DU, if the DU to be upgraded is a resource publisher, the proxy triggers the resource subscribers on this node to uninstall all the resources published by the old version of DU. For the case where there are multiple resource subscribers for the DU to be upgraded, it is necessary to wait for all resource subscribers to complete the uninstallation and set the response result to the local DB. The proxy polls the local DB to check whether all resource subscribers have uninstalled the resources published by the old version of DU. If so, it executes the steps of the process of uninstalling the old version of DU; if not, it continues to wait. If the DU to be upgraded is a resource subscriber, the proxy traverses all the resources loaded by the old version of DU on this node and triggers the old version of DU to uninstall. After all the loaded resources are uninstalled, the proxy clears all the response information related to the old version of DU in the resource record and clears the resource subscription information. Then, it executes the steps of the process of uninstalling the old version of DU.

[0064] It should be noted that when uninstalling the resources of the old version of DU, it is necessary to determine whether the resource uninstallation process is triggered by the upgrade event of DU or the uninstallation event of DU to avoid resource subscribers accidentally deleting the service configuration data of DU.

[0065] In some embodiments, when loading the resources of the new version of the DU, if the DU to be upgraded is a resource publisher, the proxy triggers the resource subscribers on this node to load all types of resources published by the new version of the DU. For the case where there are multiple resource subscribers for the DU to be upgraded, it is necessary to wait for all resource subscribers to finish loading and set the response result to the local DB. If the DU to be upgraded is a resource subscriber, the proxy traverses all the relevant resources published on this node, triggers the new version of the DU to load, and waits for the response result of the resource loading. After the DU to be upgraded finishes loading the relevant resources published on this node, it is necessary to write the response result into the local DB. The proxy polls the local DB to check whether the DU to be upgraded has loaded all the resources published on this node. If so, it performs the step of deleting the software files of the old version of the DU and writes the local DU upgrade result into the global DB; if not, it continues to wait.

[0066] It should be noted that when loading the resources of the new version of the DU, it is necessary to distinguish whether the DU resource loading is triggered by the upgrade event of the DU or the installation event of the DU. If the DU resource loading is triggered by the upgrade of the DU, the resource subscriber needs to upgrade the data structure of its own DB table according to the resource model of the new version of the DU.

[0067] To avoid the impact of the time-consuming query or download of software files on component upgrade and reduce the business loss time during the DU upgrade, before uninstalling the resources of the old version of the DU, the proxy further includes: obtaining the software file list of the new version of the DU based on the software deployment request conditions; downloading the software files of the new version of the DU to the local based on the software file list. The software files of the new version of the DU include the process of the new version of the DU and its dependent files and resource files.

[0068] Among them, the software deployment request conditions are composed of the proxy according to multiple information such as the name of the DU to be upgraded, the resource type of the DU to be upgraded, the type of CPU, and the logical type of the service board.

[0069] After the proxy generates the software deployment request conditions, it queries the software file list of the new version of the DU through the global DB interface provided by the SWR and downloads the software files of the new version of the DU to the local through FTP. Among them, the software files of the new version of the DU include but are not limited to the process of the new version of the DU and its dependent files and resource files.

[0070] It should be noted that for the resource files of the new version of the DU, they are not simply all downloaded to the local. The proxy can download them to the local as needed according to the actual deployment situation of the resource subscribers on this node, which can save local storage resources and network resources.

[0071] In some embodiments, after the proxy triggers the completion of the resource loading of the new version of the DU, it further includes: deleting the software files of the old version of the DU.

[0072] When the proxy checks that the resources of the new version of DU have been loaded, it deletes the software files of the old version of DU stored locally to save local storage space.

[0073] In some embodiments, after the proxy triggers the completion of the resource loading of the new version of DU, it further includes: writing the local loading result of the DU to be upgraded into the global DB.

[0074] The proxy queries and summarizes the loading results of the processes and resources of the local DU, and writes the summary result into the global DB as the response result for the server to query the DU upgrade result.

[0075] In some embodiments, during the DU upgrade process in a distributed system, if exceptions such as the failure or timeout of the DU process loading / unloading or the failure or timeout of the DU resource loading / unloading occur, the server automatically triggers the rollback process of the DU upgrade for the entire system. In the case of DU upgrade failure, the server generates an operation queue for DU based on the description information of the old version component package, and the operation queue includes one or more DUs; the server executes the rollback operation in the order of the DUs in the operation queue.

[0076] In some embodiments, during the DU upgrade process in a distributed system, the server starts a cyclic timer to poll the DU status upgrade results of all Agent-Ready nodes (the versions of the single boards where the proxies are located are powered on and loaded). To prevent the entire DU upgrade process from being unable to terminate due to the above exceptions, the embodiments of the present application set a reasonable timeout, such as the empirical value of 30 minutes. If the upgrade takes longer than this timeout, the server will automatically trigger the rollback operation.

[0077] For example, if the server detects that the DU upgrade on a certain proxy fails, the following rollback steps are executed:

[0078] Step A101, the server obtains the component packages of the old and new versions from the global DB, sets the status of the old version component package to the active state, sets the status of the new version component package to the add state, and reconstructs the software deployment rule.

[0079] Step A102, the server generates an operation queue for DU according to the description information of the old version component package.

[0080] The server fetches the first DU from the operation queue of the DU, first clears the response results of all Agent-Ready nodes related to this DU, writes the description information of this DU into the global DB, and sets the status of the old-version DU to the active state, and the status of the new-version DU is restored to the add state. Finally, it publishes a DU upgrade event to the agent side, declaring that the DU upgrade mode is Must, that is, the old-version DU must be activated.

[0081] Step A103, after the agent side receives the DU upgrade event, if it checks that the status of the old-version DU in the global DB and the loading status of the new-version DU in the local cache are both in the active state, and their version numbers are inconsistent, and the DU upgrade mode is Must, then it determines that DU rollback processing needs to be performed.

[0082] Step A104, if the node where the agent side is located has completed the loading of the new-version DU, then the agent side can perform the upgrade processing of the old-version DU.

[0083] Step A105, if the node where the agent side is located is still in the process of upgrading the new-version DU, then the agent side forcibly performs a reverse rollback according to the DU upgrade process.

[0084] Step A106, if the node where the agent side is located has not received the new-version DU upgrade event, that is, the currently running is still the old-version DU, then the agent side does not need to process the rollback event and directly sets the response result to the global DB.

[0085] It should be noted that during the component upgrade process, the server constructs software deployment rules in terms of component packages, so rollback is also performed in terms of component packages. When the server constructs software deployment rules in terms of DUs, during the component upgrade process, the server pushes onto the stack in the global DB and records the upgraded and upgrading DUs. When component upgrade rollback is required, the recorded DUs are popped from the stack one by one to perform rollback processing, so that more refined control can be achieved.

[0086] For the currently upgraded DU, if the server checks that the upgrade results of all Agent-Ready nodes are completed (ok), then it continues to fetch the next DU from the DU operation queue for processing. When the server checks that the processing of the last DU in the DU operation queue is completed, it clears the upgrade operation flag and closes the polling timer. The component package upgrade processing ends and the command returns. After the component upgrade is completed, a solidification operation is automatically performed by the server or by user operation to ensure that the upgraded new-version components continue to take effect after the distributed system restarts.

[0087] During the upgrade process of a distributed system, the server detects that the DU upgrade on a certain proxy fails, retrieves the old and new version component packages from the global DB, sets the status of the old version component package to the active state, sets the status of the new version component package to the add state, and rebuilds the software deployment rules. The server generates an operation queue for the DU based on the description information of the old version component package, and then performs a rollback operation in the order of the DUs in the operation queue.

[0088] It should be noted that the server in this embodiment only performs system-level control over the component upgrade process. The proxy independently controls and executes the DU upgrade process on its own node. However, the DU upgrade progress of each proxy in the distributed system is not synchronized. When the server triggers the rollback process, it is possible that resource subscribers on some proxy nodes receive an event to forcibly uninstall the resource during the process of loading the resources of the new version DU; or, during the process of uninstalling the resources of the old version DU, they receive an event to forcibly load the resource, that is, the proxy needs to forcibly uninstall a certain type of resource of the DU.

[0089] The steps of the rollback operation of the DU resources in the embodiments of this application include:

[0090] For the rollback of DU resources, when currently in the situation of uninstalling the resources of the old version DU, the proxy sets the status of the old version DU resources to the loading state; the proxy clears all subscriber response results of the old version DU resources to be loaded in the local DB; the proxy publishes an upgrade loading event for the DU resources and waits for the resource subscribers to finish loading.

[0091] When currently in the situation of loading the resources of the new version DU, or the resources of the new version DU have been loaded, the proxy sets the status of the new version DU resources to the unloading state; the proxy clears all subscriber response results of the new version DU resources to be unloaded in the local DB; the proxy publishes an upgrade unloading event for the DU resources and waits for the resource subscribers to finish unloading. After the proxy finishes unloading the resources of the new version DU, it triggers the upgrade loading of the resources of the old version DU.

[0092] In the local DB interface provided to the resource subscribers for setting the resource loading / unloading results, add a consistency check for the DU resource status. For example, when the resource subscriber sets the resource loading result, it is necessary to compare the DU resource status input by the resource subscriber with the currently expected DU resource status, and filter out the responses with inconsistent DU resource status.

[0093] In the actual application process, it is necessary to impose constraints on the resource subscribers, and the constraint conditions are shown in Table 1.

[0094] Table 1

[0095]

[0096] In some embodiments, when the rollback process of component upgrade fails, the proxy end decides whether to actively restart this node to recover according to the importance of the component service, so as to minimize the impact of component upgrade failure on the services running on the current service board.

[0097] In a distributed system, during component upgrade, if scenarios such as abnormal restart or power-off of the server end or the proxy end, or abnormal communication between the server end and the proxy end occur, the following exception handling steps can be taken.

[0098] Scenario 1: The proxy end node has an abnormal restart or power-off

[0099] In the case of abnormal restart or power-off of the proxy end, the server end abandons the control of the proxy end; when the proxy end is powered on again, if it is detected that the component is being upgraded, it waits until the component upgrade is completed and then powers on with the new version DU. The specific steps include:

[0100] Step A201, when the server end on the active main control perceives that a certain proxy end is powered off (down) through the endpoint power-on (UP) / power-off (DOWN) service, it removes the proxy end from the Agent-Ready (the version power-on loading of the board where the proxy end is located is completed) table in the global DB, that is, this component upgrade no longer controls this proxy end node, and then continues to perform upgrade processing on other proxy end nodes.

[0101] Step A202, when the proxy end node restarts and powers on, the proxy end checks that there is an upgrade operation mark in the current system, indicating that the current system is performing component upgrade, and actively avoids restarting this proxy end node until the current component upgrade processing ends.

[0102] Step A203, when the proxy end is powered on, it traverses the DU table in the global DB and powers on with the new version DU.

[0103] Scenario 2: There is abnormal communication between the server end node and the proxy end node

[0104] In the case of abnormal communication between the server end and the proxy end, the proxy end powers on and registers the loss callback of the DU upgrade event; after the communication between the proxy end and the server end returns to normal, the global DB actively publishes the loss event of the DU upgrade; the proxy end traverses the DU table in the global DB in the loss callback, performs consistency reconciliation on the version number of the DU in the global DB and the version number of the DU in the local DB, and upgrades the DU with inconsistent version numbers.

[0105] To handle this abnormal scenario, a global DB that supports the Pub / Sub Loss notification mechanism is required. The specific steps are as follows:

[0106] Step A301: The proxy side powers on and registers the Loss callback for the DU upgrade event.

[0107] Step A302: Before the timeout for component upgrade processing set by the server side, if the message communication between the server side and the proxy side node resumes normal, the global DB actively publishes the Loss notification for the DU upgrade event.

[0108] Step A301: After the server side receives the Loss callback for the DU upgrade event, it traverses the DU table in the global DB, compares it with the local DU table, determines whether the component status is consistent, that is, performs consistency reconciliation processing, finds the DU with inconsistent status, and upgrades this DU.

[0109] Scenario 3: The server side node experiences an abnormal restart or power-off

[0110] To handle this abnormal scenario, the device needs to support the primary / standby environment.

[0111] In the case of an abnormal restart or power-off of the server side node, the standby main control is upgraded to the primary main control. The server side of the new primary main control senses the power-off of the proxy side under the new standby main control, and then abandons the control of the proxy side; the server side of the new primary main control checks if there is an upgrade operation flag, and if so, performs a rollback operation; the new standby main control restarts and powers on, and the proxy side on the new standby main control checks if there is an upgrade operation flag, and if so, restarts the node where the proxy side is located until the component upgrade rollback processing is completed; after the proxy side on the new standby main control powers on, it traverses the DU table in the global DB and loads the power-on with the old version component.

[0112] Specifically, when the server side node experiences an abnormal restart or power-off, the following steps are executed:

[0113] Step A401: After the original primary main control restarts, the original standby main control senses the power-off of the primary main control and actively upgrades to the primary main control.

[0114] Step A402: The server side on the new primary main control senses the power-off (down) of the proxy side on the new standby main control through the endpoint UP / DOWN service, then removes this proxy side from the Agent-Ready table in the global DB, that is, this component upgrade no longer controls this proxy side, and then continues the system-level control processing of the upgrade process.

[0115] It should be noted that when the original standby main control upgrades to the primary main control, the original primary main control downgrades to the new standby main control after restarting, that is, the primary / standby roles of the original primary main control and the original standby main control are swapped.

[0116] Step A403: During the process of promoting the standby to the primary on the new primary master controller, when the server detects an upgrade operation flag during the standby-to-primary promotion process on the new primary master controller, it decides that component upgrade rollback processing is required. The rollback processing can follow Steps A101 to A106 and will not be elaborated here.

[0117] Step A404: The new standby master controller restarts and powers on. If the proxy on this new standby master controller detects an upgrade operation flag in the current system, it will actively avoid restarting the standby master controller where this proxy is located until the current component upgrade rollback processing is completed.

[0118] Step A405: The proxy on the new standby master controller powers on, traverses the DU table in the global DB, and loads and powers on with the old version components.

[0119] Second, the upgrade method for the distributed system provided by the embodiments of the present application is applied to the proxy.

[0120] Figure 5 It is a flowchart of another upgrade method for the distributed system provided by the embodiments of the present application. Among them, the resources of the old version DU and the resources of the new version DU are both service OAM interfaces for providing usage capabilities externally.

[0121] As Figure 5 shown, the upgrade method for the distributed system includes:

[0122] Step S501: Unload the resources of the old version DU.

[0123] In some embodiments, the object of component upgrade may be the resource publisher or the resource subscriber. Therefore, unloading the resources of the old version DU includes:

[0124] When the DU is the resource publisher, the proxy triggers the resource subscribers on this node to unload all the resources published by the old version DU, waits for the resource subscribers to complete the unloading, and writes the unloading result into the local DB.

[0125] When the DU is the resource subscriber, the proxy triggers the old version DU on this node to unload all the loaded resources, and clears the response messages and resource subscription information related to the old version DU.

[0126] Step S502: Load the resources of the new version DU.

[0127] In some embodiments, when loading the resources of the new version DU, the proxy triggers the relevant resource subscribers on this node to load all such resources published by the new version DU, waits for the resource subscribers to complete the loading, and writes the loading result into the local DB.

[0128] The component upgrade method provided in this embodiment first uninstalls the resources of the old version of DU, and then loads the resources of the new version of DU. It does not require restarting the service single board or the OAM process. Through the dynamic uninstallation and loading of resources, the upgrade processing of component resources is realized, ensuring the integrity of component upgrade.

[0129] In some embodiments, in order to improve the efficiency of upgrade switching, before the proxy uninstalls the resources of the old version of DU, it further includes: obtaining the software file list of the new version of DU based on the software deployment request conditions; downloading the software files of the new version of DU to the local based on the software file list. The software files of the new version of DU include the processes and dependent files of the new version of DU and the resource files of the new version of DU.

[0130] Based on the software deployment request conditions, the proxy queries the software file list of the new version of DU through the global DB interface provided by SWR, and downloads the software files of the new version of DU to the local through FTP. Among them, the software files of the new version of DU include, but are not limited to, the process files of the new version of DU and their dependent files and resource files. Among them, the dependent files include binary library files, business model files, etc. on which the processes of the new version of DU depend. It should be noted that for the resource files of the new version of DU, the proxy can download them to the local as needed according to the actual deployment situation of the resource subscribers on this node, and does not need to download all the resource files of the new version of DU to the local, which can save local storage resources and network resources.

[0131] In some embodiments, after loading the resources of the new version of DU, it further includes: deleting the software files of the old version of DU.

[0132] After the proxy triggers the completion of the resource loading of the new version of DU, the software files of the old version of DU stored locally are deleted to save local storage space.

[0133] In some embodiments, after loading the resources of the new version of DU, it further includes: writing the loading result corresponding to DU into the global DB.

[0134] The proxy queries the loading results of the processes and resources related to DU locally and summarizes them, and writes the summary result into the global DB as the response result for the server to query the upgrade result.

[0135] In some embodiments, before loading the resources of the new version of DU, it further includes: uninstalling the process of the old version of DU and loading the process of the new version of DU; where the process of the old version of DU is the process currently running by DU, and the process of the new version of DU is the process that DU expects to run.

[0136] The upgrade method of the distributed system provided by the embodiment of the present application uninstalls the process of the old version of DU first, and then loads the process of the new version of DU, realizing the upgrade of business features, shortening the power-on and power-off switching time of the old and new version processes during the upgrade process, and providing reliability support for uninterrupted business.

[0137] It should be noted that the process of uninstalling the old version of DU and the process of loading the new version of DU can be referred to in steps S401 to S402. For the sake of saving space, it will not be elaborated here.

[0138] Figure 6 This is the installation schematic diagram of DU provided by the embodiment of the present application. Assume that ISIS DU is the publisher of netconf resources, and NETCONF DU is the subscriber of netconf resources. When ISIS is installed and activated, if the subscriber NETCONF exists, it is necessary to download the netconf resources of ISIS to the local and notify NETCONF to load. After NETCONF completes the loading of the netconf model of ISIS, the ISIS service can be configured through the netconf command, or the status information of the ISIS service can be queried.

[0139] The following will take the ISIS netconf resources as an example for introduction. As Figure 6 shown, the netconf resource activation and installation steps include:

[0140] Step S601, the NETCONF process is powered on and registers the upgrade event of subscribing to netconf resources with the local DB.

[0141] Step S602, the agent receives the ISISDU installation and activation event. After downloading the ISISDU process and its dependent files to the local, it triggers the power-on and loading of the DU process. Wait for the loading to complete and write the loading result of the DU process to the local DB.

[0142] Step S603, the agent checks that ISISDU has published netconf resources and the subscriber NETCONF exists, then downloads the netconf resource file of ISIS to the local. Then, DUM_AGENT first writes the file path and status information of the resource to the local DB, and then publishes the upgrade event of the netconf resource to notify the resource subscriber to load.

[0143] Step S604, NETCONF receives the upgrade event of the netconf resource, starts to load the netconf resource, waits for the loading to complete, and writes the loading result of the netconf resource to the local DB.

[0144] Step S605: The proxy polls the local DB to check the loading results of the ISIS process and various published resources. If all the loading is completed, write the DU loading result to the global DB.

[0145] The processing procedures of the mib and telemetry resources of ISISDU are similar to those of the netconf resources and will not be elaborated here.

[0146] Before the component upgrade in the embodiment of this application, the server publishing endpoint UP / DOWN service on the active master control. The proxy on all service boards subscribes to the endpoint UP / DOWN service and registers with the global DB to subscribe to the DU upgrade event. After each service board completes software loading, the proxy writes the Agent-Ready status to the global DB. After the resource subscribers on each proxy are powered on, they register with the local DB to subscribe to the DU resource status upgrade event.

[0147] Figure 7 It is the information interaction flowchart among the server, proxy, and software repository during the component upgrade provided by the embodiment of this application. As Figure 7 shown, during the component upgrade, the information interaction process among the server, proxy, and software repository is as follows:

[0148] Step S701: The user downloads the component upgrade package to the active master control and executes the installation and activation command.

[0149] Step S702: The server performs command constraint check.

[0150] The command constraint check includes but is not limited to verifying the integrity of the upgrade package, version compatibility, etc.

[0151] Step S703: If the check passes, the server sets an upgrade operation flag and writes the upgrade operation flag to the global DB.

[0152] Step S704: The server parses the configuration file of the component upgrade package and writes the description information of the component package and the identifiers of the old and new version component packages to the global DB. Record the identifier of the old version component package for the master control to roll back to the old version in case of anomalies.

[0153] Step S705: The server sets the status of the new version component package to the active state, the status of the old version component package to the add state, and upgrades the software deployment rule.

[0154] Step S706: The server generates a DU operation queue according to the description information in the component package.

[0155] The server obtains the first DU from the DU operation queue, writes the description information of this DU into the global DB, sets the status of the new version DU to the active state, and modifies the status of the old version DU to the add state.

[0156] Step S707: Through the global DB, publish the DU upgrade event to all proxy nodes, declaring the expectation to activate the new version DU.

[0157] Step S708: The server starts a cyclic timer to poll the DU status upgrade results of all Agent-Ready nodes.

[0158] Step S709: When the proxy node receives the DU upgrade event, if it checks that both the DU declaration status in the global DB and the DU loading status in the local cache are active and their version numbers are inconsistent, it determines that the DU upgrade process needs to be executed.

[0159] Step S710: The proxy node executes the DU upgrade process of this node.

[0160] Step S711: After the local DU upgrade process is completed, the proxy node writes the upgrade result "ok" into the global DB.

[0161] Step S712: The server polls the response results of all proxy nodes. If the server checks that the upgrade results of all Agent-Ready nodes are "ok", it continues to take the next DU from the DU operation queue for processing.

[0162] Step S713: If the server checks that the processing of the last DU in the DU operation queue is completed, it clears the upgrade operation flag and closes the polling timer.

[0163] Step S714: If the response result of any proxy node is a failure / timeout, the server starts the rollback process.

[0164] Step S715: After the component package upgrade process ends and the command returns, a solidification operation can be performed once to ensure that the upgraded new version components continue to take effect after the system restarts.

[0165] To better understand this application, the following takes the proxy node execution steps as an example to introduce the component upgrade. Figure 8 This is the flowchart of the component upgrade method provided by the embodiment of this application. As Figure 8 shown, the component upgrade method includes:

[0166] After the proxy node receives the DU status upgrade event, it checks that both the DU declaration status in the global DB and the DU loading status in the local cache are active and their version numbers are inconsistent. If so, it determines that the local DU upgrade process needs to be performed.

[0167] Step S801, the agent downloads the software file of the new version of the DU through FTP.

[0168] After the agent enters the DU upgrade process, it first triggers the download of the software file of the new version of the DU. The agent generates software deployment request conditions based on multiple pieces of information such as the name of the DU, the resource type of the DU, the type of the CPU, and the logical type of the service board, queries the software file list of the new version of the DU through the global DB interface provided by the software warehouse SWR, and then downloads the software file of the new version of the DU to the local through FTP. Among them, the software file of the new version of the DU includes processes (sets) and their dependent files, and also includes DU resource files. For DU resource files, according to the actual deployment situation of resource subscribers on the node where the agent is located, the DU resource files are downloaded to the local as needed. Here, the local refers to the local storage space, such as a storage hard disk and memory.

[0169] Step S802, uninstall the resources of the old version of the DU.

[0170] If the DU to be upgraded is a resource publisher, the agent triggers the resource subscribers on this node to uninstall all resources published by the old version of the DU. When there are multiple resource subscribers for the DU to be upgraded, it is necessary to wait for all resource subscribers to complete the uninstallation and write the response result into the local DB.

[0171] If the DU to be upgraded is a resource subscriber, the agent traverses all resources loaded by the old version of the DU on this node, triggers its uninstallation, and clears the response information and resource subscription information related to this DU in the resources.

[0172] Step S803, uninstall the processes of the old version of the DU.

[0173] When the agent triggers the uninstallation of the processes of the old version of the DU on this node, in order to ensure the reliability of the power-on and power-off switching of the old and new version processes, reduce the power-off time of the processes, and ensure data consistency. First, perform power-off preprocessing on the processes of the old version of the DU, and only retain the necessary keep-alive messages. In the power-off preprocessing process of the processes of the old version of the DU, after the process completes the pre-power-off processing, it needs to return a response confirmation message to the agent. After the agent receives the confirmation messages that the power-off preprocessing of all processes of the DU is completed, it then performs batch power-off processing on the DU processes, thereby achieving the time performance and data reliability of the DU process power-off.

[0174] It should be noted that when there are multiple processes in the old version of the DU, all processes of the old version of the DU need to be uninstalled.

[0175] Step S804, load the processes of the new version of the DU.

[0176] When there are multiple processes that need to be loaded in the new version of the DU, it is necessary to batch load the processes of the new version of the DU and wait for all processes to complete the power-on initialization.

[0177] Step S805, resource loading of the new version of DU.

[0178] If the DU to be upgraded is a resource publisher, the proxy triggers the resource subscribers on this node to load all the resources published by the new version of DU. During the DU upgrade process, the resource subscribers upgrade the data structure of their own DB tables according to the resource model of the new version. For the case where there are multiple resource subscribers for DU, it is necessary to wait for all resource subscribers to complete the loading and write the response results into the local DB.

[0179] If the DU to be upgraded is a resource subscriber, the proxy traverses all the relevant resources downloaded on this node, notifies the resource subscriber to load the resources of the new version of DU, and waits for the response results.

[0180] Step S806, deletion of the old version of the DU software file.

[0181] After the new version of DU process and its resource loading are completed, the old version of the DU software file on the local can be deleted.

[0182] After the proxy completes the above steps, it queries and summarizes the loading results of the DU process and its resources locally. Finally, the summarized results are written into the global DB as response results for the server to query.

[0183] In a third aspect, referring to Figure 9 , an embodiment of the present application provides an electronic device, which includes:

[0184] One or more processors 901;

[0185] A memory 902, on which one or more programs are stored. When the one or more programs are executed by the one or more processors, the one or more processors implement the upgrade method of the distributed system in any one of the above.

[0186] One or more I / O interfaces 903, connected between the processor and the memory, configured to implement information interaction between the processor and the memory.

[0187] Among them, the processor 901 is a device with data processing capabilities, which includes but is not limited to a central processing unit (CPU), etc.; the memory 902 is a device with data storage capabilities, which includes but is not limited to a random access memory (RAM, more specifically such as SDRAM, DDR, etc.), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory (FLASH); the I / O interface (read / write interface) 903 is connected between the processor 901 and the memory 902, and can implement information interaction between the processor 901 and the memory 902, which includes but is not limited to a data bus (Bus), etc.

[0188] In some embodiments, the processor 901, the memory 902, and the I / O interface 903 are interconnected via a bus and further connected to other components of the computing device.

[0189] In a fourth aspect, an embodiment of the present application provides a computer-readable medium having a computer program stored thereon, and when the program is executed by a processor, the above-mentioned method for upgrading any one of the distributed systems is implemented.

[0190] Those of ordinary skill in the art can understand that all or some of the steps in the above-mentioned applied method, and the functional modules / units in the system and device, can be implemented as software, firmware, hardware, and their appropriate combinations. In the hardware implementation, the division between the functional modules / units mentioned above 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 executed by several physical components in cooperation. Some physical components 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. Such software can be distributed on a computer-readable medium, which can include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, tape, 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. In addition, as is well known to those of ordinary skill in the art, a communication medium typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and can include any information delivery medium.

[0191] Example embodiments have been applied herein, and although specific terms have been used, they are used for and should be construed only as general illustrative meanings and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly stated, the features, characteristics, and / or elements described in connection with a particular embodiment may be used alone or in combination with the features, characteristics, and / or elements described in connection with other embodiments. Accordingly, those skilled in the art will understand that various forms and details may be changed without departing from the scope of the present application as set forth by the appended claims.

Claims

1. A method for upgrading a distributed system, characterized in that, Applied to the agent side, the method includes: Unloading the process of the old version of the deployment unit DU; wherein, the process of the old version of DU is the process currently running of the DU to be upgraded; Loading the process of the new version of DU; wherein, the process of the new version of DU is the process that the DU to be upgraded expects to run.

2. The method according to claim 1, characterized in that, The process of unloading the process of the old version of the deployment unit DU includes: Sending a power-down preprocessing message to the process of the old version of DU; After receiving the power-down preprocessing confirmation messages returned by all the processes of the old version of DU, performing a batch power-down process on the processes of the old version of DU.

3. The method according to claim 2, wherein The power-down preprocessing of the process of the old version of DU includes: After the business critical data is processed, clearing the critical area data; Removing the non-critical message processing logic in the process of the old version of DU.

4. The method according to claim 3, characterized in that, The critical area data includes one or more of service database control plane data, cross-process shared memory data, inter-process semaphores, and lock resources.

5. The method according to claim 3, characterized in that The non-critical message processing logic includes one or more of events for processing based on the synchronization status of the database, status query messages between upstream and downstream services, user operation command events, and telemetry / alarm reporting events.

6. The method according to claim 1, characterized in that, Before unloading the process of the old version of the deployment unit DU, it further includes: unloading the resources of the old version of DU; After loading the process of the new version of DU, it further includes: loading the resources of the new version of DU; Wherein, the resources of the old version of DU and the resources of the new version of DU are both service operation and maintenance management interfaces for providing usage capabilities externally.

7. The method according to claim 6, characterized in that, The unloading of the resources of the old version of DU includes: When the DU to be upgraded is a resource publisher, triggering the resource subscribers on the node where the agent is located to unload all the resources published by the old version of DU; When the DU to be upgraded is a resource subscriber, unloading all the resources that the old version of DU has subscribed and loaded on the node where the agent is located, and clearing the response results and resource subscription information related to the old version of DU.

8. The method according to claim 6, wherein The loading of the resources of the new version of DU includes: When the DU to be upgraded is a resource publisher, the agent triggers the resource subscribers on this node to load the resources of the new version of DU; When the DU to be upgraded is a resource subscriber, the agent traverses all the resources downloaded on this node and triggers the loading of the new version of DU.

9. The method according to claim 6, characterized in that, Before unloading the resources of the old version of DU, it further includes: Obtaining the software file list of the new version of DU based on the software deployment request conditions; Downloading the software files of the new version of DU to the local based on the software file list, and the software files of the new version of DU include the process of the new version of DU and its dependent files and resource files.

10. The method according to claim 9, wherein The software deployment request conditions are composed of a combination of multiple pieces of information such as the name of the DU to be upgraded, the resource type of the DU to be upgraded, the type of the central processing unit, and the logical type of the service board.

11. The method according to claim 6, wherein After loading the resources of the new version of DU, it further includes: Writing the loading result of the DU to be upgraded into the global DB.

12. The method according to claim 6, wherein The method further includes: Execute a rollback operation in response to a rollback operation instruction from the server; wherein, when component upgrade fails, the server generates an operation queue of DUs based on the description information of the old version component package, and issues rollback operation instructions one by one in the order of the DUs in the operation queue, and the operation queue includes one or more DUs.

13. The method according to claim 12, wherein The steps of the rollback operation include: When currently unloading the resources of the old version DU, set the status of the old version DU resources to the loading state; clear all subscriber response results of the old version DU resources to be loaded in the local DB; publish an upgrade event of the DU resources, and wait for the resource subscribers to finish loading; When currently loading the resources of the new version DU, or when the resources of the new version DU have been loaded, set the status of the resources of the new version DU to the unloading state; clear all subscriber response results of the new version DU resources to be unloaded in the local DB; publish an upgrade event of the DU resources, and wait for the resource subscribers to finish unloading; after the resources of the new version DU are unloaded, trigger the upgrade and loading of the resources of the old version DU.

14. The method according to claim 12, characterized in that, The steps of the rollback operation further include: In the local DB interface used by the resource subscriber to set the response result, determine whether the DU resource status returned by the resource subscriber is consistent with the currently expected DU resource status, and filter out the responses with inconsistent DU resource status.

15. An upgrade method for a distributed system, characterized in that, Applied to the proxy side, the method includes: Unload the resources of the old version deployment unit DU; Load the resources of the new version DU; wherein, the resources of the old version DU and the resources of the new version DU are both business operation maintenance management interfaces for providing usage capabilities externally.

16. An electronic device, characterized in that, Includes: One or more processors; A storage device, on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1-14 or implement the method according to claim 15; One or more I / O interfaces, connected between the processor and the memory, configured to implement information interaction between the processor and the memory.

17. A computer-readable medium, on which a computer program is stored, and when the program is executed by a processor, it implements the method according to any one of claims 1-14 or implements the method according to claim 15.

Images