Forum Discussion
mpfeifer_63884
Nimbostratus
Nimbostratusredirect part of the traffic
Hi. This is my first post in this forum, I'm not sure if it is the right topic, but as it might involve complex iRuling, I give it a try to post it under "iRules".
We have a difficult issue to set up, and it looks like this:
We have about 70 Webservers, they're all in one pool and get the traffic assigned by RoundRobin.
Now we need to redirect about 3% of the traffic to a subdomain.
We had a few ideas, like:
-redirect the traffic to 3% of of the webservers using "ratio" instead of roundrobin, but then still, how can we squeeze in an iRule at this level? Reading the docs I understand, that this is probably not possible.
-Another idea was to create an iRule which counts every userrequest and every 60th requests goes to that subdomain. But I believe that will cost a lot in performance.
Nevertheless I dislike both these solutions.
Does someone in this forum have an idea how to handle this? That would be really great.
Thanks in advance.
Markus
11 Replies
- So, to make sure I understand:
For every 100 requests that come in, 3 of them need to have a 302 issued in order to redirect the browser somewhere else.
One way to accomplish this is to apply a STATS profile to the virtual server, than increment the counter as needed via an iRule.
Take a look here for an example of using a STATS profile for reporting:
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=66
...here, for a look at the STATS::incr commmand
http://devcentral.f5.com/Wiki/default.aspx/iRules/STATS__incr.html
...and here for a rule that grabs info from the STATS data for decision making (in this case, whether or not to display a 'under maintenance' page:
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=70
I'm going to fire up my lab box in a little while, but I think this should be fairly straightforward, assuming I have your requirement correct. - Hmm. This is sort of working, but maybe one of the gurus can explain an odd bit of behavior I'm seeing.
when HTTP_REQUEST { log local0. "rule starting, count is: [STATS::get counter "counter"] " if {[STATS::get counter "counter"] == 40} { reset the clock STATS::set counter "counter" 0 log local0. "Clock was reset to 0." } if {[STATS::get counter "counter"] == 33} { HTTP::redirect http://www.google.com log local0. "redirect issued!" } STATS::incr counter "counter" log local0. "Incremented the current count to: [STATS::get counter "counter"]" }
I have a stats profile called "counter" with a single field in it, also called "counter". What I see in the logs sort of indicates that the number isn't being incremented correctly - a CMP issue, perhaps?Nov 12 14:55:35 v10bigip tmm tmm[5000]: Rule redirect_some_percent : Incremented the current count to: 1 Nov 12 14:55:39 v10bigip tmm1 tmm1[5001]: Rule redirect_some_percent : rule starting, count is: 40 Nov 12 14:55:39 v10bigip tmm1 tmm1[5001]: Rule redirect_some_percent : Clock was reset to 0. Nov 12 14:55:39 v10bigip tmm1 tmm1[5001]: Rule redirect_some_percent : Incremented the current count to: 1 Nov 12 14:55:47 v10bigip tmm tmm[5000]: Rule redirect_some_percent : rule starting, count is: 1 Nov 12 14:55:47 v10bigip tmm tmm[5000]: Rule redirect_some_percent : Incremented the current count to: 2 Nov 12 14:55:50 v10bigip tmm1 tmm1[5001]: Rule redirect_some_percent : rule starting, count is: 1 Nov 12 14:55:50 v10bigip tmm1 tmm1[5001]: Rule redirect_some_percent : Incremented the current count to: 2
At 33, the request to google was issued as expected.
Notice that it stayed 1 for 2 iterations there. In the final rule, we'd want to basically roll through a 0-99 count, then issue the redirect 3 times, at 33, 66 and 99 for example. This is sort of a quick proof of concept, but it's pretty close. It's possible that it could be tightened up considerably, speed- and efficiency-wise.
JQ 
hoolioCirrostratus
Hi JQ,
It does seem like a CMP related issue. It looks like each TMM instance (tmm versus tmm1) is referencing its own copy of the stats counter... I thought stats profiles were CMP compatible in v10. Can anyone clarify this?
A workaround might be to use the session table to store the current count.
Thanks,
Aaron- I think a better solution could be to add some dummy pool members (such that 3% of pool members are dummies) and check to see if they were hit in LB_FAILED and do the redirect there.
- hoolioHi Spark,
That's a nice solution. But can you comment on whether stats profiles are CMP compatible in 9.4.x and 10?
Thanks,
Aaron - hoolioAye... this isn't looking good. It seems like each TMM references its own copy of a stats profile. This isn't mentioned in SOL7751 or the CMP page. I opened a case on this (C595714).
Spark, do you know if there are any plans to support stats profiles with CMP? We have a customer who was planning an emergency upgrade to 10.0.1 in a few weeks who depends on the stats profile for reporting on iRule stats via SNMP.
Here's a simple example:when HTTP_REQUEST { STATS::incr test_stats_profile field1 log local0. "field1: [STATS::get test_stats_profile field1]" }
Log output shows tmm has one version of the count and tmm1 has a different one:Nov 13 12:26:57 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 2 Nov 13 12:26:57 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 3 Nov 13 12:26:58 local/tmm1 info tmm1[7681]: Rule test_stats_simple_rule : field1: 5 Nov 13 12:26:58 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 4 Nov 13 12:26:58 local/tmm1 info tmm1[7681]: Rule test_stats_simple_rule : field1: 6 Nov 13 12:26:58 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 5 Nov 13 12:26:58 local/tmm1 info tmm1[7681]: Rule test_stats_simple_rule : field1: 7 Nov 13 12:26:58 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 6 Nov 13 12:26:58 local/tmm1 info tmm1[7681]: Rule test_stats_simple_rule : field1: 8 Nov 13 12:26:58 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 7 Nov 13 12:26:58 local/tmm1 info tmm1[7681]: Rule test_stats_simple_rule : field1: 9 Nov 13 12:26:58 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 8 Nov 13 12:26:58 local/tmm1 info tmm1[7681]: Rule test_stats_simple_rule : field1: 10 Nov 13 12:26:58 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 9 Nov 13 12:26:59 local/tmm1 info tmm1[7681]: Rule test_stats_simple_rule : field1: 11 Nov 13 12:26:59 local/tmm info tmm[7675]: Rule test_stats_simple_rule : field1: 10
Aaron 
mpfeifer_63884Hi hoolio, hi sparks. Thanks for the ideas. Indeed to manage it through a STATS-profile seems like a good idea (hoping that it doesn't have an impact on the performance, but I'll see that in the tests).
But one thing I do not understand. What do you mean by using the session table to store the count?
Unfortunately the setup is even a bit more complicated (I didn't expect that that might an issue, so I didn't reference it): these 3 percent of the traffic should only affect users who don't have a session-cookie yet. So 3% of the users who don't have a session cookie need to get a different cookie as well (besides being redirected (by 302) to anpother subdomain)
All other users should be left untouched.
But as far I can see, there is no such information available in the statistics.- Assuming the CMP bit can be addressed (simple and fast workaround - depending on traffic profile, it's possible demote the Virtual Server so that CMP is not an issue), the rule would just include a check for the cookie (HTTP::cookie exists), and another line for the HTTP::cookie insert. See:
http://devcentral.f5.com/Wiki/default.aspx/iRules/HTTP__cookie.html - I don't know of any efforts to make them work across CMP in tmm-land, but that's hardly definitive. The general way that stats are handled right now is that each tmm keeps track of its own statistics, and then these are published to user-space where they are rolled-up (external to tmm). So it is quite possible that SNMP reporting works as expected, even if each tmm acts independently. This is not a part of the product that I'm intimately familiar with, so please don't take this as gospel.
That said, we do recognize that there is a need to accumulate and access statistics across processors entirely in iRules, and are actively working on this for a future release. - The session command is used to access a global table, and could be used instead of a stats profile to keep track of data. While there are currently some limitations to doing things that way, they should not affect this use of them over-much, and you could solve the problem that way.
As for your new requirement, it shouldn't be that hard to implement with either solution. If you go with the dummy pool member solution, you could check in LB_FAILED if the pool member that failed is a dummy member, and only redirect if it is (since only users without persistence cookies will get load-balanced to these pool members). If you go with the counter solution (either via the stats profile or via the session table), then you could only do the counting if the cookie doesn't already exist.
