8 of 9 – Service Meshes

Service Meshes define a relationship between one or more source clusters and one or more target clusters.
Typically this would be a 1:1 relationship so you know ‘that’ service mesh will move a VM from cluster A to cluster B.
Each service mesh will deploy 1 or more components dependent on the services defined in the Compute Profile used.

A service mesh may be dedicated for a purpose i.e. Migrations only or Network Extensions only, a service mesh may also be an custom services or all in one mesh.
Note – Mixing network extensions and other migration services in the same mesh may add some challenges when trying to make changes or upgrades, consider maybe having migration meshes and NE meshes.

When planning your service meshes, please refer to the Config Max site for details https://configmax.esp.vmware.com/guest?vmwareproduct=VMware%20HCX&release=VMware%20HCX%204.9&categories=41-0,42-0,43-0,44-0,45-0

As of HCX version 4.9.x there is a maximum of 64 service meshes, 128 NE appliances or 192 total appliances (NE, IX, WAN OPT, SENTINAL) per HCX Manager.
This may seem a lot but if you are stretching say one network per NE appliances this could easily be reached.
Note – You ‘can’ stretch up to 8 networks per NE appliance, the question should be if you should. Be mindful that each appliance has its limitations for throughput, scale out rather than up.

The Service Mesh design will also be impacted by your deployment model, there are 2 x core types:

  • Dedicated Deployment Cluster – A separate vSphere cluster is deployed to only host the HCX components (NE, IX, WAN OPT, SENTINAL), this cluster would need to be part of the VDS it wishes to stretch networks for. A separate cluster means you can give the appliances full CPU and Memory reservations without impacting Production workloads plus there may be relaxed change management if it doesn’t host prod workloads.
  • Shared Deployment / Service Cluster – This option has the HCX appliances deployed into one of the ‘Service’ clusters it will be migrating VMs from. This model is easy to deploy but does run the risk of competing for resources with production workloads.

Pre-Requisites

  • Network Profiles created
  • Compute Profiles created
  • IP Pools PING tested to ensure no addresses are already in use.
  • The required Firewall rules are in place to allow communications between all the components (vCenter to to IX appliances is commonly forgotten), refer to the Ports and Protocols link for a list – https://ports.esp.vmware.com/home/VMware-HCX

Note – The network pools defined in the Network Profiles MUST be routable, if not, the service mesh deployments will not be 100% successful.

Scripting Service Meshes

For this Lab example, I am doing the simplest of service meshes deployments, I am not even taking in any addiitonal inputs from a CSV file.
In this example I am using the source and target Compute Profiles deployed to create a new Service Mesh.

In the script I have tagged a simple Create Service Mesh section, the profile and new mesh names could be read from a file or dynmically read from HCX or results from previous commands, in this instance I have hard coded them for simplicity:

The script calls the New-HCXServiceMesh cmdlets and passes in the variables.

New-HCXServiceMesh -SourceComputeProfile $myLocalComputeProfile -Destination $destination -DestinationComputeProfile $myRemoteComputeProfile -Service BulkMigration,Interconnect,Vmotion,RAV -Name $ServiceMeshName

Please refer to the official cmdlet reference guide for more detail – https://developer.broadcom.com/powercli/latest/vmware.vimautomation.hcx/commands/new-hcxservicemesh


The Script output the variables being used for the Service Mesh before running the New-HCXServiceMesh cmdlet.

During the deployment of the Service Mesh you can expand the Tasks option to see the active jobs, some of these can also be seen in vCenter:

Once all jobs are complete, the service mesh will have a successful status and all the service icons should have green dots.

If you click View Appliances, you can expand the source IX and view the site to site tunnel status, this should be green as shown:

You are now good to start basic migrations from the cluster defined in the service mesh.
I shall document some code to create basic migration batches from CSV input in another post.

Ready to move on? Click here for blog 9 of 9 – Automating HCX Migrations