CN117742903A

CN117742903A - Host migration method, device and system

Info

Publication number: CN117742903A
Application number: CN202211117012.3A
Authority: CN
Inventors: 龙彬
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2022-09-14
Filing date: 2022-09-14
Publication date: 2024-03-22

Abstract

The present invention relates to the field of computers, and in particular, to a method, an apparatus, and a system for host migration. The method comprises the following steps: the migration source end obtains partition information of a first disk partition used for starting an operating system at the migration source end; the migration source end sends the partition information to the migration destination end; the migration destination end creates a second disk partition which is adapted to the target starting mode in a disk of the migration destination end according to the partition information; the migration destination end receives the data of the host sent by the migration source end and stores the data of the host into the second disk partition; and the migration destination end injects a starting manager matched with the operating system into an expandable firmware interface system partition ESP in the second disk partition, and modifies a starting guide configuration file of the operating system according to the position of data of the operating system in the second disk partition. The method can ensure the data security and service persistence of the host while switching the starting mode of the host.

Description

Host migration method, device and system

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, and a system for host migration.

Background

Currently, the boot loader of an operating system has a basic input/output system (BIOS) and a unified extensible firmware interface (unified extensible firmware interface, UEFI). The BIOS is a conventional boot loader, and has many drawbacks. For example, the start-up speed is full, the security is low, the development efficiency is low, and a large capacity (2 TB and above) disk (disk) is not supported. UEFI is a new generation of boot strap procedure, solving the aforementioned problems. With the continuous updating of computer hardware, more and more computers are no longer supporting or compatible with BIOS, but only supporting UEFI.

Users may change the computer executing the business for reasons of cloud service (i.e., migrating the business to a cloud platform), changing cloud platform service providers, using new features of UEFI, etc. In the replacement of a computer executing a service, migration of a host to a new computer is a common means, and the means does not need to redeploy service applications, so that the method is simple and effective. Wherein, the host refers to a software system comprising an operating system and business applications running on the operating system.

If the host to be migrated is booted by the BIOS at the migration source and the boot program at the migration destination is UEFI, after the host is migrated to the migration destination, the boot program of the host needs to be switched. At present, the switching scheme of the starting boot program is complicated, and the service needs to be stopped for a long time.

Disclosure of Invention

The embodiment of the application provides a host migration method, a device and a system, which can ensure the data security and service persistence of a host while switching the starting mode of the host.

In a first aspect, a host migration method is provided and applied to a migration system, wherein the migration system comprises a migration source end and a migration destination end, the migration source end is provided with a host, and the host comprises an operating system and an application running on the operating system; the method comprises the following steps: the migration source end obtains partition information of a first disk partition used for starting an operating system at the migration source end; the migration source end sends the partition information to the migration destination end; the migration destination end creates a second disk partition which is adapted to a target starting mode in a disk of the migration destination end according to partition information, and the target starting mode is guided by a Unified Extensible Firmware Interface (UEFI); the migration destination end receives the data of the host sent by the migration source end and stores the data of the host into the second disk partition; and the migration destination end injects a starting manager matched with the operating system into the extensible firmware interface system partition ESP in the second disk partition under the condition that the starting mode of the host at the migration source end is different from the target starting mode, and modifies a starting guide configuration file of the operating system according to the position of the data of the operating system in the second disk partition.

The first disk partition is used for starting the operating system of the host at the migration source end, and the second disk partition is used for starting the operating system of the host at the migration destination end.

According to the scheme, the data security is guaranteed (the possibility of being deleted by mistake is small) while the starting mode of the host is switched to the starting mode guided by the UEFI, and the migration source end does not need to stop the service when the host is migrated, so that the host does not need to stop the service for a long time. In addition, in the transmission process of the host data, the migration source end can continue to provide the service, and finally, new data generated in the transmission process of the host data can be synchronized to the migration destination end in an incremental synchronization mode, so that the continuity of the service is further ensured.

In one possible implementation, the partition information includes a first space size, where the first space size is a size of an occupied space of data of the host in the first disk partition or a space size of the first disk partition; the second disk partition has a space size not smaller than the first space size.

In this embodiment, the space size of the disk used for the migration destination end to start the host may be set according to the size of the space occupied by the host data and the space size of the disk partition of the host data at the migration source end, so as to avoid or reduce the waste of storage resources while meeting the demand of the host data on the storage resources.

In one possible implementation, injecting the boot manager matching the operating system into the extensible firmware interface system partition in the second disk partition includes: the migration destination end obtains the type of the operating system, and determines a starting manager matched with the operating system from a plurality of starting managers according to the type of the operating system.

In this embodiment, a boot manager that matches the host operating system may be injected into the extensible firmware interface system partition, so that the host operating system may be booted at the migration destination using the second disk partition in a boot mode that is booted by UEFI.

In one possible embodiment, the method further comprises: the migration destination end receives the type of the operating system from the migration source end; or the migration destination end identifies the type of the operating system based on the data of the operating system in the data of the host.

In this embodiment, the migration source end may notify the migration destination end of the type of the operating system, so that the migration destination end may identify the type of the operating system without after the host data is migrated to the migration destination end, so that a boot manager matched with the host operating system may be injected into the extensible firmware interface system partition in advance.

Or in this embodiment, the migration destination end may identify the type of the operating system according to the received data of the host, so that the migration source end is not required to notify the migration destination end of the type of the operating system, thereby saving the overhead of communication resources.

In one possible implementation, creating a second disk partition in the disk of the migration destination adapted to the target boot mode includes: and creating a second disk partition in the blank disk of the migration destination.

In this embodiment, creating a second disk partition in a blank disk may avoid the risk of losing (being deleted) data on the disk as compared to creating a disk partition on a non-blank disk.

In one possible embodiment, the method further comprises: when the host operates at the migration source, the migration source sends data of the host to the migration destination.

In this embodiment, operations such as disk creation are performed at the migration destination end, and operation of the host at the migration source end is not affected, so that the migration source end may not stop operation of the host when data of the host is sent to the migration destination end, thereby avoiding interruption of service and ensuring continuity of service.

In a second aspect, a host migration method is provided, and is applied to a migration destination end in a migration system, wherein the migration system further comprises a migration source end, the migration source end is provided with a host, and the host comprises an operating system and an application running on the operating system; the method comprises the following steps: the migration destination end receives partition information of a first disk partition sent by the migration source end, wherein the first disk partition is used for starting an operating system at the migration source end; the migration destination end creates a second disk partition which is adapted to a target starting mode in a disk of the migration destination end according to partition information, and the target starting mode is guided by a Unified Extensible Firmware Interface (UEFI); the migration destination end receives the data of the host sent by the migration source end and stores the data of the host into the second disk partition; and the migration destination end injects a starting manager matched with the operating system into the extensible firmware interface system partition ESP in the second disk partition under the condition that the starting mode of the host at the migration source end is different from the target starting mode, and modifies a starting guide configuration file of the operating system according to the position of the data of the operating system in the second disk partition.

In a third aspect, a host migration device is provided, configured at a migration destination end in a migration system, where the migration system further includes a migration source end, and the migration source end is installed with a host, and the host includes an operating system and an application running on the operating system; the device comprises: the system comprises a communication module, a creation module and a processing module; the communication module is used for receiving partition information of a first disk partition sent by the migration source end, and the first disk partition is used for starting an operating system at the migration source end; the creating module is used for creating a second disk partition which is adapted to a target starting mode in a disk of the migration destination according to partition information, and the target starting mode is guided by a Unified Extensible Firmware Interface (UEFI); the communication module is also used for receiving the data of the host computer sent by the migration source end and storing the data of the host computer into the second disk partition; and the processing module is used for injecting a starting manager matched with the operating system into the extensible firmware interface system partition ESP in the second disk partition under the condition that the starting mode of the host at the migration source end is different from the target starting mode, and modifying the starting guide configuration file of the operating system according to the position of the data of the operating system in the second disk partition.

In one possible implementation, the processing module further uses: the type of the operating system is obtained, and a boot manager matched with the operating system is determined from a plurality of boot managers according to the type of the operating system.

In one possible implementation, the communication module is further configured to receive, from the migration source, a type of operating system by the migration destination; or the processing module is also used for identifying the type of the operating system in the data of the host.

In one possible implementation, the creating module is further configured to create a second disk partition in a blank disk of the migration destination.

In a fourth aspect, a migration system is provided, where the migration system includes a migration source end and a migration destination end, and the migration source end is installed with a host, and the host includes an operating system and an application running on the operating system; the method comprises the following steps:

the migration source end is used for acquiring partition information of a first disk partition used for starting the operating system at the migration source end;

the migration source end is used for sending the partition information to the migration destination end;

the migration destination end is used for creating a second disk partition which is adapted to a target starting mode in a disk of the migration destination end according to the partition information, and the target starting mode is guided by a Unified Extensible Firmware Interface (UEFI);

The migration destination end is used for receiving the data of the host sent by the migration source end and storing the data of the host into the second disk partition; and the migration destination end injects a startup manager matched with the operating system into an expandable firmware interface system partition ESP in the second disk partition under the condition that the startup mode of the host at the migration source end is different from the target startup mode, and modifies a startup guide configuration file of the operating system according to the position of the data of the operating system in the second disk partition.

In one possible implementation manner, the migration destination is further configured to obtain a type of an operating system, and determine a boot manager matching the operating system from a plurality of boot managers according to the type of the operating system.

In one possible implementation, the migration destination is further configured to receive a type of operating system from the migration source; or the migration destination end is further used for identifying the type of the operating system based on the data of the operating system in the data of the host.

In one possible implementation, the migration destination is configured to create a second disk partition in a blank disk of the migration destination.

In one possible implementation, the migration source is configured to send data of the host to the migration destination when the host runs on the migration source.

In a fifth aspect, a cluster of computing devices is provided, comprising at least one computing device, each computing device comprising a processor and a memory;

the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method provided in the second aspect.

In a sixth aspect, there is provided a computer readable storage medium comprising computer program instructions which, when executed by a cluster of computing devices, perform the method provided by the second aspect.

In a seventh aspect, there is provided a computer program product comprising instructions which, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method provided by the second aspect.

According to the host migration method, device and system provided by the embodiment of the invention, the data security (the possibility of being deleted by mistake is small) can be ensured while the starting mode of the host is switched to the starting mode guided by the UEFI, and the migration source end does not need to stop the service when the host is migrated, so that the host does not need to stop the service for a long time. In addition, in the transmission process of the host data, the migration source end can continue to provide the service, and finally, new data generated in the transmission process of the host data can be synchronized to the migration destination end in an incremental synchronization mode, so that the continuity of the service is further ensured.

Drawings

FIG. 1 is a system architecture provided in an embodiment of the present application;

FIG. 2 is a flow chart of a host migration scheme provided by an embodiment of the present application;

FIG. 3 is a schematic diagram of a host migration scheme according to an embodiment of the present disclosure;

FIG. 4 is a flowchart of a method for host migration provided in an embodiment of the present application;

Fig. 5 is a schematic structural diagram of a host migration apparatus according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a computing device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a computing device cluster according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a computing device cluster according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present invention will be described below with reference to the accompanying drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present specification.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the specification. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise.

Wherein, in the description of the present specification, "/" means or is meant unless otherwise indicated, for example, a/B may represent a or B; "and/or" herein is merely an association relation describing associated objects, meaning that three relations may exist, e.g., a and/or B may represent: a exists alone, A and B exist together, and B exists alone. In addition, in the description of the embodiments of the present specification, "a plurality" means two or more than two.

In the description of this specification, the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

Currently, the boot modes of an operating system may be divided into a boot mode that is booted by the BIOS and a boot mode that is booted by the UEFI. In the case where the original boot mode of the operating system of the host to be migrated is the boot mode guided by the BIOS, and the boot program of the migration destination is UEFI, it is necessary to switch the boot mode of the operating system of the host from the boot mode guided by the BIOS to the boot mode guided by the UEFI.

In the following description, the startup mode guided by the BIOS may be simply referred to as a BIOS startup mode, and the startup mode guided by the UEFI may be simply referred to as a UEFI startup mode.

A scheme for switching the starting mode is that an operating system and a service Application (APP) are reinstalled at a migration destination end, and then host data of a migration source end is copied to the migration destination end. In this scheme, the operating system and the service application need to be reinstalled, and the operation is complicated. In particular, some service applications have lost their installation packages, making this approach difficult to implement. In addition, it takes a long time (several hours to several tens of hours) for host data to be imported into a newly installed operating system and business applications, and during this long time, the host cannot run, resulting in a long interruption of business.

Another scheme for switching the boot mode is to partition and format the disk at the migration source according to the requirement of the UEFI, so as to switch the boot mode of the host operating system from the boot mode guided by the BIOS to the boot mode guided by the UEFI at the migration source. Since host data is stored on the disk, the disk is subjected to partition formatting, which is easy to cause data loss (for example, deleted in the formatting process), and the operation is also complicated. In addition, in the scheme, the service needs to be interrupted for a long time, and the user experience is poor.

The embodiment of the application provides a host migration scheme, which can be used for creating a disk partition which can accommodate host data and is adapted to be guided by a startup mode guided by UEFI at a migration destination according to partition information of a host at a migration source. And then, transmitting the host data from the migration source end to the migration destination end, and storing the host data in the disk partition. Then, the disk partition and the operating system of the host can be adapted to realize the starting of the host at the migration destination.

In the scheme, before host data is sent to the migration source end, a disk partition is created at the migration destination end, so that operations such as partition formatting and the like of the disk partition are created, the migration source end is not affected, the data security of host migration is guaranteed, and the migration source end does not need to stop the service, so that the host does not need to stop the service for a long time. In this scheme, the data of the host is directly transmitted to the migration destination. In addition, in the transmission process of the host data, the migration source end can continue to provide the service, and finally, new data generated in the transmission process of the host data can be synchronized to the migration destination end in an incremental synchronization mode, so that the continuity of the service is further ensured.

In this embodiment of the present application, the host data refers to data of a host, and may include data of an operating system and data of an application running on the operating system. The data of the operating system includes data of the operating system itself (program codes and the like), and data generated when the operating system runs. The data of an application includes data of the application itself (program code, etc.) running on the operating system, and data generated when the application runs. The migration source end refers to the original equipment of the host, the migration destination end refers to the equipment to which the host is to be migrated, and the host migration refers to the migration of the host from the migration source end to the migration destination end.

Next, a specific description is given of a host migration scheme provided in the embodiment of the present application.

The present embodiments provide a system architecture that may be used to implement this embodiment. As shown in fig. 1, the architecture includes a migration source end 100 and a migration destination end 200. In some embodiments, the migration source end 100 and/or the migration destination end 200 may be physical entity devices, such as servers, etc. In some embodiments, the migration source end 100 and/or the migration destination end 200 may be virtual computing instances, such as Virtual Machines (VMs). The embodiments of the present application do not limit the specific implementation manner of the migration source end 100 and/or the migration destination end 200.

As shown in FIG. 1, migration source 100 includes a processor 110, a memory 120, and a disk 130. Among other things, processor 110, memory 120, and disk 130 may communicate via a bus (bus) 140. The memory 120 may store therein a program code of the acquisition device 121. The processor 110 may execute program code of the acquisition device 121 to implement the relevant functions of the acquisition device 121. The related functions of the acquisition device 121 will be described in detail below with reference to the flowchart, and will not be described herein.

The disk 130 stores data of the host a. The data of the host a may include program code of the operating system A1 itself and program code of an application running on the operating system A1, and may also include data generated by the operating system A1 during running and data generated by the application running on the operating system A1 during running. In some embodiments, disk 130 is a collection of one or more disks. For example, as shown in FIG. 1, disk 130 may include disk 130a and disk 130b, where disk 130a may serve as a system disk for storing program code for operating system A1 itself and for applications running on operating system A1. The disk 130b may be used as a data disk for storing data generated by the operating system A1 during operation and data generated by applications running on the operating system A1 during operation.

As shown in fig. 1, the migration destination 200 includes a processor 210, a memory 220, and a disk 230. Among other things, processor 210, memory 220, and disk 230 may communicate via bus 240. Wherein memory 220 may store program codes for partition means 221. Processor 210 may execute the program code of partition device 221 to implement the functions associated with partition device 221. The related functions of the partition device 221 will be described in detail below with reference to the flowchart, and will not be described herein.

Disk 230 may be a blank disk or an empty disk, i.e., disk 230 is empty, before partition device 220 performs the associated operations on disk 230. In some embodiments, disk 230 is a collection of disks consisting of one or more disks. For example, as shown in FIG. 1, disk 230 may include disk 230a and disk 230b.

Wherein disk 210 and/or disk 230 are storage devices in a computer capable of storing data. In some embodiments, disk 210 and/or disk 230 may be solid state disks in particular. In other embodiments, disk 210 and/or disk 230 may be a mechanical hard disk.

The migration source end 100 and the migration destination end 200 may perform information interaction, for example, through a network or a data line. In some embodiments, the migration source end 100 and the migration destination end 200 may be in the same local area network, and the migration source end 100 and the migration destination end 200 may perform information interaction in the local area network. In some embodiments, the migration destination 200 may be in an external network of the migration source 100, for example, the migration source 100 is a local device on the user side, and the migration destination 200 is a cloud device or platform. In this case, the migration source terminal 100 and the migration destination terminal 200 may perform information interaction through the internet (internet). The embodiment of the present application does not specifically limit the manner of information interaction between the migration source end 100 and the migration destination end 200.

The above examples introduce a system architecture to which a host migration scheme provided by embodiments of the present application may be applied. Next, a flow of the host migration scheme provided in the embodiment of the present application is described.

Referring to fig. 2, the collection device 121 may perform step 201 to collect partition information B11 of the disk partition B1. The disk partition B1 is used to start the host a by the migration source 100. The disk partition B11 is used to store data for the host a.

The starting host a may specifically refer to starting an operating system of the host a, that is, starting the operating system A1.

In some embodiments, referring to fig. 3, the boot loader of the migration source 100 is a BIOS, that is, the boot mode of the migration source 100 for booting the host a is a BIOS boot mode. As shown in fig. 3, the disk partition B1 in the BIOS boot mode includes a main boot record (master boot record, MBR) partition, a partition gap,/boot partition,/partition, and/home partition. Wherein the master boot record partition is used to store parameters of the disk 130 and a section of boot strap program. The main function of the boot program is to check whether each partition on the disk 130 is correct, and after the disk 130 completes the self-check, the operating system on the partition with the activation flag is booted, and control is given to the boot program. The boot partition is used to store the kernel of the operating system A1, etc. The home partition is used to store program code of an application running on the operating system A1, data generated at the time of operating system A1 running, data generated at the time of application running, and the like.

Partition information B11 of the disk partition B1 refers to information describing characteristics of the disk partition B1.

In some embodiments, partition information B11 of disk partition B1 may include a space size C1. The space size C1 refers to the size of a storage space required to store data of the host a. In one example, the space size C1 may refer to the space size of the disk partition B1. The space size of the disk partition B1 refers to the size of the set space of the disk partition B1, including the size of the utilized space and the size of the unused space. In one example, the space size C1 may refer to the size of the space occupied by the data of host A1, i.e., the size of the utilized space of disk partition B1.

In this embodiment of the present application, the space refers to a storage space. The larger the space, the more data can be stored. The smaller the space, the less data can be stored.

In one example of this embodiment, partition information B11 may include the size of each partition in disk partition B1. Specifically, the partition information B11 may include/boot partition space size,/partition space size, and/home partition space size.

In some embodiments, partition information B11 may include a boot mode that disk partition B1 is adapted to. For example, the boot mode adapted by the disk partition B1 is a BIOS boot mode, that is, the disk partition B1 is used by the migration source 100 to boot the host a according to the BIOS boot mode. For another example, the startup mode adapted by the disk partition B1 is a UEFI startup mode, that is, the disk partition B1 is used by the migration source end 100 to start the host a according to the UEFI startup mode.

In some embodiments, partition information B11 may include a disk partition form of disk partition B1. For example, the disk partition may be in the form of an MBR.

In some embodiments, disk 130 may be one disk or may be composed of multiple disks. Accordingly, disk partition B1 may be created on one of disks 130 or may be created on multiple ones of disks 130. That is, disk partition B1 may refer to one or more disks. Partition information B11 may also include the number of disks involved in disk partition B1.

In a specific example, the partition information B11 may specifically include the following information.

Type of boot strap: a BIOS;

disk partition form: MBR;

number of disks: 1 (/ dev/vda);

space size C1:40GB;

partitioning: boot,1G, ext4; v, 19g, ext4; /home, about 20G, ext4.

With continued reference to fig. 2, the acquisition device 121 may perform step 202 to send the partition information B11 to the partition device 221. Partition device 221 may perform step 203 to create disk partition B2 in disk 230 based on partition information B11. Wherein, prior to performing step 203, as shown in fig. 3, disk 230 is an empty disk.

The created disk partition B2 is a disk partition capable of hosting host a's data and adapted to the startup mode (UEFI startup mode) guided by UEFI. That is, the created disk partition B2 is adapted to the UEFI startup mode, and the size of the storage space of the disk partition B2 is greater than or equal to the space size C1. Also, disk partition B2, which is adapted to the UEFT start-up mode, has an extensible firmware interface system (extensible firmware interface system partition, ESP) partition. That is, in step 203, an ESP partition is created on disk 130.

More specifically, as shown in FIG. 3, in step 203, a/boot partition,/boot partition/EFI partition,/home partition, globally unique identifier partition table (globally unique identifier partition table, GPT) partition is created on disk 230. The/boot partition,/boot/EFI partition,/home partition, and the globally unique identifier partition table (globally unique identifier partition table, GPT) partition make up disk partition B2. Wherein the/boot/EFI partition is an ESP partition.

In some embodiments, as described above, partition information B11 may include the spatial size of each partition, such as/boot partition, and home partition. In step 203, the size of each partition in the disk partition B2 may be set according to the space size of each partition in the partition information B11. Illustratively, the space size of the/boot partition in the disk partition B2 is equal to the space size of the/boot partition in the partition information B11 (i.e., the/boot partition in the disk partition B1), and the space size of the/partition in the disk partition B2 is equal to the space size of the/partition in the partition information B11 (i.e., the/partition in the disk partition B1). Since there are more/boot/EFI partitions in disk partition B2 relative to disk partition B1. Typically, the space of the/boot partition/EFI partition is 512MB-1GB, and the/home partition has redundant storage space, so a portion of the space of the/home partition may be utilized to create the/boot partition/EFI partition. That is, the sum of the spatial sizes of the/boot/EFI partition and/home partition in disk partition B2 is equal to the spatial size of the/home partition in partition information B11 (i.e., the/home partition in disk partition B1).

In some embodiments, partition information B11 may also include the number of disks involved in disk partition B1, as described above. In step 203, disk partition B2 may be created on a corresponding number of disks based on the number of disks involved in disk partition B1. That is, the number of disks involved in disk partition B2 is equal to the number of disks involved in disk partition B1. For example, disk partition B1 relates to disk 130a and disk 130B. The magnetic disk 130a may be used as a system disk to store program codes of the operating system A1 itself and program codes of applications running on the operating system A1. The disk 130b may be used as a data disk for storing data generated by the operating system A1 during operation and data generated by applications running on the operating system A1 during operation. Disk partition B2 then involves disk 230a and disk 230B. The magnetic disk 230a may be used as a system disk to store program codes of the operating system A1 itself and program codes of applications running on the operating system A1. Disk 230b may be used as a data disk for storing data generated by operating system A1 during runtime and for storing data generated by applications running on operating system A1 during runtime.

In a specific example, the partition information B11 may be set to include the following information.

Type of boot strap: a BIOS;

disk partition form: MBR;

number of disks: 1 (/ dev/vda);

space size C1:40GB;

partitioning: boot,1G, ext4; v, 19g, ext4; /home, about 20G, ext4.

Then, based on the partition information B11, the created disk partition B2 is specifically as follows.

Type of boot strap: UEFI;

disk partition form: GPT;

number of disks: 1 (/ dev/vda);

space size: 40GB;

partitioning: boot,1G, ext4; boot/EFI,512M, fat32; v, 19g, ext4; /home, about 19G.

In step 203, disk 230 may be partition formatted as required to complete the creation of disk partition B2.

With continued reference to FIG. 2, after step 203, step 204a may be performed to migrate data of host A on disk partition B1 to disk partition B2. Step 204a may include step 2041, step 2042, and step 2043, among others. The acquisition device 121 may perform step 2041 to acquire data of host a from the disk partition B1 and send the data of host a to the partition device 221, via step 2042. Partition device 220 may perform step 2043 to migrate the host of host a to disk partition B2.

In some embodiments, as shown in FIG. 3, the data of host A may include data stored in/boot partition,/data in partition, and/home of disk partition B1. In step 204a, data in the/boot partition of disk partition B1 may be migrated to the/boot partition of disk partition B2, data in the/partition of disk partition B1 may be migrated to the/partition of disk partition B2, and data in the/home partition of disk partition B1 may be migrated to the/home partition of disk partition B2.

In some embodiments, during the execution of step 204a, host a on migration source 100 is still running. That is, in the solution of the embodiment of the present application, the migration of the host does not affect the operation of the host at the migration source end 100.

With continued reference to FIG. 2, partition device 221 may execute step 204B to inject a boot manager to the ESP partition of disk partition B2 that matches operating system A1. Wherein injecting a boot manager into an ESP partition may be understood as storing or writing the program code of the boot manager to the ESP partition. As described above, the operating system A1 is the operating system of the host a. The boot manager is configured to boot an operating system. In some embodiments, the boot manager may be a multiple operating system boot manager (grand unified bootloader, GRUB) in particular.

In step 204B, partition device 221 may obtain the type of operating system A1 and determine a boot manager matching operating system A1 from among the plurality of boot managers according to the type of operating system A1, and further inject the boot manager matching operating system A1 into the ESP partition of disk partition B2. In some embodiments, a mapping table of the operating system and the boot manager may be preconfigured, where the mapping table records mapping relationships of multiple operating system types and multiple boot managers. For example, the mapping table may record the mapping relationship as shown in table 1.

TABLE 1

Operating system type	Start-up manager
		Entos	Boot manager D1
Ubuntu	Boot manager D2
		Debian	Boot manager D3
…	…

Thus, in step 204b, partition device 221 may query the mapping table for a boot manager that matches operating system A1, resulting in a boot manager that matches operating system A1.

In some embodiments, the mapping table may be preconfigured into the migration destination 200 as a configuration file. In some embodiments, before step 204b, the migration source 100 may send the mapping table to the migration destination 200, e.g., the collection device 121 may send the mapping table preconfigured in the migration source 100 to the partition device 221.

In some embodiments, step 204b may be performed after step 204 a. Wherein, when or after data of host A is migrated into disk partition B2, partition device 221 identifies the type of operating system A1 based on the data of the operating system in the data of host A. For example, the type of the operating system A1 is identified based on the program code of the operating system or the like in the data of the host a.

In some embodiments, step 204b may be performed before step 204a, or step 204b and step 204a may be performed simultaneously, or step 204b may be performed after step 204 a. The collection device 121 may collect the type of the operating system A1, and send the type of the operating system A1 to the partition device 221.

In some embodiments, during the execution of step 204b, host a on migration source 100 is still running. It should be appreciated that step 204b is performed at the migration destination 200, so that execution of step 204b does not affect the operation of the host at the migration source 100.

With continued reference to FIG. 2, partition device 221 may execute step 204c, modifying the boot configuration file of operating system A1. The boot configuration file is used by the boot manager to boot the operating system. The boot manager obtains the kernel and other positions of the operating system A1 through the boot configuration file, so that the operating system can be booted. Before the boot configuration file is modified, the information in the boot configuration file is still the information of the operating system A1 and the like on the disk partition B1, and if not modified, the boot manager on the disk partition B2 has difficulty in acquiring the position of the kernel and the like of the operating system A1 on the disk partition B2 through the boot configuration file, so that it is difficult to boot the operating system A1 on the disk partition B2. To this end, a modification to the boot configuration file on disk partition B2 is required.

Specifically, the boot configuration file of operating system A1 in disk partition B2 may be modified based on the location of operating system A1 data in disk partition B2. That is, the information recorded by the boot configuration file of the operating system A1 in the disk partition B2 is updated to the position of the data of the operating system A1 in the disk partition B2. The kernel of the operating system A1 recorded in the boot configuration file may be updated to the location of the kernel of the operating system A1 in the disk partition B2, and other data of the operating system A1 recorded in the boot configuration file may be updated to the location of the data in the disk partition B2.

Wherein the location of data in disk partition B may also be referred to as the location of data in disk 230.

In some embodiments, during the execution of step 204c, host a on migration source 100 is still running. It should be appreciated that step 204c is performed at the migration destination 200, so that execution of step 204c does not affect the operation of the host at the migration source 100.

Through the above steps, the host a may be started at the migration destination 200. For example, the migration destination 200 may restart, by restarting, the operating system A1 of the host a, and further, the application running on the operating system A1, thereby completing the startup of the host a. Thus, the host a on the migration source 100 may be turned off, and the host a on the migration destination 200 takes over the service.

After the migration source end 100 closes the host a, the host a on the migration source end 100 may migrate data generated in a period from when the execution of step 204a is completed to when the host a on the migration source end 100 is closed to the disk partition B2, so as to implement incremental synchronization, thereby ensuring data consistency between the migration source end and the migration destination end.

By combining the above, the host migration scheme provided by the embodiment of the present application can ensure data security (for example, the possibility of being deleted by mistake is small) while the startup mode of the host is switched to the startup mode guided by UEFI, and the migration source does not need to stop the service when the host migration is performed, so that the host does not need to stop the service for a long time. In addition, in the scheme, the data of the host is directly sent to the migration destination end, the host can be started at the migration destination end, and an operating system and a service application of the host do not need to be reloaded, so that a process of importing the data to a newly installed operating system and service application is not needed, and therefore, the service does not need to be stopped at the migration destination end. In addition, in the transmission process of the host data, the migration source end can continue to provide the service, and finally, new data generated in the transmission process of the host data can be synchronized to the migration destination end in an incremental synchronization mode, so that the continuity of the service is further ensured.

Based on the above-described host migration scheme, the embodiment of the application provides a host migration method. It will be appreciated that the method is combined with the host migration scheme described above, and that specific execution of relevant steps in the method may refer to execution of corresponding steps in the host migration scheme.

The method is applied to a migration destination end in a migration system, and the migration system further comprises a migration source end, wherein a host is installed on the migration source end and comprises an operating system and an application running on the operating system. As shown in fig. 4, the method includes the following steps.

In step 401, a migration destination end receives partition information of a first disk partition sent by a migration source end, where the first disk partition is used to start the operating system at the migration source end. Reference is made in particular to the implementation of the above description of steps 201 and 202 in fig. 2.

In step 402, the migration destination creates, according to the partition information, a second disk partition adapted to a target startup mode in a disk of the migration destination, where the target startup mode is guided by a unified extensible firmware interface UEFI. In particular, reference is made to the description of step 203 in fig. 2 above.

Step 403, the migration destination end receives the data of the host sent by the migration source end, and stores the data of the host in the second disk partition; and the migration destination end injects a startup manager matched with the operating system into an expandable firmware interface system partition ESP in the second disk partition under the condition that the startup mode of the host at the migration source end is different from the target startup mode, and modifies a startup guide configuration file of the operating system according to the position of the data of the operating system in the second disk partition. Reference is made in particular to the above description of steps 204a, 204b and 204c in fig. 2.

In some embodiments, the injecting the boot manager matching the operating system into the extensible firmware interface system partition in the second disk partition comprises: and the migration destination end acquires the type of the operating system and determines a starting manager matched with the operating system from a plurality of starting managers according to the type of the operating system. Reference is made in particular to the implementation of the description of step 204b in fig. 2 above.

In one example of this embodiment, the method further comprises: the migration destination end receives the type of the operating system from the migration source end; or the migration destination end identifies the type of the operating system based on the data of the operating system in the data of the host.

In some embodiments, creating the second disk partition in the disk of the migration destination adapted to the target boot mode includes: and creating the second disk partition in the blank disk of the migration destination.

According to the host migration method provided by the embodiment of the invention, the data security (such as small possibility of being deleted by mistake) can be ensured while the starting mode of the host is switched to the starting mode guided by the UEFI, and the migration source end does not need to stop the service when the host is migrated, so that the host does not need to stop the service for a long time. In addition, in the scheme, the data of the host is directly sent to the migration destination end, the host can be started at the migration destination end, and an operating system and a service application of the host do not need to be reloaded, so that a process of importing the data to a newly installed operating system and service application is not needed, and therefore, the service does not need to be stopped at the migration destination end. In addition, in the transmission process of the host data, the migration source end can continue to provide the service, and finally, new data generated in the transmission process of the host data can be synchronized to the migration destination end in an incremental synchronization mode, so that the continuity of the service is further ensured.

The embodiment of the application also provides a host migration device 500. The host migration device 500 may be configured at a migration destination end in a migration system, where the migration system further includes a migration source end, and the migration source end is installed with a host, and the host includes an operating system and an application running on the operating system. As shown in fig. 5, the host migration apparatus 500 includes: a communication module 510, a creation module 520, and a processing module 530. Wherein,

the communication module 510 is configured to receive partition information of a first disk partition sent by the migration source, where the first disk partition is used to start the operating system at the migration source;

the creating module 520 is configured to create, according to the partition information, a second disk partition adapted to a target startup mode in a disk of the migration destination, where the target startup mode is guided by a unified extensible firmware interface UEFI;

the communication module 510 is further configured to receive the data of the host sent by the migration source end, and store the data of the host in the second disk partition; and the processing module 530 is configured to, when the host computer has a different boot mode at the migration source end from the target boot mode, inject a boot manager matching with the operating system into an extensible firmware interface system partition ESP in the second disk partition, and modify a boot configuration file of the operating system according to a location of data of the operating system in the second disk partition.

Wherein, the communication module 510, the creation module 520 and the processing module 530 may be implemented by software, or may be implemented by hardware. Illustratively, the implementation of the communication module 510 is described next as an example of the communication module 510. Similarly, the implementation of creation module 520 and processing module 530 may refer to the implementation of communication module 510.

Module as an example of a software functional unit, the communication module 510 may include code that runs on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container, among others. Further, the above-described computing examples may be one or more. For example, the communication module 510 may include code running 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 communication module 510 may include at least one computing device, such as a server or the like. Alternatively, the communication module 510 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 plurality of computing devices included in the communication module 510 may be distributed in the same region or may be distributed in different regions. The plurality of computing devices included in the communication module 510 may be distributed among the same AZ or may be distributed among different AZ. Likewise, the plurality of computing devices included in the communication module 510 may be distributed in the same VPC or may be distributed among 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 communication module 510 may be used to perform any step in the method shown in fig. 4, the creating module 520 and the processing module 530 may be used to perform any step in the method shown in fig. 4, and the steps that the communication module 510, the creating module 520 and the processing module 530 are responsible for implementing may be specified as needed, and the different steps in the method shown in fig. 4 are implemented by the communication module 510, the creating module 520 and the processing module 530 respectively to implement all the functions of the host migration apparatus 500.

The present application also provides a computing device 600. As shown in fig. 6, the computing device 600 includes: bus 602, processor 604, memory 606, and communication interface 608. The processor 604, the memory 606, and the communication interface 608 communicate via the bus 602. Computing device 600 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 600.

Bus 602 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one line is shown in fig. 6, but not only one bus or one type of bus. Bus 602 may include a path to transfer information between various components of computing device 600 (e.g., memory 606, processor 604, communication interface 608).

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

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

The memory 606 has stored therein executable program code that the processor 604 executes to implement the functions of the communication module 510, the creation module 520, and the processing module 530, respectively, to implement the method shown in fig. 4. That is, the memory 606 has instructions stored thereon for performing the method of FIG. 4.

Communication interface 608 enables communication between computing device 600 and other devices or communication networks using transceiver modules such as, but not limited to, network interface cards, transceivers, and the like.

The embodiment of the application also provides a computing device cluster. The cluster of computing devices 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. 7, the cluster of computing devices includes at least one computing device 600. The same instructions for performing the method shown in fig. 4 may be stored in memory 606 in one or more computing devices 600 in a computing device cluster.

In some possible implementations, portions of the instructions for performing the method shown in fig. 4 may also be stored in the memory 606 of one or more computing devices 600 in the computing device cluster, respectively. In other words, a combination of one or more computing devices 600 may collectively execute instructions for performing the method shown in FIG. 4.

It should be noted that, the memory 606 in different computing devices 600 in the computing device cluster may store different instructions for performing part of the functions of the host migration apparatus 500. That is, the instructions stored by the memory 606 in the different computing devices 600 may implement the functionality of one or more of the communication module 510, the creation module 520, and the processing module 530.

In some possible implementations, one or more computing devices in a cluster of computing devices may be connected through a network. Wherein the network may be a wide area network or a local area network, etc. Fig. 8 shows one possible implementation. As shown in fig. 8, two computing devices 600A and 600B are connected by a network. Specifically, the connection to the network is made through a communication interface in each computing device. In this type of possible implementation, instructions to perform the functions of the communication module 510 are stored in the memory 606 in the computing device 600A. Meanwhile, instructions to perform the functions of creation module 520 and processing module 530 are stored in memory 606 in computing device 600B.

It should be appreciated that the functionality of computing device 600A shown in fig. 8 may also be performed by multiple computing devices 600. Likewise, the functionality of computing device 600B may also be performed by multiple computing devices 600.

The embodiment of the application also provides another computing device cluster. The connection between computing devices in the computing device cluster may be similar to the connection of the computing device cluster described with reference to fig. 7 and 8. In contrast, the same instructions for performing the method of FIG. 4 may be stored in memory 606 in one or more computing devices 600 in the computing device cluster.

Embodiments of the present application also provide a computer program product comprising instructions. The computer program product may be software or a program product containing instructions capable of running on a computing device or stored in any useful medium. The computer program product, when run on at least one computing device, causes the at least one computing device to perform the method of fig. 4.

Embodiments of the present application also provide a computer-readable storage medium. The computer readable storage medium may be any available medium that can be stored by a computing device or a host migration 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 method shown in fig. 4.

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. The host migration method is characterized by being applied to a migration system, wherein the migration system comprises a migration source end and a migration destination end, the host is installed on the migration source end, and the host comprises an operating system and an application running on the operating system; the method comprises the following steps:

the migration source end obtains partition information for starting a first disk partition of the operating system at the migration source end;

the migration source end sends the partition information to the migration destination end;

the migration destination end creates a second disk partition which is adapted to a target starting mode in a disk of the migration destination end according to the partition information, wherein the target starting mode is guided by a Unified Extensible Firmware Interface (UEFI);

The migration destination end receives the data of the host sent by the migration source end and stores the data of the host into the second disk partition; and the migration destination end injects a startup manager matched with the operating system into an expandable firmware interface system partition ESP in the second disk partition under the condition that the startup mode of the host at the migration source end is different from the target startup mode, and modifies a startup guide configuration file of the operating system according to the position of the data of the operating system in the second disk partition.

2. The method of claim 1, wherein the partition information comprises a first space size, the first space size being a size of a space occupied by data of the host in the first disk partition or a space size of the first disk partition; the second disk partition has a space size not smaller than the first space size.

3. The method of claim 1, wherein the injecting the boot manager into the extensible firmware interface system partition in the second disk partition that matches the operating system comprises:

And the migration destination end acquires the type of the operating system and determines a starting manager matched with the operating system from a plurality of starting managers according to the type of the operating system.

4. A method according to claim 3, characterized in that the method further comprises:

the migration destination end receives the type of the operating system from the migration source end; or,

and the migration destination end identifies the type of the operating system based on the data of the operating system in the data of the host.

5. The method of any of claims 1-4, wherein creating a second disk partition in the migration destination's disk that is adapted to a target boot mode comprises: and creating the second disk partition in the blank disk of the migration destination.

6. The method according to any one of claims 1-5, further comprising: and the migration source end sends the data of the host to the migration destination end when the host runs at the migration source end.

7. The host migration method is characterized by being applied to a migration destination end in a migration system, wherein the migration system further comprises a migration source end, a host is installed on the migration source end, and the host comprises an operating system and an application running on the operating system; the method comprises the following steps:

The migration destination end receives partition information of a first disk partition sent by the migration source end, wherein the first disk partition is used for starting the operating system at the migration source end;

8. The method of claim 7, wherein the injecting the boot manager into the extensible firmware interface system partition in the second disk partition that matches the operating system comprises:

9. The method of claim 8, wherein the method further comprises:

10. The method of any of claims 7-9, wherein creating a second disk partition in the migration destination's disk that is adapted to a target boot mode comprises: and creating the second disk partition in the blank disk of the migration destination.

11. The host migration device is characterized by being configured at a migration destination end in a migration system, wherein the migration system further comprises a migration source end, a host is installed at the migration source end, and the host comprises an operating system and an application running on the operating system; the device comprises: the system comprises a communication module, a creation module and a processing module;

The communication module is used for receiving partition information of a first disk partition sent by the migration source end, and the first disk partition is used for starting the operating system at the migration source end;

the creating module is used for creating a second disk partition which is adapted to a target starting mode in a disk of the migration destination according to the partition information, and the target starting mode is guided by a Unified Extensible Firmware Interface (UEFI);

the communication module is further configured to receive the data of the host sent by the migration source end, and store the data of the host in the second disk partition; and the processing module is configured to, when the migration destination end is different from the target startup mode in the startup mode of the host at the migration source end, inject a startup manager matched with the operating system into an extensible firmware interface system partition ESP in the second disk partition, and modify a startup boot configuration file of the operating system according to a position of data of the operating system in the second disk partition.

12. The apparatus of claim 11, wherein the processing module is further configured to: and acquiring the type of the operating system, and determining a boot manager matched with the operating system from a plurality of boot managers according to the type of the operating system.

13. The apparatus of claim 12, wherein the communication module is further configured to receive, by the migration destination, the type of the operating system from the migration source; or the processing module is further used for identifying the type of the operating system in the data of the host.

14. The apparatus of any of claims 11-13, wherein the creating module is further configured to create the second disk partition in a blank disk of the migration destination.

15. The migration system is characterized by comprising a migration source end and a migration destination end, wherein a host is installed on the migration source end, and comprises an operating system and an application running on the operating system; wherein,

16. A cluster of computing devices, comprising at least one computing device, each computing device comprising a processor and a memory;

the processor of the at least one computing device is configured to execute instructions stored in a memory of the at least one computing device to cause the cluster of computing devices to perform the method of any of claims 7-10.

17. A computer readable storage medium comprising computer program instructions which, when executed by a cluster of computing devices, perform the method of any of claims 7-10.