A high-availability method, system, and electronic device for key management based on clustered deployment.

Abstract

This application provides a high-availability method, system, and electronic device for key management based on clustered deployment, relating to the field of information security technology for industrial control systems. The method includes: constructing a symmetric cluster consisting of three nodes, dynamically generating a master node through an election mechanism; configuring virtual IP groups for the cluster to handle access requests; deploying high-availability components at the network layer, service discovery layer, application layer, and data layer of each node to form a full-stack high-availability architecture; and automatically performing fault recovery when the master node fails: the network layer switches traffic via virtual IP migration, the service discovery layer updates the service list and redirects requests, and the data layer automatically completes master instance election or data recovery within each high-availability cluster. This method achieves decentralized, redundant, and full-stack high-availability key management deployment, possessing fault isolation, accurate recovery, and flexible scalability capabilities.

Description

Technical Field

[0001] This application relates to the field of information security for industrial control systems, and in particular to a high-availability method, system, and electronic device for key management based on clustered deployment. Background Technology

[0002] In the field of information security for industrial control systems, key management systems are core infrastructure for ensuring communication security, identity authentication, and data encryption. In industrial scenarios with extremely high requirements for continuous operation, such as power generation and rail transportation, any interruption of key management services may lead to the shutdown of the entire production control system; therefore, it must possess extremely high availability and reliability.

[0003] Currently, key management systems in industrial environments often employ standalone deployments or traditional master-slave configurations. In a standalone deployment, any failure in server hardware, network, database, or application processes can lead to a complete service interruption. While the traditional master-slave configuration offers some redundancy, it typically suffers from the following significant drawbacks: (1) The switching between primary and backup systems often relies on manual or semi-automatic scripts, which takes a long time and cannot meet the real-time requirements of industrial control for fault recovery at the minute or even second level. In fact, the system still has a single point of failure bottleneck.

[0004] (2) Existing solutions are difficult to effectively support the need for simultaneous and reliable access to key services across multiple network planes, such as the intranet (production control network) and the private network (management and maintenance network).

[0005] (3) At the data layer level, the database master-slave replication has a delay, which may lead to a temporary inconsistency in key status; the cache layer generally lacks a high availability design, and once it fails, it is easy to cause a service performance avalanche; the whole system lacks a systematic fault detection and automated recovery process across the network, service and data layers, and relies heavily on manual intervention, making the fault recovery time uncontrollable, and the recovery process may introduce new risks.

[0006] Therefore, there is an urgent need for a high-availability deployment solution for key management that can solve the above-mentioned technical problems. Summary of the Invention

[0007] In view of the above problems, this application is proposed to provide a highly available method, system, and electronic device for key management based on clustered deployment that overcomes or at least partially solves the above problems. The technical solution is as follows: Firstly, a highly available method for key management based on clustered deployment is provided, the method comprising: Construct a symmetric cluster consisting of a first node, a second node, and a third node, and elect a master node from the first node, the second node, and the third node through an election mechanism; each node includes a network layer, a service discovery layer, an application layer, and a data layer; Configure a virtual IP (Internet Protocol) group for the symmetric cluster to carry access requests to the master node through at least one virtual IP address; High-availability software is deployed at the network layer of each node to enable the switching of virtual IP addresses between the first, second, and third nodes; A service registration and configuration center is deployed at the service discovery layer of each node; the service registration and configuration center on each node communicates and synchronizes data through the Raft protocol (a distributed system consensus protocol); Deploy Spring Boot management services and C++ (a general-purpose programming language) / Go (Go Programming Language) business services at the application layer of each node, and register Spring Boot (an open-source framework based on Java) management services and C++ / Go business services to the service registration and configuration center of the corresponding node; Deploy MySQL (a relational database management system) instances, Redis (Remote Dictionary Server) instances, and Elasticsearch (a distributed full-text search engine) nodes in the data layer of each node, and build a highly available data cluster based on the data layer of each node; When the master node in a symmetric cluster fails, automated fault handling is performed.

[0008] In one possible implementation, the virtual IP group includes a first virtual IP address and a second virtual IP address; wherein the first virtual IP address is used to respond to access requests from intranet clients, and the second virtual IP address is used to respond to access requests from extranet clients.

[0009] In one possible implementation, high-availability software is deployed at the network layer of each node to enable virtual IP address switching between the first, second, and third nodes, including: Keepalived (a high-availability software) is deployed at the network layer of each node, and the first or second virtual IP address is automatically migrated between the first, second and third nodes through the virtual router redundancy protocol.

[0010] In one possible implementation, a highly available data cluster is built based on the data layer of each node, including: Configure the MySQL instances of the first, second, and third nodes into a highly available MySQL database cluster based on the Paxos (a distributed system consensus protocol) protocol; Deploy sentinel processes for the Redis instances on the first, second, and third nodes to form a highly available Redis sentinel cluster; Configure the Elasticsearch nodes of the first, second, and third nodes as an Elasticsearch cluster, and configure multiple primary shards and at least one replica shard for the index to build a highly available Elasticsearch cluster.

[0011] In one possible implementation, master node failures include network layer failures, application layer failures, and data layer failures. Network layer failure refers to the unreachability of the master node network carrying the first virtual IP address or the second virtual IP address; Application layer failure refers to the unavailability of the Spring Boot management service or C++ / GO business service deployed on the master node; Data layer failure refers to the failure of the master node as the master instance of a MySQL database cluster; or, the failure of the master node as the master instance of a Redis Sentinel cluster; or, the failure of the master shard of the master node hosting an Elasticsearch cluster.

[0012] In one possible implementation, when the master node in a symmetric cluster fails, automated fault handling is performed, including: When the master node experiences a network layer failure, the Keepalived software automatically migrates either the first or second virtual IP address to the currently healthy node based on the virtual router redundancy protocol. When the master node experiences an application-layer failure, the service registration and configuration center removes the unavailable Spring Boot management service or C++ / GO business service from the service registration list and routes access requests to the service instance registered on the healthy node.

[0013] In one possible implementation, when the master node in the symmetric cluster fails, and the master node failure is a data layer failure, automated fault handling is performed, including: If the master node fails as the primary instance of the MySQL database cluster, a new master instance will be automatically elected within the MySQL database cluster based on the Paxos protocol. If the master node, which serves as the master instance of the Redis Sentinel cluster, fails, a new master instance will be automatically elected and failover will be completed through inter-process communication among the Sentinels. If the primary shard of the Elasticsearch cluster on the primary node fails, the Elasticsearch cluster will automatically restore the data and services of the primary shard based on the replica shards.

[0014] In one possible implementation, the cluster size is expanded by adding new nodes with the same hierarchical architecture as the first, second, and third nodes to the symmetric cluster.

[0015] Secondly, a high-availability key management system based on clustered deployment is provided, the system comprising: The cluster building unit is used to build a symmetric cluster consisting of a first node, a second node, and a third node. A master node is elected from the first node, the second node, and the third node through an election mechanism. Each node includes a network layer, a service discovery layer, an application layer, and a data layer. A virtual IP bearer unit is used to configure a virtual IP group for a symmetric cluster, which is used to carry access requests to the master node through at least one virtual IP address. The network layer high availability unit is used to deploy high availability software at the network layer of each node to enable the switching of virtual IP addresses between the first node, the second node, and the third node. The high-availability unit at the service discovery layer is used to deploy a service registration and configuration center at the service discovery layer on each node; the service registration and configuration center on each node communicates and synchronizes data via the Raft protocol. The application layer service unit is used to deploy Spring Boot management services and C++ / GO business services at the application layer of each node, and to register the Spring Boot management services and C++ / GO business services to the service registration and configuration center of the corresponding node. The high-availability data layer unit is used to deploy MySQL instances, Redis instances, and Elasticsearch nodes in the data layer of each node, and to build a high-availability data cluster based on the data layer of each node; An automated fault handling unit is used to perform automated fault handling when the master node in a symmetric cluster fails.

[0016] Thirdly, an electronic device is provided, comprising a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the high-availability key management method based on clustered deployment as described in any of the preceding claims.

[0017] By employing the above technical solutions, the high-availability key management method, system, and electronic device based on clustered deployment provided in this application constructs a symmetric cluster consisting of three nodes, dynamically generating a master node through an election mechanism; configuring virtual IP groups for the cluster to handle access requests; and deploying high-availability components at the network layer, service discovery layer, application layer, and data layer of each node to form a full-stack high-availability architecture. When the master node fails, the system automatically performs fault recovery: the network layer switches traffic through virtual IP migration, the service discovery layer updates the service list and redirects requests, and the data layer automatically completes master instance election or data recovery within each high-availability cluster. This method achieves decentralized, redundant, and full-stack high availability for key management deployment, possessing fault isolation, accurate recovery, and flexible scalability capabilities. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0019] Figure 1 A flowchart of a high-availability key management method based on clustered deployment provided in an embodiment of this application is shown; Figure 2 This paper illustrates a structural diagram of a high-availability key management system based on clustered deployment, provided in a specific embodiment of this application. Figure 3 The flowchart illustrates a high-availability key management method based on clustered deployment provided in a specific embodiment of this application; Figure 4 This paper illustrates the structure of a high-availability key management system based on clustered deployment, as provided in an embodiment of this application. Figure 5 A structural diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the term "comprising" and its variations should be interpreted as open-ended terms meaning "including but not limited to."

[0022] Through analysis, the inventors discovered that existing technical solutions generally suffer from key defects when dealing with highly reliable and real-time industrial control environments, such as high risk of single-point failure, weak support for multiple network planes, insufficient data consistency assurance, and low degree of automation in fault recovery.

[0023] To address the aforementioned technical problems, embodiments of this application provide a highly available key management method based on clustered deployment, such as... Figure 1 As shown, this high-availability key management method based on clustered deployment may include the following steps S101 to S107: Step S101: Construct a symmetric cluster consisting of a first node, a second node, and a third node, and elect a master node from the first node, the second node, and the third node through an election mechanism; each node includes a network layer, a service discovery layer, an application layer, and a data layer.

[0024] In this step, the election mechanism refers to the process where cluster nodes exchange heartbeat information and automatically negotiate based on a consensus algorithm to dynamically select a node as the master node based on the majority voting confirmation principle. That is, the node that receives at least a majority of votes becomes the master node. Key parameters involved in the election process, such as heartbeat interval, election timeout, and node voting weight, can be flexibly configured according to the actual deployment environment and reliability requirements. For example, in a stable intranet environment, the heartbeat interval can be appropriately extended to reduce overhead, while in scenarios with high requirements for fault recovery speed, the election timeout can be shortened. This embodiment does not limit the specific configuration of the election mechanism implementation process.

[0025] Step S102: Configure a virtual IP group for the symmetric cluster to carry access requests to the master node through at least one virtual IP address.

[0026] In this step, the virtual IP group provides external clients with a unified, stable service access point that is decoupled from the backend physical server nodes. The virtual IP address is not fixed to any specific node, but floats dynamically according to the cluster status.

[0027] Step S103: Deploy high-availability software at the network layer of each node to enable the switching of virtual IP addresses between the first node, the second node, and the third node.

[0028] Step S104: Deploy a service registration and configuration center at the service discovery layer of each node; the service registration and configuration center on each node communicates and synchronizes data via the Raft protocol.

[0029] In this step, the service registration and configuration center deployed at the service discovery layer is specifically a Nacos Server (Dynamic Naming and Configuration Service Server) instance. Nacos Server instances on each node form a cluster using the Raft consensus protocol to achieve strong consistency synchronization of service registration and configuration data. The master node centrally processes all data change requests (such as service registration and deregistration), and other nodes synchronously replicate the master node's log entries. Once other nodes persist the logs, the change is committed and takes effect, thus ensuring eventual consistency of the service registry view across all nodes.

[0030] Step S105: Deploy the Spring Boot management service and C++ / GO business service at the application layer of each node, and register the Spring Boot management service and C++ / GO business service to the service registration and configuration center of the corresponding node.

[0031] In this step, the Spring Boot management service and C++ / GO business service deployed at the application layer of each node form independent service instances after startup. Each service instance is an independent process that can provide specific business capabilities (such as key generation and policy management). Each service instance completes service registration by reporting its network address, service name, health status, and other metadata to the Nacos Server service registry center of its local node.

[0032] Step S106: Deploy MySQL instances, Redis instances, and Elasticsearch nodes in the data layer of each node, and build a highly available data cluster based on the data layer of each node.

[0033] Step S107: When the master node in the symmetric cluster fails, perform automated fault handling.

[0034] This embodiment constructs a symmetric cluster consisting of three nodes, dynamically electing a master node through an election mechanism. Virtual IP groups are configured for the cluster to handle access requests. High-availability components are deployed at the network layer, service discovery layer, application layer, and data layer of each node, forming a full-stack high-availability architecture. When the master node fails, the system automatically performs fault recovery: the network layer switches traffic via virtual IP migration, the service discovery layer updates the service list and redirects requests, and the data layer automatically completes master instance election or data recovery within each high-availability cluster. This embodiment achieves decentralized, redundant, and full-stack high availability for key management deployment, possessing fault isolation, precise recovery, and flexible scalability capabilities.

[0035] This application provides a possible implementation method in which the virtual IP group in step S102 above includes a first virtual IP address and a second virtual IP address; wherein the first virtual IP address is used to respond to access requests from intranet clients, and the second virtual IP address is used to respond to access requests from extranet clients.

[0036] This embodiment configures a virtual IP group containing a first virtual IP address and a second virtual IP address for a symmetric cluster to carry access requests from intranet and extranet clients respectively. This logically isolates access traffic from multiple network planes on a single physical cluster basis, meeting the domain-specific and secure access requirements for key management services in complex industrial network environments.

[0037] This application embodiment provides a possible implementation method. In step S103 above, high availability software is deployed at the network layer of each node to enable the switching of virtual IP addresses between the first node, the second node, and the third node. Specifically, this may include the following steps: Keepalived software is deployed at the network layer of each node, and the first or second virtual IP address is automatically migrated between the first, second and third nodes through the virtual router redundancy protocol.

[0038] This embodiment utilizes a Virtual Router Redundancy Protocol (VRRP) to automatically migrate either a first or second virtual IP address between the first, second, and third nodes. VRRP is a protocol used to achieve gateway redundancy within a local area network (LAN). It virtualizes multiple physical routers into a single virtual router and uses a heartbeat mechanism to determine the status of the master node. Keepalived, as a high-availability software based on this protocol, establishes heartbeat connections between the three nodes to monitor network reachability in real time. When the master node's network status is normal, the virtual IP address is bound to the master node, handling external access requests. When the master node experiences a network failure or crashes, Keepalived automatically migrates the virtual IP address to one of the remaining normal nodes based on the VRRP's election rules. This achieves seamless switching of the virtual IP address between the three nodes, ensuring high availability at the cluster's network layer. The entire switching process requires no manual intervention and is transparent to external access requests.

[0039] This application embodiment provides a possible implementation method. Step S106 above, which involves building a highly available data cluster based on the data layer of each node, may specifically include the following steps: Configure the MySQL instances of the first, second, and third nodes into a highly available MySQL database cluster based on the Paxos protocol; Deploy sentinel processes for the Redis instances on the first, second, and third nodes to form a highly available Redis sentinel cluster; Configure the Elasticsearch nodes of the first, second, and third nodes as an Elasticsearch cluster, and configure multiple primary shards and at least one replica shard for the index to build a highly available Elasticsearch cluster.

[0040] This embodiment constructs three types of highly available data clusters. Each type of cluster runs independently and performs fault decisions, jointly supporting the high availability and reliability of the symmetric cluster data layer.

[0041] This application provides a possible implementation method in which the failure of the master node in step S107 above includes network layer failure, application layer failure and data layer failure. Network layer failure refers to the unreachability of the master node network carrying the first virtual IP address or the second virtual IP address; Application layer failure refers to the unavailability of the Spring Boot management service or C++ / GO business service deployed on the master node; Data layer failure refers to the failure of the master node as the master instance of a MySQL database cluster; or, the failure of the master node as the master instance of a Redis Sentinel cluster; or, the failure of the master shard of the master node hosting an Elasticsearch cluster.

[0042] In this embodiment, network unreachability refers to the inability to receive and respond to external access requests normally; application layer failure specifically refers to the unavailability of the Spring Boot management service or C++ / GO business service deployed on the master node, such as process crash, no response, or port occupation, which prevents the normal provision of business functions to the outside world; data layer failure specifically includes the failure of the master node as the master instance of the MySQL database cluster, i.e., the MySQL master instance process terminates, data synchronization is interrupted, or it cannot handle read and write requests; the failure of the master node as the master instance of the Redis Sentinel cluster, i.e., the Redis master instance crashes, memory overflows, or cannot respond to the Sentinel monitoring heartbeat; and the failure of the master shard of the Elasticsearch cluster carried by the master node, i.e., the node where the Elasticsearch master shard is located crashes, the shard data is corrupted, or it cannot participate in cluster data retrieval and synchronization. These three types of failures correspond to abnormal states at different levels of the cluster, and each level of failure can occur independently and trigger the corresponding level of failure handling mechanism independently, thereby realizing the layered failure management and precise recovery of the cluster.

[0043] This application embodiment provides a possible implementation method. In step S107 above, when the master node in the symmetric cluster fails, automated fault handling is performed, which specifically includes the following steps: When the master node experiences a network layer failure, the Keepalived software automatically migrates either the first or second virtual IP address to the currently healthy node based on the virtual router redundancy protocol. When the master node experiences an application-layer failure, the service registration and configuration center removes the unavailable Spring Boot management service or C++ / GO business service from the service registration list and routes access requests to the service instance registered on the healthy node.

[0044] This embodiment uses Keepalived to automatically migrate virtual IP addresses based on the VRRP protocol to handle network layer failures, and dynamically removes faulty instances and redirects requests through the service registry to handle application layer failures. This enables layered and precise fault recovery without manual intervention, ensuring the continuity and high availability of the key management service.

[0045] This application embodiment provides a possible implementation method. In step S107 above, when the master node in the symmetric cluster fails, and the master node failure is a data layer failure, automated fault handling is performed, which may specifically include the following steps: If the master node fails as the primary instance of the MySQL database cluster, a new master instance will be automatically elected within the MySQL database cluster based on the Paxos protocol. If the master node, which serves as the master instance of the Redis Sentinel cluster, fails, a new master instance will be automatically elected and failover will be completed through inter-process communication among the Sentinels. If the primary shard of the Elasticsearch cluster on the primary node fails, the Elasticsearch cluster will automatically restore the data and services of the primary shard based on the replica shards.

[0046] This embodiment addresses data layer failures by implementing automated recovery based on the fault tolerance mechanisms of each data service cluster: the MySQL cluster elects a new master instance among nodes according to the Paxos protocol, the Redis Sentinel cluster completes the master instance switch through inter-sentinel communication, and the Elasticsearch cluster automatically rebuilds the failed master shard using replica shards, thereby ensuring the continuous availability and data consistency of database, cache, and search services without intervention.

[0047] This application provides a possible implementation method to expand the cluster size by adding a new node with the same hierarchical architecture as the first node, the second node, and the third node to the symmetric cluster.

[0048] The above introduces Figure 1 The embodiments shown have various implementation methods for each stage. The following will further explain the high availability method for key management based on clustered deployment in this application through specific embodiments.

[0049] This specific embodiment achieves decentralized, redundant, and full-stack high availability for key management deployment, and has fault isolation, accurate recovery, and flexible expansion capabilities.

[0050] like Figure 2 As shown, this specific embodiment adopts a three-node symmetrical cluster architecture, which includes node A, node B, and node C. Node A is the master node. A virtual IP group is configured outside the cluster, including intranet virtual IP and private network virtual IP, which respectively carry access requests from intranet clients and private network clients. External clients access the cluster master node through the virtual IP.

[0051] Each node deploys four layers of components: the network layer deploys Keepalived, which uses the VRRP protocol to implement heartbeat detection and virtual IP migration between nodes; the service discovery layer deploys Nacos Server, with each node's Nacos Server synchronizing data via the Raft protocol; the application layer deploys Spring Boot management services and C++ / GO business services, with services registered to the corresponding node's Nacos Server; and the data layer deploys a MySQL Instance, a Redis Instance, and an Elasticsearch Node. MySQL maintains the MGR (Group Replication) cluster state via the Paxos protocol, Redis achieves high availability via the Sentinel protocol, and Elasticsearch manages shards via the cluster protocol. Each layer of components independently completes high-availability interactions through its corresponding protocol.

[0052] like Figure 3 As shown, the fault handling process when the master node fails is as follows: (a) Initial state stage 1. The cluster is in a state where node A is the MySQL master instance. At this time, the service network, Keepalived, and business applications are all in a normal state. 2. The virtual IP group is bound to node A, and external customers access the business services of node A through the virtual IP.

[0053] (II) Fault Occurrence Stage 3. The MySQL instance on node A failed, and write requests initiated by the business application returned errors, resulting in timeouts.

[0054] (III) Independent testing phase for each component 4. MySQL MGR Cluster Detection: The MGR cluster detects that the MySQL instance on node A is unresponsive, triggering the MGR cluster detection process; 5. Keepalived detection: The network status of node A is checked using the VRRP protocol to determine if it is normal, thus indicating that node A's network is healthy; 6. Nacos Cluster Detection: The Spring Boot management service and C++ / GO business service processes on node A are detected to be in normal status, indicating that the application on node A is healthy; 7. Redis Sentinel Detection: The Sentinel process checks the heartbeat status of the Redis instance and determines that the caching service is healthy if it is normal.

[0055] (iv) Fault Isolation and Recovery Phase 8. MySQL Cluster Recovery: The MySQL MGR cluster elects node B as the new master instance based on the Paxos protocol, completing the master-slave switchover and data synchronization for data services; 9. Other components are inactive: Keepalived maintains its current state (virtual IP does not drift), Nacos cluster maintains the application state as normal, and Redis Sentinel maintains the cache service as normal.

[0056] (v) Application Adaptation Phase 10. Business applications access the restored MySQL instance (which has been switched to the master instance of node B) and execute new write requests; 11. The business application completes the operation through the MySQL instance on node B and returns a success result.

[0057] In this specific embodiment, the MySQL instance failure is recovered only within the data layer, while the network layer, application layer, and cache layer remain in normal condition. This achieves independent handling of layered failures and enables automatic recovery without manual intervention.

[0058] It should be noted that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In practical applications, all the above possible implementation methods can be arbitrarily combined in a combined manner to form possible embodiments of this application, which will not be described in detail here.

[0059] Based on the high availability method for key management based on clustered deployment provided in the above embodiments, and based on the same inventive concept, this application also provides a high availability system for key management based on clustered deployment.

[0060] Figure 4 This is a structural diagram of a high-availability key management system based on clustered deployment provided in an embodiment of this application. For example... Figure 4 As shown, the high availability key management system based on clustered deployment may specifically include a cluster building unit 210, a virtual IP bearer unit 220, a network layer high availability unit 230, a service discovery layer high availability unit 240, an application layer service unit 250, a data layer high availability unit 260, and an automated fault handling unit 270.

[0061] Cluster building unit 210 is used to build a symmetric cluster consisting of a first node, a second node, and a third node, and elects a master node from the first node, the second node, and the third node through an election mechanism; each node includes a network layer, a service discovery layer, an application layer, and a data layer; Virtual IP bearer unit 220 is configured with virtual IP groups for symmetric clusters, used to carry access requests to the master node through at least one virtual IP address; The network layer high availability unit 230 is used to deploy high availability software at the network layer of each node to enable the switching of virtual IP addresses between the first node, the second node and the third node. The high-availability unit 240 at the service discovery layer is used to deploy a service registration and configuration center at the service discovery layer on each node; the service registration and configuration center on each node communicates and synchronizes data via the Raft protocol; Application layer service unit 250 is used to deploy Spring Boot management services and C++ / GO business services at the application layer of each node, and to register Spring Boot management services and C++ / GO business services to the service registration and configuration center of the corresponding node. The data layer high availability unit 260 is used to deploy MySQL instances, Redis instances, and Elasticsearch nodes in the data layer of each node, and to build a highly available data cluster based on the data layer of each node; The automated fault handling unit 270 is used to perform automated fault handling when the master node in the symmetric cluster fails.

[0062] This application embodiment provides a possible implementation, wherein the network layer high availability unit 230 is further configured to: Keepalived software is deployed at the network layer of each node, and the first or second virtual IP address is automatically migrated between the first, second and third nodes through the virtual router redundancy protocol.

[0063] This application embodiment provides a possible implementation, wherein the data layer high availability unit 260 is further configured to: Configure the MySQL instances of the first, second, and third nodes into a highly available MySQL database cluster based on the Paxos protocol; Deploy sentinel processes for the Redis instances on the first, second, and third nodes to form a highly available Redis sentinel cluster; Configure the Elasticsearch nodes of the first, second, and third nodes as an Elasticsearch cluster, and configure multiple primary shards and at least one replica shard for the index to build a highly available Elasticsearch cluster.

[0064] This application embodiment provides a possible implementation, wherein the automated fault handling unit 270 is further configured to: When the master node experiences a network layer failure, the Keepalived software automatically migrates either the first or second virtual IP address to the currently healthy node based on the virtual router redundancy protocol. When the master node experiences an application-layer failure, the service registration and configuration center removes the unavailable Spring Boot management service or C++ / GO business service from the service registration list and routes access requests to the service instance registered on the healthy node.

[0065] This application embodiment provides a possible implementation, wherein the automated fault handling unit 270 is further configured to: When the master node in a symmetric cluster fails, and the failure is a data layer failure, automated fault handling is performed: If the master node fails as the primary instance of the MySQL database cluster, a new master instance will be automatically elected within the MySQL database cluster based on the Paxos protocol. If the master node, which serves as the master instance of the Redis Sentinel cluster, fails, a new master instance will be automatically elected and failover will be completed through inter-process communication among the Sentinels. If the primary shard of the Elasticsearch cluster on the primary node fails, the Elasticsearch cluster will automatically restore the data and services of the primary shard based on the replica shards.

[0066] Based on the same inventive concept, embodiments of this application also provide an electronic device, including a processor and a memory, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the high availability key management method based on clustered deployment of any of the above embodiments.

[0067] In an exemplary embodiment, an electronic device is provided, such as Figure 5 As shown, Figure 5 The illustrated electronic device 300 includes a processor 301 and a memory 303. The processor 301 and the memory 303 are connected, for example, via a bus 302. Optionally, the electronic device 300 may also include a transceiver 304. It should be noted that in practical applications, the transceiver 304 is not limited to one type, and the structure of this electronic device 300 does not constitute a limitation on the embodiments of this application.

[0068] Processor 301 may be a CPU (Central Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 301 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0069] Bus 302 may include a pathway for transmitting information between the aforementioned components. Bus 302 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 302 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0070] The memory 303 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0071] The memory 303 stores computer program code that executes the scheme of this application, and its execution is controlled by the processor 301. The processor 301 executes the computer program code stored in the memory 303 to implement the content shown in the foregoing method embodiments.

[0072] Among them, electronic devices include, but are not limited to: mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (such as in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0073] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of this application, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to leave the protection scope of this application.

Claims

1. A highly available key management method based on clustered deployment, characterized in that, The method includes: Construct a symmetric cluster consisting of a first node, a second node, and a third node, and elect a master node from the first node, the second node, and the third node through an election mechanism; each node includes a network layer, a service discovery layer, an application layer, and a data layer; Configure a virtual IP group for the symmetric cluster to carry access requests to the master node through at least one virtual IP address; High-availability software is deployed at the network layer of each node to enable the switching of virtual IP addresses between the first, second, and third nodes; A service registration and configuration center is deployed at the service discovery layer on each node; the service registration and configuration center on each node communicates and synchronizes data via the Raft protocol. Deploy Spring Boot management services and C++ / GO business services at the application layer of each node, and register the Spring Boot management services and C++ / GO business services to the service registration and configuration center of the corresponding node; Deploy MySQL instances, Redis instances, and Elasticsearch nodes in the data layer of each node, and build a highly available data cluster based on the data layer of each node; When the master node in a symmetric cluster fails, automated fault handling is performed.

2. The method according to claim 1, characterized in that, The virtual IP group includes a first virtual IP address and a second virtual IP address; wherein the first virtual IP address is used to respond to access requests from intranet clients, and the second virtual IP address is used to respond to access requests from extranet clients.

3. The method according to claim 2, characterized in that, High-availability software is deployed at the network layer of each node to enable virtual IP address switching between the first, second, and third nodes, including: Keepalived software is deployed at the network layer of each node, and the first or second virtual IP address is automatically migrated between the first, second and third nodes through the virtual router redundancy protocol.

4. The method according to claim 1, characterized in that, A highly available data cluster is built based on the data layer of each node, including: Configure the MySQL instances of the first, second, and third nodes into a highly available MySQL database cluster based on the Paxos protocol; Deploy sentinel processes for the Redis instances on the first, second, and third nodes to form a highly available Redis sentinel cluster; Configure the Elasticsearch nodes of the first, second, and third nodes as an Elasticsearch cluster, and configure multiple primary shards and at least one replica shard for the index to build a highly available Elasticsearch cluster.

5. The method according to claim 4, characterized in that, Master node failures can include network layer failures, application layer failures, and data layer failures. Network layer failure refers to the unreachability of the master node network carrying the first virtual IP address or the second virtual IP address; Application layer failure refers to the unavailability of the Spring Boot management service or C++ / GO business service deployed on the master node; Data layer failure refers to the failure of the master node as the master instance of a MySQL database cluster; or, the failure of the master node as the master instance of a Redis Sentinel cluster; or, the failure of the master shard of the master node hosting an Elasticsearch cluster.

6. The method according to claim 5, characterized in that, When the master node in a symmetric cluster fails, automated fault handling is performed, including: When the master node experiences a network layer failure, the Keepalived software automatically migrates either the first or second virtual IP address to the currently healthy node based on the virtual router redundancy protocol. When the master node experiences an application-layer failure, the service registration and configuration center removes the unavailable Spring Boot management service or C++ / GO business service from the service registration list and routes access requests to the service instance registered on the healthy node.

7. The method according to claim 5, characterized in that, When the master node in a symmetric cluster fails, and the failure is a data layer failure, automated fault handling is performed, including: If the master node fails as the primary instance of the MySQL database cluster, a new master instance will be automatically elected within the MySQL database cluster based on the Paxos protocol. If the master node, which serves as the master instance of the Redis Sentinel cluster, fails, a new master instance will be automatically elected and failover will be completed through inter-process communication among the Sentinels. If the primary shard of the Elasticsearch cluster on the primary node fails, the Elasticsearch cluster will automatically restore the data and services of the primary shard based on the replica shards.

8. The method according to any one of claims 1 to 7, characterized in that, The method includes: The cluster size can be expanded by adding new nodes with the same hierarchical architecture as the first, second, and third nodes to the symmetric cluster.

9. A high-availability key management system based on clustered deployment, characterized in that, The system includes: The cluster building unit is used to build a symmetric cluster consisting of a first node, a second node, and a third node. A master node is elected from the first node, the second node, and the third node through an election mechanism. Each node includes a network layer, a service discovery layer, an application layer, and a data layer. A virtual IP bearer unit is used to configure a virtual IP group for a symmetric cluster, which is used to carry access requests to the master node through at least one virtual IP address. The network layer high availability unit is used to deploy high availability software at the network layer of each node to enable the switching of virtual IP addresses between the first node, the second node, and the third node. The high-availability unit at the service discovery layer is used to deploy a service registration and configuration center at the service discovery layer on each node; the service registration and configuration center on each node communicates and synchronizes data via the Raft protocol. The application layer service unit is used to deploy Spring Boot management services and C++ / GO business services at the application layer of each node, and to register the Spring Boot management services and C++ / GO business services to the service registration and configuration center of the corresponding node. The high-availability data layer unit is used to deploy MySQL instances, Redis instances, and Elasticsearch nodes in the data layer of each node, and to build a high-availability data cluster based on the data layer of each node; An automated fault handling unit is used to perform automated fault handling when the master node in a symmetric cluster fails.

10. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the high-availability key management method based on clustered deployment as described in any one of claims 1 to 8.

Images