Upgrading method of distributed system, and electronic device and readable storage medium

Abstract

Disclosed in the present application are an upgrading method for a distributed system, and an electronic device and a readable storage medium. The method comprises: unloading a process of an old-version deployment unit (DU), wherein the process of the old-version DU is the currently running process of a DU to be upgraded; and loading a process of a new-version DU, wherein the process of the new-version DU is a desired process to be run of the DU to be upgraded.

Description

Distributed system upgrade method, electronic device, and readable storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Chinese patent application No. 202311779462.3 filed on December 22, 2023, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a method for upgrading a distributed system, an electronic device, and a computer-readable storage medium. Background Art

[0004] Distributed systems within a microservices architecture can modularize services, achieving isolated deployment. This allows for independent installation, uninstallation, and upgrades, greatly facilitating business functionality scalability, online business software upgrades, and troubleshooting. Consequently, business componentization is becoming the evolutionary direction of data communication systems. However, this modularization places higher demands on the reliability of distributed system component upgrades.

[0005] Summary of the Invention

[0006] In the first aspect, an embodiment of the present application provides an upgrade method for a distributed system, which is applied to an agent end, and the method includes: uninstalling the process of the old version deployment unit DU; wherein the process of the old version DU is the process currently running of the DU to be upgraded; loading the process of the new version DU; wherein the process of the new version DU is the process that the DU to be upgraded expects to run.

[0007] On the second aspect, an embodiment of the present application provides an upgrade method for a distributed system, which is applied to the agent end, and the method includes: unloading the resources of the old version deployment unit DU; loading 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 and management interfaces for providing external usage capabilities.

[0008] In a third aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; a storage device on which one or more computer programs are stored, and when the one or more computer programs are executed by the one or more processors, the one or more processors implement the distributed system upgrade method provided in an embodiment of the present application; one or more I / O interfaces, connected between the processor and the memory, and configured to implement information interaction between the processor and the memory.

[0009] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. The computer program is executed by a processor, so that the processor implements the distributed system upgrade method provided by the embodiment of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG1 is a diagram showing the relationship between component packages in an embodiment of the present application;

[0011] FIG2 is a diagram showing the components of a deployment unit in an embodiment of the present application;

[0012] FIG3 is an application scenario diagram of the distributed system upgrade method provided in an embodiment of the present application;

[0013] FIG4 is a flow chart of a method for upgrading a distributed system according to an embodiment of the present application;

[0014] FIG5 is a flowchart of another distributed system upgrade method provided in an embodiment of the present application;

[0015] FIG6 is a schematic diagram of the installation of a deployment unit according to an embodiment of the present application;

[0016] FIG7 is a flowchart of information interaction between the server, agent, and software repository during component upgrade according to an embodiment of the present application;

[0017] FIG8 is a flow chart of a method for upgrading an agent component according to an embodiment of the present application;

[0018] FIG9 is a block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to enable those skilled in the art to better understand the technical solution of the present application, the server provided in the present application is described in detail below with reference to the accompanying drawings.

[0020] Hereinafter, example embodiments will be described more fully with reference to the accompanying drawings, but the example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. These examples are provided to make this application more thorough and complete and to enable those skilled in the art to fully understand the scope of this application.

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

[0022] The terms used herein are used only to describe specific embodiments and are not intended to limit this application. As used herein, the singular forms "a," "an," 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 "comprising" and / or "made of" are used in this specification, the presence of the features, wholes, steps, operations, elements, and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof is not excluded.

[0023] The embodiments described herein may be described with reference to plan views and / or cross-sectional views, with the aid of idealized schematic diagrams of the present application. Accordingly, the example illustrations may be modified based on manufacturing techniques and / or tolerances. Therefore, the embodiments are not limited to the embodiments shown in the accompanying drawings, but include modifications of the configurations formed based on the manufacturing process. Therefore, the regions illustrated in the accompanying drawings are schematic in nature, and the shapes of the regions shown in the drawings illustrate specific shapes of the regions of the elements, but are not intended to be limiting.

[0024] 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 defined as such herein.

[0025] The distributed system in the embodiments of the present application can be a distributed system in the communications field or a distributed system in other fields. From the user operation level, the installation, uninstallation, and upgrade of components in the distributed system are usually based on the component package (also called feature package) granularity; from the internal implementation level, the installation, uninstallation, and upgrade of components in the distributed system are based on the deployment unit (DU) granularity.

[0026] FIG1 is a relationship diagram of the component package structure in an embodiment of the present application. As shown in FIG1 , a component package 10 includes one or more deployment units (DUs) 20, such as a ratio of component package 10 to DU 20 of 1:M, and DU 20 includes one or more closely related business components 30, such as a ratio of DU 20 to business component 30 of 1:N, where N and M are both positive integers. A DU is a complete, independently deployable minimum unit and a complete deployment entity. Each DU is uniquely identified by a name and a version number.

[0027] As shown in Figure 2, the DU logically consists of component processes, their dependent files, and component Operation Administration and Maintenance (OAM) resource files. A component process and its dependent files include one or more service binary files, the software development kit (SDK) files that the process depends on, and private resource files. OAM resource files include cli files, netconf files, mib files, alarm files, and so on.

[0028] In this embodiment of the application, the provider of OAM resource files is referred to as the resource publisher, and the user of OAM resource files is referred to as the resource subscriber. The internal implementation process of component upgrades is based on the DU granularity. After the component process is restarted, it supports lossless regeneration. That is, neighboring devices are unaware, the local device's main control and service boards are not restarted, the forwarding plane does not lose packets or interruptions, component service configurations are not lost, and the status of upstream and downstream components remains consistent after restart.

[0029] FIG3 is an application scenario diagram of the upgrade method of a distributed system provided in an embodiment of the present application. As shown in FIG3 , the distributed system corresponding to the component upgrade method includes a main processing unit (MPU) 1, a backup MPU 2, and one or more service boards 3. The main processing unit 1 is used for system-level control of component upgrades (In-Service Software Upgrade, ISSU). When the main MPU 1 fails (such as abnormal restart or power failure), the backup MPU 2 replaces the main MPU 1 to perform corresponding operations (such as performing a rollback operation). The service board 3 is used to forward services.

[0030] In some embodiments, the main control 1 includes a deployment unit management server (Deployment Unit Management Server, abbreviated as DUM_SVR) 11 and a software repository (Software Repository, abbreviated as SWR) 12. For the convenience of description, the deployment unit management server is referred to as the server, and the server 11 is responsible for the system-level control of component upgrades, such as component upgrade control, rollback control, etc. When the user downloads the component package to the storage device of the distributed system and performs component installation or upgrade operations, the server 11 will trigger SWR12 to parse the descriptive configuration file in the component package, build software deployment rules, and store them in the global database (DataBase, abbreviated as DB) 13 in the form of key-value, and provide key-value query services. Among them, the key is used to represent the software deployment request condition, that is, the query condition 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 central processing unit (CPU) type, the logical type of the service board, etc., and the value is used to represent the software file list information.

[0031] The software warehouse 12 includes a global DB 13 and an FTP service 14. The global DB 13 is used to store software deployment rules, component package status information, DU status information, interaction information between server and agent nodes, etc. The FTP service 14 is used to provide cross-board download capabilities for files in the distributed system.

[0032] Service board 3 can generate software deployment request conditions based on its own needs. For example, it can query or download the processes and dependent files of a specified DU based on information such as the DU name, CPU type, and logic type of the service board; or it can query or download a specific type of resource file of a specified DU based on information such as the DU name and resource type.

[0033] In some embodiments, the global DB 23 in the standby master 2 is used to mirror the global DB 13 in the active master 1 , that is, the standby master 2 synchronously stores a copy of the data in the global DB 13 in the active master 1 through the primary and backup databases.

[0034] The service board 3 includes a local DB31 and a file system 32, wherein the local DB31 is used to store the status information of the DU and its resources on this node, as well as the resource subscription information registered by the resource subscriber. The status information of the local DU resources includes but is not limited to the resource name, resource location, resource status, etc. The resource status includes states such as waiting to load, waiting to unload, loading completed, and unloading completed. The file system 32 is used to manage the list of software files downloaded to this node. During the component upgrade process, it is necessary to manage the list of component software files of both the new and old versions. After the old version of the component is uninstalled, the corresponding software files and memory records can be deleted.

[0035] In some embodiments, each service board 3 corresponds to one or more deployment unit management agents (DUM_AGENTs) 21. For ease of description, this application will simply refer to each deployment unit management agent as an agent. Agents 21 are used for board-level control, including orchestration and execution of upgrade processes on the node where they reside.

[0036] The server 11 and agent 21 exchange information during the DU installation, uninstallation, and upgrade process via the Pub / Sub mechanism and read / write interface of the global DB 13 on the active master 11. The agent 21 interacts with resource subscribers on the local node via the Pub / Sub mechanism and read / write interface of the local DB 31 to complete the DU resource installation, uninstallation, and upgrade process.

[0037] In an embodiment of the present application, information interaction is performed between the server 11 and the agent 21 through the global DB13, and information interaction is performed between the agent and the resource subscriber of this node through the local DB31. This can decouple the server and the agent, and the agent and the resource subscriber of this node.

[0038] During the upgrade process, the server and agent perform the upgrade steps provided by the embodiment of the present application according to the actual situation, which can achieve the reliability of the upgrade. The specific process of the server and agent system upgrade is introduced below.

[0039] First, the embodiment of the present application provides a method for upgrading a distributed system. FIG4 is a flow chart of the method for upgrading a distributed system provided by the embodiment of the present application. As shown in FIG4 , the method for upgrading a distributed system, which is applied to an agent, includes the following steps S401 to S402.

[0040] In step S401, the process of the old version DU is uninstalled.

[0041] In some embodiments, the process of the old version DU is a currently running process of the DU to be upgraded.

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

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

[0044] To improve the reliability of power-off switching between old and new versions of processes, reducing the time required to power off processes and ensuring data consistency, the agent triggers power-off pre-processing before uninstalling processes from the old version of the DU. This involves sending a power-off pre-processing message to the processes in the old version of the DU and waiting for a confirmation message. After receiving a response message confirming the completion of power-off pre-processing for all processes in the old version of the DU, the agent powers off the processes in the old version of the DU. It should be noted that if multiple processes in the old version of the DU exist, batch power-off can be performed on all of them.

[0045] In the DU upgrade process, the embodiment of the present application introduces power-off pre-processing, that is, the process of uninstalling the old version of DU includes two steps: power-off pre-processing and power-off processing. Power-off pre-processing is performed before power-off processing, which can shorten the power-on and power-off switching time of the new and old version processes, while ensuring the consistency of business process data, and providing reliability support for achieving uninterrupted business upgrades.

[0046] In some embodiments, the process of the old version DU is pre-processed for power off, including: clearing the critical section data after the key data of the business process is processed; removing the non-critical message processing logic in the process of the old version DU, and retaining only the necessary keep-alive messages.

[0047] In some embodiments, critical section data refers to data associated with a business process, and the critical section data includes one or more of business database control plane data, cross-process shared memory data, inter-process semaphores, and lock resources.

[0048] Non-critical message processing logic refers to processing logic that has no impact on business process regeneration. Non-critical message processing logic includes: synchronization status processing events based on the business database, status query messages between upstream and downstream businesses, user operation command events, and telemetry / alarm reporting events. One or more of these events.

[0049] After clearing critical section data and removing non-critical messages, batch powering off DU processes can ensure both time performance and data reliability.

[0050] In step S402, the process of loading the new version DU.

[0051] In some embodiments, the process of the new version DU is a process that the DU to be upgraded expects to run.

[0052] The distributed system upgrade method provided in 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, thereby realizing the upgrade of business characteristics. By shortening the time for powering on and off the old and new version processes, it provides reliability support for uninterrupted business during the upgrade process.

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

[0054] In some embodiments, both the resources of the old version DU and the resources of the new version DU are business operation, administration and maintenance (OAM) interfaces for providing external usage capabilities.

[0055] Before uninstalling the old DU process, the old DU's resources are uninstalled first, preventing the impact of OAM services on the upgrade. After loading the new DU process, the new DU's resources are loaded. This does not require restarting the service board or the resource subscriber process, enabling dynamic loading and unloading of resources. This allows for simultaneous upgrades of service OAM interfaces and service features, ensuring the integrity of component upgrades.

[0056] In some embodiments, when uninstalling the resources of the old version DU, 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 DU. In 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 results to the local DB. The agent polls the local DB to check whether all resource subscribers have uninstalled the resources published by the old version DU. If so, the process steps of uninstalling the old version DU are executed; if not, the process steps of uninstalling the old version DU are executed. If the DU to be upgraded is a resource subscriber, the agent traverses all resources loaded by the old version DU on this node and triggers the uninstallation of the old version DU. After all loaded resources are uninstalled, the agent clears all response information related to the old version DU in the resource record and clears the resource subscription information. Then, the process steps of uninstalling the old version DU are executed.

[0057] It should be noted that when uninstalling resources of an old version DU, it is necessary to determine whether the resource uninstallation process is triggered by a DU upgrade event or a DU uninstallation event to prevent resource subscribers from mistakenly deleting the DU's service configuration data.

[0058] In some embodiments, when loading resources of a new version of the DU, if the DU to be upgraded is a resource publisher, the agent triggers the resource subscribers on this node to load all types of resources published by the new version of the DU. In the case where there are multiple resource subscribers for the DU to be upgraded, it is necessary to wait for all resource subscribers to be loaded and set the response results to the local DB. If the DU to be upgraded is a resource subscriber, the agent traverses all relevant resources published on this node, triggers the loading of the new version of the DU, and waits for the response results of the resource loading. After the DU to be upgraded has completed loading the relevant resources published on this node (for example, resources published by other DUs on this node when they act as resource publishers, and resources of the new version of the DU), the response results need to be written to the local DB. The agent polls the local DB to check whether the DU to be upgraded has loaded all resources published on this node (for example, resources published by other DUs on this node when they act as resource publishers, and resources of the new version of the DU). If so, the step of deleting the old version of the DU software file is executed, and the local DU upgrade result is written to the global DB; if not, continue waiting.

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

[0060] In order to avoid the impact of time-consuming software file query or download on component upgrades and reduce business loss time during the DU upgrade process, the agent side also includes: obtaining the software file list of the new version DU based on the software deployment request conditions; downloading the software files of the new version DU to the local computer based on the software file list. The software files of the new version DU include the processes of the new version DU and its dependent files and resource files.

[0061] In some embodiments, the software deployment request condition is formed by the agent based on a combination 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 CPU, the logical type of the service board, and the like.

[0062] After the agent generates the software deployment request conditions, it queries the software file list for the new version of the DU through the global database interface provided by SWR and downloads the new version of the DU's software files to its local computer via FTP. The new version of the DU's software files include but are not limited to the new version of the DU's processes, dependent files, and resource files.

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

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

[0065] When the agent checks that the resources of the new version of DU have been loaded, the locally stored software files of the old version of DU are deleted to save local storage space.

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

[0067] The agent queries the local DU's process and resource loading results and summarizes them, and writes the summary results as response results into the global DB, so that the server can query the DU upgrade results.

[0068] In some embodiments, during a distributed system DU upgrade, if an exception occurs, such as a DU process load / unload failure or timeout, or a DU resource load / unload failure or timeout, the server automatically triggers a system-wide rollback of the DU upgrade. In the event of a DU upgrade failure, the server generates a DU operation queue based on the description of the old version component package. The operation queue includes one or more DUs; the server performs the rollback operation according to the order of the DUs in the operation queue.

[0069] In some embodiments, during a distributed system DU upgrade, the server starts a loop timer to poll all Agent-Ready nodes (those whose agent-hosted boards have completed version loading) for DU status upgrade results. To prevent the entire DU upgrade process from being terminated due to the aforementioned exceptions, embodiments of the present application set a reasonable timeout, such as 30 minutes, as a rule of thumb. If the upgrade takes longer than this timeout, the server automatically triggers a rollback.

[0070] For example, if the server detects that the DU upgrade on a certain agent fails, the following rollback steps A101 to A106 are executed.

[0071] In step A101, the server obtains the old and new versions of the component packages from the global DB, sets the status of the old version component package to active, sets the status of the new version component package to add, and rebuilds the software deployment rules.

[0072] In step A102, the server generates an operation queue of the DU based on the description information of the old version component package.

[0073] The server retrieves the first DU from the DU operation queue, clears the responses from all Agent-Ready nodes associated with the DU, writes the DU's description to the global database, sets the old version DU's status to active, and restores the new version DU's status to add. Finally, it publishes a DU upgrade event to the agent, declaring the DU upgrade mode to must, meaning that the old version DU must be activated.

[0074] In step A103, after receiving the DU upgrade event, the agent 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 active, and the version numbers of the two are inconsistent, and the DU upgrade mode is Must, then it is determined that DU rollback processing needs to be performed.

[0075] In step A104 , if the node where the agent is located has completed loading of the new version of DU, the agent can simply perform the upgrade process of the old version of DU.

[0076] In step A105, if the node where the agent is located is currently in the process of upgrading the new version of DU, the agent is forced to perform a reverse rollback according to the DU upgrade process.

[0077] In step A106, if the node where the agent is located does not receive the new version DU upgrade event, that is, the old version DU is still currently running, the agent does not need to process the rollback event and directly sets the response result to the global DB.

[0078] It should be noted that during the component upgrade process, the server constructs software deployment rules at the component package level, so rollbacks are also performed at the component package level. When the server constructs software deployment rules at the DU level, during the component upgrade process, the server pushes DUs onto the global database, placing them into a stack structure that records both upgraded and currently upgraded DUs. When a component upgrade rollback is required, the recorded DUs are popped off the stack one by one and the rollback is executed, enabling more refined control.

[0079] For the currently upgraded DU, if the server checks that all Agent-Ready nodes have completed the upgrade (ok), it proceeds to remove the next DU from the DU operation queue for processing. When the server checks that the last DU in the DU operation queue has been processed, it clears the upgrade operation flag and turns off the polling timer. The component package upgrade process is complete, and the command returns. After the component upgrade is complete, a fix operation is performed automatically by the server or by user operation to ensure that the upgraded new version of the component continues to take effect after the distributed system restarts.

[0080] During a distributed system upgrade, if the server detects a DU upgrade failure on an agent, it retrieves the old and new versions of the component packages from the global database, sets the old version's status to active, the new version's status to added, and rebuilds the software deployment rules. Based on the description of the old version's component package, the server generates an operation queue for the DUs and then performs a rollback according to the order of the DUs in the operation queue.

[0081] It should be noted that the server in this embodiment only controls the component upgrade process at the system level, while the agent independently controls and executes the DU upgrade process on its own node. However, the DU upgrade progress of each agent in the distributed system is not synchronized. When the server triggers the rollback process, resource subscribers on some agent nodes may receive an event to force unload resources while loading a new version of the DU; or receive an event to force load resources while unloading an old version of the DU. This means that the agent needs to force unload and / or load a certain type of DU resource.

[0082] The steps of the rollback operation of DU resources in the embodiment of the present application include the following steps.

[0083] For the rollback of DU resources, when the old version of DU resources is currently being uninstalled, the agent sets the status of the old version of DU resources to loading; the agent clears all subscriber response results of the old version of DU resources to be loaded in the local DB; the agent publishes the upgrade loading event of the DU resources and waits for the resource subscribers to complete the loading.

[0084] When a new version of a DU resource is currently being loaded, or loading of the new version of the DU resource has been completed, the agent sets the state of the new version of the DU resource to unloading. The agent clears all subscriber response results of the new version of the DU resource to be unloaded from the local database. The agent publishes an upgrade and uninstallation event for the DU resource and waits for the resource subscriber to complete uninstallation. After the new version of the DU resource is unloaded, the agent triggers the upgrade and loading of the old version of the DU resource.

[0085] In the local DB interface provided to resource subscribers for setting resource loading / unloading results, a consistency check of the DU resource status is added. 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 current expected DU resource status, and filter out responses with inconsistent DU resource status. For example, when the resource subscriber calls the interface to set the resource loading / unloading result, the operation results with inconsistent DU resource status will not be written to the local DB table.

[0086] In actual application, resource subscribers need to be constrained. The constraints are shown in Table 1.

[0087] Table 1

[0088] In some embodiments, when the rollback process of a component upgrade fails, the agent decides whether to actively restart the node to recover based on the importance of the component business, so as to minimize the impact of the component upgrade failure on the business running on the current business board.

[0089] In a distributed system, during a component upgrade, if a server or agent unexpectedly restarts or powers off, or communication between the server and agent fails, take the following exception handling steps.

[0090] Scenario 1: The proxy node unexpectedly restarts or powers off

[0091] If the agent unexpectedly restarts or loses power, the server abandons control of the agent. When the agent is powered on again, if it detects that a component is being upgraded, it waits for the upgrade to complete before loading the new version of the DU and powering it back on. This includes steps A201 to A203.

[0092] In step A201, the server on the active master controller senses that an agent is powered down through the endpoint power up (UP) / power down (DOWN) service, and removes the agent from the Agent-Ready (version of the board where the agent is located is powered on and loaded) table of the global DB, that is, this component upgrade no longer controls the agent node, and then continues to upgrade other agent nodes.

[0093] In step A202, the agent node is restarted and powered on. The agent checks whether there is an upgrade operation mark in the current system, indicating that the current system is undergoing component upgrade, and actively backs off and restarts the agent node until the current component upgrade process is completed.

[0094] In step A203 , the agent is powered on, the DU table in the global DB is traversed, and the new version of the DU is loaded and powered on.

[0095] Scenario 2: Communication anomaly between the server node and the proxy node

[0096] In the event of an abnormality in communication between the server and the agent, the agent powers on and registers a loss callback for the DU upgrade event; after the communication between the agent and the server returns to normal, the global DB proactively publishes a loss event for the DU upgrade; the agent traverses the DU table in the global DB in the loss callback, reconciles the version number of the DU in the global DB with the version number of the DU in the local DB, and upgrades the DU with inconsistent version numbers.

[0097] To handle this abnormal scenario, the global DB needs to support the Pub / Sub loss notification mechanism, which specifically includes the following steps A301 to A303.

[0098] In step A301 , the agent is powered on and registers a Loss callback for a DU upgrade event.

[0099] In step A302, before the timeout period of the component upgrade process set by the server, if the message communication between the server and the agent node is restored to normal, the global DB proactively issues a Loss notification of the DU upgrade event.

[0100] In step A301, after receiving the Loss callback of the DU upgrade event, the server traverses the DU table in the global DB and compares it with the local DU table to determine whether the component status is consistent, that is, performs consistency reconciliation processing, finds the DU with inconsistent status, and upgrades the DU.

[0101] Scenario 3: The server node unexpectedly restarts or powers off

[0102] To handle this abnormal scenario, the device needs to support a master-slave environment.

[0103] In the event of an abnormal restart or power-off of a server node, the backup master is upgraded to the active master. The server of the new active master senses that the agent under the new backup master is powered off and gives up controlling the agent. The server of the new active master checks for the existence of an upgrade operation mark and performs a rollback operation. When the new backup master is restarted and powered on, the agent on the new backup master checks for the existence of an upgrade operation mark and restarts the node where the agent is located until the component upgrade rollback is completed. After the agent on the new backup master is powered on, it traverses the DU table in the global DB and loads and powers on the old version of the component.

[0104] Specifically, when the server node abnormally restarts or is powered off, the following steps A401 to A405 are executed.

[0105] In step A401 , after the original active master controller is restarted, the original standby master controller senses that the active master controller is powered off and proactively upgrades to become the active master controller.

[0106] In step A402, the server on the new active master senses that the agent on the new standby master is powered off (down) through the endpoint UP / DOWN service, and removes the agent from the Agent-Ready table of the global DB, that is, the agent is no longer managed by this component upgrade, and then the system-level control processing of the upgrade process continues.

[0107] It should be noted that when the original backup master controller is promoted to the active master controller, the original active master controller is downgraded to the new backup master controller after restarting, that is, the active and backup roles of the original active master controller and the original backup master controller are swapped.

[0108] In step A403, when the backup master is upgraded to the active master on the new active master, the server checks for an upgrade operation flag and determines that a component upgrade rollback is required. The rollback process can be performed according to steps A101 to A106, which will not be described in detail here.

[0109] In step A404, the new standby master is restarted and powered on. The agent on the new standby master checks if there is an upgrade operation mark in the current system, and then actively backs off and restarts the standby master where the agent is located until the current component upgrade rollback process is completed.

[0110] In step A405 , the agent on the new standby master is powered on, the DU table in the global DB is traversed, and the old version components are loaded and powered on.

[0111] In a second aspect, an embodiment of the present application provides an upgrade method for a distributed system, which is applied to an agent side.

[0112] Figure 5 is a flow chart of another distributed system upgrade method provided by an embodiment of the present application, wherein both the resources of the old version DU and the resources of the new version DU are service OAM interfaces for providing external usage capabilities.

[0113] As shown in FIG5 , the distributed system upgrade method includes the following steps S501 to S502 .

[0114] In step S501 , resources of the old version DU are uninstalled.

[0115] In some embodiments, the target of a component upgrade may be a resource publisher or a resource subscriber. Therefore, uninstalling resources from an older DU involves: if the older DU to be upgraded is a resource publisher, the agent triggers the resource subscriber on the local node to uninstall all resources published by the older DU, waits for the resource subscriber to complete the uninstallation, and writes the uninstallation results to the local database. If the older DU to be upgraded is a resource subscriber, the agent triggers the older DU on the local node to uninstall all loaded resources and clears the response messages and resource subscription information associated with the older DU.

[0116] In step S502 , resources of the new version DU are loaded.

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

[0118] The component upgrade method provided in this embodiment first uninstalls the resources of the old version DU and then loads the resources of the new version DU. There is no need to restart the service board or the OAM process. Through dynamic unloading and loading of resources, the upgrade processing of component resources is realized, ensuring the integrity of the component upgrade.

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

[0120] Based on the software deployment request conditions, the agent queries the software file list of the new version DU through the global DB interface provided by SWR, and downloads the software files of the new version DU to the local computer via FTP. Among them, the software files of the new version DU include but are not limited to the new version DU process files and their dependent files and resource files, among which the dependent files include the binary library files and business model files that the new version DU process depends on. It should be noted that for the resource files of the new version DU, the agent can download them to the local computer on demand based on the actual deployment of the resource subscribers on this node, and does not need to download all the resource files of the new version DU to the local computer, which can save local storage resources and network resources.

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

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

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

[0124] The agent queries the local loading results of DU-related processes and resources and summarizes them, and writes the summary results as response results into the global DB to facilitate the server to query the upgrade results.

[0125] In some embodiments, before loading the resources of the new version DU, it also includes: unloading the process of the old version DU and loading the process of the new version DU; wherein the process of the old version DU is the process currently running by the DU, and the process of the new version DU is the process that the DU expects to run.

[0126] The distributed system upgrade method provided in 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, thereby realizing the upgrade of business characteristics, 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.

[0127] It should be noted that the process of uninstalling the old version DU and loading the new version DU is described in steps S401 to S402 , which will not be described here for the sake of space saving.

[0128] Figure 6 is a schematic diagram of the DU installation provided in an embodiment of the present application. Assume that the ISIS DU is the publisher of NETCONF resources, and the NETCONF DU is the subscriber of NETCONF resources. When installing and activating ISIS, if the subscriber NETCONF exists, it is necessary to download the ISIS NETCONF resources locally and notify NETCONF to load them. After NETCONF has loaded the ISIS NETCONF model, you can use NETCONF commands to configure ISIS services or query ISIS service status information.

[0129] The following describes the ISIS netconf resource as an example. As shown in FIG6 , the netconf resource activation and installation steps include the following steps S601 to S605 .

[0130] In step S601, the NETCONF process is powered on and registers with the local DB to subscribe to NETCONF resource upgrade events.

[0131] In step S602, the agent receives the ISISDU installation activation event, downloads the ISISDU process and its dependent files to the local computer, triggers the power-on loading of the DU process, waits for the loading to complete, and writes the loading results of the DU process to the local database.

[0132] In step S603, the agent checks whether the ISISDU has published a NETCONF resource and whether the subscriber's NETCONF exists. It then downloads the ISIS NETCONF resource file to its local database. The DUM_AGENT then writes the resource's file path and status information to the local database and publishes a NETCONF resource upgrade event to notify the resource subscriber to load the resource.

[0133] In step S604, NETCONF receives the upgrade event of the NETCONF resource, starts loading the NETCONF resource, waits for the loading to be completed, and writes the loading result of the NETCONF resource to the local DB.

[0134] In step S605, the agent polls the local DB to check the loading results of the ISIS process and various publishing resources. If all loading is completed, the DU loading results are written to the global DB.

[0135] The processing of MIB and Telemetry resources in an ISIS DU is similar to that of NETCONF resources and is not detailed here.

[0136] In this embodiment of the present application, before a component upgrade, the server on the active master controller publishes an endpoint UP / DOWN service. Agents on all service boards subscribe to this endpoint UP / DOWN service and register with the global database, subscribing to DU upgrade events. After each service board completes software loading, the agent writes the Agent-Ready status to the global database. After powering on, the resource subscriber on each agent registers with the local database and subscribes to DU resource status upgrade events.

[0137] Figure 7 is a flow chart of information interaction between the server, agent, and software repository during component upgrade according to an embodiment of the present invention. As shown in Figure 7, during component upgrade, the information interaction process between the server, agent, and software repository includes the following steps S701 to S715.

[0138] In step S701, the user downloads the component upgrade package to the primary controller and executes the installation and activation command.

[0139] In step S702 , the server performs a command constraint check.

[0140] Command constraint checking includes but is not limited to verifying the integrity of the upgrade package and version compatibility.

[0141] In step S703, if the check passes, the server sets an upgrade operation flag and writes the upgrade operation flag into the global DB.

[0142] In step S704, the server parses the configuration file of the component upgrade package and writes the component package description information and the identifiers of the old and new versions of the component package into the global DB. The identifier of the old version of the component package is recorded for the master to roll back the old version in case of an abnormality.

[0143] In step S705 , the server sets the status of the new version component package to active status, the status of the old version component package to add status, and upgrades the software deployment rules.

[0144] In step S706, the server generates a DU operation queue according to the description information in the component package.

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

[0146] In step S707, a DU upgrade event is published to all agents through the global DB, declaring the desire to activate the new version of DU.

[0147] In step S708, the server starts a cyclic timer to poll all Agent-Ready nodes for DU status upgrade results.

[0148] In step S709, the agent receives the DU upgrade event, checks the DU declaration status in the global DB and the DU loading status in the local cache, and finds that both are active and their version numbers are inconsistent, then determines that DU upgrade processing needs to be performed.

[0149] In step S710 , the agent executes the DU upgrade process of the node.

[0150] In step S711, after the local DU upgrade process is completed, the agent writes the upgrade result into the global DB.

[0151] In step S712, the server polls the response results of all agents. If the server checks that the upgrade results of all Agent-Ready nodes are completed (ok), it continues to take the next DU from the DU operation queue for processing.

[0152] In step S713, if the server checks that the last DU in the DU operation queue has been processed, the upgrade operation flag is cleared and the polling timer is turned off.

[0153] In step S714, if any agent responds with a failure / timeout result, the server initiates a rollback process.

[0154] In step S715, the component package upgrade process is completed, the command returns, and a solidification operation can be performed to ensure that the upgraded new version component continues to take effect after the system is restarted.

[0155] To better understand the present application, the following describes component upgrades using the agent-side execution steps as an example. FIG8 is a flowchart of a component upgrade method provided by an embodiment of the present application. As shown in FIG8 , the component upgrade method includes the following steps S801 to S806 .

[0156] After receiving the DU status upgrade event, the agent checks whether the DU declaration status in the global DB and the DU loading status in the local cache are both active, and whether the version numbers of the two are inconsistent. If so, it determines that the local DU needs to be upgraded.

[0157] In step S801, the agent downloads the software file of the new version DU via FTP.

[0158] After the agent enters the DU upgrade process, it first triggers the download of the software files of the new version of DU. The agent generates software deployment request conditions based on multiple pieces of information including the name of the DU, the resource type of the DU, the type of the CPU, and the logical type of the business board. Through the global DB interface provided by the software warehouse SWR, the software file list of the new version of DU is queried. Then, the software files of the new version of DU are downloaded to the local computer via FTP. Among them, the software files of the new version of DU include processes (sets) and their dependent files, as well as DU resource files. For DU resource files, the DU resource files are downloaded to the local computer on demand based on the actual deployment status of the resource subscribers on the node where the agent is located. Among them, local refers to local storage space, such as storage hard disks and memory.

[0159] In step S802, the resources of the old version DU are uninstalled.

[0160] If the DU to be upgraded is a resource publisher, the proxy triggers the resource subscribers on this node to uninstall all resources published by the old version of the DU. If the DU to be upgraded has multiple resource subscribers, it is necessary to wait for all resource subscribers to complete the uninstallation and write the response results to the local DB.

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

[0162] In step S803, the process of the old version DU is uninstalled.

[0163] When the agent triggers the uninstallation of the old-version DU process on this node, to ensure the reliability of the power-on and power-off switching between the old and new versions of the process, reduce the power-off time of the process, and ensure data consistency, it first performs power-off preprocessing on the old-version DU process, retaining only the necessary keep-alive messages. During the power-off preprocessing process for the old-version DU process, 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 message that the power-off preprocessing is complete for all DU processes, it performs batch power-off processing on the DU processes, thereby achieving both time performance and data reliability for the DU process power-off.

[0164] It should be noted that when the old version of DU has multiple processes, all processes of the old version of DU need to be uninstalled.

[0165] In step S804, the process of the new version DU is loaded.

[0166] When a new version of DU has multiple processes that need to be loaded, you need to load the processes of the new version of DU in batches and wait until all processes are powered on and initialized.

[0167] In step S805 , the resources of the new version DU are loaded.

[0168] If the DU to be upgraded is a resource publisher, the proxy triggers resource subscribers on the local node to load all resources published by the new version of the DU. During the DU upgrade process, resource subscribers update their own database table data structures based on the new version of the resource model. If a DU has multiple resource subscribers, the proxy waits until all resource subscribers have finished loading and writes the response results to the local database.

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

[0170] In step S806, the old version DU software file is deleted.

[0171] After the new version of the DU process and its resources are loaded, the local old version of the DU software files can be deleted.

[0172] After the agent completes the above steps, it queries the local DU's processes and resource loading results and summarizes them. Finally, it writes the summary results as the response result to the global DB and provides them to the server for query.

[0173] In the third aspect, referring to Figure 9, an embodiment of the present application provides an electronic device, which includes: one or more processors 901; a memory 902, on which one or more computer programs are stored, and when the one or more computer programs are executed by one or more processors, the one or more processors implement any of the above-mentioned distributed system upgrade methods; and one or more I / O interfaces 903, connected between the processor and the memory, and configured to implement information interaction between the processor and the memory.

[0174] In some embodiments, the processor 901 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 902 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) 903 is connected between the processor 901 and the memory 902, and can realize information interaction between the processor 901 and the memory 902, including but not limited to a data bus (Bus), etc.

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

[0176] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor so that the processor implements any one of the above-mentioned methods for upgrading a distributed system.

[0177] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods applied for above may be implemented as software, 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 may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may 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 may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled 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 technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic 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, it is well known to those skilled in the art that communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0178] Example embodiments have been claimed herein, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present application as set forth in the appended claims.

Claims

1. A distributed system upgrade method, applied to an agent, comprising: Uninstalling the process of the old version deployment unit DU; wherein the process of the old version DU is the process currently running on the DU to be upgraded; and 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 expects to run.

2. The method according to claim 1, wherein: The process of uninstalling the old version deployment unit DU includes: Sending a power-off pre-processing message to the process of the old version DU; and After receiving the power-off pre-processing confirmation messages returned by all the processes of the old version DU, batch power-off processing is performed on the processes of the old version DU.

3. The method according to claim 2, wherein: The sending of the power-off pre-processing message to the process of the old version DU includes: After the business-critical data is processed, clear the critical area data; and The non-critical message processing logic in the process of the old version DU is removed.

4. The method according to claim 3, wherein: The critical section data includes one or more of business database control plane data, cross-process shared memory data, inter-process semaphores, and lock resources.

5. The method according to claim 3, wherein: The non-critical message processing logic includes: one or more of: database-based synchronization status processing events, status query messages between upstream and downstream businesses, user operation command events, and telemetry / alarm reporting events.

6. The method according to claim 1, wherein: Before the process of uninstalling the old version deployment unit DU, the process also includes: uninstalling the resources of the old version DU; After the process of loading the new version DU, the process further includes: loading the resources of the new version DU; The resources of the old version DU and the resources of the new version DU are both business operation, maintenance and management interfaces for providing external usage capabilities.

7. The method according to claim 6, wherein: The uninstallation of the resources of the old version DU includes: When the DU to be upgraded is a resource publisher, trigger the resource subscriber on the node where the proxy is located to uninstall all resources published by the old version DU; When the DU to be upgraded is a resource subscriber, all resources subscribed and loaded by the old version DU on the node where the proxy is located are uninstalled, and the response results and resource subscription information related to the old version DU are cleared.

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

9. The method according to claim 6, wherein: Before uninstalling the resources of the old version DU, the following steps are also included: Obtaining a software file list of a new version of DU based on the software deployment request condition; and The software files of the new version DU are downloaded locally based on the software file list, wherein the software files of the new version DU include the processes of the new version DU and its dependent files and resource files.

10. The method according to claim 9, wherein: The software deployment request condition is formed by combining multiple information including the name of the DU to be upgraded, the resource type of the DU to be upgraded, the type of the central processor and the logic type of the service board.

11. The method according to claim 6, wherein: After the resource of the new version DU is loaded, the method further includes: The loading result of the DU to be upgraded is written into the global database DB.

12. The method according to claim 6, wherein: The method further comprises: Respond to the rollback operation instruction of the server and perform a rollback operation; wherein, when the component upgrade fails, the server generates an operation queue of DU 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 to multiple DUs.

13. The method according to claim 12, wherein: The steps of the rollback operation include: If the old version DU resource is currently being uninstalled, the status of the old version DU resource is set to the loading status; all resource subscriber response results of the old version DU resource to be loaded in the local DB are cleared; the upgrade event of the DU resource is published, and the resource subscriber loading is waited for completion; If a new version of DU resources is currently being loaded, or the new version of DU resources has been loaded, the status of the new version of DU resources is set to the unloading status; the response results of all resource subscribers of the new version of DU resources to be uninstalled in the local DB are cleared; the upgrade event of the DU resources is published, and the resource subscribers are waited for the uninstallation to be completed; after the new version of DU resources is uninstalled, the upgrade loading of the old version of DU resources is triggered.

14. The method according to claim 12, wherein: The step of the rollback operation also includes: In the local DB interface used by the resource subscriber to set the response result, it is determined whether the DU resource status returned by the resource subscriber is consistent with the currently expected DU resource status, and the responses with inconsistent DU resource status are filtered out.

15. A distributed system upgrade method, applied to an agent, the method comprising: Uninstall the resources of the old version deployment unit DU; as well as 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 external usage capabilities.

16. An electronic device, wherein: include: one or more processors; A storage device having one or more computer programs stored thereon, wherein when the one or more computer programs are executed by the one or more processors, the one or more processors implement any one of claims 1 to 14 or implement the method according to claim 15; as well as One or more I / O interfaces are connected between the processor and the memory and are configured to implement information interaction between the processor and the memory.

17. A computer-readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor so that the processor implements any one of claims 1 to 14 or implements the method according to claim 15.

Images