NC2 on Azure Architecture, Deployment, and Networking
Domain 1: NC2 on Azure architecture, deployment, and networking
This domain tests whether you can map the Nutanix stack onto Azure's dedicated bare-metal model and design a deployable cluster. NC2 is not a nested-virtualization product: each node is a Nutanix-certified Azure bare-metal instance, and AHV runs directly on that hardware.
Core architecture
- AOS pools local NVMe devices across cluster nodes into a distributed storage fabric; Azure managed disks are not the storage layer.
- Each cluster has a Prism Element; Prism Central is deployed separately (in Azure or on-premises) and registered to the cluster. The NC2 console handles cluster create/scale/delete.
- Azure objects include a resource group, VNet/subnet, network security group, and the bare-metal nodes. The NC2 service principal needs subscription permissions to deploy them.
Networking rules
- Reserve enough subnet IPs for every node, the Prism Element VIP, the cluster VIP, Prism Central (if in Azure), and any AHV address pools.
- Guest VM traffic is bridged to the Azure VNet; Azure NSGs filter at the subnet/NIC boundary, while Nutanix Flow can apply distributed microsegmentation inside the cluster.
- Connect to on-premises with VNet peering, site-to-site VPN, or ExpressRoute; peering is non-transitive, so hub-spoke routing and UDRs must be designed deliberately.
Worked example
A /24 subnet has 251 usable IPs. Three nodes use 3; PE VIP 1; cluster VIP 1; Prism Central 1; AHV IP pool 20; gateway/DNS 3; reserve 30 for growth. That leaves ample space, but a /26 (59 usable) would be tight once PC and pools are added. Count before deployment, not after.
Traps
Assuming Azure managed disks back AOS; treating NC2 as nested VMs; forgetting the NC2 service principal consent; designing a subnet that cannot accommodate VIPs and AHV pools; expecting Azure RBAC to grant Prism rights.