5.1 VCF Deployment Models: Standard vs. Consolidated & Prerequisites

5.1 VCF Deployment Models: Standard vs. Consolidated & Prerequisites

Executive Overview: The deployment of VMware Cloud Foundation (VCF) represents the foundational transition from disparate virtualization silos to a fully standardized, software-defined private cloud. Choosing between the enterprise Standard Architecture and the resource-optimized Consolidated Architecture defines the long-term scalability, operational blast radius, and lifecycle maintenance model of the entire datacenter. Before any automation engine executes, administrators must establish uncompromising environmental prerequisites—spanning sub-minute NTP synchronization, deterministic DNS forward and reverse lookups, multi-VLAN segmentation, end-to-end Jumbo Frame MTU sizing, and BGP routing topologies.

---

VCF Architectural Deployment Models

VMware Cloud Foundation supports two primary architectural deployment models: Standard Architecture and Consolidated Architecture. Both architectures deploy the full VMware software-defined stack—vSphere compute virtualization, vSAN software-defined storage, and NSX software-defined networking—managed uniformly through SDDC Manager. However, they differ fundamentally in their hardware footprint, operational boundary isolation, and lifecycle independence.

┌─────────────────────────────────────────────────────────────────────────────────┐
│                     STANDARD VS. CONSOLIDATED TOPOLOGY                          │
├──────────────────────────────────────┬──────────────────────────────────────────┤
│         STANDARD ARCHITECTURE        │        CONSOLIDATED ARCHITECTURE         │
├──────────────────────────────────────┼──────────────────────────────────────────┤
│  Management Domain (Min 4 Hosts)     │  Consolidated Cluster (Min 4 Hosts)      │
│  - SDDC Manager, vCenter, NSX Mgr    │  - Resource Pool 1: Mgmt Components      │
│  - Dedicated vSAN Datastore          │  - Resource Pool 2: User Workloads       │
│  - STRICT ADMINISTRATIVE ISOLATION   │  - Single Shared vCenter & NSX Fabric    │
│                                      │                                          │
│  VI Workload Domain 1 (Min 3 Hosts)  │  Shared Storage & Network Fabric         │
│  - Dedicated vCenter, User VMs       │  - Shared vSAN Datastore                 │
│  - Scales up to 25 VI Domains        │  - Shared Compute & Maintenance Cycles   │
└──────────────────────────────────────┴──────────────────────────────────────────┘

1. Standard Architecture (Recommended Enterprise Model)

The Standard Architecture is the definitive, production-grade deployment model for enterprise private clouds. It enforces a strict physical and logical separation between infrastructure management services and tenant business applications.

• Dedicated Management Domain: Requires a dedicated cluster of at least four (4) ESXi hosts. This cluster exclusively hosts the software-defined infrastructure management plane:
  • SDDC Manager appliance
  • vCenter Server Appliance (VCSA) for the Management Domain
  • NSX Manager cluster (a 3-node high-availability management plane with a Virtual IP)
  • Optional shared services such as VCF Operations (formerly vRealize Operations), VCF Operations for Logs (vRealize Log Insight), and VCF Automation (vRealize Automation)
  • Dedicated vSAN datastore (OSA or ESA) backing management workloads
• Independent Virtual Infrastructure (VI) Workload Domains: Tenant applications never run within the Management Domain. Instead, administrators provision one or more VI Workload Domains. Each workload domain consists of one or more vSphere clusters (minimum 3 hosts for vSAN OSA, or 3 hosts for vSAN ESA, though 4 is recommended for N+1 redundancy) with its own dedicated vCenter Server instance.
• Scalability: A single SDDC Manager instance in a Standard Architecture can orchestrate up to 25 workload domains and manage up to 1,000 ESXi hosts, delivering massive enterprise horizontal scale.
• Lifecycle Autonomy: Upgrades and patches can be applied to individual VI Workload Domains independently without affecting the Management Domain or other tenant domains, dramatically reducing maintenance windows and operational risk.

2. Consolidated Architecture (Resource-Constrained Model)

The Consolidated Architecture is engineered for small-scale deployments, remote offices, edge datacenters, or proof-of-concept (POC) environments where physical server count is severely constrained.

• Single Shared Cluster: Both management virtual appliances (SDDC Manager, vCenter, NSX Manager) and customer tenant virtual machines reside on the same physical 4-host ESXi cluster.
• Logical Isolation via Resource Pools: Rather than physical host separation, isolation between management services and user workloads is enforced logically through vSphere Resource Pools:
  • Management Resource Pool: High CPU/RAM reservations allocated for SDDC Manager, vCenter, and NSX.
  • User Workload Resource Pool: Shares and reservations configured for business applications.
• Operational Trade-offs and Limitations:
  • Noisy Neighbor Risk: High compute or storage I/O spikes in user workloads can adversely contend with management control-plane appliances if reservations are misconfigured.
  • Converged Blast Radius: Any physical cluster failure, network disruption, or misconfigured storage policy affects both administrative management and business production workloads simultaneously.
  • Upgrade Contention: Upgrading the cluster's ESXi hosts or shared vCenter Server requires coordinated maintenance windows that impact both management infrastructure and production applications.
  • Migration Path: To scale a Consolidated Architecture into a Standard Architecture, administrators must deploy a new dedicated VI Workload Domain, migrate tenant workloads to the new domain via cross-vCenter vMotion, and reconfigure the original cluster strictly as a Management Domain.

Architectural Comparison Matrix

---

Environmental and Infrastructure Prerequisites

Before initiating VMware Cloud Foundation deployment via the VCF Installer, the underlying physical infrastructure must be meticulously prepared. Failure to satisfy these prerequisites results in immediate precheck aborts or subtle, difficult-to-diagnose runtime failures during bring-up.

1. DNS Resolution Requirements

Domain Name System (DNS) is the most critical dependency during VCF bring-up. Every physical host, virtual machine, and virtual IP (VIP) must have accurate, pre-configured forward and reverse DNS records.

• Forward (A) and Reverse (PTR) Records: Must be fully populated and operational on authoritative corporate DNS servers prior to bring-up for:
  • All physical ESXi host FQDNs and management IP addresses
  • SDDC Manager FQDN and IP address
  • Management vCenter Server FQDN and IP address
  • All three NSX Manager node FQDNs and individual IP addresses
  • NSX Management Cluster Virtual IP (VIP) FQDN and IP address
  • VCF Installer appliance FQDN and IP address
• Strict Case Sensitivity & Resolution Integrity: All hostnames and domain names must use lowercase characters. Ephemeral or split-horizon DNS environments that yield intermittent NXDOMAIN responses will halt the bring-up workflow immediately.

2. Network Time Protocol (NTP) Synchronization Tolerance

Time synchronization is strictly enforced across every layer of the software-defined datacenter. Clock skew between any two participating systems must strictly remain under 60 seconds, with best practices targeting sub-second drift.

• Authoritative Time Sources: All ESXi hosts, virtual appliances, and physical Top-of-Rack (ToR) switches must synchronize to identical, highly available, stratum-1 or stratum-2 NTP servers.
• Consequences of Clock Skew (>60s):
  • TLS/SSL Handshake Rejection: Modern certificate validation routines reject tokens and handshakes if appliance system clocks disagree on validity timestamps.
  • Single Sign-On (SSO) Token Invalidation: VMware Identity Services and OAuth/OIDC tokens expire prematurely or fail replay-detection checks.
  • vSAN Cluster Quorum Partitioning: vSAN distributed object metadata and Paxos consensus state machines drop membership when raft heartbeats encounter timestamps out of sequence.

3. Network VLAN Allocations and IP Subnetting

Deploying the VCF Management Domain requires carving out dedicated, non-overlapping VLANs across the physical switching fabric. Trunking must be enabled on physical switch ports connected to ESXi physical network interface cards (pNICs).

Physical Switch Trunk Port (vmnic0 / vmnic1)
  ├── VLAN 10: Management Traffic (Untagged/Tagged, Routable)
  ├── VLAN 20: vSAN Storage Traffic (Tagged, Non-Routable Layer 2, Jumbo Frames)
  ├── VLAN 30: vMotion Traffic (Tagged, Routable or Non-Routable, Jumbo Frames)
  ├── VLAN 40: Geneve Host Overlay TEP (Tagged, Routable L3, MTU 1700+)
  ├── VLAN 50: Geneve Edge Overlay TEP (Tagged, Routable L3, MTU 1700+)
  ├── VLAN 60: Uplink 1 eBGP Peering (Tagged, /30 or /31 Transit to ToR-A)
  └── VLAN 70: Uplink 2 eBGP Peering (Tagged, /30 or /31 Transit to ToR-B)

• Management VLAN: Carries administrative traffic for ESX vmk0, vCenter Server, SDDC Manager, NSX Manager, VCF Operations, and the VCF Installer. Typically routable across the enterprise corporate network.
• vSAN VLAN: Dedicated to vSAN storage clustering and replication. Must be isolated, non-routable across external networks, and maintain low latency (<1ms RTT). Layer 2 adjacency is required across all hosts within the cluster.
• vMotion VLAN: Dedicated to live virtual machine migration. Recommended to be isolated and non-routable, though multi-NIC vMotion across routed networks is supported for cross-datacenter migrations.
• Host Overlay TEP VLAN: Carries Geneve-encapsulated East-West virtual machine overlay traffic between ESXi host Tunnel Endpoints (TEPs). Must be routed if clusters span multiple Layer 2 broadcast domains.
• Edge Overlay TEP VLAN: Dedicated to Geneve encapsulation between NSX Edge nodes and ESXi host transport nodes for North-South service routing.
• Uplink VLANs (Uplink 1 & Uplink 2): Point-to-point transit VLANs connecting NSX Tier-0 Gateway uplinks to upstream physical ToR switches for external external IP routing.

4. Maximum Transmission Unit (MTU) Sizing Requirements

Virtual network overlays encapsulate standard Ethernet frames within outer IP/UDP/Geneve headers. To prevent catastrophic packet fragmentation and CPU-intensive reassembly, physical network switches must support Jumbo Frames.

• NSX Geneve Overhead: Geneve encapsulation adds exactly 50 bytes of packet header overhead (14-byte outer Ethernet + 20-byte outer IP + 8-byte outer UDP + 8-byte Geneve header).
• Minimum Mandatory MTU: The physical network must support an MTU of at least 1700 bytes end-to-end between all host and edge TEP interfaces.
• Enterprise Best Practice (9000 Bytes): Broadcom strongly recommends configuring an MTU of 9000 bytes (Jumbo Frames) end-to-end across all physical switch ports, inter-switch links (ISLs), spine-leaf fabrics, and ESXi vSwitch uplinks. This accommodates Geneve encapsulation with ample margin and dramatically optimizes vSAN replication and vMotion throughput.

5. BGP Autonomous System Number (ASN) and Routing Planning

North-South routing between the NSX software-defined fabric and the physical datacenter relies on external Border Gateway Protocol (eBGP).

• Autonomous System Numbers (ASNs): Administrators must plan 2-byte (64512–65534) or 4-byte (4200000000–4294967294) private ASNs. The Tier-0 gateway runs an independent BGP process that peers with the physical ToR switches (acting as BGP neighbors).
• Equal-Cost Multi-Pathing (ECMP): NSX Tier-0 Gateways support up to 8 active ECMP paths to upstream physical routers. This requires physical ToR switches to support BFD (Bidirectional Forwarding Detection) for sub-second failure detection and deterministic path failover.

6. Hardware Compatibility and ESXi Host Preparation

Every server selected for VCF must comply strictly with the VMware Compatibility Guide (VCG) and vSAN Hardware Compatibility List (HCL).

• vSAN ReadyNode Profiles: Physical servers must match certified vSAN ReadyNode specifications for CPU generation, memory density, controller firmware, and disk drive models.
• Clean Disk Requirement: All local storage drives intended for vSAN (both NVMe drives for vSAN Express Storage Architecture [ESA] or SSD/HDD pairs for Original Storage Architecture [OSA]) must be completely blank. Disks must contain no existing partition tables, no remnant VMFS filesystems, and no software RAID metadata. VCF Installer validation will fail if foreign partitions are detected.
• ESXi Base Installation: Hosts must have a fresh installation of the exact ESXi version matching the target VCF Bill of Materials (BOM). The initial configuration requires:
  • Standard vSwitch (vSwitch0) attached to physical uplink vmnic0
  • Management VMkernel port (vmk0) configured with static IP, mask, gateway, DNS, and NTP
  • SSH service enabled and set to start automatically
  • Initial root password set identically across all participating hosts

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] The 1700 vs 9000 Byte MTU Exam Trap: Questions testing network prerequisites frequently ask for the absolute minimum MTU required for NSX Geneve overlay traffic versus the recommended MTU. The absolute minimum is 1700 bytes (1500 byte payload + 50 byte Geneve overhead + safety margin). However, the enterprise standard for production is 9000 bytes. Selecting 1500 bytes for Geneve overlay will result in immediate packet drops and transport node configuration failure.

[!WARNING] Remnant Disk Partitions Halt Bring-Up: A common real-world and exam failure scenario involves repurposing existing lab or server hardware for a VCF bring-up. If the disks previously hosted VMFS volumes or Linux partitions, VCF Installer validation reports a fatal disk claim error. Administrators must execute partedUtil delete or wipe disk headers using wipefs prior to bring-up.

[!NOTE] NTP Skew Severity: The maximum allowable time difference across any VCF component during bring-up is 60 seconds. In real-world environments, even a 15-second drift can disrupt VMware Single Sign-On token synchronization between the VCF Installer and the newly deployed vCenter Server Appliance.