Kemp Support, how can we help?

The latest application delivery knowledge and expertise at your fingertips.

Persistence best practices when using Port Following

 

Information

 

Summary:

What are the best practice settings for persistence when Port Following is used

Environment:

Product: LoadMaster

Version: Any

Platform: Any

Application: Any

Question/Problem Description:

Recommended persistence settings to prevent connections from going into different servers on different Virtual Services when using Port Following

Steps to Reproduce:  
Error Message:  
Defect Number:  
Enhancement Number:  
Cause:  
Resolution:

Port following is set when two services need to share persistence records. Typically this is done for applications that require different services to work with another.

Port following has several requirements:

  • The Virtual Services must have the same set of Real Servers
  • The Virtual Service must be using the same persistence options (this does not apply for the persistence timeout)

Applications such as VMWare Horizon View, Microsoft Always-On-VPN and many others need port following between virtual services when multiple servers are used. Usually, there is a primary protocol which handles the initial connection (HTTPS and SSTP in most cases) and a secondary protocol which completes the connection such as Blast, PCoIP, IKEv2, ect.

Below are a few recommendations for persistence when using port following:

  • As best practice, the secondary Virtual Service should always be getting the persistence records from he primary Virtual Service. That is, Port Following must be configured on the secondary Virtual Service to follow the primary Virtual Service.

This can be configured by navigating to the secondary Virtual Service(s) > Modify > Advanced Properties > Port Following > Select the primary Virtual Service from the dropdown.

port follow 1.png

  • Another recommendation is to always configure the secondary Virtual Service's persistence timeout to have a considerably lower value compared to the primary Virtual Service. The goal with this is to have the persistence records in the secondary Virtual Service expire before the primary ones do. This will result in the persistence table of the primary Virtual Service to always be used hence connecting the same clients to the same back-end servers.
  • When it comes to the persistence timeout on the primary Virtual Service, it is important to set a timeout which equals or exceeds the value for any session timeout configuired on the server side.

The ideal connection flow is as follows:

  1. Client establishes the first connection against the primary Virtual Service.
  2. This connection gets sent to a back-end server out of the server pool.
  3. A persistence record is created to always send requests from this connection to same back-end server as long as the persistence timeout has not expired.
  4. Client establishes a second connection to the secondary Virtual Service.
  5. A persistence record is not created by the secondary Virtual Service for this connection, instead this Virtual Service will retrieve the record from the primary Virtual Service.
  6. Client is connected to the back-end server.

With the use of L7 Traces (WUI > System Configuration > Logging Options > System Log Files > Debug Options > Enable L7 Debug Traces) in the LoadMaster, the same connection flow can be observed:

l7 traces.png

NOTE: L7 Traces are meant to be used for troubleshooting purposes and should not be enable for long periods of time.

 

1. Client establishes the first connection against the primary Virtual Service.

kernel: L7: ffff888228a40a80: SSL accept on 10.67.48.161:443 from 10.248.5.147:63645 (0)

2. This connection gets sent to a back-end server out of the server pool.

kernel: L7: ffff888228a40a80: Connecting from 10.67.48.133:53301 to 10.67.48.139:80
kernel: L7: ffff888228a40a80: Connected

3. A persistence record is created to always send requests from this connection to same back-end server as long as the persistence timeout has not expired.

kernel: L7: ffff888228a40a80: updating persist 0 1
kernel: L7: ffff888228a40a80: find persist returns ffff88822ae6d5b0

4. Client establishes a second connection to the secondary Virtual Service.

kernel: L7: ffff88822c7a8000: SSL accept on 10.67.48.161:8443 from 10.248.5.147:63661 (0)

5. A persistence record is not created by the secondary Virtual Service for this connection, instead this Virtual Service will retrieve the record from the primary Virtual Service.

kernel: L7: ffff88822c7a8000: find persist returns (null) 
kernel: L7: ffff88822c7a8000: find persist returns ffff88822ae6d5b0

6. Client is connected to the back-end server.

kernel: L7: ffff88822c7a8000: Connecting from 10.67.48.133:16933 to 10.67.48.139:80 
kernel: L7: ffff88822c7a8000: Connected

 

If the persistence timeout from the secondary Virtual Services happens to expire, the following output is expected:

kernel: L7: ffff88822c7a8000: find persist returns (null) 
kernel: L7: ffff88822c7a8000: find persist returns ffff88822ae6d5b0

As seen above, the idea to have the secondary Virtual Service(s) always get the persistence records from the primary Virtual Service.

Workaround:  
Notes:

https://support.kemptechnologies.com/hc/en-us/articles/7170511106189-Port-Following

https://support.kemptechnologies.com/hc/en-us/articles/202040855-Persistence

https://support.kemptechnologies.com/hc/en-us/articles/6370901430157-Troubleshooting-Connectivity-to-the-Virtual-Service


Was this article helpful?
0 out of 0 found this helpful

Comments