NC2 Cluster Build Fails at 70% in West Europe
Contoso is deploying a four-node NC2 cluster on Azure in West Europe to host 60 AHV VMs and 18 TB of usable storage. The landing zone uses a hub-and-spoke topology. The NC2 spoke VNet has a single /24 subnet, and an NSG attached to it allows inbound TCP 9440 only from the on-premises /24 management range over ExpressRoute. Azure quota for the selected NC2 node family shows 16 vCPUs available in the region, and the subscription has no capacity reservation. The first deployment attempt fails at 70% with a cluster-formation error; the fourth node never appears in Prism Element, and Prism Central cannot be reached from the on-premises jump host. The team also wants to add a second cluster later in the same subscription. They need to keep management traffic private and avoid re-IP addressing workloads after go-live.
1. What is the most likely cause of the failed cluster formation, and what should you verify before retrying? Include the immediate remediation.
Read the worked answer
The 70% failure with only three nodes visible points first to Azure capacity/quota, not to a Nutanix configuration error. The subscription shows 16 vCPUs available for the chosen node family; a fourth node needs its full vCPU and memory allocation, and without a capacity reservation Azure can also fail allocation even when quota looks sufficient. Verify regional quota and actual available capacity for that family, subnet free IPs (each node and CVM needs addresses), NSG and route symmetry for Prism Element and Prism Central, and whether the deployment template uses a stale image or placement option. The immediate remediation is to request a quota increase or reserve capacity for all four nodes, confirm the subnet has enough free addresses, then redeploy or resume. Do not treat the Prism Central unreachable symptom as the root cause yet: if the cluster never formed, PC registration could not complete. After cluster formation, test TCP 9440 from the jump host and check NSG and ExpressRoute routes.
2. Propose the subnet and NSG design for the NC2 spoke, including management versus workload traffic and the later second cluster. Explain why a single /24 is or is not sufficient.
Read the worked answer
A single /24 can technically hold 60 VMs, but it mixes management, workload, and future-cluster traffic and makes NSG rules coarse. Build separate subnets: management for Prism Element/Central, CVMs, and jump hosts; workload subnets per application tier; a gateway or firewall subnet if using Azure Firewall; and a separate subnet for the second cluster so its address space does not overlap. Size each subnet with growth: a /24 per cluster may be acceptable for 60 VMs, but if IPs are consumed by CVMs, Prism Central, load balancers, and test clones, a /23 for workloads is safer. NSGs should allow 9440 only from the management subnet and authorized on-premises range, restrict SMB/NFS to workload subnets, deny inbound internet, and use application security groups. Keep management private via ExpressRoute/VPN and Azure Bastion; do not assign public IPs. For the second cluster, allocate a non-overlapping VNet or address space up front to avoid re-IP.
3. Should the team use availability zones or a single availability set for the NC2 cluster? Justify with the constraints.
Read the worked answer
For a single NC2 cluster, prioritize low-latency, supported placement over zone sprawl. Spread cluster nodes across Azure availability zones only if the NC2 release and node type explicitly support it; otherwise use a single zone or proximity placement group so CVM-to-CVM and storage replication traffic stays within the latency budget. A four-node cluster already tolerates one node failure at the Nutanix layer, so the bigger risk is an unsupported stretched cluster that increases rebuild time and operational complexity. Use a second NC2 cluster in another zone or region for site-level DR rather than stretching one cluster. Verify quota and capacity in the chosen zone before deployment. If the business requires zone-level resilience, design application-level replication to a second cluster and test failover; do not assume an availability set gives zone redundancy.