About 7 years ago, the very first projects moved to our cloud simply and unpretentiously. Images of virtual machines were uploaded to an FTP server, or they were brought on hard drives. Then, through a special import server, the VMs were uploaded to the cloud.
If it is not a problem for the client to turn off the virtual machine for a day or two (or there are no other options), then this 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.
Migration with Veeam Backup and Replication
Everyone knows Veeam Backup and Replication as a tool for creating backups and replicas. We use it to migrate between our sites and to transfer clients from private virtualization to our cloud. Client virtual machines are replicated to our vCenter, after which the engineer adds them to vCloud Director.
Primary replication runs on a powered-on virtual machine. At the agreed time, the machine on the client side shuts down. Replication is run again to carry over 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 to the moment it is turned on in our cloud, it takes no more than half an hour, but rather 15ā20 minutes.
At the same time, the original virtual machine remains on the client site. If suddenly something goes wrong, you can always roll back and turn it on. For the client, this method is also convenient because it does not require the presence of Veeam.
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 was already outdated, and the client decided not to get involved in the purchase of a new one and move to a public cloud. The downtime requirement for critical systems was no more than an hour. Veeam Replication was chosen as a tool. It was also a plus that the client's Internet provider was present in our data center, which made it possible to organize a good channel. Migration took about a month, downtime when switching was up to 30 minutes per group of virtual machines.
Migration with Veeam Cloud Connect
Veeam Cloud Connect is a tool that helps you set up virtual machine replication and run replicas in a service provider's cloud. After updating to year, it became possible to replicate virtual machines directly to vCloud Director. The only condition is that Veeam Backup and Replication must be deployed on the client side at least version 9. In short (detailed version ), then the whole process is as follows.
An organization is created in vCloud Director with the necessary resources and networks. In Veeam Cloud Connect, we create an account, the client connects to it from his Veeam B&R, selects a DataLine provider and organization, and sets up tasks for replication. In addition to the fact that with such a migration, downtime will be within 15ā20 minutes, the client does not depend on the providerās technical support in any way and manages the entire process independently: creates replication tasks, replication itself, turns off the machines and starts them up on a new site.
Case 2
The client's 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 it would take several days. During this time, a large delta would have grown on the VM, and this could already have a negative impact on the performance of the machines or, even worse, the datastore ran out of space. We acted as follows: first, the client made a local full backup and transferred its copy to our cloud via Veeam Cloud Connect. Then I made and transferred an increment to the cloud. The original virtual machine continued to run. After turning off 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 made it possible to minimize downtime to 2 hours when switching to our site.
Migrating 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 the replication management process and minimizes downtime during switchover.
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. An organization was created for the client in the St. Petersburg cloud and the necessary networks were organized. Further, from the vCloud Director interface, the client went to the vCloud Availability settings, created replication tasks, and switched to the St. Petersburg site at a convenient time for him. Idle time when switching was 12 minutes.
Scheme of migration between DataLine clouds in St. Petersburg and Moscow.
vCloud Availability has a mechanism for migrating VMs from the client's site to our cloud. To do this, a special vCloud Availability application is deployed in the client's vCenter. After a simple setup, you connect to the cloud and set up migration jobs. The client also manages the whole process independently and the migration time is kept to a minimum.
The scheme of migration of virtual machines from a private installation to the cloud.
VMware vCloud Availability has many other use cases, we will cover them soon in a separate article.
Preparing for migration
To choose a tool and actually start 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 the tools. If you move out from the provider, then it is more difficult. Most likely, linking the infrastructures of two providers and simply dragging the VM will not work due to security reasons. Sometimes the provider, from which the client is going to refuse, even starts to be harmful and takes time. You can move out of the provider in the old fashioned way: by uploading the VM to disks and FTP, or by migrating at the application level. The name of the latter is conditional, 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 capacity of 54 TB. The client was allocated resources in our cloud. Network connectivity was organized between us and the infrastructure of the European provider. The application servers were re-deployed with the necessary configurations rolled up. Large databases migrated by uploading backups to our cloud. Next, replication was configured between the databases on our site and the source site. At the agreed time, we switched to databases in our cloud.
Data volume and internet channel. We usually ask the client to provide an upload by system with parameters of memory, CPU, disks. We evaluate whether the channel is enough to directly send replicas or backups of virtual machines.
Allowed simple. For different systems and, accordingly, virtual machines, it can be different depending on their business criticality. Typically, a client comes with ready-made requirements for migration downtime, and based on this, we select the appropriate tool and migration plan. We try to schedule the final switchover at night or on weekends so that even minor downtime is not noticeable to the customer's end users.
Based on this data, you can choose a tool and proceed with the migration itself. Here's what happens next.
- Setting up network connectivity. We organize network connectivity between our cloud and the client's infrastructure. Virtual machines will be copied over this network. If Veeam Backup and Replication is used, then this is a dedicated channel, less often 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 not one day. After the VMs have been moved to us and launched, they must interact with the machines that still remain on the original 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 are moving and when the final replication and switching to a new site will be performed.
- Test migration. We migrate the test virtual machine and check if everything is configured correctly: network connectivity between sites, availability of the virtual machine for machines on the source site, account rights, and so on. Such a test helps to avoid hitches at the stage of combat migration.
That's all for me. Feel free to ask questions and tell us about your migration experience in the comments.
Source: habr.com
