Persistent Rebalance question

[cricketbuff]

Folks

I have a situation where I am not using persistent rebalance on ACE and what happens is that the server does not stick to the same server. Now if i enable persistent rebalance it does stick to the same server but load runner tests fails. This site is running akami . Now non akami just works fine even without persistent rebalance.we are using cookie insert.

We have a similar environment on CSS with akami and it works fine there. We are using arrowpoint-cookie. Now by default persistent-rebalnce is enabled on the CSS.

SO why a different behaviour on ACE? is persistent-rebalance used differently on ACE?

also does anybody know whats equivalent of persistent rebalance on F5?

[Gilles Dufour]

The persistent-rebalance function is only required if you have proxy users and the proxy shares one TCP connection between multiple users.

With this behavior, inside a single connection you will see different cookies.

Therefore, for each cookie, ACE/CSS/F5 needs to first detect the new cookie and then loadbalance to the appropriate server.

In order to speed up the transfer, ACE will stop inspecting the connection after the first cookie...assuming all other cookies are the same.

Disabling inspection makes the connection faster and reduce amount of resources require on the ACE.

But, if you are in the proxy situation described above, you have no other choice than to allow full traffic inspection and therefore enable the persistent rebalance feature.

The question should be "why does the loadrunner fail ?".

could you tell us more ?

Thanks.

Gilles.

[jason.espino]

Hello,

Gilles is right on with his response.  Akami tend to perform TCP optimization on their end which would cause cookie persistence to break and the exact behavior Gilles mentioned where persistent-rebalance is required on the ACE.

To answer your F5 question, if you are running v.10 on the LTM you could apply both the Fast HTTP Profile (parse requests parameter) and Cookie Persistence Profile to the virtual server configuration to achieve the same "persistent-rebalance" behavior on the F5 while maintaining session persistence based on a session cookie.

- Jason

[parveesm123]

Hi ,

Persistance rebalance is used for single  HTTP 1.1 connection , where as stickiness/ or in F5 terms persistence is configured for the consequent HTTP connections from the same client.

With only persistence rebalance configured , i dont think we can achieve the same result as stickiness /persistence for individual clients to achieve so you need to configured Stickiness configuration for sure.

that could be the reason why your load run failed.

Persistance rebalance feature in F5 is called as OneConnect , you can configure it in HTTP profile configuration. Where as in cisco ACE it is a parametre map configuration.

You can go for a cookie based configuration , to stick the akamai based connection , or else you can stick based on true-client-ip value in the header. irule for F5 to achieve the same is as follows.

when HTTP_REQUEST {

                  set True_Client_IP [HTTP::header "True-Client-IP"]

                if { $True_Client_IP != "" } {

                  persist uie $True_Client_IP

                  log local0. "[IP::client_addr]:[TCP::client_port]: True-Client-IP: [HTTP::header value True-Client-IP], persist record: [persist lookup uie $True_Client_IP]"

                }

                }

this can be attached to the vserver and yu can achieve the task.

HTH

Parvees