Load Balancing in NSX T
Reference:
This post covers the configuration required to use load balancer which is a native feature in NSX-T.
Pre requisites before configuring load balancer:
1. NSX T Manager Cluster should be deployed
2. Transport zones should be defined.
3. Uplink profiles should be created.
4. Hosts should be configured as Host Transport Nodes.
5. Edge Transport Nodes should be deployed and configured.
6. Edge Cluster should be created.
7. Tier 0 Gateway should be created and peering with physical network should be in place.
 |
| Logical Topology for Load Balancing |
As shown in the above topology, one Tier 0 Gateway aggregates the connections from two Tier 1 Gateways.
There is one Tier 1 Gateway dedicated for load balancing service.
The other Tier 1 Gateway is where the workloads are connected via segments.
Tier 1 Logical Router 2 is a DR only Logical Router/Gateway to which workload segment is connected.
Tier 0 Gateway peers with the physical network and hence always requires edge cluster.
In this lab, we will use the same edge cluster for Tier 0 Gateway and for the Tier 1 Gateway used for load balancing service.
If sufficient resources exist, then dedicated resources can be provided for load balancing service and as such a separate edge cluster can be created which will be used only for services viz. load balancing.
 |
| DR only Tier 1 Gateway |
As shown above, this Tier 1 Gateway is a DR only Tier 1 Gateway.
Segments for workloads are connected to this Tier 1 Gateway.
This Tier 1 Gateway is not associated with any edge cluster.
The DR only status of Tier 1 Gateway can also be verified using the below command on CLI of the edge node.
 |
| DR Only Tier 1 Gateway |
The above Tier 1 Gateway is used for load balancing purpose.
Load balancing service requires presence of edge cluster.
As you can see, edge cluster is associated with this Tier 1 Gateway.
Also note that from route advertisement perspective, we are advertising LB VIP routes and LB SNAT IP Routes from this Tier 1 Gateway.
 |
| Communication between Virtual Server and the servers |
LB Virtual Server IP 172.16.40.6 is also used as SNAT IP address because the load balancer is in one arm mode. One arm mode of load balancer requires SNAT because the back end servers will then respond back to the SNAT IP.
Configuration of Load Balancer:
Here we are going to configure Layer 4 TCP based load balancing.
Server pool is defined as follows.
 |
| Server Pool Configuration |
 |
| Server Pool Members |
Please note that SNAT configuration has been applied while creating the server pool and the SNAT IP has been kept as the virtual server IP 172.16.40.6
Server pool members are configured.
 |
| Create load balancer |
Note that the load balancer size here is kept as small, this is just for lab purpose.
We need to keep in mind the configuration maximums for each load balancer size.
Load balancer size depends upon the size of the edge node deployed.
If the size of the edge node is large, then one large sized load balancer can be created.
1000 virtual servers can be created for Large sized load balancer.
Next, create a virtual server.
 |
| Create Virtual Server |
 |
| Associate Virtual Server with server pool |
 |
| Status of Virtual Server |
Troubleshooting using CLI:
 |
| High Availability Status on Edge Node |
Using the above commands, you can verify which edge node is 'Active'.
As seen, for the service router SR-T1-LB, edge node 'edgenode-01a' is Active.
You can get UUID of Load Balancer using the Advanced UI:
You can get UUID of Load Balancer using the Advanced UI:
 |
| UUID of Load Balancer |
Using
this UUID, you can execute below commands on the Active edge node to
display the server pool status and the status of virtual server.
 |
| Server Pool Members Information using CLI |
 |
| Virtual Server Status and information |
No comments:
Post a Comment