NSX Load Balancer: Under the Hood

Although NSX Load Balancer is not usually the feature that makes customers buy NSX, it’s quite commonly used.

Included from the Advanced version, NSX-V Load Balancer offers L4 (TCP/UDP) and L7 (HTTP/HTTPS) load balancing, multiple SSL options (SSL Offload, SSL Passthrough or SSL End-to-End), in-line (transparent mode) or one-arm (proxy mode) load balancing, and many other features. The load balancing features and functionalities natively supported in NSX-V cover most of the type requirements found in real life deployments.

NSX-V Load Balancer: Under the Hood

NSX-V Load Balancer is composed of 2 engines: a layer 4 load balancer engine (packet-based) and a layer 7 load balancer engine (socket-based). While a packet-based load balancing is implemented on the TCP and UDP layer, a socket-based load balancing is implemented on top of the socket interface.

• Packet-based load balancing: does not stop the connection or buffer the whole request; instead it sends the packet directly to the selected server after manipulating the packet. TCP and UDP sessions are maintained in the load balancer so that packets for a single session are directed to the same server.

• Socket-based load balancing: 2 connections are established for a single request, a client-facing connection and a server-facing connection. For HTTP socket-based implementation, the whole request is received before sending to the selected server with optional L7 manipulation. For HTTPS socket-based implementation, authentication information is exchanged either on the client-facing connection or server-facing connection.

Socket-based load balancing (layer 7 engine) is the default mode for TCP, HTTP, and HTTPS virtual servers. In NSX-V configuration, you can select Acceleration Enable in both the global configuration and relevant virtual server configuration to enable packet-based load balancing (layer 4 engine).

Although the configuration required for a load balancer is quite straightforward, you have to go through 6 different screens** (although only 4 of them are required).

**: potentially 7 if you are doing HTTPS and need to import a SSL certificate.

When people are going through the configuration for the 1st time, they can ask themselves how does everything fit together? How do application profiles and virtual servers interact for example?

Based on this thought, I built the schema below to help to understand how the various components of the NSX Logical Load Balancer are working and interact together.

NSX-V Load Balancer Components

The key NSX-V Load Balancer configuration components are the following:

• Global Configuration: global load balancer configuration parameters such as acceleration (layer 4 engine), logging, service insertion.
• Application Profile: define the behavior of a particular type of network traffic (persistence, SSL configuration, and so on).
• Service Monitor: define health check parameters for a particular type of network traffic.
• Pool: manages load balancer distribution methods amongst backend servers and has a service monitor attached to it for health check parameters.
• Application Rule: allow to manipulate and manage application traffic.
• Virtual Server: abstract of an application service, represented by a unique combination of IP, port, and protocol such as TCP or UDP.

Although the schema above should be quite self-explanatory (I hope), let’s go through a typical configuration.

Once you have a NSX Edge Services Gateway (ESG) deployed, the first step is to define the IP that will be used as a Virtual IP (a.k.a. VIP). You can either add an interface (uplink or internal) or define a secondary IP on an existing interface.

The next step is optional: if you want to load balance HTTPS traffic (for SSL Offload and SSL End-to-End), you have to import your SSL certificate in the general configuration of the ESG.

You then enable load balancing and set global parameters.

You then create an application profile to define the common application behavior in a load balancer such as client SSL, server SSL, X-Forwarded-For, or persistence. Persistence sends subsequent requests with similar characteristic such as, source IP or cookie are required to be dispatched to the same pool member, without running the load balancing algorithm. An application profile can be reused across virtual servers.

(optional) You can define a new service monitor if the default service monitors don’t meet your requirements.

The next step is to create a server pool consisting of backend server members and associate a service monitor with the pool to manage and share the backend servers efficiently.

(optional) You can create an application rule to configure application-specific settings for traffic manipulation such as, matching a certain URL or hostname so that different requests can be handled by different pools. The technology behind the layer 7 engine is based on HAProxy and as such you can leverage some of the HAProxy ACLs (Access Control Lists) capabilities (you can’t do backend rules for example).

Finally, the virtual server is a unique combination of an application profile, an IP address, a port and a protocol, a default pool and potentially one or multiple application rules.

When the virtual server receives a request, the load balancing algorithm considers pool member configuration and runtime status. The algorithm then calculates the appropriate pool to distribute the traffic comprising one or more members. The pool member configuration includes settings such as, weight, maximum connection, and condition status. The runtime status includes current connections, response time, and health check status information.