Deep Dive of the Day VCF Automation in 9.1: three nodes, seven addresses, two FQDNs and the load balancer you already have
VCF Automation 9.x isn't the old Aria Automation appliance with a new name. The VCF Installer deploys it as three appliance VMs that together form a Kubernetes-based runtime, and that changes how you plan addresses, DNS and load balancing. If you're coming from 8.18 or building your first 9.1 instance, getting this right up front saves a redeploy later.
Start with the numbers in the TechDocs planning table for the first VCF instance. VCF Automation needs five IP addresses: three for the nodes and two kept spare "as a buffer for automatic redeployment of failed nodes or for rolling updates in the future". It also needs two FQDNs: one for VCF Automation itself and one for the VCF services runtime, and each FQDN needs its own unused IP outside the node range, so plan on seven addresses in all. Unlike VCF Operations, those counts are the same whether you pick the simple or the high-availability deployment model. Don't hand the two spare addresses to anything else; the upgrade and scale-out workflows expect to find them free.
The two FQDNs do different jobs. Per Broadcom's blog, the VCF Automation FQDN carries end-user and API traffic on 443, while the services runtime FQDN carries machine-to-machine control-plane traffic from SDDC Manager and VCF Operations. They're a logical split only: all three nodes and both endpoints share a single NIC on the management port group, so two names don't mean two networks.
Load balancing is built in. kube-vip and Envoy run on all three nodes, hold the virtual IPs, handle failover and spread HTTP and API traffic across the pods. You can put an external load balancer or GSLB (HAProxy, Avi or F5 are the blog's examples) in front for health checks, DNS routing or TLS handling, but the embedded layer stays active and control-plane traffic bypasses the external one. If you do go external or use round-robin DNS, the blog says you'll need per-node VIPs for nodes 2 and 3 as well, kept in the same management subnet to avoid hairpinning; an upgrade from Aria Automation 8.18 brings the total to nine IPs.
A few gotchas from the docs and the field. By default the nodes land on the VM management network; 9.1.1 lets you pick a dedicated VLAN in the UI for Day-N deployments. The internal runtime network defaults to 198.18.0.0/15, so if that clashes with anything you route, change it to 240.0.0.0/15 or 250.0.0.0/15 before deployment. Containerised services, VCF Automation included, don't support .local domains, and TechDocs asks for lowercase FQDNs. Chris Kitchens at VCF Insider adds that the FQDN, the primary VIP and the certificate SANs must all line up, and that the primary VIP is "the front door", not just another appliance IP.
In a nested lab the temptation is to skimp on addresses, but the five node IPs and the two FQDN addresses are needed in every deployment model, so carve out all seven and create the DNS records for both names before you start the Installer. Write the plan down too: when a node is redeployed or you run a rolling update, those spare addresses are what the workflow reaches for, and a lab you can rebuild from notes is a lab you'll actually rebuild.
Based on First VCF Instance FQDNs and IP addresses (Broadcom TechDocs) Official Demystifying VCF Automation Node Architecture and Load Balancing (VCF Blog) Official Deploying VCF Automation in the Lab: The Primary VIP Lesson (VCF Insider)
