node select expression

I appologize for belated response. Unfortunately I don't have any good news for you. You cannot use if-then control constructs in the expression on the righthand side of "select" statement. Also mapclass2node cannot be nested (wrapped) inside of other functions. It is intended to be the top-level function in a select statement.

 

 

What exactly do you need to achieve? Could you post example of configuration that you need to implement along with description what is supposed to do? What version of BIG-IP do you use (you've mentioned just 4.6.x)? Without having more information, it is really hard to offer any help.

Sorry forgot to mention. It is 4.6.1 CR37770.

 

 

The idea is, once the irule selects pool, I want to perform additional checks in the node select expression. I want to do it this way, because if I put it in main irule, it hampers the performance which I wish to avoid. Believe me, considering hits on website, adding 3 or more if-elseif in main irule, performance is affected.

 

 

Well coming back to my request, I am already using mapclass2node in node select expression, to check a cookie value and parse it in a class and based on that select node in the pool. However, I wish to check that cookie, and also check http_uri part for few possibilities which are defined in 3 different external classes, and based on a hit from a perticular class, I wish to take a different action.

 

 

I know that this should be done in irules but wish to stretch limits of node select expression to achive it.

It is true that additional cases in rules may impact performance, but what makes you believe that complex direct node select expression is going to be any better? Moreover, the bulk of performance impact of rules is due to late-binding which is necessary in order to collect data for the loadbalancing decision. Rule evaluation (especially on a well structured rule set) is a minor portion of the CPU time spent on rules. The only expesive operation during rule evaluation is regular expression matching (which can be avoided in majority of cases). Data collection (such as extraction of http_uri, cookies, headers, etc.) is performed only once (on each request) and results are cached. They key to well performing rule set is proper structure. You need to:

a) filter as much as possible via virtual server matching. So, for

example matching server address or port in a rule used by a wildcard

virtual server delivers much worse performance than several

address/port specific virtual servers,

b) match common conditions only once,

c) test for the most likely cases first

d) use classes (as opposed to chains of if-then-elses) as much as

possible

Stretching capabilities of direct node select in a pool is not a good idea in general for (at least) 2 reasons:

1) the select statement cannot be stretched too far because the

expression on the right-hand side needs to return "node type" value,

which pretty mcuh prevents any use of logical expressions,

2) even if it did allow the same flexibility as a rule, it would

definitely not deliver better performance, because it uses the same

evaluation engine.

Let me illustrate a little bit the performance aspect. Let's say that you have 2 layer structure, in which the first layer picks a pool and the second layer does additional checks and in some special cases picks a particular node. This can be implemented with a rule like this:

pool p1 {
   member server1:port1
   member server2:port1
}
pool pref_server1 {
   member server1:port1 priority 10
   member server2:port1
}
rule theRule {
  if(top_level_expression1) {
    if(special_case_expression1) {
       use pool pref_server1
    }
    use pool pool1
  } else
  if(top_level_expression2) {
    ...
  } else
  if ...
}

Even if the same functionality could actually be implemented in a select statement, the above would deliver same or better performance than:

pool p1 {
   select special_case_expression1_evaluating_to_node1;
   member server1:port1
   member server2:port1
}
rule theRule {
  if(top_level_expression1) {
    use pool pool1
  } else
  if(top_level_expression2) {
    ...
  } else
  if ...
}

If you post (at least) a mock-up of the configuration you are working on, I can help you to convert/improve it.

In any case, if flexibility and performance of iRules in 4.6 does not meet your requirements, you can always upgrade to BIG-IP version 9 which has significantly more flexible rule engine and also typically delivers much better performance than version 4.x on the same hardware. BIG-IP 540 is supported in version 9.2.

Really appreciate your detailed reply.

 

 

By the way, it came to as a surprise that 540 can support 9.x version. 6 months back a call to F5 gave us a different answer that it just cant run on 540. Can you pl. confirm as you are F5 person pl?

 

 

The reason I want to use it this way is as follows...

 

We have 12 servers in web farm as 3 groups of 4 servers each catering for different set of business apps. All servers are always live and get tons of hit everyday. However at the same time we as SA need to point browsers to a perticular server to test apps on it, using test urls.

 

This is achieved by setting up separate VIPs for live (production) urls and for test urls. Based on requested http_uri cookie set, the irules points traffic to either perticular box in production farm or to the load balanced production farm.

 

 

We have 6 lines of if-endif in production irules and adding one or more to it causes performance impact. I can add one at the most, hence thought of adding that one to check http_uri and cookie as mentioend above and branching out to the pool which contains IPs of servers I wish to access, based on cookie. mapclass2node can help me there, however situation demands that it is not just checking cookie, but couple of more things in http_uri. Thats why I need to do complex settings in node expression. Since this expression will only be accessible to urls that are used to point to perticular server, it wont put perf. impact on live production rules, and still get my job done.

 

 

Sorry it was bit complex to explain here. If you still need mock-up of prod I will provide it to you. Thx for help again.

Little bit off-topic for this forum ... support for BIG-IP 540 has been added in version 9.2 which was released in September this year. So, the your previous information was correct. See version 9.2 release notes for details: Click here.

 

 

Regarding rules, direct node select expressions and performance... Wow, you've must done very detailed measurements that you know for sure that you can add 2 if-statements (and no more) before your performance is impacted. You either must have very complicated expressions in your rules or extremely strict performance requirements that adding 2 if-statements results in un-acceptable performance degradation. BTW, what are the performance metrics we are talking about? Throughput, connection rate, transaction rate, number of simultaneous connections, latency, something else?

 

 

I'd like to reiterate: implementing the same logic using direct node select expression (which is most likely not possible in you case anyway - can't tell for sure because I've not seen your rules) would have the same performance impact as using a cascaded if-statement. Direct node select expressions use the same evaluation engine as iRules.

 

 

I've outlined in my previous post a possible solution to your problem Please, explain why it cannot work for you.