CN117827080A

CN117827080A - Disk migration method, related device and computer readable storage medium

Info

Publication number: CN117827080A
Application number: CN202211189924.1A
Authority: CN
Inventors: 刘亮; 张占军
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2022-09-28
Filing date: 2022-09-28
Publication date: 2024-04-05
Also published as: WO2024066640A1

Abstract

The application provides a disk migration method, related equipment and the like, wherein the attribute value of a partition to be migrated in a disk to be migrated (which does not belong to public cloud) of a user can be obtained, the expected utilization rate of a target partition (a partition for data migration of the partition to be migrated) input or selected by the user is obtained, then the attribute value of the target partition (such as the capacity of the target partition) is determined based on the attribute value of the partition to be migrated and the expected utilization rate of the target partition, then the target disk is deployed on the public cloud based on the attribute value of the target partition, the target partition is partitioned in the target disk, and finally the data of the partition to be migrated is migrated to the target partition. Therefore, after the disk migration is carried out, the utilization rate of the target partition is equal to the expected utilization rate of the user to the target partition, and if the expected utilization rate of the user to the target partition is moderate, the problem that the utilization rate of each partition of the disk on the cloud is too high or too low after the disk migration is carried out by the current user can be solved.

Description

Disk migration method, related device and computer readable storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a disk migration method, related devices, and a computer readable storage medium.

Background

With the rapid development of cloud computing technology in recent years, virtualization technology is mature, and more users want to migrate off-line hosts to public cloud Virtual Machines (VM), that is, migrate applications and data on off-line hosts to public cloud virtual machines, as shown in fig. 2, and users want to migrate applications and data on a physical server to public cloud virtual machines.

When a user migrates an offline host to a virtual machine, the user needs to purchase a disk from a public cloud and then migrate data in the disk in the offline host to the cloud disk. The partition of the disk in the offline host of the current user usually has the phenomenon of over-high or under-low utilization rate, so that after the disk migration, each partition of the disk on the cloud can also have over-high or under-low utilization rate, and further, the cost and the performance of the disk on the cloud are unbalanced.

Disclosure of Invention

The application provides a disk migration method, related equipment and a computer readable storage medium, which can solve the problem that the utilization rate of each partition of a disk on a cloud is too high or too low after a current user performs disk migration, and avoid the situation that the cost and the performance of the disk on the cloud are unbalanced.

In a first aspect, a disk migration method is provided, the method including the steps of: the cloud platform obtains an attribute value of a first partition in a disk to be migrated, and obtains an expected utilization rate of a second partition input or selected by a user, wherein the disk to be migrated does not belong to a public cloud, the second partition is a target partition of the first partition to be subjected to data migration, then the attribute value of the second partition is determined based on the attribute value of the first partition and the expected utilization rate of the second partition, the attribute value of the second partition comprises the capacity of the second partition, then the target disk is deployed on the public cloud based on the attribute value of the second partition, the target disk comprises the second partition, and finally the data of the first partition is migrated to the second partition.

Because the attribute value of the second partition in the target disk is determined by the cloud platform according to the attribute value of the first partition (i.e. the partition to be migrated) and the expected utilization rate of the second partition, after the cloud platform migrates the data of the partition to be migrated to the second partition, the utilization rate of the second partition is equal to the expected utilization rate of the second partition by the user. It can be understood that if the user input obtained by the cloud platform or the selected expected utilization rate of the second partition is moderate, the problem that the utilization rate of each partition of the disk on the cloud is too high or too low after the current user performs disk migration can be solved, and the situation that the cost and the performance of the disk on the cloud are unbalanced is avoided.

In one possible implementation, the attribute value of the first partition includes a capacity of the first partition and a utilization of the first partition.

In one possible implementation, the attribute value of the first partition includes the used capacity of the first partition, so that flexibility of the scheme may be improved.

In one possible implementation, the attribute value of the first partition further includes a type of the first partition, and the attribute value of the second partition further includes a type of the second partition, where the type of the first partition is a normal partition, PV or LV, and the normal partition is a main partition or a logical partition. In this way, the type of the second partition partitioned in the target disk can be kept consistent with the type of the first partition, and the user experience can be optimized.

In a second aspect, there is provided a disk migration apparatus, the apparatus comprising: the system comprises an acquisition module, a processing module, a deployment module and a migration module;

the system comprises an acquisition module, a storage module and a storage module, wherein the acquisition module is used for acquiring an attribute value of a first partition in a disk to be migrated, wherein the disk to be migrated does not belong to public cloud; the acquisition module is further used for acquiring the expected utilization rate of a second partition input or selected by a user, wherein the second partition is a target partition to be subjected to data migration of the first partition; the processing module is used for determining the attribute value of the second partition based on the attribute value of the first partition and the expected utilization rate of the second partition, wherein the attribute value of the second partition comprises the capacity of the second partition; the deployment module is used for deploying a target disk on the public cloud based on the attribute value of the second partition, wherein the target disk comprises the second partition; and the migration module is used for migrating the data of the first partition to the second partition.

In one possible implementation, the attribute value of the first partition includes a used capacity of the first partition.

In one possible implementation, the attribute value of the first partition further includes a type of the first partition, and the attribute value of the second partition further includes a type of the second partition, where the type of the first partition is a normal partition, PV or LV, and the normal partition is a main partition or a logical partition.

With respect to the magnetic disk migration apparatus provided in the second aspect and the relevant advantages and descriptions of any implementation manner of the second aspect, reference may be made to the foregoing first aspect and the relevant advantages and descriptions of any implementation manner of the first aspect, which are not repeated herein.

In a third aspect, a computing device is provided, the computing device comprising a processor and a memory; the processor of the computing device is configured to execute instructions stored in the memory of the computing device to cause the computing device to implement a method as provided by the first aspect or any possible implementation of the first aspect.

In a fourth aspect, a computer readable storage medium is provided, the computer readable storage medium comprising computer program instructions for implementing the method as provided by the above-mentioned first aspect or any possible implementation of the first aspect, when the computer program instructions are executed by a computing device.

In a fifth aspect, there is provided a computer program product comprising a computer program which, when read and executed by a computing device, causes the computing device to perform the method as provided above in the first aspect or any of the possible implementations of the first aspect.

Drawings

FIG. 1 is a schematic diagram of a magnetic disk as exemplarily shown in the present application;

FIG. 2 is a schematic diagram of an application scenario involved in the present application;

FIG. 3 is a schematic diagram of another application scenario to which the present application relates;

FIG. 4 is a schematic diagram of a disk migration system according to the present application;

FIG. 5 is a schematic flow chart of a disk migration method provided in the present application;

FIG. 6 is a schematic diagram of a process for performing disk migration as exemplary shown herein;

FIG. 7 is a schematic diagram of another exemplary process for performing disk migration, as illustratively shown herein;

FIG. 8 is a schematic diagram of a disk migration apparatus according to the present application;

FIG. 9 is a schematic diagram of a computing device provided herein;

fig. 10 is a schematic structural diagram of a computing device cluster provided in the present application.

Detailed Description

In order to facilitate clear understanding of the technical solutions provided in the present application, some terms and terminology related to the technical solutions provided in the present application are explained first.

Normal partition, physical Volume (PV), and Logical Volume (LV):

conventional disk management mechanisms typically partition a disk, then format the partition into a File System (FS), and finally mount the partition for use. However, this conventional disk management mechanism has a problem that when the partition size is insufficient, the partition cannot be dynamically stretched to perform partition expansion. The partitions after the disk is divided and formatted into the file system by the conventional disk management mechanism are the normal partitions, including the main partition formatted into the file system, the logical partition formatted into the file system which is divided on the basis of the extended partition, and the like.

In order to solve the above-mentioned problems of the conventional disk management mechanism, a logical volume management (logical volume manager, LVM) technology is produced in the industry, and the LVM is a mechanism for managing disks, and its working principle is that the underlying disk is encapsulated and then presented to an upper layer application in an LV manner, where the LV is used to replace a common partition in the conventional disk management mechanism. The biggest feature of LVM is that it can dynamically manage the disk, because the LV size is dynamically adjustable, and no existing data is lost.

More specifically, in the LVM, a plurality of disks, a plurality of partitions without formatting a file system, which are divided from the plurality of disks, or a plurality of partitions without formatting a file system, which are divided from the same disk, are formatted into PV, then a Volume Group (VG) is created, PV is added to the VG, then an LV is created on the basis of VG, and the created LV is used after formatting the file system.

In practical applications, a disk may include only a normal partition, only a PV, or both a normal partition and a PV. Referring to fig. 1, fig. 1 is a schematic diagram of a disk including normal partitions and PV exemplarily shown in the present application, and in fig. 1, a disk 100A includes normal partitions 1 and PV1, and a disk 100B includes normal partitions 2 and PV2, wherein LV1 and LV2 are LV created on VG composed of PV1 and PV 2.

With the rapid development of cloud computing technology, more and more users want to migrate applications and data on off-line hosts to a public cloud virtual machine, as shown in fig. 2, users want to migrate applications and data on a physical server to a public cloud virtual machine, or migrate applications and data on one virtual machine to another virtual machine, as shown in fig. 3, users want to migrate applications and data on a public cloud a virtual machine A2 to a public cloud B virtual machine B1.

When a user migrates applications and data on an off-line host to a virtual machine, the user needs to purchase a disk from a public cloud and then migrate data in the disk in the off-line host to the on-cloud disk. The partitions (including normal partitions, LV, PV) of the disk in the offline host (such as the physical server shown in fig. 2 and the virtual machine A2 shown in fig. 3) of the current user generally have the phenomenon that the utilization rate is too high (such as 90%) or too low (such as 20%), so that after the disk migration is performed, the utilization rate of each partition of the disk on the cloud is too high or too low, and the utilization rate of each partition of the disk is too high or too low, which in turn causes unbalanced cost and performance of the disk on the cloud, for example, the partition utilization rate is too high, resulting in lower throughput of the partition, and the partition utilization rate is too low, resulting in waste of disk space.

In order to solve the above problems, the present application provides a disk migration system, a method, a related device, and the like, and the disk migration system, the method, the related device, and the like provided in the present application are described in detail below with reference to corresponding drawings.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a disk migration system provided in the present application, as shown in fig. 4, the system includes: the terminal device 410, the host 420 to be migrated, and the public cloud data center 440, and the terminal device 410, the host 420 to be migrated, and the public cloud data center 440 are connected through the network 430. The host to be migrated includes a disk to be migrated, where the disk to be migrated may be a soft disk (soft disk), or may be a hard disk such as a Hard Disk Drive (HDD), and the network 430 may be a wide area network, a local area network, a point-to-point connection, or any combination thereof.

The terminal device 410 may be an electronic device such as a personal computer, a tablet computer, or a mobile notebook, and fig. 4 illustrates the terminal device 410 as a personal computer, but this is not particularly limited in this application.

The host 420 to be migrated may be a general physical server, such as an ARM server or an X86 server, and may also be a virtual machine, and fig. 4 illustrates the host 420 to be migrated as a physical server, which is not specifically limited in this application.

The public cloud data center 440 may provide shared resource services to users, which may include object storage services (object storage service, OBS), cloud phone (closed phone) services, content delivery network services (content delivery network, CDN), cloud backup services (cloud backup and recovery, CBR), data management services (data admin service, DAS), and so forth, without limiting the types of shared resource services that may be provided by the public cloud data center 440.

Illustratively, the public cloud data center 440 may include a cloud platform 441 and a hardware resource pool 442, and it should be understood that the division manner shown in fig. 4 is used for illustration, and the public cloud data center 440 may be divided in other manners, which are not limited in this application.

The cloud platform 441 may be a general physical server, for example, an ARM server or an X86 server, or may be a virtual machine implemented in combination with network function virtualization (network functions virtualization, NFV) technology, or the cloud platform 441 may be a virtual machine or a physical server in the hardware resource pool 442, which is not specifically limited in this application.

The hardware resource pool 442 may include at least one physical server (fig. 4 illustrates that the resource pool includes the physical server 1 and the physical server 2 as an example), where the physical server may be a general physical server, such as an ARM server or an X86 server, which is not specifically limited in this application. The physical servers in the hardware resource pool 442 may communicate with other physical servers or cloud platforms 441 over an internal network. Wherein each physical server includes at least hardware resources (e.g., physical server 1 includes hardware resources 1, physical server 2 includes hardware resources 2) and an operating system (e.g., physical server 1 includes operating system 1, physical server 2 includes operating system 2), some physical servers may also include multiple virtual machines (e.g., physical server 1 includes virtual machine 11 and virtual machine 12), and multiple virtual machines in a physical server may share the operating system and hardware resources in the physical server.

The hardware resources (such as the hardware resource 1 and the hardware resource 2) may include various available hardware resources of a physical server, such as the processor 1, the memory 1, the peripheral component interconnect standard (peripheral component interconnect, PCI) device 1, and the like, and may also include other hardware resources that may be required by a user, which is not specifically limited in this application. The operating systems (such as the operating system 1 and the operating system 2) may be operating systems applicable to a virtual machine or a physical server, such as an android (android) operating system, a windows operating system, a linux operating system, and the like, which are not particularly limited in this application. It should be noted that the operating system may be an official complete operating system, or may be an operating system in which individual driving modules of the official complete operating system are modified to adapt to an operation manner of the server, which is not specifically limited in this application. Also, the number of physical servers, the number of virtual machines, the kind and the number of hardware resources shown in fig. 4 are only for illustration, and the present application is not limited in detail.

In this embodiment of the present application, the cloud platform 441 may obtain an attribute value (such as a capacity and a utilization rate of a partition to be migrated) of a partition to be migrated in a disk to be migrated of a user, and obtain an expected utilization rate of a target partition (a partition for data migration of the partition to be migrated) input or selected by the user through the terminal device 410, then determine an attribute value (such as a capacity of the target partition) of the target partition based on the attribute value of the partition to be migrated and the expected utilization rate of the target partition, then deploy (create) the target disk on a public cloud based on the attribute value of the target partition, and partition the target partition in the target disk, and finally migrate the data of the partition to be migrated to the target partition, thereby implementing disk migration.

In a possible embodiment, the cloud platform 441 may obtain a partition migration instruction input by a user, where the instruction may include an identifier of a partition to be migrated and a desired utilization rate of a target partition, then scan the partition to be migrated according to the identifier of the partition to be migrated in the partition migration instruction, obtain an attribute value of the partition to be migrated, obtain the desired utilization rate of the target partition from the instruction, and then perform a subsequent operation, and finally migrate data of the partition to be migrated to the target partition.

In one possible embodiment, after the cloud platform 441 divides the target partition in the target disk, a notification may be sent to the terminal device 410 of the user, notifying that the target partition has been divided in the target disk, and after the user sees the notification, the user may send a data migration instruction including an identifier of the partition to be migrated to the cloud platform 441 through the terminal device 410, and instruct the cloud platform 441 to migrate the data of the partition to be migrated to the target partition.

It should be understood that the above-described process is by way of example only and the present application is not particularly limited.

It can be appreciated that, since the attribute value of the target partition in the target disk is determined according to the attribute value of the partition to be migrated and the expected utilization rate of the target partition, after the data of the partition to be migrated is migrated to the target partition, the utilization rate of the target partition is equal to the expected utilization rate of the target partition by the user. It can be appreciated that if the expected utilization rate of the second partition, which is input or selected by the user and obtained by the cloud platform 441, is moderate, the problem that the utilization rate of each partition of the disk on the cloud is too high or too low after the current user migrates the disk can be solved, so as to avoid the situation that the cost and the performance of the disk on the cloud are unbalanced.

In particular implementations, cloud platform 441 may provide a configuration interface to a user that may be used to obtain attribute values for partitions to be migrated in a disk to be migrated, as well as to obtain desired utilization of a target partition entered or selected by the user. For example, the configuration interface may receive a partition migration instruction sent by the user through the terminal device 410, and then execute the partition migration instruction to scan the partition to be migrated to obtain the attribute value of the partition to be migrated, and for example, the configuration interface may receive the attribute value of the partition to be migrated sent by the user through the terminal device 410.

In a specific implementation, the configuration interface may be a console (console) or an application program interface (application program interface, API) of the cloud platform 441, where the console may be specifically an application program or a web page for the user to interact with the cloud platform 441, and it should be understood that the foregoing examples are for illustration, and the application is not limited specifically.

In order to more clearly understand the process of performing disk migration by the disk migration system provided in the present application shown in fig. 4, the following uses the cloud platform 441 as an execution body, and the process is described in detail with reference to the flowchart shown in fig. 5.

Referring to fig. 5, fig. 5 is a schematic flow chart of a disk migration method provided in the present application, as shown in fig. 5, the method may include the following steps:

s501: the cloud platform 441 obtains an attribute value of a first partition in a disk to be migrated, where the disk to be migrated does not belong to a public cloud.

S502: the cloud platform 441 obtains the expected utilization rate of a second partition input or selected by the user, where the second partition is a target partition to be subjected to data migration by the first partition.

S503: cloud platform 441 determines an attribute value for a second partition based on the attribute value for the first partition and the desired utilization of the second partition, wherein the attribute value for the second partition includes a capacity of the second partition.

S504: the cloud platform 441 deploys the target disk on the public cloud based on the attribute value of the second partition, and divides the second partition in the target disk.

S505: cloud platform 441 migrates the data of the first partition to the second partition.

The steps shown in fig. 5 are described below.

In S501, the disk to be migrated may be one disk or multiple disks, and the disk to be migrated may be a floppy disk or an HDD, where the disk to be migrated generally includes multiple partitions, and the multiple partitions may be all normal partitions, and the multiple partitions may also be partially normal partitions and partially PV, and the multiple partitions may also include LV partitioned on PV, taking the disk 100A and the disk 100B shown in fig. 1 as an example of the disk to be migrated, it can be seen that the disk to be migrated includes 6 partitions: general partition 1, general partition 2, PV1, PV2, LV1, and LV2, wherein LV1 and LV2 are two LV divided on the basis of PV1 and PV 2.

The first partition is the partition to be migrated, the first partition may be any partition among a plurality of partitions included in the disk to be migrated, and the type of the first partition may be a common partition, a PV or an LV.

In one possible embodiment, the attribute values of the first partition acquired by the cloud platform 441 include: the capacity of the first partition and the utilization of the first partition.

In another possible embodiment, the attribute values of the first partition acquired by the cloud platform 441 include: the used capacity of the first partition, it will be appreciated, is equal to the amount of data stored in the first partition.

In yet another possible embodiment, the attribute value of the first partition acquired by the cloud platform 441 may include a type of the first partition in addition to the capacity of the first partition and the utilization rate of the first partition, or the attribute value of the first partition may include a type of the first partition in addition to the used capacity of the first partition.

In a specific implementation, the cloud platform 441 may display an input box or a control for inputting the attribute value of the first partition to the user through the configuration interface, so that the user may input the attribute value of the first partition, or may display some partition attribute values, such as 50G, 60G, etc., to the user through the configuration interface, so that the user may select some attribute values from the displayed partition attribute values as the attribute value of the first partition.

In S502, the cloud platform 441 may display an input box or a control for the user to input the desired utilization rate of the second partition through the configuration interface, so that the user may input the desired utilization rate of the second partition, and may display some desired utilization rates, such as 50%, 60%, etc., through the configuration interface, so that the user may select one desired utilization rate from the displayed desired utilization rates as the desired utilization rate of the second partition.

In S503, in the case where the attribute value of the first partition includes the capacity of the first partition and the utilization of the first partition, the cloud platform 441 may determine: capacity of the second partition = capacity of the first partition/utilization of the first partition/desired utilization of the second partition; in the case where the attribute value of the first partition includes the used capacity of the first partition, the cloud platform 441 may determine: capacity of the second partition = used capacity of the first partition/desired utilization of the second partition; in the case where the attribute value of the first partition further includes the type of the first partition, cloud platform 441 may determine: the attribute value of the second partition also includes a type of the second partition, the type of the second partition being the same as the type of the first partition.

In S504, the cloud platform 441 may first determine the capacity of the target disk based on the attribute value of the second partition, then purchase the target disk based on the determined capacity of the target disk, and deploy the target disk on the public cloud. Specifically, the capacity of the target disk is greater than or equal to the capacity of the second partition.

After the cloud platform 441 deploys the target disk, a region may be partitioned in the target disk as the second partition, where the capacity of the region is equal to the capacity of the second partition. If the attribute value of the second partition determined by the cloud platform 441 in S503 does not include the type of the second partition, then the second partition partitioned by the cloud platform 441 in the target disk may be any type of partition, such as a normal partition, LV, and if the attribute value of the second partition determined by the cloud platform 441 in S503 includes the type of the second partition, then the second partition partitioned by the cloud platform 441 in the target disk is a partition of a corresponding type, for example, assuming that the type of the second partition determined by the cloud platform 441 in S503 is a normal partition, then the second partition partitioned by the cloud platform 441 in the target disk is a normal partition.

In a specific implementation, the common partition can be obtained by dividing the target disk through a traditional disk management mechanism, and the LV can be obtained by dividing the target disk through an LVM.

In S505, it can be understood that, after migrating all data of the first partition to the second partition, the cloud platform 441 migrates the entire data of the first partition to the second partition, the utilization of the second partition=the desired utilization of the second partition.

In a specific implementation, the cloud platform 441 may receive a data migration instruction input by a user and including an identifier of the first partition, and then migrate all data of the first partition to the second partition according to the data migration instruction.

In the embodiment described above, the first partition is described as being used as any one partition of a plurality of partitions included in the to-be-migrated magnetic disk, and in a specific implementation, the first partition may also be used as any one partition of a plurality of partitions included in the to-be-migrated magnetic disk.

In the case that the first partition is a plurality of partitions, in S501, the obtaining an attribute value of the first partition refers to obtaining an attribute value of each partition of the plurality of partitions included in the first partition, where the attribute value of each partition corresponds to a capacity of the partition, a utilization rate of the partition, an used capacity of the partition, a type of the partition, and so on. In S502, the second partition is also a plurality of partitions, the plurality of partitions in the second partition and the plurality of partitions in the first partition are in a one-to-one correspondence, and taking the ith partition in the plurality of partitions included in the second partition as an example, the partition is a target partition to be subjected to data migration in the ith partition in the plurality of partitions included in the first partition, and in S502, the obtaining the expected utilization rate of the second partition input or selected by the user refers to obtaining the expected utilization rate of each partition in the plurality of partitions included in the second partition input or selected by the user. In S503, determining the attribute value of the second partition based on the attribute value of the first partition and the expected utilization rate of the second partition refers to determining the attribute value of the corresponding partition in the plurality of partitions included in the second partition based on the attribute value of each partition in the plurality of partitions included in the first partition and the expected utilization rate of the partition. In S504, the deploying the target disk on the public cloud based on the attribute values of the second partitions and dividing the second partitions in the target disk refers to deploying the target disk on the public cloud based on the attribute values of all the second partitions and dividing all the second partitions in the target disk. In S505, the migration of the data of the first partition to the second partition refers to migration of the data of all the partitions in the first partition to the corresponding partitions in the second partition.

In order to facilitate a clearer understanding of the technical solutions provided in the present application, the following description will be given with two detailed examples.

First, taking the disk 600 shown in fig. 6 as a disk to be migrated, the first partition 1 is a normal partition 1 in the disk 600, the first partition 2 is a normal partition 2 in the disk 600, the capacity of the normal partition 1 is 120G, the capacity of the normal partition 2 is 80G, the utilization rate of the normal partition 1 is 80%, and the utilization rate of the normal partition 2 is 40% as an example.

Then in S501, the attribute value of the first partition 1 acquired by the cloud platform 441 includes: the capacity is 120G, the utilization rate is 80%, and the acquired attribute values of the first partition 2 include: the capacity is 80G, and the utilization rate is 40%.

Assume that in S502, the expected utilization of the second partition 1, which is input by the user and obtained by the cloud platform 441, is 60% and the expected utilization of the second partition 2 is 50%, where the second partition 1 is a target partition of the first partition 1 to be subjected to data migration, and the second partition 2 is a target partition of the first partition 2 to be subjected to data migration.

Based on the above, in S503, the cloud platform 441 may determine: capacity of the second partition 1=capacity of the first partition 1/desired utilization of the first partition 1=120 g×80%/60% =160G, capacity of the second partition 2=capacity of the first partition 2/desired utilization of the second partition 2=80 g×40%/50% =64G.

Based on the above, in S504, the capacity of the target disk deployed by the cloud platform 441 on the public cloud is equal to or greater than the capacity of the second partition 1+the capacity of the second partition 2=160g+64g=224G. Taking the deployed target disk with the capacity of 224G as an example, the cloud platform 441 may divide the target disk into two parts 160G and 64G, where the part 160G is the second partition 1 and the part 64G is the second partition 2, see the target disk shown in fig. 6.

Based on the above, in S505, the cloud platform 441 may migrate data in the first partition 1 to the second partition 1 and data in the first partition 2 to the second partition 2. It will be appreciated that, since the capacity of the first partition 1 is 120G and the utilization of the first partition 1 is 80%, the cloud platform 441 may determine that the used capacity of the first partition 1=the capacity of the first partition 1=120g80% =96G, that is, the amount of data stored in the first partition 1 is 96G. Since the capacity of the second partition 1 is 160G, after the cloud platform 441 migrates the data in the first partition 1 to the second partition 1, the utilization of the second partition 1=the used capacity of the second partition 1/the capacity of the second partition 1=96G/160 g=60%, which is equal to the desired utilization of the second partition 1 input by the user. Similarly, after the cloud platform 441 migrates the data in the first partition 2 to the second partition 2, the utilization of the second partition 2 is equal to the desired utilization of the second partition 2 entered by the user.

Taking the disks 700A and 700B shown in fig. 7 as the disks to be migrated, the first partition 1 is LV1 shown in fig. 7, the first partition 2 is LV2 shown in fig. 7, the first partition 3 is PV1 shown in fig. 7, the first partition 4 is PV2 shown in fig. 7, the first partition 5 is the normal partition 1 shown in fig. 7, the first partition 6 is the normal partition 2 shown in fig. 7, the used capacity of lv1 is 30G, the used capacity of lv2 is 33G, the used capacity of pv1 is 36G, the used capacity of pv2 is 27G, the used capacity of normal partition 1 is 42G, and the used capacity of normal partition 2 is 39G as an example.

Then in S501, the attribute value of the first partition 1 acquired by the cloud platform 441 to the attribute value of the first partition 6 correspond to include: the used capacity of the first partition 1 is 30G, the type of the first partition 1 is LV, the used capacity of the first partition 2 is 33G, the type of the first partition 2 is LV, the used capacity of the first partition 3 is 36G, the type of the first partition 3 is PV, the used capacity of the first partition 4 is 27G, the type of the first partition 4 is PV, the used capacity of the first partition 5 is 42G, the type of the first partition 5 is a normal partition, the used capacity of the first partition 6 is 39G, and the type of the first partition 6 is a normal partition.

Assume that in S502, the expected utilization rates of the second partition 1 to the second partition 6, which are obtained by the cloud platform 441 and input by the user, are all 60%, where the second partition 1 is a target partition to be subjected to data migration by the first partition 1, the second partition 2 is a target partition to be subjected to data migration by the first partition 2, …, and the second partition 6 is a target partition to be subjected to data migration by the first partition 6.

Based on the above, in S503, the cloud platform 441 may determine: the capacity of the second partition 1 = used capacity of the first partition 1/desired utilization of the second partition 1 = 30G/60% = 50G, the capacity of the second partition 2 = used capacity of the first partition 2/desired utilization of the second partition 2 = 33G/60% = 55G, the capacity of the second partition 3 = used capacity of the first partition 3/desired utilization of the second partition 3 = 36G/60% = 60G, the capacity of the second partition 4 = used capacity of the first partition 4/desired utilization of the second partition 4 = 27G/60% = 45G, the capacity of the second partition 5 = used capacity of the first partition 5/desired utilization of the second partition 5 = 42G/60% = 70G, the capacity of the second partition 6 = used capacity of the first partition 6/desired utilization of the second partition 6 = 39G/60% = 65G, the second partition 1 is of the same type as the first partition 1, and thus the second partition 1 is of the same type as the first partition 1, the second partition 3 and the second partition 4 is of the same type as the LV type of the second partition 6.

Based on the above, in S504, the cloud platform 441 may deploy a target disk with a capacity equal to or greater than the capacity of the second partition 3, the capacity partition of the second partition 4, the capacity of the second partition 5, the capacity of the second partition 6=60g+45g+70g+65g=240G. Taking the deployed target disk as 240G as an example, the cloud platform 441 may then divide the target disk by the capacities and types of the second partition 1 to the second partition 6, and divide the second partition 1 to the second partition 6 from the target disk. Specifically, the target disk may be divided into four parts of 60G, 45G, 70G, 65G, wherein the part of 60G is processed into the second partition 3 of type PV, the part of 45G is processed into the second partition 4 of type PV, the part of 70G is processed into the second partition 5 of type ordinary partition, the part of 65G is processed into the second partition 6 of type ordinary partition, and the first partition 1 of type LV of capacity 50G and the second partition 2 of type LV of capacity 55G are divided on the basis of the second partition 3 and the second partition 4, see the target disk shown in fig. 7.

Based on the above, in S505, the cloud platform 441 migrates the data in the first partition 1 to the second partition 1, the data in the first partition 2 to the second partition 2, …, and the data in the first partition 6 to the second partition 6. It will be appreciated that since the used capacity of the first partition 1 is 30G, that is, the amount of data stored in the first partition 1 is 96G. Since the capacity of the second partition 1 is 50G, after migrating the data in the first partition 1 to the second partition 1, the utilization of the second partition 1=the used capacity of the second partition 1/the capacity of the second partition 1=30G/50 g=60%, which is equal to the desired utilization of the second partition 1 input by the user. Similarly, after the data in the first partition 2 is migrated to the second partition 2, the utilization of the second partition 2 is equal to the expected utilization of the second partition 2 input by the user, …, and after the data in the first partition 6 is migrated to the second partition 6, the utilization of the second partition 6 is equal to the expected utilization of the second partition 6 input by the user.

In summary, in the disk migration method provided by the present application, the cloud platform 441 may obtain the attribute value of the partition to be migrated in the disk to be migrated (not belonging to the public cloud) of the user, and obtain the expected utilization rate of the target partition (the partition for data migration of the partition to be migrated) input or selected by the user, then determine the attribute value of the target partition (such as the capacity of the target partition) based on the attribute value of the partition to be migrated and the expected utilization rate of the target partition, then deploy the target disk on the public cloud based on the attribute value of the target partition, and divide the target partition in the target disk, and finally migrate the data of the partition to the target partition. Thus, the utilization rate of the target partition after the disk migration is enabled to be equal to the expected utilization rate of the user on the target partition. It can be understood that if the obtained user input or the selected expected utilization rate of the second partition is moderate, the problem that the utilization rate of each partition of the disk on the cloud is too high or too low after the disk migration of the current user is performed can be solved, and the situation that the cost and the performance of the disk on the cloud are unbalanced is avoided.

It can be further seen that in the disk migration method provided by the present application, the type of the target partition partitioned in the target disk may be kept consistent with the type of the partition to be migrated, so that user experience may be optimized.

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not limit the implementation process of the embodiment of the present application in any way.

The disc migration method and the disc migration system provided by the application are described in detail above, and based on the same inventive concept, the disc migration device and the computing device provided by the application are further described below.

Referring to fig. 8, fig. 8 is a schematic structural diagram of a disk migration apparatus 800 provided in the present application, where the apparatus 800 may be deployed in the cloud platform 441 shown in fig. 4. As shown in fig. 8, the apparatus 800 includes: acquisition module 810, processing module 820, deployment module 830, and migration module 840. The functions of the respective modules of the disk migration apparatus 800 are exemplarily described below. It should be understood that the functions of the respective modules described below by way of example are only functions that the disk migration apparatus 800 may have in some embodiments of the present application, and the present application is not limited to the functions that the respective modules have.

The obtaining module 810 is configured to obtain an attribute value of a first partition in a disk to be migrated, where the disk to be migrated does not belong to a public cloud.

The obtaining module 810 is further configured to obtain a desired utilization of a second partition input or selected by a user, where the second partition is a target partition of the first partition to be subjected to data migration.

And a processing module 820 configured to determine an attribute value of the second partition based on the attribute value of the first partition and the expected utilization of the second partition, wherein the attribute value of the second partition includes a capacity of the second partition.

The deployment module 830 is configured to deploy a target disk on the public cloud based on the attribute value of the second partition, where the target disk includes the second partition.

The migration module 840 is configured to migrate data of the first partition to the second partition.

In one possible embodiment, the attribute value of the first partition includes a capacity of the first partition and a utilization of the first partition.

In one possible embodiment, the attribute value of the first partition includes a used capacity of the first partition.

In one possible embodiment, the attribute value of the first partition further includes a type of the first partition, and the attribute value of the second partition further includes a type of the second partition, wherein the type of the first partition is a normal partition, PV or LV, and the normal partition is a main partition or a logical partition.

The acquiring module 810, the processing module 820, the deploying module 830 and the migrating module 840 may be implemented by software, or may be implemented by hardware. Illustratively, an implementation of the processing module 820 is described next with respect to the processing module 820. Similarly, the implementation of the acquisition module 810, the deployment module 830, and the migration module 840 may refer to the implementation of the processing module 820.

Module as an example of a software functional unit, the processing module 820 may include code that runs on a computing instance. The computing instance may include at least one of a physical server (computing device), a virtual machine, and a container, among others. Further, the above-described computing examples may be one or more. For example, processing module 820 may include code that runs on multiple hosts/virtual machines/containers. It should be noted that, multiple hosts/virtual machines/containers for running the code may be distributed in the same region (region), or may be distributed in different regions. Further, multiple hosts/virtual machines/containers for running the code may be distributed in the same availability zone (availability zone, AZ) or may be distributed in different AZs, each AZ comprising a data center or multiple geographically close data centers. Wherein typically a region may comprise a plurality of AZs.

Also, multiple hosts/virtual machines/containers for running the code may be distributed in the same virtual private cloud (virtual private cloud, VPC) or in multiple VPCs. In general, one VPC is disposed in one region, and a communication gateway is disposed in each VPC for implementing inter-connection between VPCs in the same region and between VPCs in different regions.

Module as an example of a hardware functional unit, the processing module 820 may include at least one computing device. Alternatively, the processing module 820 may be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (programmable logic device, PLD), etc. The PLD may be implemented as a complex program logic device (complex programmable logical device, CPLD), a field-programmable gate array (FPGA), a general-purpose array logic (generic array logic, GAL), or any combination thereof.

The processing module 820 may include multiple computing devices distributed across the same region or across different regions. The processing module 820 may include multiple computing devices distributed among the same AZ or among different AZs. Likewise, multiple computing devices included in processing module 820 may be distributed across the same VPC or across multiple VPCs. Wherein the plurality of computing devices may be any combination of computing devices such as servers, ASIC, PLD, CPLD, FPGA, and GAL.

It should be noted that, in other embodiments, the processing module 820 may be configured to perform any step in the disk migration method provided in the present application shown in fig. 5, the obtaining module 810 may be configured to perform any step in the disk migration method provided in the present application shown in fig. 5, the deployment module 830 may be configured to perform any step in the disk migration method provided in the present application shown in fig. 5, the migration module 840 may be configured to perform any step in the disk migration method provided in the present application shown in fig. 5, and the steps responsible for implementation of the obtaining module 810, the processing module 820, the deployment module 830 and the migration module 840 may be specified according to need, and the obtaining module 810, the processing module 820, the deployment module 830 and the migration module 840 implement different steps in the disk migration method provided in the present application shown in fig. 5, respectively, to implement all functions of the disk migration device 800.

The present application also provides a computing device 900, where the computing device 900 may be the cloud platform 441 shown in fig. 4, for deploying the disk migration apparatus 800 shown in fig. 8. As shown in fig. 9, the computing device 900 includes: bus 902, processor 904, memory 906, and communication interface 908. Communication between the processor 904, the memory 906, and the communication interface 908 is via the bus 902. Computing device 900 may be a server or a terminal device. It should be understood that the present application is not limited to the number of processors, memories in computing device 900.

Bus 902 may be a PCI bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, or the like. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one line is shown in fig. 9, but not only one bus or one type of bus. Bus 902 may include a path to transfer information between various components of computing device 900 (e.g., memory 906, processor 904, communication interface 908).

The processor 904 may include any one or more of a central processing unit (central processing unit, CPU), a graphics processing unit (graphics processing unit, GPU), a Microprocessor (MP), or a digital signal processor (digital signal processor, DSP).

The memory 906 may include volatile memory (RAM), such as random access memory (random access memory). The processor 904 may also include non-volatile memory (ROM), such as read-only memory (ROM), flash memory, HDD, or solid state disk (solid state drive, SSD).

The memory 906 stores executable program codes, and the processor 904 executes the executable program codes to implement the functions of the aforementioned acquisition module 810, the processing module 820, the deployment module 830, and the migration module 840, respectively, so as to implement the disk migration method provided in the present application as shown in fig. 5. That is, the memory 906 has instructions stored thereon for performing the disk migration method provided herein.

Communication interface 908 enables communication between computing device 900 and other devices or communication networks using a transceiver module such as, but not limited to, a network interface card, transceiver, etc.

The present application further provides a computing device cluster 1000, where the computing device cluster 1000 may be a cloud platform 441 shown in fig. 4, and is configured to deploy the disk migration apparatus 800 shown in fig. 8. The computing device cluster 1000 includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop, notebook, or smart phone.

As shown in fig. 10, the computing device cluster 1000 includes at least one computing device 900. The same instructions for performing the disk migration methods provided herein may be stored in memory 906 in one or more computing devices 900 in the computing device cluster 1000.

In some possible implementations, part of the instructions for performing the disk migration methods provided herein may also be stored separately in the memory 906 of one or more computing devices 900 in the computing device cluster 1000. In other words, a combination of one or more computing devices 900 may collectively execute instructions for performing the disk migration methods provided herein.

It should be noted that, the memory 906 in different computing devices 900 in the computing device cluster 1000 may store different instructions for performing part of the functions of the disk migration apparatus 800. That is, the instructions stored by the memory 906 in the different computing devices 900 may implement the functionality of one or more of the acquisition module 810, the processing module 820, the deployment module 830, and the migration module 840.

The present application also provides a computer program product comprising instructions, which may be software or a program product comprising instructions, capable of running on a computing device or being stored in any available medium. The computer program product, when executed on at least one computing device, causes the at least one computing device to perform the disk migration method provided herein.

The present application also provides a computer-readable storage medium that can be any available medium that can be stored by a computing device or a data storage device such as a data center containing 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), etc. The computer-readable storage medium includes instructions that instruct a computing device to perform the disk migration methods provided herein.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; these modifications or substitutions do not depart from the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method of disk migration, the method comprising:

the cloud platform acquires an attribute value of a first partition in a disk to be migrated, wherein the disk to be migrated does not belong to public cloud;

the cloud platform obtains the expected utilization rate of a second partition input or selected by a user, wherein the second partition is a target partition to be subjected to data migration of the first partition;

the cloud platform determines an attribute value of the second partition based on the attribute value of the first partition and the expected utilization rate of the second partition, wherein the attribute value of the second partition comprises the capacity of the second partition;

the cloud platform deploys a target disk on the public cloud based on the attribute value of the second partition, wherein the target disk comprises the second partition;

And the cloud platform migrates the data of the first partition to the second partition.

2. The method of claim 1, wherein the attribute values of the first partition include a capacity of the first partition and a utilization of the first partition.

3. The method of claim 1, wherein the attribute value of the first partition comprises a used capacity of the first partition.

4. A method according to any of claims 1 to 3, wherein the attribute value of the first partition further comprises a type of the first partition and the attribute value of the second partition further comprises a type of the second partition, wherein the type of the first partition is a normal partition, a physical volume PV or a logical volume LV, and the normal partition is a main partition or a logical partition.

5. A disk migration apparatus, characterized in that the disk migration apparatus comprises:

the device comprises an acquisition module, a storage module and a storage module, wherein the acquisition module is used for acquiring an attribute value of a first partition in a disk to be migrated, and the disk to be migrated does not belong to public cloud;

the acquisition module is further configured to acquire an expected utilization rate of a second partition input or selected by a user, where the second partition is a target partition to be subjected to data migration by the first partition;

The processing module is used for determining the attribute value of the second partition based on the attribute value of the first partition and the expected utilization rate of the second partition, wherein the attribute value of the second partition comprises the capacity of the second partition;

the deployment module is used for deploying a target disk on the public cloud based on the attribute value of the second partition, wherein the target disk comprises the second partition;

and the migration module is used for migrating the data of the first partition to the second partition.

6. The apparatus of claim 5, wherein the attribute value of the first partition comprises a capacity of the first partition and a utilization of the first partition.

7. The apparatus of claim 5, wherein the attribute value of the first partition comprises a used capacity of the first partition.

8. The apparatus of any of claims 5 to 7, wherein the attribute value of the first partition further comprises a type of the first partition and the attribute value of the second partition further comprises a type of the second partition, wherein the type of the first partition is a normal partition, PV or LV, and the normal partition is a main partition or a logical partition.

9. A computing device, the computing device comprising a processor and a memory;

a processor of the computing device is configured to execute instructions stored in a memory of the computing device to cause the computing device to perform the method of any of claims 1 to 4.

10. A computer readable storage medium comprising computer program instructions which, when executed by a computing device, perform the method of any of claims 1 to 4.

11. A computer program product comprising instructions which, when executed by a computing device, cause the computing device to perform the method of any of claims 1 to 4.