Holodeck 5.1.1 Multi-site HCX

HCX Nested Environment Overview

The Holodeck 5.1.1 Multi-site configuration for HCX uses the following network architecture.

Prerequisites

Holodeck 5.1.1 Holo-Console deployed
Ubuntu 18.04 Bionic OVA is available in C:\Users\Administrator\Downloads
Holodeck environment is configured to allow internet access outbound for HCX License Activation
Download the VMware HCX Cloud appliance (this guide is tested with HCX 4.9) from VMware.com to C:\Users\Administrator\Downloads on the Holo-Console (Be sure you are downloading the Cloud appliance, not the connector)
Fresh unmodified VLC-Holo-Site-1 and VLC-Holo-Site-2 deployments
- Built via VLC CLI
- The INI file for the default configuration was NOT modified below line 59 on either site (Site-1 shown)

Prepare Environment and Configuration files

In Holodeck the automated configuration files have already been created and just need to be modified for prior to HCX can be deployed or utiilized

Step 1: Pull the environment's NSX Data Center Enterprise Plus Key

On the Holo-Console, Login to Holo-Site-1 Management NSX instance (admin/VMware123!VMware123!)
Navigate to System->Licenses and copy the NSX Data Center Enterprise Plus key

Step 2: Configure the HCX-Multi-Site-Inputs.ini file. This file will be used to deploy HCX for both sides of the Holodeck multi site environment.

Open C:\VLC\VLC-Holo-Site-1\Holo-Lab-Support-Files\Multisite-HCX-Lab\HCX-Multi-Site-Inputs.ini for editing
For variable ActivationKey paste the NSX license that was pulled from NSX Manager
Save the file

Initialize Internet Explorer (First run security)

A core I.E. security check will block the HCX deployment automation. This step is necessary to clear that security check one time after deployment of a new instance of Holo Console.

On the Holo-Console, click Start -> Windows Accessories -> Internet Explorer
Click don't use recommended settings
Leave send do not track requests blank
Click OK

Add Holodeck HCX Infrastructure

In order to support the HCX lab it is necessary to create additional Port groups on Site-1 vCenter Server

On the Holo-Console Open a PowerShell window as administrator
cd to:\VLC\VLC-Holo-Site-1\Holo-Lab-Support-Files\Multisite-HCX-Lab\
Run 01-Holodeck-HCX-Infrastructure.ps1

Deploy HCX Opencart infrastructure

The HCX lab utilizes a separate set of virtual machines located in Site-1, this script deploys one instance of MySQL and five instances of Apache configured specifically for the HCX lab exercise

Open a PowerShell window NOTE: Ensure it is a 64 bit PowerShell session versus an X86 session.
Change directories to C:\VLC\VLC-Holo-Site-1\Holo-Lab-Support-Files\Multisite-HCX-Lab
Run .\HCX-OC-Create.ps1

Once the 6 HCX OpenCart virtual machines are created they need to be reconfigured for use in the HCX Migration lab by reassigning IP addresses and moving to new port groups.

Run .\HCX-OC-Finalize.ps1

Once the finalize script reconfigures the HCX OpenCart VMs for use in HCX lab; verify the database and web servers are running on the correct Port Groups.

Access the Site-1 Management vCenter Server instance. In Chrome on the "Bookmarks Bar" click on "Holodeck-5.1.1 > Holo-Site-1 > Mgmt Domain > Mgmt-vCenter"
Log into vCenter (administrator@vsphere.local/VMware123!)
Browse to Virtual Machines in the left pane and expand "vcenter-mgmt.vcf.sddc.lab > mgmt-datacenter-01 > Holodeck"
Validate the both the Apache and DB servers are on the appropriate Port Group:
- HCX-OC-Apache-A is on Port Group HCX-OC-WEB-NET and running with IP address 10.2.1.2
- HCX-OC-MySQL is on Port Group HCX-OC-DB-NET and running with IP address 10.2.2.2
Verify you can access the OpenCart instance by opening a browser to http://10.2.1.2

Deploy HCX

The included PowerShell script to deploy HCX is specific to the Holodeck configuration and utilizes the ini file that was modified earlier. This script will deploy and configure the HCX components on both sites of a Holodeck Multi-Site environment

Open a PowerShell window NOTE: Ensure you open a 64 bit PowerShell session versus an X86 session.
Change directories to C:\VLC\VLC-Holo-Site-1\Holo-Lab-Support-Files\Multisite-HCX-Lab
Run .\02-Holodeck-deployHCX.ps1
When prompted, select the C:\VLC\VLC-Holo-Site-1\Holo-Lab-Support-Files\Multisite-HCX-Lab\HCX-Multi-Site-inputs.ini file and click open
This kicks off the HCX deployment automation and will take approximately 45 minutes to complete.

Migrating workloads with HCX

Holodeck 5.1.1 HCX Lab Overview

The Holodeck 5.1.1 HCX Workload Onboarding Lab shows how to bring existing applications on VLANs into VCF with VCF overlay networking. This lab simulates a real world problem where customers are required to migrate legacy applications, running on legacy network hardware, into a modern VCF private cloud, running software defined networking and security. The Holodeck 5.1.1 multisite configurations was designed specifically to support this HCX lab configuration. A legacy OpenCart application sits on VLAN 17-18 on site 1 and will be migrated to VCF overlay networks on site 2

Prerequisites

This lab guide assumes the following Holodeck 5.1.1 guides have been completed within your deployment

4- Holodeck 5.1.1 VLC-Holo-Site-1 and VLC-Holo-Site-2 deployed using CLI method with zero modifications other than physical host details to the VLC INI files
5 - Holodeck 5.1.1 Post Deployment Updates completed
9 - Holodeck 5.1.1 Deploy HCX Multi-Site complete, including virtual machine build

Lab Overview

In this lab, we will use the OpenCart Apache webserver VMs to demonstrate the capabilities of HCX Multi-Site. You will migrate HCX-OC-Apache VMs to VLC-Holo-Site2 using multiple migration methods built into HCX. When all the Apache VMs are fully migrated, you will then migrate the Network Gateway from Site1 router to site 2 router. This will simulate an actual network subnet gateway migration. Currently the logical view of the environment looks like this.

User access to the HCX-OC-Apache web servers from Holo-Console is via Site-1 Cloud Builder acting as core datacenter infrastructure for Site-1.

To migrate the OpenCart VMs without downtime and without having to re-IP address the application, we’ll need to extend the L2 network to Site-2. HCX makes this process easy.

Review legacy networks

Login to Site-1 Management domain vCenter Server instance.
Click the network icon
Expand the selection to see networks on mgmt-vds01
Select HCX-OC-Web-Net
Notice it is a VLAN backed portgroup on VLAN 17

Extend L2 Network to Site-2

Extend HCX-OC-WEB-NET

Login to Site-1 Management domain vCenter Server instance.
Click the menu icon in the upper left
Click on HCX

Select Network Extension
Click Create New Network Extension

Select HCX-OC-WEB-Net then click next

Click on Select for Destination First Hop Router
Select VLC-Tier-1

Click on Gateway IP and set 10.2.1.1/24

Click Submit
Monitor progress on the Network Extension page

HCX Advanced Migration Types

HCX Advanced has three options for migrations, vMotion (Live), Bulk Migration (warm), and Cold Migration. Each of these migration options has pros/cons. Let's dive into the technical details of each of these as they pertain to HCX and VMware Cloud.

Cold Migration

This migration option is not listed in the UI for migration but is instead dependent on the power status of the VM you have chosen to migrate. If the VM is powered off, a cold migration process occurs by default. Cold migration uses the NFC protocol to migrate the VM. During a cold migration, the Virtual Machine IP address and MAC address remain preserved. Cold migrations must satisfy the same requirements as vMotion.

HCX vMotion

Using HCX vMotion leverages the VMware vMotion protocol to move a live VM to the target site. During the migration, HCX copies the active state of the VM, including virtual disks, CPU cycles, RAM, IP address, and MAC address. Listed in the HCX documentation are several prerequisites for HCX vMotion. HCX vMotion allows you to live-migrate one VM at a time. You also have the option to select upgrading the VM tools or VM hardware during HCX vMotion. Note; selecting these options does not automatically update either of these components during the vMotion process. Instead, it creates a pending operation in the VM. These updates are then completed after the next reboot of the VM, as these changes require the VM to be powered off.

Bulk Migration

HCX Bulk Migration uses the host-based replication protocol to copy the disks of the VM to the target site. The VM can remain powered on during this disk replication period. Once the disk replication is complete, a delta sync occurs on the disk(s). After the delta sync is complete, HCX proceeds with the switchover process. During the switchover phase, the source VM is powered off, and the replica is powered on in the target site. The switchover process can run immediately or wait until a scheduled downtime window. The downtime period of a bulk migration is concise. The workflow for this process is; power-off source, then, power-on target. Bulk migration, as the name implies, can occur on multiple VMs at once. Bulk Migrations do not require Layer 2 extension but are recommended for a faster switchover. Personalization scripts can be run during the switchover phase, allow you to change the IP address or make other VM modifications. Additional HCX automated options include; updating the VM tools driver(s), and VM Hardware level. These settings are all selectable from the HCX UI. They are then executed immediately to the target side replica VM during the switchover process.

Perform Cold Migration

This migration option is not listed in the UI for migration but is instead dependent on the power status of the VM you have chosen to migrate. If the VM is powered off, a cold migration process occurs by default. Cold migration uses the NFC protocol to migrate the VM. During a cold migration, the Virtual Machine IP address and MAC address remain preserved. Cold migrations must satisfy the same requirements as vMotion.

Validate the OpenCart web server is running.
Open a new tab in Chrome on Holo Console and enter http://10.2.1.2
You should see the following website

Open the management vCenter Server instance for Site-1 and power off HCX-OC-Apache-A

Right click on HCX-OC-Apache-A and click HCX Actions, Migrate to HCX Target Site
Set transfer and placement options as shown

Select Migrate
Notice it is a VLAN backed portgroup on VLAN 17

Because the VM is Powered off it will default to Cold Migration.
To migrate the VM, you will need to make the required selections for where you want to transfer the VM to (I.E. What Cluster or Host) and you will need to select what storage to migrate it to.
Select the mgmt-cluster and the vcf-vsan for storage.
Note; when you click on the Carrot to expand the details for the OC-Apache-A VM, the migration details are expanded out,
Validate that Networking is migrating using the Layer 2 Extension network (L2E-OC-Web-VLAN-17-xxxxxxx).

Click Go to start the cold migration.

Note: Because this is a nested lab with limited disk space, you may see the following warning for each migration in the lab. Simply click Go a second time to acknowledge the warning to proceed with the migration.

Return to the HCX Migration Dashboard by clicking on the vCenter Menu and selecting the HCX icon.

Select Migration on the left.

Expand the Migration for OC-Apache-A you can see many details of the migration. This migration has been completed successfully. You can now power on the Application VM.
Open a new browser Tab for vCenter Site 2 and login. https://vcenter-mgmt.vcf2.sddc.lab/ui/
From vCenter you can see OC-Apache-A has migrated
Power on HCX-OC-Apache-A VM
Notice that the VM is connected to the Layer 2 Extended Network.

Once the VM powers up, return to the browser tab for the Web application and refresh the page.

When the page refreshes, you can see that you are able to maintain networking connectivity to the VM without changing any of the network settings of the OC-Apache-A VM.
From a logical view, you can see below that the VM is communicating through the L2 network extension that HCX has extended to site 2.

Also, note that this 2-tier application also contains a MySQL Server that still lives in Site 1. So this Apache Web application communicates not only with Holo-Console, but also with the MySQL server in site 1 to load the website. This Web application is now spanned across two sites without changing IPs.

Perform HCX vMotion

Using HCX vMotion leverages the VMware vMotion protocol to move a live VM to the target site. During the migration, HCX copies the active state of the VM, including virtual disks, CPU cycles, RAM, IP address, and MAC address. Listed in the HCX documentation are several prerequisites for HCX vMotion. HCX vMotion allows you to live-migrate one VM at a time. You also have the option to select upgrading the VM tools or VM hardware during HCX vMotion. Note; selecting these options does not automatically update either of these components during the vMotion process. Instead, it creates a pending operation in the VM. These updates are then completed after the next reboot of the VM, as these changes require the VM to be powered off.

To begin testing HCX vMotion, from the Site 1 HCX Migration Dashboard,

Click on Migrate.

For this migration, you will migrate HCX-OC-Apache-B.

From the Migration wizard, Select the VM
Click Add

Select the Transfer and Placement Options
Select the mgmt-cluster-01 cluster
Select the vcf-vsan Storage
Select the vMotion Option for the Migration Method
Then click GO x 2

Because this is a live migration, you will be able to continue to connect to the OC-Apache-B VM the entire time.

Open another browser Tab and test the website. Http://10.2.1.3 During the migration feel free to refresh the page as often as you like.

You can also optionally monitor the ping connectivity of the VM from Holo-Console
Start a continuous ping to the server from Holo-Console.
Enter the ping command as shown in the CLI below.

During the vMotion, When the VM switches to site 2 you should see a difference in ping response time. You might even see it drop 1 ping.

With the vMotion Migration Complete, you can have now observed how easy and seamless vMotion migrations are with HCX.

Perform Bulk Migration

HCX Bulk Migration uses the host-based replication protocol to copy the disks of the VM to the target site. The VM can remain powered on during this disk replication period. Once the disk replication is complete, a delta sync occurs on the disk(s). After the delta sync is complete, HCX proceeds with the switchover process. During the switchover phase, the source VM is powered off, and the replica is powered on in the target site. The switchover process can run immediately or wait until a scheduled downtime window. The downtime period of a bulk migration is concise. The workflow for this process is; power-off source, then, power-on target. Bulk migration, as the name implies, can occur on multiple VMs at once. Bulk Migrations do not require Layer 2 extension but are recommended for a faster switchover. Personalization scripts can be run during the switchover phase, allow you to change the IP address or make other VM modifications. Additional HCX automated options include; updating the VM tools driver(s), and VM Hardware level. These settings are all selectable from the HCX UI. They are then executed immediately to the target side replica VM during the switchover process.

To begin with Bulk Migration, You start at the HCX Migration Dashboard in site 1.

Click the Migrate button.

At this point in the lab you have a choice, and it entirely depends on how your lab is licensed. If you are not licensed for HCX Enterprise, select all the remaining HCX- OC-Apache web servers for migration. If you are licensed for HCX Enterprise, save 1 or 2 VMs to test the next Optional Migration Method.

Select the VMs you want to Migrate and click ADD.

Select the Transfer and placement options
Select the mgmt-cluster-01 cluster
Select the vcf-vsan Storage
Select the Bulk Option for the Migration Method
Then click GO x 2

During the Bulk migration, you can monitor the progress from the HCX migration Dashboard, feel free to click through the various details of the migration process. Also note that Bulk is considered a “warm” migration and does incur a short downtime while the VM powers off in Site 1 and powers on in Site 2.

Bulk Migration begins with a base sync, this is doing the disk copy process described above.

Also feel free to start a continuous ping from the Holo-Console CLI to see how long the power off cycle is.
Once base sync is complete, it will begin the short powered off migration

You will see the following on completion.