Upgrading method and device

Abstract

The invention provides an upgrading method and device.The method is applied to a basic container, the basic container is located in network equipment, the network equipment further comprises a first container, and a host process of first software runs in the first container. Determining to-be-upgraded second software according to a first version file included in the upgrading instruction; if the second software is the first software, a second container is started, and a standby process of the first software runs in the second container; if a first notification sent by the second container is received, a second notification is sent to the first container, so that the first container stops running of the host process according to the second notification; and upgrading the standby process running in the second container to the main process, and displaying an upgrading response to prompt a user that the upgrading is completed.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to an upgrading method and device. Background Art

[0002] Currently, distributed devices are usually equipped with a main board and a backup board. Various types of software can be run on the main board and the backup board. The software types include software that supports multiple instances and software that supports a single instance.

[0003] For example, Open Shortest Path First (OSPF) software is software that supports a single instance. In actual applications, the main board and the backup board run OSPF software separately, but on the same board, it is not supported to start multiple OSPF software. For another example, Border Gateway Protocol (BGP) software is software that supports multiple instances. In actual applications, the main board and the backup board also run BGP software separately, but on the same board, it is supported to start multiple BGP software and distinguish them by different instance numbers.

[0004] For multi-instance software, if one instance is restarted, other instances can continue to work. However, most existing software does not support multiple instances, and there is no backup process to back up the software in a single-machine environment. Therefore, when the software is upgraded, the services supported by the software will be interrupted.

[0005] In order to solve the above problems, a dual-container upgrade method can be used to achieve a single-machine service non-interruption upgrade (English: In-Service Software Upgrade, referred to as ISSU). During the upgrade, the backup container is first started to run the entire operating system of the network device, and then the operating system running in the main container is stopped. Subsequently, the backup container is upgraded to the new main container, so that the software can be upgraded without interrupting the service.

[0006] However, the existing dual-container upgrade method also exposes the following problems: 1) Single-machine ISSU cannot upgrade some software; 2) Network devices with insufficient hardware resources cannot start multiple operating systems. Summary of the invention

[0007] In view of this, the present application provides an upgrade method and device to solve the problem that the existing dual-container upgrade method cannot upgrade some software and the network device with insufficient hardware resources cannot start multiple operating systems.

[0008] In a first aspect, the present application provides an upgrade method, the method being applied to a basic container, the basic container being in a network device, the network device further comprising a first container, the main process of a first software running in the first container, the method comprising:

[0009] When receiving an upgrade instruction input by a user, determining the second software to be upgraded according to the first version file included in the upgrade instruction;

[0010] If the second software is the first software, starting a second container, and running a standby process of the first software in the second container;

[0011] If the first notification sent by the second container is received, sending a second notification to the first container, so that the first container stops the running of the main process according to the second notification;

[0012] The standby process running in the second container is upgraded to the main process, and an upgrade response is displayed to prompt the user that the upgrade is complete.

[0013] In a second aspect, the present application provides an upgrade device, the device is applied to a basic container, the basic container is in a network device, the network device also includes a first container, the main process of a first software runs in the first container, the device includes: a receiving unit, a determining unit, a starting unit, a sending unit and an upgrade unit;

[0014] The determining unit is configured to determine the second software to be upgraded according to the first version file included in the upgrading instruction when the receiving unit receives the upgrading instruction input by the user;

[0015] The starting unit is configured to start a second container if the second software is the first software, wherein the second container runs a standby process of the first software;

[0016] the sending unit is configured to send a second notification to the first container if the receiving unit receives the first notification sent by the second container, so that the first container stops the running of the main process according to the second notification;

[0017] The upgrading unit is used to upgrade the standby process running in the second container to the main process, and display an upgrading response to prompt the user that the upgrading is complete.

[0018] In a third aspect, the present application provides a network device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0019] Therefore, by applying the upgrade method and device provided by the present application, when an upgrade instruction input by the user is received, the basic container determines the second software to be upgraded according to the first version file included in the upgrade instruction; if the second software is the first software, the basic container starts the second container, and the standby process of the first software runs in the second container; if the first notification sent by the second container is received, the basic container sends a second notification to the first container, so that the first container stops the running of the main process according to the second notification; the basic container upgrades the standby process running in the second container to the main process, and displays an upgrade response to prompt the user that the upgrade is complete.

[0020] In this way, for the single-master environment in the network device, feature containers are used to isolate the software from each other; upgrades are implemented by starting the master and backup feature containers, avoiding business interruptions. In addition, feature containers are created on demand, saving network device software and hardware resources. This solves the problem that the existing dual-container upgrade method cannot upgrade some software and that network devices with insufficient hardware resources cannot start multiple operating systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A flowchart of an upgrade method provided in an embodiment of the present application;

[0022] Figure 2 A diagram of a multi-container structure in a network device provided in an embodiment of the present application;

[0023] Figure 3 A signaling diagram for starting a feature container provided in an embodiment of the present application;

[0024] Figure 4 A signaling diagram for stopping a feature container provided in an embodiment of the present application;

[0025] Figure 5 A signaling diagram of an upgrade feature container provided in an embodiment of the present application;

[0026] Figure 6 A structural diagram of an upgrade device provided in an embodiment of the present application;

[0027] Figure 7 The network device hardware structure provided in the embodiment of the present application. DETAILED DESCRIPTION

[0028] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0029] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more corresponding listed items.

[0030] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0031] The following is a detailed description of the upgrade method provided in the embodiment of the present application. Figure 1 , Figure 1 A flowchart of an upgrade method provided in an embodiment of the present application. The method is applied to a basic container, the basic container is in a network device, and the operating system of the network device runs in the basic container. The upgrade method provided in an embodiment of the present application may include the following steps.

[0032] Step 110: When receiving an upgrade instruction input by a user, determining the second software to be upgraded according to the first version file included in the upgrade instruction;

[0033] Specifically, a basic container has been set up in the network device, and the operating system of the network device is run in the basic container. A first container has also been set up in the network device, and the first container can also be called a characteristic container. The main process of the first software is run in the first container.

[0034] The user wants to upgrade the first software and inputs an upgrade instruction to the basic container through a command line. The upgrade instruction includes a first version file, which is specifically the latest version file of all software running in the network device. Among them, all software includes but is not limited to operating systems, applications, services, etc.

[0035] After receiving the upgrade instruction, the basic container obtains the first version file from the upgrade instruction and determines the second software to be upgraded according to the first version file.

[0036] Optionally, the specific process of the basic container determining the second software to be upgraded according to the first version file is:

[0037] After obtaining the first version file, the basic container obtains the second version file from the local computer, and the second version file is the version file of all software currently running in the network device, wherein all software includes but is not limited to operating systems, applications, services, and the like.

[0038] The basic container compares the version of each software included in the first version file with the version of each software included in the second version file to determine the software with different versions. The basic container determines the software with different versions as the second software, that is, the software to be upgraded.

[0039] The base container also obtains the custom file started by the second software locally, and through the custom file, the base container determines how to run the second software. For example, run as a process or run as a container. In an embodiment of the present application, the second software runs in a container.

[0040] Step 120: If the second software is the first software, start a second container, and run the standby process of the first software in the second container;

[0041] Specifically, according to the description of step 110, after determining that the second software is the software to be upgraded, the basic container may also determine that the second software is the first software according to the two version files.

[0042] In an embodiment of the present application, if the basic container determines that the second software to be upgraded is the first software (hereinafter referred to as the first software) and the first software is run in a container manner, the basic container starts the second container and runs the backup process of the first software in the second container.

[0043] Optionally, the specific process of the above basic container starting the second container is:

[0044] The basic container obtains the second software startup parameter of the first software to be upgraded from the first version file. The basic container identifies whether the environment in which the first software is currently running in the network device is a single master control. In the embodiment of the present application, the basic container has previously created a first container for the first software and runs the main process of the first software in the first container. Therefore, the environment in which the first software is currently running in the network device is a single master control.

[0045] If the environment in which the first software is currently running in the network device is a single master control, the basic container creates a second container, sets a container ID and a container type of the second container, and sets the container type to an environment variable of the container.

[0046] In an embodiment of the present application, the created second container may also be referred to as a feature container, which shares the net / ipc / pid namespace with the base container, and shares the file system, lmdb, and lib (the lib permissions of the feature container may not be open to the base container). The lightweight inter-process communication (English: Lightweight Inter-Process Communication, abbreviated as: LIPC) protocol is used between each container to achieve cross-container communication. The LIPC protocol distinguishes different containers by container ID to support cross-container communication (that is, when containers communicate with each other, the source address and destination address can fill in the container ID and forward through the container ID). The Unix socket protocol can also be used between containers to access files in the shared directory. The feature container accesses the conf file in the feature container directory according to the container type. The conf file is stored in lib, and the lib rights are not open to the base container.

[0047] The basic container also obtains the second software configuration data of the first software from the local dbm (database service) (in the embodiment of the present application, the software configuration data is named "second", but is not limited to this naming, it can also be "first", which is only used to distinguish other software configuration data).

[0048] The basic container generates a fifth notification (in the embodiment of the present application, the notification is named "fifth", but is not limited to this naming, and may also be "first", "second", etc., only used to distinguish other notifications), and the fifth notification includes the second software startup parameter and the second software configuration data. The basic container sends the fifth notification to the second container.

[0049] After receiving the fifth notification, the second container obtains the second software startup parameters and the second software configuration data therefrom. According to the second software configuration data and the second software startup parameters, the second container starts the second process locally. After starting the second process, the second container generates a second registration message (in the embodiment of the present application, the registration message is named "second", but it is not limited to this naming, and it can also be "first", etc., which is only used to distinguish other registration messages), and the second registration message includes a second software registration attribute (in the embodiment of the present application, the software registration attribute is named "second", but it is not limited to this naming, and it can also be "first", etc., which is only used to distinguish other software registration attributes). Among them, the second software registration attribute includes a software name, a software group name, an instance number, a high availability (English: High Availability, referred to as: HA) registration attribute, a LIPC port number, a software HA event processing function, a software HA message processing function, and the like. The second container sends a second registration message to the base container.

[0050] After the basic container receives the second registration message, it obtains the second software registration attribute from it. According to the preset decision strategy and the second software registration attribute, the basic container sets the second process as the standby process. That is, the main process of the first software runs in the current first container, and the standby process of the first software runs in the second container.

[0051] In the embodiment of the present application, the above decision strategy is the strategy for the basic container to assign identity roles to processes. The basic container can make decisions on software identities based on information such as the registration order of each software, software registration attributes, the primary / standby identities of the nodes where the software is located, and whether there is already a main process in the network device. Among them, the HA identity role of the software includes the main process and the standby process.

[0052] After the basic container sets the second process as the standby process, it generates a sixth notification (in the embodiment of the present application, this notification is named "sixth", but it is not limited to this name, and it can also be "first", "second", etc., only used to distinguish other notifications). This sixth notification is used to trigger the first container to start the backup data process of the software to the second container.

[0053] After the first container receives the sixth notification, it starts the backup data process. The first container backs up the data related to the software stored in itself to the second container. It can be understood that after the second container receives all the backup data, it generates and sends a first notification to the basic container.

[0054] Step 130: If the first notification sent by the second container is received, then send a second notification to the first container, so that the first container stops the operation of the main process according to the second notification;

[0055] Specifically, according to the description of step 120, the basic container determines whether it has received the first notification sent by the second container.

[0056] If the first notification sent by the second container is received, then the basic container determines that the backup data process between the first container and the second container has been completed. The basic container generates a second notification, and this second notification triggers the first container to exit the operation of the first software.

[0057] The first container receives the second notification and stops the operation of the main process according to the second notification. After the first container stops the main process, it also determines whether there is a running process in the first container. If there is no running process in the first container, then the first container stops its own operation and waits to be destroyed.

[0058] It should be noted that in the embodiment of the present application, the first software can support multiple instances or a single instance. When supporting multiple instances, that is, multiple processes of the same software can be run simultaneously in the container, and each process belongs to a different instance. The aforementioned upgrade instruction may also include an instance identifier. When the basic container generates the second notification and the fifth notification, it may also carry the instance identifier in the second notification and the fifth notification, so that when the first container stops running the first software, the process corresponding to the instance identifier is stopped according to the instance identifier; or, when the second container starts a process, an instance identifier is set for the process, and the process belongs to the instance corresponding to the instance identifier.

[0059] Step 140: Upgrade the standby process running in the second container to a main process, and display an upgrade response to prompt the user that the upgrade is complete.

[0060] Specifically, according to the description of step 130, after sending the second notification, the basic container waits for the first container to stop running the main process.

[0061] It is understandable that, since the first container will also register with the base container after starting the process, after the first container stops running itself, the base container will perceive that the link between it and the first container has been disconnected.

[0062] After the basic container senses that the link between it and the first container is disconnected, the basic container will select a backup process from the registered backup processes of the first software and upgrade it to the main process. Usually, in multi-process backup, containers and processes are created and started on demand. In the embodiment of the present application, there is only one backup process for the registered first software. Therefore, the basic container selects the backup process in the second container to upgrade to the main process to complete the process switching.

[0063] In summary, although the main process of the first software stops running at this time, the backup process of the first software has been started and upgraded to the main process, so the services supported by the first software are not interrupted. At the same time, according to the latest version of the software startup parameters and software configuration data, the basic container creates a second container and starts the backup process in the second container, so the upgrade of the services supported by the first software is not interrupted.

[0064] Therefore, by applying the upgrade method provided by the present application, when an upgrade instruction input by the user is received, the basic container determines the second software to be upgraded according to the first version file included in the upgrade instruction; if the second software is the first software, the basic container starts the second container, and the standby process of the first software runs in the second container; if the first notification sent by the second container is received, the basic container sends a second notification to the first container, so that the first container stops the running of the main process according to the second notification; the basic container upgrades the standby process running in the second container to the main process, and displays an upgrade response to prompt the user that the upgrade is complete.

[0065] In this way, for the single-master environment in the network device, feature containers are used to isolate the software from each other; upgrades are achieved by starting the master and backup feature containers, avoiding business interruptions. In addition, feature containers are created on demand, saving network device software and hardware resources. This solves the problem that the existing dual-container upgrade method cannot upgrade some software and that network devices with insufficient hardware resources cannot start multiple operating systems.

[0066] Optionally, in the embodiment of the present application, the process of the base container starting the first container locally according to the startup instruction and running the first process of the first software in the first container is also included. It can be understood that the process of the base container starting the first container includes the process of the base container first creating the first container and then starting the first process in the first container.

[0067] Specifically, the user wants to configure and run the first software in the network device so that the network device supports the service corresponding to the first software. Through the command line, the user inputs a startup instruction to the basic container, and the startup instruction includes a configuration file of the first software, and the configuration file includes a first software startup parameter of the first software.

[0068] After receiving the startup instruction, the basic container obtains the startup parameters of the first software. According to the startup parameters of the first software, the basic container determines that the user wants to configure and run the first software in itself. The basic container also obtains the custom file for the startup of the first software. Through the custom file, the basic container determines how to run the second software. For example, run as a process or run as a container. In an embodiment of the present application, the first software runs in a container manner.

[0069] The basic container identifies whether a container running the first software has been started in the network device. In the embodiment of the present application, a container running the first software has not been started in the network device. If a container running the first software has not been started in the network device, the basic container creates the first container. The basic container sets the container ID and container type of the first container, and sets the container type to the environment variable of the container.

[0070] In an embodiment of the present application, the first container created may also be referred to as a feature container, which shares the net / ipc / pid namespace with the base container, and shares the file system, lmdb, and lib (the lib permissions of the feature container may not be open to the base container). The LIPC protocol is used between containers to achieve cross-container communication. The LIPC protocol distinguishes different containers by container ID to support cross-container communication (that is, when containers communicate with each other, the source address and destination address can fill in the container ID and forward through the container ID). The Unix socket protocol can also be used between containers to access files in a shared directory. The feature container accesses the conf file in the feature container directory according to the container type. The conf file is stored in lib, and the lib rights are not open to the base container.

[0071] The basic container also obtains the first software configuration data of the first software from the local dbm (database service). The basic container generates a third notification (in the embodiment of the present application, the notification is named "third", but is not limited to this naming, and can also be "first", "second", etc., only used to distinguish other notifications), and the third notification includes the first software startup parameters and the first software configuration data. The basic container sends the third notification to the first container.

[0072] After receiving the third notification, the first container obtains the first software startup parameter and the first software configuration data. According to the first software configuration data and the first software startup parameter, the first container starts the first process locally. After starting the first process, the first container generates a first registration message, and the first registration message includes the first software registration attribute. Among them, the first software registration attribute includes the software name, the software group name, the instance number, the HA registration attribute, the LIPC port number, the HA event processing function of the software, the HA message processing function of the software, etc. The first container sends the first registration message to the basic container.

[0073] After receiving the first registration message, the basic container obtains the first software registration attribute from the first registration message and sets the first process as the main process according to the preset decision strategy and the first software registration attribute.

[0074] In the embodiment of the present application, the above decision strategy is a strategy for the basic container to assign identity roles to processes. The basic container can decide the software identity based on the registration order of each software, the software registration attributes, the primary and backup identities of the node where the software is located, and whether the main process currently exists in the network device. Among them, the HA identity role of the software includes the main process and the backup process.

[0075] At the same time, the first container generates a fourth notification while generating the first registration message. The first container sends the fourth notification to the base container. After receiving the fourth notification, the base container determines that the first container and the main process have been started. The base container generates and displays a startup response based on the fourth notification, prompting the user that the startup is complete.

[0076] It should be noted that, according to the above, the first software can support multiple instances or a single instance. When supporting multiple instances, that is, multiple processes of the same software can be run simultaneously in the container, and each process belongs to a different instance. The aforementioned startup instruction may also include an instance identifier, and when the basic container generates the third notification, the instance identifier may also be carried in the third notification, so that when the first container starts the process, the instance identifier is set for the process, and the process belongs to the instance corresponding to the instance identifier.

[0077] Optionally, in the embodiment of the present application, the process further includes a process in which the basic container locally stops the third container and the process running in the third container according to the stop instruction.

[0078] Specifically, the user wants to stop running the third software in the network device so that the network device no longer supports the service corresponding to the third software. Through the command line, the user inputs a stop instruction to the basic container, and the stop instruction includes the software name of the third software.

[0079] After receiving the stop instruction, the basic container obtains the software name of the third software. According to the software name, the basic container determines the third container that runs the software indicated by the software name. The basic container generates a seventh notification and sends the seventh notification to the third container. After receiving the seventh notification, the third container stops running the process of the third software. The third container also determines whether there is a running process in itself (the process is a process belonging to any instance). If there is no running process in the third container, stop its own operation and wait for destruction.

[0080] After the third container stops running itself, it also generates and sends an eighth notification to the base container. After receiving the eighth notification, the base container determines that the third container and the processes running in the third container have stopped. Based on the eighth notification, the base container generates and displays a stop response, prompting the user that the stop is complete.

[0081] It can be understood that the third container may be specifically the first container or the second container; the process running in the third container may be specifically the main process or the standby process.

[0082] It should be noted that, according to the above, the software can support multiple instances or a single instance. When supporting multiple instances, that is, multiple processes of the same software can be run simultaneously in the container, and each process belongs to a different instance. The aforementioned stop instruction may also include an instance identifier, and the basic container may also carry the instance identifier in the seventh notification when generating the seventh notification, so that when the container stops running the software, it stops the process corresponding to the instance identifier according to the instance identifier.

[0083] The following describes the structure of each container set up in the network device and the connection relationship between each container. Figure 2 . Figure 2 A diagram of a multi-container structure in a network device provided in an embodiment of the present application.

[0084] exist Figure 2 In the embodiment, the network device includes a base container and a feature container. It is understandable that in actual applications, one or more feature containers can be configured as needed. In the embodiment of the present application, one feature container is used as an example for explanation.

[0085] The feature container includes the system (Systemd) process, application (App) A, and multiple libraries (lib, libA, libB, and libC). Different files are stored in each lib, and the access permissions are also different. For example, libA can only be accessed by the feature container, and the basic container has no access; libB and libC can be accessed by the feature container and the basic container through different protocols. Application A can be specifically the software, application, or service running in the feature container. For example, BGP service. The system process can manage application A by calling the fork function.

[0086] The basic container includes the system (Systemd) process, the container management process (Container Mgr), the CLI (command line) process, the application (App) B, the application (App) C, the forwarding (Forward) process and multiple libraries (lib, libB and libC). Different files are stored in each lib, and the access rights are also different. The system process can manage the container management process, the CLI process, the application B and the application C by calling the fork function. The container management process accesses the system process in the feature container through the docker function and communicates with the system process in the feature container. The CLI process receives various instructions entered by the user through the command line, and transmits various instructions to the container management process, and the container management process executes various instructions. Application B and application C can be specifically software, applications or services running in the basic container. For example, interface management service, HA module.

[0087] The libA included in the feature container can be accessed by application A, but the base container has no access to libA. libB and libC are libraries in the shared directory. Each container can access the corresponding lib through different communications. When the LIPC protocol is used to implement cross-container communication between containers, it must be implemented through the forwarding process in the base container.

[0088] Combine the following Figure 2 as well as Figure 3 The process of starting the feature container provided in the embodiment of the present application is described in detail. Figure 3 , Figure 3 A signaling diagram for starting a feature container provided in an embodiment of the present application.

[0089] Step 310: The CLI process sends a startup instruction to the system process 1 included in the basic container.

[0090] Specifically, the user wants to configure and run the BGP service in the network device so that the network device supports the BGP service. Through the command line, the user inputs a startup instruction to the basic container, and the startup instruction includes a configuration file of the BGP service, and the configuration file includes software startup parameters 1 of the BGP service.

[0091] After receiving the startup command, the CLI process sends the startup command to the system process 1. After receiving the startup command, the system process 1 obtains the software startup parameter 1 from the startup command. The system process 1 determines that the user wants to configure and run the BGP service.

[0092] System process 1 generates notification 1, which includes software startup parameter 1.

[0093] Step 320: System process 1 sends notification 1 to the container management process.

[0094] Step 330: The container management process creates a characteristic container and sends a notification 1 to the system process 2 included in the characteristic container.

[0095] Specifically, after receiving the notification 1, the container management process obtains the software startup parameter 1 therefrom. The container management process determines that the user wants to configure and run the BGP service. The container management process also obtains the customized file for starting the BGP service from the system process 1. Through the customized file, the container management process determines how to run the BGP service. In the embodiment of the present application, the BGP service is run in a container manner.

[0096] The container management process identifies whether a container running the BGP service has been started in the network device. In the embodiment of the present application, a container running the BGP service has not been started in the network device. At this time, the container management process creates feature container 1. The container management process sets the container ID and container type of feature container 1, and sets the container type to the environment variables of the container.

[0097] In the embodiment of the present application, the created characteristic container 1 includes a system process 2 .

[0098] The container management process sends a notification 1 to the system process 2.

[0099] Step 340: System process 2 starts the service process.

[0100] Specifically, after receiving the notification 1, the system process 2 obtains the software startup parameter 1 therefrom. The system process 2 also accesses the dbm (database service) in the basic container to obtain the software configuration data of the BGP service.

[0101] According to the software configuration data of the BGP service and the software startup parameter 1, the system process 2 starts the BGP process locally. After starting the BGP process, the system process 2 generates a registration message 1, which includes the registration attributes of the BGP process. Among them, the registration attributes of the BGP process include the service name, the service group name, the instance number, the HA registration attribute, the LIPC port number, the HA event processing function of the service, the HA message processing function of the service, etc. The system process 2 sends the registration message 1 to the HA module included in the basic container.

[0102] After receiving the registration message 1, the HA module obtains the registration attribute of the BGP process from it. According to the preset decision policy and the registration attribute of the BGP process, the HA module sets the BGP process as the main process.

[0103] In the embodiment of the present application, the above decision strategy is a strategy for the HA module to assign identity roles to processes. The HA module can determine the software identity based on the registration order of each service, service registration attributes, the primary and backup identities of the node where the service is located, and whether the main process currently exists in the network device. Among them, the HA identity role of the service includes the main process and the backup process.

[0104] It should be noted that in the embodiment of the present application, the BGP service can support multiple instances or a single instance. When supporting multiple instances, that is, multiple processes of the BGP server can be run simultaneously in the feature container 1, and each process belongs to a different instance. The aforementioned startup instruction may also include an instance identifier, and when the system process 1 generates the notification 1, the instance identifier may also be carried in the notification 1, so that when the system process 2 starts the BGP process, the instance identifier is set for the BGP process, and the BGP process belongs to the instance corresponding to the instance identifier.

[0105] Step 350: The service process sends a response 1 to the system process 2.

[0106] Specifically, after the BGP process is started, a response 1 is generated, and the response 1 is used to notify that the BGP service is successfully started. The BGP process sends the response 1 to the system process 2.

[0107] Step 360: System process 2 sends response 1 to the container management process.

[0108] Specifically, after receiving the response 1, the system process 2 determines that the BGP service is started successfully. The system process 2 sends the response 1 to the container management process.

[0109] Step 370: The container management process sends a response 1 to the system process 1.

[0110] Specifically, after receiving the response 1, the container management process determines that the BGP service is successfully started. The container management process sends the response 1 to the system process 1.

[0111] Step 380: System process 1 sends response 1 to the CLI process.

[0112] Specifically, after receiving the response 1, the system process 1 determines that the BGP service is successfully started. The system process 1 sends the response 1 to the CLI process.

[0113] After receiving response 1, CLI process 1 determines that the BGP service is started successfully. The CLI process displays response 1 again through the command line, prompting the user that the BGP service is started successfully.

[0114] Combine the following Figure 2 as well as Figure 4 The process of stopping the characteristic container provided in the embodiment of the present application is described in detail. Figure 4 , Figure 4 A signaling diagram for stopping a feature container provided in an embodiment of the present application.

[0115] Step 410: The CLI process sends a stop instruction to the system process 1.

[0116] Specifically, the user wants to stop running the BGP service in the network device so that the network device no longer supports the BGP service. Through the command line, the user inputs a stop instruction to the basic container, and the stop instruction includes the service name of the BGP service.

[0117] After receiving the stop command, the CLI process sends the stop command to the system process 1. After receiving the stop command, the system process 1 obtains the service name of the BGP service from it. The system process 1 determines that the user wants to stop running the BGP service.

[0118] System process 1 generates notification 2, which includes the service name of the BGP service.

[0119] Step 420: System process 1 sends notification 2 to the container management process.

[0120] Step 430: The container management process sends notification 2 to system process 2.

[0121] Specifically, after receiving the notification 2, the container management process obtains the service name of the BGP service from it. The container management process determines that the user wants to stop running the BGP service. According to the software name, the container management process determines the feature container of the BGP service indicated by the running service name. The feature container can be the feature container 1 created in the above-mentioned embodiment.

[0122] The container management process sends a notification 2 to the system process 2 included in the characteristic container.

[0123] It should be noted that in the embodiment of the present application, the feature container is created on demand. Therefore, a service is usually run in a feature container in a network device.

[0124] Step 440: System process 2 stops the service process.

[0125] Specifically, after receiving the notification 2, the system process 2 obtains the service name of the BGP service from the notification 2. The system process 2 stops running the BGP service.

[0126] According to the service name of the BGP service, the system process 2 also determines whether there is a running BGP process in the characteristic container. If there is no running BGP process in the characteristic container (the BGP process is a process belonging to any instance), it stops running itself and waits for destruction.

[0127] It should be noted that in the embodiment of the present application, the BGP process supports multiple instances, that is, multiple BGP processes of the BGP service can be run simultaneously in the feature container 1, and each BGP process belongs to a different instance. The aforementioned stop instruction may also include an instance identifier, and when the system process 1 generates the notification 2, the instance identifier may also be carried in the notification 2, so that when the system process 2 stops running the BGP service, the BGP process corresponding to the instance identifier is stopped according to the instance identifier.

[0128] Step 450: The service process sends a response 2 to the system process 2.

[0129] Specifically, after the BGP process stops, a response 2 is generated, and the response 2 is used to notify that the BGP service is successfully stopped. The BGP process sends the response 2 to the system process 2.

[0130] Step 460: System process 2 sends response 2 to the container management process.

[0131] Specifically, after receiving the response 2, the system process 2 determines that the BGP service is stopped successfully. The system process 2 sends the response 2 to the container management process.

[0132] Step 470 : The container management process sends a response 2 to the system process 1 .

[0133] Specifically, after receiving the response 2, the container management process determines that the BGP service is stopped successfully. The container management process sends the response 2 to the system process 1.

[0134] Step 480: System process 1 sends response 2 to the CLI process.

[0135] Specifically, after receiving the response 2, the system process 1 determines that the BGP service is stopped successfully. The system process 1 sends the response 2 to the CLI process.

[0136] After receiving response 2, CLI process 1 determines that the BGP service is successfully stopped. The CLI process displays response 2 again through the command line, prompting the user that the BGP service is stopped successfully.

[0137] Combine the following Figure 2 as well as Figure 5 The upgrade process of the feature container provided in the embodiment of the present application is described in detail. Figure 5 , Figure 5 A schematic diagram of a feature container upgrade provided in an embodiment of the present application.

[0138] exist Figure 5 In the example, the network device includes a basic container and a feature container 1. The basic container also includes an upgrade management process. The container ID of the feature container 1 is ID1, and the BGP process has been running, and the BGP process is the BGP master process.

[0139] When the user wants to upgrade the BGP service, he / she inputs an upgrade instruction to the basic container through the command line. The upgrade instruction includes version file 1. Version file 1 is specifically the latest version file of all software running in the network device.

[0140] After receiving the upgrade instruction, the CLI process sends the upgrade instruction to the upgrade management process. After receiving the upgrade instruction, the upgrade management process obtains version file 1 from it. The upgrade management process also obtains version file 2 from system process 1. The version file 2 is the version file of all software currently running in the network device.

[0141] The upgrade management process compares the version of each software included in version file 1 with the version of each software included in version file 2 to determine the software with different versions. The upgrade management process determines the software with different versions as the software to be upgraded. In an embodiment of the present application, the upgrade management process determines that the BGP service is the software to be upgraded.

[0142] The upgrade management process also obtains the customized file for starting the BGP service from the system process 1. Through the customized file, the upgrade management process determines to run the BGP service in a container manner. The upgrade management process obtains the software startup parameter 2 of the BGP service to be upgraded from the version file 1, and generates a notification 3, which includes the software startup parameter 2 of the BGP service.

[0143] After receiving the notification 3, the container management process obtains the software startup parameter 2 from it. The container management process identifies whether a container running the BGP service has been started in the network device. The container management process determines the environment in which the BGP service is currently running in the network device, that is, a single master or multiple masters, by calling an interface provided by a device management module included in the network device.

[0144] In the embodiment of the present application, a feature container 1 providing BGP service already exists in the network device, and the main process of the BGP service runs in the feature container 1. Therefore, the environment in which the BGP service currently runs in the network device is a single master control.

[0145] If the environment in which the BGP service is currently running in the network device is a single master, the container management process creates the feature container 2 again. It can be understood that the container management process can be based on the above Figure 3 The process of creating feature container 2 again is not described in detail here.

[0146] In one example, the container management process creates a property container 2. The container management process sets the container ID and container type of the property container 2, and sets the container type to the environment variables of the container.

[0147] In the embodiment of the present application, the created characteristic container 2 includes a system process 3.

[0148] The container management process sends a notification 3 to the system process 3. After receiving the notification 3, the system process 3 obtains the software startup parameter 2 therefrom. The system process 3 also accesses the dbm (database service) in the basic container to obtain the software configuration data of the BGP service.

[0149] According to the software configuration data of the BGP service and the software startup parameter 2, the system process 3 starts the BGP process locally. After starting the BGP process, the system process 3 generates a registration message 2, which includes the registration attributes of the BGP process. Among them, the registration attributes of the BGP process include the service name, the service group name, the instance number, the HA registration attribute, the LIPC port number, the HA event processing function of the service, the HA message processing function of the service, etc. The system process 3 sends the registration message 2 to the HA module included in the basic container.

[0150] After receiving the registration message 2, the HA module obtains the registration attribute of the BGP process from it. According to the preset decision policy and the registration attribute of the BGP process, the HA module sets the BGP process as a standby process.

[0151] In the embodiment of the present application, the above decision strategy is a strategy for the HA module to assign identity roles to processes. The HA module can determine the software identity based on the registration order of each service, service registration attributes, the primary and backup identities of the node where the service is located, and whether the main process currently exists in the network device. Among them, the HA identity role of the service includes the main process and the backup process.

[0152] It should be noted that in the embodiment of the present application, the BGP service can support multiple instances or a single instance. When supporting multiple instances, that is, multiple processes of the BGP server can be run simultaneously in the feature container 2, and each process belongs to a different instance. The aforementioned upgrade instruction may also include an instance identifier, and the upgrade management process may also carry the instance identifier in the notification 3 when generating the notification 3, so that when the system process 3 starts the BGP process, the instance identifier is set for the BGP process, and the BGP process belongs to the instance corresponding to the instance identifier.

[0153] After the BGP process is started, a response 3 is generated, which is used to notify that the BGP service is successfully started. The BGP process sends the response 3 to the system process 3. After the system process 3 receives the response 3, it determines that the BGP service is successfully started. The system process 3 sends the response 3 to the container management process. After the container management process receives the response 3, it determines that the BGP service is successfully started.

[0154] Meanwhile, after setting the backup process for the BGP process, the HA module will also generate a notification 4, which is used to trigger the feature container 1 to start the backup data process of the BGP service to the feature container 2. It is understandable that the notification 4 may also include an instance identifier.

[0155] After receiving the notification 4, the feature container 1 starts the data backup process. The feature container 1 backs up the data related to the BGP service currently stored in itself to the feature container 2. After receiving all the backup data, the feature container 2 generates and sends a notification 5 to the container management process. The notification 5 is used to enable the container management process to determine that the data backup process has been completed.

[0156] After receiving notification 5, the container management process determines that the data backup process between feature container 1 and feature container 2 has been completed. The container management process generates and sends notification 6 to the feature container, which is used to trigger feature container 1 to exit the BGP service. After sending notification 6, the container management process waits for the first container to stop the main process. It is understandable that notification 5 and notification 6 may also include an instance identifier.

[0157] After receiving the notification 6, the characteristic container 1 stops the operation of its main process according to the notification 6. After stopping the main process, the characteristic container 1 also determines whether there is a running process in itself. If there is no running process in the characteristic container 1, the characteristic container 1 stops its own operation and waits for destruction.

[0158] After feature container 1 stops running, the HA module will sense that the link between it and feature container 1 has been disconnected. The HA module will select a standby process from the registered standby processes of the BGP service and upgrade it to the main process. Usually, in multi-process backup, containers and processes are created and started on demand. In the embodiment of the present application, there is only one standby process for the registered BGP service, so the HA module selects the standby process in feature container 2 to upgrade to the main process to complete the process switching.

[0159] In summary, although the main process of the BGP service stops running at this time, the backup process of the BGP service has been started and upgraded to the main process, so the services supported by the BGP service are not interrupted.

[0160] Based on the same inventive concept, the embodiment of the present application also provides an upgrade device corresponding to the upgrade method. Figure 6 , Figure 6 An upgrade device provided in an embodiment of the present application is applied to a basic container, the basic container is in a network device, the network device also includes a first container, and a main process of a first software runs in the first container. The device includes: a receiving unit 610, a determining unit 620, a starting unit 630, a sending unit 640, an upgrade unit 650, and a display unit 660;

[0161] The determining unit 620 is configured to determine the second software to be upgraded according to the first version file included in the upgrade instruction when the receiving unit 610 receives the upgrade instruction input by the user;

[0162] The starting unit 630 is configured to start a second container if the second software is the first software, and run a standby process of the first software in the second container;

[0163] The sending unit 640 is configured to send a second notification to the first container if the receiving unit 610 receives the first notification sent by the second container, so that the first container stops the running of the main process according to the second notification;

[0164] The upgrade unit 650 is used to upgrade the standby process running in the second container to the main process;

[0165] The display unit 660 is used to display an upgrade response to prompt the user that the upgrade is completed.

[0166] Optionally, the receiving unit 610 is further configured to receive a startup instruction input by the user, wherein the startup instruction includes a configuration file of the first software, and the configuration file includes a first software startup parameter of the first software;

[0167] The apparatus further includes: a creation unit (not shown in the figure), configured to create the first container if the container for running the first software is not started in the network device;

[0168] The sending unit 640 is further configured to send a third notification to the first container, where the third notification includes the first software startup parameter and the first software configuration data, so that the first container starts the first process locally according to the first software startup parameter and the first software configuration data;

[0169] The receiving unit 610 is further configured to receive a first registration message sent by the first container, where the first registration message includes a first software registration attribute;

[0170] The device further includes: a setting unit (not shown in the figure), configured to set the first process as the main process according to a preset decision strategy and the first software registration attribute;

[0171] The receiving unit 610 is further configured to receive a fourth notification sent by the first container;

[0172] The display unit 660 is further configured to display a startup response according to the fourth notification to prompt the user that the startup is completed.

[0173] Optionally, the determining unit 620 is specifically configured to obtain second version files of all software currently running in the network device;

[0174] Compare the version of each software included in the first version file with the version of each software included in the second version file to determine the software with different versions;

[0175] The software with a different version is determined as the second software.

[0176] Optionally, the startup unit 630 is specifically configured to obtain a second software startup parameter of the first software to be upgraded from the first version file;

[0177] If the environment in which the first software is currently running in the network device is a single master control, creating a second container;

[0178] Sending a fifth notification to the second container, where the fifth notification includes the second software startup parameter and the second software configuration data, so that the second container starts the second process locally according to the second software startup parameter and the second software configuration data;

[0179] receiving a second registration message sent by the second container, where the second registration message includes a second software registration attribute;

[0180] According to a preset decision strategy and the second software registration attribute, setting the second process as the standby process;

[0181] A sixth notification is sent to the first container, so that the first container backs up data to the second container, and after backing up the data, the second container sends the first notification to the base container.

[0182] Optionally, the receiving unit 610 is further configured to receive a stop instruction input by the user, wherein the stop instruction includes a software name of the third software;

[0183] The determining unit 620 is further configured to determine, according to the software name, a third container for running the software indicated by the software name;

[0184] The sending unit 640 is further configured to send a seventh notification to the third container, so that the third container stops running the process of the third software, and stops the third container when there is no running process in the third container;

[0185] The display unit 660 is further configured to display a stop response to prompt the user that the stop is complete if the receiving unit 610 receives the eighth notification sent by the third container.

[0186] Therefore, by applying the upgrade device provided by the present application, when an upgrade instruction input by the user is received, the basic container determines the second software to be upgraded according to the first version file included in the upgrade instruction; if the second software is the first software, the basic container starts the second container, and the standby process of the first software runs in the second container; if the first notification sent by the second container is received, the basic container sends a second notification to the first container, so that the first container stops the running of the main process according to the second notification; the basic container upgrades the standby process running in the second container to the main process, and displays an upgrade response to prompt the user that the upgrade is complete.

[0187] In this way, for the single-master environment in the network device, feature containers are used to isolate the software from each other; upgrades are achieved by starting the master and backup feature containers, avoiding business interruptions. In addition, feature containers are created on demand, saving network device software and hardware resources. This solves the problem that the existing dual-container upgrade method cannot upgrade some software and that network devices with insufficient hardware resources cannot start multiple operating systems.

[0188] Based on the same inventive concept, the embodiment of the present application also provides a network device, such as Figure 7 As shown, it includes a processor 710, a transceiver 720 and a machine-readable storage medium 730, the machine-readable storage medium 730 stores machine-executable instructions that can be executed by the processor 710, and the processor 710 is prompted by the machine-executable instructions to execute the upgrade method provided in the embodiment of the present application. Figure 6 The upgrade device shown can be used as Figure 7 The network device hardware structure shown is implemented.

[0189] The computer-readable storage medium 730 may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk storage. Optionally, the computer-readable storage medium 730 may also be at least one storage device located away from the processor 710.

[0190] The processor 710 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0191] In the embodiment of the present application, the processor 710 reads the machine executable instructions stored in the machine readable storage medium 730, and the machine executable instructions enable the processor 710 itself and the transceiver 720 to execute the upgrade method described in the aforementioned embodiment of the present application.

[0192] In addition, an embodiment of the present application provides a machine-readable storage medium 730, which stores machine-executable instructions. When called and executed by the processor 710, the machine-executable instructions prompt the processor 710 itself and the calling transceiver 720 to execute the upgrade method described in the aforementioned embodiment of the present application.

[0193] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0194] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0195] As for the embodiments of the upgrade device and the machine-readable storage medium, since the method contents involved are basically similar to those of the aforementioned method embodiments, the description is relatively simple, and the relevant parts may refer to the partial description of the method embodiments.

[0196] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. An upgrading method, characterized in that: The method is applied to a basic container, the basic container is in a network device, the network device also includes a first container, and a main process of a first software runs in the first container. The method includes: When receiving an upgrade instruction input by a user, determining the second software to be upgraded according to the first version file included in the upgrade instruction; If the second software is the first software, starting a second container, and running a standby process of the first software in the second container; If the first notification sent by the second container is received, sending a second notification to the first container, so that the first container stops the running of the main process according to the second notification; The standby process running in the second container is upgraded to the main process, and an upgrade response is displayed to prompt the user that the upgrade is complete.

2. The method according to claim 1, characterized in that Before receiving the upgrade instruction input by the user, the method further includes: receiving a startup instruction input by the user, wherein the startup instruction includes a configuration file of the first software, and the configuration file includes a first software startup parameter of the first software; If the container running the first software is not started in the network device, creating the first container; Sending a third notification to the first container, where the third notification includes the first software startup parameter and the first software configuration data, so that the first container starts the first process locally according to the first software startup parameter and the first software configuration data; receiving a first registration message sent by the first container, where the first registration message includes a first software registration attribute; According to a preset decision strategy and the first software registration attribute, setting the first process as the main process; receiving a fourth notification sent by the first container; According to the fourth notification, a startup response is displayed to prompt the user that the startup is completed.

3. The method according to claim 1, characterized in that The step of determining the second software to be upgraded according to the first version file included in the upgrade instruction specifically includes: Obtaining second version files of all software currently running in the network device; Compare the version of each software included in the first version file with the version of each software included in the second version file to determine the software with different versions; The software with a different version is determined as the second software.

4. The method according to claim 1, characterized in that: The starting of the second container specifically includes: Acquire a second software startup parameter of the first software to be upgraded from the first version file; If the environment in which the first software is currently running in the network device is a single master control, creating a second container; Sending a fifth notification to the second container, where the fifth notification includes the second software startup parameter and the second software configuration data, so that the second container starts the second process locally according to the second software startup parameter and the second software configuration data; receiving a second registration message sent by the second container, where the second registration message includes a second software registration attribute; According to a preset decision strategy and the second software registration attribute, setting the second process as the standby process; A sixth notification is sent to the first container, so that the first container backs up data to the second container, and after backing up the data, the second container sends the first notification to the base container.

5. The method according to claim 1, characterized in that: The method further comprises: receiving a stop instruction input by the user, wherein the stop instruction includes a software name of the third software; According to the software name, determining a third container for running the software indicated by the software name; Sending a seventh notification to the third container so that the third container stops running the process of the third software, and when no running process exists in the third container, stops the third container; If the eighth notification sent by the third container is received, a stop response is displayed to prompt the user to stop the completion.

6. An upgrading device, characterized in that: The device is applied to a basic container, the basic container is in a network device, the network device also includes a first container, a main process of a first software runs in the first container, and the device includes: a receiving unit, a determining unit, a starting unit, a sending unit, an upgrading unit, and a display unit; The determining unit is configured to determine the second software to be upgraded according to the first version file included in the upgrading instruction when the receiving unit receives the upgrading instruction input by the user; The starting unit is configured to start a second container if the second software is the first software, wherein the second container runs a standby process of the first software; the sending unit is configured to send a second notification to the first container if the receiving unit receives the first notification sent by the second container, so that the first container stops the running of the main process according to the second notification; The upgrading unit is configured to upgrade the standby process running in the second container to a main process; The display unit is used to display the upgrade response to prompt the user that the upgrade is completed.

7. The device according to claim 6, characterized in that The receiving unit is further configured to receive a startup instruction input by the user, wherein the startup instruction includes a configuration file of the first software, and the configuration file includes a first software startup parameter of the first software; The apparatus further includes: a creating unit, configured to create the first container if the container running the first software is not started in the network device; The sending unit is further configured to send a third notification to the first container, where the third notification includes the first software startup parameter and the first software configuration data, so that the first container starts the first process locally according to the first software startup parameter and the first software configuration data; The receiving unit is further configured to receive a first registration message sent by the first container, where the first registration message includes a first software registration attribute; The device further includes: a setting unit, configured to set the first process as the main process according to a preset decision strategy and the first software registration attribute; The receiving unit is further configured to receive a fourth notification sent by the first container; The display unit is further configured to display a startup response according to the fourth notification to prompt the user that the startup is completed.

8. The device according to claim 7, characterized in that The determining unit is specifically used to obtain the second version files of all software currently running in the network device; Compare the version of each software included in the first version file with the version of each software included in the second version file to determine the software with different versions; The software with a different version is determined as the second software.

9. The device according to claim 6, characterized in that The startup unit is specifically used to obtain the second software startup parameter of the first software to be upgraded from the first version file; If the environment in which the first software is currently running in the network device is a single master control, creating a second container; Sending a fifth notification to the second container, where the fifth notification includes the second software startup parameter and the second software configuration data, so that the second container starts the second process locally according to the second software startup parameter and the second software configuration data; receiving a second registration message sent by the second container, where the second registration message includes a second software registration attribute; According to a preset decision strategy and the second software registration attribute, setting the second process as the standby process; A sixth notification is sent to the first container, so that the first container backs up data to the second container, and after backing up the data, the second container sends the first notification to the base container.

10. The device according to claim 6, characterized in that The receiving unit is further configured to receive a stop instruction input by the user, wherein the stop instruction includes a software name of the third software; The determining unit is further configured to determine, according to the software name, a third container for running the software indicated by the software name; The sending unit is further configured to send a seventh notification to the third container, so that the third container stops running the process of the third software, and stops the third container when there is no running process in the third container; The display unit is further configured to display a stop response if the receiving unit receives an eighth notification sent by the third container, so as to prompt the user that the stop is completed.

Images