Cloud host migration method across storage pools

Abstract

The invention discloses a cloud host migration method across storage pools. The method comprises the following steps: acquiring capability information of a source storage pool and a target storage pool of a source cloud host; if both the source cloud host and the source cloud host support storage volume migration, cloning a target disk in the source storage pool to generate a cloned storage volume, and creating a first network port with the same network configuration as the source cloud host; migrating the cloned storage volume to a target storage pool, and creating a target cloud host based on the cloned storage volume, the target disk at least comprising a system disk; if any storage pool does not support migration, creating an auxiliary cloud host and an empty storage volume with the same size in the target storage pool; cloning a target disk in the source storage pool and copying data to the empty storage volume to generate a target storage volume; and creating a first network port with the same network configuration, and creating a target cloud host in the target storage pool based on the target storage volume and the network port. The technical problems that a traditional virtual machine migration scheme is tedious in process, high in labor cost and low in efficiency are solved.

Description

Technical Field

[0001] The present application relates to the field of cloud service technology, and in particular to a method for cloud host migration across storage pools. Background Art

[0002] With the maturity and widespread application of cloud computing technology, virtualization technology has become an indispensable part of the cloud environment. It provides advantages such as environmental isolation, fast configuration, resource saving and high service availability. On the cloud platform, virtual machines (cloud hosts) are key components that carry user services. Sometimes they need to be migrated or backed up, especially when storage capacity is insufficient or storage devices need to be upgraded or replaced. In a hybrid cloud environment, a resource pool may contain multiple storage pools, which may come from different suppliers, including distributed storage, centralized storage, etc. For key business systems deployed in a hybrid cloud environment, there is a need to migrate or back up a large number of ordinary cloud hosts and GPU cloud hosts across storage to ensure business continuity and data security. At present, when performing large-scale virtual machine migration, the use of migration tools or traditional migration methods may not only require a lot of expenses and manpower, but also the migration process is cumbersome and time-consuming. If the cross-storage migration of the same resource pool is integrated into the hybrid cloud management platform, it can save a lot of cost, manpower and time. Summary of the invention

[0003] The embodiment of the present application provides a cloud host migration method across storage pools to at least solve the technical problems of traditional virtual machine migration solutions that are cumbersome, have high labor costs and low efficiency.

[0004] According to one aspect of an embodiment of the present application, a cloud host migration method across storage pools is provided, comprising: obtaining capability information of a source storage pool and a target storage pool corresponding to a source cloud host in a migration task; when both the source storage pool and the target storage pool support a storage volume migration function, cloning a target disk of a source cloud host in the source storage pool to obtain a cloned storage volume, and creating a first network port configured identically to a source network port of the source cloud host; migrating the cloned storage volume to a target storage pool, and creating a target cloud host in the target storage pool based on the cloned storage volume and the first network port, wherein the target disk includes at least a system disk; when the source storage pool and / or the target storage pool do not support a storage volume migration function, creating an auxiliary cloud host in the target storage pool, and creating an empty storage volume of the same size as the target disk under the auxiliary cloud host; cloning a target disk in the source storage pool to obtain a cloned storage volume, and copying data in the cloned storage volume to the empty storage volume to obtain a target storage volume; creating a first network port configured identically to a source network port of the source cloud host, and creating a target cloud host in the target storage pool based on the target storage volume and the first network port.

[0005] Optionally, a target disk of the source cloud host is cloned in the source storage pool to obtain a cloned storage volume, and a first network port with the same configuration as the source network port of the source cloud host is created, including: in response to a cloud host migration instruction input by the target object in the cloud management platform, calling a shutdown instruction of the OpenStack cloud platform to shut down the source cloud host; calling a clone instruction of the OpenStack cloud platform to clone the target disk of the source cloud host in the source storage pool to obtain a cloned storage volume; calling a port creation instruction of the OpenStack cloud platform to create a first network port with the same configuration as the source network port of the source cloud host in the virtual private cloud corresponding to the source cloud host, wherein the source network port corresponds to the virtual network card of the source cloud host.

[0006] Optionally, the cloned storage volume is migrated to the target storage pool, and a target cloud host is created in the target storage pool based on the cloned storage volume and the first network port, including: calling the cinderretype function of the OpenStack cloud platform to perform a disk type change operation on the cloned storage volume to migrate the cloned storage volume to the target storage pool; calling the host creation instruction of the OpenStack cloud platform to create a target cloud host based on the information of the system disk and the first network port in the cloned storage volume; calling the port uninstall instruction of the OpenStack cloud platform to uninstall the source network port of the source cloud host, and calling the port add instruction of the OpenStack cloud platform to bind the first network port to the target cloud host; when the target disk also includes a data disk, the data disk in the cloned storage volume is mounted to the target cloud host; when the source cloud host is configured with an elastic public IP, calling the IP uninstall instruction of the OpenStack cloud platform to uninstall the elastic public IP configured by the source cloud host, and calling the IP add instruction of the OpenStack cloud platform to bind the elastic public IP to the target cloud host.

[0007] Optionally, copying the data in the cloned storage volume to the empty storage volume to obtain the target storage volume includes: calling a target disk copy command to copy the data in the cloned storage volume to the empty storage volume to obtain the target storage volume, wherein the type of the target disk copy command includes at least one of the following: an rsync command that only copies data that actually occupies space, a dd command that copies the disk sector by sector, and a ddrescue command that automatically skips problem areas during data copying; performing a data consistency check on the target storage volume and the cloned storage volume, determining that the data copying is complete when the check passes, and deleting the data in the target storage volume when the check fails, and re-copying the data in the cloned storage volume to the target storage volume.

[0008] Optionally, a first network port with the same configuration as the source network port of the source cloud host is created, and a target cloud host is created in the target storage pool based on the target storage volume and the first network port, including: calling the port creation instruction of the OpenStack cloud platform to create a first network port with the same configuration as the source network port of the source cloud host in the virtual private cloud corresponding to the source cloud host, wherein the source network port corresponds to the virtual network card of the source cloud host; calling the host creation instruction of the OpenStack cloud platform to create the target cloud host according to the information of the system disk and the first network port in the target storage volume; calling the port uninstall instruction of the OpenStack cloud platform to uninstall the source network port of the source cloud host, and calling the port add instruction of the OpenStack cloud platform to bind the first network port to the target cloud host; when the target disk also includes a data disk, the data disk in the target storage volume is mounted to the target cloud host; when the source cloud host is configured with an elastic public IP, calling the IP uninstall instruction of the OpenStack cloud platform to uninstall the elastic public IP configured by the source cloud host, and calling the IP add instruction of the OpenStack cloud platform to bind the elastic public IP to the target cloud host.

[0009] Optionally, the source cloud host is configured with a GPU, and the method further includes: before cloning the target disk, calling the product specification query instruction of the OpenStack cloud platform to obtain a first product specification instance corresponding to the source cloud host; calling the product specification creation instruction of the OpenStack cloud platform to create a second product specification instance that does not include GPU information and whose other product specifications are the same as those in the first product specification instance; calling the product specification adjustment instruction of the OpenStack cloud platform to replace the product specifications of the source cloud host with the second product specification instance; after creating the target cloud host, calling the product specification adjustment instruction of the OpenStack cloud platform to replace the product specifications of the target cloud host with the first product specification instance.

[0010] Optionally, during the migration process of the source cloud host, target information is obtained and stored in the migration record, wherein the target information includes at least one of the following: a migration task identifier, a universally unique identifier of the source cloud host, a host name, status information, configuration information, virtual private cloud information, network port information, cloud hard disk information, elastic public network information, and specification information of a configured GPU; a universally unique identifier of the target cloud host, a host name, status information, configuration information, virtual private cloud information, network port information, cloud hard disk information, elastic public network information, and specification information of a configured GPU; an identifier, type, and capacity of a source storage pool; an identifier, type, and capacity of a target storage pool; and migration log information.

[0011] Optionally, the data and configuration information of the source cloud host are checked for consistency with the data and configuration information of the target cloud host; if the check passes, the migration is determined to be complete and the source cloud host is destroyed; if the check fails, the migration is determined to have failed, the configuration information of the source cloud host is rolled back according to the migration record information, and the rollback log is stored in the migration record.

[0012] According to another aspect of an embodiment of the present application, a cross-storage pool cloud host migration method is also provided, including: obtaining multiple cloud hosts corresponding to multiple cloud platform applications to be migrated, and dividing the multiple cloud hosts according to the virtual private clouds corresponding to each cloud host to obtain multiple cloud host sets; determining the target number of cloud hosts to be migrated in parallel based on the storage bandwidth and throughput performance of the target storage pool; for each cloud host set, migrating the cloud hosts in the cloud host set to the target storage pool in parallel based on the target number and using any one of the cross-storage pool cloud host migration methods.

[0013] According to another aspect of an embodiment of the present application, an electronic device is also provided, which includes: a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the above-mentioned cloud host migration method across storage pools through the computer program.

[0014] In the embodiment of the present application, the most suitable migration path is intelligently selected according to whether the source storage pool and the target storage pool support the storage volume migration function. When both storage pools support storage volume migration, this function is directly used for efficient migration. When any storage pool does not support it, an indirect migration strategy is adopted to complete data replication by creating an auxiliary cloud host and an empty storage volume to ensure the smooth completion of the migration task. Whether it is direct migration or indirect migration, the target disk of the source cloud host will be cloned in the source storage pool to generate a clone storage volume to ensure the consistency and integrity of the data. For indirect migration, the data of the clone storage volume will also be copied to the empty storage volume in the target storage pool to further ensure the accuracy of the data. When creating the target cloud host in the target storage pool, a first network port with the same configuration as the source network port of the source cloud host will be created to ensure that the migrated cloud host is consistent with the original host in network configuration and does not affect the normal operation of the business. By creating an auxiliary cloud host and an empty storage volume in the target storage pool to handle the situation where direct migration is not supported, the resources of the target storage pool are effectively utilized to avoid unnecessary waste of resources, thereby solving the technical problems of the traditional virtual machine migration solution being cumbersome, high labor cost and low efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0016] Figure 1 It is a flowchart of an optional cloud host migration method across storage pools according to an embodiment of the present application;

[0017] Figure 2 It is a flowchart of performing cross-storage migration of a cloud host when both the source storage pool and the target storage pool support the storage volume migration function according to an embodiment of the present application;

[0018] Figure 3 It is a flowchart of performing cross-storage migration of a cloud host when neither the source storage pool nor the target storage pool supports the storage volume migration function according to an embodiment of the present application;

[0019] Figure 4 It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0020] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0021] It should be noted that the terms "first", "second", etc. in the specification, claims and drawings of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0022] Example 1

[0023] According to an embodiment of the present application, a method for cloud host migration across storage pools is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0024] Figure 1is a flow chart of a cloud host migration method across storage pools provided according to an embodiment of the present application, such as Figure 1 As shown, the method comprises the following steps:

[0025] Step S102, obtaining the capacity information of the source storage pool and the target storage pool corresponding to the source cloud host in the migration task;

[0026] Step S104, when both the source storage pool and the target storage pool support the storage volume migration function, clone the target disk of the source cloud host in the source storage pool to obtain the cloned storage volume, and create a first network port with the same configuration as the source network port of the source cloud host; migrate the cloned storage volume to the target storage pool, and create a target cloud host in the target storage pool based on the cloned storage volume and the first network port, wherein the target disk includes at least: a system disk;

[0027] Step S106, when the source storage pool and / or the target storage pool does not support the storage volume migration function, create an auxiliary cloud host in the target storage pool, and create an empty storage volume with the same size as the target disk under the auxiliary cloud host; clone the target disk in the source storage pool to obtain a cloned storage volume, and copy the data in the cloned storage volume to the empty storage volume to obtain the target storage volume; create a first network port with the same configuration as the source network port of the source cloud host, and create a target cloud host in the target storage pool based on the target storage volume and the first network port.

[0028] The following describes the various steps of the cloud host migration method across storage pools in conjunction with the specific implementation process.

[0029] Obtain the capacity information of the source storage pool and target storage pool corresponding to the source cloud host in the migration task.

[0030] As an optional implementation, in order to obtain the capacity information of the current storage pool of the source cloud host, the cloud management platform needs to interact with the OpenStack cloud platform to query the detailed information of the storage volume (the system disk and data disk of the cloud host), which can be completed through the openstack volume show or cinder show command, and the command contains the volume_id of the source cloud host disk. The query results usually contain information such as the type, status, size and capacity of the storage volume, which can reflect the type and current capacity of the source storage pool. Similarly, the cloud management platform also needs to query the information of the target storage pool, which usually involves using the openstack volume type show or cinder type-show command to understand the characteristics and limitations of the target storage pool. The query information of the target storage pool will include its supported features, current capacity, available space, and whether it supports migration functions such as cinder retype. This information is crucial for evaluating whether the target storage pool can accommodate the data of the source cloud host and whether the storage-level migration function can be used directly. After obtaining the storage pool information, the cloud management platform will evaluate the capabilities of the source storage pool and the target storage pool to determine the most appropriate migration strategy.

[0031] In the process of cross-storage migration of cloud hosts, it is crucial to distinguish whether the source storage pool and the target storage pool support the storage volume migration function (such as through the cinder retype command). The reason is that different storage pools may have different characteristics, limitations and compatibilities, which directly affect the feasibility and efficiency of data migration. In this regard, this application also proposes migration methods under different circumstances. If both storage pools support direct migration through cinder retype, this more efficient method can be selected. If one of the source storage pool or the target storage pool does not support direct migration, the cloud management platform will consider using a data replication and verification process, such as using dd, rsync or ddrescue commands to ensure data integrity and consistency. The specific implementation steps are as follows:

[0032] When both the source storage pool and the target storage pool support the storage volume migration function, the target disk of the source cloud host is cloned in the source storage pool to obtain the cloned storage volume, and a first network port with the same configuration as the source network port of the source cloud host is created; the cloned storage volume is migrated to the target storage pool, and a target cloud host is created in the target storage pool based on the cloned storage volume and the first network port, wherein the target disk includes at least: a system disk.

[0033] As an optional implementation method, cloning the target disk of the source cloud host in the source storage pool to obtain a cloned storage volume, and creating a first network port with the same configuration as the source network port of the source cloud host can be performed in the following manner: in response to the cloud host migration instruction input by the target object in the cloud management platform, calling the shutdown instruction of the OpenStack cloud platform to shut down the source cloud host to prevent data writing and ensure data consistency; calling the cloning instruction of the OpenStack cloud platform to clone the target disk of the source cloud host in the source storage pool to obtain a cloned storage volume; calling the port creation instruction of the OpenStack cloud platform to create a first network port with the same configuration as the source network port of the source cloud host in the virtual private cloud corresponding to the source cloud host, so as to ensure that the new cloud host created in the target storage pool can access the same virtual private cloud as the source cloud host, wherein the source network port corresponds to the virtual network card of the source cloud host, which determines the network accessibility and communication capability of the cloud host. When creating the first network port, the key is to ensure that the configuration of the new port is exactly the same as the source network port, including information such as the IP (Internet Protocol) address, the MAC (Media Access Control Address) address, the subnet to which it belongs, and the security group.

[0034] For example, the user first needs to access the web interface of the cloud management platform, enter the corresponding user name and password for authentication, and log in to the cloud management platform. After successful login, the system will display a list of resources accessible to the user, including cloud hosts, virtual private clouds, storage pools, etc. After logging in, the user enters the virtual machine list interface, which lists all the user's cloud host instances. The user finds the cloud host to be migrated in the list. Usually, this selection process can be completed through the search or filtering function to quickly locate the cloud host. After the selection is completed, a user can further view the detailed information of the cloud host, such as virtual private cloud information, network card configuration, cloud hard disk information, physical specifications and elastic public network IP, etc. This information is very important in the subsequent migration procedures. After the user determines the cloud host to be migrated, the shutdown operation can be triggered by the shutdown button on the interface of the cloud management platform, or the shutdown command can be executed through the command line. The shutdown command is usually implemented by calling the API (Application Programming Interface) of the OpenStack cloud platform through the cloud management platform, specifically named: openstack server stop<server_id> ,in,<server_id> It is the unique identifier of the cloud host. After executing the shutdown command, the system will continuously poll the status of the cloud host until it is confirmed that it is in the shutdown state (SHUTOFF state). This is to avoid data writing and ensure the integrity of the data during the migration process. Changes in data during the shutdown process lead to the problem of inconsistent final data. After completing the above login, selection and shutdown steps, the cloud management platform will automatically perform subsequent cloud host cross-storage migration operations, including cloning of system disks and data disks, creating new cloud hosts, migration of network ports and elastic public IPs, and necessary data verification and rollback mechanisms, ultimately achieving efficient and safe migration of cloud hosts between different storage pools. For GPU cloud hosts, the shutdown process is equally important, because after shutdown, GPU card resources can be uninstalled more safely, and then storage-level migration can be performed. Finally, GPU resources are reconfigured on the target cloud host to ensure that the migrated GPU cloud host can operate normally and has the same computing power as the original GPU cloud host.

[0035] As an optional implementation, the clone instruction usually uses the cinder create command, for example: cindercreate --name<new_volume_name> --source<source_volume_id><volume_size> ,in,<new_volume_name> is the name of the cloned storage volume.<source_volume_id> is the ID of the source storage volume,<volume_size> is the size of the clone volume, usually the same as the source volume.

[0036] As an optional implementation, the port creation instruction usually uses the openstack port create command, for example: openstack port create --network<vpc_network_id> --fixed-ip ip_address=<ip_address> --mac-address<mac_address><port_name> ,in,<vpc_network_id> is the ID of the virtual private cloud network.<ip_address> is the IP address of the port,<mac_address> is the MAC address of the port,<port_name> is the name of the newly created port.

[0037] As an optional implementation, the cloned storage volume is migrated to the target storage pool, and a target cloud host is created in the target storage pool based on the cloned storage volume and the first network port. The following steps can be taken: call the cinderretype function of the OpenStack cloud platform to change the disk type of the cloned storage volume to migrate the cloned storage volume to the target storage pool; call the host creation instruction of the OpenStack cloud platform to create a target cloud host based on the system disk and the first network port information in the cloned storage volume; call the port uninstall instruction of the OpenStack cloud platform to uninstall the source network port of the source cloud host, and call the port add instruction of the OpenStack cloud platform to bind the first network port to the target cloud host; when the target disk also includes a data disk, mount the data disk in the cloned storage volume to the target cloud host; when the source cloud host is configured with an elastic public IP, call the IP uninstall instruction of the OpenStack cloud platform to uninstall the elastic public IP configured by the source cloud host, and call the IP add instruction of the OpenStack cloud platform to bind the elastic public IP to the target cloud host. The above process of cloud host cross-storage migration when both the source storage pool and the target storage pool support the storage volume migration function is as follows. Figure 2 shown.

[0038] For example, when the source storage pool supports the cinder retype command, the cloud management platform calls the cinder retype function of the OpenStack cloud platform to change the disk type of the cloned storage volume and migrate the data of the cloned storage volume to the target storage pool. This usually involves changing the type attribute of the storage volume to meet the requirements of the target storage pool, such as migrating from Huawei FC-SAN (Fiber Channel Storage Area Network) to Tianyi Cloud distributed storage. Command example: cinder retype<volume_id><volume-type>--migration-policyon-demand, where<volume_id> is the ID of the cloned storage volume. <volume-type>It is the type of the target storage pool. The on-demand migration strategy means that data is migrated only when it is actually needed to ensure non-destructive migration. The cloud management platform calls the nova boot command of OpenStack to create a target cloud host based on the system disk and the first network port information in the cloned storage volume. The first network port should be consistent with the network port configuration of the source host to ensure the continuity of the network connection. Command example: nova boot --flavor<flavor_id> --nic port-id=<port_id> --block-device id=<volume_id> , source=volume,bootindex=0--availability-zone <az> <name>,in,<flavor_id> is the specification ID of the new host,<port_id> is the ID of the first network port,<volume_id> is the ID of the cloned storage volume. <az>is the available area, <name>is the name of the new host. Use openstack server remove port<port_id> Command to uninstall the source network port on the source cloud host, use openstack server add port<server_id><port_id> Command to bind the first network port to the target cloud host, ensuring that the target cloud host has the same network configuration as the source cloud host. If the source cloud host still has data disks, you need to clone the data disks in the source storage pool and use cinderretype to migrate them to the target storage pool. Use nova interface-attach or openstack server add volume command to mount the data disks to the target cloud host to ensure the consistency of the data disks. Use openstack floating ipunset-port <ip>Command to uninstall the elastic public IP on the source cloud host, using openstack server addfloating ip<server_id><ip_address> Command to bind the elastic public IP to the target cloud host to achieve seamless switching of the public IP.

[0039] The above method directly changes the type of storage volume at the storage layer, thereby migrating the volume from the source storage pool to the target storage pool without the need for additional data copying and processing. This usually means that data migration can be completed within the storage system, avoiding data copying and potential performance bottlenecks in network transmission, while reducing the time and complexity of data migration.

[0040] In the case where the source storage pool and / or the target storage pool do not support the storage volume migration function, create an auxiliary cloud host in the target storage pool, and create an empty storage volume with the same size as the target disk under the auxiliary cloud host; clone the target disk in the source storage pool to obtain a cloned storage volume, and copy the data in the cloned storage volume to the empty storage volume to obtain the target storage volume; create a first network port with the same configuration as the source network port of the source cloud host, and create a target cloud host in the target storage pool based on the target storage volume and the first network port.

[0041] As an optional implementation, the data in the cloned storage volume is copied to the empty storage volume to obtain the target storage volume. The following steps can be adopted: call the target disk copy command to copy the data in the cloned storage volume to the empty storage volume to obtain the target storage volume, wherein the type of the target disk copy command includes at least one of the following: the rsync command that only copies the data that actually occupies the space, the dd command that copies the disk sector by sector, and the ddrescue command that automatically skips the problem area during the data copying process; perform a data consistency check on the target storage volume and the cloned storage volume, determine that the data copying is completed when the check passes, and delete the data in the target storage volume when the check fails, and re-copy the data in the cloned storage volume to the target storage volume.

[0042] Among them, when the disk is large enough and the utilization rate is not high, the rsync command is preferably used. Rsync saves time and bandwidth resources by efficiently copying only the data that actually occupies the space instead of the entire disk. The specific command is as follows: rsync-avz--progress / mnt / source / / mnt / target / , where / mnt / source / and / mnt / target / represent the mount point paths of the cloned storage volume and the target storage volume mounted on the secondary cloud host, respectively. When the disk utilization is high or a complete copy is required, the dd command is used. The dd command copies the disk sector by sector to ensure that all data, including unallocated space and residual information of deleted files, can be accurately copied. The specific command is as follows: dd if= / dev / vda of= / dev / vdcbs=64K conv=noerror,sync. When the disk needs data recovery-style migration due to some unexpected situation (such as bad sectors), the ddrescue command is used. ddrescue can automatically skip the problem area during the copying process and try to recover as much data as possible. The command is as follows: ddrescue-dfn-r3 / dev / vda / dev / vdc / path / to / logfile, where / dev / vda and / dev / vdc represent the clone storage volume and the target storage volume respectively, and / path / to / logfile is used to record the problem areas encountered during the copying process for subsequent analysis or retry.

[0043] When performing data consistency check on the target storage volume and the cloned storage volume, you can take the following steps: Use the diff tool to compare the entire disk sector by sector. The specific command is diff-qr / mnt / source / mnt / target. Or, if you use rsync for data synchronization, you can enable the --checksum option to force the use of checksums to check whether the files are identical. The command is as follows: rsync-avz--checksum--progress / mnt / source / / mnt / target / . The --checksum option in the above command is used to check whether the files are exactly the same through checksums after data transmission.

[0044] As an optional implementation, creating a first network port with the same configuration as the source network port of the source cloud host, and creating a target cloud host in the target storage pool based on the target storage volume and the first network port may include the following steps: calling the port creation instruction of the OpenStack cloud platform to create a first network port with the same configuration as the source network port of the source cloud host in the virtual private cloud corresponding to the source cloud host, wherein the source network port corresponds to the virtual network card of the source cloud host; calling the host creation instruction of the OpenStack cloud platform to create the target cloud host according to the information of the system disk and the first network port in the target storage volume; calling the port unloading instruction of the OpenStack cloud platform The load instruction uninstalls the source network port of the source cloud host, and calls the port add instruction of the OpenStack cloud platform to bind the first network port to the target cloud host; if the target disk also includes a data disk, mount the data disk in the target storage volume to the target cloud host; if the source cloud host is configured with an elastic public IP, call the IP uninstall instruction of the OpenStack cloud platform to uninstall the elastic public IP configured by the source cloud host, and call the IP add instruction of the OpenStack cloud platform to bind the elastic public IP to the target cloud host. The above process of cloud host cross-storage migration when both the source storage pool and the target storage pool do not support the storage volume migration function is as follows Figure 3 shown.

[0045] As an optional implementation, during the migration process of the source cloud host, target information is also obtained and stored in the migration record, wherein the target information includes at least one of the following: a migration task identifier, a universally unique identifier of the source cloud host, a host name, status information, configuration information, virtual private cloud information, network port information, cloud hard disk information, elastic public network information, and specification information of a configured GPU; a universally unique identifier of the target cloud host, a host name, status information, configuration information, virtual private cloud information, network port information, cloud hard disk information, elastic public network information, and specification information of a configured GPU; an identifier, type, and capacity of the source storage pool; an identifier, type, and capacity of the target storage pool; and migration log information.

[0046] As an optional implementation, during the cross-storage migration of cloud hosts, ensuring consistency verification of data and configuration information is a key step to the success of the migration. The specific operation process can be as follows: perform consistency verification on the data and configuration information of the source cloud host with the data and configuration information of the target cloud host; if the verification passes, the migration is determined to be complete and the source cloud host is destroyed; if the verification fails, the migration is determined to have failed, and the configuration information of the source cloud host is rolled back according to the migration record information, and the rollback log is stored in the migration record.

[0047] If the source cloud host is configured with a GPU, the product specifications (also known as instance specifications or Flavors) need to be adjusted before and after cross-storage migration to ensure that the GPU resources are correctly uninstalled and reconfigured during the migration process. The specific steps can be as follows: before cloning the target disk, in order to identify whether the source cloud host contains GPU resources and other specification parameters other than GPU (such as CPU, memory, disk type and size), call the product specification query instruction of the OpenStack cloud platform to obtain the first product specification instance corresponding to the source cloud host; in order to temporarily uninstall the GPU resources during the migration process to avoid dependence on the GPU in storage migration, call the product specification creation instruction of the OpenStack cloud platform to create a second product specification instance that does not include GPU information and has other product specifications that are the same as the product specifications in the first product specification instance; call the product specification adjustment instruction of the OpenStack cloud platform to replace the product specification of the source cloud host with the second product specification instance, that is, a specification that does not contain GPU information; after creating the target cloud host, call the product specification adjustment instruction of the OpenStack cloud platform to replace the product specification of the target cloud host with the first product specification instance, that is, replace the specification that does not contain GPU information back to the original first product specification instance, that is, the original specification that contains GPU information.

[0048] As an optional implementation method, the above situation can be summarized into the following steps: select the cloud host and target storage pool to be migrated, generate a migration record, and save the network related information of the cloud host in the record, determine whether the storage pool where the current cloud host is located supports cross-storage migration capability, and if not, use Figure 3 If supported, determine whether the cloud host is a GPU cloud host. If not, follow Figure 2 The method completes the cross-storage migration of the cloud host. If it is a GPU host, create a new instance without GPU information and uninstall the GPU card. Clone the system disk and data disk in the source storage pool and migrate the cloned volume to the target storage pool. Create a network port in the target storage pool and create a target cloud host based on the cloned system disk and network port. Mount the cloned data disk at the same time, uninstall the network port on the source cloud host and modify the network port in the target cloud host to the network port of the source cloud host. Uninstall the elastic public IP of the source cloud host and bind the elastic IP to the target cloud host. Determine whether it is a GPU cloud host again. If it is a GPU cloud host, update the cloud host product specification information to the original specification instance with GPU parameters. If not, check whether the migration is successful. If successful, destroy the source host and update the migration record information. If failed, perform the migration rollback operation.

[0049] Through the above steps, the cloud management platform implements a mechanism to temporarily unload GPU resources during migration and reconfigure GPU resources after migration is completed, ensuring the smooth progress of GPU cloud host cross-storage migration, while avoiding storage compatibility issues and technical difficulties that may be encountered in direct migration of cloud hosts containing GPUs. This mechanism is a part of the entire cloud host cross-storage migration method specially designed for GPU cloud hosts, ensuring that the business system can stably and efficiently perform storage migration in a hybrid cloud environment.

[0050] In the embodiment of the present application, the most suitable migration path is intelligently selected according to whether the source storage pool and the target storage pool support the storage volume migration function. When both storage pools support storage volume migration, this function is directly used for efficient migration. When any storage pool does not support it, an indirect migration strategy is adopted to complete data replication by creating an auxiliary cloud host and an empty storage volume to ensure the smooth completion of the migration task. Whether it is direct migration or indirect migration, the target disk of the source cloud host will be cloned in the source storage pool to generate a clone storage volume to ensure the consistency and integrity of the data. For indirect migration, the data of the clone storage volume will also be copied to the empty storage volume in the target storage pool to further ensure the accuracy of the data. When creating the target cloud host in the target storage pool, a first network port with the same configuration as the source network port of the source cloud host will be created to ensure that the migrated cloud host is consistent with the original host in network configuration and does not affect the normal operation of the business. By creating an auxiliary cloud host and an empty storage volume in the target storage pool to handle the situation where direct migration is not supported, the resources of the target storage pool are effectively utilized to avoid unnecessary waste of resources, thereby solving the technical problems of the traditional virtual machine migration solution being cumbersome, high labor cost and low efficiency.

[0051] Example 2

[0052] According to an embodiment of the present application, a method for cloud host migration across storage pools is also provided. It should be noted that the steps shown can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown, in some cases, the steps shown or described can be executed in an order different from that shown here. The method includes the following steps:

[0053] Step S202, obtaining multiple cloud hosts corresponding to multiple cloud platform applications to be migrated, and dividing the multiple cloud hosts according to the virtual private clouds corresponding to the respective cloud hosts to obtain multiple cloud host sets;

[0054] Step S204, determining the target number of cloud hosts to be migrated in parallel according to the storage bandwidth and throughput performance of the target storage pool;

[0055] Step S206: for each cloud host set, based on the target number, using any one of the cloud host migration methods across storage pools in Example 1, migrate the cloud hosts in the cloud host set to the target storage pool in parallel.

[0056] The following describes the various steps of the cloud host migration method across storage pools in combination with the specific implementation process.

[0057] First, identify and collect all cloud hosts corresponding to the cloud platform applications that need to be migrated.

[0058] According to the virtual private cloud information associated with each cloud host, these cloud hosts are classified to form different cloud host sets. This ensures that cloud hosts in the same virtual private cloud are processed simultaneously or sequentially, avoiding network configuration confusion and data consistency issues.

[0059] Analyze the storage bandwidth and throughput performance of the target storage pool to determine the maximum number of cloud hosts that can be processed simultaneously, that is, the target number of cloud hosts to be migrated in parallel. The purpose of this step is to maximize the efficiency of migration without affecting the performance of the target storage. The setting of the target number also needs to consider the performance of the source storage pool, network bandwidth, and the management capabilities of the cloud management platform to ensure that the entire migration process proceeds smoothly.

[0060] For each divided cloud host set, the migration task is started according to the previously determined number of parallel migration targets, and the cloud hosts in the set are migrated to the target storage pool at the same time. During the migration process, the migration process of each cloud host should follow the method of the above-mentioned embodiment 1, including data cloning, disk type conversion, new cloud host creation, network port and elastic IP migration and other steps. Through the scheduling and monitoring of the cloud management platform, the balanced use of resources during the migration process is ensured to avoid any single point resource overload, which affects the migration efficiency or the stability of the storage pool.

[0061] During the migration process, the performance indicators of the target storage pool, such as bandwidth usage and input and output operations per second, are continuously monitored, and the number of targets for parallel migration is dynamically adjusted according to the actual situation to maintain the best migration efficiency. The migration status of the cloud hosts in the cloud host collection is regularly checked to promptly identify and handle problems encountered during the migration, such as network failures and insufficient storage space. After the migration is completed, the data and configuration information of the target cloud host are verified to be consistent with the source cloud host to ensure the accuracy of the migration and the integrity of the data.

[0062] It should be noted that the steps in the cloud host migration method across storage pools in the embodiment of the present application correspond one-to-one to the implementation steps of the cloud host migration method across storage pools in Example 1. Since a detailed description has been given in Example 1, some details not reflected in this embodiment can be referred to Example 1 and will not be repeated here.

[0063] Example 3

[0064] According to an embodiment of the present application, a computer program product is also provided, which includes a computer program, wherein when the computer program is executed by a processor, the cloud host migration method across storage pools in Example 1 or Example 2 is implemented.

[0065] According to an embodiment of the present application, a non-volatile storage medium is also provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the cloud host migration method across storage pools in Example 1 or Example 2 by running the computer program.

[0066] According to an embodiment of the present application, a processor is also provided, which is used to run a computer program, wherein the computer program executes the cloud host migration method across storage pools in Example 1 or Example 2 when running.

[0067] According to an embodiment of the present application, an electronic device is also provided, which includes: a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the cloud host migration method across storage pools in Example 1 or Example 2 through the computer program.

[0068] Specifically, when the computer program is running, the following steps can be executed: obtaining the capability information of the source storage pool and the target storage pool corresponding to the source cloud host in the migration task; when both the source storage pool and the target storage pool support the storage volume migration function, cloning the target disk of the source cloud host in the source storage pool to obtain the cloned storage volume, and creating a first network port with the same configuration as the source network port of the source cloud host; migrating the cloned storage volume to the target storage pool, and creating a target cloud host in the target storage pool based on the cloned storage volume and the first network port, wherein the target disk includes at least: a system disk; when the source storage pool and / or the target storage pool do not support the storage volume migration function, creating an auxiliary cloud host in the target storage pool, and creating an empty storage volume with the same size as the target disk under the auxiliary cloud host; cloning the target disk in the source storage pool to obtain the cloned storage volume, and copying the data in the cloned storage volume to the empty storage volume to obtain the target storage volume; creating a first network port with the same configuration as the source network port of the source cloud host, and creating a target cloud host in the target storage pool based on the target storage volume and the first network port.

[0069] As an optional implementation, the electronic device may be in the form of a mobile terminal, a computer terminal or a similar computing device. Figure 4 The hardware structure block diagram of an electronic device for implementing a cloud host migration method across storage pools is shown. Figure 4 As shown, the electronic device 40 may include one or more (402a, 402b, ..., 402n are used to illustrate) processors 402 (the processor 402 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 404 for storing data, and a transmission device 406 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 4 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 4 More or fewer components as shown, or with Figure 4 Different configurations shown.

[0070] It should be noted that the one or more processors 402 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the electronic device 40. As involved in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0071] The memory 404 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the cloud host migration method across storage pools in the embodiment of the present application. The processor 402 executes various functional applications and data processing by running the software programs and modules stored in the memory 404, that is, realizing the vulnerability detection method of the above-mentioned application. The memory 404 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 404 may further include a memory remotely arranged relative to the processor 402, and these remote memories may be connected to the electronic device 40 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0072] The transmission device 406 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the electronic device 40. In one example, the transmission device 406 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 406 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0073] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the electronic device 40 .

[0074] The serial numbers of the above embodiments are only for description and do not represent the advantages or disadvantages of the embodiments.

[0075] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0076] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0077] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0078] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, 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 in the form of software functional units.

[0079] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0080] The above are only preferred implementations of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.< / ip> < / name> < / az> < / name> < / az>

Claims

1. A cloud host migration method across storage pools, applied to a cloud management platform, characterized in that: include: Obtain the capacity information of the source storage pool and target storage pool corresponding to the source cloud host in the migration task; In the case where both the source storage pool and the target storage pool support the storage volume migration function, the target disk of the source cloud host is cloned in the source storage pool to obtain a cloned storage volume, and a first network port with the same configuration as the source network port of the source cloud host is created; the cloned storage volume is migrated to the target storage pool, and a target cloud host is created in the target storage pool based on the cloned storage volume and the first network port, wherein the target disk includes at least: a system disk; In the case that the source storage pool and / or the target storage pool do not support the storage volume migration function, an auxiliary cloud host is created in the target storage pool, and an empty storage volume with the same size as the target disk is created under the auxiliary cloud host; the target disk is cloned in the source storage pool to obtain a cloned storage volume, and the data in the cloned storage volume is copied to the empty storage volume to obtain a target storage volume; a first network port with the same configuration as the source network port of the source cloud host is created, and a target cloud host is created in the target storage pool based on the target storage volume and the first network port.

2. The method according to claim 1, characterized in that Cloning the target disk of the source cloud host in the source storage pool to obtain a cloned storage volume, and creating a first network port with the same configuration as the source network port of the source cloud host, including: In response to a cloud host migration instruction input by the target object in the cloud management platform, calling a shutdown instruction of the OpenStack cloud platform to shut down the source cloud host; Calling a clone instruction of the OpenStack cloud platform to clone the target disk of the source cloud host in the source storage pool to obtain a clone storage volume; The port creation instruction of the OpenStack cloud platform is called to create a first network port with the same configuration as the source network port of the source cloud host in the virtual private cloud corresponding to the source cloud host, wherein the source network port corresponds to the virtual network card of the source cloud host.

3. The method according to claim 2, characterized in that Migrating the cloned storage volume to the target storage pool, and creating a target cloud host in the target storage pool based on the cloned storage volume and the first network port, including: Calling the cinderretype function of the OpenStack cloud platform to perform a disk type change operation on the cloned storage volume, so as to migrate the cloned storage volume to the target storage pool; Calling a host creation instruction of the OpenStack cloud platform to create a target cloud host according to the system disk in the cloned storage volume and the information of the first network port; Calling a port uninstall instruction of the OpenStack cloud platform to uninstall the source network port of the source cloud host, and calling a port add instruction of the OpenStack cloud platform to bind the first network port to the target cloud host; In the case where the target disk also includes a data disk, mounting the data disk in the cloned storage volume to the target cloud host; In the case where the source cloud host is configured with an elastic public IP, the IP uninstall instruction of the OpenStack cloud platform is called to uninstall the elastic public IP configured by the source cloud host, and the IP add instruction of the OpenStack cloud platform is called to bind the elastic public IP to the target cloud host.

4. The method according to claim 1, characterized in that: Copying the data in the cloned storage volume to the empty storage volume to obtain a target storage volume includes: Calling a target disk copy command to copy the data in the cloned storage volume to the empty storage volume to obtain the target storage volume, wherein the type of the target disk copy command includes at least one of the following: an rsync command that only copies data that actually occupies space, a dd command that copies the disk sector by sector, and a ddrescue command that automatically skips problem areas during data copying; A data consistency check is performed on the target storage volume and the clone storage volume. When the check passes, it is determined that the data replication is completed. When the check fails, the data in the target storage volume is deleted, and the data in the clone storage volume is re-copied to the target storage volume.

5. The method according to claim 4, characterized in that Creating a first network port configured identically to a source network port of the source cloud host, and creating a target cloud host in the target storage pool based on the target storage volume and the first network port, comprising: Calling a port creation instruction of the OpenStack cloud platform to create a first network port configured identically to a source network port of the source cloud host in a virtual private cloud corresponding to the source cloud host, wherein the source network port corresponds to a virtual network card of the source cloud host; Calling a host creation instruction of the OpenStack cloud platform to create a target cloud host according to the system disk in the target storage volume and the information of the first network port; Calling a port uninstall instruction of the OpenStack cloud platform to uninstall the source network port of the source cloud host, and calling a port add instruction of the OpenStack cloud platform to bind the first network port to the target cloud host; In the case where the target disk also includes a data disk, mounting the data disk in the target storage volume to the target cloud host; In the case where the source cloud host is configured with an elastic public IP, the IP uninstall instruction of the OpenStack cloud platform is called to uninstall the elastic public IP configured by the source cloud host, and the IP add instruction of the OpenStack cloud platform is called to bind the elastic public IP to the target cloud host.

6. The method according to claim 1, characterized in that The source cloud host is configured with a graphics processor (GPU), and the method further includes: Before cloning the target disk, calling a product specification query instruction of the OpenStack cloud platform to obtain a first product specification instance corresponding to the source cloud host; Calling a product specification creation instruction of the OpenStack cloud platform to create a second product specification instance excluding GPU information and having other product specifications that are the same as those in the first product specification instance; Invoke a product specification adjustment instruction of the OpenStack cloud platform to replace the product specification of the source cloud host with the second product specification instance; After the target cloud host is created, a product specification adjustment instruction of the OpenStack cloud platform is called to replace the product specification of the target cloud host with the first product specification instance.

7. The method according to claim 1, characterized in that The method further comprises: During the migration process of the source cloud host, target information is obtained and stored in the migration record, wherein the target information includes at least one of the following: a migration task identifier, a universally unique identifier of the source cloud host, a host name, status information, configuration information, virtual private cloud information, network port information, cloud hard disk information, elastic public network information, and specification information of a configured GPU; a universally unique identifier of the target cloud host, a host name, status information, configuration information, virtual private cloud information, network port information, cloud hard disk information, elastic public network information, and specification information of a configured GPU; an identifier, type, and capacity of the source storage pool; an identifier, type, and capacity of the target storage pool; and migration log information.

8. The method according to claim 7, characterized in that The method further comprises: Performing consistency check on the data and configuration information of the source cloud host and the data and configuration information of the target cloud host; If the verification passes, the migration is confirmed to be complete, and the source cloud host is destroyed; If the verification fails, it is determined that the migration has failed, and a rollback operation is performed on the configuration information of the source cloud host according to the migration record information, and the rollback log is stored in the migration record.

9. A cloud host migration method across storage pools, characterized in that: include: Acquire multiple cloud hosts corresponding to multiple cloud platform applications to be migrated, and divide the multiple cloud hosts according to virtual private clouds corresponding to each of the cloud hosts to obtain multiple cloud host sets; Determine the target number of cloud hosts to be migrated in parallel based on the storage bandwidth and throughput performance of the target storage pool; For each of the cloud host sets, the cloud hosts in the cloud host set are migrated in parallel to the target storage pool according to the target number and using the cross-storage pool cloud host migration method described in any one of claims 1 to 8.

10. An electronic device, characterized in that: include: A memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the cloud host migration method across storage pools as described in any one of claims 1 to 9 through the computer program.

Images