CN115878269A

CN115878269A - Cluster migration method, related device and storage medium

Info

Publication number: CN115878269A
Application number: CN202211739454.1A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Beijing Real AI Technology Co Ltd
Current assignee: Beijing Real AI Technology Co Ltd
Priority date: 2022-12-31
Filing date: 2022-12-31
Publication date: 2023-03-31

Abstract

The embodiment of the application relates to the field of cloud service, and provides a cluster migration method, a related device and a storage medium, wherein the cluster migration method is applied to a migration control node in a cluster migration system, the cluster migration system further comprises a source cluster and a target container environment which are separately deployed, the target container environment comprises a plurality of first nodes, the source cluster comprises a plurality of second nodes, and the first nodes and the second nodes are the same in number; the method comprises the following steps: adding each first node into the source cluster to obtain a transition cluster; the transition cluster comprises all first nodes and all second nodes; in the transition cluster, migrating all partitioned data in each second node to each first node respectively; the first nodes correspond to the second nodes one by one, and each second node stores a plurality of partition data; and updating the configuration information of all the nodes in the transitional cluster to obtain a target cluster, wherein the target cluster only comprises the first node.

Description

Cluster migration method, related device and storage medium

Technical Field

The embodiment of the application relates to the technical field of cloud services, in particular to a cluster migration method, a related device and a storage medium.

Background

The advent of container technology has made the delivery and deployment of applications and middleware more convenient and faster than traditional virtual machine or physical machine environment based delivery and deployment, and easier to integrate into container environment based Development and Operations (developers) ecology.

Kafka is a widely used high-throughput and high-reliability message middleware, and nowadays, with the popularization of the cloud native concept, more and more users deploy Kafka in a container environment. However, for the original service system in the enterprise, how to migrate the Kafka cluster from the virtual machine or physical machine environment to the container environment on the premise that the service is basically uninterrupted does not have a proper scheme.

Disclosure of Invention

Embodiments of the present application provide a cluster migration method, a related apparatus, and a storage medium, which can migrate a cluster service program from a virtual machine environment or a physical machine environment to a container environment on the premise of not interrupting a service.

In a first aspect, an embodiment of the present application provides a cluster migration method, which is applied to a migration control node in a cluster migration system, where the cluster migration system further includes a source cluster and a target container environment that are separately deployed, the target container environment includes a plurality of first nodes, the source cluster includes a plurality of second nodes, and the number of the first nodes is the same as that of the second nodes; the method comprises the following steps:

adding each first node into the source cluster to obtain a transition cluster; the transition cluster comprises all first nodes and all second nodes;

in the transition cluster, respectively migrating the data of all the partitions in each second node to each first node; the first nodes correspond to the second nodes one by one, and each second node stores a plurality of partition data;

and updating the configuration information of all the nodes in the transitional cluster to obtain a target cluster, wherein the target cluster only comprises the first node.

In a second aspect, an embodiment of the present application provides a control node, which is applied to a cluster migration system and has a function of implementing the cluster migration method provided in the first aspect. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above functions, which may be software and/or hardware.

In one embodiment, the node is applied to a cluster migration system, which further includes a source cluster and a target container environment separately deployed, where the target container environment includes a plurality of first nodes, the source cluster includes a plurality of second nodes, and the number of the first nodes is the same as that of the second nodes; the node comprises;

the receiving and sending module is configured to send an instruction of joining the source cluster to each first node to obtain a transition cluster; the transition cluster comprises all first nodes and all second nodes;

the processing module is configured to migrate the data of all the partitions in each second node to each first node in the transition cluster respectively; the first nodes correspond to the second nodes one by one, and each second node stores a plurality of partition data;

the processing module is further configured to update configuration information of all nodes in the transition cluster to obtain a target cluster, where the target cluster only includes the first node.

In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which includes instructions that, when executed on a computer, cause the computer to perform the cluster migration method according to the first aspect.

In a fourth aspect, an embodiment of the present application provides a computing device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor implements the cluster migration method according to the first aspect when executing the computer program.

Compared with the prior art, in the embodiment of the application, the migration control node adds the newly-built first node in the target container environment to the source cluster in the virtual machine or physical machine environment to obtain a complete transition cluster, then completes the migration of partition data in all second nodes of the source cluster to the first node in the transition cluster, and finally shuts down the source cluster. Because the data migration operation in the embodiment of the application is completed in the same cluster, rather than between different clusters in the prior art, cross-domain transmission of data is avoided, the transmission efficiency of the data is improved, and network resources and time are saved. In addition, in the embodiment of the application, the network configuration information of the new and old cluster nodes is updated through the migration control node, so that the conversion of the data transmission destination address after data migration is realized, which is equivalent to that the data transmission between a service party (a consumer and a producer) and a cluster is transferred through a fixed transfer station instead of the way of directly connecting the service party and the cluster in the prior art, so that the service party can be respectively connected with the old node or the new node through the transfer station before the cluster migration starts and after the cluster migration finishes, the possible jitter in the cluster migration process is avoided, the hot migration of the cluster is realized, and the condition of service interruption is avoided.

Drawings

Objects, features and advantages of embodiments of the present application will become apparent from the detailed description of embodiments of the present application with reference to the accompanying drawings. Wherein:

fig. 1 is a schematic diagram of a cluster migration system of a cluster migration method in an embodiment of the present application;

FIG. 2 is a schematic flowchart of a cluster migration method according to an embodiment of the present application;

fig. 3 is a schematic diagram of a node change process of cluster migration in the cluster migration method in the embodiment of the present application;

fig. 4 is a schematic flowchart illustrating a cluster migration method according to an embodiment of the present application, in which data of a second node is migrated to a first node;

fig. 5 is a schematic flowchart illustrating a cluster migration method for migrating data of a second partition to a first node according to an embodiment of the present application;

fig. 6 is a schematic diagram of a partition change process of data migration in the cluster migration method in the embodiment of the present application;

fig. 7 is a signaling interaction diagram of a cluster migration method in an embodiment of the present application;

fig. 8 is a schematic structural diagram of a control node in the embodiment of the present application;

FIG. 9 is a schematic structural diagram of a computing device in an embodiment of the present application;

fig. 10 is a schematic structural diagram of a server in an embodiment of the present application.

In the drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

Detailed Description

The terms "first," "second," and the like in the description and claims of the embodiments of the present application and in the drawings described above are used for distinguishing between similar elements (e.g., a first node and a second node are respectively referred to as different nodes, and the like), and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be implemented in other sequences than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to such process, method, article, or apparatus, and such that a division of modules presented in an embodiment of the present application is merely a logical division that may be implemented in an actual implementation in another embodiment, e.g., a combination of modules may be integrated or integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling between modules through some interfaces, and the communication connection may be an electrical connection or other similar forms, which are not limited in the embodiments of the present application. Moreover, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed in a plurality of circuit modules, and some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

The embodiment of the application provides a cluster migration method, a related device and a storage medium, which can be applied to a cluster migration system. The migration control node is at least used for adding each first node into the source cluster to obtain a transition cluster, and migrating all partition data in each second node to each first node in the transition cluster respectively. The source cluster is deployed in a virtual machine or physical machine environment and includes first nodes, each of which deploys a cluster service and data. The migration control node may be an application program that migrates all partition data in each second node to each first node, respectively, or a server that installs an application program that migrates all partition data in each second node to each first node, respectively.

The scheme of the embodiment of the application can be realized based on a cloud technology, and particularly relates to the technical fields of cloud computing, cloud storage, databases and the like in the cloud technology, which are respectively introduced as follows:

cloud technology refers to a hosting technology for unifying series of resources such as hardware, software, and network in a wide area network or a local area network to realize calculation, storage, processing, and sharing of data. The cloud technology (cloud technology) is based on a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied in a cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of technical network systems require a large amount of computing and storage resources, such as video websites, picture-like websites and more portal websites. With the high development and application of the internet industry, each article may have its own identification mark and needs to be transmitted to a background system for logic processing, data in different levels are processed separately, and various industrial data need strong system background support and can only be realized through cloud computing. According to the embodiment of the application, the target migration data can be stored through a cloud technology.

A distributed cloud storage system (hereinafter, referred to as a storage system) refers to a storage system that integrates a large number of storage devices (storage devices are also referred to as storage nodes) of different types in a network through application software or application interfaces to cooperatively work by using functions such as cluster application, grid technology, and a distributed storage file system, and provides a data storage function and a service access function to the outside. In the embodiment of the application, information such as network configuration and the like can be stored in the storage system, so that the server can conveniently retrieve the information.

At present, a storage method of a storage system is as follows: logical volumes are created, and when a logical volume is created, physical storage space, which may be the disk composition of a certain storage device or several storage devices, is allocated to each logical volume. The client stores data on a certain logical volume, that is, stores the data on a file system, the file system divides the data into a plurality of parts, each part is an object, the object includes not only the data but also additional information such as data identification (ID, ID entry), the file system writes each object into a physical storage space of the logical volume, and the file system records storage location information of each object, so that when the client requests to access the data, the file system can allow the client to access the data according to the storage location information of each object.

The process of allocating physical storage space for the logical volume by the storage system specifically includes: physical storage space is pre-partitioned into stripes according to a set of capacity measures of objects stored in the logical volumes (which often have a large margin with respect to the capacity of the actual objects to be stored) and Redundant Array of Independent Disks (RAID), and a logical volume can be understood as a stripe, thereby allocating physical storage space to the logical volume.

Database (Database), which can be regarded as an electronic file cabinet in short, a place for storing electronic files, a user can add, query, update, delete, etc. to data in files. A "database" is a collection of data that is stored together in a manner that can be shared by multiple users, has as little redundancy as possible, and is independent of the application.

Database Management System (English: database Management System, DBMS for short)

The computer software system designed for managing the database generally has basic functions of storage, interception, safety guarantee, 5 backup and the like. The database management system may be categorized according to the database models it supports

Classes, such as relational, XML (Extensible markup language); or classified according to the type of computer supported, e.g., server cluster, mobile phone; regardless of which classification is used, some DBMSs can be across classes, e.g., supporting multiple query languages simultaneously.

In the prior art, kafka cluster nodes are often connected with a service party (production party) through real network addresses

Customer node or consumer node), when the Kafka cluster needs to be migrated 5 from the original deployment environment to a new deployment environment (for example, from a physical machine environment to a container environment), because the real network address of the cluster node cannot be changed, the service to the service party is often interrupted in the migration process, so that the system shutdown of the service party is caused, and great inconvenience is brought to users; moreover, in the prior art, when cluster migration is performed, data of an old cluster is often migrated to a new cluster across domains, so that a data transmission flow is long, and more transmission resources are consumed.

Compared with the prior art, the embodiment of the application can be used for establishing the newly-established first section in the target container environment

And adding the point into the source cluster to obtain a transition cluster, then completing the migration of the partition data in all the second nodes of the source cluster to the first node in the transition cluster, and finally shutting down the source cluster. Because the data migration operation in the embodiment of the application is completed in the same cluster, not in the prior art

The data transmission is finished among different clusters, which is equivalent to avoiding the cross-domain transmission of the data, improving the transmission efficiency of the data by 5 percent, and saving network resources and time. In addition, the embodiment of the application is controlled by migration

The node updates the network configuration information of the new and old cluster nodes, realizes the conversion of the data transmission destination address after data migration, which is equivalent to transferring the data transmission between a service party (consumer and producer) and a cluster through a fixed transfer station instead of the way of directly connecting the service party and the cluster in the prior art, so that the service party can be respectively connected with the old node or the new node through the transfer station before the cluster migration starts and after the cluster migration finishes, thereby avoiding the possible jitter in the cluster migration process, realizing the hot migration of the cluster and avoiding the service interruption.

In some embodiments, the cluster migration method provided in the embodiments of the present application may be implemented based on a cluster migration system shown in fig. 1. The cluster migration system may include a migration control node 01, a first node 02, and a second node 03.

The migration control node 01 is configured to combine the first node 02 and the second node 03 to obtain a transition cluster, migrate partition data in the second node 03 to the first node 02 in the transition cluster, update configuration information of the first node 02 and the second node 03 in the transition cluster after the partition data is migrated, and shut down the second node 03 to obtain a target cluster including only the first node 02.

It should be noted that the server related to the embodiment of the present application may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, middleware service, a domain name service, a security service, a CDN, and a big data and artificial intelligence platform.

Referring to fig. 2, fig. 2 is a schematic flowchart of a cluster migration method in the embodiment of the present application. The method can be applied to a cluster migration system, is executed by a migration control node, and migrates a cluster service program from a source cluster (such as a virtual machine or a physical machine environment) to a target cluster (such as a container environment) on the premise of not interrupting the service. The cluster migration system also comprises a source cluster and a target container environment which are separately deployed, wherein the target container environment comprises a plurality of first nodes, the source cluster comprises a plurality of second nodes, and the number of the first nodes is the same as that of the second nodes; the cluster migration method comprises the following steps of 101-103:

and 101, adding each first node into the source cluster to obtain a transition cluster.

And the transition cluster comprises all the first nodes and all the second nodes. In the embodiment of the present application, the source cluster may be a physical server cluster or a virtual server cluster, in which a cluster service program may be deployed, and the cluster service program may provide service support for operation of a service system; message middleware, such as ActiveMQ, rabbitMQ, rocketMQ, and Kafka, coordinates data transfer efforts between data producers (e.g., servers) and data consumers (e.g., clients). In some application scenarios, it may be necessary to migrate the cluster service program in the source cluster to a new cluster for reasons such as improving the performance of the service program deployment environment, so that the cluster service program is deployed in a machine environment with higher performance.

When performing cluster migration, it is necessary to make explicit the destination of the migration work (e.g., the new node relative to the original node in the source cluster), i.e., where the cluster service and data are to be migrated. Therefore, in the embodiment of the present application, each first node (i.e., a node in a destination cluster) created in a target container environment may be obtained, where the first node may be used to receive part of data of a cluster service program in a source cluster; for example, a first node may host all the data of a second node in a source (Kafka) cluster (i.e., a brooker in Kafka). It can be understood that in the embodiment of the present application, all data of each second node in the source cluster may need to be migrated to a new node, and thus, a number of first nodes equal to the number of second nodes may be created in the target container environment, so as to be able to accept all data of the source cluster.

It should be noted that, in the embodiment of the present application, the target container environment may be established in advance by a third party (or a cluster maintenance party) before cluster migration is performed, or may be established by a migration control node, which is not limited in this embodiment of the present application. The target container environment may be a unit built using the Docker technology for providing runtime environment support for program services. In some optional embodiments, the migration control node may also create a target container environment and create a preset number of first nodes in the target container environment.

After specifying the source cluster and the destination (i.e., each first node) involved in the cluster migration, each first node and each second node may be placed into a cluster to obtain a transition cluster, so as to complete the data migration work in the transition cluster. Because the data migration operation in the embodiment of the application is completed in the same cluster, rather than between different clusters in the prior art, cross-domain transmission of data is avoided, the transmission efficiency of data is improved, and network resources and time are saved.

In this embodiment of the present application, for example, referring to fig. 3, a first node may be added to a source cluster to obtain a transition cluster; or each second node may be separated from the source cluster, and a transition cluster different from the source cluster is established with each first node, and those skilled in the art may perform the setting according to actual needs, which is not limited herein.

In some optional embodiments, adding each first node to the source cluster, and obtaining the transition cluster may be performed in a specific manner: and registering each first node in the control node of the source cluster, so that each first node can be controlled by the control node in the source cluster, and the transition cluster is obtained.

In consideration of the above, the control node in the source cluster is substantially selected from the second nodes (that is, obtained by pre-registering one second node), that is, the control node itself is also a certain node (for example, a physical server or a virtual server) in the source cluster, and belongs to an object that needs to be shut down after the cluster migration work is completed. Therefore, when the cluster migration work is performed to a certain degree, the control node needs to be replaced so as to maintain the normal operation of the new cluster (i.e., the target cluster) after the shutdown of the source cluster. Therefore, in the embodiment of the present application, one of the first nodes may be obtained as a candidate control node, so that the candidate control node takes over an original control node in the source cluster at a preset time, that is, the candidate cluster includes a master control node (i.e., the original control node in the source cluster) and a candidate control node (obtained based on one first node).

In the prior art, each Broker node in the Kafka cluster is co-registered with a Zookeeper node, and a temporary node is generated from each Broker node, that is, only one Broker node is successfully registered (becomes a master control node of a source cluster), and the registration behaviors of other nodes are failed. Therefore, the temporary node successfully registered in the Zookeeper node becomes a control node (Controller) of the Kafka cluster, which can register to listen to the Watch service in the Zookeeper node, i.e., the Controller can listen to all information of other Broker nodes. If the Broker node corresponding to the Controller crashes, the temporary node registered on the Zookeeper node disappears, and all Broker nodes go to the Zookeeper node to register together at the moment, because only one Broker node can register successfully and the others can fail, the Broker node which successfully registers as the temporary node on the Zookeeper node becomes a new Controller of the Kafka cluster.

Specifically, once the Broker node corresponding to the original Controller is down, the Broker node corresponding to the new Controller reads the states of all Partition partitions on the Zookeeper node on the down Broker node, and selects one copy replay in the Isr list as a main Partition Leader (if all the replays in the Isr list are unavailable, an available replay outside the Isr list is selected as a Partition Leader; if all the replays of the Partition are down, the new Partition Leader is set to-1, and waits for any replay in the Isr to be recovered and selects the replay as the Partition Leader; or selects the first recovered replay as the Partition Leader). In addition, the original Controller can inform the Zookeeper node of the information that the corresponding Broker node is down, and the Zookeeper node can inform other Broker nodes so as to register and select a new Controller.

Therefore, in the prior art, the source cluster elects a new master control node from each second node only when the master control node fails. In the embodiment of the present application, the cluster migration work needs to be performed on the premise of ensuring that the service is not interrupted, and when the cluster migration work is completed, each second node of the source cluster is actively shut down; therefore, in the embodiment of the present application, a problem that a control node is frequently replaced may occur by using a control node handover manner in the prior art, for example, after a historical master control node of a source cluster is shut down, a new master control node is still generated in a second node, so that the new control node still needs to be actively shut down, and then another round of master control node selection step is performed.

In order to realize the orderly handover of the master control node in the cluster migration work, the cluster migration is ensured not to influence the normal operation of a service system. In this embodiment of the present application, after each first node joins in the source cluster to obtain the transition cluster, a candidate control node is elected from each first node of the transition cluster (that is, the candidate control node is obtained by registering one first node), and the candidate control node may synchronize the configuration information in the master control node and take over the master control node when receiving a preset instruction. It can be understood that the generation manner of the candidate control node may be similar to that in the prior art, that is, the candidate control node may be obtained by registering each first node on the Zookeeper node; alternatively, the migration control node may randomly select from the first nodes, which is not limited herein.

It can be understood that, after the candidate control node in the embodiment of the present application is generated, the control information of the master control node, for example, the operation information of each node in the transition cluster, may be obtained in real time, so as to take over the master control node at any time. In some optional embodiments, if the master control node fails, the candidate control node may immediately take over the master control node to become a new master control node, and at the same time, a new candidate control node is generated (from each first node), so as to ensure that the control node is generated in each first node until each second node is shut down, and no additional workload is brought due to the shutdown of the second node of the source cluster.

In consideration of the above, during the handover of the new control node and the old control node, some control configuration information may not be completely migrated and an error may be generated due to different sources of the new control node (i.e., the candidate control node of the transition cluster) and the old control node (i.e., the master control node of the transition cluster), so that the new control node may not perform control correctly. In order to find the migration error in advance and avoid repeated operation caused by continuous error work after the migration error as much as possible, in some optional embodiments, the cluster migration progress may be monitored, and when the cluster migration progress is reached, the migration control node sends a preset instruction to the candidate control node, so that the candidate control node may actively take over the master control node to control each node in the transition cluster. Therefore, whether a new control node has a problem or not can be found in advance, and the new control node cannot provide services as the old control node, so that backtracking can be performed as early as possible when the problem occurs, and the availability of the migration system is improved.

In the above, a possible way of replacing the control node in the cluster migration work is introduced, and how to migrate the data in the second node to the first node is described in the following.

And 102, in the transitional cluster, migrating all the partition data in each second node to each first node respectively.

The first nodes correspond to the second nodes one by one, and each second node comprises a plurality of partition data.

In this embodiment, the source cluster may be a Kafka cluster, and each second node may be a Broker node, so that each second node may include a plurality of topics Topic therein, and each Topic may include a plurality of Partition partitions. It is contemplated that in order to completely migrate the data of each second node into the new node, a predetermined number of first nodes are created in the target container environment in step 101. Therefore, the first nodes can correspond to the second nodes one to one, so that each second node has a corresponding data migration destination node (namely, the first node), and the data migration work is ensured to be performed orderly.

When data in a second node needs to be migrated to a corresponding first node, in order to ensure that the operation of a service system is not interrupted, that is, the second node can continuously provide data support services, different data migration strategies can be adopted according to the data active state in the second node; for example, for active data, its copy may be migrated, avoiding data occupation from affecting normal service operation. Referring to fig. 4, migrating all data in a second node to a first node corresponding to the second node may include steps 201-202:

step 201, according to the historical consumption records of each consumer node, a first partition and a second partition are obtained from all partitions of the second node.

The historical consumption times of the first partition are not more than a preset value, and the historical consumption times of the second partition are more than the preset value.

In the embodiment of the present application, in order to determine the active state of the data to be migrated, a characteristic that data of each partition can only be consumed by one consumer node in a Kafka cluster may be utilized, and by counting historical consumption records of the consumer nodes, an active data partition and an inactive data partition are obtained.

Specifically, when data of a second node needs to be migrated, historical consumption records of all consumer nodes can be obtained, then recorded data of the second node is analyzed, and the number of times each partition in the second node is consumed is determined; if the number of times a partition is consumed is not greater than the preset value (e.g., 10), it may be considered that the data of the partition is accessed infrequently and is inactive, i.e., it may be determined as a first partition (inactive partition); similarly, if the number of times a partition is consumed is greater than the preset value, it may be considered that the data of the partition is frequently accessed, and it is active, i.e., it may be determined as a second partition (active partition).

It can be understood that, in order to ensure that the data activity state determined according to the historical consumption record is fitted with the current situation (namely the situation during data migration), the active data and the inactive data during data migration can be accurately distinguished. In some optional embodiments, the consumption record in a history period closest to the current time may be obtained as the history consumption record, for example, the consumption record of the consumer node in 7 days before the data migration may be obtained as the history consumption record.

Step 202, migrating the data of each first partition to the first node according to a first migration strategy; and migrating the data of each second partition to the first node according to a second migration strategy.

In the embodiment of the present application, after determining the active state of each partition in the second node to be migrated, data in each partition may be migrated to the first node corresponding to the second node according to a preset migration policy. Specifically, for an inactive first partition, a first migration policy may be adopted to indiscriminately migrate data therein to a corresponding first node; for the active second partition, a second migration policy may be adopted to differentially migrate data therein to the corresponding first node.

It should be noted that, even in the inactive first partition, the state in which the data is consumed is not completely consistent. Specifically, in the Kafka cluster, each Broker node includes a plurality of partitions, which do not include only one data but a data sequence of the same subject, and the chronologically succeeding data generated by the producer node may be additionally stored in the form of a queue following the preceding data to form the data sequence.

For example, in a Kafka cluster, each partition may exist in the form of a folder, and multiple sets of segment files may be included in each partition folder, each set of segment files containing an index, a log file, and a timeindex file, where the log file is the location where the message is actually stored and the index and timeindex files are index files for retrieving the message. After receiving a message generated by a producer node, the message is written into segments sequentially, and only the last segment can perform the write operation.

It can be seen that a partition includes multiple data (i.e. segment files), and the number of times that the multiple data in the partition are consumed by consumers is not exactly the same, i.e. each data has a difference of liveness. However, although the respective data in the first partition has different activity, but is generally not frequently consumed, the data may be attributed to inactive data, and thus, the data of the first partition may be completely and indiscriminately migrated into the first partition using the unified first migration policy.

In step 101, mention is made of: in cluster migration, not only data stored on each second node in the source cluster needs to be migrated, but also a control node in the source cluster needs to be changed, that is, a master control node obtained based on the second node is replaced by a candidate control node obtained from the first node.

Considering that each first partition is an inactive partition, the first partition can be directly and integrally migrated to the corresponding first node, instead of the migration operation of the second partition needing to distinguish different data and respectively adopt different modes for processing; that is, the data migration speed of the first partition may be faster and may be completed earlier, and if the first partition in each second node completes migration and the candidate control node replaces the master control node, problems that may occur during cluster migration may be discovered as early as possible and backtrack in time.

Therefore, in some optional embodiments, migration schedules of all first partitions of each second node may be obtained (in real time or at regular time), and if the migration schedules of all first partitions meet a preset condition (for example, the migration schedules indicate that data of each first partition has been migrated to a first node), the preset instruction is sent to the candidate control node, so that the candidate control node may take over a master control node to test whether the candidate control node can correctly control each node in the transitional cluster, and normally complete the data support service of the entire cluster.

The second partition also includes a plurality of data whose liveness is not completely the same, similarly to the case of the first partition. For example, in some second partitions there may be active data that may be frequently consumed by the consumer node, e.g., some data is accessed by the consumer node more than a preset number of times over a historical period of time, and inactive data that may be rarely consumed by the consumer, e.g., the number of times over the historical period of time is not consumed by the consumer node over the preset value. Therefore, the active data and the inactive data in the second partition can be migrated differentially by adopting a second migration strategy, so that the active data is not influenced to be accessed by the consumer node during data migration, and the inactive data can be migrated more quickly.

Referring to fig. 5, in some optional embodiments, when data of a second partition is differentially migrated to the first node according to the second migration policy, the active data and the inactive data in the second partition may be processed differently, which specifically includes steps 2021 to 2024:

step 2021, obtain active data in the second partition.

In the embodiment of the present application, the active data in the second partition may also be determined according to a historical consumption record, that is, according to the number of times that each data in the second partition is consumed by the consumer node in a historical period. If the number of times of consuming a certain data exceeds the preset value, it can be determined as the active data.

Step 2022, storing the copy of the active data and the first incremental data in a buffer.

Wherein the cache region is used for providing data service for a producer node and a consumer node, and the first incremental data is generated by the producer node in a first period.

In the embodiment of the present application, it is considered that active data is frequently consumed by consumers, that is, it may still need to be consumed by consumers at the time of data migration. In order to continue to provide data service for the consumer node without affecting the migration of the active data, a copy of the active data can be obtained and then stored in the cache region, and the data service is provided for the consumer through the cache region, so that the operation of a service system is not interrupted, and each data in the second partition can be completely migrated to the first node.

It will be appreciated that in a Kafka cluster, each partition may include multiple replicas such that upon failure of a (primary) partition, the master becomes the new (primary) partition. Therefore, in the embodiment of the application, when active data in a second partition in a second node is migrated, a copy of the second partition may be obtained, and a copy of the active data is obtained based on the copy of the second partition, and the copy of the active data is stored in the cache region, so as to provide a data service during data migration.

In consideration of the fact that, in the Kafka cluster, in order to ensure the safety of data, when a certain node fails, each partition in the node still keeps a complete data backup, and can continue to assume data service instead of the failed (primary) partition, one partition and its copy are stored on different nodes. For example, if the Kafka cluster includes 3 nodes, then partition A1 in node a may include 2 copies, which may be stored in node B and node C, respectively. Therefore, if the copy of the active data in the second partition is obtained according to the copy of the second partition, cross-node data transmission is involved, which may be inconvenient; therefore, in some optional embodiments, the active data in the second partition to be migrated may be directly copied to obtain a copy thereof, and the copy is stored in the cache region, so as to implement data processing more quickly and efficiently.

In order to ensure that the data service support is continuously provided for the business system in the cluster migration process, the message production requirements of the producer nodes need to be considered in the embodiment of the present application. In this embodiment, a message newly generated by a producer node and required to be stored in a second node may be referred to as first incremental data after a period of time (for example, a period of time between the start of migration to a target partition corresponding to the second node, that is, a first period of time) after the second node starts data migration, where the first incremental data may also be stored in a cache region, so as to continue to provide data services for the producer node and the consumer node, without affecting normal data migration.

In the embodiment of the present application, data migration is performed in units of partitions. Therefore, in order to ensure that each partition can provide data services in time when data migration is performed, in some optional embodiments, a cache region may be set corresponding to each partition. That is, each second node may be located in the same number of cache regions as the second partition, so as to provide the data cache service for each second partition one to one, so that each second partition can continue to support the data service of the consumer node and the producer node during data migration without hindrance.

Step 2023, migrating all data in the second partition to the first node to obtain a target partition.

Wherein the storage order of all data in the second partition is the same as that in the target partition.

Due to the arrangement of the cache region, when the data of the second partition is migrated, the data of the second partition can be migrated as a whole without considering how the active data provides data consumption support for the consumer node, and new messages generated by the producer node can be continuously accepted.

Referring to fig. 6, in the embodiment of the present application, when data in a second partition is migrated, data migration may be performed according to storage locations of data in the partition, so as to ensure that after the data in the second partition is migrated to a first node, a target partition completely consistent with the second partition may be obtained; i.e., data storage locations and storage order in the target partition, are the same as the corresponding second partition.

Step 2024, migrating the first incremental data in the cache region to the target partition.

In this embodiment of the present application, after all data in a second partition to be migrated is migrated to a first node, a target partition may be obtained, however, at this time, the data in the target partition is not complete, and a message (i.e., a first increment number in a cache region) generated by a producer node after a data migration operation is started needs to be stored in the target partition. Specifically, since the data of each next partition of one broker node in the Kafka cluster is additionally stored in time sequence, after all the data in one second partition is migrated to the first node to obtain the corresponding target partition, the first incremental data in the cache area corresponding to the second partition may be directly additionally stored directly after the last data in the target partition.

It is contemplated that the action of the producer node to produce the message may continue while the old delta data (i.e., the first delta data) in the cache is stored in its corresponding target partition, and new delta data is still being generated, i.e., the delta data in the cache is increasing. In order to avoid data collision in the buffer, in some optional embodiments, while the first incremental data in the buffer is stored in the corresponding target partition, the storage of the second incremental data generated by the producer node in this period (i.e., the second period, which may be temporally connected to the first period so as to continue the data migration work) into the buffer may also be stopped, and the second incremental data may be stored in a preset position of the target partition; wherein the preset position is determined based on the first incremental data in the buffer.

For example, a second partition includes 3 data segments: a1, a2 and a3, at the time of t1, starting to migrate the 3 data segments in the second partition to the corresponding first nodes; at time t2, the producer node generates 2 new messages: a4 and a5, and therefore, the first incremental data a4 and a5 are stored in the cache area of the second partition; at a time t3 (that is, the first period includes the time t1-t 3), a1, a2 and a3 are completely migrated successfully, and a target partition of the second partition is obtained, where a1, a2 and a3 are stored in the target partition; at time t4 (i.e., the second period), the first incremental data a4 and a5 in the buffer area start to be migrated into the target partition, at this time, the producer node regenerates a message a6 (i.e., the second incremental data), so that it can determine, according to the two first incremental data included in the buffer area, the 6 th data position where a6 should be stored in the target partition, and start to store a6 to the corresponding position in the target partition. That is, in the embodiment of the present application, after the target partition is obtained, the message newly generated by the producer node is no longer stored in the cache region, but is stored in the corresponding target partition.

And 103, updating the configuration information of all the nodes in the transition cluster to obtain a target cluster.

Wherein only the first node is included in the target cluster.

In this embodiment of the present application, after migrating data of all partitions in each second node to the corresponding first node, the second node may no longer provide data services, that is, may shut down each second node. For example, the cluster node addresses corresponding to the producer node and the consumer node may be changed from the address of the second node to the address of the first node.

In some scenarios, the real network address (e.g., the real IP address) of each node in the cluster may not be changed, and if the real network address is directly connected to the producer node or the consumer node, the cluster migration cannot be implemented without interrupting the service. Therefore, in the embodiment of the present application, an intermediate address may be mapped with a real network address of a cluster node by means of address mapping, and then a connection is established with a producer node or a consumer node by using the intermediate address.

Specifically, in the embodiment of the present application, each second node establishes a communication connection with a consumer node and a producer node through a preset network address mapping; the preset network address mapping comprises a mapping of a real network address of each second node and a preset network address, and the preset network address comprises one of the following items: domain name, virtual network address, or forwarding node address. Based on this, the real network address of each second node in the preset network address map may be updated to the real network address of each first node, so as to update the configuration information of each node in the transition cluster, thereby shutting down each second node in the transition cluster, and obtaining the target cluster.

For example, if the business parties (consumer nodes and producer nodes) access the source cluster through the domain name, the real network address of the first node of the target container environment is added to the domain name mapping; if the service party accesses the source cluster by adopting the virtual network address, the back-end host address of the virtual network address agent needs to be adjusted (namely, the real network address of each second node in the source cluster is adjusted to the real network address of each first node); if the service party adopts flow forwarding, the IPtable rules need to be adjusted, which is not described in detail here.

Therefore, in the final stage of cluster migration, the real network address of the old cluster node is unbound with the intermediate address, and then bound with the real network address of the new cluster node, so that the switching of the cluster nodes corresponding to the consumer node and the producer node can be realized. In the embodiment of the application, because the consumer node and the producer node are in communication connection with the intermediate address, even if the cluster node bound by the intermediate address is changed, the consumer node and the producer node are still insensitive, and service interruption is not caused.

Although the embodiment shown in fig. 2 of the present application describes a cluster migration method that can be implemented without interrupting a service by using a migration control node as an execution subject, the present application is not limited thereto. In some optional embodiments, the migration control node may also send an instruction to each second node in the source cluster and each newly-built first node in the target container environment, and the first node, the second node, and the migration control node interact with each other to complete the migration of the entire cluster service program. Referring to FIG. 7, in some alternative embodiments, data in a second node may be migrated to a first node by steps 301-305 of:

step 301, the migration control node sends a first instruction to the first node.

Wherein the first instruction may be to instruct the first node to join the source cluster.

Step 302, the first node receives the first instruction and joins the source cluster based on the first instruction.

Step 303, the migration control node sends a second instruction to the second node.

The second instruction may be used to instruct the second node to start data migration.

Step 304, the second node receives the second instruction and migrates data to the first node based on the second instruction.

Step 305, the second node sends a message to the migration control node.

Wherein the message may be used to indicate that the data in the second node has been completely migrated to the first node.

And step 306, the migration control node receives the message, and updates configuration information of all nodes in the transition cluster based on the message to obtain a target cluster.

In the embodiment of the application, a first node newly built in a target container environment is added into a source cluster in a virtual machine or physical machine environment to obtain a complete transition cluster, then migration of partition data in all second nodes of the source cluster to the first node is completed in the transition cluster, and finally the source cluster is shut down. Because the data migration operation in the embodiment of the application is completed in the same cluster, rather than between different clusters in the prior art, cross-domain transmission of data is avoided, the transmission efficiency of the data is improved, and network resources and time are saved. In addition, in the embodiment of the application, the network configuration information of the new and old cluster nodes is updated through the migration control node, so that the conversion of the data transmission destination address after data migration is realized, which is equivalent to that the data transmission between a service party (a consumer and a producer) and a cluster is transferred through a fixed transfer station instead of the way of directly connecting the service party and the cluster in the prior art, so that the service party can be respectively connected with the old node or the new node through the transfer station before the cluster migration starts and after the cluster migration finishes, the possible jitter in the cluster migration process is avoided, the hot migration of the cluster is realized, and the condition of service interruption is avoided.

In the above description, a cluster migration method in the embodiment of the present application is described, and a cluster migration system (for example, a server cluster) that executes the cluster migration method is described below.

Referring to fig. 8, a schematic structural diagram of a control node shown in fig. 8 may be applied to a server cluster, and is used to migrate a cluster service program from a source cluster (e.g., a virtual machine or a physical machine environment) to a target cluster (e.g., a container environment) without interrupting traffic. The control node in the embodiment of the present application can implement the steps corresponding to the cluster migration method executed in the embodiment corresponding to fig. 2. The functions realized by the cluster migration system can be realized by hardware, and can also be realized by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, which may be software and/or hardware. The control node may include a transceiver module 601 and a processing module 602, and the node may further include a display module (not identified in fig. 5), and the processing module 602 and the transceiver module 601 may implement the operations performed in the embodiment corresponding to fig. 2, which are not described herein again. For example, the processing module 602 may be used to control transceiving, obtaining, and the like operations of the transceiving module 601.

In some embodiments, the control node 60 is applied to a cluster migration system, which further includes a separately deployed source cluster and a target container environment, where the target container environment includes a plurality of first nodes, the source cluster includes a plurality of second nodes, and the number of the first nodes is the same as that of the second nodes;

the transceiver module 601 is configured to send an instruction for joining the source cluster to each first node to obtain a transition cluster; the transition cluster comprises all first nodes and all second nodes;

the processing module 602 is further configured to migrate, in the transition cluster, data of all partitions in each second node to each first node respectively; the first nodes correspond to the second nodes one by one, and each second node stores a plurality of partition data;

the processing module 602 is further configured to update configuration information of all nodes in the transition cluster to obtain a target cluster, where the target cluster includes only the first node.

In some embodiments, the transition cluster includes a master control node and candidate control nodes, the master control node is obtained by pre-registering a second node, and the candidate control nodes are obtained by registering a first node;

and the candidate control nodes are used for synchronizing the configuration information in the main control node and taking over the main control node when receiving a preset instruction.

In some embodiments, each second node establishes a communication connection with the consumer node and the producer node through a preset network address mapping;

the preset network address mapping comprises a mapping between a real network address of each second node and a preset network address, and the preset network address comprises one of the following items: a domain name, a virtual network address, and a forwarding node address;

the processing module 602 is further configured to update the real network address of each second node in the preset network address map to the real network address of each first node.

In some embodiments, the processing module 602 is further configured to obtain a first partition and a second partition from all partitions of the second node according to the historical consumption records of the respective consumer nodes, where the historical consumption times of the first partition are not greater than a preset value, and the historical consumption times of the second partition are greater than the preset value; migrating the data of each first partition to the first node according to a first migration strategy; and migrating the data of each second partition to the first node according to a second migration strategy.

In some embodiments, the processing module 602 is further configured to obtain all active data in the second partition, where the number of times each active data is consumed by a consumer node within a history period exceeds the preset value; storing the copy of each active data and first incremental data into a cache region, wherein the cache region is used for providing data services for a producer node and a consumer node, and the first incremental data is generated by the producer node in a first time period;

the processing module 602 is further configured to migrate all data in the second partition to the first node, so as to obtain a target partition; wherein the storage order of all data in the second partition is the same as that in the target partition; and migrating the first incremental data in the cache region to the target region.

In some embodiments, the processing module 602 is further configured to, after the migrating all data in the second partition to the first node and obtaining a target partition, store second incremental data in a preset position of the target partition;

wherein the second incremental data is generated by a producer node at a second time period that is chronologically adjacent to, and not earlier than, the first time period; the preset position is determined based on the first incremental data in the buffer.

In some embodiments, the processing module 602 is further configured to obtain migration progress of all first partitions of each second node before the updating of the configuration information of all nodes in the transition cluster to obtain the target cluster; and if the migration progress of all the first partitions meets a preset condition, sending the preset instruction to the candidate control node.

In the embodiment of the application, under the control of the processing module, the control node adds a newly-built first node in the container environment to a source cluster in the virtual machine or physical machine environment to obtain a complete transition cluster, then completes migration of partition data in all second nodes of the source cluster to the first node in the transition cluster, and finally shuts down the source cluster. Because the data migration operation in the embodiment of the application is completed in the same cluster, rather than between different clusters in the prior art, cross-domain transmission of data is avoided, the transmission efficiency of the data is improved, and network resources and time are saved. In addition, in the embodiment of the application, the network configuration information of the new and old cluster nodes is updated through the control node, so that the conversion of the data transmission destination address after data migration is realized, which is equivalent to that the data transmission between a service party (a consumer and a producer) and a cluster is transferred through a fixed transfer station, but not a mode that the service party is directly connected with the cluster in the prior art, so that the service party can be respectively connected with the old node or the new node through the transfer station before the cluster migration starts and after the cluster migration finishes, the possible jitter in the cluster migration process is avoided, the hot migration of the cluster is realized, and the condition of service interruption is avoided.

The control node 60 in the embodiment of the present application is described above from the perspective of a modular functional entity, and the servers executing the cluster migration method in the embodiment of the present application are described below from the perspective of hardware processing.

It should be noted that, in the embodiment of the control node of the present application, the entity device corresponding to the transceiver module 601 shown in fig. 8 may be an input/output unit, a transceiver, a radio frequency circuit, a communication module, an input/output (I/O) interface, and the like, and the entity device corresponding to the processing module 602 may be a processor. The control node 60 shown in fig. 8 may have a structure as shown in fig. 9, when the control node 60 shown in fig. 8 has a structure as shown in fig. 9, the processor and the transceiver in fig. 9 can implement the same or similar functions of the processing module 602 and the transceiver module 601 provided in the embodiment of the node corresponding to the node, and the memory in fig. 9 stores a computer program that needs to be called when the processor executes the cluster migration method.

Referring to fig. 10, fig. 10 is a schematic structural diagram of a server provided in the embodiment of the present application, where the server 1100 may generate relatively large differences due to different configurations or performances, and may include one or more Central Processing Units (CPUs) 1122 (e.g., one or more processors) and a memory 1132, and one or more storage media 1130 (e.g., one or more mass storage devices) storing an application program 1142 or data 1144. Memory 1132 and storage media 1130 may be, among other things, transient storage or persistent storage. The program stored on the storage medium 1130 may include one or more modules (not shown), each of which may include a series of instruction operations for the server. Still further, the central processor 1122 may be provided in communication with the storage medium 1130 to execute a series of instruction operations in the storage medium 1130 on the server 1100.

The Server 1100 may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1150, one or more input-output interfaces 1158, and/or one or more operating systems 1141, such as Windows Server, mac OS X, unix, linux, freeBSD, etc.

The steps performed by the server in the above-described embodiment may be based on the structure of the server 1100 shown in fig. 10. For example, the steps performed by the control node 60 shown in fig. 10 in the above-described embodiment may be based on the server structure shown in fig. 10. For example, the central processor 1122, by calling the instructions in the memory 1132, performs the following operations:

sending an instruction to each first node through an input/output interface 1158, so that each first node joins the source cluster to obtain a transition cluster; each first node is deployed in a target container environment, each second node is deployed in a source cluster, and the number of the first nodes is the same as that of the second nodes;

respectively migrating the data of all the partitions in each second node to each first node, wherein the first nodes correspond to the second nodes one by one, and each second node comprises a plurality of partitions;

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the system, the apparatus and the module described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the embodiments of the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the modules is merely a logical division, and in actual implementation, there may be other divisions, for example, multiple modules or components may be combined or integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed coupling or direct coupling or communication connection between each other may be through some interfaces, indirect coupling or communication connection between devices or modules, and may be in an electrical, mechanical or other form.

The modules described as separate parts may or may not be physically separate, and parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, functional modules in the embodiments of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a separate product, may be stored in a computer-readable storage medium.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product.

The computer program product includes one or more computer instructions. The procedures or functions described in accordance with the embodiments of the present application are generated in whole or in part when the computer program is loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device, such as a server, a data center, etc., that is integrated with one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

The technical solutions provided by the embodiments of the present application are introduced in detail, and the principles and implementations of the embodiments of the present application are explained by applying specific examples in the embodiments of the present application, and the descriptions of the embodiments are only used to help understanding the method and core ideas of the embodiments of the present application; meanwhile, for a person skilled in the art, according to the idea of the embodiment of the present application, there may be a change in the specific implementation and application scope, and in summary, the content of the present specification should not be construed as a limitation to the embodiment of the present application.

Claims

1. A cluster migration method is applied to a migration control node in a cluster migration system, the cluster migration system further comprises a source cluster and a target container environment which are separately deployed, the target container environment comprises a plurality of first nodes, the source cluster comprises a plurality of second nodes, and the number of the first nodes is the same as that of the second nodes; the method comprises the following steps:

in the transition cluster, migrating all partitioned data in each second node to each first node respectively; the first nodes correspond to the second nodes one by one, and each second node stores a plurality of partition data;

2. The method of claim 1, wherein the transitional cluster includes a primary control node and a candidate control node, the primary control node being pre-registered by a second node and the candidate control node being registered by a first node;

3. The method of claim 1, wherein each second node establishes a communication link with the consumer node and the producer node via a predetermined network address mapping;

the preset network address mapping comprises a mapping of a real network address of each second node and a preset network address, and the preset network address comprises one of the following items: a domain name, a virtual network address, and a forwarding node address;

the updating the configuration information of all the nodes in the transition cluster comprises:

and updating the real network address of each second node in the preset network address mapping into the real network address of each first node.

4. The method of any of claims 1-3, wherein migrating all partition data in a second node to a first node comprises:

acquiring a first partition and a second partition from all partitions of a second node according to historical consumption records of all consumer nodes, wherein the historical consumption times of the first partition are not more than a preset value, and the historical consumption times of the second partition are more than the preset value;

migrating the data of each first partition to the first node according to a first migration strategy; and migrating the data of each second partition to the first node according to a second migration strategy.

5. The method of claim 4, wherein migrating data of a second partition to the first node according to the second migration policy comprises:

acquiring all active data in the second partition, wherein the consumption frequency of each active data by a consumer node in a historical period exceeds the preset value;

storing the copy of each active data and first incremental data into a cache region, wherein the cache region is used for providing data service for a producer node and a consumer node, and the first incremental data is generated by the producer node in a first period;

migrating all data in the second partition to the first node to obtain a target partition; wherein the storage order of all data in the second partition is the same as that in the target partition;

migrating the first incremental data in the cache region to the target partition.

6. The method of claim 5, wherein after migrating all data in the second partition to the first node to obtain a target partition, the method further comprises:

storing second incremental data into a preset position of the target partition;

wherein the second incremental data is generated by a producer node at a second time period that is chronologically adjacent to and later than the first time period; the preset position is determined based on the first incremental data in the buffer.

7. The method of claim 4, wherein before updating configuration information for all nodes in the transitional cluster to obtain a target cluster, the method further comprises:

acquiring the migration progress of all the first partitions of each second node;

and if the migration progress of all the first partitions meets a preset condition, sending the preset instruction to the candidate control node.

8. A control node is applied to a cluster migration system, the cluster migration system also comprises a source cluster and a target container environment which are separately deployed, the target container environment comprises a plurality of first nodes, the source cluster comprises a plurality of second nodes, and the number of the first nodes is the same as that of the second nodes; the node comprises:

the processing module is configured to migrate all partitioned data in each second node to each first node in the transition cluster respectively; the first nodes correspond to the second nodes one by one, and each second node stores a plurality of partition data;

9. A computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1-7 when executing the computer program.

10. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1-7.