Optimize connections with client-to-server affinity for the Dispatcher component

The Dispatcher affinity feature maps a client IP address to a back-end server. Affinity is established after a packet's destination IP address matches the cluster, the destination port matches the Load Balancer port, and the source IP address matches.

About this task

When affinity is established, subsequent packets are sent to the same back-end server. When affinity is broken, due to a server down or a server removal, all affinity and thus connections to that server are broken. Also, there is no "connection" information reported in the command line or GUI clients. Only the number of active affinity records are used.

This approach has the advantages of providing a hard affinity and of being more efficient for Load Balancer. The affinity method that is used decreases memory and CPU utilization as compared to connection forwarding.

Avoid trouble: The removal of an affinity record also breaks connections, so when you migrate from Load Balancer for IPv4 to Load Balancer for IPv4 and IPv6, the value you have set for maximum staletimeout setting should be used as the value for stickytime setting for Load Balancer for IPv4 and IPv6.

Choose a selection algorithm based on how Load Balancer should route connections. You can choose the following selection algorithms:

affinity

Specifies that when a subsequent packet arrives from the same client as a previous packet, the request will be directed to the same server as the previous packet. Over time, the client will finish sending packets, and the affinity record will go away.

Each affinity record lives for the stickytime value, which is in seconds:

If a subsequent connection is received within the interval of the stickytime value, the affinity record is still valid and the request will go to the same server.
If a subsequent connection is not received within the interval for the stickytime value, the record is purged. Load Balancer will select a new server for a connection that is received after the stickytime value has expired.

You can use the quiesce command to take a server offline. The server is not taken down until after the staletimeout value expires. This is an example of the quiesce command:

dscontrol manager quiesce server

connection

Specifies that when a new TCP connection is received from a client, Load Balancer will choose the server at that moment in time, and forwards the packets to it. If a subsequent connection comes in from the same client, Load Balancer treats this connection as an unrelated, new connection and choose an appropriate server at that moment.

conn+affin

The conn+affin selection algorithm combines the connection and affinity selection algorithms. Specifies that when a packet arrives from an existing connection, it is forwarded to the server which was chosen for that connection. If the packet does not belong to an existing connection, but the packet arrives from the same client, then Load Balancer selects the same server that was chosen for the previous connection.

The behavior for the conn+affin algorithm is similar to the affinity algorithm, but the timeout value for affinity is calculated from start of every connection. That means that if the time between the start of two connections from the same client is less than the stickytime value, then both connections will be forwarded to same server.

Procedure

Optional: Enable affinity by adding a port and setting the selection algorithm and stickytime at the port level to some number of seconds by using the dscontrol port command.

Choose from the following selection algorithms:

affinity

Specifies that the server selection is based on client affinity.

connection

Specifies that the server selection is based on weighted round-robin selection (default).

conn+affin

Specifies that server selection is based on the relationship to an existing connection. For new connections, the server selection is based on affinity.
For example, use the following command to set the selection algorithm to affinity and stickytime to 60 seconds:
```
dscontrol port add cluster@port selectionalgorithm affinity stickytime 60
```
Avoid trouble: When you enable affinity, it cannot be disabled unless you completely remove the port and add it again without affinity configured.
Optional: Enable cross-port affinity.
Cross port affinity is the affinity feature that has been expanded to cover multiple ports. For example, if a client request is first received on one port and the next request is received on another port, cross port affinity allows Load Balancer to send the client request to the same server. To use this feature, the ports must:
- Share the same cluster address.
- Share the same servers.
- Use the same selection algorithm, which must be affinity or conn+affin.
- Have the same stickytime value, which is not zero. After cross port affinity has been established, you have the flexibility to modify the stickytime value for the port. However, it is recommended that you change the stickytime values for all shared ports to the same value, otherwise results might occur that are not expected.
More than one port can link to the same crossport. When subsequent connections arrive from the same client on the same port or a shared port, the same server will be accessed.
Configure the crossport value with the dscontrol port add command. The following is an example of configuring multiple ports with:
- a selection algorithm of conn+affin
- a stickytime value of 60 seconds
- cross port affinity set to port 10
Enter the following:
```
dscontrol port add cluster@20 selectionalgorithm conn+affin stickytime 60 crossport 10
dscontrol port add cluster@30 selectionalgorithm conn+affin stickytime 60 crossport 10
dscontrol port add cluster@40 selectionalgorithm conn+affin stickytime 60 crossport 10
```
Avoid trouble: You can only specify a value for crossport with the dscontrol port add command and cannot be modified afterwards. You cannot use the dscontrol port set command to configure the crossport value.
See dscontrol port for detailed information on command syntax for the crossport option.
Optional: Enable port affinity override for a specific server.
You can override the stickiness of a port for a specific server with this feature, but you must be using the conn+affinity selection algorithm. The port affinity override feature can be useful in certain situations, like if you are using rules. For example, assume that you:
- Use a rule to limit the amount of connections to each application server
- Want to establish an overflow server with an always true rule. This rule responds to incoming connections with a message like Try again later for that application.
- Do not want the client to be sticky to that server, because the port has a stickytime value of 25 minutes.
With port affinity override, you can change the overflow server to override the affinity that would normally be associated with that port. The next time the client requests the cluster, it is load balanced to the best available application server and not the overflow server.
To enable port affinity override, enter the following command:
```
dscontrol server set cluster@port@server sticky no
```