VMware Cloud Well-Architected Framework for Google Cloud VMware Engine: Modernization Through Rehosting
Keeping your infrastructure consistent between your data center and public cloud allows the flexibility to seamlessly migrate to any cloud provider, giving you agility in changing times.
For many applications and businesses, it is more practical to rehost/migrate an application in its current state to the VMware Cloud than to modify it as it currently runs. Time may become the most constrained resource when considering which method to migrate an app when combined with the current staff’s daily pressure of running infrastructure. This is when it makes the most sense to move an application and its dependencies entirely to an instance of VMware Cloud without modifying its functionality. By doing so, you will be able to continue to provide the application functionality to the business as it currently is with minimal change while gaining the efficiencies of the VMware Cloud.
The VMware Cloud provides a common abstraction layer across different infrastructure providers and the tools to migrate workloads from one location to another.
Prior to moving workloads, a proper networking strategy for all workloads both on-premises and in the cloud needs to be identified and determined. The critical networking decisions related to migrating workloads consist of the overall IP strategy for workloads that are being migrated and the actual network traffic flows that impact the associated workloads and their downstream consumers.
Determine an IP Addressing Strategy
A critical decision to make early on, possibly in the Plan pillar, is an IP addressing strategy for workloads to be moved. This comes down to a decision between two possible scenarios.
Scenario 1: Workloads change their IP addresses
In the case where workloads will change their IP addresses, there are certain additional planning activities to be performed.
- A new IP addressing scheme must be determined for the migrated workloads.
- Application owners must be made aware of the new IP addressing schemes and must be prepared to update their applications accordingly.
- System administrators must make plans for changing workload IP addresses post-migration.
- Updates to DNS, Firewalls, Load Balancers, and other infrastructure services must be coordinated to reflect changes in IP assignments.
Scenario 2: Workloads keep their existing IP addresses
A common goal of a migration project is to minimize disruption to business. However, IP address changes tend to be very disruptive. For this reason, most migration projects will require that workloads keep their IP addresses post-migration.
In order to accomplish this, there are two choices:
- Migrate entire subnets worth of workloads at a time.
- Utilize a layer-2 network extension during the migration.
Since workloads that house applications aren’t always arranged neatly within the bounds of a given subnet, it is often impractical to plan migrations around subnet boundaries. For this reason, the most common strategy is to utilize a Layer 2 network extension during a migration. Network extensions provide a great deal of flexibility in how a migration is performed and allow entire applications to be migrated regardless of the layout of the underlying network addressing scheme.
Each application’s business value will determine whether an organization continues to evaluate its architecture for future functionality and investment in its modernization continuum as previously discussed. If an application is key to the organization and its business, the organization may consider different styles of deployment even after migration. This is normal for an application to be continually re-evaluated for best performance and functionality during its life cycle. The following are various styles of application architectures that can be deployed with cloud.
After a migration, an application may very well be in the perfect state for its business objective and provide full functionality and performance. As such, the application may not warrant further review or architecture investment. Often, an organization may simply achieve their cloud strategy objectives by moving the application and addressing the surrounding business dependencies like backup and load balancing services.
Applications can often be moved in their entirety to the cloud to achieve business objectives like moving to an OpEx (Operating Expenditure) model and speed cloud adoption. An application can further warrant investment in different architectures once in the cloud to further gain application functionality like application-level availability and redundancy. A large application with several functions in its architecture will often require careful planning and transition plans to minimize disruptions. The application components could be separated and transitioned one by one. As the transition occurs over time, an application will be in a state of transition.
For other applications, a portion of the service may be transitioned while maintaining the remainder in its current form. For example, if an application has a database component and an organization has plans to migrate the database component to a different architecture where they are taking advantage of native cloud database services or licensing benefits. This split application architecture may be the final design to minimize service disruptions, maximize cloud benefits, and maximize database features.
Thus, an applications actual modernization journey may continue in a progressive fashion in the modernization continuum.
Discuss Connectivity options and progression for long term use and additional services.
Automate Workload Migration
Moving workloads to the cloud with VMware can be significantly less impactful for businesses since VMware is consistent through the different platforms and you can utilize VMware tools to facilitate the migration of existing workloads. By leveraging VMware tools, your migration methods can be streamlined with good planning in migration waves.
Migration Waves and Events
A migration wave is a group of workloads that will be migrated concurrently as a single event.
A migration event can contain multiple migration waves that consists of the workloads to be moved and all the other steps planned like table-top activities, go/no-go checks, infrastructure updates (DNS, Load balancers, etc), Application teams testing, and Operations take-over.
The general recommendations for planning migration waves are as follows:
- Plan migration waves around applications whenever possible. In other words, attempt to migrate all workloads of a given application in as few waves as possible. This approach helps to keep intra-application traffic local to the SDDC.
- Plan to isolate larger/complex workloads to dedicated waves. Larger/complex workloads are typically databases or those VMs which have a high rate of change (lots of writes). These types of workloads tend to generate excessive amounts of delta data replication and will negatively impact other migrations.
- Choose the most appropriate migration option which fits the needs of each workload group. If a workload can afford to be powered off, then use a cold migration. Bulk migration is the preferred migration method for most workloads. Most workloads can tolerate the relatively small amount of cutover time imposed by a bulk migration. Additionally, VMware HCX bulk migration provides the opportunity to perform certain updates such as VM machine version and vmtools upgrades; another benefit is that it keeps a shutdown copy at the source, so it can be restored quickly instead of moving it back.
- Plan for contingency and recovery of the business activities even in the case some of the workload of the wave will have issue during the scheduled time.
- Make sure the operations, monitoring, and backup teams are aware of the Migration Events and disable/suspend specific automated tasks (i.e. taking snapshots, doing a filesystem backups, databases export) which will impact the migration.
- Automate the execution of the migration waves; often migration Tools offer Application Programming Interfaces (APIs) that allow writing scripts to batch the procedure; automation not only simplify the migration activities but reduce the human errors.
VMware Migration Solutions
With migration wave and events in mind, we can take advantage of several VMware based tools:
- VMware Content Libraries
- VMware vSphere Replication(embedded in SRM, HCX)
- VMware HCX
- VMware Cross vCenter vMotion
- API’s & PowerCLI
VMware Content Libraries
The Content Library service provides simple and effective management of OVF templates, ISO images, and scripts for vSphere administrators. The Content Library service lets you synchronize content across vCenter Server instances.
Content libraries are container objects for VM and vApp templates and other types of files, such as ISO images, text files, and so on. To deploy virtual machines and vApps in the vSphere inventory, you can use the templates in the library. You can also use content libraries to share content across vCenter Server instances in the same or different locations. Sharing templates and files results in consistency, compliance, efficiency, and automation in deploying workloads at scale.
By using Content Libraries, organizations can use vCenter to subscribe to their existing Content Libraries to move content up into a VMware Cloud platform without using third party tools or software.
VMware vSphere Replication
VMware vSphere Replication is an extension to VMware vCenter Server that provides a hypervisor-based virtual machine replication and recovery. It is also a part of VMware Site Recovery Manager, VMware Site Recovery Service, and VMware HCX.
vSphere Replication is an alternative to storage-based replication. It protects virtual machines from partial or complete site failures by replicating the virtual machines between the following sites:
- From a source site to a target site
- Within a single site from one cluster to another
- From multiple source sites to a shared remote target site
Another automated and supported method of moving VMware based workloads up to the cloud is by using vSphere Replication between vCenters on premise and in the cloud. This method is well understood and used by many organizations today. It is included in existing VMware vCenter licensing, VMware Site Recovery Manager, VMware Site Recovery Service, and VMware HCX.
VMware HCX™ is an application mobility platform designed for simplifying application migration, workload rebalancing and business continuity across data centers and clouds.
The HCX platform provides a hybrid interconnect to enable simple, secure and scalable application migration and mobility within and across data centers and clouds.
VMware HCX abstracts vSphere-based on-premises and cloud resources and presents them to the applications as one continuous resource. At the core of this is a secure, encrypted, high throughput, WAN optimized, load balanced, traffic-engineered hybrid interconnect that automates the creation of a network extension. This allows support for hybrid services, such as application mobility, on top of it. With HCX hybrid interconnect in place, applications can reside anywhere, independent of the hardware and software underneath.
The following figure illustrates the conceptual design for the HCX solution between two sites.
Virtual Machines can be moved to and from VMware HCX-enabled data centers using multiple migration technologies. The migration type depends largely on the use-case, number and size of migrated virtual machines, and network bandwidth. The migration type is also restricted by the HCX license available.
The following sections describe the available migration options.
VMware HCX Bulk Migration
This migration method uses the VMware vSphere Replication protocols to move the virtual machines to a destination site.
- The Bulk migration option is designed for moving virtual machines in parallel.
- This migration type can set to complete on a pre-defined schedule.
- The virtual machine runs at the source site until the failover begins. The service interruption with the bulk migration is equivalent to a reboot.
Note – for the most up-to-date list of requirements and restrictions when using HCX Bulk Migration, please refer to the Understanding VMware HCX Bulk Migration section in the VMware HCX online documentation.
VMware HCX vMotion
This migration method uses the VMware vMotion protocol to move a virtual machine to a remote site.
- The vMotion migration option is designed for moving single virtual machine at a time.
- VM is migrated while powered on. There is no service interruption during the VMware HCX vMotion migration.
- The vm data is encrypted by HCX.
Note – for the most up-to-date list of requirements and restrictions when using HCX vMotion, please refer to the Understanding VMware HCX vMotion and Cold Migration section in the VMware HCX online documentation.
VMware HCX Cold Migration
This migration method uses the VMware NFC protocol. It is automatically selected when the source virtual machine is powered off.
Note – for the most up-to-date list of requirements and restrictions when using HCX Cold Migration, please refer to the Understanding VMware HCX vMotion and Cold Migration section in the VMware HCX online documentation.
VMware HCX Replication Assisted vMotion
VMware HCX Replication Assisted vMotion (RAV) combines advantages from VMware HCX Bulk Migration (parallel operations, resiliency, and scheduling) with VMware HCX vMotion (zero downtime virtual machine state migration).
Note – for the most up-to-date list of requirements and restrictions when using HCX Replication Assisted vMotion, please refer to the Understanding VMware HCX Replication Assisted vMotion section in the VMware HCX online documentation.
VMware HCX OS Assisted Migration
This migration method provides for the bulk migration of guest (non-vSphere) virtual machines using OS Assisted Migration to VMware vSphere on-premises or cloud-based data centers.
Note – for the most up-to-date list of requirements and restrictions when using HCX OS Assisted Migration, please refer to the Understanding VMware HCX OS Assisted Migration section in the VMware HCX online documentation.
Figure 1 summary table
VMware Advanced Cross vCenter vMotion
The Advanced Cross vCenter Server vMotion (XVM) helps to migrate virtual workloads between vCenter Server instances, without the requirement for Enhanced Linked Mode (ELM) or Hybrid Linked Mode (HLM). This means it’s possible to migrate virtual machines (VMs) between vCenter Servers that are in different Single Sign-On (SSO) domains. The XVM capability is embedded into the vSphere Client with the vSphere 7 Update 1c release.
From within the vSphere Client, two workflows are available to migrate workloads between vCenter Servers. Either using the ‘import VMs’ option in the Hosts and Cluster view to import VMs from a target vCenter Server Appliance (VCSA), or by selecting VMs and opting for ‘Migrate’ in the menu.
For detailed information, visit Advanced Cross vCenter Server vMotion Capability.