6.2 Deploying & Configuring a vSAN Cluster

6.2 Deploying & Configuring a vSAN Cluster

Deploying a resilient, high-performance VMware vSAN cluster requires careful alignment between physical hardware validation, cluster topology design, network engineering, and day-two lifecycle maintenance. Because vSAN aggregates local host drives across the network, cluster stability depends directly upon predictable communication paths and strict compliance with the VMware Compatibility Guide.

---

Hardware Requirements & HCL Validation

The most frequent cause of storage instability, performance degradation, or data unavailability in vSAN environments is uncertified hardware. Unlike traditional SAN arrays where storage controllers manage drive interactions within a closed proprietary chassis, vSAN tasks the ESXi hypervisor with orchestrating raw physical drives across enterprise host buses.

vSAN ReadyNodes vs. Custom Builds

To eliminate hardware interoperability risks, Broadcom and server OEM partners offer vSAN ReadyNodes:

• Pre-Configured & Validated: A vSAN ReadyNode is a tested server configuration pre-loaded with certified CPU models, memory capacities, network interface cards (NICs), storage controllers, and solid-state drives sized to meet specific performance and capacity tiers.
• Simplified Support: ReadyNodes carry dedicated profile identifiers (such as ESA-AF-8 or OSA-AF-6), streamlining procurement and ensuring day-one compatibility with vSphere Lifecycle Manager (vLCM) hardware support managers.
• Custom "Build-Your-Own" Constraints: If deploying custom server hardware, every component in the storage I/O path—host bus adapters (HBAs), drive backplanes, SSDs, and NIC transceivers—must be rigorously verified against the vSAN Hardware Compatibility List (HCL). Use the certified controller mode and exact firmware/driver combination. Some supported OSA controllers use passthrough and some use RAID-0 presentation; do not impose a universal controller mode or queue depth.
• Firmware and Driver Lockstep: Controller and NVMe drive firmware must match the exact version certified for the installed ESXi VMkernel driver. Even minor firmware discrepancies can cause controller timeouts, command aborts, and cluster health alarms.

---

vSAN Cluster Deployment Topologies

vSAN supports three distinct cluster topologies tailored to different operational scopes and availability requirements:

1. Standard vSAN Cluster

A standard vSAN cluster resides within a single physical datacenter site:

• Minimum Node Count: Requires a minimum of three ESXi hosts to establish an operational cluster under the default RAID-1 (FTT=1) storage policy. Under FTT=1, vSAN creates two mirrored data components and one tie-breaking witness component, requiring three distinct physical hosts to ensure no single host failure compromises quorum.
• The 4-Host Production Recommendation: Although a three-host cluster is fully functional, four or more hosts are strongly recommended for production environments. In a three-host cluster, if a single host fails, the remaining two hosts maintain object quorum, but vSAN cannot rebuild the missing replica because there is no fourth host available to hold the new mirror component. The cluster remains in a degraded, non-redundant state until the failed host is physically repaired. With four or more hosts (N+1 redundancy), vSAN has a potential placement target for repair, subject to the repair timer and available capacity onto surviving hosts, restoring full fault tolerance.

2. Two-Node vSAN Cluster

Tailored for remote offices, branch offices (ROBO), and edge locations where deploying three or more physical hosts is economically impractical:

• Architecture: Two physical ESXi hosts run active virtual machine workloads and store mirrored data components (RAID-1).
• The External Witness Host: Because two nodes cannot form a tie-breaking majority during a network partition, a specialized Witness Host (typically a lightweight virtual appliance running a specialized ESXi instance) is deployed outside the cluster—typically in a central datacenter or cloud environment. The witness host stores only small metadata witness components (votes) and does not store VM data disks.
• Witness Traffic Separation (WTS): A key architectural feature that allows administrators to bind witness network communication to a dedicated VMkernel interface on a routable management network. This isolates low-bandwidth witness communication (which supports WAN links with up to 500 ms round-trip time) from high-throughput, low-latency inter-node storage traffic.

3. Stretched vSAN Cluster

Provides cross-site disaster tolerance and active-active datacenter availability across metropolitan distances:

• Topology: Configured with three physical locations: the Preferred Site, the Secondary Site, and an independent Witness Site.
• Synchronous Mirroring: Virtual machine data is mirrored synchronously between the Preferred and Secondary sites, guaranteeing a Zero Recovery Point Objective (RPO) in the event of a total site failure.
• Network Latency Requirements: High-bandwidth links between the Preferred and Secondary data sites must maintain a strict round-trip time (RTT) latency of <= 5 milliseconds (supporting 10 GbE or faster connections). The link to the independent Witness Site supports higher latencies (typically up to 100–200 ms RTT depending on cluster size).

---

vSAN Networking Architecture & Best Practices

Because vSAN is a distributed storage architecture, network throughput and deterministic packet delivery are paramount. Modern vSAN configurations adhere to the following network engineering standards:

VMkernel Interface Configuration

Each ESXi host participating in vSAN requires at least one dedicated VMkernel adapter (vmk) with the vSAN service flag enabled. Multi-NIC configurations can leverage multiple VMkernel adapters across redundant uplinks for load balancing and fault tolerance.

Unicast Communication (Multicast Retirement)

Historically, vSAN relied on network multicast and IGMP snooping for cluster heartbeats and metadata synchronization. Multicast was permanently retired in vSAN 6.6. All modern vSAN releases utilize efficient, routable unicast IP communication. The hypervisor automatically distributes node IP address tables through vCenter Server and cluster membership services (CMMDS).

Switch Architecture & Traffic Management

• vSphere Distributed Switch (vDS): Standardizing on a vDS is strongly recommended. A vDS enables centralized configuration, uniform teaming policies, and the use of Network I/O Control (NIOC).
• Network I/O Control (NIOC): When vSAN traffic shares physical 10 GbE or 25 GbE uplinks with VM traffic, vMotion, or management traffic, NIOC must be configured with bandwidth reservations (typically assigning 40–50% of available bandwidth to vSAN) to prevent vMotion bursts from starving storage I/O.
• MTU & Jumbo Frames: vSAN fully supports the default standard MTU of 1500 bytes. Configuring Jumbo Frames (MTU 9000) is recommended for high-throughput environments because larger packet payloads reduce CPU serialization overhead. However, Jumbo Frames require strict end-to-end consistency: the VMkernel port, vDS, physical switch interfaces, and intervening routers must all support MTU 9000; mismatched MTUs cause packet fragmentation and severe cluster communication failures.

---

Maintenance Mode Actions & Operational Clocks

When performing host lifecycle tasks, firmware patching, or hardware replacements, an ESXi host must be placed into Maintenance Mode. Because the host holds physical components of distributed vSAN objects, the administrator must select an appropriate data evacuation mode:

Evacuation Mode Trade-Offs

1. Full Data Migration: vSAN copies every storage component residing on the host's drives to other hosts in the cluster before entering maintenance mode. Full policy compliance and redundancy are preserved throughout the maintenance window. However, this process consumes significant free cluster capacity, generates heavy network traffic, and can take hours on dense storage nodes.
2. Ensure Accessibility (Default): vSAN evacuates only those components whose absence would cause virtual machines to lose quorum or become inaccessible. If a virtual machine is protected by RAID-1 (FTT=1) and has one mirror on the entering host and another on a surviving host, the component on the entering host is left in place. The VM continues running using the surviving mirror, though its redundancy is temporarily degraded. This is the recommended choice for routine ESXi reboots and software updates.
3. No Data Migration: vSAN evacuates no data components from the host. Any virtual machine object that has components on this host and lacks redundant copies on surviving hosts will immediately become unavailable. This option is reserved for scenarios where all VMs are powered off or during coordinated cluster-wide maintenance.

The 60-Minute CLOM Repair Delay (clomd Timeout)

When a host goes offline unexpectedly or enters maintenance mode using Ensure Accessibility, vSAN marks the absent components with an Absent state rather than a Degraded state.

To prevent the cluster from prematurely launching massive data resynchronizations across the network for a routine five-minute host reboot, vSAN starts an internal countdown clock governed by the advanced parameter the object repair timer, configured by default to 60 minutes:

• Within 60 Minutes: If the host recovers and rejoins the cluster within 60 minutes, vSAN simply resynchronizes the small delta of writes that occurred while the host was offline, restoring redundancy rapidly.
• After 60 Minutes Expire: If the host remains offline after 60 minutes, vSAN can begin repairing absent components if suitable capacity and failure domains are available. Timer expiry does not prove that a host has permanently failed and cannot create missing rebuild capacity.

Official Reading

Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.

Review Takeaways

• Validate the exact ReadyNode/device, firmware, driver and controller mode combination.
• A standard RAID-1 FTT=1 layout needs three independent hosts; additional eligible capacity is needed for rebuilding after a loss.
• Two-node and stretched configurations require the supported separate witness design.
• Maintenance choices trade data movement against accessibility and redundancy; verify the actual object health afterward.