Forum Discussion

Jogen_Doshi_453's avatar
Jogen_Doshi_453
Icon for Nimbostratus rankNimbostratus
Dec 03, 2008

BIG-LTM Loadbalancing problem

Hi,

 

 

We have a setup where in the user request hit a web server whcih in turn is calling the virtual ip on my BIG-IP.

 

 

Now the web server is SSO across many applications once of whcih is called by my virtual IP.

 

we are trying to loadbalance this particular application. since its SSO we need to enable persistancey. Due to this the source ip that the BIG-IP gets is the webserver ip. Now here is the problem we are not able to load balance the user requests for the end application since the webserver always remains persistant to only one of the application server.

 

 

Friends this is quite critical to us as we are stuck in launching the site due to this issue.

 

 

hope to get some help n solutions here......

10 Replies

  • A simplified network diagram would help. Can you change to cookie insert persistence if the client IP is always the web server?

     

     

    Aaron
  • The flow of request is as below.

     

     

    Client request

     

    |

     

    |

     

    Webserver

     

    |

     

    |

     

    BIG_IP Virtual IP

     

    |

     

    |

     

    |

     

    -----------

     

    | |

     

     

    Application x (1) Application x (2)

     

     

     

    As you wud get it the webserver wud be the source n the application x (Node 1 or 2) wud be the destination.

     

     

    Can you pl suggest the sol.

     

     

    Since the webserver is using SOAP to communicate with the application servers.

     

     

    HTTP browsers cookie doesnt help.

     

  • Also i have hunted the following irul as it seemed to be of help.

     

     

    can u suggest.

     

     

    when HTTP_RESPONSE {

     

     

    Clear the BSI_SESSIONID if it exists already on this TCP connection

     

    if {[info exists BSI_SESSIONID]}{

     

    unset BSI_SESSIONID

     

    }

     

     

    Only look for the BSI_SESSIONID in text responses

     

    if {[HTTP::header value "Content-Type"] starts_with "text"}{

     

     

    log local0. "[IP::client_addr]:[TCP::client_port]: Matched text, enabling stream filter"

     

     

    Because TCL doesn't support lookaheads, match the BSI_SESSIONID string and value

     

    We'll parse out the value in STREAM_MATCHED

     

    Assume the BSI_SESSIONID is 1 to 100 characters (terminated by a non-alphanumeric character).

     

    STREAM::expression {@;BSI_SESSIONID=[A-Za-z0-9]{1,100}@}

     

    STREAM::enable

     

     

    Enable the STREAM_MATCHED event as it could have been disabled if there was a prior

     

    response on this TCP connection

     

    event STREAM_MATCHED enable

     

     

    } else {

     

     

    Disable the stream filter as this wasn't a text response

     

    log local0. "[IP::client_addr]:[TCP::client_port]: No Content-Type match, disabling stream filter"

     

    STREAM::disable

     

    }

     

    }

     

    when STREAM_MATCHED {

     

     

    Save the matched value (example: ;BSI_SESSIONID=ABCDEF)

     

    set BSI_SESSIONID [STREAM::match]

     

    log local0. "[IP::client_addr]:[TCP::client_port]: Matched: $BSI_SESSIONID"

     

     

    STREAM::match shouldn't match a null string with the defined regex, but check anyhow

     

    if {[string length $BSI_SESSIONID]}{

     

     

    Get the BSI_SESSIONID value (split ;BSI_SESSIONID=ABCDEF on the equals sign)

     

    set BSI_SESSIONID [getfield $BSI_SESSIONID "=" 2]

     

     

    The iRule parser doesn't allow the persist command in STREAM_MATCHED.

     

    It works though, so hide the command from the parser

     

    set persist_cmd "persist add uie $BSI_SESSIONID"

     

    log local0. "[IP::client_addr]:[TCP::client_port]: Parsed: $BSI_SESSIONID \$persist_cmd: $persist_cmd"

     

     

    eval $persist_cmd

     

    persist add uie $BSI_SESSIONID

     

     

    Assume the first match is the same as any other BSI_SESSIONIDs, so stop checking for them

     

    log local0. "[IP::client_addr]:[TCP::client_port]: Added persistence record. Exiting event for this response."

     

    event STREAM_MATCHED disable

     

    }

     

    }
  • Hi,

     

     

    check the error m getting on the application server.

     

     

    Invalid session P7910RCOM231|%40P7930RCOM196|P7910RCOM231%406545JqRwJEFqdIh834ru6544JDsz0zO5SvonidMj|osca%3Aiiop%3A%2F%2FP7910RCOM231%3BSI_SESSIONID%3D6544JDsz0zO5SvonidMj|en_US|GMT+05:30 (Error: WRE 00005)

     

    Exception: com.businessobjects.dsws.wsc.common.axis.WSExceptionFactory$InvalidSessionID

     

    Message: P7910RCOM231|%40P7930RCOM196|P7910RCOM231%406545JqRwJEFqdIh834ru6544JDsz0zO5SvonidMj|osca%3Aiiop%3A%2F%2FP7910RCOM231%3BSI_SESSIONID%3D6544JDsz0zO5SvonidMj|en_US|GMT+05:30

     

     

    I m using the same irule as above. and trying to capture n match the BSI_Sessionid

     

     

    Can u suggest a serch string change in the irule so that it starts matching the captured parameter.

     

     

     

    iRule Statistics

     

    iRule Event Type Total Executions Failures Aborts

     

    BO_LB_P STREAM_MATCHED 0 0 0

     

    BO_LB_P HTTP_RESPONSE 40 0 0

     

  • Hi Jogen,

     

     

    Can you take a look at the questions in my last post? It would be helpful to know what you can potentially persist on before trying to help you configure an iRule to do it.

     

     

    Thanks,

     

    Aaron
  • Is the BSI_SESSIONID included in the request from the web server to the app via the BIG-IP? If so, is it in the HTTP headers or body?

     

     

    Aaron
  • Hi,

     

     

    BSI_SESSIONID is coming in the http response header from the app server to the webserver.

     

     

    So for the first time i guess we will have to capture the BSI_SESSIONID from the response of the app server header n thn may b use it in future for persisting the session.

     

     

    Basically the ans to your question is NO.
  • If the BSI_SESSIONID isn't included in any location in the request from the web server to the app server, you won't be able to use it for persisting the web server request to the same app server over the course of multiple requests.

     

     

    Is there any portion of the request headers or data from the web server to the app server that you could use to persist the same client requests to the same app server? You need to determine this before trying different persistence methods. See the previous post on some related options (Click here).

     

     

    Thanks,

     

    Aaron
  • one unique parameter that i m passing from the webserver to the app server is "UserID"

     

     

    Can v persist on this n how..?

     

  • The UserID token would need to be present in each request in order for the persistence to work. By parameter, do you mean an actual parameter in the HTTP URI or the payload? If the former, you could parse the parameter value using 'URI::query [HTTP::uri] UserID'. If the parameter is in the HTTP payload, you would need to collect the payload using HTTP::collect (Click here).

     

     

    Once you have parsed the token to persist off of, you can use 'b persist uie $token 3600' where 3600 is the time in seconds to maintain the persistence record for.

     

     

    Aaron