SDK data recovery method and device of single machine ISSU

Abstract

The invention provides an SDK (Software Development Kit) data recovery method and device for a single machine ISSU (Inter-Service Software Unit), and the method comprises the steps: building a standby container under the condition of receiving an ISSU upgrading instruction, starting a software development kit SDK process in the standby container, closing the writing authority of the SDK process in the standby container to a forwarding chip, and carrying out system starting data initialization; under the condition that system starting data initialization is completed, forwarding table items of the SDK process in the original container are added to the SDK process in the standby container; and starting a write permission of the SDK process in the standby container to a forwarding chip, and synchronizing forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container. By applying the embodiment of the invention, the forwarding table item of the SDK process can be recovered in a stand-alone ISSU process, and the code modification amount is reduced to be extremely low, so that the integrity of the SDK code is ensured.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a method and device for recovering SDK data of a stand-alone ISSU. Background Art

[0002] ISSU (In-Service Software Upgrade) is a highly reliable way to upgrade the startup software of a device. ISSU upgrade can ensure that services are not interrupted or the interruption time is short during the upgrade process.

[0003] Existing ISSU technology is no longer limited to stacked networking, but has developed to implement ISSU software upgrades on a single network device with the help of containers. Its core idea is to separate programs and data, and the program runs in the container. During the ISSU upgrade, the program in the container is replaced and upgraded as a whole, while the data remains unchanged, so as to achieve the upgrade effect without interrupting the business.

[0004] SDK (Software Development Kit) driver code is the chip supporting code provided by the chip manufacturer. Its data storage is complex. According to the current data storage method of shared memory or database, the data structure of the SDK code must be modified, which will destroy the independence of the SDK code. Excessive modifications to the SDK code will also cause a great burden on future SDK upgrades. Summary of the invention

[0005] The present invention provides a method and device for recovering SDK data of a single-machine ISSU, so as to solve the problem in the prior art that the data structure of the SDK code is greatly modified by the ISSU upgrade.

[0006] According to a first aspect of an embodiment of the present invention, a method for restoring SDK data of a single-machine ISSU is provided, comprising:

[0007] Upon receiving an ISSU upgrade instruction, a standby container is created, a software development kit SDK process is started in the standby container, the write permission of the SDK process in the standby container to the forwarding chip is disabled, and system startup data is initialized;

[0008] When the system startup data initialization is completed, the forwarding table entry of the SDK process in the original container is added to the SDK process in the standby container;

[0009] The write permission of the SDK process in the standby container to the forwarding chip is enabled, and the forwarding table entries of the forwarding chip are synchronized according to the forwarding table entries of the SDK process in the standby container.

[0010] According to a second aspect of an embodiment of the present invention, there is provided a creating unit, which is used to create a standby container when receiving an ISSU upgrade instruction for an uninterrupted service upgrade;

[0011] an initialization unit, used to start a software development kit SDK process in the standby container, close the write permission of the SDK process in the standby container to the forwarding chip, and perform system startup data initialization;

[0012] A data recovery unit, used to add the forwarding table entry of the SDK process in the original container to the SDK process in the standby container when the system startup data initialization is completed;

[0013] The synchronization unit is used to enable the write permission of the SDK process in the standby container to the forwarding chip, and synchronize the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container.

[0014] By applying the technical solution disclosed in the present invention, when an ISSU upgrade instruction is received, a standby container is created, an SDK process is started in the standby container, the write permission of the SDK process in the standby container to the forwarding chip is closed, and system startup data initialization is performed; when the system startup data initialization is completed, the forwarding table items of the SDK process in the original container are added to the SDK process in the standby container, and then, the write permission of the SDK process in the standby container to the forwarding chip is enabled, and the forwarding table items of the forwarding chip are synchronized according to the forwarding table items of the SDK process in the standby container. Compared with the implementation scheme of storing data in a shared memory or a database in the traditional scheme, the scheme provided by the embodiment of the present invention avoids the modification of the data structure of the SDK code by closing the chip write permission and retracing the chip startup and table item establishment process, which can not only ensure that the forwarding table items of the SDK process can be restored during the single-machine ISSU process, but also reduce the code modification amount to an extremely low level, thereby ensuring the integrity of the SDK code. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic diagram of the implementation principle of a single-machine ISSU;

[0016] Figure 2 It is a flowchart of a method for recovering SDK data of a single-machine ISSU provided by an embodiment of the present invention;

[0017] Figure 3 It is a flowchart of a method for recovering SDK data of a single-machine ISSU provided by an embodiment of the present invention;

[0018] Figure 4 It is a structural schematic diagram of an SDK data recovery device for a stand-alone ISSU provided by an embodiment of the present invention;

[0019] Figure 5 It is a structural schematic diagram of an SDK data recovery device for a stand-alone ISSU provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0020] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the implementation principle of a single-machine ISSU is briefly described below.

[0021] like Figure 1 As shown, network devices (such as switches or routers, etc.) can include three levels: forwarding chip, kernel state, and user state. Among them:

[0022] A forwarding chip refers to a hardware module of a network device, whose main function is to forward or process data.

[0023] Kernel state is the core execution mode of the operating system. It runs the core part of the operating system and is responsible for system-level tasks such as hardware management, process scheduling, and memory management.

[0024] User state is the normal mode in which processes in an operating system run. User state programs cannot directly access hardware resources and can only access them indirectly through the system call interface provided by the operating system.

[0025] In order to implement stand-alone ISSU, user-state programs run in containers, and user-state data is independent of the container and stored using LMDB databases, shared memory, and other methods to achieve cross-container access.

[0026] During the ISSU upgrade process, the kernel state and forwarding chip remain unchanged, and the user state is upgraded.

[0027] During the user-mode upgrade process, a new container can be created and the user-mode process can be restarted in the channel container using the new version.

[0028] Among them, the user-mode process includes the SDK process, which is the bridge for the driver to access the chip. It includes functions such as chip initialization, address mapping of sending and receiving messages, reading and writing of registers, and management of chip transfer tables.

[0029] In order to make the above-mentioned purposes, features and advantages of the embodiments of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention are further described in detail below with reference to the accompanying drawings.

[0030] See also Figure 2 , is a flow chart of a method for recovering SDK data of a single-machine ISSU provided by an embodiment of the present invention. Figure 2 As shown, the SDK data recovery method of the stand-alone ISSU may include the following steps:

[0031] Step 201: When an ISSU upgrade instruction is received, a standby container is created, an SDK process is started in the standby container, the write permission of the SDK process in the standby container to the forwarding chip is disabled, and system startup data is initialized.

[0032] In the embodiment of the present invention, in order to implement stand-alone ISSU, during the ISSU process, a backup container may be created, and an SDK process may be started in the backup container.

[0033] It should be noted that, in addition to running the SDK process, the standby container also runs an upgraded version of the business process that is consistent with the business process running in the original container.

[0034] In the embodiment of the present invention, in order to ensure the initial state of the environment and data of the SDK process in the standby container, necessary initialization settings need to be performed.

[0035] In order to avoid the modification of the hardware forwarding table entries during the SDK process initialization, the SDK process's write permission to the forwarding chip can be turned off during the SDK process initialization (that is, the SDK process's write permission to the chip registers of the forwarding chip is turned off). Thus, during the chip initialization process of the SDK process, the SDK code software is initialized instead of the chip hardware.

[0036] Among them, during the initialization process of the SDK code software, the system startup data can be initialized.

[0037] Exemplarily, the system startup data may include, but is not limited to, device form parameters, chip status, and initial software data status.

[0038] Among them, the device form factor parameters refer to the physical structure and configuration of the device at the hardware level, including the size, shape, interface type, and supported functional modules of the hardware platform.

[0039] The chip status refers to the operating status and configuration of the chip during the initialization process. The chip status affects the startup, function implementation and performance of the entire device.

[0040] The initial software data state refers to the initial data or configuration state that the operating system or application depends on when the device starts up. This data is the basis for starting the system and application.

[0041] Step 202: When the system startup data initialization is completed, the forwarding table entry of the SDK process in the original container is added to the SDK process in the standby container.

[0042] In the embodiment of the present invention, when the SDK process in the standby container is initialized, the forwarding table entry of the SDK process can be added to the SDK process in the standby container to implement SDK service data recovery.

[0043] Exemplarily, the SDK process may call an API (Application Programming Interface) interface provided by the forwarding chip to add the forwarding table entry of the SDK process saved before the ISSU upgrade to the SDK process in the standby container.

[0044] Exemplarily, the forwarding table entries of the SDK process may include, but are not limited to, forwarding table entries of modules such as PORT, FDB (Forwarding Database), IP, and TCAM (Ternary Content Addressable Memory).

[0045] Step 203: Enable the write permission of the backup container SDK process to the forwarding chip, and synchronize the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the backup container.

[0046] In an embodiment of the present invention, when the SDK business data recovery is completed, the SDK process's write permission to the forwarding chip can be reopened, and the SDK process's normal access to the forwarding chip can be restored, ensuring that the system enters a normal operating state after the upgrade. The forwarding table entries of the forwarding chip are synchronized based on the forwarding table entries of the SDK process in the backup container, and the complete matching of all table entries is ensured through compliance processes, so that the system can enter stable operation with optimized performance.

[0047] It can be seen that in Figure 2 In the method flow shown, when an ISSU upgrade instruction is received, a backup container is created, an SDK process is started in the backup container, the write permission of the SDK process in the backup container to the forwarding chip is closed, and the system startup data is initialized; when the system startup data is initialized, the forwarding table items of the SDK process in the original container are added to the SDK process in the backup container, and then, the write permission of the SDK process in the backup container to the forwarding chip is enabled, and the forwarding table items of the forwarding chip are synchronized according to the forwarding table items of the SDK process in the backup container. Compared with the implementation scheme of storing data in shared memory or database in the traditional scheme, the scheme provided by the embodiment of the present invention avoids the modification of the data structure of the SDK code by closing the chip write permission and retracing the chip startup and table item establishment process, which can not only ensure that the forwarding table items of the SDK process can be restored during the single-machine ISSU process, but also reduce the amount of code modification to an extremely low level, thereby ensuring the integrity of the SDK code.

[0048] In some embodiments, disabling the write permission of the SDK process in the standby container to the forwarding chip may include:

[0049] For the interface of the SDK process in the standby container accessing the forwarding chip, the value of the first write permission flag bit corresponding to the interface is set to a first value; wherein the value of the first write permission flag bit is the first value, indicating that the SDK process has closed the write permission to the forwarding chip;

[0050] The above-mentioned enabling of the SDK process in the standby container to write to the forwarding chip may include:

[0051] The value of the first write permission flag is set to the second value; wherein the value of the first write permission flag is the second value, indicating that the SDK process has enabled the write permission for the forwarding chip.

[0052] Exemplarily, in order to implement control of the write permission of the SDK process in the standby container to the forwarding chip, a flag bit (which may be called a first write permission flag bit) may be set for the interface of the SDK process in the standby container accessing the forwarding chip.

[0053] The value of the first write flag bit may include a first value (such as 0) and a second value (such as 1). The value of the first write permission flag bit is the first value, indicating that the SDK process has closed the write permission to the forwarding chip; the value of the first write permission flag bit is the second value, indicating that the SDK process has opened the write permission to the forwarding chip.

[0054] Correspondingly, when it is necessary to close the write permission of the SDK process in the standby container to the forwarding chip, the value of the first write permission flag bit can be set to the first value.

[0055] When it is necessary to enable the write permission of the SDK process in the standby container to the forwarding chip, the value of the first write permission flag bit may be set to the second value.

[0056] In some other embodiments, the above-mentioned disabling the write permission of the SDK process in the standby container to the forwarding chip may include:

[0057] Disable the write permission of the SDK process in the standby container to the forwarding chip. This can include:

[0058] For the interface of the SDK process in the standby container accessing the forwarding chip, a second write permission flag is set; wherein the second write permission flag is used to indicate that the write permission of the SDK process in the standby container to the forwarding chip is closed;

[0059] The above-mentioned enabling of the SDK process in the standby container to write to the forwarding chip may include:

[0060] Delete the second write permission flag.

[0061] Exemplarily, in order to improve the control efficiency of the SDK process's write permission to the forwarding chip and save storage resources, when it is necessary to close the access permission of the SDK process in the backup container to the forwarding chip, a flag (which may be called the second write permission flag) can be set for the interface of the SDK process in the backup container to access the forwarding chip.

[0062] The second write permission flag is used to indicate that the write permission of the SDK process in the standby container to the forwarding chip is closed.

[0063] That is, when the interface for the SDK process in the standby container to access the forwarding chip is set with the second write permission flag bit, it indicates that the write permission of the SDK process in the standby container to the forwarding chip is closed.

[0064] Accordingly, when it is necessary to reopen the write permission of the SDK process in the standby container to the forwarding chip, the second write permission flag bit can be deleted.

[0065] In some embodiments, when an ISSU upgrade instruction is received, the following steps may also be included:

[0066] Through the SDK process in the original container, the application programming interface provided by the forwarding chip is called to read and save the forwarding table entries of the SDK process in the original container;

[0067] The above-mentioned adding the forwarding table entry of the SDK process in the original container to the SDK process in the standby container may include:

[0068] The SDK process in the standby container calls the application programming interface provided by the forwarding chip to add the saved forwarding table entry of the SDK process to the SDK process in the standby container.

[0069] Exemplarily, in order to restore SDK data during the ISSU upgrade process, before initializing the SDK process of the backup container, the forwarding table entries of the SDK process in the original container may be read and saved in batches.

[0070] Accordingly, when an ISSU upgrade instruction is received, the forwarding table entry of the SDK process in the original container can be read and saved.

[0071] Exemplarily, the SDK process in the original container can call the API interface provided by the forwarding chip to batch read and save the forwarding table entries of the SDK process in the original container, such as saving them in a file, thereby ensuring that the SDK data structure is not destroyed and reducing the modification of the SDK code.

[0072] After the system startup data is initialized in the above manner, the SDK process in the backup container can call the API interface provided by the forwarding chip to add the saved forwarding table entries of the SDK process to the SDK process in the backup container to realize SDK business data recovery.

[0073] In some embodiments, synchronizing the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container may include:

[0074] Compare the forwarding table entries of the SDK process in the standby container with the forwarding table entries of the forwarding chip;

[0075] For the forwarding table entries that exist in the SDK process of the backup container but do not exist in the forwarding chip, add them to the forwarding chip;

[0076] Forwarding table entries that do not exist in the SDK process of the backup container but exist in the forwarding chip are deleted from the forwarding chip.

[0077] For example, when the SDK business data recovery is completed, the SDK process can be given write permission to the forwarding chip, and a consistency check can be performed on the forwarding table entries in the SDK process and the forwarding table entries in the forwarding chip to ensure the consistency of the forwarding table entries in the SDK process (which can be called a soft table) and the forwarding table entries in the forwarding chip (which can be called a hard table).

[0078] Exemplarily, the forwarding table entries of the SDK process in the backup container can be compared with the forwarding table entries of the forwarding chip; the forwarding table entries that exist in the SDK process of the backup container but do not exist in the forwarding chip are added to the forwarding chip; the forwarding table entries that do not exist in the SDK process of the backup container but exist in the forwarding chip are deleted from the forwarding chip.

[0079] It should be noted that in the embodiment of the present invention, during the ISSU upgrade process, in addition to restarting the SDK process and restoring data in the above manner, other user-mode processes can also be restarted and data restored in the backup container, and the specific implementation method is not described here. When all user-mode processes have completed the restart and data recovery, the backup container can also be switched to the new main container to achieve the upgrade effect without interrupting the service.

[0080] In order to enable those skilled in the art to better understand the technical solution provided by the embodiment of the present invention, the technical solution provided by the embodiment of the present invention is described below in conjunction with specific application scenarios.

[0081] In this embodiment, considering that when a normal device is started, cpssInitSystem (an initialization function) is called to initialize the SDK code and the hardware forwarding chip, and the stand-alone ISSU needs to meet two points: first, the forwarding table entries of the forwarding chip are not modified during the ISSU upgrade, and the messages need to be forwarded according to the original rules without packet loss; second, the SDK data table entries need to be restored and maintain normal operation without exceptions.

[0082] In order to meet the above conditions and reduce the modification of SDK code during SDK process initialization, and to realize the recovery of SDK process data without changing the SDK data structure, the initialization of SDK process during ISSU upgrade can be divided into three stages: initialization stage, data recovery stage, and completion stage.

[0083] The relevant processing of the above three stages is explained below respectively.

[0084] 1. Initialization phase.

[0085] Exemplarily, the initialization phase is used to ensure the initial state of the SDK environment and data and perform necessary initialization settings.

[0086] During the initialization phase, a backup container may be created, the SDK process may be started in the backup container, the SDK process's write permission to the forwarding chip may be disabled, and the system startup data may be initialized.

[0087] For example, cpssInitSystem may be called to perform chip initialization, and initialize device form parameters, chip status, and initial software data status.

[0088] Among them, since the write permission is closed, the status on the hardware chip is not actually changed, but the global status data of the software is ready.

[0089] 2. Data recovery phase.

[0090] After the system startup data initialization is completed in the above manner, the data recovery phase can be entered.

[0091] At this stage, the SDK software program is ready and can deliver the attributes of the forwarding module and add and delete entries.

[0092] At this stage, the SDK process in the backup container can call the API interface provided by the forwarding chip to add the forwarding table entries of the SDK process saved before the ISSU upgrade (that is, the forwarding table entries of the SDK process in the original container saved when the ISSU upgrade instruction is received) back to the SDK process of the backup container.

[0093] Exemplarily, the forwarding table entries of the SDK process may include table entry data of modules such as PORT, FDB, IP, and TCAM.

[0094] Through the above method, data recovery of SDK table items is realized, and the principle of single-machine ISSU upgrade not to modify the forwarding table items in the forwarding chip is met.

[0095] 3. Completion stage.

[0096] After completing the business data recovery of the SDK process in the above manner, you can enter the completion phase to perform system corrections and performance optimization to ensure that the system enters a normal operating state after the upgrade.

[0097] At this stage, the normal access of the SDK process in the backup container to the forwarding chip can be restored, and the forwarding table entries of the SDK process in the backup container and the forwarding table entries in the forwarding chip can be checked for consistency to ensure the consistency of the SDK's soft table and the table entries in the hardware forwarding chip.

[0098] Exemplarily, the forwarding table entries of the SDK process in the backup container can be compared with the forwarding table entries of the forwarding chip; the forwarding table entries that exist in the SDK process of the backup container but do not exist in the forwarding chip are added to the forwarding chip; the forwarding table entries that do not exist in the SDK process of the backup container but exist in the forwarding chip are deleted from the forwarding chip.

[0099] For example, the overall flow chart of the above process can be as follows: Figure 3 shown.

[0100] Through the above method, the traditional data storage transformation method is broken. The SDK code provided by the chip manufacturer is still regarded as a whole. Most of the workload of SDK data recovery in ISSU upgrade is transferred to the outside of the SDK code. By limiting or allowing corresponding operations in different states, it is ensured that the data processing in each stage meets the requirements of ISSU. It can realize chip initialization and SDK data recovery, and meet the requirements of single-machine ISSU upgrade. The modification amount of SDK code is extremely small, which ensures the integrity of SDK code and facilitates maintenance.

[0101] See also Figure 4 , is a structural diagram of a SDK data recovery device for a single ISSU provided by an embodiment of the present invention, such as Figure 4 As shown, the SDK data recovery device of the stand-alone ISSU may include:

[0102] A creating unit 410 is configured to create a standby container upon receiving an ISSU upgrade instruction;

[0103] The initialization unit 420 is used to start a software development kit SDK process in the standby container, close the write permission of the SDK process in the standby container to the forwarding chip, and perform system startup data initialization;

[0104] The data recovery unit 430 is used to add the forwarding table entry of the SDK process in the original container to the SDK process in the standby container when the system startup data initialization is completed;

[0105] The synchronization unit 440 is used to enable the write permission of the SDK process in the standby container to the forwarding chip, and synchronize the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container.

[0106] In some embodiments, the initialization unit 420 closes the write permission of the SDK process in the standby container to the forwarding chip, including:

[0107] For the interface of the SDK process in the standby container accessing the forwarding chip, the value of the first write permission flag bit corresponding to the interface is set to a first value; wherein the value of the first write permission flag bit is the first value, indicating that the SDK process has closed the write permission to the forwarding chip;

[0108] The synchronization unit 440 enables the SDK process in the standby container to write to the forwarding chip, including:

[0109] The value of the first write permission flag is set to a second value; wherein the value of the first write permission flag is the second value, indicating that the SDK process has enabled the write permission for the forwarding chip.

[0110] In some embodiments, the initialization unit 420 closes the write permission of the SDK process in the standby container to the forwarding chip, including:

[0111] For the interface of the SDK process in the standby container accessing the forwarding chip, a second write permission flag is set; wherein the second write permission flag is used to indicate that the write permission of the SDK process in the standby container to the forwarding chip is closed;

[0112] The synchronization unit 440 enables the SDK process in the standby container to write to the forwarding chip, including:

[0113] Delete the second write permission flag.

[0114] In some embodiments, Figure 5 As shown, the SDK data recovery device of the stand-alone ISSU may include:

[0115] The data storage unit 450 is used to call the application programming interface provided by the forwarding chip through the SDK process in the original container to read and save the forwarding table items of the SDK process in the original container;

[0116] The data recovery unit 430 adds the forwarding table entry of the SDK process in the original container to the SDK process in the standby container, including:

[0117] The SDK process in the standby container calls the application programming interface provided by the forwarding chip, and adds the saved forwarding table entry of the SDK process to the SDK process in the standby container.

[0118] In some embodiments, the synchronization unit 440 synchronizes the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container, including:

[0119] Comparing the forwarding table entry of the SDK process in the standby container with the forwarding table entry of the forwarding chip;

[0120] For the forwarding table entries that exist in the SDK process of the standby container but do not exist in the forwarding chip, add them to the forwarding chip;

[0121] The forwarding table entry that does not exist in the SDK process of the backup container but exists in the forwarding chip is deleted from the forwarding chip.

[0122] An embodiment of the present invention further provides an electronic device, including a processor and a memory, wherein the memory is used to store a computer program; and the processor is used to implement the SDK data recovery method for the stand-alone ISSU described above when executing the program stored in the memory.

[0123] The memory mentioned in this article can be any electronic, magnetic, optical or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, the machine-readable storage medium can be: RAM (RadomAccess Memory, random access memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as CD, DVD, etc.), or similar storage medium, or a combination thereof.

[0124] The embodiment of the present invention further provides a machine-readable storage medium, such as the above-mentioned memory, in which machine-executable instructions are stored, and when the machine-executable instructions are executed by a processor, the SDK data recovery method for the stand-alone ISSU described above is implemented. For example, the machine-readable storage medium may be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0125] An embodiment of the present invention further provides a computer program product, which stores a computer program, and when a processor executes the computer program, it prompts the processor to execute the SDK data recovery method for the stand-alone ISSU described above.

Claims

1. A method for recovering SDK data of a single-machine ISSU, characterized in that: include: Upon receiving an ISSU upgrade instruction, a standby container is created, a software development kit SDK process is started in the standby container, the write permission of the SDK process in the standby container to the forwarding chip is disabled, and system startup data is initialized; When the system startup data initialization is completed, the forwarding table entry of the SDK process in the original container is added to the SDK process in the standby container; The write permission of the SDK process in the standby container to the forwarding chip is enabled, and the forwarding table entries of the forwarding chip are synchronized according to the forwarding table entries of the SDK process in the standby container.

2. The method according to claim 1, characterized in that The step of disabling the write permission of the SDK process in the standby container to the forwarding chip includes: For the interface of the SDK process in the standby container accessing the forwarding chip, the value of the first write permission flag bit corresponding to the interface is set to a first value; wherein the value of the first write permission flag bit is the first value, indicating that the SDK process has closed the write permission to the forwarding chip; The step of enabling the SDK process in the standby container to have write permission on the forwarding chip includes: The value of the first write permission flag is set to a second value; wherein the value of the first write permission flag is the second value, indicating that the SDK process has enabled the write permission for the forwarding chip.

3. The method according to claim 1, characterized in that The step of disabling the write permission of the SDK process in the standby container to the forwarding chip includes: For the interface of the SDK process in the standby container accessing the forwarding chip, a second write permission flag is set; wherein the second write permission flag is used to indicate that the write permission of the SDK process in the standby container to the forwarding chip is closed; The step of enabling the SDK process in the standby container to have write permission on the forwarding chip includes: Delete the second write permission flag.

4. The method according to claim 1, characterized in that: In the case where an ISSU upgrade instruction is received, the method further includes: Through the SDK process in the original container, the application programming interface provided by the forwarding chip is called to read and save the forwarding table entries of the SDK process in the original container; The step of adding the forwarding table entry of the SDK process in the original container to the SDK process in the standby container includes: The SDK process in the standby container calls the application programming interface provided by the forwarding chip, and adds the saved forwarding table entry of the SDK process to the SDK process in the standby container.

5. The method according to claim 1, characterized in that: The step of synchronizing the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container includes: Comparing the forwarding table entry of the SDK process in the standby container with the forwarding table entry of the forwarding chip; For the forwarding table entries that exist in the SDK process of the standby container but do not exist in the forwarding chip, add them to the forwarding chip; The forwarding table entry that does not exist in the SDK process of the backup container but exists in the forwarding chip is deleted from the forwarding chip.

6. A SDK data recovery device for a single-machine ISSU, characterized in that: include: A creating unit, configured to create a standby container when receiving an ISSU upgrade instruction; an initialization unit, used to start a software development kit SDK process in the standby container, close the write permission of the SDK process in the standby container to the forwarding chip, and perform system startup data initialization; A data recovery unit, used to add the forwarding table entry of the SDK process in the original container to the SDK process in the standby container when the system startup data initialization is completed; The synchronization unit is used to enable the write permission of the SDK process in the standby container to the forwarding chip, and synchronize the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container.

7. The device according to claim 6, characterized in that The initialization unit closes the write permission of the SDK process in the standby container to the forwarding chip, including: For the interface of the SDK process in the standby container accessing the forwarding chip, the value of the first write permission flag bit corresponding to the interface is set to a first value; wherein the value of the first write permission flag bit is the first value, indicating that the SDK process has closed the write permission to the forwarding chip; The synchronization unit enables the SDK process in the standby container to write to the forwarding chip, including: The value of the first write permission flag is set to a second value; wherein the value of the first write permission flag is the second value, indicating that the SDK process has enabled the write permission for the forwarding chip.

8. The device according to claim 6, characterized in that The initialization unit closes the write permission of the SDK process in the standby container to the forwarding chip, including: For the interface of the SDK process in the standby container accessing the forwarding chip, a second write permission flag is set; wherein the second write permission flag is used to indicate that the write permission of the SDK process in the standby container to the forwarding chip is closed; The synchronization unit enables the SDK process in the standby container to write to the forwarding chip, including: Delete the second write permission flag.

9. The device according to claim 6, characterized in that The device also includes: The data storage unit is used to call the application programming interface provided by the forwarding chip through the SDK process in the original container to read and save the forwarding table items of the SDK process in the original container; The data recovery unit adds the forwarding table entry of the SDK process in the original container to the SDK process in the standby container, including: The SDK process in the standby container calls the application programming interface provided by the forwarding chip, and adds the saved forwarding table entry of the SDK process to the SDK process in the standby container.

10. The device according to claim 6, characterized in that The synchronization unit synchronizes the forwarding table entries of the forwarding chip according to the forwarding table entries of the SDK process in the standby container, including: Comparing the forwarding table entry of the SDK process in the standby container with the forwarding table entry of the forwarding chip; For the forwarding table entries that exist in the SDK process of the standby container but do not exist in the forwarding chip, add them to the forwarding chip; The forwarding table entry that does not exist in the SDK process of the backup container but exists in the forwarding chip is deleted from the forwarding chip.

Images