Application Grouping and Persistence
Normally, when the ServerIron ADX selects a real server for a client’s request for a TCP/UDP port, there is no guarantee that the ServerIron ADX will select the same real server for subsequent requests from the same client.
By default, the ServerIron ADX uses the predictor (load-balancing method) you configure for each new request
from a client to a virtual server. This works well for many situations. However, for some application service implementations, it is desirable or even required to have the client continue to access the same real server for subsequent requests.
You can configure the ServerIron ADX to ensure that a client that accesses certain TCP/UDP ports on a VIP will always go to the same real server. For example, you might want the real server to be enabled to allow related application services that a client initiates to remain at the same real server or you might want the real server to be able to arbitrarily assign open TCP/UDP sessions with the client using ports that are dynamically allocated by the real server
Another example, you might want to configure the TCP/UDP ports related to an interactive Web site so that when a client begins a session on the site, subsequent requests from the client go to the same real server. [This is more commonalty handed with cookie persistence for http protocol]
To accomplish this, you can leverage Cookie Persistence [for HTTP(S) protocol] and/or Application Grouping or Persistent hash for any TCP/UDP protocol
Example code, check Cookie Switching
Application grouping parameters apply to virtual servers. When you configure a virtual server, you specify the
TCP/UDP ports on that virtual server. When you apply application grouping to a TCP/UDP port on a virtual
server, the application grouping overrides the predictor (assuming the next new connection would be handled by different real server). The ServerIron ADX allows you to configure the following application grouping methods on an individual virtual-server basis:
* Sticky connections
When a service request by a client mandates a series of sequential TCP/UDP port connections to be served by the same real server (to maintain session state information), you can enable a sticky connection on that TCP/UDP virtual server port. When you add a TCP/UDP port to a virtual server, if you specify that the port is “sticky”,
a client request for that port always goes to the same real server unless the sticky age timer has expired. The
sticky age timer specifies how long the connection remains “sticky” (always goes to the same real server) and
is reset each time a new client request goes to the sticky port. Once the sticky timer expires, the ServerIron
ADX uses the predictor (load-balancing metric) you have configured to select a real server for requests for a
port. (using the port sticky function).
Using the sticky feature, the current maximum persistence possible for Stateful SLB is 20 hours. If you need a client to persist longer than that, use hash-based SLB option.
* Sticky with TCP/UDP application port groups
Application groups extends/enhances the sticky connections method by allowing you group related ports.
Using the track port function, a “primary” TCP/UDP port with up to four additional TCP/UDP ports. After the ServerIron ADX sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server.
The ServerIron ADX automatically sends requests for the grouped ports to the same real server as the “primary”
port as long as the sticky timer has not expired.
Using the track group function, up to eight TCP/UDP ports are grouped together. After the ServerIron ADX sends a client request for any of the grouped ports to a real server, subsequent requests from the client for ports in the group go to the same real server. NOTE: You must configure all the ports in a TCP/UDP application group to be “sticky”.
For both options, you must define all the ports in an application group individually in the VIP and you must configure all of them to be sticky. The application group method, like the sticky method, is governed by the sticky age.
* Sticky with Concurrent Connections
When you configure a TCP/UDP port in a virtual server to support concurrent connections, the real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers. (i.e. the concurrent connection option supports both a primary connection and secondary connections. The connections are supported at the same time. The primary connection is the controlling connection and dictates the resource, such as a server, to which subsequent or secondary connections are made.
Once the controlling connection is established, the server dynamically assigns a TCP/UDP port to which the client should open subsequent or secondary connections. Subsequent connections from that client are accepted on the server as long as the controlling connection is still active.
Persistence Hash Based SLB
Using the sticky feature, the current maximum persistence possible for Stateful SLB is 20 hours. This setting may not be sufficient for systems that always need the client to be directed to the same real server,for example two days later, unless an event such as real server failure necessitates reassignment of the client to a different server.
Example code, check Setting/Changing/Enabling Persistence connections - SLB persistent hashing