Common load balancing topologies
Sometimes you stumble across something so obvious that you cannot believe you missed it. I had such a moment today. I have been discussing load balancing topologies with one of my customers in the last few days and in each discussion we stayed exactly within the predefined color lines: a one-arm NSX edge and an inline NSX edge:
- An inline NSX ESG load balancer has an uplink interface and an internal interface and combines L3 routing and load balancing capabilities. The load balanced VMs use the ESG as their default gateway (so no distributed routing in this case!). Because load balancing is a stateful service, the ESG cannot be configured in ECMP mode. The load balancer Virtual IPs (VIPs) are configured on the uplink interface and traffic is load balanced to the VMs below. Simple as that.
- The one-arm NSX ESG load balancer has a single interface. The VIPs are configured on this interface and traffic is load balanced to the VMs. Even simpler!
Almost every one-arm load balancer scenario you will find in the NSX documentation looks pretty much like the diagram above. The ESG and the load balanced VMs are on the same Logical Switch and appear to be in the same IP space. I guess this created a form of tunnel vision because what I so obviously missed, is the fact that one-arm load balancers can perfectly live on a different Logical Switch from the load balanced VMs. Traffic can be routed from the ESG to the load balanced VMs through the Distributed Logical Router for example:
The VIPs can be in a totally different IP space from the load balanced VMs. This allows you – for example – to aggregate all load balancers on a single Logical Switch using public IPs for the VIPs and load balance traffic to backend VMs using a private IP space. Duh! That’s exactly the use case my customer was interested in. This even provides a well-defined security zone to consume in the Distributed Firewall of NSX.
PS. Thank you Marco van Baggum for pointing this out 😉