VCF 9.1 Design Topology Field Guide Part 1: Foundational Topology Patterns
An architect’s read on the foundational design topology decisions in VCF 9.1
This is Part 14 of an architect’s read of VCF 9.1, and the first of four “Design Topology Field Guide” articles. Parts 1–13 covered platform architecture, customer migration, day-2 operations, and storage-vendor-specific migrations. This mini-series shifts the lens from “what VCF 9.1 IS” to “how do you actually DESIGN with it.”
Each article in this field guide focuses on the topology and conceptual design decisions architects make in real engagements. This first part covers the five foundational patterns: the architectural hierarchy that drives every downstream decision, the new Kubernetes-based Management Services Cluster, the Fleet Latency constraints that shape multi-region design, and the two major multi-site patterns multi-region multi-Instance and stretched-cluster within a metro region.
These five patterns are the entry points to a VCF 9.1 design. Get them right and the rest of the architecture follows. Get them wrong and the design pays for it for years.
Pattern 1: The Private Cloud / Fleet / Instance / Domain hierarchy
The foundational architectural model in VCF 9.1 is a five-layer hierarchy: Private Cloud > Fleet > Instance > Domain > Cluster > Host. These distinctions aren’t cosmetic each layer is a different scope of governance, lifecycle, and operations.
Private Cloud is the highest-level management and consumption boundary. A Private Cloud can contain one or more Fleets. Most enterprises operate one Private Cloud per organisation; multi-Private-Cloud structures exist for very large or federated organisations.
Fleet is the shared governance scope. One set of fleet-level management components VCF Operations, VCF Automation, fleet-wide lifecycle, federated identity manages the entire Fleet. A Fleet contains one or more Instances. Multi-region designs typically use one Fleet across all regions.
Instance is a discrete VCF deployment with its own SDDC Manager, management vCenter, management NSX, and optionally its own NSX Edge clusters. An Instance contains exactly one Management Domain and optionally one or more VI Workload Domains. Each region typically gets its own Instance.
Domain is a lifecycle and isolation boundary inside an Instance. The Management Domain hosts the management components; VI Workload Domains host business workloads. A Workload Domain has its own vCenter, can share or have dedicated NSX Managers, and has its own storage and networking constructs.
Cluster sits inside a Domain. Multiple clusters can exist in a single Domain, sharing the Domain’s vCenter.
Host sits inside a Cluster. Standard ESX semantics.
The HLD implication of this hierarchy is that change windows and operational responsibilities map to specific layers. Patching the management vCenter is an Instance-level event. Adding a new region is a Fleet-level event. Upgrading a tenant’s workload is a Workload Domain event. Talking about “upgrading vCenter” without specifying which layer is the most common cause of confusion in design reviews.
Common anti-patterns: treating Fleet and Instance as synonyms; planning change windows at “the vCenter level” rather than at Domain and Fleet Services levels; assuming a single Instance can span multiple regions through stretched clusters (it can’t multi-region needs multiple Instances).
Diagram to use: the three-layer hierarchy diagram showing Private Cloud > Fleet > Instance > Domain. Best source:
• Veeam Community How VCF 9.0 Architecture Works (includes the canonical diagram)
• vStellar VCF-9 Part 1 Introduction & Architecture (standard architecture diagram)
Pattern 2: VCF Management Services on a Kubernetes Runtime
The most underrated architectural shift in VCF 9.x is that management components are no longer separate appliances. They run as Kubernetes-based services on a dedicated runtime called the VCF Management Services Cluster.
The components running on the Management Services Cluster: lifecycle management, software depot, log management, real-time data services, identity services. Each VCF Instance includes its own Management Services Cluster.
Footprint requirements at deployment:
• 12 IP addresses (k8s control plane, worker nodes, service endpoints)
• 4 FQDNs (mandatory at deployment, DNS-registered)
• Initial sizing: 3 control plane + 5 worker nodes (typical)
• Auto-scaling: when you add a service component like Log Management, an extra worker node is automatically deployed (typical: 12 vCPU / 24 GB RAM per worker)
The architectural significance:
• Lifecycle is unified: patching the management plane happens through the K8s runtime, not through individual appliance upgrade workflows
• Resource sharing: services share underlying compute via K8s scheduling rather than being permanently over-provisioned as separate VMs
• Cloud-native operating model: the platform team operates VCF the same way they operate Kubernetes
• Day-2 hygiene: certificate management, secrets handling, and service discovery all use K8s primitives
HLD considerations:
• Size the Management Services Cluster for peak service load, not steady-state K8s scheduling can amplify resource consumption during patching or major operations
• Network design must accommodate the 12 IPs and 4 FQDNs from Day 0
• Protection: the Management Services Cluster is a first-class workload class requiring backup and DR consideration like the management vCenter
• Service component additions (Log Management, Identity Broker, Real-Time Metrics) consume additional capacity plan ahead
Anti-pattern: treating the Management Services Cluster like “more management VMs.” It’s architecturally different a Kubernetes control plane operating critical platform services. The operational model is K8s, not vSphere.
Diagram to use: the Management Services architecture diagram showing the K8s runtime hosting platform services. Source:
• Broadcom Scale, Simplify, and Secure VCF 9.1 (Management Services architecture)
• Broadcom TechDocs VCF Management Services Models
Pattern 3: The Fleet Latency Diagram the constraint that shapes everything
Multi-Instance VCF 9.1 designs live or die by the Fleet Latency Diagram. This is the constraint set published by Broadcom (and maintained by William Lam, Distinguished Platform Engineering Architect in the VCF Division) that defines what topologies are physically realisable.
The two thresholds that matter most:
• VCF Operations Collector → vCenter Server, NSX Manager, SDDC Manager: ≤ 50ms RTT
• VCF Operations Collector → VCF Operations: ≤ 300ms RTT
These define what “one Fleet” can span. With <=300ms collector-to-VCF-Operations, a single Fleet can span continents via the appropriate WAN Sydney to Singapore, US East to US West, US to EMEA. With <=50ms collector-to-managed-components, the collector must be local to its Workload Domain.
The architectural pattern that emerges:
• Primary VCF Operations: deployed in one Instance (typically the primary or largest)
• Distributed Collectors: one or more additional VCF Operations Collectors deployed local to remote Workload Domains where the round-trip from primary VCF Operations exceeds 50ms
• Collectors are managed centrally but execute locally best of both worlds
Why this matters for Brownfield Import scenarios: when you import a vSphere environment as a Workload Domain, that vCenter is often physically distant from the primary VCF Operations. Deploying a local VCF Operations Collector for that imported Workload Domain ensures the <=50ms requirement to the management components while staying within the <=300ms budget back to VCF Operations.
HLD considerations:
• Measure RTT before committing to a multi-Instance topology. Don’t assume; test
• Identify Workload Domains whose vCenter / NSX Manager / SDDC Manager will exceed 50ms from primary VCF Operations. Each one needs a local Collector
• Stretched cluster designs sit inside one Instance and don’t cross WAN the Fleet Latency Diagram applies between Instances, not within
• WAN reliability matters as much as latency fleet operations during link instability degrade gracefully but visibility is lost
Diagram to use: the VCF 9.1 Fleet Latency Diagram. Source:
• Broadcom Ports Portal Network Diagrams section (the canonical VCF 9.1 Fleet Latency Diagram)
• William Lam VCF 9.1 Updated Design Blueprints & Fleet Latency Diagrams
• William Lam Original VCF 9.0 Fleet Latency Diagram (background)
Pattern 4: Multi-Region Multi-Instance the right way to do multi-site
Multi-region VCF 9.1 designs are multi-Instance, not stretched. One Fleet, multiple Instances, one Instance per region. This is the canonical pattern when regions need autonomy, sovereignty, or isolation.
The architectural anatomy:
• One Fleet provides shared governance unified VCF Operations and VCF Automation across the regions, federated identity via Identity Broker, fleet-wide license management
• Each Instance owns its own management plane dedicated SDDC Manager, dedicated management vCenter, dedicated management NSX
• Each Instance has its own Management Services Cluster
• Each Instance can be lifecycle-managed independently patches happen at Instance scope, not Fleet scope
• Workload Domains belong to one Instance; cross-Instance workload patterns use replication tools (HCX, Live Site Recovery, array-native replication)
When to choose multi-Instance multi-region:
• Regions need autonomy a region can operate independently if the WAN breaks
• Regulatory or sovereignty constraints prevent shared management across borders
• Multiple sites with different operational teams need independent change control
• WAN latency between sites exceeds stretched-cluster thresholds
• Disaster recovery patterns need region-level isolation
Operating model implications:
• Platform team operates Fleet services centrally
• Regional VI admin teams own per-Instance SDDC lifecycle execution
• Application teams consume from any Instance via VCF Automation’s self-service catalog
• Identity flows through one set of fleet-level Identity Broker policies (or per-Instance brokers for hard SSO isolation)
Anti-patterns to avoid:
• Trying to make multi-region work with one Instance via stretched clusters stretched clusters are metro-scale, not continental
• Federating across multiple Fleets when a single Fleet would do multiple Fleets only when regulatory isolation requires it
• Putting all VCF Operations Collectors in the primary region distributed collectors are the architectural answer
Diagram to use: the multi-region topology diagram showing one Fleet spanning multiple regional Instances. Source:
• Digital Thought Disruption VCF 9.0 Mental Model Part 4: Fleet Topologies and SSO Boundaries
• William Lam VCF 9.1 Updated Design Blueprints
Pattern 5: Stretched Cluster single Instance across two metro sites
Stretched cluster is the metro-scale availability pattern. One Fleet, one Instance, two sites in the same metro region, with stretched constructs for site-level high availability. This is the right pattern when synchronous replication is possible and you need transparent failover.
Architectural anatomy:
• One VCF Instance single management plane, single SDDC Manager, single management vCenter
• Selected clusters stretched between sites typically the Management Domain plus performance-critical Workload Domains
• Storage stretched at the array layer vSAN ESA stretched cluster, or array-side stretched solutions (NetApp MetroCluster, Pure ActiveCluster, HPE Peer Persistence VMFS-FC, Dell SRDF/Metro)
• Witness host in a third location for split-brain prevention
• Network stretch L2 stretch (for vMotion and storage replication) and L3 routing (for north-south traffic with site failover)
• DRS site-affinity rules ensuring workloads run on their preferred site under normal operations
When to choose stretched cluster:
• Two data centres within the same metro region (synchronous replication latency budget achievable, typically <=5ms RTT)
• Site-level availability required transparent failover for a site failure
• Network stretch can be delivered (this is usually the gating constraint)
• Operations team prefers single management plane over multi-region complexity
• Storage vendor stretched cluster solution is in scope
HLD considerations:
• Decide which clusters to stretch not all of them. Management Domain typically yes; some Workload Domains yes, others no
• Confirm network stretch capability with the network team before committing
• Witness placement third location, network-isolated from both data sites
• Storage choice constrains stretched options. HPE Peer Persistence supports VMFS-FC only (not vVols) under VCF. NetApp MetroCluster requires NFS v3 for VCF. Pure ActiveCluster works with VMFS-FC and NVMe/FC
• Change windows are more sensitive to inter-site network events a metro WAN flap during patching has higher impact
Anti-patterns:
• Stretched cluster across regions with WAN latency. Stretched is metro, not continental
• Stretched cluster with non-stretched storage the storage layer must support active-active for the design to deliver
• Stretched cluster without a witness split-brain risk during inter-site network failures
• Stretching every cluster “because we can” stretched comes with Day-2 sensitivity. Choose stretched clusters deliberately
Diagram to use: the stretched cluster topology diagram showing two metro sites with single Instance, stretched Management Domain, witness host, and synchronous storage. Source:
• Digital Thought Disruption VCF 9.0 Mental Model Part 4: Fleet Topologies (stretched cluster section)
• William Lam VCF 9.1 Updated Design Blueprints (stretched cluster patterns)
• Broadcom KB Implementing vSphere Metro Storage Cluster (vMSC) with HPE Peer Persistence
Decision framework: choosing the right foundational topology
A simplified decision tree for the topology decisions in this article:
• Single site → One Fleet + One Instance + standard architecture (separate Management Domain + Workload Domains)
• Single site, small footprint → One Fleet + One Instance + consolidated architecture (Management + Workload collapsed)
• Two sites in one metro, synchronous replication possible → One Fleet + One Instance + stretched clusters
• Two sites separated by WAN, no synchronous replication → One Fleet + Two Instances + replication-based DR
• Multi-region with regional autonomy needs → One Fleet + multiple Instances + distributed VCF Operations Collectors
• Multi-region with hard regulatory isolation → Multiple Fleets + federated identity at the IDP layer
• Multi-region with one site requiring air-gap → Per-site Fleet with no cross-Fleet management
Closing
These five patterns are the foundation. Get the hierarchy terminology consistent in design reviews. Size the Management Services Cluster properly with the auto-scaling assumption baked in. Respect the Fleet Latency Diagram as the constraint that defines topology. Use multi-Instance for multi-region and stretched clusters for metro don’t try to make one solve the other’s problem. Choose stretched clusters deliberately because the Day-2 sensitivity is real.
In my design reviews, the questions I work through every time:
• How many sites? In how many regions? With what RTT between them?
• Where does VCF Operations live, and where do its Collectors live?
• How many Fleets does this customer actually need? Often the answer is one
• How many Instances per Fleet? One per region is the default
• Which clusters get stretched, and which don’t?
• What’s the storage vendor’s stretched cluster solution, and does it work under VCF?
• Where’s the witness, and how is it network-isolated?
• What’s the Management Services Cluster sizing for current and projected service load?
Get those answered and the foundational topology HLD is ready.
Part 15 of this Field Guide covers network topology patterns the VPC consumption model, Centralized vs Distributed Transit Gateway, multiple External Connections (new in 9.1), and VPC Connectivity Policies.
Sources
• Broadcom Planning a Successful VMware Cloud Foundation 9.0 Deployment
• Broadcom Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience
• Broadcom Scale, Simplify, and Secure VCF 9.1
• Broadcom TechDocs VCF Management Services Models
• William Lam VCF 9.1 Updated Design Blueprints
• William Lam VCF 9.0 Fleet Latency Diagram
• Digital Thought Disruption VCF 9.0 Mental Model Part 1 (Fleets, Instances, Domains)
• Digital Thought Disruption VCF 9.0 Mental Model Part 4 (Fleet Topologies and SSO)
• vStellar VCF-9 Part 1 Introduction & Architecture
