Non-interruption management method and system for intelligent hotfix

Abstract

The invention provides a non-interruption management method and system for an intelligent hot patch in the technical field of communication system software maintenance. The method comprises the steps that S1, a host receives a patch operation request; s2, verifying patch data carried by the patch operation request, and forwarding the patch data to the standby machine; s3, the standby machine automatically executes patch operation through the patch management module; the patch management module adopts a state machine mechanism to control the patch operation, and ensures that the service is not interrupted in the patch operation process; s4, when the patch operation fails, the standby machine automatically triggers a rollback mechanism, and when the patch operation succeeds, patch operation success feedback is sent to the host; and S5, the host executes a host and standby switching operation with the standby machine based on patch operation success feedback, and then executes the patch operation of the host after switching is completed. The method has the advantages that automatic execution, uninterrupted updating and reliable rollback of patch operation are achieved, and therefore the efficiency and safety of patch management are comprehensively improved.

Description

Technical Field

[0001] This invention relates to the field of communication system software maintenance technology, and in particular to a non-disruptive management method and system for intelligent hot patching. Background Technology

[0002] With increasingly stringent requirements for high availability in communication systems, software patch updates and maintenance have become crucial for ensuring stable equipment operation and system security. However, current common patch management technologies still have significant limitations, particularly in achieving uninterrupted service updates.

[0003] Currently, the industry's patch management methods mainly fall into three categories, none of which can simultaneously meet the requirements of intelligent operation and uninterrupted operation: (1) Full package replacement update: Patch updates are achieved by reinstalling or completely overwriting the software package. This method usually requires a system shutdown and restart to take effect, resulting in a long service interruption. In carrier-grade and other high-availability equipment, this type of interruption will directly affect the user experience, and its applicable scenarios are limited.

[0004] (2) Single-patch stacking update: This method maintains the system by stacking patches one by one, but it lacks a unified version management and dependency control mechanism. In practice, problems such as disordered patch application order and difficulty in rollback are likely to occur, and system instability is often caused by patch conflicts, such as circular dependencies or version incompatibility that may occur when dependencies are not verified.

[0005] (3) Update files plus independent scripts: This method relies on maintenance personnel to manually execute scattered update scripts, which is prone to errors and difficult to standardize. This method is inefficient and prone to equipment malfunctions or business interruptions due to human error, and lacks automated and controllable update assurance.

[0006] Based on the above-mentioned existing technologies, their main problems can be summarized as follows: (1) Imperfect patch management mechanism: The patch version management is not standardized and the dependency relationship lacks automatic verification, which can easily lead to installation failure or system instability.

[0007] (2) Poor operational recoverability: When the patch installation fails, the system cannot achieve a quick automatic rollback. The recovery process relies on manual intervention, which affects the reliability of equipment operation.

[0008] (3) Lack of uninterrupted update capability: Existing solutions often require shutdown and restart, do not support hot patching mechanism, and are difficult to meet the business continuity requirements of high availability systems.

[0009] (4) Insufficient synchronization of primary and backup devices: In a primary and backup deployment environment, patch operations lack an efficient synchronization mechanism, which can easily lead to inconsistencies between primary and backup states and increase the risk of system operation.

[0010] Therefore, how to provide a non-disruptive management method and system for intelligent hot patching, enabling automated execution of patch operations, non-disruptive updates, and reliable rollback, thereby comprehensively improving the efficiency and security of patch management, has become an urgent technical problem to be solved. Summary of the Invention

[0011] The technical problem to be solved by this invention is to provide a method and system for uninterrupted management of intelligent hot patching, which realizes automated execution of patch operations, uninterrupted updates and reliable rollback, thereby comprehensively improving the efficiency and security of patch management.

[0012] In a first aspect, the present invention provides a non-disruptive management method for intelligent hot patching, comprising the following steps: Step S1: The host receives a patch operation request carrying patch operation content and patch data through the communication submodule. The patch operation content is at least one of uploading, installing, activating, deactivating, and rolling back. Step S2: After verifying the patch data carried in the patch operation request, the host forwards the patch operation request to the standby host. Step S3: Based on the received patch operation request, the standby machine automatically executes the patch operation through the patch management module. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation. The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the transition of each of the global states based on the patch operation. Step S4: When the patch operation fails, the standby machine automatically triggers the rollback mechanism; when the patch operation succeeds, it sends a successful patch operation feedback to the master machine. Step S5: Based on the successful feedback of the received patch operation, the host performs a master-slave switchover operation with the standby machine. After the switchover is completed, the host performs the patch operation on its own machine to ensure the consistency of patch status between the host and the standby machine.

[0013] Furthermore, in step S1, the communication submodule supports domain socket communication and TCP short connection communication: The domain socket communication is used to interact with patch operation clients on the same device, and uses JSON message format; The TCP short connection communication is used for master-slave synchronization between different devices and adopts a structured binary message format.

[0014] Furthermore, in step S3, the step of the patch management module automatically performing patch operations specifically includes: The system configuration parameters are loaded through the configuration management submodule, providing a runtime environment for patch operations; The database management submodule stores and queries patch information, including patch number, patch type, dependencies, and activation status. The specific patch operation is encapsulated by the patch operation submodule, and before the operation, the dependency relationship, version compatibility and patch number of the patch data are verified by parsing the standardized control file of the patch data; the standardized control file contains patch number, compatible version, dependency relationship, patch type, activation method and creator information; The global state transition is driven by the state machine submodule, and process constraints are imposed on the patch operation. The logging submodule records the patch operation process, state transitions, and exception events. The utility submodule performs JSON parsing, file validation, and path resolution.

[0015] Furthermore, in step S3, the state machine mechanism executes automatic recovery logic after the device powers off and restarts, specifically including: Read the last global state saved in the database; If the global state is idle, it will directly revert to the normal state. If the global state is in the preparation state, application state, or verification state, a rollback operation will be automatically triggered to clean up incomplete patch operations and restore to the stable version before the power outage. If the global state is a failure state, then retain the failure flag.

[0016] Furthermore, in step S4, the rollback mechanism specifically includes: Based on the patch information recorded in the patch management module, roll back to the most recent stable version; The rollback process is recorded through the logging submodule, and error messages and recovery options are provided. Furthermore, the rollback operation is triggered only once, and if consecutive rollbacks fail, the system will automatically revert to the unpatched state.

[0017] Secondly, this invention provides a non-disruptive intelligent hot-patching management system, comprising the following modules: The patch operation request receiving module is used by the host to receive a patch operation request carrying patch operation content and patch data through the communication submodule. The patch operation content is at least one of uploading, installing, activating, deactivating, and rolling back. The patch operation request forwarding module is used by the host to verify the patch data carried in the patch operation request and then forward the patch operation request to the standby host. The patch operation module is used by the standby machine to automatically execute patch operations through the patch management module based on the received patch operation request. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation. The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the transition of each of the global states based on the patch operation. The operation feedback module is used to automatically trigger the rollback mechanism when the standby machine fails to perform a patch operation, and to send a successful patch operation feedback to the master machine when the patch operation is successful. The primary / standby synchronization module is used by the primary machine to perform a primary / standby switchover operation with the standby machine based on the successful feedback of the received patch operation. After the switchover is completed, the primary machine will perform the patch operation again, ensuring the consistency of patch status between the primary machine and the standby machine.

[0018] Furthermore, in the patch operation request receiving module, the communication submodule supports domain socket communication and TCP short connection communication: The domain socket communication is used to interact with patch operation clients on the same device, and uses JSON message format; The TCP short connection communication is used for master-slave synchronization between different devices and adopts a structured binary message format.

[0019] Furthermore, in the patch operation module, the steps by which the patch management module automatically performs patch operations specifically include: The system configuration parameters are loaded through the configuration management submodule, providing a runtime environment for patch operations; The database management submodule stores and queries patch information, including patch number, patch type, dependencies, and activation status. The specific patch operation is encapsulated by the patch operation submodule, and before the operation, the dependency relationship, version compatibility and patch number of the patch data are verified by parsing the standardized control file of the patch data; the standardized control file contains patch number, compatible version, dependency relationship, patch type, activation method and creator information; The global state transition is driven by the state machine submodule, and process constraints are imposed on the patch operation. The logging submodule records the patch operation process, state transitions, and exception events. The utility submodule performs JSON parsing, file validation, and path resolution.

[0020] Furthermore, in the patch operation module, the state machine mechanism executes automatic recovery logic after the device powers off and restarts, specifically including: Read the last global state saved in the database; If the global state is idle, it will directly revert to the normal state. If the global state is in the preparation state, application state, or verification state, a rollback operation will be automatically triggered to clean up incomplete patch operations and restore to the stable version before the power outage. If the global state is a failure state, then retain the failure flag.

[0021] Furthermore, in the operation feedback module, the rollback mechanism specifically includes: Based on the patch information recorded in the patch management module, roll back to the most recent stable version; The rollback process is recorded through the logging submodule, and error messages and recovery options are provided. Furthermore, the rollback operation is triggered only once, and if consecutive rollbacks fail, the system will automatically revert to the unpatched state.

[0022] The advantages of this invention are: 1. The host machine receives patch operation requests carrying patch operation content and patch data through the communication submodule. The patch operation content includes at least one of the following: upload, install, activate, deactivate, and rollback. After verifying the patch data carried in the patch operation request, the host machine forwards the patch operation request to the standby machine. The standby machine automatically executes the patch operation through the patch management module. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation. The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the migration of each global state based on the patch operation. When the patch operation fails, the standby machine automatically triggers the rollback mechanism. When the patch operation succeeds, it sends a patch operation success feedback to the host machine. Based on the patch operation success feedback, the host machine performs a master-slave switchover operation with the standby machine. After the switchover is completed, the host machine executes its own patch operation, ensuring the consistency of the patch state between the host machine and the standby machine. That is, by constructing a master-slave switchover with a state machine as its core, the host machine performs a master-slave switchover operation with the standby machine. The backup collaboration mechanism achieves a high degree of automation and secure control over patch management. Specifically, it adopts a "backup machine first, then main machine" order. The main machine receives and verifies patch operation requests before forwarding them to the backup machine. The patch management module in the backup machine automatically executes patch operations according to a strict process defined by the state machine (including preparation, application, and verification states), and automatically verifies dependencies and compatibility by parsing standardized files to ensure operational correctness. During this process, services are continuously provided by the main machine that is not performing any operations, thus achieving uninterrupted updates. If the backup machine operation fails, the state machine will automatically trigger a rollback mechanism to restore to the most recent stable version based on database records. Even in the event of an unexpected power outage, the system can automatically recover or roll back based on persistent state after restarting, and the rollback operation has an anti-loop mechanism to ensure reliable update rollback. After the backup machine succeeds, the main and backup machines switch roles and synchronize patch states, ultimately achieving automated execution of patch operations, uninterrupted updates, and reliable rollback, thereby comprehensively improving the efficiency and security of patch management.

[0023] 2. Through a sophisticated primary / standby switchover and state machine control process, service continuity is ensured throughout the entire patching process. Specifically, the patching operation is first executed on the standby machine, while the primary machine continues to provide services. After the standby machine operation is successful and verified, the primary / standby roles are switched over, and the new primary machine (the original standby machine) provides services. The original primary machine then executes the patching operation. This "standby first, primary later, sequential update" mechanism fundamentally avoids service interruptions caused by patch installation, activation, and other operations, greatly improving system availability during operation and maintenance, and meeting the needs of scenarios with extremely high business continuity requirements, such as finance and telecommunications.

[0024] 3. The patch management module adopts a state machine mechanism, which clearly defines global states such as idle, ready, applied, verified, and failed, as well as migration rules, and imposes strict constraints and standardized management on the patch operation process. In particular, the state machine has the ability to automatically recover from power failures. After the system restarts, it can make intelligent decisions based on the last state that is persistently saved: if it was in an intermediate state before the power failure, it will automatically trigger a rollback to clean up the state and restore to a stable version. This design effectively solves the industry pain point that the system is stuck in an unknown intermediate state due to unexpected power failures and other faults, and cannot provide normal services. It significantly improves the system's fault tolerance and self-healing capabilities.

[0025] 4. A multi-layered protection mechanism was constructed to ensure the security of patch operations. First, before the operation is executed, both the primary and backup machines verify the patch data. The patch operation submodule also parses the standardized control file to verify dependencies and version compatibility, preventing system failures caused by patch conflicts or incompatibilities. Second, a rigorous rollback mechanism was designed to automatically and reliably revert to the most recent stable version if any step of the patch operation fails. Furthermore, the strategy of "triggering only once, and reverting to the unpatched state if consecutive failures occur" avoids the risk of a rollback loop. These mechanisms together form a security net, greatly reducing the risk of patch deployment and ensuring the stability of the system baseline.

[0026] 5. The communication submodule flexibly adopts domain sockets (for efficient local interaction) and TCP short connections (for primary-backup synchronization across networks) according to application scenarios, and adapts to different message formats (JSON / structured binary), optimizing communication efficiency; the patch management module adopts a highly cohesive and loosely coupled submodule design, such as configuration management, database management, patch operation, and logging, each performing its own function, making the system structure clear and facilitating independent development, testing, maintenance, and expansion of functions; the logging submodule fully records the operation process and state transition, providing strong support for problem localization and auditing.

[0027] 6. By using a closed-loop process of request forwarding by the host, feedback execution by the standby machine, and finally triggering the master-slave switchover and synchronization operation, the software state of the master and standby devices is guaranteed to remain consistent in the critical dimension of patch management. This consistency guarantee avoids the failure of failover or service anomalies that may occur in traditional master-slave systems due to asynchronous patch installation. This ensures that the entire high-availability cluster can still operate reliably as a coordinated whole after patch updates, thus improving the cluster-level reliability level. Attached Figure Description

[0028] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0029] Figure 1 This is a flowchart of an uninterrupted management method for intelligent hot patching according to the present invention.

[0030] Figure 2 This is a schematic diagram of the uninterrupted management system for intelligent hot patching according to the present invention.

[0031] Figure 3 This is a schematic diagram of the patch management module of the present invention.

[0032] Figure 4 This is a schematic diagram of the global state transition of the present invention. Detailed Implementation

[0033] The overall approach of the technical solution in this application is as follows: A "standby machine first, then primary machine" sequence is adopted. The primary machine receives and verifies the patch operation request before forwarding it to the standby machine. The patch management module within the standby machine automatically executes the patch operation according to a strict process defined by the state machine, and automatically verifies dependencies and compatibility by parsing standardized files to ensure operational correctness. During this process, the service is continuously provided by the primary machine, which is not performing any operations, thus achieving uninterrupted updates. If the standby machine operation fails, the state machine will automatically trigger a rollback mechanism to restore to the most recent stable version based on database records. Even in the event of an unexpected power outage, the system can automatically recover or roll back based on persistent state after restarting, and the rollback operation has an anti-loop mechanism to ensure reliable update rollback. After the standby machine succeeds, the primary and standby machines switch roles and synchronize the patch state to achieve automated execution of patch operations, uninterrupted updates, and reliable rollback, thereby improving the efficiency and security of patch management.

[0034] Please refer to Figures 1 to 4 As shown, a preferred embodiment of the intelligent hot patching non-disruptive management method of the present invention includes the following steps: Step S1: The host receives a patch operation request carrying patch operation content and patch data through the communication submodule. The patch operation content is at least one of uploading, installing, activating, deactivating, and rolling back. To achieve uniformity in the creation and management of patch data (patch files), the directory structure of patch data has been standardized and templated. This directory structure is compatible with different types of patches (application patches, board patches, system patches, and plugin patches) and ensures that patch data is consistent and operable during packaging, transmission, installation, and rollback.

[0035] Patch directory hierarchy: The patch data is based on patch_dir as the root directory, with fixed subdirectories and files defined under it: a. control file: Patch description file, containing key information such as patch number, compatible version, dependencies, patch type, activation method, creator, and packaging time, serving as the unified entry point for the patch management module to parse; b. root_dir directory: Maps the root path ( / ) of the runtime environment. All files that need to be updated or replaced are placed in this directory, and the path is kept relatively consistent with the target system path. Optional script files, such as preinst (activation script) and postinst (completion script), are used to perform specific operations during patch activation or deactivation. The overall directory structure is as follows: patch_dir ├── control # Patch documentation (required) ├── preinst # Execute script before activation (optional) ├── postinst # Execute script after activation (optional) ├── preun # Execute script before uninstallation / deactivation (optional) ├── postun # Execute script after uninstallation / deactivation (optional) └── root_dir # Corresponds to the root directory of the runtime environment / ├── starnet │ └── usr # Corresponding runtime environment / starnet / usr └── usr # Corresponding runtime environment / usr Step S2: After verifying the patch data carried in the patch operation request, the host forwards the patch operation request to the standby host. Step S3: Based on the received patch operation request, the standby machine automatically executes the patch operation through the patch management module. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation (the patch operation uses a hot patch mechanism, which does not require restarting the device during patch activation or deactivation; the state machine submodule constrains the operation process to avoid service interruption). The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the transition of each of the global states based on the patch operation. The global state also includes an end state. The description of the global state is shown in the table below:

[0036] Step S4: When the patch operation fails, the standby machine automatically triggers the rollback mechanism; when the patch operation succeeds, it sends a successful patch operation feedback to the master machine. Step S5: Based on the successful feedback of the received patch operation, the host performs a master-slave switchover operation with the standby machine. After the switchover is completed, the host performs the patch operation on its own machine to ensure the consistency of patch status between the host and the standby machine.

[0037] In step S1, the communication submodule supports domain socket communication and TCP short connection communication: The domain socket communication is used to interact with patch operation clients on the same device, and uses JSON message format; The TCP short connection communication is used for master-slave synchronization between different devices and adopts a structured binary message format.

[0038] In step S3, the steps by which the patch management module automatically performs patch operations specifically include: The system configuration parameters are loaded through the configuration management submodule, providing a runtime environment for patch operations; The database management submodule stores and queries patch information, including patch number, patch type, dependencies, and activation status. The specific patch operation is encapsulated by the patch operation submodule, and before the operation, the dependency relationship, version compatibility and patch number of the patch data are verified by parsing the standardized control file of the patch data; the standardized control file contains patch number, compatible version, dependency relationship, patch type, activation method and creator information; The global state transition is driven by the state machine submodule, and process constraints are imposed on the patch operation. The logging submodule records the patch operation process, state transitions, and exception events. The utility submodule performs JSON parsing, file validation, and path resolution.

[0039] The patch management module adopts a layered and decoupled design approach. The overall framework consists of a configuration management submodule, a database management submodule, a patch operation submodule, a state machine submodule, a log submodule, a tool submodule, and a communication submodule. The modules interact with each other through well-defined interfaces to collaboratively complete the patch operation.

[0040] The configuration management submodule is responsible for parsing and loading system configuration files when the process starts, reading information such as log path, database path, patch storage path, rollback limit, and timeout control parameters, providing global running parameters for the patch management module, and uniformly outputting the running environment and policy configuration to other submodules to ensure that the entire system can run on different PBX software.

[0041] The database management submodule stores patch information based on an SQLite database; as the core data storage of the patch management module, it provides necessary data support for the patch operation submodule and works with the configuration management submodule to ensure data consistency.

[0042] The patch operation submodule encapsulates specific patch operations, including uploading, installing, activating, deactivating, and uninstalling. This module has built-in dependency verification logic, which can verify the patch number, dependencies, and applicable software versions before patching operations. During execution, the patch operation submodule relies on the database submodule to obtain patch information, and after the operation is completed, it updates the current global state through the state machine submodule.

[0043] The state machine submodule defines and maintains five global states for patch management (idle, ready, in use, verifying, and failed), and completes state transitions when different operations are triggered, while also avoiding the risk of multiple users simultaneously operating patches on a single device. The state machine submodule is closely integrated with the patch operation submodule, which imposes process constraints on all activation and deactivation operations, and works in conjunction with the log submodule to record state transitions, ensuring that rollback logic can be accurately triggered in abnormal situations.

[0044] The logging submodule records the patch operation process, state machine transitions, abnormal events, and recovery actions. It supports log rollback and hierarchical output, facilitating problem localization and auditing. The logging submodule is interconnected with all submodules, providing log policy configuration for configuration management and debugging and error tracing capabilities for the communication submodule and state machine submodule.

[0045] The utility submodule provides common utility methods such as JSON parsing, file verification (e.g., MD5 verification), and path parsing; it serves as a public library for submodules such as patching, communication, and database, avoiding redundant implementations.

[0046] The communication submodule enables interaction between the module and external entities, supporting domain socket communication and TCP short connection communication. The communication submodule is the system's input / output interface, receiving commands from the front-end or back-end operation and maintenance, and feeding back the operation results to the caller. It also interacts with the state machine submodule to drive patch operations.

[0047] In step S3, the state machine mechanism executes automatic recovery logic after the device powers off and restarts, specifically including: Read the last global state saved in the database; If the global state is idle, it will directly revert to the normal state. If the global state is in the preparation state, application state, or verification state, a rollback operation will be automatically triggered to clean up incomplete patch operations and restore to the stable version before the power outage. If the global state is a failure state, then retain the failure flag.

[0048] In step S4, the rollback mechanism specifically includes: Based on the patch information recorded in the patch management module, roll back to the most recent stable version; The rollback process is recorded through the logging submodule, and error messages and recovery options are provided. Furthermore, the rollback operation is triggered only once, and if consecutive rollbacks fail, the system will automatically revert to the unpatched state.

[0049] A preferred embodiment of the intelligent hot-patching non-disruptive management system of the present invention includes the following modules: The patch operation request receiving module is used by the host to receive a patch operation request carrying patch operation content and patch data through the communication submodule. The patch operation content is at least one of uploading, installing, activating, deactivating, and rolling back. To achieve uniformity in the creation and management of patch data (patch files), the directory structure of patch data has been standardized and templated. This directory structure is compatible with different types of patches (application patches, board patches, system patches, and plugin patches) and ensures that patch data is consistent and operable during packaging, transmission, installation, and rollback.

[0050] Patch directory hierarchy: The patch data is based on patch_dir as the root directory, with fixed subdirectories and files defined under it: a. control file: Patch description file, containing key information such as patch number, compatible version, dependencies, patch type, activation method, creator, and packaging time, serving as the unified entry point for the patch management module to parse; b. root_dir directory: Maps the root path ( / ) of the runtime environment. All files that need to be updated or replaced are placed in this directory, and the path is kept relatively consistent with the target system path. Optional script files, such as preinst (activation script) and postinst (completion script), are used to perform specific operations during patch activation or deactivation. The overall directory structure is as follows: patch_dir ├── control # Patch documentation (required) ├── preinst # Execute script before activation (optional) ├── postinst # Execute script after activation (optional) ├── preun # Execute script before uninstallation / deactivation (optional) ├── postun # Execute script after uninstallation / deactivation (optional) └── root_dir # Corresponds to the root directory of the runtime environment / ├── starnet │ └── usr # Corresponding runtime environment / starnet / usr └── usr # Corresponding runtime environment / usr The patch operation request forwarding module is used by the host to verify the patch data carried in the patch operation request and then forward the patch operation request to the standby host. The patch operation module is used by the standby machine to automatically execute patch operations through the patch management module based on the received patch operation request. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation (the patch operation adopts a hot patch mechanism, which does not require restarting the device during patch activation or deactivation, and the operation process is constrained by the state machine submodule to avoid service interruption). The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the transition of each of the global states based on the patch operation; the global state also includes an end state. The description of the global state is shown in the table below:

[0051] The operation feedback module is used to automatically trigger the rollback mechanism when the standby machine fails to perform a patch operation, and to send a successful patch operation feedback to the master machine when the patch operation is successful. The primary / standby synchronization module is used by the primary machine to perform a primary / standby switchover operation with the standby machine based on the successful feedback of the received patch operation. After the switchover is completed, the primary machine will perform the patch operation again, ensuring the consistency of patch status between the primary machine and the standby machine.

[0052] In the patch operation request receiving module, the communication submodule supports domain socket communication and TCP short connection communication: The domain socket communication is used to interact with patch operation clients on the same device, and uses JSON message format; The TCP short connection communication is used for master-slave synchronization between different devices and adopts a structured binary message format.

[0053] In the patch operation module, the steps for the patch management module to automatically perform patch operations specifically include: The system configuration parameters are loaded through the configuration management submodule, providing a runtime environment for patch operations; The database management submodule stores and queries patch information, including patch number, patch type, dependencies, and activation status. The specific patch operation is encapsulated by the patch operation submodule, and before the operation, the dependency relationship, version compatibility and patch number of the patch data are verified by parsing the standardized control file of the patch data; the standardized control file contains patch number, compatible version, dependency relationship, patch type, activation method and creator information; The global state transition is driven by the state machine submodule, and process constraints are imposed on the patch operation. The logging submodule records the patch operation process, state transitions, and exception events. The utility submodule performs JSON parsing, file validation, and path resolution.

[0054] The patch management module adopts a layered and decoupled design approach. The overall framework consists of a configuration management submodule, a database management submodule, a patch operation submodule, a state machine submodule, a log submodule, a tool submodule, and a communication submodule. The modules interact with each other through well-defined interfaces to collaboratively complete the patch operation.

[0055] The configuration management submodule is responsible for parsing and loading system configuration files when the process starts, reading information such as log path, database path, patch storage path, rollback limit, and timeout control parameters, providing global running parameters for the patch management module, and uniformly outputting the running environment and policy configuration to other submodules to ensure that the entire system can run on different PBX software.

[0056] The database management submodule stores patch information based on an SQLite database; as the core data storage of the patch management module, it provides necessary data support for the patch operation submodule and works with the configuration management submodule to ensure data consistency.

[0057] The patch operation submodule encapsulates specific patch operations, including uploading, installing, activating, deactivating, and uninstalling. This module has built-in dependency verification logic, which can verify the patch number, dependencies, and applicable software versions before patching operations. During execution, the patch operation submodule relies on the database submodule to obtain patch information, and after the operation is completed, it updates the current global state through the state machine submodule.

[0058] The state machine submodule defines and maintains five global states for patch management (idle, ready, in use, verifying, and failed), and completes state transitions when different operations are triggered, while also avoiding the risk of multiple users simultaneously operating patches on a single device. The state machine submodule is closely integrated with the patch operation submodule, which imposes process constraints on all activation and deactivation operations, and works in conjunction with the log submodule to record state transitions, ensuring that rollback logic can be accurately triggered in abnormal situations.

[0059] The logging submodule records the patch operation process, state machine transitions, abnormal events, and recovery actions. It supports log rollback and hierarchical output, facilitating problem localization and auditing. The logging submodule is interconnected with all submodules, providing log policy configuration for configuration management and debugging and error tracing capabilities for the communication submodule and state machine submodule.

[0060] The utility submodule provides common utility methods such as JSON parsing, file verification (e.g., MD5 verification), and path parsing; it serves as a public library for submodules such as patching, communication, and database, avoiding redundant implementations.

[0061] The communication submodule enables interaction between the module and external entities, supporting domain socket communication and TCP short connection communication. The communication submodule is the system's input / output interface, receiving commands from the front-end or back-end operation and maintenance, and feeding back the operation results to the caller. It also interacts with the state machine submodule to drive patch operations.

[0062] In the patch operation module, the state machine mechanism executes automatic recovery logic after the device powers off and restarts, specifically including: Read the last global state saved in the database; If the global state is idle, it will directly revert to the normal state. If the global state is in the preparation state, application state, or verification state, a rollback operation will be automatically triggered to clean up incomplete patch operations and restore to the stable version before the power outage. If the global state is a failure state, then retain the failure flag.

[0063] In the operation feedback module, the rollback mechanism is specifically as follows: Based on the patch information recorded in the patch management module, roll back to the most recent stable version; The rollback process is recorded through the logging submodule, and error messages and recovery options are provided. Furthermore, the rollback operation is triggered only once, and if consecutive rollbacks fail, the system will automatically revert to the unpatched state.

[0064] In summary, the advantages of this invention are as follows: 1. The host machine receives patch operation requests carrying patch operation content and patch data through the communication submodule. The patch operation content includes at least one of the following: upload, install, activate, deactivate, and rollback. After verifying the patch data carried in the patch operation request, the host machine forwards the patch operation request to the standby machine. The standby machine automatically executes the patch operation through the patch management module. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation. The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the migration of each global state based on the patch operation. When the patch operation fails, the standby machine automatically triggers the rollback mechanism. When the patch operation succeeds, it sends a patch operation success feedback to the host machine. Based on the patch operation success feedback, the host machine performs a master-slave switchover operation with the standby machine. After the switchover is completed, the host machine executes its own patch operation, ensuring the consistency of the patch state between the host machine and the standby machine. That is, by constructing a master-slave switchover with a state machine as its core, the host machine performs a master-slave switchover operation with the standby machine. The backup collaboration mechanism achieves a high degree of automation and secure control over patch management. Specifically, it adopts a "backup machine first, then main machine" order. The main machine receives and verifies patch operation requests before forwarding them to the backup machine. The patch management module in the backup machine automatically executes patch operations according to a strict process defined by the state machine (including preparation, application, and verification states), and automatically verifies dependencies and compatibility by parsing standardized files to ensure operational correctness. During this process, services are continuously provided by the main machine that is not performing any operations, thus achieving uninterrupted updates. If the backup machine operation fails, the state machine will automatically trigger a rollback mechanism to restore to the most recent stable version based on database records. Even in the event of an unexpected power outage, the system can automatically recover or roll back based on persistent state after restarting, and the rollback operation has an anti-loop mechanism to ensure reliable update rollback. After the backup machine succeeds, the main and backup machines switch roles and synchronize patch states, ultimately achieving automated execution of patch operations, uninterrupted updates, and reliable rollback, thereby comprehensively improving the efficiency and security of patch management.

[0065] 2. Through a sophisticated primary / standby switchover and state machine control process, service continuity is ensured throughout the entire patching process. Specifically, the patching operation is first executed on the standby machine, while the primary machine continues to provide services. After the standby machine operation is successful and verified, the primary / standby roles are switched over, and the new primary machine (the original standby machine) provides services. The original primary machine then executes the patching operation. This "standby first, primary later, sequential update" mechanism fundamentally avoids service interruptions caused by patch installation, activation, and other operations, greatly improving system availability during operation and maintenance, and meeting the needs of scenarios with extremely high business continuity requirements, such as finance and telecommunications.

[0066] 3. The patch management module adopts a state machine mechanism, which clearly defines global states such as idle, ready, applied, verified, and failed, as well as migration rules, and imposes strict constraints and standardized management on the patch operation process. In particular, the state machine has the ability to automatically recover from power failures. After the system restarts, it can make intelligent decisions based on the last state that is persistently saved: if it was in an intermediate state before the power failure, it will automatically trigger a rollback to clean up the state and restore to a stable version. This design effectively solves the industry pain point that the system is stuck in an unknown intermediate state due to unexpected power failures and other faults, and cannot provide normal services. It significantly improves the system's fault tolerance and self-healing capabilities.

[0067] 4. A multi-layered protection mechanism was constructed to ensure the security of patch operations. First, before the operation is executed, both the primary and backup machines verify the patch data. The patch operation submodule also parses the standardized control file to verify dependencies and version compatibility, preventing system failures caused by patch conflicts or incompatibilities. Second, a rigorous rollback mechanism was designed to automatically and reliably revert to the most recent stable version if any step of the patch operation fails. Furthermore, the strategy of "triggering only once, and reverting to the unpatched state if consecutive failures occur" avoids the risk of a rollback loop. These mechanisms together form a security net, greatly reducing the risk of patch deployment and ensuring the stability of the system baseline.

[0068] 5. The communication submodule flexibly adopts domain sockets (for efficient local interaction) and TCP short connections (for primary-backup synchronization across networks) according to application scenarios, and adapts to different message formats (JSON / structured binary), optimizing communication efficiency; the patch management module adopts a highly cohesive and loosely coupled submodule design, such as configuration management, database management, patch operation, and logging, each performing its own function, making the system structure clear and facilitating independent development, testing, maintenance, and expansion of functions; the logging submodule fully records the operation process and state transition, providing strong support for problem localization and auditing.

[0069] 6. By using a closed-loop process of request forwarding by the host, feedback execution by the standby machine, and finally triggering the master-slave switchover and synchronization operation, the software state of the master and standby devices is guaranteed to remain consistent in the critical dimension of patch management. This consistency guarantee avoids the failure of failover or service anomalies that may occur in traditional master-slave systems due to asynchronous patch installation. This ensures that the entire high-availability cluster can still operate reliably as a coordinated whole after patch updates, thus improving the cluster-level reliability level.

[0070] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A non-disruptive management method for intelligent hot patching, characterized in that: Includes the following steps: Step S1: The host receives a patch operation request carrying patch operation content and patch data through the communication submodule. The patch operation content is at least one of uploading, installing, activating, deactivating, and rolling back. Step S2: After verifying the patch data carried in the patch operation request, the host forwards the patch operation request to the standby host. Step S3: Based on the received patch operation request, the standby machine automatically executes the patch operation through the patch management module. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation. The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the transition of each of the global states based on the patch operation. Step S4: When the patch operation fails, the standby machine automatically triggers the rollback mechanism; when the patch operation succeeds, it sends a successful patch operation feedback to the master machine. Step S5: Based on the successful feedback of the received patch operation, the host performs a master-slave switchover operation with the standby machine. After the switchover is completed, the host performs the patch operation on its own machine to ensure the consistency of patch status between the host and the standby machine.

2. The uninterrupted management method for intelligent hot patching as described in claim 1, characterized in that: In step S1, the communication submodule supports domain socket communication and TCP short connection communication: The domain socket communication is used to interact with patch operation clients on the same device, and uses JSON message format; The TCP short connection communication is used for master-slave synchronization between different devices and adopts a structured binary message format.

3. The uninterrupted management method for intelligent hot patching as described in claim 1, characterized in that: In step S3, the steps by which the patch management module automatically performs patch operations specifically include: The system configuration parameters are loaded through the configuration management submodule, providing a runtime environment for patch operations; The database management submodule stores and queries patch information, including patch number, patch type, dependencies, and activation status. The specific patch operation is encapsulated by the patch operation submodule, and before the operation, the dependency relationship, version compatibility and patch number of the patch data are verified by parsing the standardized control file of the patch data; the standardized control file contains patch number, compatible version, dependency relationship, patch type, activation method and creator information; The global state transition is driven by the state machine submodule, and process constraints are imposed on the patch operation. The logging submodule records the patch operation process, state transitions, and exception events. The utility submodule performs JSON parsing, file validation, and path resolution.

4. The uninterrupted management method for intelligent hot patching as described in claim 1, characterized in that: In step S3, the state machine mechanism executes automatic recovery logic after the device powers off and restarts, specifically including: Read the last global state saved in the database; If the global state is idle, it will directly revert to the normal state. If the global state is in the preparation state, application state, or verification state, a rollback operation will be automatically triggered to clean up incomplete patch operations and restore to the stable version before the power outage. If the global state is a failure state, then retain the failure flag.

5. The uninterrupted management method for intelligent hot patching as described in claim 1, characterized in that: In step S4, the rollback mechanism specifically includes: Based on the patch information recorded in the patch management module, roll back to the most recent stable version; The rollback process is recorded through the logging submodule, and error messages and recovery options are provided. Furthermore, the rollback operation is triggered only once, and if consecutive rollbacks fail, the system will automatically revert to the unpatched state.

6. A non-disruptive intelligent hot-patching management system, characterized in that: Includes the following modules: The patch operation request receiving module is used by the host to receive a patch operation request carrying patch operation content and patch data through the communication submodule. The patch operation content is at least one of uploading, installing, activating, deactivating, and rolling back. The patch operation request forwarding module is used by the host to verify the patch data carried in the patch operation request and then forward the patch operation request to the standby host. The patch operation module is used by the standby machine to automatically execute patch operations through the patch management module based on the received patch operation request. The patch management module uses a state machine mechanism to control the patch operation, ensuring uninterrupted service during the patch operation. The state machine mechanism defines and maintains a global state including idle state, ready state, application state, verification state, and failure state, and triggers the transition of each of the global states based on the patch operation. The operation feedback module is used to automatically trigger the rollback mechanism when the standby machine fails to perform a patch operation, and to send a successful patch operation feedback to the master machine when the patch operation is successful. The primary / standby synchronization module is used by the primary machine to perform a primary / standby switchover operation with the standby machine based on the successful feedback of the received patch operation. After the switchover is completed, the primary machine will perform the patch operation again, ensuring the consistency of patch status between the primary machine and the standby machine.

7. The intelligent hot-patching non-disruptive management system as described in claim 6, characterized in that: In the patch operation request receiving module, the communication submodule supports domain socket communication and TCP short connection communication: The domain socket communication is used to interact with patch operation clients on the same device, and uses JSON message format; The TCP short connection communication is used for master-slave synchronization between different devices and adopts a structured binary message format.

8. The intelligent hot-patching non-disruptive management system as described in claim 6, characterized in that: In the patch operation module, the steps for the patch management module to automatically perform patch operations specifically include: The system configuration parameters are loaded through the configuration management submodule, providing a runtime environment for patch operations; The database management submodule stores and queries patch information, including patch number, patch type, dependencies, and activation status. The specific patch operation is encapsulated by the patch operation submodule, and before the operation, the dependency relationship, version compatibility and patch number of the patch data are verified by parsing the standardized control file of the patch data; the standardized control file contains patch number, compatible version, dependency relationship, patch type, activation method and creator information; The global state transition is driven by the state machine submodule, and process constraints are imposed on the patch operation. The logging submodule records the patch operation process, state transitions, and exception events. The utility submodule performs JSON parsing, file validation, and path resolution.

9. The intelligent hot-patching non-disruptive management system as described in claim 6, characterized in that: In the patch operation module, the state machine mechanism executes automatic recovery logic after the device powers off and restarts, specifically including: Read the last global state saved in the database; If the global state is idle, it will directly revert to the normal state. If the global state is in the preparation state, application state, or verification state, a rollback operation will be automatically triggered to clean up incomplete patch operations and restore to the stable version before the power outage. If the global state is a failure state, then retain the failure flag.

10. The intelligent hot-patching non-disruptive management system as described in claim 6, characterized in that: In the operation feedback module, the rollback mechanism is specifically as follows: Based on the patch information recorded in the patch management module, roll back to the most recent stable version; The rollback process is recorded through the logging submodule, and error messages and recovery options are provided. Furthermore, the rollback operation is triggered only once, and if consecutive rollbacks fail, the system will automatically revert to the unpatched state.

Images