When VMware fully realized the scale of the RAM shortage, VCF 9.1 was already largely finalized…
Thus speaks one of its employees, reacting to a topic that fuels the community: the rising hardware requirements for management services.
VCF 9.0 had hinted at a refocus of the experience on VCF Operations. With VCF 9.1, VMware stays the course, but evolves the back-end… whose footprint grows. For example with the introduction of a headless appliance serving as a licensing server.
This VM is added to every VCF Operations instance used to manage licenses. It is possible to deploy only one… or several, notably to ensure availability at sites with unreliable connectivity.
VCF management services, unified on a hungry runtime
Each of these servers requires 2 vCPU and 8 GB of RAM. But the real “big chunk” is called VCF Management Services. Under this umbrella, VMware unifies its management services around a runtime. The latter consumes at least 40 vCPU and 82 GB of RAM.
In production environments, at least the ones VMware targets, that constraint is looser. It is different in labs, at a moment when RAM prices keep climbing.
The runtime is installed in the first VCF instance, with fleet-level components (log management, policy engine…) and instance-level components (application of configurations, identity brokering…). It can optionally be deployed in an additional instance to run components at the instance level. The high-availability model uses 3 control nodes and a number of workers depending on the deployment size.
For further reading:
VMware excludes the EU from the forced move toward VCF
From VMware to Hyper-V: Microsoft extends another lifeline
AWS joins Azure and Google Cloud on nested virtualization
CNAM wins against VMware with a provisional injunction
