Application profiles are associated with virtual servers to enhance load balancing network traffic and simplify traffic-management tasks.

Application profiles define the behavior of a particular type of network traffic. The associated virtual server processes network traffic according to the values specified in the application profile. Fast TCP, Fast UDP, and HTTP application profiles are the supported types of profiles.

TCP application profile is used by default when no application profile is associated to a virtual server. TCP and UDP application profiles are used when an application is running on a TCP or UDP protocol and does not require any application level load balancing such as, HTTP URL load balancing. These profiles are also used when you only want Layer 4 load balancing, which has a faster performance and supports connection mirroring.

HTTP application profile is used for both HTTP and HTTPS applications when the load balancer must take actions based on Layer 7 such as, load balancing all images requests to a specific server pool member or stopping HTTPS to offload SSL from pool members. Unlike the TCP application profile, the HTTP application profile stops the client TCP connection before selecting the server pool member.

Figure 1. Layer 4 TCP and UDP Application Profile
Figure 2. Layer 7 HTTPS Application Profile

Procedure

  1. From your browser, log in with admin privileges to an NSX Manager at https://<nsx-manager-ip-address>.
  2. Select Networking > Load Balancing > Profiles > Application > Add Application Profiles.
  3. Select a Fast TCP application profile and enter the profile details.
    You can also accept the default FAST TCP profile settings.
    Option Description
    Name and Description Enter a name and a description for the Fast TCP application profile.
    Idle Timeout Enter the time in seconds on how long the server can remain idle after a TCP connection is established.

    Set the idle time to the actual application idle time and add a few more seconds so that the load balancer does not close its connections before the application does.

    HA Flow Mirroring Toggle the button to make all the flows to the associated virtual server mirrored to the HA standby node.
    Connection Close Timeout Enter the time in seconds that the TCP connection both FINs or RST must be kept for an application before closing the connection.

    A short closing timeout might be required to support fast connection rates.

    Tags Enter tags to make searching easier.

    You can specify a tag to set a scope of the tag.

  4. Select a Fast UDP application profile and enter the profile details.
    You can also accept the default UDP profile settings.
    Option Description
    Name and Description Enter a name and a description for the Fast UDP application profile.
    Idle Timeout Enter the time in seconds on how long the server can remain idle after a UDP connection is established.

    UDP is a connectionless protocol. For load balancing purposes, all the UDP packets with the same flow signature such as, source and destination IP address or ports and IP protocol received within the idle timeout period are considered to belong to the same connection and sent to the same server.

    If no packets are received during the idle timeout period, the connection which is an association between the flow signature and the selected server is closed.

    HA Flow Mirroring Toggle the button to make all the flows to the associated virtual server mirrored to the HA standby node.
    Tags Enter tags to make searching easier.

    You can specify a tag to set a scope of the tag.

  5. Select a HTTP application profile and enter the profile details.
    You can also accept the default HTTP profile settings.

    HTTP application profile is used for both HTTP and HTTPS applications.

    Option Description
    Name and Description Enter a name and a description for the HTTP application profile.
    Idle Timeout Enter the time in seconds on how long an HTTP application can remain idle, instead of the TCP socket setting which must be configured in the TCP application profile.
    Request Header Size Specify the maximum buffer size in bytes used to store HTTP request headers.
    Response Header Size

    Specify the maximum buffer size in bytes used to store HTTP response headers. The default is 4096, and the maximum is 65536.
    X-Forwarded-For (XFF)
    • Insert - If the XFF HTTP header is not present in the incoming request, the load balancer inserts a new XFF header with the client IP address. If the XFF HTTP header is present in the incoming request, the load balancer appends the XFF header with the client IP address.
    • Replace - If the XFF HTTP header is present in the incoming request, the load balancer replaces the header.

    Web servers log each request they handle with the requesting client IP address. These logs are used for debugging and analytics purposes. If the deployment topology requires SNAT on the load balancer, then server uses the client SNAT IP address which defeats the purpose of logging.

    As a workaround, the load balancer can be configured to insert XFF HTTP header with the original client IP address. Servers can be configured to log the IP address in the XFF header instead of the source IP address of the connection.

    Request Body Size Enter value for the maximum size of the buffer used to store the HTTP request body.

    If the size is not specified, then the request body size is unlimited.

    Redirection
    • None - If a website is temporarily down, user receives a page not found error message.
    • HTTP Redirect - If a website is temporarily down or has moved, incoming requests for that virtual server can be temporarily redirected to a URL specified here. Only a static redirection is supported.

      For example, if HTTP Redirect is set to http://sitedown.abc.com/sorry.html, then irrespective of the actual request, for example, http://original_app.site.com/home.html or http://original_app.site.com/somepage.html, incoming requests are redirected to the specified URL when the original website is down.

    • HTTP to HTTPS Redirect - Certain secure applications might want to force communication over SSL, but instead of rejecting non-SSL connections, they can redirect the client request to use SSL. With HTTP to HTTPS Redirect, you can preserve both the host and URI paths and redirect the client request to use SSL.

      For HTTP to HTTPS redirect, the HTTPS virtual server must have port 443 and the same virtual server IP address must be configured on the same load balancer.

      For example, a client request for http://app.com/path/page.html is redirected to https://app.com/path/page.html. If either the host name or the URI must be modified while redirecting, for example, redirect to https://secure.app.com/path/page.html, then load balancing rules must be used.

    NTLM Authentication Toggle the button for the load balancer to turn off TCP multiplexing and enable HTTP keep-alive.

    NTLM is an authentication protocol that can be used over HTTP. For load balancing with NTLM authentication, TCP multiplexing must be disabled for the server pools hosting NTLM-based applications. Otherwise, a server-side connection established with one client's credentials can potentially be used for serving another client's requests.

    If NTLM is enabled in the profile and associated to a virtual server, and TCP multiplexing is enabled at the server pool, then NTLM takes precedence. TCP multiplexing is not performed for that virtual server. However, if the same pool is associated to another non-NTLM virtual server, then TCP multiplexing is available for connections to that virtual server.

    If the client uses HTTP/1.0, the load balancer upgrades to HTTP/1.1 protocol and the HTTP keep-alive is set. All HTTP requests received on the same client-side TCP connection are sent to the same server over a single TCP connection to ensure that reauthorization is not required.

    Tags Enter tags to make searching easier.

    You can specify a tag to set a scope of the tag.