VCF Management Services Models, Explained
When you deploy a new VCF instance, you pick a management services model. You actually answer two separate questions, and it helps to know that before you start, because they are easy to run together in your head.
The first is which components run in that instance. The second is how the cluster underneath is built.
Where this comes from
VCF 9.1 introduces VCF management services, a single architecture for the lifecycle and operational jobs that used to be scattered. The point is a unified place to manage things from, with simpler lifecycle management and one story for backup and recovery of everything it hosts.
The piece that does the hosting is called the VCF services runtime instance. Every VCF instance has one.
Which components run in an instance
Components come in two kinds: fleet level and instance level.
Fleet level components exist on only one VCF instance. They cannot be deployed on every VCF instance. They are hosted on the first VCF instance you deploy, which runs them alongside its own instance level components.
Every other instance you add runs the instance level components only.
Read it from the top and the two columns start the same. VCF services runtime, SDDC lifecycle, Telemetry and Salt master are on both sides. Then the first instance keeps going, picking up Fleet lifecycle and Salt RaaS, the two fleet level components.
That is the whole shape of it. One instance hosts the fleet level components. Every other instance carries only its own.
The dotted boxes
The dotted boxes are the part worth slowing down for.
A dotted box is a component you can have, but not one that arrives on day one. The documentation calls these day-N operations, and they come with a cost attached: adding them means adding worker nodes.
The lists differ by model.
| Model | Day-N components |
|---|---|
| First VCF Instance | Log management, Real-time metrics |
| Additional VCF Instance | Identity broker, Software depot, Real-time metrics |
So an additional instance starts leaner. It gets four components up front, and Identity broker, Software depot and Real-time metrics are ones you add when you want them.
This matters at sizing time more than at deployment time. If you know you will want Real-time metrics, the worker nodes to carry it are part of the plan rather than something you find later.
How the cluster underneath is built
The second question is about nodes, and the answer is one of two models.
Simple gives you a single control plane node and three worker nodes.
High Availability gives you three control plane nodes. The worker node specification and count follow the deployment size you choose.
Put the two side by side and most of the picture is identical. Same nesting, a VCF instance holding a vSphere cluster, holding VCF management services, sitting on ESX hosts. Same worker nodes carrying the same services, with Replica 1 on the first worker and Replica N spread across the additional ones.
The control plane row is the difference. One node on the left, three on the right.
What that difference buys you
The documentation is direct about both sides.
Simple is the smaller footprint, and it is described as being for testing and proof of concept deployments. Its implication is stated plainly: losing the single control plane node means redeploying the cluster and restoring from backup.
High Availability gives high availability for the control plane and the worker nodes. Its implication is equally plain: it requires additional resources.
That is the trade, and it is a familiar one. Three of something costs more than one of something, and survives losing one.
Putting the two together
The two questions are independent, which is the useful thing to hold on to.
A first instance can be Simple or High Availability. So can an additional instance. The component model tells you which components run in that instance. The deployment model tells you how many nodes carry them.
When you deploy a new VCF instance, you choose both, based on the profile and the needs of that particular instance. A production first instance and a lab instance somewhere else can quite reasonably land on different answers.
Sources
Never miss a post
New guides on VMware Cloud Foundation, Aria Suite, and infrastructure automation. Follow the blog in your feed reader and new posts show up as soon as they are published.
Using a different reader? Copy the feed URL and add it there.