Let’s talk about VCF Management Services

VMware Cloud Foundation 9.1 (and VMware vSphere Foundation for that matter) introduced the VCF Management Services which are sometimes called VMSP or VSP in the product.

In my experience, customers stumble over this new platform in the VCF installer when configuring the update or installation and being faced with questions about CIDR blocks and a chunk of system resources (CPU, memory).

What are the VCF Management Services?

We all know about the well known services like vCenter and Operations but to run a private cloud stack like VCF, a number of auxiliary services are required.

Essentially, the VCF Management Services are a VCF-managed set of virtual machines that form a Kubernetes cluster which hosts and exposes these services for consumption.
To put it simpler, instead of deploying a dozen individual virtual machines with independent lifecycle and availability requirements, we provide a centralized platform that cares for the basics and just runs containers on top of it.

Let’s look at the bare minimum set of services that is deployed in the first VCF Management Services instance (typical in your management domain):

• Fleet lifecycle
• Salt RaaS
• SDDC lifecycle
• Telemetry
• Salt master
• Identity broker
• Software depot

Optionally you can add (after deployment):

• Log management (better known as LogInsight)
• Real-time metrics

As you can see, the first deployment runs a mix of fleet and instance services.
The documentation provinces more details on the distribution of first and other instances.

What are the requirements for the VCF Management Services?

Essentially you need a bunch of compute resources as well as a large number of IP addresses that are needed for scale and lifecycle management.

VCF services runtime node IP addresses

The documentation talks about a minimum of 12 IP addresses and a maximum of 30 IP addresses and references a /28 and respective a /27 CIDR blocks.
Now, this throws a lot of people off as CIDR blocks are most commonly used in terms of defining a network.
What you are providing here, is a pool of usable IP addresses in your management network that can be used for the virtual machines (VCF services runtime nodes).
The range between 12 and 30 addresses is pretty big, so what is the correct choice here?
It depends … mainly on the size of your environment and the number of services (but, you can add an additional IP range/block after deployment).

At the beginning of the deployment process, in HA mode, at least three control plane nodes are created and n worker nodes.
As you add services and your compute requirements for these services increase, more worker nodes may be created, taking more IP addresses from the provided IP range.
Also, during lifecycle operations, new virtual machines will be created, the containers respawned on the new nodes and the old nodes will be decommissioned.
Since a pool of addresses has been provided, no user interaction is required for these tasks.

In version 9.1, the installer asks in a greenfield installation (that means you have nothing and start VCF from scratch) for an IP range.
In my example below, this would be 192.168.1.160-192.168.1.192 - exceeding the 30 IP addresses.
Unfortunately, the UI driven brownfield process in 9.1 asks for a CIDR block, making the experience not consistent with the greenfield installation. In my example, this would be 192.168.1.160./27.
In both cases, the same set of IP addresses are used.
For full freedom of choice, you can use the API to specify IP ranges, IP blocks (CIDR) or individual IP addresses.

By default, the IPs are assigned from your existing VM management network but you have the option to specify another network for the deployment of the VCF Management Services.

FQDN for components

Some services of the VCF Management Services are exposed to the management network. The documentation calls for a number of FQDNs that need to be assigned, including:

• Fleet components
• Instance components
• VCF services runtime
• …

These FQDN need to be mapped to IP addresses in the same network the VCF services runtime nodes are deployed, meaning that this is part of the network you took the IP range from.
But, these must be outside of the IP range specified for the VCF services runtime nodes

Confusing?
Let’s get back to the picture above:
I specified the range of 192.168.1.160-192.168.1.192 for the VCF services runtime nodes, so these are reserved.
Therefore I will map the FQDNs required to IPs outside that range, e.g.

• VCF services runtime FQDN maps to 192.168.1.200
• Fleet components FQDN maps to 192.168.1.201

Internal Kubernetes networks

As the VCF services runtime forms a Kubernetes cluster, an internal CIDR block is assigned for pods and services.
For those who are not familiar with Kubernetes, these IPs are just used inside the cluster but they may not overlap with networks in your enterprise or you’ll be troubleshooting forever…
By default the IP block 198.18.0.0/15 is used.
If that creates a conflict, you can use the API to adjust the internal CIDR block for VCF management services to 240.0.0.0/15 or 250.0.0.0/15

VCF services runtime node compute resource requirements

Since we are running quite a few services and we form a complete Kubernetes cluster, a couple of resources need to be assigned.
Use the VCF Deployment workbook to determine your exact requirements and don’t rely on reddit.
We differentiate in sizes between small without HA and medium/large deployments with high availability.

To provide a few examples of requirements:

For a small deployment without HA, you will need to calculate with the sum 40 vCPU and 82 GB RAM for all nodes in the initial deployment.

In a medium deployment, you will have:

• Three Control plane nodes, each with 4 vCPU and 10 GB RAM.
• The Worker nodes run each with 24 vCPU and 48 GB RAM.
• Each VM has a base disk of 100 GB, worker nodes have additional storage assigned.

VCF services runtime storage requirements

VCF will use your primary datastore to deploy the VCF services runtime nodes.
In addition to that, a set of first class disks (to quote the docs: “First Class Disk (FCD), also known as Improved Virtual Disk, provides storage lifecycle management on virtual disks, independent of virtual machines”) are created on the same datastore.
These FCD host the persistent data of the VCF Management Services and will be attached to the Kubernetes nodes as needed.
For a small deployment the storage requirements for VCF services runtime nodes and FCD is specified with three TB.