Three-Node VxRail ESA Design with a RAID-5 Policy Requirement
A remote manufacturing site orders three VxRail VP-760 nodes. The customer wants vSAN ESA with a RAID-5 FTT=1 storage policy to maximize usable capacity, and an external vCenter 8.0 because corporate policy requires a central management domain. The site has a /24 management subnet and a /24 vSAN subnet, but no DHCP; all addresses are static. DNS and NTP are provided by the corporate data center over a WAN link. The customer plans to add a fourth node next fiscal year, but wants RAID-5 enabled from day one. During the deployment review, the partner notices the cluster has only three nodes and asks whether the design can meet the policy. The customer does not want to buy a fourth node now and asks for a workaround that keeps the policy compliant.
1. Can a three-node VxRail cluster run vSAN ESA with RAID-5 FTT=1? Explain the fault-domain requirement and the realistic options.
Read the worked answer
No. In vSAN ESA, RAID-5 FTT=1 is a fault-domain policy that needs at least four hosts; with three hosts there are not enough independent failure domains to place the parity and data components. A three-node cluster can run FTT=1 with RAID-1 mirroring across separate hosts, but it cannot satisfy a RAID-5 FTT=1 policy. If you assign RAID-5 to VMs on three hosts, the objects go non-compliant and may become inaccessible; that is not a 'workaround,' it is an outage waiting to happen.
Realistic options:
- Buy the fourth node now and deploy four hosts before putting production VMs on the cluster.
- Deploy three hosts with RAID-1 FTT=1 and change the VM storage policy to RAID-5 only after the fourth node is added.
- If the customer insists on RAID-5 now, document that the design is unsupported for the current host count and do not present it as compliant.
Because vSAN ESA uses storage pools rather than disk groups, adding the fourth host contributes capacity and fault domains without a disk-group rebuild. Capacity planning should still account for RAID-5 overhead, and the customer should accept that the policy cannot be applied until the fourth host is contributing.
2. What external vCenter prerequisites must be validated before deployment, and how would a vCenter version mismatch present?
Read the worked answer
Validate the external vCenter against the VxRail compatibility matrix for the exact target VxRail release, not just 'vCenter 8.0.' Check:
- vCenter build is in the supported range and the VxRail Manager plugin version is compatible.
- Forward and reverse DNS for vCenter, VxRail Manager, and all ESXi hosts; VxRail requires PTR records, not only A records.
- NTP synchronization on vCenter, VxRail Manager, and ESXi; time skew breaks SSO and certificate operations.
- The SSO account used for VxRail has the required permissions and is not locked; service accounts are not expiring.
- Required ports and any firewall between the management networks.
- vCenter has no duplicate VM or network names that collide with VxRail objects.
A mismatch usually appears as a deployment pre-check failure or as VxRail Manager failing to register its extension. Do not 'fix' it by deploying with an unsupported vCenter; align the versions first. If the vCenter build is unsupported, the deployment may complete partially and leave orphaned objects, which is harder to recover than correcting the prerequisite.
3. If the customer adds the fourth node next year, what changes are needed to move from RAID-1 to RAID-5, and what operational checks apply?
Read the worked answer
Add the fourth node through VxRail Manager's expansion workflow, then validate vSAN health before changing policy. Once four hosts are contributing, create or edit a VM storage policy with RAID-5 FTT=1 and apply it to the VMs, or to the datastore default if appropriate. The policy change triggers reconfiguration; monitor resync and rebalance traffic and capacity, and do it in a change window because it generates I/O. Confirm compliance with vSAN health and object compliance reports, not just the UI. If the cluster is already heavily used, RAID-5 can change overhead; recalculate free space. Do not delete the old RAID-1 policy until all objects are compliant.