Forum Discussion

Vincent_96516's avatar
Vincent_96516
Icon for Nimbostratus rankNimbostratus
Jan 30, 2012

Message based load balancing for no standard message format

Hi, all.

 

We have a message based load balancing requirement very similar to what is described in the following white paper:

 

http://www.f5.com/pdf/white-papers/message-based-load-balancing-wp.pdf

 

 

The message format we are using is private (2 bytes binary header + binary payload).

 

We will do load balancing based on one field in the message.

 

 

My questions are:

 

(1) Is it possible to use F5 message based load balancing framework to support our private message format? If it's possible, is there any documentation or example for this?

 

(2) If using F5 message based load balancing framework is not possible, can I create iRules script to achieve similar goal? I am thinking using OneConnect and TCP. Any example?

 

 

Thanks.

 

 

Vincent

 

 

application delivery
dev
devops
iRules

3 Replies

Sort By
  • Ian_Smith's avatar
    Ian_Smith
    Ret. Employee
    Jan 30, 2012
    1. Yes. It isn't documented, but the gist of it is this:

    First, you need to add the mblb profile to your virtual server using the command line - 

    (tmos.ltm) modify virtual my_vs profiles add { mblb }

    Now you can write a rule that uses TCP::collect, TCP::release (make it equal to the message size), and TCP::notify to find and process the messages and USER_REQUEST & USER_RESPONSE to act on them; apply the rule to my_vs.

    It works best if your message is fixed length or if each message fits in a single TCP packet, but you can still get it to work if neither are the case. Just remember that when inspecting each packet you will take a performance hit.

  • Vincent_96516's avatar
    Vincent_96516
    Icon for Nimbostratus rankNimbostratus
    Jan 31, 2012
    Ian, thanks for the answer.

     

    I have good knowledge about load balancing, but new to F5 and iRule. Some more questions:

     

    (1) Do I need to handle USER_REQUEST and USER_RESPONSE? Or they will be handled by mblb framework? I think TCP::notify is required by mblb as well, right?

     

    (2) Is the code in the post (http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=1166991) a good example to start with?

     

    (3) Our messages are with variable length and could be in multiple packets (maximun size about 2 KB). I guess I will just need to keep collecting if I didn't get all packets when handling CLIENT_DATA and SERVER_DATA, any example for better performance?

     

     

    Vincent
  • Shu_97237's avatar
    Shu_97237
    Icon for Nimbostratus rankNimbostratus
    Jul 13, 2012

    Hi Vincent,

     

    I was trying to configure F5 LTM VE 10.1 to do message-based load balancing but unsuccessful so far. I read your post here (https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/2161023/showtab/groupforums/Default.aspx). It seems you were doing something similar to what I'm trying to do. I'm wondering if you could help me. The irules I wrote are relatively simple. Basicly, what I want to do is to extract individual messages received over a single TCP connection and forward them to pool members. The messages have a 8-byte header. The last 4 bytes stores the length of message body. I don't need persistence, which makes the load balancing simpler. However, the problem is USER_REQUEST is never fired after "TCP::notify request" is called.

     

    Thank you in advance!

     

    Shu

     

    ____________

     

    iRules:

     

     

    when CLIENT_ACCEPTED {

     

    log local0.debug "Get a connection"

     

    TCP::collect 1000

     

    }

     

    when CLIENT_DATA {

     

    log local0.debug "in CLIENT_DATA"

     

    binary scan [TCP::payload] II head rlen

     

    if {($head & 0x3) == 1} {

     

    if {[TCP::payload length] < $rlen} {

     

    TCP::collect $rlen

     

    log local0.debug "a message is received"

     

    TCP::release $rlen

     

    TCP::notify request

     

    log local0.debug "requested"

     

    }

     

    }

     

    }

     

    when USER_REQUEST {

     

    Dispatch to the pool

     

    log local0.debug "in USER_REQUEST"

     

    pool my_pool

     

    }