I will be giving a presentation on the migration of a vSAN cluster at this year’s VMware Explore in Barcelona. This is not just about the technical implementation, but rather about the decision-making process. If plan A doesn’t work, you should have a plan B ready. Or – as in my practical example – a plan C and ultimately a plan D.
The easy way is not always the best and even a less attractive alternative can ultimately lead to success.
CODE1405BCN
The presentation is listed in the VMware Explore Content Catalog under the number 1405 .
Monday, November 4 – 15:00 CET.
I am delighted.
vSAN Cluster Live-Migration to new vCenter instanceIf you can’t make it to Barcelona but are still interested in the topic (spoiler alert!), you can find the full story here on my blog.
With the release of vSphere 7.0 Update 1, vSphere Cluster Services VMs (vCLS) appeared in vSphere clusters for the first time. This made cluster functions such as Distributed Resource Scheduler (DRS) and others independent of the availability of the vCenter Server Appliance (VCSA) for the first time. The latter still represents a single point of failure in the cluster. By outsourcing the DRS function to the redundant vCLS machines, a higher degree of resilience has been achieved.
Retreat Mode
The vSphere administrator has little influence on the provisioning of these VMs. Occasionally, however, it is necessary to remove these VMs from a datastore if it is to be put into maintenance mode, for example. There is a procedure for setting the cluster to retreat mode. This involves setting temporary advanced settings that lead to the deletion of the vCLS VMs by the cluster.
According to the VMware procedure, the Domain ID must be determined to activate Retreat Mode. The domain ID is the numerical value between ‘domain-c’ and the following colon. In the example from my lab, it has the value 8, but the number can also have four digits or more.
The domain ID has to be transferred to the Advanced Settings of the vCenter.
config.vcls.clusters.domain-c8.enabled = false
Correct Retreat Mode settings.
Admin error occured during activation of retreat mode.
After activating retreat mode on a vSAN cluster, administrators had lost all privileges to all objects in the vSphere Client.
A review of the services showed that the vCenter Server Daemon (vpxd) was not running.
In the last few years we’ve seen a clear trend to adopt cloud strategies on customer side. Some already pusue a multi cloud strategy to get the most benefit from different offerings. But we may not forget, that infrastructure on-premises – the so called private cloud – is still the most common kind of virtual infrastructure. This is no surprise because on-premises infrastructure has without doubt some advantages. It’s not alone aspects of data privacy, data security and data sovereignty. There are also performance aspects such as low latency that keep customers from migration special workloads to the (public) cloud.
On the other hand there are some advantages of cloud offerings too. Such as flexible consumption, minimal maintenance, built in resilience, developer agility and the possibility to manage from anywhere.
To bridge the gap between on-premises needs and cloud based offerings, VMware has announced Project Arctic during VMworld 2021. Delivering benefits of the cloud to on-premises workloads.
Added Network Security Policy support for VMs deployed via VM operator service – Security Policies on NSX-T can be created via Security Groups based on Tags. It is now possible to create NSX-T based security policy and apply it to VMs deployed through VM operator based on NSX-T tags.
Supervisor Clusters Support Kubernetes 1.22 – This release adds the support of Kubernetes 1.22 and drops the support for Kubernetes 1.19. The supported versions of Kubernetes in this release are 1.22, 1.21, and 1.20. Supervisor Clusters running on Kubernetes version 1.19 will be auto-upgraded to version 1.20 to ensure that all your Supervisor Clusters are running on the supported versions of Kubernetes.
Check before update
If you upgraded vCenter Server from a version prior to 7.0 Update 3c and your Supervisor Cluster is on Kubernetes 1.9.x, the tkg-controller-manager pods go into a CrashLoopBackOff state, rendering the guest clusters unmanageable
The image above indicates we’re already on version 1.21, which is good for an update.
Update
Before updating your VCSA make sure you have a configuration backup! An optional VM snapshot is a good idea too. It might help to revert settings fast in case something goes wrong.
You can either apply the update from VAMI or from the shell. The image below shows an overview of the new packages with this update.
After the update is installed you will have an option to deploy a new Kubernetes version in your Supervisor Control Plane.
