Load Balancing for the Management Domain

The logical load balancer capability in NSX-T Data Center offers a high-availability service for applications in VMware Cloud Foundation and distributes the network traffic load among multiple servers.

Load Balancing for a Single VMware Cloud Foundation Instance

Because it is a stateful service, a load balancer in the VMware Cloud Foundation instance requires another Tier-1 gateway.

Table 1. Design Decisions on Load Balancing

Decision ID	Design Decision	Design Justification	Design Implication
VCF-MGMT-NSX-SDN-022	Deploy a standalone Tier-1 gateway to support advanced stateful services such as load balancing for other management components.	Provides independence between north-south Tier-1 gateways to support advanced deployment scenarios.	You must add a separate Tier-1 gateway.
VCF-MGMT-NSX-SDN-023	Connect the standalone Tier-1 gateway to cross-instance NSX segments.	Provides load balancing to applications connected to the cross-instance network. For information on the NSX segment configuration for vRealize Suite, see VMware Validated Design for vRealize Lifecycle and Access Management.	You must connect the gateway to each network that requires load balancing.
VCF-MGMT-NSX-SDN-024	Configure the standalone Tier-1 gateway with static routes to the gateways of the networks it is connected to.	Because the Tier-1 gateway is standalone, it does not autoconfigure its routes.	You must configure the gateway for each network that requires load balancing.

Load Balancing for Multiple VMware Cloud Foundation Instances

NSX Federation does not support load balancing as a federated service. You must create an additional standalone Tier-1 gateway in the second VMware Cloud Foundation instance to provide a cold-standby availability of the load balancing service if a failure in the first VMware Cloud Foundation instance occurs.

Table 2. Design Decisions on Load Balancing for Multiple VMware Cloud Foundation Instances

Decision ID	Design Decision	Design Justification	Design Implication
VCF-MGMT-NSX-SDN-FED-010	Deploy a standalone Tier-1 gateway in the second VMware Cloud Foundation instance.	Provides a cold-standby non-global service router instance for the second VMware Cloud Foundation instance to support services on the cross-instance network which require advanced services not currently supported as NSX-T global objects.	You must add a separate Tier-1 gateway. You must manually configure any services and synchronize them between the non-global service router instances in the first and second VMware Cloud Foundation instances. To avoid a network conflict between the two VMware Cloud Foundation instances, make sure that primary and standby networking services are not both active at the same time.
VCF-MGMT-NSX-SDN-FED-011	Connect the standalone Tier-1 gateway in the second VMware Cloud Foundation instance to the cross-instance NSX segment.	Provides load balancing to applications connected to the cross-instance network in the second VMware Cloud Foundation instance.	You must connect the gateway to each network that requires load balancing.
VCF-MGMT-NSX-SDN-FED-012	Configure the standalone Tier-1 gateway in the second VMware Cloud Foundation instance with static routes to the gateways of the networks it is connected to.	Because the Tier-1 gateway is standalone, it does not autoconfigure its routes.	You must configure the gateway for each network that requires load balancing.

Operational Considerations

While you create a standalone Tier-1 gateway in each VMware Cloud Foundation instance for networking services, these gateways are independent of each other and you must manually configure them according to the requirements for each instance.

For instance, for a load balancer available across multiple VMware Cloud Foundation instances, the standalone Tier-1 gateway in the first instance is the primary-active load balancer while the standalone Tier-1 gateway in the second instance is configured but its services are disconnected. In this case, both Tier-1 gateways have identical load balancer configuration but only the one in the first VMware Cloud Foundation instance is active.

You must then manually duplicate any configuration changes on the first to the second instance so that the second instance is always ready to bring it online.

Table 3. Design Decisions on Load Balancer Operations for Multiple VMware Cloud Foundation Instances

Decision ID	Design Decision	Design Justification	Design Implication
VCF-MGMT-NSX-SDN-FED-013	Establish an operational practice to reproduce any changes made on the network service configuration on the load balancer instance in the first VMware Cloud Foundation instance to the disconnected failover load balancer in the second instance.	Keeps the network service in the failover load balancer instance ready for activation if a failure in the first VMware Cloud Foundation instance occurs. Because network services are not supported as global objects, you must configure them manually in each VMware Cloud Foundation instance. The load balancer service in one instance must be connected and active, while the service in the other instance must be disconnected and inactive.	Because of incorrect configuration between the VMware Cloud Foundation instances, the load balancer service in the second instance might come online with an invalid or incomplete configuration. If both VMware Cloud Foundation instances are online and active at the same time, a conflict between services could occur resulting in a potential outage. The administrator must establish and follow an operational practice by using a runbook or automated process to ensure that configuration changes are reproduced in each VMware Cloud Foundation instance.
VCF-MGMT-NSX-SDN-FED-014	Establish an operational practice to ensure that during failure of the first VMware Cloud Foundation instance, a service is manually brought online in the second VMware Cloud Foundation instance.	Provides support for the management applications that are failed over to the second VMware Cloud Foundation instance. Because network services are not supported as global objects, you must configure them manually in each VMware Cloud Foundation instance. The load balancer service in one instance must be connected and active, while the service in the other instance must be disconnected and inactive.	The administrator must establish and follow an operational practice by using a runbook or automated process to ensure the correct services are brought online.
VCF-MGMT-NSX-SDN-FED-015	Establish an operational practice to manually bring offline the load balancer services in the first VMware Cloud Foundation instance after failover to the second instance and during the recovery of the first instance.	During the recovery of the first VMware Cloud Foundation instance, the service might come back online and cause a potential conflict with the active services still running on the first instance. Because network services are not supported as global objects, you must manually fail over services in the recovery VMware Cloud Foundation instance. The load balancer service in one instance must be connected and active, while the service in the other instance must be disconnected and inactive.	The administrator must establish and follow an operational practice by using a runbook or automated process to ensure the correct services are brought offline as quickly as practical. If both VMware Cloud Foundation instances are online and active at the same time, a conflict between the services might occur resulting in a potential outage.