load balancing metrics

Hi, We currently load balance proxy servers on the alteon, in transparent mode so traffic flow generally goes

client--> alteon(inport filter redirect)-->-proxy(in)--proxy(out)-->-alteon--->internet internet-->alteon(filter redirect)-->proxy(out)-->proxy(in)-->alteon-->client

The filters redirct tcp traffic to the real server group. And the stickyness is acheived by setting thash sip, and dip, and the hash metric.

This ensures all client sessions with the same ip go through the same proxy(there are 3 proxy real servers)

My question is can we load balance by another way (not IP stickyness) but achive session sticyness on the the same proxy, maybe bye using sport, dport hash or something?

I know that cisco css firewalls use sport+dport hash and therefore give a better load balance. Thanks

Reply to
cconnell_1
Loading thread data ...

There are many metrics for a service group. For Application Redirection, these metrics have different algorithm with SLB.

Minmisses : When minmissesis specified for a real server group performing Application Redirection, all requests for a specific IP destination address will be sent to the same server. This is particularly useful in caching applications, helping to maximize successful cache hits. Best statistical load balancing is achieved when the IP address destinations of load balanced frames are spread across a broad range of IP subnets.

Hash: =EF=BB=BFFor Application Redirection, all requests for a specific IP destination address will be sent to the same server. This is particularly useful for maximizing successful cache hits. =EF=BB=BFThe hash metric should be used if the statistical load balancing achieved using minmissesis not as optimal as desired. Although the hashmetric can provide more even load balancing at any given instance, it is not as effective as minmisses when servers leave and reenter service.

So,. I th> Hi,

Reply to
Dophi

Thankyou. In our envronment we use application redirection and filters to send requests to the proxy servers. So my question is how this ties in. For the 2 filters(client to proxy on way out, internet to proxy on way back) we thash on sip which I guess means the same sip of the client is sent to the same proxy server each subsuqent request and dip on the way back (as there are 2 interfaces on proxy one in, one out)

However for the filters we cant use sport+dport together to load balance. But this would somehow affect the metric for the slb group as that is set to hash/minmisses, in our case I guess we cant use leastconns as the hash/minmisses sends requests to the same internet webserver to the same proxy.

So my question is how do the paremters in the slb group used with application redirection affect the thash paramters in the filters? I do understand though that using another metric would be bad for cache hits.

Reply to
cconnell_1

The thash parameter of a filter can change the algorithm of the metric of a group.

For example. the minmisses uses destination IP for algorithm for application redirection as default. If you use thash with sip, this parameter will changes the behavior of minmisses and you can get a different result of redirection. There are six different parameters for thash of a filter; auto, sip, dip, both, sip+sport, and dip32. Except "auto", they can change the result of redirection. But every parameters relate with IP address. There is no option as "sport+dport" on Alteon but maybe you can try "sip+sport".

Regards

cc>

Reply to
Dophi

Ok thats interesting, which part is used so that the client sip sticks on the same real server, is it the hash metric in the sip filter, or the hash metric in the group. We have thash on filter as sip and in the group hash, it seems to load balance by sip of the client i.e. we only get the same sips sticking to the same proxy server.(dont see any sips on the other proxies)

I read the sip is passed to the slb group from the filter (which as you said if you specify thash as sip in the filter it has an effect on redirection) So as the hash and minmisses used in application redirection is based on dest ip. So this should mean each time a client goes to a different web site (dest ip), it will be a different hash so the request should go to a different real server?

Reply to
cconnell_1

In the begining, without the thash of a filter, Alteon makes client persistence by minmisses or hash metric in a group. Without other factors, clients going to the same destination IP will be redirected to the same real server. Once you setup the thash in a filter, the thash will change the behavior (algorithm) of hash or minmisses in a group because it becomes a factor for hash or minmisses algorithm in a group.

By default, thash of a filter, minmisses, and hash only use 24bit IP address to make redircetion or SLB decisions. If the number of real servers or the IP address range of clients never changes when you are testing the redirection. You probably get the same result if you only use sip as the parameter of thash. In other words, clients in the same class C subnet probably are redirected to the same real server.

In the previous reply, I suggest "sip+sport" parameter for your testing because this lets the factor become more variable than "sip". Or you can use "mhash" command in a group; this command changes 24bit to 32bit IP address hash for minmisses. Therefore, you might get a different result for applicaiton redirection.

Anyway, it doesn't mean that clients go> Ok thats interesting, which part is used so that the client sip sticks

Reply to
Dophi

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.