Network Design for Private Cloud Automation for VMware Cloud Foundation

For secure access to the UI and API of VMware Aria Automation, you place the cluster nodes on the cross-instance NSX segment. This configuration also supports user access to the VMware Aria Automation cluster.

Network Segment

The network segments design consists of characteristics and decisions for placement of VMware Aria Automation in the management domain.

This validated solution uses an implementation of the VMware Cloud Foundation application virtual networks feature in the management domain provided by NSX. The application virtual networks in the management domain can be either overlay-backed NSX segments or VLAN-backed NSX segments.

Table 1. NSX Segment Types

Type	Description
Overlay-backed NSX segment	The routing to the VLAN-backed management network segment and other networks can use dynamic routing protocols or static routing. Routed access to the VLAN-backed management network segment is provided through an NSX Tier-1 and Tier-0 gateways. Recommended option to facilitate scale out to a multi instance design supporting disaster recovery.
VLAN-backed NSX segment	You must provide one unique VLAN, network subnet, and vCenter Server portgroup name.

Figure 1. Network Design of the VMware Aria Automation Deployment on Overlay-Backed NSX Segments

Table 2. Design Decisions on the Network Segment for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-001	Place the VMware Aria Automation cluster nodes on the cross-instance NSX network segment.	Provides a consistent deployment model for management applications and a potential to extend to a second VMware Cloud Foundation instance for disaster recovery.	You must use an implementation of NSX to support this networking configuration.

IP Addressing

Allocate statically assigned IP addresses and host names to the VMware Aria Automation cluster nodes and the load balancer from their corresponding network.

By default, the following network ranges are reserved for the internal Kubernetes configuration in VMware Aria Automation.

Table 3. Kubernetes Default Network Ranges

Setting	Value
Kubernetes cluster IP range	10.244.0.0/22
Kubernetes service IP range	10.244.4.0/22

If the Kubernetes default network ranges conflict with your environment, you can override the defaults during the deployment of VMware Aria Automation. Additionally, you can reconfigure the settings as a day-two action by using VMware Aria Suite Lifecycle.

Table 4. Design Decisions on the IP Addressing for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-002	Allocate statically assigned IP addresses from the cross-instance NSX segment to the VMware Aria Automation cluster nodes and the NSX load balancer virtual server.	Using statically assigned IP addresses ensures stability of the deployment and makes it simpler to maintain and easier to track.	Requires precise IP address management.

Name Resolution

Name resolution provides the translation between an IP address and a fully qualified domain name (FQDN), which makes it easier to remember and connect to components across the SDDC. The IP address of each VMware Aria Automation cluster node and the load balancer VIP must have a valid internal DNS forward (A) and reverse (PTR) record.

Table 5. Design Decisions on Name Resolution for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-003	Configure forward and reverse DNS records for each VMware Aria Automation cluster node IP address and for the NSX load balancer virtual server IP address.	VMware Aria Automation is accessible by using a fully qualified domain name instead of by using IP addresses only.	You must provide DNS records for each VMware Aria Automation cluster node and the NSX load balancer virtual server IP address. Firewalls between the VMware Aria Automation cluster nodes and the DNS servers must allow DNS traffic.
PCA-VAA-NET-004	Configure DNS servers for each VMware Aria Automation cluster node.	Ensures that VMware Aria Automation has accurate name resolution on which its services are dependent.	DNS infrastructure services should be highly-available in the environment. Firewalls between the VMware Aria Automation cluster nodes and the DNS servers must allow DNS traffic. You must provide two or more DNS servers unless a DNS geographic load balancing is activated.

Load Balancing

A VMware Aria Automation cluster deployment requires a load balancer to manage the connections to the VMware Aria Automation services.

This validated solution uses load-balancing services provided by NSX in the management domain. The load balancer is automatically configured by VMware Aria Suite Lifecycle and SDDC Manager during the deployment of VMware Aria Automation.

Table 6. VMware Aria Automation Load Balancer Configuration

Load Balancer Element	Settings
Service monitor	Name: vra-http-monitor Port and Protocol Monitoring port: 8008 Monitoring protocol: HTTP Default intervals and timeouts: Monitoring interval: 3 seconds Idle timeout period: 10 seconds Rise/Fall: 3 seconds. HTTP request: HTTP method: Get HTTP request version: 1.1 Request URL: /health HTTP response: HTTP response code: 200
Server pool	Name: vra-server-pool Algorithm: LEAST_CONNECTION SNAT translation mode: Auto Map Static members: Name: vra_node_hostname IP address: vra_node_ip_address Port: 443 Weight: 1 State: Enabled Service monitor: autogenerated_service_monitor_name
TCP application profile	Name: vra-tcp-app-profile Timeout: 1800 seconds (30 minutes)
HTTP redirect application profile	Name: vra-http-app-profile-redirect Timeout: 1800 seconds (30 minutes). Redirection: HTTP to HTTPS Redirect
Virtual server	Name: vra-https HTTP type: L4 Port: 443 IP address: vra_cluster_virtual_ip_address Application profile: autogenerated_tcp_application_profile_name Server pool: autogenerated_server_pool_name
HTTP redirect virtual server	Name: vra-http-redirect HTTP type: L7 Port: 80 IP address: vra_cluster_virtual_ip_address Persistence: Disabled Application profile: autogenerated_http_redirect_application_profile_name Server pool: None.

Table 7. Design Decisions on Load Balancing for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-005	Use the small-size NSX load balancer that is configured by SDDC Manager on the dedicated NSX Tier-1 gateway in the management domain to load balance the clustered Workspace ONE Access deployment, to also load balance the connections across the VMware Aria Automation cluster nodes.	Required to deploy VMware Aria Automation as a cluster deployment type. The VMware Aria Automation cluster can handle a greater load and obtain a higher level of service availability. During the deployment of VMware Aria Automation by using VMware Aria Suite Lifecycle, SDDC Manager automates the configuration of the NSX load balancer for the VMware Aria Automation cluster on a standalone NSX Tier-1 gateway.	You must use the NSX load balancer that is configured by SDDC Manager and the integration with VMware Aria Suite Lifecycle to support this network configuration.

Time Synchronization

VMware Aria Automation depends on system time synchronization for all cluster nodes. The system time for the VMware Aria Automation nodes, along with dependencies and integrations, such as VMware Aria Suite Lifecycle, Workspace ONE Access, and VMware Aria Operations, must be synchronized and must use the same timezone.

Table 8. Design Decisions on Time Synchronization for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-006	Configure NTP servers for each VMware Aria Automation cluster node.	Ensures that VMware Aria Automation has accurate time synchronization on which its services are dependent. Assists in the prevention of time mismatch between the VMware Aria Automation nodes and dependencies.	NTP infrastructure services should be highly-available in the environment. Firewalls between the VMware Aria Automation cluster nodes and the NTP servers must allow NTP traffic. You must provide two or more NTP servers unless an NTP geographic load balancing is activated.