The following blog covers some common processes and tools used to migrate databases from on-premises (Physical or VMware) to Google Cloud VMware Engine (GCVE). Many customers choose this lift-and-shift migration approach as a first step to quickly migrate databases into Google Cloud before beginning database upgrade and modernization workstreams. 

Google Cloud VMware Engine

GCVE is a fully-managed service that lets you run the VMware platform in Google Cloud. This solution includes vSphere, vCenter, vSAN, NSX-T, and corresponding tools. A GCVE VMware environment runs natively on Google Cloud bare metal infrastructure in some Google Cloud locations, and the GCVE service includes all the features required to help consume the VMware platforms efficiently and securely. Each cluster consists of a minimum of three nodes, and provides high availability through vSphere High Availability. For more information on vSphere HA, review the following link:  How vSphere HA Works.

Key points to remember: 

  • One GCVE private cloud = 1 vCenter + 1 NSX-T Manager + 1 HCX Manager
  • GCVE does not allow overlapping CIDR ranges for vSphere or HCX management networks.
  • A cluster has to have, at minimum, three nodes.
1 GCVE.jpg
Connecting on-premises VMware to Google Cloud VMware Engine

For more information on connecting to GCVE, see the Private Cloud Networking for Google Cloud VMware Engine whitepaper.

Database migration tooling

A number of tools exist to migrate servers to GCVE, and three common options are listed below. 

VMware HCX
VMware HCX is used to migrate VMs from your on-premises VMware environment to Google Cloud VMware Engine. GCVE requires that the HCX Connector OVA be downloaded, installed, deployed, and configured both on-premises and on the private cloud. There is a 1:1 correspondence between on-premises vCenters and HCX Connector appliances. For example, if there are 10 datacenters with VMware installations, each vCenter will need a connector installed. 

For more information about how to use VMware HCX to migrate VMs from your on-premises environment to your private cloud, see Migrating VMware VMs using VMware HCX.

PlateSpin Migrate
PlateSpin Migrate is a data center migration tool that decouples the workload infrastructure from its software (operating system, applications, and data) to migrate physical servers to target server platforms like VMware hypervisors. A common use case involves a two-step migration when migrating to GCVE, starting with P2V on-premises and then V2V to GCVE using HCX. See Platespin documentation for more information on supported workloads.

A note on migrating Windows clusters: Migrating Windows clusters, such as SQL Server Failover Clusters (FCI), can be tricky due to network connectivity, required IP changes and shared storage components.  In many cases it may make sense to build a target VM in GCVE and migrate the data, rather than migrating the cluster.

Database replatform

In some cases physical or virtual servers are not able to be migrated from on-premises to GCVE due to complexity or migration tool compatibility requirements. In these cases, VM templates are created in GCVE containing the required software configurations and tooling including OS, database, monitoring software, and operations software such as the Actifio database connector. VMs are then provisioned from these templates as migration targets for the database workloads. The strategy then used to migrate to these targets is largely platform- and migration-window dependent. 

Common database replatform strategies are listed below by database platform:

2 GCVE.jpg

For legacy database platforms such as Oracle 8i and 9i, the Stromasys Charon emulator may allow legacy databases to run on GCVE. 

Once databases are migrated to GCVE, backups may be configured using Actifio, and vSphere Replication is configured to support database DR requirements. Refer to the Actifio Go Support Matrix for supported operating systems and databases. Note that in order for a database to be backed up using the Actifio connector, both the operating system and the database version must be supported. If the database is not supported by Actifio, consider backing it up to an attached volume using a database-specific backup tool (RMAN, mysqldump, pg_dump, etc.), and then configure Actifio to snapshot the disk volume containing the backups on the required schedule. 

If the host requires cross-region disaster recovery, a common next step is to configure vSphere replication to replicate VMs between Primary and DR regions.  Note that while VMware Site Recovery Manager supports the automation of replication and recovery of VMs, it is not required. With Site Recovery Manager, scripting and automation is possible using VMware PowerCLI. 

After an initial snapshot is completed, incremental snapshots are then scheduled at the required interval to support RPO and RTO requirements. When performing a failover to a DR region it’s important to plan for IP Address changes and DNS updates, due to subnet changes. Depending on the database, certain database configuration files such as tnsnames.ora and listener.ora may need to be updated to reflect the new host IP address.  If users connect to your database via a DNS CNAME, the CNAME record will also need to be updated.

Note that not all databases are supported by vSphere replication. View the VMware 3rd Party Solution Interoperability matrix to determine if your database is supported by vSphere replication. If your database is not supported by vSphere replication, you may choose to implement a database-specific feature such as replication, log shipping, Always On Availability Groups, etc. 

Database architecture changes may be handled during the initial migration or deferred until later. For example, an MSSQL 2016 Failover Cluster (FCI) on premise may not be migrated to an FCI in GCVE, since GCVE supports HA through vMotion, and vSphere Replication and Actifio may meet the DR requirements. 

Looking forward: Modernization and Hybrid GCE – GCVE opportunities

Once databases and applications are migrated to GCVE, new workstreams focusing on application modernization and database modernization can begin. A subsequent project may include an application modernization initiative to re-architect an application to run partially in GCE or GKE and in GCVE. In this case, a Hybrid GCE/GCVE operating environment comes into play where an application could be migrated to GCE and the database would remain in GCVE.  

For more information on GCVE networking, connectivity options and common use cases, review private cloud to on-premises, private cloud to VPC and Private Google Access.

Conclusion

A lift-and-shift migration to GCVE is a popular strategy to migrate databases from on-premises to GCVE. Once the initial migration is complete, organizations can start utilizing native Google services alongside GCVE to transform their applications and databases depending on their business needs.