Metric and Description | |
---|---|
minmisses | |
The minmisses (minimum misses) metric is optimized for application redirection. When it is specified for a real server group performing application redirection, all requests for a specific IP destination address are sent to the same server. This is useful in caching applications, helping to maximize successful cache hits. The best statistical load balancing is achieved when the IP address destinations of load balanced frames are spread across a broad range of IP subnets. Minmisses can also be used for SLB. When specified for a real server group performing SLB, all requests from a specific client are sent to the same server. This is useful for applications where client information must be retained on the server between sessions. Server load with this metric becomes most evenly balanced as the number of active clients increases. | |
hash | |
Like the minmisses metric, the hash metric uses IP address information in the client request to select a server. For application redirection, all requests for a specific IP destination address are sent to the same server. This is particularly useful for maximizing successful cache hits. For SLB, all requests from a specific client are sent to the same server. This is useful for applications where client information must be retained between sessions. Use this metric if the statistical load balancing achieved using minmisses is not as optimal as desired. Although the hash metric can provide more even load balancing at any given instance, it is not as effective as minmisses when servers leave and re-enter service. If the load balancing statistics indicate that one server is processing significantly more requests over time than other servers, consider using this metric. | |
leastconns | |
With the leastconns (least connections) option, the number of connections currently open on each real server is measured in real time. The server with the fewest current connections is considered to be the best choice for the next client connection request. This option is the most self-regulating, with the fastest servers typically getting the most connections over time, due to their ability to accept, process, and shut down connections faster than slower servers. | |
roundrobin | |
With the round-robin option, new connections are issued to each server in turn. The first real server in this group gets the first connection, the second real server gets the next connection, followed by the third real server, and so on. When all the real servers in this group have received at least one connection, the issuing process starts over with the first real server. Note: The roundrobin metric works on a per-Alteon Switch Processor (SP) basis. | |
response | |
This is the real server response time. With this option, Alteon monitors and records the time that each real server takes to reply to a health check. Use the response time to adjust the real server weights. The weights are adjusted so they are inversely proportional to a moving average of response time. | |
bandwidth | |
With the bandwidth option, the real server weights are adjusted so they are inversely proportional to the number of octets that the real server processes during a given interval. The higher the bandwidth used, the smaller is the weight assigned to that server. | |
phash | |
The phash metric uses the best features of the hash and minmiss metrics. With phash enabled, Alteon supports an even load distribution (hash) and stable server assignment (minmiss) even when a server in the group goes down. With the phash metric, the first hash always is the same even if a real server is down. If the first hash hits a dead server, it rehashes for that request based on the actual number of servers that are up. This results in a request always being sent to a server that is up. The default phash mask is 255.255.255.255. To change the default, configure the required mask next to metric parameter. For example, /cfg/slb/group 1/metric phash 255.255.255.0. | |
svcleast | |
The svcleast (least connections per service) metric is an extension of the leastconns metric. When using this metric, Alteon selects the real server based only on the number of active connections for the service which is load balanced, and not the total number of connections active on the server. For example, when selecting a real server for a new HTTP session, a real server serving one HTTP connection and 20 FTP connections takes precedence over a real server serving two HTTP connections only. | |
hrw | |
Can ensure client IP address persistency in an Active-Active cluster scenario. Usually Layer 3 session stickiness to a real server is preserved on Alteon via the session table and the persistency entries (p-entries). To ensure that Layer 3 stickiness is preserved when the active Alteon fails, the preserved session table and persistency entries must be by synchronized (mirrored) between the cluster peers. In an Active-Active cluster such synchronization is not practical, and a different mechanism is required to preserve Layer 3 connections and Layer 3 session stickiness to a real server for a scenario where an Alteon instance fails. The HRW method performs hash on the client IP plus server IP. Thus, when a new connection arrives, hash is performed for the combination of client IP address with each of the servers. The server that results in the highest hash value is selected. When a real server becomes unavailable or is removed, all session entries mapped to it are removed and load balancing is performed again for those sessions. HRW then selects the new highest result for each client and all sessions of each specific client are mapped to a new server. This is consistent across all cluster members. Note: If a new server is defined and shortly afterwards failover occurs, sessions that started before the addition of the new server might be redirected to the wrong server (if the new server yields a higher hash value). To ensure that client persistency is maintained in an Active-Active cluster in all cases you have the option to use Client IP persistency and the /cfg/slb/sync/cluster command. This ensures client IP persistency is synchronized among cluster members and can be used with different metrics. For more information about the /cfg/slb/sync/cluster command, see /cfg/slb/sync/cluster Cluster Sync Configuration. |