VMware Cloud Foundation Operations is the next generation of Aria Operations and tightly integrated with VMware VCF-based private cloud infrastructure. At its core, VCF Operations is an Ops Management tool, but with the next release of VMware Cloud Foundation, VCF Operations will be the focal point for managing and operating the VMware VCF environment. VCF Operations will integrate single sign-on, certificate, password, and lifecycle management(LCM) capabilities. Simply put, it will be the centralized point for configuring the VCF private cloud and will be mainly used, but not limited to, for VCF day-2 operations. In this blog post, we’ll go through the components and architecture of VCF Operations.

If you have experience working with Aria Operations or Aria Operations, then understanding the components and architecture of VCF Operations won’t be hard for you! But don’t worry if you don’t have experience with vROps or Aria Ops! Keep reading this blog post, and you’ll get a better idea.

Aria Operation was rebranded into VCF Operations in 2024; as explained, the idea behind that was to make this solution “The” Center of Operations for VCF. The vision for this operational change will become a reality in the next release of VMware Cloud Foundation.

Primary Node

The VCF Operations primary node acts as the cluster’s “brain” and coordinator and is formerly called the Master node. It handles configuration management, orchestrates cluster activities, and processes administrative tasks. When implementing VCF Operations, the Primary node is the first to be deployed. This node collects and processes incoming data, contains the central vPostgres database, and distributes tasks and data across the cluster using the Controller engine. The Primary node also acts as an NTP server for VCF Ops components.

Replica Node

The replica node serves as a high-availability copy of the Primary node and maintains up-to-date configuration and state data replicas. The standby node provides redundancy so that a replica can be promoted to primary if the primary node becomes unavailable. Replica nodes also share the load for read and query operations.

Data Node

Data nodes manage the operational data VCF Operations collects, processes, and stores. They provide the core database functionality of collecting and processing incoming data. The Data nodes are the additional nodes in VCF Operations that allow scaling out and monitoring larger environments.

Cloud Proxy (aka Remote Collector)

The cloud proxy is a gateway between Aria Operations and remote sites. Typically, you deploy one cloud proxy per physical data center, and Cloud Proxy creates a one-way communication between your remote environment and VCF Operations. The Cloud Proxies collect the data from local locations and push this data to the VCF Operations cluster.

Load Balancer

In the case of a Multinode cluster, we need a load balancer. A load balancer fronts the Aria Operations cluster, ensuring that incoming requests—whether from users accessing the UI or API calls—are evenly distributed. It distributes traffic across primary, replica, and data nodes to optimize performance and prevent any single node from becoming a bottleneck.

Now that we understand VCF Operation’s components, let’s examine how this architecture will be assembled.

This is, of course, a simplified view of the VCF Operations cluster. More than one Data Node could be in place, and we would have one cloud proxy for each remote location. Keep in mind that the VCF Operations cluster can have a maximum of sixteen (16) nodes. It’s important to note that Cloud Proxy instances are not included in this 16-node limit.

In the next post in this series, where I’ll dive deeper into VCF Operations Fleet Management. So if you are intrested to learn more keep-on reading!