The load balancer distributes incoming service requests among multiple servers in such a way that the load distribution is transparent to users. Load balancing helps achieve optimal resource use, maximizing throughput, minimizing response time, and avoiding overload.

The NSX load balancer supports two load balancing engines. The layer 4 load balancer is packet-based and provides fast-path processing. The layer 7 load balancer is socket-based and supports advanced traffic management strategies and DDOS mitigation for back end services.

Load balancing for an NSX Data Center for vSphere edge gateway is configured on the external interface because the edge gateway load balances incoming traffic from the external network. When configuring virtual servers for load balancing, specify one of the available IP addresses you have in your organization VDC.

Load Balancing Strategies and Concepts

A packet-based load balancing strategy is implemented on the TCP and UDP layer. Packet-based load balancing does not stop the connection or buffer the whole request. Instead, after manipulating the packet, it sends it directly to the selected server. 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.

A socket-based load balancing strategy 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 the 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 is the default mode for TCP, HTTP, and HTTPS virtual servers.

The key concepts of the NSX load balancer are, virtual server, server pool, server pool member, and service monitor.

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 back end servers.
Server Pool Member
Represents the back end server as member in a pool.
Service Monitor
Defines how to probe the health status of a back end server.
Application Profile
Represents the TCP, UDP, persistence, and certificate configuration for a given application.

Setup Overview

You begin by setting global options for the load balancer. You now create a server pool consisting of back end server members and associate a service monitor with the pool to manage and share the back end servers efficiently.

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. The application profile 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 you can use an existing service monitor if it meets your needs.

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.

Configure Load Balancing On NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal

Global load balancer configuration parameters include overall enablement, selection of the layer 4 or layer 7 engine, and specification of the types of events to log.

Procedure

  1. Open Edge Gateway Services.
    1. From the primary left navigation panel, select Networking and from the page top navigation bar, select Edge Gateways.
    2. Select the edge gateway that you want to edit, and click Services.
  2. Navigate to Load Balancer > Global Configuration.
  3. Select the options you want to enable:
    Option Action
    Status Enable the load balancer by clicking the toggle icon.

    Enable Acceleration Enabled to configure the load balancer to use the faster L4 engine rather than L7 engine. The L4 TCP VIP is processed before the edge gateway firewall so no Allow firewall rule is required.

    Note:

    L7 VIPs for HTTP and HTTPS are processed after the firewall, so when you do not enable acceleration, an edge gateway firewall rule must exist to allow access to the L7 VIP for those protocols. When you enable acceleration, and the server pool is in a non-transparent mode, a SNAT rule is added, so you must ensure that the firewall is enabled on the edge gateway.

    Enable Logging Enable logging so that the edge gateway load balancer collects traffic logs.
    Log Level Choose the severity of events to be collected in the logs.
  4. Click Save changes.

What to do next

Configure application profiles for the load balancer. See Create an Application Profile On An NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal.

Create an Application Profile On An NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal

An application profile defines the behavior of the load balancer for a particular type of network traffic. After configuring a profile, you associate it with a virtual server. The virtual server then processes traffic according to the values specified in the profile. Using profiles enhances your control over managing network traffic, and makes traffic-management tasks easier and more efficient.

When you create a profile for HTTPS traffic, the following HTTPS traffic patterns are allowed:
  • Client -> HTTPS -> LB (terminate SSL) -> HTTP -> servers
  • Client -> HTTPS -> LB (terminate SSL) -> HTTPS -> servers
  • Client -> HTTPS-> LB (SSL passthrough) -> HTTPS -> servers
  • Client -> HTTP-> LB -> HTTP -> servers

Procedure

  1. Open Edge Gateway Services.
    1. From the primary left navigation panel, select Networking and from the page top navigation bar, select Edge Gateways.
    2. Select the edge gateway that you want to edit, and click Services.
  2. Navigate to Load Balancer > Application Profiles.
  3. Click the Create (Create button) button.
  4. Enter a name for the profile.
  5. Configure the application profile.
    Option Description
    Type Select the protocol type used to send requests to the server. The list of required parameters depends on the protocol you select. Parameters that are not applicable to the protocol you selected cannot be entered. All other parameters are required.
    Enable SSL Passthrough Click to enable SSL authentication to be passed through to the virtual server.

    Otherwise SSL authentication takes place at the destination address.

    HTTP Redirect URL (HTTP and HTTPS) Enter the URL to which traffic that arrives at the destination address should be redirected.
    Persistence Specify a persistence mechanism for the profile.

    Persistence tracks and stores session data, such as the specific pool member that serviced a client request. This ensures that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions. The options are:

    • Source IP

      Source IP persistence tracks sessions based on the source IP address. When a client requests a connection to a virtual server that supports source address affinity persistence, the load balancer checks to see if that client previously connected, and if so, returns the client to the same pool member.

    • MSRDP

      (TCP Only) Microsoft Remote Desktop Protocol persistence (MSRDP) maintains persistent sessions between Windows clients and servers that are running the Microsoft Remote Desktop Protocol (RDP) service. The recommended scenario for enabling MSRDP persistence is to create a load balancing pool that consists of members running a Windows Server guest OS, where all members belong to a Windows cluster and participate in a Windows session directory.

    • SSL Session ID

      SSL Session ID persistence is available when you enable SSL passthrough. SSL Session ID persistence ensures that repeat connections from the same client are sent to the same server. Session ID persistence allows the use of SSL session resumption, which saves processing time for both the client and the server.
    Cookie Name (HTTP and HTTPS) If you specified Cookie as the persistence mechanism, enter the cookie name. Cookie persistence uses a cookie to uniquely identify the session the first time a client accesses the site. The load balancer refers to this cookie when connecting subsequent requests in the session, so that they all go to the same virtual server.
    Mode Select the mode by which the cookie should be inserted. The following modes are supported:
    • Insert

      The edge gateway sends a cookie. When the server sends one or more cookies, the client will receive one extra cookie (the server cookies plus the edge gateway cookie). When the server does not send any cookies, the client will receive the edge gateway cookie only.

    • Prefix
      Select this option when your client does not support more than one cookie.
      Note: All browsers accept multiple cookies. But you might have a proprietary application using a proprietary client that supports only one cookie. The Web server sends its cookie as usual. The edge gateway injects (as a prefix) its cookie information in the server cookie value. This cookie added information is removed when the edge gateway sends it to the server.
    • App Session For this option, the server does not send a cookie. Instead, it sends the user session information as a URL. For example, http://example.com/admin/UpdateUserServlet;jsessionid=OI24B9ASD7BSSD, where jsessionid is the user session information and is used for the persistence. It is not possible to see the App Session persistence table for troubleshooting.
    Expires in (Seconds) Enter a length of time in seconds that persistence stays in effect. Must be a positive integer in the range 1–86400.
    Note: For L7 load balancing using TCP source IP persistence, the persistence entry times out if no new TCP connections are made for a period of time, even if the existing connections are still alive.
    Insert X-Forwarded-For HTTP header (HTTP and HTTPS) Select Insert X-Forwarded-For HTTP header for identifying the originating IP address of a client connecting to a Web server through the load balancer.
    Note: Using this header is not supported if you enabled SSL passthrough.
    Enable Pool Side SSL (HTTPS Only) Select Enable Pool Side SSL to define the certificate, CAs, or CRLs used to authenticate the load balancer from the server side in the Pool Certificates tab.
  6. (HTTPS only) Configure the certificates to be used with the application profile. If the certificates you need do not exist, you can create them from the Certificates tab.
    Option Description
    Virtual Server Certificates Select the certificate, CAs, or CRLs used to decrypt HTTPS traffic.
    Pool Certificates Define the certificate, CAs, or CRLs used to authenticate the load balancer from the server side.
    Note: Select Enable Pool Side SSL to enable this tab.
    Cipher Select the cipher algorithms (or cipher suite) negotiated during the SSL/TLS handshake.
    Client Authentication Specify whether client authentication is to be ignored or required.
    Note: When set to Required, the client must provide a certificate after the request or the handshake is canceled.
  7. To preserve your changes, click Keep.

What to do next

Add service monitors for the load balancer to define health checks for different types of network traffic. See Create a Service Monitor On An NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal.

Create a Service Monitor On An NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal

You create a service monitor to define health check parameters for a particular type of network traffic. When you associate a service monitor with a pool, the pool members are monitored according to the service monitor parameters.

Procedure

  1. Open Edge Gateway Services.
    1. From the primary left navigation panel, select Networking and from the page top navigation bar, select Edge Gateways.
    2. Select the edge gateway that you want to edit, and click Services.
  2. Navigate to Load Balancer > Service Monitoring.
  3. Click the Create (Create button) button.
  4. Enter a name for the service monitor.
  5. (Optional) Configure the following options for the service monitor:
    Option Description
    Interval Enter the interval at which a server is to be monitored using the specified Method.
    Timeout Enter the maximum time in seconds within which a response from the server must be received.
    Max Retries Enter the number of times the specified monitoring Method must fail sequentially before the server is declared down.
    Type Select the way in which you want to send the health check request to the server—HTTP, HTTPS, TCP, ICMP, or UDP.

    Depending on the type selected, the remaining options in the New Service Monitor dialog are activated or deactivated.

    Expected (HTTP and HTTPS) Enter the string that the monitor expects to match in the status line of the HTTP or HTTPS response (for example, HTTP/1.1).
    Method (HTTP and HTTPS) Select the method to be used to detect server status.
    URL (HTTP and HTTPS) Enter the URL to be used in the server status request.
    Note: When you select the POST method, you must specify a value for Send.
    Send (HTTP, HTTPS, UDP) Enter the data to be sent.
    Receive (HTTP, HTTPS, and UDP) Enter the string to be matched in the response content.
    Note: When Expected is not matched, the monitor does not try to match the Receive content.
    Extension (ALL) Enter advanced monitor parameters as key=value pairs. For example, warning=10 indicates that when a server does not respond within 10 seconds, its status is set as warning. All extension items should be separated with a carriage return character. For example: 
    <extension>delay=2
critical=3
escape</extension>
  6. To preserve your changes, click Keep.

Example: Extensions Supported for Each Protocol

Table 1. Extensions for HTTP/HTTPS Protocols
Monitor Extension Description
no-body Does not wait for a document body and stops reading after the HTTP/HTTPS header.
Note: An HTTP GET or HTTP POST is still sent; not a HEAD method.
max-age=SECONDS Warns when a document is more than SECONDS old. The number can be in the form 10m for minutes, 10h for hours, or 10d for days.
content-type=STRING Specifies a Content-Type header media type in POST calls.
linespan Allows regex to span newlines (must precede -r or -R).
regex=STRING or ereg=STRING Searches the page for regex STRING.
eregi=STRING Searches the page for case-insensitive regex STRING.
invert-regex Returns CRITICAL when found and OK when not found.
proxy-authorization=AUTH_PAIR Specifies the username:password on proxy servers with basic authentication.
useragent=STRING Sends the string in the HTTP header as User Agent.
header=STRING Sends any other tags in the HTTP header. Use multiple times for additional headers.
onredirect=ok|warning|critical|follow|sticky|stickyport Indicates how to handle redirected pages.

sticky is like follow but stick to the specified IP address. stickyport ensures the port stays the same.

pagesize=INTEGER:INTEGER Specifies the minimum and maximum page sizes required in bytes.
warning=DOUBLE Specifies the response time in seconds to result in a warning status.
critical=DOUBLE Specifies the response time in seconds to result in a critical status.
Table 2. Extensions for HTTPS Protocol Only
Monitor Extension Description
sni Enables SSL/TLS hostname extension support (SNI).
certificate=INTEGER Specifies the minimum number of days a certificate has to be valid. The port defaults to 443. When this option is used, the URL is not checked.
authorization=AUTH_PAIR Specifies the username:password on sites with basic authentication.
Table 3. Extensions for TCP Protocol
Monitor Extension Description
escape Allows for the use of \n, \r, \t, or \ in a send or quit string. Must come before a send or quit option. By default, nothing is added to send and \r\n is added to the end of quit.
all Specifies all expect strings need to occur in a server response. By default, any is used.
quit=STRING Sends a string to the server to cleanly close the connection.
refuse=ok|warn|crit Accepts TCP refusals with states ok, warn, or criti. By default, uses state crit.
mismatch=ok|warn|crit Accepts expected string mismatches with states ok, warn, or crit. By default, uses state warn.
jail Hides output from the TCP socket.
maxbytes=INTEGER Closes the connection when more than the specified number of bytes are received.
delay=INTEGER Waits the specified number of seconds between sending the string and polling for a response.
certificate=INTEGER[,INTEGER] Specifies the minimum number of days a certificate has to be valid. The first value is #days for warning and the second value is critical (if not specified - 0).
ssl Uses SSL for the connection.
warning=DOUBLE Specifies the response time in seconds to result in a warning status.
critical=DOUBLE Specifies the response time in seconds to result in a critical status.

What to do next

Add server pools for your load balancer. See Add a Server Pool for Load Balancing On an NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal.

Add a Server Pool for Load Balancing On an NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal

You can add a server pool to manage and share backend servers flexibly and efficiently. A pool manages load balancer distribution methods and has a service monitor attached to it for health check parameters.

Procedure

  1. Open Edge Gateway Services.
    1. From the primary left navigation panel, select Networking and from the page top navigation bar, select Edge Gateways.
    2. Select the edge gateway that you want to edit, and click Services.
  2. Navigate to Load Balancer > Pools.
  3. Click the Create (Create button) button.
  4. Type a name and, optionally, a description for the load balancer pool.
  5. Select a balancing method for the service from the Algorithm drop-down menu:
    Option Description
    ROUND-ROBIN Each server is used in turn according to the weight assigned to it. This is the smoothest and fairest algorithm when the server processing time remains equally distributed.
    IP-HASH Selects a server based on a hash of the source and destination IP address of each packet.
    LEASTCONN Distributes client requests to multiple servers based on the number of connections already open on the server. New connections are sent to the server with the fewest open connections.
    URI The left part of the URI (before the question mark) is hashed and divided by the total weight of the running servers. The result designates which server will receive the request. This option ensures that a URI is always directed to the same server as long as the server does not go down.
    HTTPHEADER

    HTTP header name is looked up in each HTTP request. The header name in parenthesis is not case sensitive which is similar to the ACL 'hdr()' function. If the header is absent or does not contain any value, the round robin algorithm is applied. The HTTP HEADER algorithm parameter has one option headerName=<name>. For example, you can use host as the HTTP HEADER algorithm parameter.

    URL

    URL parameter specified in the argument is looked up in the query string of each HTTP GET request. If the parameter is followed by an equal sign = and a value, then the value is hashed and divided by the total weight of the running servers. The result designates which server receives the request. This process is used to track user identifiers in requests and ensure that a same user ID is always sent to the same server as long as no server goes up or down. If no value or parameter is found, then a round robin algorithm is applied. The URL algorithm parameter has one option urlParam=<url>.

  6. Add members to the pool.
    1. Click the Add (Create button) button.
    2. Enter the name for the pool member.
    3. Enter the IP address of the pool member.
    4. Enter the port at which the member is to receive traffic from the load balancer.
    5. Enter the monitor port at which the member is to receive health monitor requests.
    6. In the Weight text box, type the proportion of traffic this member is to handle. Must be an integer in the range 1-256.
    7. (Optional) In the Max Connections text box, type the maximum number of concurrent connections the member can handle.
      When the number of incoming requests exceeds the maximum, requests are queued and the load balancer waits for a connection to be released.
    8. (Optional) In the Min Connections text box, type the minimum number of concurrent connections a member must always accept.
    9. Click Keep to add the new member to the pool.
      The operation can take a minute to complete.
  7. (Optional) To make client IP addresses visible to the back end servers, select Transparent.
    When Transparent is not selected (the default value), back end servers see the IP address of the traffic source as the internal IP address of the load balancer.

    When Transparent is selected, the source IP address is the actual IP address of the client and the edge gateway must be set as the default gateway to ensure that return packets go through the edge gateway.

  8. To preserve your changes, click Keep.

What to do next

Add virtual servers for your load balancer. A virtual server has a public IP address and services all incoming client requests. See Add a Virtual Server On an NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal.

Add an Application Rule On an NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal

You can write an application rule to directly manipulate and manage IP application traffic.

Procedure

  1. Open Edge Gateway Services.
    1. From the primary left navigation panel, select Networking and from the page top navigation bar, select Edge Gateways.
    2. Select the edge gateway that you want to edit, and click Services.
  2. Navigate to Load Balancer > Application Rules.
  3. Click the Add (Create button) button.
  4. Enter the name for the application rule.
  5. Enter the script for the application rule.
    For information on the application rule syntax, see http://cbonte.github.io/haproxy-dconv/2.2/configuration.html.
  6. To preserve your changes, click Keep.

What to do next

Associate the new application rule to a virtual server added for the load balancer. See Add a Virtual Server On an NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal.

Add a Virtual Server On an NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal

Add an NSX Data Center for vSphere edge gateway internal or uplink interface as a virtual server in VMware Cloud Director. A virtual server has a public IP address and services all incoming client requests.

By default, the load balancer closes the server TCP connection after each client request.

Procedure

  1. Open Edge Gateway Services.
    1. From the primary left navigation panel, select Networking and from the page top navigation bar, select Edge Gateways.
    2. Select the edge gateway that you want to edit, and click Services.
  2. Navigate to Load Balancer > Virtual Servers.
  3. Click the Add (Create button) button.
  4. On the General tab, configure the following options for the virtual server:
    Option Description
    Enable Virtual Server Click to enable the virtual server.
    Enable Acceleration Click to enable acceleration.
    Application Profile Select an application profile to be associated with the virtual server.
    Name Type a name for the virtual server.
    Description Type an optional description for the virtual server.
    IP Address Type or browse to select the IP address that the load balancer listens on.
    Protocol Select the protocol that the virtual server accepts. You must select the same protocol used by the selected Application Profile.
    Port Type the port number that the load balancer listens on.
    Default Pool Choose the server pool that the load balancer will use.
    Connection Limit (Optional) Type the maximum concurrent connections that the virtual server can process.
    Connection Rate Limit (CPS) (Optional) Type the maximum incoming new connection requests per second.
  5. (Optional) To associate application rules with the virtual server, click the Advanced tab and complete the following steps:
    1. Click the Add (Create button) button.
      The application rules created for the load balancer appear. If necessary, add application rules for the load balancer. See Add an Application Rule On an NSX Data Center for vSphere Edge Gateway Using the VMware Cloud Director Tenant Portal.
  6. To preserve your changes, click Keep.

What to do next

Create an edge gateway firewall rule to permit traffic to the new virtual server (the destination IP address). See Add an NSX Data Center for vSphere Edge Gateway Firewall Rule in the VMware Cloud Director Tenant Portal