Hi Martin,
If you are not specifying a beginning and an ending pattern, the entire URL is hashed and used to select a real server.
Is there any sticky also configure because of which the traffic is reaching to one server only. Please check.
I would like to share some information about URL hash predictor.
URL hashing is a load-balancing predictor for Layer 7 connections.
Always remember that HTTP header load balancing is different from HTTP URL hashing. HTTP header load balancing is a method of selecting virtual servers. URL hashing is a method of deciding which real server to send the request to, after the content switch selects a virtual server.
The load balancer chooses the real server by using a hash value based on a URL. This hash value may be computed on the entire URL or on a portion of it. To select only a portion of the URL for hashing, you can specify the beginning and ending patterns in the URL so that only the portion of the URL from the specified beginning pattern through the specified ending pattern is hashed.
Cache servers perform better using URL hashing. However, the hash methods do not recognize weight for the real servers. The weight assigned to the real servers is used in the round-robin and least-connection predictor methods.
Server weights are not used for hash predictors.
Cache servers perform better with the URL hash method because you can divide the contents of the caches evenly if the traffic is random enough but does not guarantee to load balance evenly. In a redundant configuration, the cache servers continue to work even if the active ACE switches over to the standby ACE.
The goal is to guarantee that the same object will not be cached on many servers and therefore maximise disk usage.
So, if you don't really need to maximize this disk usage, you could use any other balancing method like .
If the primary concern is the BW and not disk space, you need to go to roundrobin or leastconn.
If your goal is to preserver disk space, your solution is the best one and the drawback is unequal loadbalancing.
You can't get both at the same time.
There is no one-best-for-all solution.
It all depends on what are your priorities.
URL hashing is useful in caching environments in which the content is not duplicated across the real servers.
FOR CSM
In CSM URL hashing maps the URL (or portion) for the request to a real in a server farm. To specify only a portion of the URL, you need to configure the starting and/or ending keyword strings.
This configuration is per vserver object.
url-hash begin-pattern str [end-pattern str]
All characters in the keywords are included in the hash-value. In order to map it to a real, the CSM looks at the first few bits in the hash-value. If this real is disabled, the CSM finds the next available real in the list. In release 2.2(3) and later, the CSM looks at the higher bits in the hash-value if the first hash bits mapped to a disabled real. If the CSM cannot find an enabled real, it looks sequentially for the next available real.
The benefit of hashing in general is that, because the content switch hashes every packet of a flow, it does not need to store the associations of the client's connection to the selected real server in RAM. As a result, hashing is a stateless distribution method,
You can removed sticky connections from URL hash, thus, might be your both caches will get equal amount of requests if your traffic pattern is random but as I said above hashing can't guarantee to have equal load balance to the servers.
For ACE
If you want to load balance a pool of proxy servers based on the HTTP URL (not based on source or dest ip address) so that a certain domain always gets "cached/forwarded" to the same proxy server. But you don't really want to put matching criteria in the configuration (such as /a* to S1, /b* to S2, /c* to S3,etc..), but have this hash calculated automatically.
The ACE compute its own hash based on the number of "online" proxy servers ie. when 4 servers are online, it distribute the load by distribute the URLs based on domains between 1,2,3,4 evenly.
Suppose if server 4 fail, it will recalculate hash so that the load of S4 gets distributed across the other 3 evenly. Also load-balancing domains of S1 ,S2 and S3 should not change if S4 fails.....
This can be done as follows:
ACE1/Admin# conf t
Enter configuration commands, one per line. End with CNTL/Z.
ACE1/Admin(config)# serverfarm Proxy
ACE1/Admin(config-sfarm-host)# predictor hash ?
address Configure 'hash address' Predictor algorithms
content Configure 'hash http content' Predictor algorithms
cookie Configure 'hash cookie' Predictor algorithms
header Configure 'hash header' Predictor algorithm
layer4-payload Configure 'hash layer4-payload' Predictor algorithms
url Configure 'hash url' Predictor algorithm
ACE1/Admin(config-sfarm-host)# predictor hash url
It does hash the url and the result takes into account the number of active proxies dynamically.
Because of the design of the ACE code, it didn't know how many ip, which ip ... would be used.
Morever, this information changes with every customer.
In conclusion cisco made a generic algorithm which works most of the time.
But this algorithm can't guarantee that you will have equal loadbalancing.
If you need equal load on your caches, you need to switch to leastconn or roundrobin.
Usually when using ACE with caches, cisco recommends to use either hash url (if you want to make sure one object only exists on one cache - save disk space) or roundrobin/leastconn to have equal load on the caches.
Kindly see below the article in this regard:
http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Data%20Center&topic=Application%20Networking&topicID=.ee7814f&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cc060ee
CSM Hash URL config example:
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/csm/4.2.x/configuration/guide/rsfarms.html#wp1038416
ACE URL HASH
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/rsfarms.html#wp1039347
HTH
Sachin garg
