Share:

In the past, moving a large application estate to the cloud involved second-guessing connectivity, dependencies, configuration and how the application should be re-installed in the cloud. Once the critical applications were installed, a testing and acceptance cycle was required, making the timeline for the migration of a single application extend into months if not longer. Applying a similar approach to hundreds of applications made large data centre migrations difficult and unpredictable. In recent years, continuous block replication services have made moving workloads from physical or virtual infrastructure to cloud much easier, enabling the concept of high-velocity migrations. The options to lift and shift workloads in Google Cloud Platform (GCP) rotate around Velostrata, recently renamed Migrate for Compute Engine.

How should you approach migrations?

In the same way that it’s not always possible to modernise every workload part of a large portfolio, I would not recommend moving every and each application using a lift and shift approach. Specific business-critical or revenue-generating applications might benefit  from a complete transformation using a cloud-native design, which also offers cost and performance benefits

My preferred approach when approaching a large cloud migration to Google is to define clear criteria to assign the 6R’s (inspired by this Gartner article published in 2010) based on technical and business drivers. Technical data points can be collected using an automated discovery tool, such as Cloudamize. Cloudamize, or similar tools available in the market, can help with providing a like for like right-sized running costs for running in GCP, and the many data points which can be used to drive the application assessment. Business data points are usually collected with surveys and/or interviews, but the specific approach might be different according to your specific needs. Depending on the size of the portfolio to assess the amount of information collected will change.

All the applications which are deemed technically movable to GCP and will not benefit from transformation, will be marked as Rehost and be moved as lift and shift.

What options do you have on GCP?

Great, you have assessed your applications and decided to lift and shift some to GCP. What’s next?

As mentioned, Migrate for Compute Engine is the best option for a plain rehost. It supports migration from an on-premise VMware environment or from other cloud providers. A wide range of operating systems are supported:

  • Windows 2003 and newer
  • Linux with kernel 2.6+ for offline migrations
  • Linux with kernel  3.13+ for online migrations

Additional information on supported OS are available here.

How do you start?

We assume that you have set up your cloud environment with at least a project and a VPC connected back to your on-premise datacentre. In addition to the cloud environment, some network ports have to be opened in order to allow communication between your GCP environment and VMware.

Once network connectivity is set up, you can go ahead and deploy the Compute Engine Manager. The Manager will guide you through a wizard, which will create a service account and a VM which will run the Manager itself.

Next, in order to use Migrate for Compute Engine, you will require deploying a backend VM on your VMware environment. The detailed instructions can be found here but what is worth mentioning two main watchpoints:

  1. The size of the VM you have to create will vary depending on the number of servers to lift and shift. The number of servers replicating will also have an impact on your network bandwidth requirements
  2. The back VM on vSphere will require a specific set of permissions that are granted as a Service role. Depending on your security requirements address this need early, in order to avoid delays during the migration

The last step between you and your first migration is setting up a Cloud Extension. The Extension will deploy two Edge nodes, which will take care of receiving the replicated data from on-premise and storing it in Cloud Storage as a staging area.

Great, you are ready now to migrate your first workload!

Testing a VM in GCP

Completing the setup is probably the most time-consuming activity required in order to use Migrate for Compute Engine. Moving a VM from on-premise is as simple as using the vSphere client to choose the VM you would like to run in the cloud and then select “Migrate for Google Compute Engine Operations > Run-in-Cloud”.

One of the main differentiations between Migrate for Compute Engine and other tools which can be used for lift and shift, is that “Run-in-Cloud” doesn’t actually migrate the VM. Instead, the tool will sync enough of the VM disk to allow a bootstrap while the remaining data is streamed and cached locally on GCP. This approach reduces the time required to test VMs, especially when the on-premise storage accounts for several hundreds of GBs.

The Migrate for Compute Engine documentation is fairly extensive, so I won’t list all the steps here. What is worth pointing out when testing VMs in the cloud is:

  1. When selecting Storage Policy, “Write Back” will write any changes made on GCP back to on-premise. This setting can be dangerous, especially if you have to adapt the VM in order to run in GCP. We would recommend using the much safer “Write Isolation” in order to avoid affecting your live workloads.
  2. Even if ‘Write ~Isolation’ is enabled, your VM will very likely interact with other VMs (databases, application servers etc.) which might or might not move at the same time. Also, in the case of Windows workloads, the VM might be joined to your corporate active directory domain. It is important to check the network tags applied at the VM in order to make sure that interaction with other systems is kept under control.

Once your testing is completed, Migrate for Compute Engine allows failover the storage from on-premise to GCP, effectively shutting down the source VM and cutting over to the one in the cloud.

Can you do more?

Often a straight lift and shift is not enough as some changes will be required to make the VM work correctly.

Migrate for Compute Engine supports the execution of adaptation scripts on boot. The scripts can be used to change network interfaces, uninstall tools that are not required in the new environment, or even temporarily disable services which will cause issues during testing.

For both Windows and Linux hosts, the way the scripts work is the same: the scripts have to be placed in a specific directory in the source VM and will be executed according to specific rules.

In addition to automation scripts, Migrate for Compute Engine supports upgrading the version of Windows from 2008 R2 to a more modern (and cloud-friendly) Windows 2012. Your mileage may vary, depending on the complexity of the VM and if any of the software installed has hard dependencies to Windows 2008, but the possibility of performing an in-place upgrade which is orchestrated by Migrate for Compute Engine is a huge advantage over other software that performs similar block replication.

Finishing up

Migrate for Compute Engine, has taken all the features of Velostrata and improved with additional features such as the in-place upgrade, and more recently the possibility of migrating into a container rather than a VM.

If you need to migrate workloads quickly, then GCP is a great choice as your target cloud. Our experience at Cloudreach is that Migrate for Compute Engine increases the velocity of migrations into the platform.

For more information about our Google Cloud practice click here. Get in touch if you would like to discuss cloud migrations and how Cloudreach can help your organization moving to GCP!