Version 5.0

Migrate for Compute Engine architecture

Migrate for Compute Engine provides a path for you to migrate your virtual machines (VMs) running on-premises to VM instances running on Compute Engine on Google Cloud.

Migration architecture

The following diagram shows the architecture of a typical Migrate for Compute Engine deployment:

Migrate for Compute Engine architecture.

On-premises services for Migrate for Compute Engine

You install the Migrate Connector in your on-premises data center. The Migrate Connector runs as a service on the data center to:

  • Establish a secure datapath between the on-premises environment and Google Cloud APIs over port 443.

  • Perform storage operations against VM disks using the vSphere APIs.

  • Query on-prem VM inventory, stop and monitor source VMs using vSphere APIs.

See Install the Migrate Connector for instructions on installing the Migrate Connector.

Using a proxy to connect to Google Cloud APIs

In some environments, the Migrate Connector might not be able to make external internet requests. In this case, the Migrate Connector might have to access a proxy that is then allowed to make the connection:

Migrate Connector access over a proxy.

Private Google Access for on-premises hosts

Migration traffic can also be routed over VPN or Private Google Access instead:

Migrate Connector access over a VPN.

With Private Google Access, your on-premises hosts connect to Google Cloud APIs through a Cloud VPN tunnel or Cloud Interconnect by using one of the Private Google Access-specific domains and VIPs. If your environment uses Private Google Access, ensure that you have configured access correctly so that the Migrate Connector can access Google Cloud APIs.

See Dedicated interconnect for more.

Migrate for Compute Engine host project

The host project is the Google Cloud project where you enable the Migrate for Compute Engine API. From the host project, you manage migrations from sources to your migration targets.

Along with the Migrate for Compute Engine services, you also use the following Google Cloud services when performing a migration.

Compute Engine

Compute Engine lets you create and run virtual machines (VMs) on the Google Cloud. Compute Engine offers scale, performance, and value that lets you easily launch large compute clusters on Google's infrastructure.

Persistent disks are durable network storage devices that your Compute Engine instances can access like physical disks in a desktop or a server. The data on each persistent disk is distributed across several physical disks. Compute Engine manages the physical disks and the data distribution for you to ensure redundancy and optimal performance.

Google Cloud Console

Google Cloud Console is the graphical user interface for Google Cloud. Use the Google Cloud Console to manage all aspects of migration, access monitoring and logging data, and to configure authentication and authorization.

Cloud IAM

Identity and Access Management (IAM) lets you control access to specific Google Cloud resources and prevents unwanted access to your resources. To give users the ability to create and manage your Compute Engine resources, you can add users as team members to your project or to specific resources and grant them permissions using IAM roles.

About migration sources and targets

A migration is defined by:

  • The migration source: The on-prem data center hosting the VMs that you want to migrate.

  • The migration target: The Compute Engine instance on Google Cloud running your migrated VM.

    Migrate for Compute Engine data replication.

Migration sources

To start migrating you first configure a migration source that specifies the on-prem data center from which you'll be migrating VMs. As part of configuring a migration source, you must install the Migrate Connector on the data center. Once installed, you can then use the Google Cloud Console to browse the VMs in the data center available for migration.

Migration targets

You migrate the source VM to an instance of Compute Engine running in a specific project and region on Google Cloud. The Compute Engine instance is referred to as the migration target.

About Google Cloud projects

Google Cloud projects form the basis for creating, enabling, and using Google Cloud services including managing APIs, enabling billing, adding and removing collaborators, and managing permissions for Google Cloud resources.

About host projects

The project you use to control the migration process is referred to as your host project. Within your host project, you enable the Migrate for Compute Engine service and any other services required by Migrate for Compute Engine. Once enabled, you can begin migrating source VMs from your on-prem data center.

About target projects

You migrate VMs to Compute Engine instances in your target projects. You can use your host project as a target project, or you can migrate to additional projects.

Use multiple target projects to isolate migrated VMs from each other. For example, it is recommended to isolate a Compute Engine instance used for testing from ones used for production. You can use projects and VPCs to create sandbox environments for testing that are separate from your production environments. See Best practices for enterprise organizations for more.

You can also use the Deployment Manager to deploy a migrated VM to production across multiple projects. See Using Images from Other Projects for more.

About Compute Engine instances

As part of defining the migration target, you set the project of the Compute Engine instance. The characteristics of the target Compute Engine instance are based on the requirements of the migrated VM. You can customize the Compute Engine instance to specify:

  • Google Cloud project
  • Number of CPUs
  • Amount of memory
  • Disk type
  • Network configuration
  • many other options

You might have different requirements on the target Compute Engine instance based on whether the instance is being used for testing a migrated VM or being used in a production environment. For example, you might test the migrated VM in a single Compute Engine instance with 2 CPUs and 8 GBytes of RAM. Then, when you move to a production environment, you define target Compute Engine instances with different characteristics, such as 4 or 8 CPUs, and 16 GBytes of RAM.

What's next