Forum Discussion

Dave_21103's avatar
Dave_21103
Icon for Nimbostratus rankNimbostratus
Jun 26, 2014
Solved

LTM - Load Balancing iRule

We have a VIP that takes two connections per day coming from the same client. The client opens the two connections within the same second of each other, each connection stays open for 30 seconds. Persistence is not configured on the VIP. The pool behind the VIP contains two members. LB method is Round Robin. We've also tried Least Connections with no luck. The intermittent issue is that sometimes the two connections get load balanced to one member and sometimes each member receives one connection. Is there an iRule I can put in place to ensure one connection goes to each member every time?

 

  • The intermittent issue is that sometimes the two connections get load balanced to one member and sometimes each member receives one connection. Is there an iRule I can put in place to ensure one connection goes to each member every time?

     

    what you are seeing is due to how cmp works. i think disabling cmp should work.

     

    sol14358: Overview of Clustered Multiprocessing (11.3.0 and later)

     

    http://support.f5.com/kb/en-us/solutions/public/14000/300/sol14358.html

     

    if you do not want to disable cmp, irule similar to Matt's suggestion is needed (global variable will demote cmp, so you have to store global_myvsconncnt in session table instead).

     

    sol13033: Constructing CMP-compatible iRules

     

    http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13033.html

     

15 Replies

  • Hi!

     

    Do you know the IP of the client? You could enable source persistence for only this client with the help ir iRules.

     

    https://devcentral.f5.com/wiki/iRules.persist.ashx

     

    /Patrik

     

  • Hi Dave,

     

    Sure, you will probably want to enable oneconnect on your VS. You said that the client opens two connections, but do you know for sure they are opening two completely seperate TCP sessions from the same client? More than likely, it is one TCP session, and two HTTP requests. If that is the case, and you are not using oneconnect profile on the VS, then the loadbalancer only chooses a backend server when setting up the TCP connection...meaning all those subsequent HTTP requests may or may not be on that same connection.

     

    My first suggestion is to leave it at either Round Robin or Least Connection on the LB algo and just enable a oneconnect profile. See how that works for you.

     

    If its not cutting the mustard, I can give you an irule that will force a per HTTP REQUEST division between two pool members, but you will still need/want oneconnect on the VS

     

    Hope this helps Matt

     

  • Thanks Matt. Packet captures confirm the client is opening two TCP connections. We are not using the oneconnect profile on the VS.

     

  • Hi Dave,

    Okay, I am surprised there are two tcp connections. That would seem like round robin algorithim is not working. Could it be that there is other traffic hitting this vip? Perhaps nagios/sitescope/opennms/etc monitor traffic making requests to verify it is up? That would of course skew the alternation

    Here is an irule that uses a global variable (to retain across tcp sessions). One draw back to this irule is that it will use only one core/tmm of your LTM, but that might be okay if you aren't pushing the LTM to its max limits. If someone knows a way to do this without using a writable global var, I would be keen to know.

    You will need to add in the internal IP's of your member servers in the variables where 1.1.1.1 and 1.1.1.2 are prefilled

    when RULE_INIT {
       set ::global_myvsconncnt 0
    }
    
    when CLIENT_ACCEPTED {
       set member1 "1.1.1.1 80"
       set member2 "1.1.1.2 80"
       set pool [LB::server pool]
    
       incr ::global_myvsconncnt
       if { $::global_myvsconncnt > 1 } {
          set ::global_myvsconncnt 0
          pool $pool member $member1
       } else {
          pool $pool member $member2
       }
    }
    

    Come to think of it, if you do/may have the odd user hitting this vip in addition to the client or perhaps you have a monitoring system hitting it, we could easily add a source IP check in this irule to only apply the alternating logic to the requests coming from your client source IP. Then you could guarantee that of their two connections, one will always be on one member server and the other on the other. Additionally, logic could be added to check if the target member server is actually down in the pool and send to the other one until it is back up. Perhaps the pool member command will do this automatically if attempting to pool member a connection to a down member

    Hope this helps. If it does please mark the answer as correct

  • Hi!

    Just wanted to recommend against using the global variables as it disables CMP.

    You might want to try this one as well:

    when HTTP_REQUEST {
    
        if { [IP::client_addr] eq "10.0.0.1" } {
            persist source_addr 255.255.255.255 60
        }
    
    }
    

    Not tested for functionality nor syntax since the laptop running my lab environment died just now. 🙂

    /Patrik

  • Matt, Thanks for the suggested iRule. The developers want me to attempt an iRule and I'm willing to try the one you provided. I will mark the answer as correct if it works for us. Also Patrick, I will try your suggestion as well if Matt's doesn't work. At this point, I'm not too concerned if a solution disables CMP as this VIP only takes 4 connection request per day at the most.

     

    • Matt_Breedlove_'s avatar
      Matt_Breedlove_
      Icon for Nimbostratus rankNimbostratus
      Great Dave, hope it works out for you. It sounds like you have ruled out any other possible source client from using that vip including monitoring Couple things to note, the forums converted the literal greater than character to a > in the irule, so you will want to change that when copy/pasting. Also if your pools are not using port 80 for the members in the pool that will need to be changed as well on the line with the member IP addresses
    • Dave_21103's avatar
      Dave_21103
      Icon for Nimbostratus rankNimbostratus
      I did rule out any other possible source clients from using the VIP. Thanks for the note about greater than symbol Matt! Very much appreciate all of your help. I'm planning to deploy the iRule into Production environment next week and will let you know how things went.
    • Dave_21103's avatar
      Dave_21103
      Icon for Nimbostratus rankNimbostratus
      Matt does the iRule disable CMP for the entire LTM or just the VIP it is applied to?
  • The intermittent issue is that sometimes the two connections get load balanced to one member and sometimes each member receives one connection. Is there an iRule I can put in place to ensure one connection goes to each member every time?

     

    what you are seeing is due to how cmp works. i think disabling cmp should work.

     

    sol14358: Overview of Clustered Multiprocessing (11.3.0 and later)

     

    http://support.f5.com/kb/en-us/solutions/public/14000/300/sol14358.html

     

    if you do not want to disable cmp, irule similar to Matt's suggestion is needed (global variable will demote cmp, so you have to store global_myvsconncnt in session table instead).

     

    sol13033: Constructing CMP-compatible iRules

     

    http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13033.html

     

  • The intermittent issue is that sometimes the two connections get load balanced to one member and sometimes each member receives one connection. Is there an iRule I can put in place to ensure one connection goes to each member every time?

     

    what you are seeing is due to how cmp works. i think disabling cmp should work.

     

    sol14358: Overview of Clustered Multiprocessing (11.3.0 and later)

     

    http://support.f5.com/kb/en-us/solutions/public/14000/300/sol14358.html

     

    if you do not want to disable cmp, irule similar to Matt's suggestion is needed (global variable will demote cmp, so you have to store global_myvsconncnt in session table instead).

     

    sol13033: Constructing CMP-compatible iRules

     

    http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13033.html

     

  • Thanks everybody who posted for help with this issue. We ended up disabling CMP on the VIP with the following command and that fixed our issue, connections are balanced exactly even between the two members in the pool: modify ltm virtual VIRTUALNAME cmp-enabled no. Since we only have up to 4 connection per day, disabling CMP didn't have any affect on the performance of the VIP.