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.

Figure 1. Layer 4 TCP and UDP Application Profile
""

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 terminates the client TCP connection at the load balancer and waits for the clients HTTP or HTTPS request before selecting the server pool member.

Figure 2. Layer 7 HTTPS Application Profile
""

Procedure

  1. With admin privileges, log in to NSX Manager.
  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.

    To detect an inactive client or server communication, the load balancer uses the HTTP application profile response timeout feature set to 60 seconds. If the server does not send traffic during the 60 seconds interval, NSX ends the connection on the client and server side. Default application profiles cannot be edited. To edit HTTP application profile settings, create a custom profile.

    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 client idle connections remain before the load balancer closes them (FIN).
    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.
    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.

    Tags Enter tags to make searching easier.

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

    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 analytic 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.

    Response Timeout (sec) Enter the time in seconds on how long the load balancer waits for Server HTTP Response before it stops and closes the connection to the pool member and retries the request to another server.
    Server Keep-Alive Toggle the button for the load balancer to turn off TCP multiplexing and enable HTTP keep-alive.

    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.

    When HTTP keep-alive is enabled and forwarding rules are configured in the load balancer, the server keep-alive setting takes precedence. As a result, HTTP requests are sent to servers already connected with keep-alive.

    If you always want to give priority to the forwarding rules when the load balancer rule conditions are met, disable the keep-alive setting.

    Note that the persistence setting takes precedence over the keep-alive setting.

    Processing is done in the order of Persistence > Keep-Alive > Load Balancer Rules.