So let us have a quick overview of HCX Service Meshes before we continue:
Service Meshes can contain all 3 appliances or just an Interconnect appliance or just a Layer 2 Ext appliance, depending on your needs. The WAN Optimiser is optional. Features are always being added to HCX, but these are the key services/appliances. The Interconnect (IX) appliance holds most of the services, I tell people to think of it as a vSphere Replication Manager, as that is one of the main services it holds. HCX uses vSphere Replication for all its replication bits, so the same pros and cons that apply to vSphere Replication apply here as well!
How the Mesh is configured and deployed is dependant on your Compute Profile and Network Profile at each site:
The key things I have found with HCX are the configuration of the Service Clusters and Deployment Clusters, they can impact how you scale things.
Service Clusters = The clusters where the VMs reside that you want to migrate. So it’s the clusters HCX can migrate VMs from/to using the Service Mesh.
Deployment Cluster = Where the HCX appliances are deployed
Now when just using Bulk Migration these can be one and the same thing and life is good. It is a simple deployment that covers you to migrate what you need
The main constraint is the Layer 2 Ext Appliance, as this has a 1-2-1 mapping with the VDS at both sites. As it needs access to the cluster/host where the VDS is so that it can extend the Distributed Port Group across to the destination. If you have a vCenter with lots of clusters with lots of VDS switches, this can become a problem, and needs to be managed correctly.
The 1-2-1 mapping requirement is something that can be easily overlooked!
Now as you see in the above diagram, the Service Clusters are set for the whole vCenter at each site. Which when you are doing bulk migrations is fine, it gives you the flexibility you need to allow HCX to put the VMs wherever they need to be.
The issue above is that since the Service Mesh is deployed into the “Source Linux Cluster” (Source) and “Dev Linux Cluster” (Destination), it can only extend the Layer 2 into the Dev Linux VDS as that is all that cluster has access to from the VDS standpoint, as that is where the Service Mesh is deployed into. Now the “Virtual Machine” VDS at the source is used in every cluster, so where the Layer 2 appliance is deployed doesn’t really make any difference, as the VDS is available, so the limitation is much more apparent at the destination side.
If I try to deploy another Service Mesh I get an error similar to this:
Invalid service cluster pairs found in request. ServiceMesh ServiceMesh1 already serves the following clusters. Local clusters: Source Linux Cluster (id domain-c148). Remote clusters: Dev Linux Cluster (id domain-c7)
So how do we work around this you ask? Well, I am glad you asked!
Let us compare the original diagram to an amended diagram showing the changes that need to be made:
NB: When creating multiple service meshes, multiple IX and L2 appliances are needed at both sides
So in the above diagram, I am now extending into the “Dev Windows Cluster” as well.
The original Compute Profile I used to service every cluster at the destination, has needed to be adjusted to exclude the “Dev Windows Cluster”. Once this adjustment has been made, you have to resync the original service mesh, so the current appliances know not to service it anymore.
I know that can seem a bit odd…..I mean I want to put VMs and extend into it….but bear with me!
Now what you do, is you create a new Compute Profile at the destination and you set the Service Cluster to the “Dev Windows Cluster” and you set the Deployment Cluster to the “Dev Windows Cluster”.
This allows you to deploy an Interconnect and Layer 2 Ext appliance into that cluster and allows you then to migrate VMs to it and extend a source Port Group/VLAN into it as well
Now if you created a new compute profile and didn’t deploy an IX appliance and just deployed a Layer 2 Ext appliance, it would deploy fine. But when you tried to migrate VMs you would get an error telling you there was no Service Mesh configured to service this cluster. This is because you have to change the service cluster in the original compute profile to exclude this cluster (otherwise you cant deploy any additional service meshes at all).
There are cases where people just want to use HCX for the Layer 2 Extension piece and then migrate VMs themselves some other way, which is perfectly acceptable
If you do not edit the original compute profile and resync the original Service Mesh, your deployment of the second service mesh will fail, because as far as HCX is concerned it already has a Service Mesh ….that is servicing that cluster….so why do you need another service mesh?
As you can see the Layer 2 Extension appliance is constrained to the cluster/hosts that have access to the VDS you want to extend from/to. I mean it makes sense it needs access to the hosts that the VDS is part of, so it can access it and work its magic.
So this can impact how you design your service meshes and it could easily catch you out if you are not paying attention!
Leave a Reply