CN107368369B - Distributed container management method and system - Google Patents

Abstract

The invention provides a distributed container management method and a distributed container management system.A Cassandra ring network topology comprises a plurality of nodes and host nodes corresponding to the nodes, and the host nodes comprise a plurality of containers; the method comprises the following steps: the Cassandra component module sends container load request information to the container management module; the container management module acquires container resource information according to the container load request information and sends log request information to the log monitoring module; the log monitoring module acquires log monitoring information used for being sent to the container management module according to the log request information; the container management module receives the log monitoring information, and fuses the container resource information and the log monitoring information into container load information which is sent to the Cassandra component module; and the Cassandra component module receives the container load information and sends the container load information to other host nodes so as to realize the sharing of the container load information among the host nodes.

Description

Distributed container management method and system

technical field

The present invention relates to the field of communication technologies, and in particular, to a distributed container management method and system.

Background technique

With the development of container technology, container technology and virtualization technology have become a widely recognized method of container technology server resource sharing. Container technology can provide operators with extreme great flexibility.

At present, the container technology often used in the prior art is the Docker technology, and the container management is mainly implemented in a master-slave manner. Specifically, a master node is used to manage the entire container cluster. In addition, the registration, creation and management of containers on the node can also be realized by the proxy of the container orchestration tool. For example, Kuber-proxy needs to be deployed on each node to realize the proxy of the node, and Kuber-proxy is used to realize the Management of Pod containers on nodes, etc.

However, the master-slave mode of the existing container management technology constrains the flat management of container clusters, thereby constraining the response mechanism for rapid container expansion and contraction. Specifically, if the traditional master-slave mode is adopted, the role of the host needs to be determined in advance , so that when creating multiple container nodes with few clusters, one or more machines need to be set aside as the master node to manage the containers on other slave nodes of the container cluster in a unified manner, while the master node cannot deploy containers, so it greatly Resources are wasted. In addition, the location of the container shared database cluster is relatively concentrated. Generally, the database cluster is mainly concentrated on a few nodes, and there is no data backup on other nodes. Therefore, when the network on a node fails, the entire node The container will automatically fail, and all containers on the node need to be recreated on other nodes. If it is a container for the core business, it will inevitably cause the possibility of slow business requests or downtime.

SUMMARY OF THE INVENTION

The present invention provides a distributed container management system and method, which is used to solve the problem that the main node in the prior art cannot deploy the container, so resources are greatly wasted, and the location of the container shared database cluster is relatively concentrated, which easily causes the service request to be slow or downtime. The problem.

One aspect of the present invention provides a distributed container management method based on a Cassandra ring network topology. The Cassandra ring network topology includes multiple nodes, each node corresponds to a host node, and the host node includes multiple nodes. A container; the host node also includes a Cassandra component module, a container management module and a log monitoring module, and the method includes:

The Cassandra component module sends container load request information to the container management module;

The container management module acquires container resource information stored by itself according to the container load request information, and sends log request information to the log monitoring module according to the container load request information;

The log monitoring module obtains log monitoring information according to the log request information, and sends the log monitoring information to the container management module;

The container management module receives the log monitoring information, performs fusion processing on the container resource information and the log monitoring information, obtains the container load information, and sends the container load information to the Cassandra component module;

The Cassandra component module receives the container load information, and sends the container load information to other host nodes, so as to realize the sharing of the container load information among the host nodes.

Another aspect of the present invention provides a distributed container management system based on a Cassandra ring network topology. The Cassandra ring network topology includes multiple nodes, each node corresponds to a host node, and the host node includes a plurality of containers; the system includes:

The Cassandra component module is used to send container load request information to the container management module;

The container management module is configured to acquire container resource information stored by itself according to the container load request information, and send log request information to the log monitoring module according to the container load request information;

the log monitoring module, configured to obtain log monitoring information according to the log request information, and send the log monitoring information to the container management module;

The container management module is further configured to receive the log monitoring information, perform fusion processing on the container resource information and the log monitoring information, obtain container load information, and send the container load information to the Cassandra component module;

The Cassandra component module is further configured to receive the container load information, and send the container load information to other host nodes, so as to realize the sharing of the container load information among the host nodes.

The distributed container management method and system provided by the present invention are implemented based on the Cassandra ring network topology, and each host node in the Cassandra ring network topology may include multiple containers, thereby effectively improving the utilization of resources; At the same time, the container load information can be shared between the host nodes. Therefore, it effectively overcomes the problem that the container shared database cluster in the prior art is relatively centralized, which easily causes the service request to be slow or downtime. The practicality of the management method is conducive to the promotion and application of the market.

Description of drawings

1 is a schematic flowchart of a distributed container management method based on a Cassandra ring network topology provided by an embodiment of the present invention;

2 is a schematic structural diagram of a Cassandra ring network topology provided by an embodiment of the present invention;

3 is a schematic flowchart of a Cassandra component module sending container load request information to the container management module according to an embodiment of the present invention;

4 is a schematic flowchart of another distributed container management method based on a Cassandra ring network topology provided by an embodiment of the present invention;

5 is a schematic flowchart of a target host node creating a corresponding container according to the container data information according to an embodiment of the present invention;

6 is a schematic flowchart of another distributed container management method based on Cassandra ring network topology provided by an embodiment of the present invention;

7 is a schematic structural diagram of a host node architecture according to an embodiment of the present invention;

8 is a schematic flowchart of a specific application of a distributed container management method based on a Cassandra ring network topology provided by an embodiment of the present invention;

9 is a schematic flowchart of another specific application of a distributed container management method based on a Cassandra ring network topology provided by an embodiment of the present invention;

FIG. 10 is a schematic structural diagram of a distributed container management system based on a Cassandra ring network topology according to an embodiment of the present invention.

Detailed ways

The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and embodiments. The following examples are intended to illustrate the present invention, but not to limit the scope of the present invention.

Cassandra technology is an open source distributed NoSQL database system. It was originally developed by Facebook to store data in simple formats such as inboxes. It integrates the data model of Google Big Table and the fully distributed architecture of Amazon Dynamo. Facebook opened Cassandra in 2008. Since then, due to the good quality of Cassandra Scalability, adopted by well-known Web2.0 websites such as Digg and Twitter, has become a popular distributed structured data storage solution.

Cassandra is a hybrid non-relational database, similar to Google's Big Table. Its main functions are richer than Dynamo (distributed Key-Value storage system), but its support is not as good as that of document storage MangoDB (an open source product between relational databases and non-relational data, which is the most feature-rich and most non-relational database among non-relational databases). Like relational databases. The supported data structure is very loose, and it is a bjson format similar to json, so it can store more complex data types).

The main feature of Cassandra is that it is not a database in the full sense, but a distributed network service composed of a bunch of database nodes. A write operation to Cassandra will be replicated to other nodes, and a read operation to Cassandra, It will also be routed to a node to read. For a Cassandra cluster, scaling performance is relatively simple, just add nodes to the cluster.

Compared with other databases, Cassandra has the following three prominent features: (1) The schema is flexible. Using Cassandra, like document storage, users do not have to solve the fields in the record in advance. (2) Scalability, so that amazing improvements in efficiency can be achieved, especially in large-scale deployments. Cassandra is purely horizontal scaling. To add more capacity to the cluster, you can point to another physical node, change application queries, or manually migrate any data without having to restart any processes. (3) Multiple data centers, the user's node layout can be adjusted to avoid a fire in a data center, and a spare data center will have at least a full copy of each record.

1 is a schematic flowchart of a distributed container management method based on a Cassandra ring network topology provided by an embodiment of the present invention, and FIG. 2 is a schematic structural diagram of a Cassandra ring network topology provided by an embodiment of the present invention; Based on the above Cassandra technology, Referring to Figures 1-2, this embodiment provides a distributed container management method based on the Cassandra ring network topology, wherein, referring to Figure 2, it can be seen that the Cassandra ring network topology includes multiple nodes, and each node corresponds to a The host node, the host node can include multiple containers, wherein, the containers on each host node are not required to be a certain application cluster; in addition, a preset protocol method (gossip protocol) can be used between the host nodes. method) to realize applications such as mutual communication, status monitoring, data access, etc. Specifically, the host node also includes a Cassandra component module, a container management module and a log monitoring module, and the method includes:

S101: The Cassandra component module sends container load request information to the container management module;

Among them, the Cassandra component module can be used to realize the internal management, data coordination and unified management of the host node; the container management module is mainly responsible for the management of the containers created on the host node; when the host nodes need to communicate with each other or When the data access function is used, the Cassandra component module will send the container load request information to the container management module. The container load request information is used to obtain the container load information on the host node, so as to realize the container load information between each host node. shared.

S102: The container management module obtains the container resource information stored by itself according to the container load request information, and sends log request information to the log monitoring module according to the container load request information;

Among them, the log monitoring module is mainly responsible for collecting and monitoring logs during the container operation and operation. When the container management module receives the container load request information, it can obtain the container resource information stored by itself according to the container load request information. The resource information is part of the container load information; in order to obtain the complete container load information, the container management module can also send log request information to the log monitoring module according to the container load request information, and the log request information is used to obtain the log request information stored in the log monitoring module. The log monitoring information, where the log monitoring information is also part of the container load information.

S103: The log monitoring module obtains the log monitoring information according to the log request information, and sends the log monitoring information to the container management module;

After the log monitoring module receives the log request information, it can query the log monitoring information stored by itself according to the log request information. Since the log monitoring information is part of the container load information, the log monitoring module will monitor the obtained logs. The information is sent to the container management module, so that the container management module obtains the container load information according to the container resource information and the log monitoring information.

S104: The container management module receives the log monitoring information, integrates the container resource information and the log monitoring information, obtains the container load information, and sends the container load information to the Cassandra component module;

After the container management module receives the log monitoring information, it can perform fusion processing on the container resource information and the log monitoring information according to a preset algorithm (the specific fusion algorithm can be set by those skilled in the art according to specific design requirements), thereby The container load information can be obtained. The container load information is the data information that needs to be shared between each host node. Therefore, the container load information needs to be sent to the Cassandra component module, so that the Cassandra component module can implement each host. Data sharing between nodes.

S105: The Cassandra component module receives the container load information, and sends the container load information to other host nodes, so as to realize the sharing of the container load information among the host nodes.

After the Cassandra component module receives the container load information, it can send the container load information to other host nodes by broadcasting or other forms, so that other host nodes can obtain the container load information on the host node, realizing The sharing of information between the host nodes realizes that if the network of the host node of the core business is abnormal, since the container load information of the host node is stored on other host nodes, the container load information of the host node can be stored immediately. Load information creates corresponding containers, thereby effectively ensuring the timely response efficiency of business requests.

The distributed container management method provided by this embodiment is implemented based on the Cassandra ring network topology, and each host node in the Cassandra ring network topology may include multiple containers, thereby effectively improving resource utilization; At the same time, the container load information can be shared between the host nodes. Therefore, it effectively overcomes the problem that the container shared database cluster in the prior art is relatively centralized, which easily causes the service request to be slow or downtime. The practicality of the management method is conducive to the promotion and application of the market.

FIG. 3 is a schematic flowchart of a Cassandra component module sending container load request information to a container management module according to an embodiment of the present invention. On the basis of the foregoing embodiment, it can be seen with continued reference to FIG. 3 that the host node in this embodiment also includes Including a protocol analysis module, the protocol analysis module is used for docking the preset operation protocol (Gossip operation protocol) and the analysis and operation between the container operation instructions, etc.; further, in this embodiment, the Cassandra component module to the container management module The specific implementation process for sending the container load request information is not limited, and those skilled in the art can adopt different implementation methods according to specific design requirements. For example, the Cassandra component module can directly use a wired or wireless communication channel to send a container load request to the container management module. information; preferably, the container load request information sent by the Cassandra component module to the container management module may include:

S1011: The Cassandra component module sends a protocol method call request to the protocol parsing module;

Among them, the protocol method call request is used to call the protocol method corresponding to the Cassandra component module. Commonly, the protocol method is the gossip operation protocol. The Cassandra component modules between the host nodes realize mutual coordination and communication through the gossip operation protocol. It can effectively guarantee the quality and efficiency of communication.

S1012: The protocol analysis module determines the called protocol method according to the protocol method calling request, and sends the determined called protocol method to the Cassandra component module;

After the protocol parsing module receives the protocol method invocation request, it can search for the protocol method to be invoked among the preset multiple protocol methods according to the protocol method invocation request, wherein the protocol method invocation request may include the protocol to be invoked The identification information of the method is used to determine the protocol method to be called among the plurality of protocol methods according to the identification information, and further determines the protocol method to be sent to the Cassandra component module.

S1013: The Cassandra component module sends the container load request information to the container management module by using the determined calling protocol method.

After the Cassandra component module obtains the called protocol method, the protocol method can be used to send the container load request information to the container management module, thereby effectively ensuring the reliability of the container load request information sending and further improving the stability of the management method. reliability.

4 is a schematic flowchart of another distributed container management method based on Cassandra ring network topology provided by an embodiment of the present invention; FIG. 5 is a process by which a target host node according to an embodiment of the present invention creates a corresponding container according to container data information Schematic diagram; on the basis of the above-mentioned embodiment, it can be seen that with reference to the accompanying drawings 4-5, the host node in this embodiment may further include a data storage module, and the data storage module is used to perform operation data on the host node. storage to facilitate the retrieval and viewing of operating data; in order to further improve the practicability of the management method, the method is set to further include:

S201: The log monitoring module monitors the running status of the container in the host node according to the log monitoring information, and if there is an abnormal running condition of the container in the host node, it sends abnormal prompt information to the Cassandra component module;

The log monitoring module in the host node can collect the log monitoring information generated by the container running in the host node in real time. After the log monitoring information, the log monitoring module can analyze and process the log monitoring information, so as to realize the function of monitoring the running status of the container in the host node; when analyzing and processing the log monitoring information, the log monitoring information can be compared with the pre-processing information. The set standard information is analyzed and compared. When the log monitoring information does not meet the standard information, it can be determined that the container in the host node is running abnormally; when the log monitoring information is consistent with the standard information, it can be determined that the host node is running. The containers are running normally; among them, the host node includes multiple containers, and each container runs independently. Therefore, one or several containers may run abnormally in the host node, while other containers are running normally. ; When the log monitoring module finds that there is an abnormal container operation in the host node, in order to ensure the processing quality and efficiency of the service request of the host node, it sends the exception prompt information to the Cassandra component module, wherein the abnormal prompt information can include the operation The abnormal container identification and/or the degree of abnormal operation information, etc.

S202: The Cassandra component module judges whether to migrate the abnormally running container in the host node to the preset target host node according to the abnormal prompt information; if the container needs to be migrated to the target host node, send a message to the data storage module data request information;

After the Cassandra component module obtains the abnormal prompt information, it can analyze and judge the abnormal prompt information. Specifically, it can judge whether it is necessary to migrate the abnormally running container in the host node to the preset target host node, for example: when After analyzing and judging the abnormal prompt information, it is determined that the abnormality of the container running abnormally in the host node is relatively light, and the container can also process the corresponding service request. At this time, it can be determined that the abnormal container running in the host node is not abnormal. It needs to be migrated to the target host node; after analyzing and judging the abnormal prompt information, it is determined that the abnormality of the container running abnormally in the host node is more serious, that is, the container cannot process the corresponding business request. It is determined that the abnormally running container in the host node needs to be migrated to the target host node, where the target host node is preset, which can be any other host node except the host node; After migrating the container to the target host node, the Cassandra component module can send data request information to the data storage module, where the data request information is used to obtain container data information corresponding to the abnormal container running on the host node.

S203: The data storage module queries the container data information corresponding to the container according to the data request information, and sends the container data information to the Cassandra component module;

The data request information may include container identification information. After the data storage module receives the data request information, it can query the container data information corresponding to the container according to the above container identification information, and query the container data corresponding to the abnormal running container. After the information, the container data information can be sent to the Cassandra component module, so that the Cassandra component module can forward the container data information to the target host node.

S204: The Cassandra component module sends the container data information to the target host node, so that the target host node creates a corresponding container according to the container data information.

After the Cassandra component module obtains the container data information, in order to facilitate the migration of the abnormally running container to the target host node, the container data information needs to be sent to the target host node, and the container data information is received on the target host node. After that, a corresponding container can be created according to the container data information. Specifically, the target host node creating a corresponding container according to the container data information can include:

S2041: The target Cassandra component module in the target host node receives the container data information, and sends the container data information to the target container management module in the target host node;

After the Cassandra component module sends the container data information to the target host node, the target host node includes the target Cassandra component module, the target container management module, and the target data storage module, etc. The target Cassandra component module can receive the container data information. , after receiving the container data information, the container data information can be sent to the target container management module, so that the target container management module can create a corresponding container according to the container data information.

S2042: The target container management module creates the container according to the container data information, and sends the creation result to the target Cassandra component module;

After the target container management module receives the container data information, it can create a corresponding container according to the container data information, and after the container is created, it can send the creation result to the target Cassandra component module, so that the target Cassandra component module can learn about it in time The creation and operation of the container.

S2043: The target Cassandra component module sends the container data information to the target data storage module in the target host node for storage according to the creation result; and sends the creation result to the Cassandra component module.

When it is determined that the container is created, the target Cassandra component module can send the container data information to the target data storage module in the target host node for storage, so as to facilitate later retrieval and viewing of the container data information.

In this embodiment, the log monitoring module is used to monitor the running status of the container in the host node. When there is an abnormal operation of the container in the host node, the abnormal running container is migrated to the target host node through the Cassandra component module. Specifically, the target host node can obtain the container data information corresponding to the abnormal running container sent by the Cassandra component module, and can create a corresponding container according to the container data information, thereby realizing the process of container migration and ensuring the container The timely reliability of business request processing further improves the stability and reliability of the management method.

FIG. 6 is a schematic flowchart of another distributed container management method based on the Cassandra ring network topology provided by an embodiment of the present invention. On the basis of the above embodiment, referring to FIG. Stable reliability, after sending the creation result to the Cassandra component module, set the method to also include:

S301: The Cassandra component module sends a container removal request to the container management module;

After the abnormally running container is successfully migrated to the target host node, in order to ensure the work quality and efficiency of the original host node, the Cassandra component module can send a container removal request to the container management module. The container removal request includes the identifier of the abnormally running container. The information is used to delete the abnormally running container on the host node, so as to ensure the memory space of the host node and improve the quality and efficiency of the service request processing by the host node.

S302: The container management module clears the abnormally running container in the host node according to the container clearing request, and sends the clearing result to the Cassandra component module.

After the container management module receives the container removal request, it can find the corresponding container data according to the container identification information included in the container removal request. The container data is the data information corresponding to the abnormally running container. Clear, and notify the Cassandra component module of the clearing result, so that the Cassandra component module can obtain the status information of the container in the host node.

After the abnormally running container is successfully migrated to the target host node, a container removal request is sent to the container management module through the Cassandra component module, and the container management module can delete the abnormally running container according to the container removal request, thus effectively ensuring the host The memory space of the node improves the quality and efficiency of the service request processing by the host node.

In specific applications, on each host node, the internal container management and external network coordination management are mainly based on Cassandra technology, so as to realize the coordination of the entire container cluster. The architecture of the host node is shown in Figure 7. , the host node is mainly based on the Cassandra component module to realize the communication between each node and the management of the container on the node, etc. The nodes realize the mutual coordination and communication between the nodes through the Gossip communication protocol between the Cassandra component modules mechanism. The host node mainly includes: Cassandra component module, protocol analysis module, container management module, data storage module, log monitoring module, etc. Among them, the protocol analysis module, container management module, data storage module, and log monitoring module all communicate with the Cassandra component module connect;

Cassandra component module: used to complete the internal management and data coordination and unified management of nodes;

Container network: responsible for the network protocol between the container and the host node; network routing: responsible for the external network routing and communication of the node; Cassandra data: responsible for the data of the entire node and the data backup of the entire container cluster, etc., its backup and read-write mechanism It is mainly implemented based on the related mechanism of Cassndra technology;

Protocol parsing module: used to connect the Gossip operation protocol and the parsing and operation between the container operation instructions, etc.;

Container management module: mainly responsible for the management of containers created on the host node;

Data storage module: mainly responsible for the storage of part of the container management data;

The log monitoring module is mainly responsible for collecting and monitoring logs during container operation and operation;

In addition, the host node may also include a health check module: the health check module is mainly responsible for checking the container status, etc.

In addition, referring to FIG. 2 , it can be known that the network between the host nodes adopts the Cassandra component module, and uses the point-to-point gossip information exchange protocol to realize. Through the point-to-point gossip protocol, the information of the nodes and the information coordinated between the containers are coordinated. Among them, the Gossip protocol realizes the consistency of information between nodes, so that the status of each node is exactly the same, and there is no CITIC node. Each node in gossip communication maintains a set of states, which are used to keep the state of the node consistent with the information of other nodes.

Based on the communication mechanism of Gossip, the communication state between the host nodes is mainly stored in Cassandra data, and the upper-layer data information is stored through data storage and log monitoring. According to the information of the host node and the state of the host container, etc.

Among them, the management method provided in this embodiment can realize the synchronization of the load information mechanism between nodes based on the mechanism of the running load of the host node, so as to migrate the container with excessive node load to the host node with less load. Specifically, Through the load information synchronization mechanism of the gossip protocol in the Cassandra technology, the load information sharing between the host nodes is realized. The specific interaction process is shown in Figure 8, including:

Step 1: The Cassandra component module needs to call the container state of the node before calling the gossip protocol method to send its own container load information to other nodes, and translate it into an internal calling method through protocol analysis;

Step 2: The protocol parsing module receives the protocol call and performs internal processing and method call;

Step 3: Obtain relevant information from the container management module through a method call;

Step 4: The container management module receives the method call, and queries the internal container resource operation status and other information;

Step 5: The container management module sends other information query requests to the log monitoring module;

Step 6: The log monitoring module retrieves relevant information for processing according to the query request sent by the container management module;

Step 7: The log monitoring module feeds back relevant information to the container management;

Step 8: The container management module integrates the information fed back by the log monitoring module and its own information;

Step 9: The container management module feeds back the container information to the protocol analysis module;

Step 10: The protocol parsing module is organized into gossip protocol interface information;

Step 11: The protocol parsing module feeds back the gossip protocol information to the Cassandra component module.

According to the above load information synchronization mechanism, the load synchronization mechanism in the gossip protocol in the Cassandra technology in the entire host node cluster not only realizes the load information synchronization of the original Cassandra cluster nodes, but also backs up the load host nodes. The above container load operation is synchronized, so that the subsequent container operation and destruction, container migration and registration, etc. are all implemented without master load balancing distribution mode, thus ensuring the stable operation of the container and the balanced distribution of resources. , which further improves the stability and reliability of the management method.

In addition, according to the above-mentioned container load communication mechanism, when there is a shortage of resources on a host node or the host node itself hangs, it is necessary to migrate the container on the node to other nodes. The migration information mechanism needs to ensure the above two aspects of the migration mechanism and message synchronization in order to be able to migrate smoothly and to be able to access containers on other nodes after the migration.

For the container migration resource request mechanism, as above, when the resources of a host node are insufficient and the container needs to be migrated to other nodes, it is necessary to send resource requests to other nodes, and check the nodes with sufficient resources in other nodes. An optimal solution can be obtained according to the network routing path and the number of idle resources, which can be used as the basis for the container to migrate to this node. This node is the target host node. The optimal solution algorithm of the target host node is as follows :

The parameters of (Formula 1-1) are described as follows:

i: Represents the number of host nodes, and represents the value of all other cluster nodes except its own node; C: Represents the computing resources of the host node itself; M: Represents the memory resources of the host node itself; T: Indicates the routing time from this node to a host node; other parameters represent adjustment parameters or weighted values.

In this optimal solution algorithm, the host node with the maximum value is considered to be the node with the best container migration, that is, the target host node, and the container is migrated to the target host node to be pulled up. The implementation process is shown in Figure 9: Migrating a container from a container in one host node to another target host node, the general process is as follows:

Step 1: The log monitoring module finds that there is abnormal resource preemption in the container operation, and reports to the Cassandra component module;

Step 2: The Cassandra component module makes a decision based on the abnormal situation submitted by the log monitoring module and decides to migrate the specified container to the target host node (or other nodes), and starts to retrieve relevant information from the data storage module;

Step 3: The data storage module feeds back the parameters and information of the specified container to the Cassandra component module according to the request of the Cassandra component module;

Step 4: The Cassandra component module sends the request in the early stage of the request container to the target host node, and the algorithm for its selection decision refers to the above formula 1-1;

Step 5: The target Cassandra component module of the target host node sends the parameters of the migration container to the target container management module;

Step 6: The target container management module creates the container according to the sent container parameters, and feeds back the creation result to the target Cassandra component module;

Step 7: The target Cassandra component module saves the container parameters and data in the target data storage module according to the created result;

Step 8: The target data storage module feeds back the saved result to the target Cassandra component module;

Step 9: The target host node feeds back the created result to the original host node;

Step 10: The original host node starts to eliminate the container according to the result created by the target node;

Step 11: The container management module feeds back the operation result of eliminating the container to the Cassandra component module;

Step 12: The original host node clears the data and broadcasts the migration message in the cluster through Gossip;

Step 13: After the target host node completes the data migration, it broadcasts the effective message in the cluster through Gossip.

Through the above-mentioned entire migration mechanism, a complete container migration process is realized. Therefore, when other containers in the data cluster composed of containers are accessing data, they can know in time that data access is performed on the target host node.

Further, the management method may further include a container migration broadcast mechanism, and the container migration broadcast mechanism needs to broadcast a message in the entire cluster after the container migration operation is completed, informing all nodes in the cluster that the original container is migrated to the target host node. Above, when a related container or data service needs to access the container, the location of the specified target host node can be accessed through the Cassandra cluster network. According to the above migration mechanism process, after the container migration is completed, the original host node needs to broadcast to declare that the container has been migrated, and at the same time broadcast to the target host node to declare that the specified container has been created successfully, so that all nodes in the cluster complete the container information. renew.

In addition, the Cassandra-based container masterless cluster management method provided by this application mainly adopts the Gossip protocol to realize real-time synchronization of node status in the absence of a master node, which mainly includes: node startup, node normal operation, Leaving (ready to exit) ) and status such as node exit.

(1) For the node startup mechanism, when the host node newly connected to the cluster starts up, it broadcasts in the cluster network through the Gossip communication protocol to notify all other nodes on the cluster that a new node has joined the cluster. , to register information for subsequent resource sharing and container migration.

(2) For the normal operation mechanism, in order to ensure the normal operation of the nodes, a long-term health check communication mechanism needs to be established between the cluster nodes. Real-time synchronization of the normal operation information of the status of each node is realized by heartbeat mode.

(3) For the Leaving mechanism, there is a pre-preparation stage for the cluster nodes that are planned to be taken off the shelf. By informing that the node will be removed from the cluster, and the host container on the node needs to be migrated to other nodes in advance. The mechanism of container migration is implemented by the migration mechanism.

(4) For the exit mechanism, when the Leaving mechanism in the pre-preparation phase is completed and the container on the host node is migrated to other nodes, all other nodes in the broadcast cluster notify the node that the preparation for de-listing has been completed. Then other nodes clear the information of the node in the data information maintained by themselves, and complete the delisting process of the node.

In addition to the state mechanism of the above cluster nodes, it also maintains the synchronization of container state information. The process, such as the node state mechanism, is different from the node state mechanism in that the specific state information of the container is maintained on the host node, and other nodes save the registration information.

In addition, the management method can also use the preset container backup mechanism to perform container backup on the node cluster. The container disaster recovery backup mechanism (container backup mechanism) is implemented according to the disaster recovery backup mechanism of the Cassandra-based host node, According to Cassandra's copy backup mechanism, the nodes for data disaster recovery backup are mainly selected through virtual nodes and Hash rings. Generally, one node selects two nodes as nodes for data backup and container backup, thus forming a 1:2 security processing mechanism to accomplish.

In terms of container and data access, it is implemented in the form of tokens. That is, when accessing a specified container or data, it can be accessed on a random node. In order to avoid access conflicts, uniqueness is confirmed by means of tokens, thereby avoiding resource conflicts. In addition, different nodes can be selected as backup nodes on different nodes. The own node can also be implemented as a backup node for other nodes.

FIG. 10 is a schematic structural diagram of a distributed container management system based on a Cassandra ring network topology provided by an embodiment of the present invention. Referring to FIG. 10 , this embodiment provides a distributed container management system based on a Cassandra ring network topology The system, the Cassandra ring network topology includes multiple nodes, each node corresponds to a host node, and the host node includes multiple containers; the system includes:

Cassandra component module 1 is used to send container load request information to container management module 2;

The container management module 2 is used to obtain the container resource information stored by itself according to the container load request information, and send log request information to the log monitoring module 3 according to the container load request information;

The log monitoring module 3 is used to obtain the log monitoring information according to the log request information, and send the log monitoring information to the container management module 2;

The container management module 2 is also used to receive log monitoring information, integrate the container resource information and the log monitoring information, obtain the container load information, and send the container load information to the Cassandra component module 1;

The Cassandra component module 1 is also used to receive container load information, and send the container load information to other host nodes, so as to realize the sharing of container load information among the host nodes.

The specific shapes and structures of the Cassandra component module 1, the container management module 2, and the log monitoring module 3 are not limited, and those skilled in the art can arbitrarily set them according to their functions; in addition, in this embodiment, the Cassandra component module 1. The specific implementation process and implementation effect of the operation steps implemented by the container management module 2 and the log monitoring module 3 are the same as the implementation process and implementation effect of steps S101-S105 in the above-mentioned embodiment. Repeat.

The distributed container management system provided by this embodiment is implemented based on the Cassandra ring network topology, and each host node in the Cassandra ring network topology may include multiple containers, thereby effectively improving resource utilization; At the same time, the use of Cassandra component module 1 can realize the sharing of container load information between host nodes. Therefore, it effectively overcomes the centralized location of container sharing database clusters in the prior art, which easily causes service requests to be slow or downtime. The defect ensures the practicability of the management system and is beneficial to the promotion and application of the market.

On the basis of the above-mentioned embodiment, and continuing to refer to FIG. 10, the system may further include: a protocol parsing module 4; and, in this embodiment, the specific implementation process of the Cassandra component module 1 sending the container load request information to the container management module Without limitation, the more preferred:

The Cassandra component module 1 is also used to send a protocol method invocation request to the protocol parsing module 4;

Protocol parsing module 4, for determining the called protocol method according to the protocol method calling request, and sending the determined calling protocol method to the Cassandra component module 1;

The Cassandra component module 1 is further configured to send container load request information to the container management module 2 by using the determined calling protocol method.

The specific shape and structure of the protocol analysis module 4 is not limited, and those skilled in the art can arbitrarily set it according to the functions it realizes; in addition, the operation steps implemented by the Cassandra component module 1 and the protocol analysis module 4 in this embodiment The specific implementation process and implementation effect are the same as the implementation process and implementation effect of steps S1011-S1013 in the above-mentioned embodiment. For details, please refer to the above-mentioned statement content, which will not be repeated here.

After the Cassandra component module 1 obtains the called protocol method, the protocol method can be used to send the container load request information to the container management module, thereby effectively ensuring the reliability of the sending of the container load request information, and further improving the use of the management system. Stable reliability.

Further, as shown in FIG. 10, the system may further include: a data storage module 5; in order to further improve the practicability of the management system, the log monitoring module 3 is also used to monitor the containers in the host node according to the log monitoring information If there is an abnormal operation of the container in the host node, it will send abnormal notification information to Cassandra component module 1;

The Cassandra component module 1 is also used to judge whether to migrate the abnormally running container in the host node to the preset target host node according to the abnormal prompt information; if the container needs to be migrated to the target host node, the data The storage module 5 sends data request information;

The data storage module 5 is also used to query the container data information corresponding to the container according to the data request information, and send the container data information to the Cassandra component module 1;

The Cassandra component module 1 is further configured to send the container data information to the target host node, so that the target host node creates a corresponding container according to the container data information.

Specifically, after the Cassandra component module 1 obtains the container data information, in order to facilitate the migration of the abnormally running container to the target host node, the container data information needs to be sent to the target host node, and received on the target host node. After the container data information is obtained, a corresponding container can be created according to the container data information. Specifically, the target host node may include: a target Cassandra component module, a target container management module, and a target data storage module, so that the target Cassandra component module, using It is used to receive container data information and send the container data information to the target container management module; the target container management module is used to create the container according to the container data information, and send the creation result to the target Cassandra component module; the target Cassandra component module, It is also used to send the container data information to the target data storage module for storage according to the creation result; and send the creation result to the Cassandra component module.

The specific implementation process and implementation effect of the operation steps implemented by the Cassandra component module 1, the container management module 2, the log monitoring module 3, and the data storage module 5 in this embodiment are the same as the implementation processes of steps S201-S204 and S2041-S2043 in the above embodiment And the implementation effect is the same, for details, reference can be made to the above statement, which will not be repeated here.

In this embodiment, the log monitoring module 3 monitors the running status of the container in the host node. When there is an abnormal operation of the container in the host node, the Cassandra component module 1 migrates the abnormally running container to the target host node. Specifically, the target host node can obtain the container data information corresponding to the abnormal running container sent by the Cassandra component module 1, and can create a corresponding container according to the container data information, thereby realizing the process of container migration, thereby This ensures the timely reliability of the processing of business requests by the container, and further improves the stability and reliability of the management system.

On the basis of the above-mentioned embodiment, and continuing to refer to FIG. 10, in order to further improve the stability and reliability of the management system, the Cassandra component module 1 is also used to send the creation result to the Cassandra component module 1 to send the The management module 2 sends a container removal request;

The container management module 2 is used for clearing the abnormally running containers in the host node according to the container clearing request, and sending the clearing result to the Cassandra component module 1 .

The specific implementation process and implementation effect of the operation steps implemented by the Cassandra component module 1 and the container management module 2 in this embodiment are the same as the implementation process and implementation effect of steps S301-S302 in the above-mentioned embodiment. No longer.

After the abnormally running container is successfully migrated to the target host node, a container removal request is sent to the container management module 2 through the Cassandra component module 1, and the container management module 2 can delete the abnormally running container according to the container removal request, thereby effectively guaranteeing The memory space of the host node is increased, and the quality and efficiency of the host node's processing of business requests are improved.

In the several embodiments provided by the present invention, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, for example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.

Units described as separate components may or may not be physically separated, and components shown as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware, or may be implemented in the form of hardware plus software functional units.

The above-mentioned integrated units implemented in the form of software functional units can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to execute some steps of the methods in the various embodiments of the present invention. . The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program codes.

Those skilled in the art can clearly understand that, for the convenience and brevity of the description, only the division of the above functional modules is used for illustration. The internal structure is divided into different functional modules to complete all or part of the functions described above. For the specific working process of the apparatus described above, reference may be made to the corresponding process in the foregoing method embodiments, and details are not described herein again.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions described in the foregoing embodiments can still be modified, or some or all of the technical features thereof can be equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present invention. scope.

Claims (10)

1. A distributed container management method based on a Cassandra ring network topology is characterized in that the Cassandra ring network topology comprises a plurality of nodes, each node is correspondingly provided with a host node, and the host node comprises a plurality of containers; the host node further comprises a Cassandra component module, a container management module and a log monitoring module, and the method comprises the following steps:

the Cassandra component module sends container load request information to the container management module;

the container management module acquires container resource information stored by the container management module according to the container load request information and sends log request information to the log monitoring module according to the container load request information;

the log monitoring module acquires log monitoring information according to the log request information and sends the log monitoring information to the container management module;

the container management module receives the log monitoring information, performs fusion processing on the container resource information and the log monitoring information to obtain container load information, and sends the container load information to the Cassandra component module, wherein the container load information is data information which needs to be shared among all host nodes;

and the Cassandra component module receives the container load information and sends the container load information to other host nodes so as to realize the sharing of the container load information among the host nodes.

2. The method of claim 1, wherein the host node further comprises a protocol parsing module, and wherein the Cassandra component module sends container load request information to the container management module, comprising:

the Cassandra component module sends a protocol method calling request to the protocol analysis module;

the protocol analysis module determines the called protocol method according to the protocol method calling request and sends the determined called protocol method to the Cassandra component module;

the Cassandra component module sends container load request information to the container management module using the determined invoked protocol method.

3. The method according to claim 1 or 2, wherein the host node further comprises a data storage module, the method further comprising:

the log monitoring module monitors the operation condition of a container in the host node according to the log monitoring information, and if the container operation abnormal condition exists in the host node, the log monitoring module sends abnormal prompt information to the Cassandra component module;

the Cassandra component module judges whether a container with abnormal operation in the host node is migrated to a preset target host node or not according to the abnormal prompt information; if the container needs to be migrated to the target host node, sending data request information to the data storage module;

the data storage module inquires container data information corresponding to the container according to the data request information and sends the container data information to the Cassandra component module;

and the Cassandra component module sends the container data information to the target host node, so that the target host node creates a corresponding container according to the container data information.

4. The method of claim 3, wherein the target host node creates a corresponding container according to the container data information, comprising:

a target Cassandra component module in the target host node receives the container data information and sends the container data information to a target container management module in the target host node;

the target container management module creates a container according to the container data information and sends a creation result to the target Cassandra component module;

the target Cassandra component module sends the container data information to a target data storage module in a target host node for storage according to a creation result; and sending the creation result to the Cassandra component module.

5. The method of claim 4, wherein after sending the created result to the Cassandra component module, the method further comprises:

the Cassandra component module sending a container clear request to the container management module;

and the container management module clears the container which runs abnormally in the host node according to the container clearing request and sends a clearing result to the Cassandra component module.

6. A distributed container management system based on a Cassandra ring network topology is characterized in that the Cassandra ring network topology comprises a plurality of nodes, each node is correspondingly provided with a host node, and the host node comprises a plurality of containers; the system comprises:

the Cassandra component module is used for sending container load request information to the container management module;

the container management module is used for acquiring self-stored container resource information according to the container load request information and sending log request information to the log monitoring module according to the container load request information;

the log monitoring module is used for acquiring log monitoring information according to the log request information and sending the log monitoring information to the container management module;

the container management module is further configured to receive the log monitoring information, perform fusion processing on the container resource information and the log monitoring information, acquire container load information, and send the container load information to the Cassandra component module, where the container load information is data information that needs to be shared among all host nodes;

the Cassandra component module is further configured to receive the container load information and send the container load information to other host nodes, so as to implement sharing of the container load information between the host nodes.

7. The system of claim 6, further comprising: a protocol analysis module;

the Cassandra component module is also used for sending a protocol method calling request to the protocol analysis module;

the protocol analysis module is used for determining the called protocol method according to the protocol method calling request and sending the determined called protocol method to the Cassandra component module;

the Cassandra component module is further configured to send container load request information to the container management module using the determined invoked protocol method.

8. The system according to claim 6 or 7, characterized in that it further comprises: a data storage module;

the log monitoring module is further configured to monitor an operation condition of a container in the host node according to the log monitoring information, and send an abnormal prompt message to the Cassandra component module if the abnormal operation condition of the container exists in the host node;

the Cassandra component module is further used for judging whether to migrate a container with abnormal operation in the host node to a preset target host node according to the abnormal prompt information; if the container needs to be migrated to the target host node, sending data request information to the data storage module;

the data storage module is further configured to query container data information corresponding to the container according to the data request information, and send the container data information to the Cassandra component module;

the Cassandra component module is further configured to send the container data information to the target host node, so that the target host node creates a corresponding container according to the container data information.

9. The system of claim 8, wherein the target host node comprises: the system comprises a target Cassandra component module, a target container management module and a target data storage module;

the target Cassandra component module is used for receiving the container data information and sending the container data information to the target container management module;

the target container management module is used for creating a container according to the container data information and sending a creation result to the target Cassandra component module;

the target Cassandra component module is also used for sending the container data information to the target data storage module for storage according to a creation result; and sending the creation result to the Cassandra component module.

10. The system of claim 9,

the Cassandra component module is further used for sending a container clearing request to the container management module after sending a creating result to the Cassandra component module;

and the container management module is used for clearing the container which runs abnormally in the host node according to the container clearing request and sending a clearing result to the Cassandra component module.

Images