background

Customers want to migrate their services from a self-built virtualized data center to UCloud. They want to switch from the VMware system to the public cloud system. Among them:

  • The customer wants the upcloud process not to affect the existing business;
  • Remove the overguaranteed equipment hosted by the machine room to reduce unnecessary expenditure;
  • Reduce the maintenance manpower and operation pressure of resources;

In addition, we hope that the migration process will not be too long and will not affect marketing and business innovation.

I. Migration assessment

After feasibility analysis, there are at least the following challenges:

  1. Customers use various types of old operating systems, most of which are Windows Server versions.
  2. The business system cannot be rebuilt because the software does not have deployment guidance documents and source code, or there are no personnel to redeploy.
  3. A large amount of data is migrated, including database and backup data.
  4. The customer cannot or does not want to rebuild the service system because the version of the commercial software used by the customer is too old or the customer does not purchase the license. For example, the full set of third-party commercial software such as SAP and ERP is purchased.

Due to the above reasons, existing tools cannot be used, because the migration tool supports mainstream operating systems (CentOS, Ubuntu) well, but older systems cannot be used due to the lack of vendor support for the new hardware drivers.

Therefore, the migration can only be mirrored.

2. Migration scheme

Based on the above background and migration assessment, the overall migration ideas are basically in two directions:

  1. Public transport

The prerequisites are:

  1. The public network bandwidth is sufficient and does not affect production services.
  2. Data sensitivity is not high, allowing public network transmission;
  3. The amount of data is not too large, preferably not more than 10T level;

2. Offline disk copy

Online transmission over the public network cannot be performed due to large data volume, insufficient bandwidth on the public network, or security factors. Therefore, offline disk copy is advantageous.

Here, USB flash disk (which can be understood as AWS Snowball and Ali lightning Cube) is used to transmit the mirror. The main advantages are as follows:

  1. ** High data security, large space: ** as raiD5 large capacity space, data security is guaranteed.
  2. ** Fast transmission speed: ** supports USB3.0 interface, maximum speed support 500MB/s, storage media read and write speed in about 150MB/s.
  3. ** Physical servers can be mounted: ** Physical machines in the hosting area can communicate with the network in the public cloud area and the US3 service Intranet of the public cloud. If a large amount of data outside the machine room needs to be copied to the machine room, data can be transmitted in this way.

In order to simplify the steps and reduce the intermediate waiting time, and to shorten the single migration process time, asynchronous operation is adopted to reduce the waiting time brought by synchronous operation.

In this case, the data is too large. To speed up the migration, scheme 2, offline disk migration, is selected.

3. Migration details

The migration flow chart is as follows:

First of all:

  • Disable the Windows group policy for Guest.
  • Uninstall the vmware-tool Tool of the Guest system.
  • Close the antivirus software.
  • Shut down the VM.

In the preceding process, you need to create a physical cloud server in advance, use usb flash drives to transfer system disks and data disk images, mount the USB flash drives with stored data to the physical cloud server, and convert the format of system disk images and inject drivers into the physical cloud host.

On the physical cloud host, use the internal API to create a temporary transfer machine and a cloud disk with the properties of a system disk. Use the mounted USB flash disk as the local site. Remotely mount the system disk and data disk of the USB flash disk to the two cloud disks (system disk and data disk) in transit using QEMU-NBD.

Unmount the two cloud disks that are attached to the cloud host during the intermediate flight, use the system disk to create a cloud host (this process requires an internal API), and attach the other disk to the cloud host as a data disk to complete data migration on the cloud host system disk.

3.1 Preparing for VMware environment in IDC

1. Connect the vSphere client to the vCenter server

Install a vsphere client, remotely connect to vCenter on the VMware management node in the IDC, and transfer the cloned image to a USB flash drive.

2. Export the image

If the system is shut down and offline, you can export the image in OVF or VMDK format. If the system cannot be exported offline, you can clone the system in the VMDK format.

3.2 Preparing the Transfer server environment

① Install the KVM hypervisor

Install the CentOS 7 OPERATING system and ensure that the hardware virtualization function is enabled. Ensure that the disk space is not less than the amount of data to be migrated. To install KVM virtualization, run the following command:

# yum install qemu-kvm qemu-key-tools libvirt  qemu-img
# yum install virt-*
# modprobe kvm
# modprobe kvm_intel
# systemctl start libvirtd
# systemctl enable libvirtd.service
Copy the code

(2) install virt – v2v

Virt-v2v is used to convert old systems, such as Windows 2000, Windows Server 2003, and Windows Server 2008, in consideration of compatibility problems of compatible cloud service providers, such as I/O and network acceleration, and high kernel versions.

For I/O acceleration, virt-V2V automatically injects the VirtIO driver. You can import VMS from one VM platform to another, and run the virt-V2v command to convert VMS running on other hypervisors. This allows you to run on Red Hat Enterprise Virtualization or a KVM managed by Libvirt. Currently, Virt-V2V can convert Red Hat Enterprise Linux VMS and Windows VMS running on Xen, KVM, and VMWare ESX/ESX(I). If necessary, VirT-V2V enables paravirtualization (VirtIO) drivers on the converted virtual machines.

Virt-v2v converts VMS from external virtualization platforms to KVM platforms. It can read Windows and Linux virtual machines running on VMware, Xen, Hyper-V, and other VM hypervisors and convert them to KVM in several ways: Libvirt, OpenStack, oVirt, Red Hat Virtualization (RHV), and more.

# yum install virt-v2v
Copy the code

3 Install the VirtIO driver on the host

The Virtio driver is a paravirtualization device driver for KVM VMS. The paravirtualization driver improves machine performance, reduces I/O latency, and improves throughput to a level close to that of bare VMS. Install the Windows VirtIO driver as follows:

# yum install libguestfs-winsupport libguestfs-tools
# wget https://fedorapeople.org/groups/virt/VirtIO-win/VirtIO-win.repo
-O /etc/yum.repos.d/VirtIO-win.repo
# yum install VirtIO-win
Copy the code

4. Install NTFS-3G to mount USB flash drives

Ntfs-3g supports reading and writing NTFS partitions in Linux, FreeBSD, Mac OS X, NetBSD, and Haiku operating systems. In addition to full file ownership and access, it supports all POSIX compliant disk operations. The goal is to provide trusted, feature-rich, high-performance solutions for hardware platforms and operating systems that users need to reliably interwork with NTFS.

# yum install epel-release
# yum install ntfs*
Copy the code

⑤ Compile and install NDB

An NBD installation can be used for remote storage and backup. The NBD driver simulates a block device, such as a disk or partition, on the local client, but the actual physical support is provided by a remote server connected over a network.

3.3 Image format conversion and VirtIO driver injection

Convert the disk files and inject the VirtIO driver, run the following command:

# export LIBGUESTFS_BACKEND=direct # virt-v2v -i VMX server2003. VMX -of qcow2 -o qemu-os. Run the virt-v2v -i VMX VMX file name - of qcow2 -o qemu -os Disk file path after Conversion command to convert both system disks and data disks by default. To save conversion time, you can modify the VMX file to convert only system disks.Copy the code

3.4 Using APIS to Create transfer system disks and Data disks

Create a cloud disk using the API as the system disk to start the cloud host and the data disk to import data (disks with system attributes are internal apis). The two newly created cloud disks are temporary turntables used to store the system and data imported to the image.

For details about the API, see github.com/ucloud

3.5 Remotely Mounting the Cloud Disk and Disk Copy

To reduce the migration process, you can directly mount the system disk and data disk of a USB flash drive to a newly created VM in network mode, and then copy the data on the USB flash drive to a cloud disk created temporarily. Due to the limitation of disk I/O and network bandwidth, the above scheme can save the transfer process of public network transmission and object storage US3 storage image.

The process is as follows: Mount data disks on usb flash disks to cloud disks using qEMU-NBD remote disks. Then unmount the cloud disk and mount it to the corresponding customer machine.

1 On the physical cloud server, mount the disk mirror of a USB flash drive to a specific port on the NBD

# qemu-nbd-r-t-v-f qcow2 -p 5000 web-sdc. Qcow2 // Note: 5000 indicates the port number, and web-sdc indicates the data disk mirroring.Copy the code

② Install qEMU-IMG on the transfer plane and mount the remote data disk image to the newly created cloud disk.

# qemu-img convert NBD ://10.23.xx.xx:5000 /dev/vdc // Note: 10.23.xx.xx is the internal IP address of the physical server, and /dev/vdc is the newly created cloud disk.Copy the code

3.6 Creating a Cloud Host and Mounting Data Disks

For the system disk and data disk whose data has been synchronized, you can use apis to create a cloud host for the system disk. For cloud data disks, uninstall the cloud disk on the transfer plane and mount it to the target cloud host to enable the cloud host creation and data disk mounting functions. UCloud has automated scripts and procedures to implement this process.

Four, experience,

After this migration, the support and restriction factors are as follows for your reference.

4.1 support

For VMware, this migration supports the following environments:

  1. Supports vSphere and ESXI.
  2. Migrate system disks and data disks.
  3. Supports OSS RHEL 3-7, Centos 3-7, Ubuntu 10.04, 12.04, 14.04, 16.04 or higher, Windows XP-Windows 10/ Windows Server2016.

4.2 limit

  1. Migration of hosts created in VMware Workstation may fail.
  2. The Sha-2 certificate must be enabled for Windows 7 and Windows Server 2008 R2.
  3. The operating system migration must be disabled and online hot migration is not supported.
  4. You need to uninstall the antivirus software.
  5. The virtualization platform tool needs to be uninstalled.

This article is from UCloud East China Architecture Center, if you have relevant needs or business consultation, welcome to contact or leave a message in the comment area!