7.1 VCF Operations Architecture, Cluster Nodes, & Deployment Options

7.1 VCF Operations Architecture, Cluster Nodes, & Deployment Options

Exam Focus: For the VMware Certified Professional - VMware Cloud Foundation Administrator (2V0-17.25) exam, candidates must master the unified VCF Operations platform architecture in VCF 9.0. You must understand the distinct operational roles of Primary, Primary Replica, Data, Cloud Proxy (formerly Remote Collector), and Witness nodes; the sizing profiles and scaling thresholds; the multi-tier storage architecture utilizing VMware Tanzu GemFire in-memory caching alongside Cassandra, the FileSystem Database (FSDB), and PostgreSQL; the critical operational differences between High Availability (HA) and Continuous Availability (CA) stretched clusters; and how adapter instances integrate vCenter, NSX, and vSAN into an enterprise telemetry fabric.

---

VCF Operations Platform Architecture in VCF 9.0

In modern software-defined private cloud infrastructures, operations management cannot function as a disconnected collection of point monitoring tools. In legacy architectures, administrators toggled between disparate consoles—vCenter performance charts for compute utilization, storage array consoles for IOPS and latency, NSX interfaces for network packet flows, and standalone log analyzers for event debugging. This fragmented operational model resulted in high Mean Time to Resolution (MTTR), uncoordinated capacity planning, and blind spots across virtualization boundaries.

VMware Cloud Foundation 9.0 elevates operations management into a core, native platform capability through VCF Operations (formerly branded as VMware Aria Operations and vRealize Operations). Deeply integrated into the Cloud Foundation software stack and orchestrated via SDDC Manager, VCF Operations delivers an AI-powered, unified observability, performance optimization, capacity forecasting, and compliance engine. It continuously ingests millions of telemetry data points across the physical, virtual, and software-defined networking layers of the private cloud, establishing a holistic operational fabric.

Deployed natively into the Management Domain or a dedicated shared-services infrastructure cluster, VCF Operations interacts directly with SDDC Manager, the Management vCenter Server, Workload vCenter instances, NSX Manager clusters, and vSAN storage fabrics. By establishing full-stack topological visibility, the platform enables IT organizations to shift from reactive fire-fighting to proactive, predictive self-healing infrastructure operations.

---

Multi-Node Analytics Cluster Architecture & Node Roles

The foundation of VCF Operations is its distributed, scale-out Analytics Cluster. The analytics cluster ingests raw metrics, properties, and events, processes them through dynamic machine learning baselines, evaluates symptom and alert definitions, and persists time-series data across high-performance storage repositories. To provide both horizontal scalability and high availability, the platform divides operational responsibilities among distinct, specialized node roles.

VCF Operations Cluster Node Hierarchy & Topology:

   ┌──────────────────────────────────────────────────────────────────────────┐
   │                       VCF Operations Analytics Cluster                   │
   │                                                                          │
   │   ┌───────────────────────────┐         ┌────────────────────────────┐   │
   │   │       Primary Node        │ <=====> │    Primary Replica Node    │   │
   │   │ - Cluster Admin UI (443)  │  GemFire│ - Active-Standby Admin UI  │   │
   │   │ - Master GemFire Locator  │   Sync  │ - Hot Replica PostgreSQL   │   │
   │   │ - Central PostgreSQL DB   │   & DB  │ - Active Data Node (FSDB)  │   │
   │   │ - Active Data Node (FSDB) │  Repl.  │ - Analytics & Collection   │   │
   │   └─────────────┬─────────────┘         └─────────────┬──────────────┘   │
   │                 │                                     │                  │
   │                 │       Internal Cluster Fabric       │                  │
   │                 ▼                                     ▼                  │
   │   ┌───────────────────────────┐         ┌────────────────────────────┐   │
   │   │        Data Node 01       │         │        Data Node 02        │   │
   │   │ - Sharded FSDB Metrics    │ <=====> │ - Sharded FSDB Metrics     │   │
   │   │ - Dynamic Thresholds (DT) │ Data Rep│ - Dynamic Thresholds (DT)  │   │
   │   │ - Capacity Calculations   │         │ - Capacity Calculations    │   │
   │   └───────────────────────────┘         └────────────────────────────┘   │
   └───────────────────────────────────────▲──────────────────────────────────┘
                                           │
                                HTTPS (TCP 443)
                                           │
         ┌─────────────────────────────────┴─────────────────────────────────┐
         │                                                                   │
 ┌───────▼────────────────────────┐                 ┌────────────────────────▼───────┐
 │        Cloud Proxy 01          │                 │        Cloud Proxy 02          │
 │   (Isolated Workload WLD)      │                 │   (Remote Edge / Datacenter)   │
 │ - Stateless Metric Ingestion   │                 │ - Stateless Metric Ingestion   │
 │ - Encrypted Outbound Push      │                 │ - Encrypted Outbound Push      │
 └───────────────▲────────────────┘                 └────────────────▲───────────────┘
                 │                                                   │
     vCenter / NSX / vSAN APIs                           vCenter / ESXi / Edge APIs

1. Primary Node

The Primary Node is the initial appliance deployed during cluster bring-up. It provides the central administrative coordination plane for the entire analytics cluster. Key responsibilities include:

• Cluster Administration Interface (Admin UI): Hosts the administrative console (accessed via https://<fqdn>/admin on TCP port 443) used to manage cluster lifecycle, node provisioning, certificate installation, cluster online/offline state changes, and software upgrades.
• Master GemFire Locator: Coordinates the distributed in-memory caching grid, tracking member node health and routing query traffic across cluster partitions.
• Central Relational Store: Hosts the primary instance of the internal PostgreSQL database, storing cluster topology, configuration settings, user accounts, role definitions, and dashboard metadata.
• Analytics Processing: In addition to management duties, the Primary Node actively runs analytics workloads, collects metrics from assigned adapters, and stores a slice of the time-series database.

2. Primary Replica Node (High Availability)

When High Availability (HA) is enabled on the analytics cluster, a Primary Replica Node is deployed. The Primary Replica functions as a direct mirror of the Primary Node:

• Operates in an active-standby configuration for management services. It continuously synchronizes PostgreSQL relational data, administrative configurations, and GemFire locator state from the Primary Node.
• Simultaneously operates as an active data node, participating fully in metric collection, dynamic threshold computation, and time-series data storage.
• In the event of a catastrophic failure of the Primary Node, an administrator can promote the Primary Replica to become the active Primary Node via the Admin UI (or automatically under supported conditions), restoring administrative management without data loss.

3. Data Nodes

Data Nodes provide horizontal, linear scale-out capacity for the analytics cluster. As the number of monitored workloads, ESXi hosts, and network interfaces expands:

• Data Nodes ingest metrics directly from assigned adapters or Cloud Proxies.
• They execute localized Dynamic Threshold (DT) algorithms and capacity projection models.
• They host shards of the distributed time-series database (FileSystem Database / FSDB).
• Data Nodes do not host the Admin UI management master services, allowing their compute and memory resources to be dedicated entirely to data collection, analytics computation, and query serving.

4. Cloud Proxy Nodes (formerly Remote Collectors)

In enterprise Cloud Foundation environments spanning multiple network security zones, remote datacenters, or isolated VI Workload Domains, direct communication between the analytics cluster and target endpoints is often blocked by firewalls. Cloud Proxy Nodes (which supersede legacy Remote Collectors) solve this architectural challenge:

• Stateless Ingestion Appliances: Cloud Proxies are lightweight virtual appliances that do not persist metrics locally, do not run analytics, and do not host database components.
• Network Boundary Traversal: Deployed locally within remote networks or DMZs, Cloud Proxies poll local vCenter Servers, ESXi hypervisors, and NSX Managers using local API protocols, buffer telemetry in RAM, and stream compressed, encrypted data outbound to the analytics cluster over HTTPS (TCP port 443).
• One-Way Outbound Communication: Because communication is outbound from the Cloud Proxy to the analytics cluster, network security teams only need to permit a single outbound port through internal firewalls, eliminating the requirement to expose the core analytics cluster to untrusted network segments.
• High Availability & Load Balancing: Cloud Proxies can be grouped into Collector Groups, enabling automatic failover and load balancing if a single proxy appliance encounters an outage.

5. Witness Node (Continuous Availability)

The Witness Node is an appliance deployed exclusively in Continuous Availability (CA) stretched cluster topologies. Its operational characteristics are strictly bounded:

• Deployed in an independent third failure domain (Fault Domain 3 / Site 3).
• Does not collect metrics, does not store time-series data, does not host adapter instances, and does not run analytics algorithms.
• Serves strictly as a quorum arbiter and tie-breaker. If a network partition severs communication between the two primary fault domains, the Witness Node votes with the surviving site to maintain majority quorum (preventing destructive split-brain conditions).

---

Cluster Sizing Profiles & Scaling Thresholds

Proper sizing of the VCF Operations analytics cluster is essential to maintain acceptable UI query responsiveness, avoid metric collection drops, and ensure sufficient headroom for dynamic threshold recalculations. VMware Cloud Foundation defines standardized sizing profiles based on total monitored object count and metric ingestion volume.

Scaling Rules & Operational Constraints

[!IMPORTANT] The Node Symmetry Rule: In any VCF Operations analytics cluster, all analytics nodes (Primary, Primary Replica, and Data Nodes) must be sized identically. Mixing different node sizes (e.g., pairing a Medium Primary Node with Large Data Nodes) is unsupported and causes severe memory imbalance, uneven data sharding, and cluster destabilization. Cloud Proxies and Witness Nodes do not store analytics shards and are exempt from this node symmetry rule.

• Maximum Cluster Scale: An analytics cluster can scale horizontally up to 16 analytics nodes (or up to 16 analytics nodes plus 1 Witness in CA mode), supporting hundreds of thousands of concurrent objects and tens of millions of metrics collected every 5 minutes.
• Storage Performance Requirements: The underlying storage tier supporting analytics nodes must deliver high sustained write throughput and low latency. VMware strongly recommends backing analytics nodes with vSAN Express Storage Architecture (ESA) or low-latency all-flash VMFS datastores. Storage write latency exceeding 15–20 ms will cause the internal FileSystem Database (FSDB) to stall, triggering collection delays and node unresponsiveness.

---

Internal Storage Architecture: GemFire, FSDB, & PostgreSQL

VCF Operations incorporates a multi-tiered internal data storage architecture designed specifically to balance sub-second query responsiveness with massive historical time-series throughput:

Internal Tiered Data Architecture:

   ┌──────────────────────────────────────────────────────────────┐
   │                   Incoming Telemetry Stream                  │
   └──────────────────────────────┬───────────────────────────────┘
                                  │
                                  ▼
   ┌──────────────────────────────────────────────────────────────┐
   │              VMware Tanzu GemFire (In-Memory Grid)           │
   │ - Sub-second metric lookup      - Real-time DT evaluation    │
   │ - Active symptom state cache    - Cluster-wide shared state  │
   └───────────────┬──────────────────────────────┬───────────────┘
                   │                              │
       Time-Series Stream                 Relational / Metadata
                   │                              │
                   ▼                              ▼
   ┌──────────────────────────────┐ ┌─────────────────────────────┐
   │ FileSystem Database (FSDB)   │ │    PostgreSQL Database      │
   │ - Proprietary time-series DB │ │ - Relational configuration  │
   │ - Horizontally sharded       │ │ - Object relationship graph │
   │ - Historical rollups         │ │ - RBAC, policies, dashboards│
   │ - Raw metric persistence     │ │ - Primary/Replica mirrored  │
   └──────────────────────────────┘ └─────────────────────────────┘

1. VMware Tanzu GemFire (In-Memory Distributed Cache):
   • Tanzu GemFire operates as a distributed, in-memory data grid distributed across the RAM of all cluster nodes.
   • Holds the most recent metric values, active symptom states, and dynamic threshold models in memory.
   • Enables instantaneous anomaly evaluation and sub-second dashboard rendering without waiting for disk read/write cycles.
2. FileSystem Database (FSDB):
   • A purpose-built, proprietary time-series database optimized for high-ingestion chronological telemetry.
   • Stores raw metric data points and pre-computed statistical rollups (hourly averages, daily averages, standard deviations, minimums, maximums).
   • Horizontally partitioned and sharded across all Data Nodes. When High Availability or Continuous Availability is enabled, FSDB data shards are duplicated across nodes to ensure zero data loss.
3. PostgreSQL Relational Database:
   • An enterprise relational engine residing on the Primary Node and replicated synchronously to the Primary Replica.
   • Stores static configuration properties, inventory object hierarchies, parent-child topological relationship graphs, alert definitions, user credentials, RBAC permissions, custom dashboards, and report templates.
4. Cassandra Datastore:
   • Serves as a distributed key-value storage layer supporting component health coordination, historical collection state, and cross-node tracking.

---

High Availability (HA) vs. Continuous Availability (CA)

To safeguard the operations management platform against infrastructure failures, VCF Operations provides two distinct clustering resilience models:

High Availability (HA) Mechanics

In an HA deployment, the cluster introduces a Primary Replica node and activates 1:1 data replication for all FSDB metric shards. Each data shard exists on its primary hosting node and a designated partner node. If any single data node crashes, the cluster continues operating seamlessly using the surviving replica shard. If the Primary Node experiences a physical server failure, the administrator accesses the Admin UI on the Primary Replica and triggers promotion, elevating the replica to the active Primary role.

Continuous Availability (CA) Mechanics

Continuous Availability stretches the analytics cluster across two geographically separated datacenters or campus availability zones. The nodes are divided into two equal Fault Domains (FD1 and FD2):

• Nodes in FD1 and FD2 are deployed symmetrically (e.g., Primary Node and 2 Data Nodes in FD1; Primary Replica and 2 Data Nodes in FD2).
• Every data shard written in FD1 is synchronously mirrored across the inter-site link to a corresponding node in FD2.
• A Witness Node is placed at a third site (or sovereign cloud endpoint) with network connectivity to both fault domains.
• If Datacenter A experiences a complete power failure or catastrophic flood, FD2 pairs with the Witness Node to form a majority quorum (2 out of 3 votes), automatically promoting FD2 nodes to maintain uninterrupted private cloud monitoring, alerting, and capacity analysis.

---

Management Pack & Adapter Framework

VCF Operations uses a modular, extensible architecture driven by Management Packs and Adapter Instances to connect to diverse infrastructure systems:

• Adapter Instances: Software connectors configured with target endpoints (FQDNs/IPs) and secure credentials. The adapter polls target APIs, transforms external telemetry into VCF Operations data models, and feeds the ingestion pipeline.
• Core Cloud Foundation Adapters:
  • vCenter Server Adapter: Connects to vCenter via vSphere APIs. Collects compute, memory, cluster, datastore, virtual machine, and host metrics.
  • NSX Adapter: Communicates with the NSX Manager cluster to discover virtual switches, Tier-0/Tier-1 gateways, Edge nodes, distributed firewall rules, and Geneve overlay tunnel health.
  • vSAN Adapter: Integrates directly with the vSAN Performance and Health Services, ingesting disk group latency, cache hit ratios, NVMe ESA wear endurance, and component resynchronization metrics.
  • SDDC Manager Adapter / VCF Management Pack: Discovers workload domains, commissioning events, host inventory lifecycle status, and certificate expirations across the private cloud.
• Credential Management & Collector Groups: Adapter instances use encrypted Credential objects stored in the PostgreSQL database. Adapters can be pinned to specific Collector Groups (associating the adapter with a specific Cloud Proxy or set of analytics nodes), ensuring network traffic remains isolated within designated management VLANs.
• Collection Intervals: The standard default polling cycle is 5 minutes. For latency-sensitive workloads or high-frequency telemetry endpoints, VCF Operations supports near-real-time 1-minute collection intervals on supported adapters.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] Node Sizing Homogeneity Trap: Questions testing cluster scale-out scenarios often suggest adding a "Large" data node to an existing cluster composed of "Medium" nodes to accommodate sudden workload growth. Remember: all analytics nodes (Primary, Primary Replica, Data) must maintain identical sizing profiles. Heterogeneous node sizing is completely unsupported.

[!WARNING] Cloud Proxy vs. Data Node Architecture: Do not confuse Cloud Proxies with Data Nodes! Cloud Proxies are strictly stateless forwarders designed to traverse firewalls; they do not store metrics, do not run analytics, and do not execute dynamic threshold calculations.

[!TIP] Continuous Availability Quorum Requirements: Continuous Availability mandates a Witness Node placed in a third independent site outside Fault Domains 1 and 2. The Witness Node requires only minimal network bandwidth and acts strictly as a tie-breaker; it stores zero operational telemetry.