Network Design for Private Cloud Automation for VMware Cloud Foundation

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

Network Segment

The network segments design consists of characteristics and decisions for placement of vRealize 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-T Data Center. 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-T Data Center 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 vRealize Automation Deployment on Overlay-Backed NSX Segments

Table 2. Design Decisions on the Network Segment for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-001	Place the vRealize 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-T Data Center to support this networking configuration.

IP Addressing

Allocate statically assigned IP addresses and host names to the vRealize 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 vRealize 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 vRealize Automation. Additionally, you can reconfigure the settings as a day-two action by using vRealize Suite Lifecycle Manager.

Table 4. Design Decisions on the IP Addressing for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-002	Allocate statically assigned IP addresses from the cross-instance NSX segment to the vRealize 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 vRealize 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 vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-003	Configure forward and reverse DNS records for each vRealize Automation cluster node IP address and for the NSX load balancer virtual server IP address.	vRealize Automation is accessible by using a fully qualified domain name instead of by using IP addresses only.	You must provide DNS records for each vRealize Automation cluster node and the NSX load balancer virtual server IP address. Firewalls between the vRealize Automation cluster nodes and the DNS servers must allow DNS traffic.
PCA-VRA-NET-004	Configure DNS servers for each vRealize Automation cluster node.	Ensures that vRealize Automation has accurate name resolution on which its services are dependent.	DNS infrastructure services should be highly-available in the environment. Firewalls between the vRealize 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 vRealize Automation cluster deployment requires a load balancer to manage the connections to the vRealize Automation services.

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

Table 6. vRealize 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 vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-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 vRealize Automation cluster nodes.	Required to deploy vRealize Automation as a cluster deployment type. The vRealize Automation cluster can handle a greater load and obtain a higher level of service availability. During the deployment of vRealize Automation by using vRealize Suite Lifecycle Manager, SDDC Manager automates the configuration of the NSX load balancer for the vRealize 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 vRealize Suite Lifecycle Manager to support this network configuration.

Time Synchronization

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

Table 8. Design Decisions on Time Synchronization for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-006	Configure NTP servers for each vRealize Automation cluster node.	Ensures that vRealize Automation has accurate time synchronization on which its services are dependent. Assists in the prevention of time mismatch between the vRealize Automation nodes and dependencies.	NTP infrastructure services should be highly-available in the environment. Firewalls between the vRealize 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.