Author Topic: And now for something cool...  (Read 2844 times)

Offline TheOracle

  • Hero Member
  • *****
  • Posts: 152
  • Karma: 18
And now for something cool...
« on: February 13, 2008, 03:39:18 PM »
The following example takes advantage of the new features in 8.0 in order to allow a NS to divide user requests based on a field in the query string to one of many different farms to allow siloing of content.

Assumptions:  All requests hitting a CS vserver have a query string of UID=X in it.  Based on the value X, the request should be directed to a server farm allocated to a range of UID values, for example 0-100 to farm one, 101-200 to farm 2, etc.  If a request doesn't have the UID= query parameter, then it should fall through to a default server farm. 

add cs vserver uid_cs HTTP 1.2.3.21 80
add lb vserver uid_1_farm HTTP
add lb vserver uid_2_farm HTTP

# if the policy has the string UID= in the query, jump to priority 999
add cs policy has_uid -rule "HTTP.REQ.URL.QUERY.CONTAINS(\"UID=\")"
bind cs vserver uid_cs -policyName has_uid -priority 10 -gotoPriorityExpression 999

# if control passes here, then there was no UID query param, so just go to our default farm
add cs policy true0 -rule true
bind cs policy uid_cs -policyName true0 -priority 20 -gotoPriority 10000

# our first "true" policy, needed as you can only bind the policy once
add cs policy compute_uid -rule true
# the goto here computes the priority based on the value in the UID field (if present)
bind cs vserver uid_cs -policyName compute_uid -priority 999 -gotoPriorityExpression "http.REQ.url.QUERY.value(\"UID\").typecast_num_at.div(100)+1000"

# we need to keep adding these, as you can only bind the policy once
add cs policy true1 -rule true
bind cs vserver uid_cs uid_1_farm -policyName true1 -priority 1001

add cs policy true2 -rule true
bind cs vserver uid_cs uid_2_farm -policyName true2 -priority 1002

#... continue as needed

# bind your default farm as a default policy, to be executed if nothing else matches
bind cs vserver uid_cs default_farm

Now, why did I bind the default_farm without a policy instead of binding it with the true0 policy at priority 20?  This is to allow this command to be useful:

nsapimgr -ys csw_state_update=1

This allows the CS vserver state to track the state of the default farm (so if the default farm goes down, so does the cs vserver).  This is useful in GSLB and/or RHI situations so that requests are directed to Netscalers that can service the content.  Using this mechanism allows you to silo your content, and rack and stack NetScalers, then use GSLB or RHI to scale your configuration to virtually unlimited capacity levels.

The Oracle

Offline TheOracle

  • Hero Member
  • *****
  • Posts: 152
  • Karma: 18
Re: And now for something cool...
« Reply #1 on: February 19, 2008, 08:31:27 AM »
I wanted to add why this is interesting as a configuration--it basically allows a single policy execution to split traffic up into buckets, thus causing very low overhead.  In addition, you can adjust the way it works so as to allow for variable size buckets if you desire, by setting up the buckets to have gaps in them, say binding the farms spaced out.  By adjusting where in the priority scheme you bind, then you can shift more or less traffic to one "bucket".  How is this useful?  Consider if you were building a social networking site.  You may find that initially the low numbered accounts are generating a ton of traffic, but as time goes on, the "high" usage shifts to higher and higher numbers (or it could remain the opposite).  As such, you can adjust the size of the buckets to account for actual traffic volume, insuring that your silos carry roughly the same amount of traffic, and you can easily shift traffic without impacting the overall load on the Netscaler.

The Oracle