VCF Operations sizing and scaling (9.1)

How big each VCF Operations node size is on 9.1, how to tell whether the current size still fits, and how to scale up (bigger nodes) or scale out (more nodes) afterwards. Applies to VCF and VVF. It complements Aria Operations → VCF Operations, which covers getting to 9.1 in the first place.

Typical moments to come here:

• before an Aria Operations 8.18 → VCF Operations 9.1 upgrade, to check the existing cluster still fits its size;
• after an upgrade or import that added vCenters, hosts or VMs;
• when VCF Operations is slow, or objects or metrics are near the limits below.

Where 9.1 sizing lives

For 9.1.x, Broadcom no longer publishes a separate sizing KB. Its sizing index (KB 324340) points 9.1.x to VMware Configuration Maximums (configmax.broadcom.com, product VCF Operations). The 9.0 equivalent was KB 397782. For a sizing based on your own object and metric counts, use the VCF Operations Sizing Estimator.

Node sizes (Configuration Maximums, VCF Operations 9.1)

Captured from Configuration Maximums, VCF Operations 9.1.0. There is no separate 9.1.1 release of these values.

• Per-node limits drop once you add nodes. A single Medium node takes 30,000 objects, but in a cluster each Medium node takes 17,000. Size a cluster on the per node in a cluster columns.
• Memory can be raised to a maximum per size (Extra Small 16 GB, Small 32, Medium 64, Large 96, Extra Large 256 GB).
• vCPU: “1 vCPU to 1 physical core at scale maximums” – don’t overcommit CPU on hosts running nodes near their limits.
• Latency: at most 5 ms between data nodes, and datastore latency at most 10 ms.
• Extended cluster maximums (Continuous Availability) are about 10% higher than the plain cluster figures, e.g. Medium 149,600 objects.

Cloud proxies (collectors) have their own sizes:

The 9.1 Add a Cloud Proxy page sizes the unified proxies by VM count: Small “Up to 16,000 VMs”, Standard “Between 16,000 to 80,000 VMs”.

The disk size per node is not in Configuration Maximums. For whole management-domain sizing (VCF Operations together with vCenter, NSX, VCF Automation and the rest), see the companion repo’s Management Domain Sizing & Fit Check. Its VCF Operations vCPU and RAM figures match the table above.

Does the current size still fit?

Compare the real object and metric counts with the table above. Configuration Maximums says where to find the metric figure: “go to the Cluster Management page in VCF Operations and view the adapter instances of each node at the bottom of the page … The sum of these metrics is what is estimated.” (The overall metric count on that page also includes metrics VCF Operations creates itself, so it reads higher.)

• Near the per-node limits: scale up (bigger node) or scale out (more data nodes), below.
• Planning an upgrade: check this before the Phase 1 window, so the upgrade doesn’t land on an already overloaded cluster, and run the Sizing Estimator with the counts for the target version.
• Many vCenters or remote sites: look at the collectors as well. Each size supports a maximum number of vCenter adapters per collector, so more cloud proxies may fit better than bigger analytics nodes.

Which scaling option each model supports

From Broadcom’s VCF Operations Models:

Scale up: bigger nodes

From Scaling VCF Management Components:

1. Log in to VCF Operations as a user with the Administrator role.
2. Build → Lifecycle → VCF Management, select VCF Operations.
3. Actions → Scale.
4. Select the node size: XS, Small, Medium, Large, XL.
5. Optionally, add disk space (GB) to every node in the cluster. Use Advanced Datastore Configuration to choose where the extra disk is placed on each node.
6. Review the summary and click Scale. Follow it on the Tasks tab.

For a Continuous Availability cluster, start the scale-up from the VCF Operations administrator interface in the primary fault domain.

Downtime: “During the process, the nodes are restarted and services are not available during the downtime.” Plan a window.

Take a new backup afterwards. “Rolling back to a backup created before scale up will revert the cluster to its earlier size and permanently delete data from the node added during scale up.”

The same Build → Lifecycle → VCF Management → Actions → Scale flow also scales VCF Operations for Networks (platform or collector nodes), Log Management (size and number of replicas), the VCF services runtime (size, plus extra IPs for the node pool), VCF Automation, Identity Broker and Real-time Metrics.

Scale out: more nodes

From Add Nodes in VCF Operations and VCF Operations for networks. For VCF Operations you add replica or data nodes.

Update the certificate first. The VCF Operations certificate must include the FQDN (and IP) of every node you are about to add. “If you do not update the certificate prior to performing the scale-out operation, the lifecycle management process will fail.” Regenerate it under Manage → Fleet Management → Certificates → VCF Management (VCF Operations, TLS Certificate): Generate CSRs with the new FQDNs and IPs in the SAN, have it signed, then Import Certificates. If nodes were already added without this, follow KB 430384.

1. Create DNS records (forward and reverse, lowercase) for the new node.
2. Log in to VCF Operations as an Administrator, Build → Lifecycle → VCF Management, select VCF Operations.
3. Actions → the Node Management action.
4. Select the node type (replica or data), enter the new node’s FQDN, the VCF Operations admin password and a password for the new node.
5. Confirm the certificate already covers the new FQDN, then click ADD.

Without fleet lifecycle (standalone VVF), use the Admin UI. KB 430384 states that adding nodes through Build → Lifecycle → VCF Management → Components and through the VCF Operations Admin UI are “equally valid”. The Admin UI steps, including turning a Data node into the Replica for HA, are in Walkthrough B, steps 2–3. The certificate rule applies to both methods.

Collectors scale out too. Add a cloud proxy under Build → Lifecycle → VCF Management → VCF Operations → Actions → Add cloud proxy (FQDN, size, admin password, a password for the proxy, VCF instance). Then point the integration at it: Operate → Administration → Integrations → Accounts → VMware Cloud Foundation → the VCF instance → Edit → Cloud Proxy / Group → Validate Connection → Save (Add a Cloud Proxy). In the HA model, Broadcom notes cloud proxies are “expanded to a collector group manually”.

Scaling back

There is no scale-down action. Removing a node is a separate procedure with a data-loss risk outside HA: see Removing a node – data loss. Don’t confuse HA with Continuous Availability when planning node counts: see Continuous Availability vs. plain HA.

Sources

• VMware Cloud Foundation (VCF) Operations Sizing Guidelines (KB 324340) – 9.1.x sizing lives in Configuration Maximums.
• VMware Configuration Maximums, VCF Operations 9.1.0 (configmax.broadcom.com) – node sizes, object and metric limits, latency, cloud proxy sizes.
• VCF Operations Sizing Estimator – sizing from your own counts.
• VCF Operations Models (9.1) – which model supports which scaling.
• Scaling VCF Management Components (9.1) – scale-up procedure, downtime, backup warning.
• Add Nodes in VCF Operations and VCF Operations for networks (9.1) – scale-out procedure, certificate prerequisite.
• Add a Cloud Proxy (9.1) – collector scale-out.
• KB 430384 – certificate remediation after adding nodes; Admin UI is an equally valid method.