If it’s not a problem for the client to turn off the virtual machine for a day or two (or not other options), then it is possible. But if downtime should be a maximum of an hour, then this method will not work. Today I’ll tell you what tools will help you migrate to the cloud with minimal downtime and how the migration process works with us.
Migrating with Veeam Backup and Replication
Everyone knows Veeam Backup and Replication as a tool for creating backups and replicas. We use it for migration between our sites and for transporting clients with private virtualization to our cloud. Client virtual machines are replicated to our vCenter, after which the engineer adds them to vCloud Director.
Primary replication is performed on an enabled virtual machine. At the agreed time, the machine on the client side turns off. Replication starts again to transfer the changes that have occurred since the first replication. After that, the virtual machine starts already in our cloud.
Usually from the moment the machine is turned off on the client’s infrastructure and until the moment it is turned on, no more than half an hour, but rather 15–20 minutes, pass in our cloud.
At the same time, the original virtual machine remains on the client’s site. If suddenly something goes wrong, you can always roll back and turn it on. For the client, this method is also convenient in that it does not require Veeam from him.
Case 1
The client had its own virtual infrastructure based on VMware - 40 VMs with a capacity of 30 Tb. The equipment on which the cluster was deployed is already outdated, and the client decided not to mess with the purchase of a new one and move to a public cloud. The requirement for downtime of critical systems was no more than an hour. As a tool they chose Veeam Replication. The plus was also that the client’s Internet provider was present in our data center, which allowed us to organize a good channel. Migration took about a month, while switching was simple, it took up to 30 minutes to one group of virtual machines.
Migrate with Veeam Cloud Connect
Veeam Cloud Connect is a tool that helps you configure virtual machine replication and run replicas in the service provider's cloud. After the update in 2019 , it became possible to replicate virtual machines directly to vCloud Director. The only condition is that on the client side, your Veeam Backup and Replication must be deployed at least version 9. In short (the detailed version is here ), the whole process looks like this.
VCloud Director creates an organization with the necessary resources and networks. In Veeam Cloud Connect, we create an account, the client connects to it from our Veeam B&R, selects the DataLine provider and organization, and sets up tasks for replication. In addition to the fact that during such a migration it will be simple within 15–20 minutes, the client does not depend on the technical support of the provider and manages the entire process independently: it creates replication tasks, replication itself, turns off the machines and starts their start on a new site.
Case 2
The client infrastructure from where the migration was planned was located in Belarus. It was necessary to transport 90 VMs with a total volume of 27 TB, despite the fact that the Internet channel was 100 Mbps. If you make a backup and immediately upload it to our cloud, then for some VMs this would take several days. During this time, a large delta would grow on the VM, and this could already adversely affect the performance of the machines or, even worse, the place on the datastore ran out. They acted as follows: first, the client made a local full backup and transferred a copy of it to us in the cloud via Veeam Cloud Connect. Then he made and threw the increment into the cloud. The original virtual machine continued to work. After shutting down the VM, the client made another increment and also transferred it to the cloud. On our side, we deployed a virtual machine from a full backup, and then rolled two increments onto it. Such a scheme allowed us to minimize downtime to 2 hours when switching to our site.
Migration with VMware vCloud Availability
In March of this year, VMware released vCloud Availability 3.0, which allows virtual machines to migrate between different clouds (vCloud Director - vCloud Director) and from private client virtualization stands to the cloud (vCenter - vCloud Director). The main convenience is integration with the vCloud Director interface. This greatly simplifies replication management and minimizes downtime when switching.
Using this tool, we migrated one of the clients from our Moscow cloud to our cloud in St. Petersburg. It was necessary to transport 18 virtual machines with a total capacity of 14 TB. For the client, an organization was created in the St. Petersburg cloud and the necessary networks were organized. Then, from the vCloud Director interface, the client switched to the vCloud Availability settings, created replication tasks, and switched to the St. Petersburg site at a convenient time. Downtime during switching was 12 minutes.
The migration scheme between the DataLine clouds in St. Petersburg and Moscow.
VCloud Availability has a mechanism for migrating VMs from a client site to our cloud. To do this, a special vCloud Availability application is deployed in the vCenter client. After a simple setup, you are connected to the cloud and migration tasks are configured. The client also independently manages the entire process, and the migration time is minimized.
A diagram of the migration of virtual machines from a private installation to the cloud.
VMware vCloud Availability has many other use cases; we’ll talk about them in a separate article soon.
Preparing for Migration
To select a tool and actually proceed with migration, you need to decide on the following points:
Where are we migrating from. If you are migrating from a private solution, then you have complete freedom in choosing tools. If you move out of the provider, then it’s more difficult. Most likely, linking the infrastructure of the two providers and simply dragging the VM will fail due to security reasons. Sometimes the provider, whom the client is going to refuse, completely begins to be harmful and takes time. You can leave the provider in the old fashioned way: by uploading the VM to disks and FTP or migrate at the application level. The name of the latter is arbitrary, and it looks something like this.
Case 3
It was necessary to migrate the client’s SAP system from a European provider: 34 VMs with a volume of 54 Tb. Resources were allocated to the client in our cloud. Between us and the infrastructure of the European provider, network connectivity was organized. Application servers have been redeployed, with a roll-up of the necessary configurations. Large databases migrated through uploading backups to our cloud. Next, replication between the databases on our and the source sites was configured. At the agreed time, we switched to the databases in our cloud.
The amount of data and the Internet channel. We usually ask the client to provide unloading on systems with parameters of memory, CPU, disks. We estimate whether the channel is enough to directly send replicas or backups of virtual machines.
Valid simple. For different systems and, accordingly, virtual machines, it can be different depending on their criticality for business. Usually, a client comes with ready-made requirements for downtime during migration, and based on this we choose the right tool and migration plan. We try to plan the final switch to night or weekend, so that even a slight downtime is not noticeable to the end users of the client.
Based on these data, you can choose a tool and proceed with the migration itself. Here's what happens next.
- Configuring network connectivity. We organize network connectivity between our cloud and client infrastructure. Virtual machines will be copied over this network. If Veeam Backup and Replication is used, then this is a dedicated channel, less commonly a VPN channel. If Veeam Cloud Connect, then everything goes through the Internet or the same dedicated channel.
Then the network is configured for the VM in the cloud. Cars usually move in groups and more than one day. After the VMs were transferred to us and launched, they should interact with the machines that still remain at the starting site. - Migration schedule. When there are a lot of cars, it is reasonable to break them into groups and transport them in batches. Together with the client, we agree on a plan in which we prescribe when and which machines move and when the final replication and switching to a new site will be performed.
- Test migration. We migrate the test virtual machine and check whether everything is configured correctly: network connectivity between sites, the availability of the virtual machine for machines on the source site, account rights, and more. Such a test helps to avoid hitch during the stage of combat migration.
That’s all for me. In the comments, ask questions and talk about your migration experience.