Data storage method, system and device and electronic equipment

Abstract

The invention discloses a data storage method, system and device and electronic equipment. The method comprises the following steps: acquiring state data of a container arrangement platform; state data are stored through a distributed storage assembly, the distributed storage assembly comprises a main node and a standby node, each of the main node and the standby node comprises a distributed replication layer, a cluster consensus layer and a resource control layer, the distributed replication layer adopts a double-main mode and is used for copying the state data written into the main node to the standby node, and the cluster consensus layer is used for storing the state data written into the standby node. The cluster consensus layer is used for detecting active states of the main node and the standby node and determining an effective node after communication interruption according to a preset node weight, and the resource control layer is used for switching to the standby node for data storage when the main node fails. According to the invention, the technical problems that a 2-node etcd cluster is difficult to deploy in a mobile edge gateway environment with limited bandwidth and constrained hardware resources and the availability is poor during data storage in the prior art are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of edge computing, in particular to a data storage method, system, device and electronic equipment. BACKGROUND

[0002] Kubernetes, as the leading technology in the field of container orchestration today, is widely used in data centers, cloud computing environments and edge computing scenarios to achieve the automatic deployment, expansion and management of application programs. Its core component etcd is a highly reliable, distributed key-value storage component, mainly used to save the state data of the entire cluster, such as the configuration information of Pods, Services, Nodes and other resources.

[0003] However, etcd is usually based on the Raft consensus algorithm, and its high availability must guarantee that more than half of the nodes in the cluster are available for the master election mechanism, so the number of etcd nodes is odd, and the minimum high-availability scale is three nodes. This limitation poses a challenge in many actual deployment scenarios, especially in edge computing environments, where edge computing nodes are often limited by cost-effectiveness and physical deployment conditions, making it difficult to accommodate excessive hardware resources, and generally only 2 nodes can be used for high-availability architecture design. In addition, edge computing scenarios are often accompanied by limited bandwidth, unstable network and other factors, further exacerbating the difficulty of building a high-availability etcd cluster in a 2-node environment.

[0004] At present, there is no effective solution to the above problems. SUMMARY

[0005] The embodiments of the present application provide a data storage method, system, device and electronic equipment to at least solve the technical problems of difficult deployment of a 2-node etcd cluster in a mobile edge gateway environment with limited bandwidth and scarce hardware resources, and poor availability during data storage in the related art.

[0006] According to an aspect of an embodiment of the present application, a data storage method is provided, comprising: obtaining state data of a container orchestration platform, wherein the container orchestration platform is used for the automatic deployment, expansion and management of application containers; and storing the state data by a distributed storage component, wherein the distributed storage component includes one master node and one standby node, the master node and the standby node each include a distributed replication layer, a cluster consensus layer and a resource control layer, the distributed replication layer adopts a dual-master mode, and is used for replicating state data written to the master node to the standby node, the dual-master mode allows the master node and the standby node to read and write data simultaneously, the cluster consensus layer is used for detecting the active state of the master node and the standby node, and determining the effective node after communication interruption according to a preset node weight, and the resource control layer is used for switching to the standby node for data storage when the master node fails.

[0007] Optionally, the distributed replication layer is configured as follows: a first resource configuration file of the distributed replication layer is determined, wherein the first resource configuration file includes a preset synchronization protocol, the preset synchronization protocol being a protocol followed by synchronization of state data written to a master node to a backup node; metadata of the distributed replication layer is initialized, wherein the metadata is used to reflect a data synchronization state between the master node and the backup node; after the metadata is initialized, a data synchronization service of the distributed replication layer is started according to the first resource configuration file, and a dual-master mode of the distributed replication layer is activated.

[0008] Optionally, the cluster consensus layer is configured as follows: a second resource configuration file of the cluster consensus layer is determined, wherein the second resource configuration file includes a preset transmission protocol and a dual-node weight strategy, the preset transmission protocol being used to realize heartbeat communication between the master node and the backup node, and the dual-node weight strategy being used to determine an effective node after communication interruption; a cluster communication service of the cluster consensus layer is started according to the second resource configuration file, and an independent heartbeat network is configured for the cluster consensus layer, wherein the independent heartbeat network is used to avoid misjudgment caused by network jitter.

[0009] Optionally, the dual-node weight strategy is used to determine an effective node after communication interruption, including: a first weight corresponding to the master node and a second weight corresponding to the backup node are respectively determined, wherein the first weight is greater than the second weight; the dual-node weight strategy is determined according to the first weight, the second weight and a preset node parameter, and in the case of communication interruption between nodes, an effective node is selected from the master node and the backup node according to the dual-node weight strategy for data storage.

[0010] Optionally, the resource control layer is configured as follows: a third resource configuration file of the resource control layer is determined, wherein the third resource configuration file includes an address resource, a file system resource and a distributed storage resource; a resource arrangement sequence corresponding to the third resource configuration file is determined; and a resource management service of the resource control layer is started according to the third resource configuration file and the resource arrangement sequence.

[0011] Optionally, the method further includes: a resource stickiness parameter corresponding to the third resource configuration file is determined, wherein the resource stickiness parameter is used to limit frequent migration of resources; and the address resource, the file system resource and the distributed storage resource are bound to the same node according to the resource stickiness parameter.

[0012] Optionally, the method further comprises: promoting, by the resource management service, the distributed replication layer resource on the master node to a master state; mounting, by the resource management service, the file system resource to the master node and determining a first mounting position, wherein the first mounting position is used to represent a data storage position in the master node; allocating, by the resource management service, a target IP for the master node from an address resource, and starting the data storage service of the master node after the target IP allocation is completed, wherein the target IP is a unified access portal for external access to the distributed storage component.

[0013] Optionally, the method further comprises: in the case of failure of the master node, promoting, by the resource management service, the distributed replication layer resource on the standby node to a master state; mounting, by the resource management service, the file system resource to the standby node and determining a second mounting position, wherein the second mounting position is used to represent a data storage position in the standby node; transferring, by the resource management service, the target IP from the master node to the standby node, and starting the data storage service of the standby node after the target IP transfer is completed.

[0014] Optionally, the method further comprises: determining a database component started and stopped by the system management; switching the distributed storage component to store state data for the database component.

[0015] According to another aspect of the embodiments of the present application, a data storage system is also provided, comprising a distributed storage node, a management node and a worker node, wherein the distributed storage node is configured to receive state data of a container orchestration platform, and store the state data through a corresponding distributed storage component, wherein the container orchestration platform is used to automate deployment, expansion and management of application containers; the distributed storage component comprises a master node and a standby node, and the master node and the standby node comprise a distributed replication layer, a cluster consensus layer and a resource control layer; the distributed replication layer adopts a dual master mode, and is configured to replicate state data written in the master node to the standby node; the dual master mode allows the master node and the standby node to read and write data simultaneously; the cluster consensus layer is configured to detect active states of the master node and the standby node, and determine effective nodes after communication interruption according to preset node weights; the resource control layer is configured to switch to the standby node for data storage when the master node fails; the management node and the worker node are configured to determine corresponding management components and working components, and allocate target IPs for the management components and the working components from a preset address resource, wherein the target IPs are unified access portals for internal and external data access of the management components and the working components.

[0016] According to a further aspect of the embodiments of the present application, a data storage apparatus is also provided, comprising: an acquisition module configured to acquire state data of a container orchestration platform, wherein the container orchestration platform is configured to automate deployment, expansion and management of application containers; and a storage module configured to store the state data by means of a distributed storage component, wherein the distributed storage component comprises a primary node and a backup node, and the primary node and the backup node each comprise a distributed replication layer, a cluster consensus layer and a resource control layer, the distributed replication layer adopts a dual-primary mode, and is configured to replicate state data written to the primary node to the backup node, the dual-primary mode allows the primary node and the backup node to read and write data simultaneously, the cluster consensus layer is configured to detect active states of the primary node and the backup node, and determine effective nodes after communication interruption according to preset node weights, and the resource control layer is configured to switch to the backup node for data storage when the primary node fails.

[0017] According to a further aspect of the embodiments of the present application, an electronic device is also provided, comprising: a memory and a processor, wherein the memory is configured to store program instructions, and the processor is connected to the memory and configured to execute the above-mentioned data storage method.

[0018] According to a further aspect of the embodiments of the present application, a non-volatile storage medium is also provided, comprising a stored computer program, wherein a device in which the non-volatile storage medium is located executes the above-mentioned data storage method by running the computer program.

[0019] According to a further aspect of the embodiments of the present application, a computer program product is also provided, comprising computer instructions which, when executed by a processor, implement the above-mentioned data storage method.

[0020] In the embodiment of the present application, the state data of the container orchestration platform is obtained, wherein the container orchestration platform is used for automatic deployment, expansion and management of application containers; the state data is stored by a distributed storage component, wherein the distributed storage component includes a master node and a backup node, the master node and the backup node each include a distributed replication layer, a cluster consensus layer and a resource control layer, the distributed replication layer adopts a dual master mode, and is used for copying the state data written in the master node to the backup node, the dual master mode allows the master node and the backup node to read and write data at the same time, the cluster consensus layer is used for detecting the active state of the master node and the backup node, and determining the effective node after communication interruption according to a preset node weight, and the resource control layer is used for switching to the backup node for data storage when the master node fails, so as to achieve the purpose of optimizing Kubernetes cluster deployment and maintenance in the edge computing scenario, thereby realizing the technical effect of ensuring the service continuity and data consistency of etcd and Kubernetes as a whole even in extreme conditions such as hardware failure or network interruption, and further solving the technical problems of difficult deployment of the 2-node etcd cluster in the mobile edge gateway environment with limited bandwidth and scarce hardware resources, and poor data storage availability in the related art. BRIEF DESCRIPTION OF DRAWINGS

[0021] The drawings described herein are used to provide further understanding of the present application, and form a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation on the present application. In the drawings:

[0022] Figure 1 It is a hardware structure diagram of a computer terminal for implementing a data storage method according to an embodiment of the present application;

[0023] Figure 2 It is a flowchart of a data storage method according to an embodiment of the present application;

[0024] Figure 3 It is a structure diagram of a distributed storage component according to an embodiment of the present application;

[0025] Figure 4 It is a flowchart of a data synchronization service according to an embodiment of the present application;

[0026] Figure 5 It is a flowchart of node state detection according to an embodiment of the present application;

[0027] Figure 6 It is a whole schematic diagram of a resource definition process according to an embodiment of the present application;

[0028] Figure 7 It is a detailed schematic diagram of a resource definition process according to an embodiment of the present application;

[0029] Figure 8 is a flowchart of a master-backup node switching according to an embodiment of the present application;

[0030] Figure 9 is a structural diagram of a data storage system according to an embodiment of the present application;

[0031] Figure 10 is a structural diagram of a data storage device according to an embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to enable persons skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present application.

[0033] It should be noted that the terms “first”, “second”, and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms “include” and “have” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units does not necessarily have to be limited to only those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to the process, method, product, or device.

[0034] First, some of the nouns or terms that appear in the process of explaining the embodiments of the present application are applicable to the following explanations:

[0035] Kubernetes (K8s): an open-source container orchestration system for automating the deployment, scaling, and management of containers. It can provide a high-availability microservices architecture, simplify the complexity of application deployment and operation, and is one of the mainstream technologies in the current cloud-native environment.

[0036] etcd: a distributed, consistent key-value storage system, mainly used for service discovery, shared configuration, and distributed coordination, is the core component of the Kubernetes control plane, used to persistently store the state information of the cluster.

[0037] DRBD (Distributed Replicated Block Device): A distributed replication storage technology implemented in the Linux kernel, used to replicate block device data between two or more nodes in real-time to build a highly available storage cluster. DRBD supports full synchronization and semi-synchronization modes to ensure data consistency.

[0038] Pacemaker: An open-source cluster resource manager that dynamically manages resources such as services, file systems, and network interfaces in a cluster. It can define resource agents, failover policies, and isolation mechanisms to ensure high availability and fault recovery of resources.

[0039] Corosync: An open-source cluster communication layer that maintains communication and synchronization between cluster members. It maintains node heartbeat information through multicast or point-to-point communication to implement fault detection and avoid brain split (inconsistent state between cluster members).

[0040] Raft protocol: A distributed consensus algorithm used to achieve state consistency among multiple nodes. Compared to traditional algorithms such as Paxos, Raft is designed to be more intuitive, easier to understand and implement, especially suitable for building highly available distributed systems.

[0041] Totem protocol: A communication protocol used in Corosync to implement node communication and state synchronization. It uses multicast or unicast mechanisms to maintain node heartbeat, ensuring the consistency and arbitration of cluster state.

[0042] Kronosnet: A communication protocol option in Corosync, replacing the traditional Totem protocol. Kronosnet aims to provide a more efficient and flexible cluster member communication and state synchronization mechanism, especially optimized for modern network environments, supporting TCP / IP and other transport layer protocols.

[0043] Quorum mechanism: In a distributed system, the Quorum mechanism requires at least more than half of the nodes to participate in decision-making to ensure system stability and consistency.

[0044] Brain Split: An abnormal state in a distributed system, where a part of the cluster nodes cannot communicate with other nodes but still consider themselves part of the cluster, which may lead to inconsistent data and unstable system.

[0045] VIP (Virtual IP): commonly used in high-availability systems, providing a unified network entry for a group of servers. When the primary server fails, the VIP can be migrated to the standby server, ensuring the continuity of services.

[0046] Systemd: an initialization system and system management daemon in Linux, used to manage the startup, service management and resource allocation of the system, and is the default initialization system of Linux distribution.

[0047] In order to solve the problem of poor etcd cluster availability in the related art, the data storage method provided by the embodiment of the application can be run in Figure 1 The computer terminal is described below.

[0048] The data storage method provided by the embodiment of the application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 A hardware structure block diagram of a computer terminal for implementing the data storage method is shown. As Figure 1 shown, the computer terminal 10 can include one or more processors (the processor can include but is not limited to a microprocessor MCU or a programmable logic device FPGA processing device), a memory 104 for storing data, and a transmission module 106 for communication function through wired and / or wireless network connection. In addition, it can also include a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which can be included as one of the ports of the I / O interface), a network interface, a BUS bus. Those skilled in the art can understand, Figure 1 The structure shown is only schematic, which does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 can include more or fewer components than Figure 1 shown, or have a different configuration than Figure 1 shown.

[0049] It should be noted that the one or more processors and / or other data processing circuits described above can be referred to herein as "data processing circuits" in general. The data processing circuit can be embodied in whole or in part as software, hardware, firmware or any other combination. In addition, the data processing circuit can be a single independent processing module, or all or part of any one of the other elements combined into the computer terminal 10. As referred to in the embodiments of the present application, the data processing circuit as a kind of processor control (for example, the selection of variable resistance terminal path connected with the interface).

[0050] The memory 104 can be used to store software programs of application software and modules, such as program instructions / data storage means corresponding to the data storage method in the embodiments of the present application, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implements the data storage method described above. The memory 104 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can further include a memory remotely arranged with respect to the processor, which can be connected to the computer terminal 10 through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0051] The transmission module 106 is used to receive or send data via a network. Specific examples of the above-mentioned network can include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network adapter (NIC) which can be connected to other network devices through a base station so as to be able to communicate with the Internet. In one example, the transmission module 106 can be a radio frequency (RF) module used to communicate with the Internet in a wireless manner.

[0052] The display can be, for example, a touch screen type liquid crystal display (LCD) which can enable a user to interact with the user interface of the computer terminal 10.

[0053] It should be noted that, in some optional embodiments, the above-mentioned Figure 1 The computer terminal shown can include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that, Figure 1 is only one example of a particular implementation and is intended to illustrate the types of components that can be present in the above-described computer terminal.

[0054] Under the above-mentioned operating environment, the embodiments of the present application provide a data storage method embodiment. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a group of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in a different order.

[0055] Figure 2 is a flowchart of a data storage method according to the embodiments of the present application, as Figure 2 shown, the method comprises the following steps:

[0056] In step S202, state data of a container orchestration platform is acquired, wherein the container orchestration platform is used for automating deployment, expansion and management of application containers.

[0057] In step S202, state data can be acquired from a container orchestration platform (Kubernetes is taken as an example in the present application), including but not limited to configuration information and running states of elements such as Pods, Nodes and Services in a Kubernetes cluster, which are key to normal operation and management of the Kubernetes.

[0058] In step S204, the state data is stored by a distributed storage component, wherein the distributed storage component includes a master node and a backup node, and the master node and the backup node each include a distributed replication layer, a cluster consensus layer and a resource control layer, the distributed replication layer adopts a dual-primary mode and is used for replicating state data written in the master node to the backup node, the dual-primary mode allows the master node and the backup node to read and write data at the same time, the cluster consensus layer is used for detecting active states of the master node and the backup node and determining effective nodes after communication interruption according to preset node weights, and the resource control layer is used for switching to the backup node for data storage when the master node fails.

[0059] In step S204, the state data collected in step S202 can be stored by a core component etcd (i.e. the above-mentioned distributed storage component) in Kubernetes. As shown in Figure 3 The etcd is composed of a master node (node 1) and a backup node (node 2), and each node is internally divided into three key layers: a distributed replication layer, a cluster consensus layer and a resource control layer. Specifically:

[0060] 1. Distributed replication layer (DRBD)

[0061] a. The DRBD is deployed in a dual-primary mode to realize real-time synchronization at the block device level.

[0062] b. Protocol C full synchronization protocol is configured to ensure that state data writing returns an acknowledgement after being written to both nodes, thereby avoiding the risk of data loss.

[0063] c. Storage network is independently isolated (10 Gbps dedicated channel), and Activity Log cache is enabled to accelerate metadata update. In abnormal scenarios such as communication link interruption, node degradation protection is automatically triggered to prevent partition split-brain.

[0064] 2. Cluster consensus layer (Corosync)

[0065] a. Base Kronosnet (knet) implements cross-node heartbeat communication, which can achieve 200ms-level high-frequency state detection.

[0066] b. Adopt dual-node weight strategy (arbitration mechanism): Give the master node a higher weight (e.g. 10 points), while the standby node holds a lower weight (e.g. 5 points). In the event of communication interruption or failure, the effective node or partition can be automatically determined according to the weight of the node. If the master node cannot communicate with the standby node, but due to its higher weight, the system can still recognize the master node as a legal partition and continue to provide services until communication is restored or further failure handling measures are taken.

[0067] c. Cooperate with independent heartbeat network, that is, use special, cross-switch redundant links for inter-node heartbeat signal transmission, effectively avoid misjudgment caused by network jitter.

[0068] 3. Resource control layer (Pacemaker)

[0069] a. Define key resource linkage rules:

[0070] VIP drift: Pacemaker realizes the automatic drift of virtual IP (VIP) by binding ocf:heartbeat:IPaddr2 resource. When the etcd process of the master node times out (e.g. 30 seconds) and does not respond, automatically switch the VIP to the standby node, ensuring the continuity of the service entrance and avoiding the impact of service interruption on users.

[0071] Storage mounting: DRBD device mounting and file system (such as ext4 / XFS) linkage control. Only when the storage device is successfully mounted and confirmed as available, Pacemaker allows the etcd process to start.

[0072] Service orchestration: etcd process startup strictly depends on the completion of storage mounting.

[0073] b. Set resource stickiness parameter (resource-stickiness = 200) to limit frequent switching of resources between nodes, avoid resource drift caused by transient faults, and reduce unnecessary service interruption and system load. At the same time, through Colocation constraint, ensure that VIP, storage and etcd service process are bound to run on the same node, guarantee the continuity of service and the consistency of data.

[0074] c. Fault-tolerant reinforcement design:

[0075] Anti-split-brain mechanism: Deploy STONITH hardware isolation modules such as IPMI / iLO, when detecting node disconnection, actively power off the disconnected node, avoid the problem of two nodes considering themselves as the effective partition of the cluster, maintain the consistency of the cluster state.

[0076] Data integrity protection: Regularly (e.g. every hour) perform etcd snapshot backup to object storage, ensure that even in the case of master node failure or data loss, data can be quickly recovered from backup, maintain the integrity and availability of etcd database.

[0077] Fast recovery strategy: Integrate DRBD's differential synchronization algorithm, when the node needs to be rebuilt or rejoin the cluster, only transmit incremental data since the last synchronization, reduce data synchronization time and network bandwidth consumption, achieve fast and efficient service recovery.

[0078] Through the above steps S202 to S204, the purpose of optimizing the deployment and maintenance of Kubernetes cluster in edge computing scenario is achieved, so as to realize the technical effect of ensuring the service continuity and data consistency of etcd and Kubernetes as a whole even in extreme conditions such as hardware failure or network interruption, and further solve the technical problems of difficult deployment of 2-node etcd cluster in bandwidth-limited and hardware resource-constrained mobile edge gateway environment, and poor data storage availability in related technologies. The following will be described in detail.

[0079] The etcd database is based on Raft protocol algorithm, and its high availability must ensure that more than half of the nodes in the cluster are available for master election mechanism, so the number of etcd nodes is odd, and the minimum high availability scale is three nodes. However, in most use scenarios, due to resource constraints, only 2 nodes can be selected for high availability architecture design, and in this scenario, the high availability architecture of etcd cannot meet the requirements.

[0080] Therefore, in the embodiment of the present application, in order to ensure that the Kubernetes cluster can still achieve high availability standard in the resource-limited edge computing environment, improve the overall system stability and service continuity, a complete and systematic 2-node etcd high availability architecture is designed for storing the state data of Kubernetes cluster, the whole implementation is from the specific configuration of DRBD, Corosync and Pacemaker to resource orchestration and test verification, finally realizes lightweight, efficient and reliable data storage and management. The specific process analysis can be as follows:

[0081] I. Basic environment preparation.

[0082] 1. Establish passwordless SSH trust between nodes for convenience and security in subsequent remote operations;

[0083] 2. Create independent disk partitions (e.g., 50GB+) as backend storage for DRBD to ensure the independence and efficiency of data storage;

[0084] 3. Configure a dedicated heartbeat network, which provides higher network reliability and bandwidth through dual NIC bonding. This is key to communication and status detection among cluster members.

[0085] II. DRBD Deployment and Configuration.

[0086] Optionally, the distributed replication layer is configured as follows: A first resource configuration file for the distributed replication layer is determined, wherein the first resource configuration file includes a preset synchronization protocol, which is the protocol followed to synchronize state data written to the master node to the standby node; the metadata of the distributed replication layer is initialized, wherein the metadata is used to reflect the data synchronization status between the master node and the standby node; after the metadata initialization is completed, the data synchronization service of the distributed replication layer is started according to the first resource configuration file, and the dual-master mode of the distributed replication layer is activated. Specific analysis is as follows:

[0087] In this embodiment, the DRBD deployment configuration first requires installing the drbd-utils component to provide the necessary tools for DRBD management and operation. Then, a DRBD resource configuration file (i.e., the aforementioned first resource configuration file) is created, using Protocol C full synchronization as the preset synchronization protocol to enhance data consistency and security. Next, the drbdadm create-md command is executed to initialize metadata, laying the foundation for subsequent data synchronization. Finally, the DRBD service (i.e., the aforementioned data synchronization service) is started, and the drbdadm primary--force command is executed to simultaneously activate the dual-master mode, enabling NodeA and NodeB to handle read and write operations simultaneously, effectively utilizing resources.

[0088] like Figure 4 As shown, NodeA and NodeB form a 2-node cluster, with NodeA as the primary and NodeB as the backup. On NodeA, the command `drbdadm create-md etcd` (the etcd resource definition specified in the configuration file) is executed, triggering NodeA to send device configuration synchronization to NodeB. NodeA and NodeB start the DRBD service sequentially, and then enter a data synchronization monitoring loop. In the loop, NodeA sends real-time block synchronization commands to NodeB, and NodeB confirms the data block write position with NodeA, forming a complete data replication process.

[0089] III. Corosync Deployment Configuration.

[0090] Optionally, the cluster consensus layer is configured as follows: A second resource configuration file for the cluster consensus layer is determined, comprising a preset transmission protocol and a dual-node weighting strategy. The preset transmission protocol is used to implement heartbeat communication between the master node and the backup node, and the dual-node weighting strategy is used to determine the valid node after communication interruption. The cluster communication service of the cluster consensus layer is started according to the second resource configuration file, and an independent heartbeat network is configured for the cluster consensus layer. The independent heartbeat network is used to avoid misjudgments caused by network jitter. Specific analysis follows:

[0091] In this embodiment, the installation and configuration of Pacemaker and Corosync form the basis for cluster resource management and node communication.

[0092] In the Corosync deployment configuration, by configuring the corosync.conf file (i.e., the second resource configuration file mentioned above), Kronosnet (knet) is defined as the default transport layer protocol, supporting fast heartbeat detection and status communication. Simultaneously, a two-node Quorum strategy (two_node=1) is set, i.e., the aforementioned two-node weighted strategy. In the event of communication anomalies, the more likely correct node is automatically selected based on its weight to continue data storage and service, avoiding split-brain phenomena. Furthermore, an independent heartbeat network is deployed to avoid misjudgments caused by network jitter or instability. Even if the main data network experiences a brief failure, the independent heartbeat network can ensure the normal transmission of heartbeat signals between nodes, maintaining the correct Quorum state and cluster consensus, thereby avoiding split-brain phenomena and ensuring the high availability and data consistency of the etcd database.

[0093] like Figure 5 As shown, Node1 and Node2 form a 2-node cluster, with Node1 as the master and Node2 as the backup. Configure the corosync.conf configuration file on Node1, replacing the IP addresses of the two nodes, and then configure the file on Node2. Verify the IP address configuration on Node2, and then start the Corosync service (i.e., the cluster communication service mentioned above), entering the status cluster detection loop. The key configuration items of Corosync are shown in Table 1.

[0094] Table 1 Key Configuration Items for Corosync

[0095] Parameter Value Purpose token 1000ms Token timeout (1 second) max_messages 500 Maximum message queue number two_node 1 Two-node cluster forced identification

[0096] In the above configuration, the application of the dual-node weight strategy includes: determining a first weight and a second weight corresponding to the master node and the standby node respectively, wherein the first weight is greater than the second weight; determining the dual-node weight strategy according to the first weight, the second weight and a preset node parameter, and selecting an effective node from the master node and the standby node for data storage in the case of interruption of inter-node communication according to the dual-node weight strategy.

[0097] Specifically, under normal operation, the master node is assigned a higher weight (first weight), while the standby node holds a lower weight (second weight). Based on the first weight, the second weight and a preset cluster parameter, such as the minimum number of node survival (quorum) in the cluster, the dual-node weight strategy can be determined, which ensures that when the inter-node communication is interrupted, the node with higher weight can be quickly identified and selected as the effective node to continue to provide services and store data. When the communication interruption occurs, Corosync makes a decision by comparing the node weights. If the master node cannot communicate with the standby node, but it has a higher first weight, it will be considered as an effective partition and continue to run. This mechanism avoids the brain split phenomenon, that is, the cluster is split into two or more independent sub-clusters, each of which considers itself to be legitimate, which may cause data inconsistency and other problems.

[0098] IV. Pacemaker deployment configuration.

[0099] Optionally, the resource control layer is configured as follows: a third resource configuration file of the resource control layer is determined, wherein the third resource configuration file includes address resources, file system resources and distributed storage resources; a resource arrangement sequence corresponding to the third resource configuration file is determined; and a resource management service of the resource control layer is started according to the third resource configuration file and the resource arrangement sequence. The specific analysis is as follows:

[0100] In the embodiment of the application, the CRM shell of Pacemaker defines key resources, including VIP resources (address resources), FS resources (file system resources) and etcd resources, and defines the dependency relationship and operation sequence among the resources. Pacemaker can effectively coordinate the behavior of these resources in the 2-node etcd high-availability architecture. The specific analysis is as follows:

[0101] VIP resource configuration: create a VIP resource through the ocf:heartbeat:IPaddr2 agent. This resource will be automatically activated on the master node and will drift to the standby node when the master node fails, ensuring that external access to the etcd cluster will not be interrupted.

[0102] FS resource configuration: using the ocf:heartbeat:Filesystem agent to perform the file system mounting operation on the DRBD backend storage. Only after the DRBD device is successfully mounted and converted into an available file system, the etcd resource can be started, ensuring that the etcd service runs on the latest and consistent data state.

[0103] etcd resource configuration: provided by systemd:etcd (dependent on the file system resource), ensuring that the startup of the etcd service strictly depends on the completion of the file system mounting.

[0104] Resource constraint 1: determine the resource stickiness parameter corresponding to the third resource configuration file, wherein the resource stickiness parameter is used to limit the frequent migration of resources; and bind the address resource, the file system resource and the distributed storage resource to the same node according to the resource stickiness parameter.

[0105] Specifically, Pacemaker can specify that the three resources created must exist on the same node in strong consistency by setting the resource stickiness parameter (resource-stickiness = 200). If a node becomes the master node, all associated resources must also run on the node, ensuring the close coupling between resources and the orderly performance of the failover.

[0106] Resource constraint 2: the resource arrangement order is set as: DRBD switching → file system mounting → VIP allocation → etcd service startup.

[0107] This resource arrangement order ensures the synchronization of data, the availability of the file system, the continuity of the service entrance and the startup order of the etcd service, which is an important guarantee for the safety and stability of the entire high-availability architecture.

[0108] In the embodiment of the present application, the resource definition process includes: promoting the distributed replication layer resource on the master node to the master state through the resource management service; mounting the file system resource to the master node through the resource management service and determining a first mounting position, wherein the first mounting position is used to represent a data storage position in the master node; allocating a target IP for the master node from the address resource through the resource management service, and starting the data storage service of the master node after the target IP allocation is completed, wherein the target IP is a unified access entrance for external access to the distributed storage component.

[0109] As shown in Figure 6 , Pacemaker first promotes the DRBD resource to the master primary, then performs file system mounting, the mounting point (mounting position) is ready, then performs VIP resource allocation and activates the IP, and finally starts the etcd service.

[0110] The specific implementation details are as follows:Figure 7 As shown, NodeA and NodeB form a 2-node cluster, with NodeA as the primary and NodeB as the backup. DRBD / FS / VIP / ETCD are defined resources. Pacemaker performs drbd_resource_promote on the DRBD resource on NodeA, which is to promote the resource to primary. After the DRBD resource is promoted and the data is synchronized, Pacemaker mounts the FS resource on NodeA. After the mount point (i.e., the first mount position mentioned above) is confirmed, Pacemaker allocates a VIP (i.e., target IP) to NodeA from the VIP resource and confirms the IP activation status by probing the VIP through ARP. After the IP is activated, Pacemaker operates on the etcd resource on NodeA, such as starting the etcd service (i.e., the data storage service mentioned above) through systemd. After etcd is successfully started and running, Pacemaker confirms NodeA as the primary and marks the resource operation as complete.

[0111] V. Verification and Testing.

[0112] Verify and test the entire system, such as triggering a failure of the etcd process on the master node and observing the VIP drift to verify the failover mechanism; verify data consistency and DRBD synchronization effect by performing cross-node etcd write operations; and simulate network isolation to test the effectiveness of the automatic STONITH mechanism to ensure that the system can react correctly in extreme cases and protect data security.

[0113] In this embodiment, the method further includes: in the event of a failure of the primary node, promoting the distributed replication layer resources on the backup node to the primary state through the resource management service; mounting the file system resources to the backup node through the resource management service and determining a second mount location, wherein the second mount location is used to represent the data storage location in the backup node; transferring the target IP from the primary node to the backup node through the resource management service, and starting the data storage service on the backup node after the target IP transfer is completed.

[0114] like Figure 8 As shown, when a primary node failure is triggered, DRBD is controlled via Pacemaker and / or Corosync to perform a master-slave switch, switching the backup node to the primary node. Simultaneously, the DRBD resources on the backup node are promoted to primary status. After the DRBD resources are promoted and the data is synchronized, FS resources are mounted on the backup node. Once the mount point (i.e., the second mount position mentioned above) is confirmed, the VIP is controlled to drift to the backup node, that is, the VIP is transferred from the primary node to the backup node. The IP activation status of the VIP is confirmed by ARP detection. After the IP is activated, the etcd service on the backup node is started. After etcd is successfully started and running, the backup node is confirmed as the primary node and the resource operation is marked as complete.

[0115] It should be noted that when the original master node recovers, it can rejoin the system and become a backup node.

[0116] Optionally, the method further comprises: determining a database component managed by the system to start and stop; and switching the distributed storage component to store state data for the database component.

[0117] In the embodiments of the present application, one significant advantage is flexibility. The high-availability architecture design described above is not limited to etcd, but can also be switched to or applied to any database component that can be managed by systemd to start and stop, such as MySQL, Redis, PostgreSQL, etc.

[0118] The key of this mechanism is the integration of DRBD, Corosync, Pacemaker and STONITH. By adjusting the configuration and resource agent, these components can adapt to different database requirements, achieve fast and reliable failover and data synchronization, ensure high availability, and provide unified high-availability architecture support for various types of databases, which can be widely used in different database scenarios, further enhancing the generality and practicality of the scheme.

[0119] In summary, the present application ingeniously combines DRBD, Corosync, Pacemaker and kube-vip technologies, and for the first time realizes the high availability of etcd and the entire Kubernetes cluster in a 2-node environment with extremely limited resources. By designing a dual-master hot standby mechanism and optimizing resource stickiness parameters, not only does it solve the limitation of odd-numbered nodes for etcd database based on Raft protocol, but also ensures the high availability of cluster entry through kube-vip components. Even in the case of a node failure, the other node can quickly take over the service and provide uninterrupted database support and Kubernetes orchestration capabilities. In addition, the present application also demonstrates scalability, which can easily switch to other systemd-managed database components such as MySQL, Redis, PostgreSQL, etc., greatly expanding its application scenarios and value, and providing strong technical support for high-availability deployment in edge computing, Internet of Things and other limited environments.

[0120] According to the embodiments of the present application, a data storage system is provided. It should be noted that the data storage system of the embodiments of the present application can be used to execute the data storage method provided by the embodiments of the present application. The data storage system provided by the embodiments of the present application is introduced as follows.

[0121] The structure diagram of the data storage system includes an etcd node, a master node and a worker node, in particular:

[0122] The distributed storage node is configured to receive state data of a container orchestration platform, wherein the container orchestration platform is configured to automate deployment, expansion and management of application containers; and store the state data through a corresponding distributed storage component, wherein the distributed storage component includes a master node and a backup node, the master node and the backup node include a distributed replication layer, a cluster consensus layer and a resource control layer, the distributed replication layer adopts a dual master mode, and is configured to replicate state data written in the master node to the backup node, the dual master mode allows the master node and the backup node to read and write data simultaneously, the cluster consensus layer is configured to detect active states of the master node and the backup node, and determine effective nodes after communication interruption according to preset node weights, and the resource control layer is configured to switch to the backup node for data storage when the master node fails;

[0123] The master node and the worker node are configured to determine corresponding management components and working components, and allocate target IP for the management components and the working components from preset address resources, wherein the target IP is a unified access portal for realizing internal and external data access of the management components and the working components.

[0124] In the embodiments of the present application, a highly available kubernetes cluster is mainly composed of three role nodes of master, worker and etcd. Among them, the etcd role can be realized by the above-mentioned high-availability architecture design, and the remaining master role and worker role in the 2-node environment can be realized by deploying master and worker components on each node at the same time, and using kube-vip as a high-availability load balancer, so as to ensure that even in the case of single node failure, the cluster can still provide stable services.

[0125] As Figure 9As shown, the etcd node is based on the DRBD+Corosync+Pacemaker architecture, is the core of the kubernetes cluster state storage, and is the cornerstone of the overall high availability. Further, the master component (kube-apiserver / kube-scheduler / kube-controller-manager), the worker component (kubelet / kube-proxy), and the load balancer component kube-vip (i.e., the preset address resource) are deployed on each node, and the VIP (i.e., the target IP) managed by the load balancer component kube-vip is obtained, and the IP in the access configuration file of the kubernetes cluster is configured as the VIP. It should be noted that the VIP is the unified network address of the kubernetes cluster, and all internal and external access traffics of the management component and the worker component are accessed through the VIP.

[0126] In the embodiment of the present application, by unifying the network access of the management component and the worker component to one VIP, the following two important goals are achieved: first, even in the case of single node failure, external requests can be seamlessly routed to another healthy node, ensuring service continuity; second, the communication between internal components is also through the VIP, simplifying the data interaction process between nodes, improving the operation and maintenance efficiency of the cluster and the overall system robustness.

[0127] According to the embodiment of the present application, a data storage device is provided. It should be noted that the data storage device of the embodiment of the present application can be used to execute the data storage method provided by the embodiment of the present application. The data storage device provided by the embodiment of the present application is introduced as follows.

[0128] Figure 10 is a structural diagram of a data storage device according to the embodiment of the present application. As shown in the figure, Figure 10 The device comprises:

[0129] The obtaining module 1002 is configured to obtain state data of a container orchestration platform, wherein the container orchestration platform is used for automatic deployment, expansion and management of containers.

[0130] The storage module 1004 is configured to store the state data by using a distributed storage component, wherein the distributed storage component comprises a master node and a backup node, the master node and the backup node each comprise a distributed replication layer, a cluster consensus layer and a resource control layer, the distributed replication layer adopts a dual-master mode, and is configured to copy the state data written in the master node to the backup node, the dual-master mode allows the master node and the backup node to read and write data at the same time, the cluster consensus layer is configured to detect the active state of the master node and the backup node, and determine the effective node after communication interruption according to a preset node weight, and the resource control layer is configured to switch to the backup node for data storage when the master node fails.

[0131] Through the acquisition module and the storage module in the data storage device, the purpose of optimizing Kubernetes cluster deployment and maintenance in an edge computing scenario is achieved, so that the technical effect of ensuring the service continuity and data consistency of etcd and Kubernetes as a whole even in extreme conditions such as hardware failure or network interruption is achieved, and the technical problems of difficulty in deploying a 2-node etcd cluster in a mobile edge gateway environment with limited bandwidth and scarce hardware resources, and poor data storage availability in the related art are solved.

[0132] In the data storage device provided in the embodiments of the present application, the configuration module is further configured to determine a first resource configuration file of the distributed replication layer, wherein the first resource configuration file comprises a preset synchronization protocol, the preset synchronization protocol is a protocol followed by the state data written in the master node and synchronized to the backup node; initialize metadata of the distributed replication layer, wherein the metadata is used to reflect the data synchronization state between the master node and the backup node; after the metadata is initialized, start a data synchronization service of the distributed replication layer according to the first resource configuration file, and activate a dual-master mode of the distributed replication layer.

[0133] In the data storage device provided in the embodiments of the present application, the configuration module 1006 is further configured to determine a second resource configuration file of the cluster consensus layer, wherein the second resource configuration file comprises a preset transmission protocol and a dual-node weight strategy, the preset transmission protocol is used to realize heartbeat communication between the master node and the backup node, and the dual-node weight strategy is used to determine the effective node after communication interruption; start a cluster communication service of the cluster consensus layer according to the second resource configuration file, and configure an independent heartbeat network for the cluster consensus layer, wherein the independent heartbeat network is used to avoid misjudgment phenomenon caused by network jitter.

[0134] In the data storage device provided by the embodiment of the application, the configuration module is further configured to determine a first weight and a second weight corresponding to the master node and the backup node respectively, wherein the first weight is greater than the second weight; determine a dual-node weight strategy according to the first weight, the second weight and a preset node parameter, and select an effective node from the master node and the backup node to store data according to the dual-node weight strategy in the case of interruption of inter-node communication.

[0135] In the data storage device provided by the embodiment of the application, the configuration module is further configured to determine a third resource configuration file of the resource control layer, wherein the third resource configuration file comprises address resources, file system resources and distributed storage resources; determine a resource arrangement sequence corresponding to the third resource configuration file; and start a resource management service of the resource control layer according to the third resource configuration file and the resource arrangement sequence.

[0136] In the data storage device provided by the embodiment of the application, the configuration module is further configured to determine a resource stickiness parameter corresponding to the third resource configuration file, wherein the resource stickiness parameter is used to limit frequent migration of resources; and bind the address resources, the file system resources and the distributed storage resources to the same node according to the resource stickiness parameter.

[0137] In the data storage device provided by the embodiment of the application, the storage module is further configured to promote, by the resource management service, a distributed replication layer resource on the master node to a master state; mount, by the resource management service, the file system resources to the master node and determine a first mounting position, wherein the first mounting position is used to represent a data storage position in the master node; allocate, by the resource management service, a target IP for the master node from the address resources, and start a data storage service of the master node after the target IP allocation is completed, wherein the target IP is a unified access portal for external access to the distributed storage component.

[0138] In the data storage device provided by the embodiment of the application, the storage module is further configured to promote, by the resource management service, a distributed replication layer resource on the backup node to a master state in the case of failure of the master node; mount, by the resource management service, the file system resources to the backup node and determine a second mounting position, wherein the second mounting position is used to represent a data storage position in the backup node; transfer, by the resource management service, the target IP from the master node to the backup node, and start a data storage service of the backup node after the target IP transfer is completed.

[0139] In the data storage device provided by the embodiment of the application, the storage module is further configured to determine a database component started and stopped by the system management; and switch the distributed storage component to the database component to store state data.

[0140] The embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory is used for storing program instructions; the processor is connected with the memory and is used for executing the data storage method.

[0141] It should be noted that the electronic device is used for executing the data storage method as shown in the above Figure 2 Therefore, the related explanations in the data storage method are also applicable to the electronic device, and details are not described herein.

[0142] The embodiment of the present application further provides a nonvolatile storage medium, comprising a stored computer program, wherein a device where the nonvolatile storage medium is located executes the data storage method by running the computer program.

[0143] It should be noted that the nonvolatile storage medium is used for executing the data storage method as shown in the above Figure 2 Therefore, the related explanations in the data storage method are also applicable to the nonvolatile storage medium, and details are not described herein.

[0144] The embodiment of the present application further provides a computer program product, comprising computer instructions, which are executed by a processor to implement the data storage method.

[0145] It should be noted that the computer program product is used for executing the data storage method as shown in the above Figure 2 Therefore, the related explanations in the data storage method are also applicable to the computer program product, and details are not described herein.

[0146] The serial numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0147] In the above embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0148] In the several embodiments provided by the present application, it should be understood that the disclosed technology can be implemented in other ways. Of course, the unit division in the above-described device embodiment is only a logical function division, and there can be another division manner during actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, units or modules, and can be electrical or other forms.

[0149] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0150] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present alone, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0151] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part of the prior art that contributes to the technical solutions or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: a U disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a mobile hard disk, a magnetic disk or an optical disk, and various program code storage media.

[0152] The above is only the preferred embodiment of the present application, and it should be pointed out that for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, and these improvements and refinements should be considered as the protection scope of the present application.

Claims

1. A data storage method, characterized in that, include: Obtain status data from a container orchestration platform, wherein the container orchestration platform is used to automate the deployment, scaling, and management of application containers; The state data is stored using a distributed storage component, which includes a primary node and a backup node. Both the primary node and the backup node include a distributed replication layer, a cluster consensus layer, and a resource control layer. The distributed replication layer adopts a dual-primary mode and is used to replicate the state data written to the primary node to the backup node. The dual-primary mode allows the primary node and the backup node to read and write data simultaneously. The cluster consensus layer is used to detect the active status of the primary node and the backup node and determine the valid node after a communication interruption based on a preset node weight. The resource control layer is used to switch to the backup node for data storage when the primary node fails.

2. The method according to claim 1, characterized in that, The distributed replication layer is configured as follows: A first resource configuration file for the distributed replication layer is determined, wherein the first resource configuration file includes a preset synchronization protocol, the preset synchronization protocol being a protocol followed by which state data written to the master node is synchronized to the backup node; Initialize the metadata of the distributed replication layer, wherein the metadata is used to reflect the data synchronization status between the master node and the backup node; After the metadata initialization is completed, the data synchronization service of the distributed replication layer is started according to the first resource configuration file, and the dual-master mode of the distributed replication layer is activated.

3. The method according to claim 1, characterized in that, The cluster consensus layer is configured as follows: The second resource configuration file of the cluster consensus layer is determined, wherein the second resource configuration file includes a preset transmission protocol and a dual-node weight strategy. The preset transmission protocol is used to implement heartbeat communication between the master node and the backup node, and the dual-node weight strategy is used to determine the effective node after communication is interrupted. The cluster communication service of the cluster consensus layer is started according to the second resource configuration file, and an independent heartbeat network is configured for the cluster consensus layer. The independent heartbeat network is used to avoid misjudgment caused by network jitter.

4. The method according to claim 3, characterized in that, The dual-node weighting strategy is used to determine the valid nodes after communication interruption, including: A first weight and a second weight are determined for the master node and the backup node, respectively, wherein the first weight is greater than the second weight; The dual-node weighting strategy is determined based on the first weight, the second weight, and the preset node parameters. In the event of an interruption in inter-node communication, a valid node is selected from the primary node and the backup node for data storage based on the dual-node weighting strategy.

5. The method according to claim 1, characterized in that, The resource control layer is configured as follows: The third resource configuration file of the resource control layer is determined, wherein the third resource configuration file includes address resources, file system resources and distributed storage resources; Determine the resource orchestration order corresponding to the third resource configuration file; The resource management service of the resource control layer is started according to the third resource configuration file and the resource orchestration order.

6. The method according to claim 5, characterized in that, The method further includes: Determine the resource stickiness parameter corresponding to the third resource configuration file, wherein the resource stickiness parameter is used to limit the frequent migration of resources; The address resource, the file system resource, and the distributed storage resource are bound to the same node based on the resource stickiness parameter.

7. The method according to claim 5, characterized in that, The method further includes: The resource management service is used to promote the distributed replication layer resources on the master node to master status. The file system resources are mounted to the master node through the resource management service, and a first mount location is determined, wherein the first mount location is used to represent the data storage location in the master node; The resource management service allocates a target IP to the master node from the address resources, and starts the data storage service of the master node after the target IP is allocated. The target IP is a unified access point for external access to the distributed storage component.

8. The method according to claim 7, characterized in that, The method further includes: In the event of a failure of the primary node, the resource management service will promote the distributed replication layer resources on the backup node to the primary state. The file system resources are mounted to the standby node through the resource management service, and a second mount location is determined, wherein the second mount location is used to represent the data storage location in the standby node; The target IP is transferred from the primary node to the backup node through the resource management service, and the data storage service of the backup node is started after the target IP transfer is completed.

9. The method according to claim 1, characterized in that, The method further includes: Identify the database components that are started and stopped by system management; The distributed storage component is switched to the database component to store the state data.

10. A data storage system, characterized in that, It includes distributed storage nodes, management nodes, and worker nodes, among which, The distributed storage node is used to receive status data from the container orchestration platform, which is used to automate the deployment, expansion, and management of application containers. The distributed storage node stores the status data through a corresponding distributed storage component, which includes a primary node and a backup node. The primary node and the backup node each include a distributed replication layer, a cluster consensus layer, and a resource control layer. The distributed replication layer adopts a dual-primary mode and is used to replicate status data written to the primary node to the backup node. The dual-primary mode allows the primary node and the backup node to read and write data simultaneously. The cluster consensus layer is used to detect the active status of the primary node and the backup node and determine the effective node after a communication interruption based on a preset node weight. The resource control layer is used to switch to the backup node for data storage when the primary node fails. The management node and the working node are used to determine the corresponding management component and working component, and to allocate target IPs to the management component and the working component from the preset address resources. The target IP is a unified access point for the management component and the working component to access internal and external data.

11. A data storage device, characterized in that, include: The acquisition module is used to acquire status data of the container orchestration platform, wherein the container orchestration platform is used to automate the deployment, scaling and management of application containers; A storage module is used to store the state data through a distributed storage component. The distributed storage component includes a primary node and a backup node. Both the primary node and the backup node include a distributed replication layer, a cluster consensus layer, and a resource control layer. The distributed replication layer adopts a dual-primary mode and is used to replicate the state data written to the primary node to the backup node. The dual-primary mode allows the primary node and the backup node to read and write data simultaneously. The cluster consensus layer is used to detect the active status of the primary node and the backup node and determine the valid node after communication interruption based on a preset node weight. The resource control layer is used to switch to the backup node for data storage when the primary node fails.

12. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; The processor, connected to the memory, is used to execute the data storage method according to any one of claims 1 to 9.

13. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the data storage method according to any one of claims 1 to 9 by running the computer program.

14. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the data storage method according to any one of claims 1 to 9.

Images