The NSX Edge load balancer distributes network traffic across multiple servers to achieve optimal resource use, provide redundancy, and distribute resource utilization.

NSX load balancer supports layer 4 and layer 7 load balancing engines. The layer 4 load balancer is packet-based, providing fast path processing and the layer 7 load balancer is socket-based, allowing for advanced traffic manipulations and DDOS mitigation for back-end services.

Packet-based load balancing is implemented on the TCP and UDP layer. Packet-based load balancing does not stop the connection or buffer the whole request, 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. You can select Acceleration Enable in both the global configuration and relevant virtual server configuration to enable packet-based load balancing.

Socket-based load balancing is implemented on top of the socket interface. Two connections are established for a single request, a client-facing connection and a server-facing connection. The server-facing connection is established after server selection. 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 on the server-facing connection. Socket-based load balancing is the default mode for TCP, HTTP, and HTTPS virtual servers.

Key concepts of the NSX load balancer include:

Virtual Server

Abstract of an application service, represented by a unique combination of IP, port, protocol and application profile such as TCP or UDP.

Server Pool

Group of backend servers.

Server Pool Member

Represents the backend server as member in a pool.

Service Monitor

Defines how to probe the health status of a backend server.

Application Profile

Represents the TCP, UDP, persistence, and certificate configuration for a given application.

You begin by setting global options for the load balancer, then create a server pool of backend server members, and associate a service monitor with the pool to manage and share the backend servers efficiently.

Next, you 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. Application profiles can be reused across virtual servers.

You then create an optional 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. Next, you create a service monitor that is specific to your application, or use a previously created service monitor.

Optionally, you can create an application rule to support advanced functionality of L7 virtual servers. Some use cases for application rules include content switching, header manipulation, security rules, and DOS protection.

Finally, you create a virtual server that connects your server pool, application profile, and any potential application rules together.

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. The calculation methods can be round-robin, weighted round-robin, least connection, source IP hash, weighted least connections, URL, URI, or HTTP header.

Each pool is monitored by the associated service monitor. When the load balancer detects a problem with a pool member, it is marked as DOWN. Only UP server is selected when choosing a pool member from the server pool. If the server pool is not configured with a service monitor, all the pool members are considered as UP.

Note:

For load balancer troubleshooting information, refer to NSX Troubleshooting Guide.