Use application profiles to enhance your control over managing network traffic, and make traffic-management tasks easier and more efficient.
About this task
You create an application profile to define the behavior of a particular type of network traffic. After configuring a profile, you associate the profile with a virtual server. The virtual server then processes traffic according to the values specified in the profile.
- Log in to the vSphere Web Client.
- Click Networking & Security and then click NSX Edges.
- Double-click an NSX Edge.
- Click Manage and then click the Load Balancer tab.
- In the left navigation panel, click Application Profiles.
- Click the Add () icon.
- Type a name for the profile and select the traffic type for which you are creating the profile from the drop-down menu.
Persistence Method Supported
Source IP, MSRDP
Cookie, Source IP
Cookie, SSL Session ID (SSL Passthrough enabled) , Source IP
- Enter the URL to which you want to redirect HTTP traffic.
For example, you can direct traffic from http://myweb.com to https://myweb.com.
- Specify persistence type for the profile from the drop-down menu.
Persistence tracks and stores session data, such as the specific pool member that serviced a client request. With persistence, client requests are directed to the same pool member throughout the life of a session or during subsequent sessions.
Select Cookie persistence to insert a unique cookie to identify the session the first time a client accesses the site.
The cookie is referred in subsequent requests to persist the connection to the appropriate server.
Select Source IP persistence to track 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.
Select Microsoft Remote Desktop Protocol MSRDP persistence to maintain 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 Windows Server 2003 or Windows Server 2008, where all members belong to a Windows cluster and participate in a Windows session directory.
- Enter a cookie name and select the mode by which the cookie should be inserted.
NSX Edge sends a cookie.
If the server sends one or more cookies, the client receives an extra cookie (the server cookie(s) + the Edge cookie). If the server does not send a cookie, the client receives the Edge cookie.
This option is selected if your client does not support more than one cookie.Note:
All browsers accept multiple cookies. If you have a proprietary application using a proprietary client that supports only one cookie. The Web server sends its cookie as usual. NSX Edge injects (as a prefix) its cookie information in the server cookie value. This cookie added information is removed when NSX Edge sends it to the server.
The server does not send a cookie. Instead, it sends the user session information as a URL.
For example, http://mysite.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.
- Enter the persistence expiration time in seconds. The default value of persistence is 300 seconds (five minutes). Note that the persistence table is of limited size. A large timeout value may lead to the persistence table quickly filling up if the traffic is heavy. When the persistence table fills up, the oldest entry is deleted to accept the newest entry.
The load balancer persistence table maintains entries to record that client requests are directed to the same pool member.
If no new connection requests are received from the same client within the timeout period, the persistence entry expires and is deleted.
If a new connection request from same client is received within the timeout period, the timer is reset, and the client request is sent to a sticky pool member.
After the timeout period has expired, new connection requests will be sent to a pool member allocated by the load balancing algorithm.
For the L7 load balancing TCP source IP persistence scenario, 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.
- (Optional) Create an application profile for HTTPS traffic.
Supported HTTPS traffic patterns:
SSL Offloading - Client -> HTTPS -> LB (terminate SSL) -> HTTP -> server
SSL Proxy - Client -> HTTPS -> LB (terminate SSL) -> HTTPS -> server
SSL Passthrough - Client -> HTTPS-> LB (SSL passthrough) -> HTTPS -> server
Client -> HTTP-> LB -> HTTP -> servers
- (Optional) Check Insert X-Forwarded-For HTTP header to identify the originating IP address of a client connecting to a Web server through the load balancer.
- Check Configure Service Certificate to select the applicable service certificate, CA certificates, and CRLs used to terminate the HTTPS traffic from the client on the load balancer in the Virtual Server Certificates tab.
This is only required if the Client -> LB connection is HTTPS.
- (Optional) Check Enable Pool Side SSL to enable the HTTPS communication between the load balancer and the backend servers.
You can use the pool side SSL to configure End-to-End SSL.
- (Optional) Check Configure Service Certificate to select the applicable service certificate, CA certificates, and CRLs used to authenticate the load balancer from the server side in the Pool Certificates tab.
This is only required for the pattern Client -> HTTPS -> LB -> HTTPS -> servers.
You can configure service certificate if the NSX Edge load balancer has CA certificate and CRL already configured and needs to verify service certificate from backend servers. This option can also be used to provide load balancer certificate to backend server if the backend server needs to verify the load balancer side service certificate.
- Enter the cipher algorithms or cipher suite negotiated during the SSL/TLS handshake. Multiple ciphers can be added, separated with a colon (:). Make sure that the approved cipher suite contains DH key length more than or equal to 1024 bits.
You can use approved ciphers suite as below:
- Specify whether client authentication is to be ignored or required from the drop-down menu.
If you select required, the client must provide a certificate after the request or the handshake is aborted.
- Click OK.