Forum Discussion

Werner_Strydom_'s avatar
Werner_Strydom_
Icon for Nimbostratus rankNimbostratus
Feb 25, 2014

Routing traffic to compatible nodes using the value of a cookie and and HTML page with the same value

Consider a web application incompatible with previous or future versions of itself. V1 can only process HTTP requests from V1 clients, nothing else. The application adds a cookie (AV) to the response with the version (V1, V2, V3 etc) as the value. An HTML page in the application displays the same version information. Two versions cannot coexist on the same node. The action of logging off, deletes the cookie.

 

Consider a web farm with a large number of nodes. A subset host V1 and another V2. Its deployment day and V1 nodes is being upgraded to V2. Customers perform transactions during this time with zero tolerance for disruptions. Sticky sessions prevent traffic intended for nodes with V1 to be sent to nodes with V2. Some nodes with V1 remain to allow old sessions to bleed off.

 

A script removes a node with v1 from of the pool. A customer with a V1 client starts a transaction. The load balancer arbitrarily assigns the request to another node with V2 installed. The application blows up and disrupts the customer. Tomorrow the process starts all over again with V3.

 

How would one configure the F5

 

  • to ensure that traffic with the V1 cookie is only redirected to nodes with V1 installed?
  • to ensure that traffic with the V2 cookie is only redirected to nodes with V2 installed?
  • to ensure that traffic with the V1 cookie is evenly distributed between nodes with V1 installed? Using sticky sessions means that some nodes work harder due to the usage from the customer.
  • to transparently handle nodes with V3 (and other versions) installed?

The site is under constant load. Customers use the system 24x7. We'd like to minimise downtime or mistakes during deployment. An iRule makes sense, however, folks are concerned about upgrades from one version of the F5 to another. There is also HTTP class profiles, but it seems complicated.

 

APM
application delivery
availability
deployment
design
devops
iRules
security

5 Replies

Sort By
  • IheartF5_45022's avatar
    IheartF5_45022
    Icon for Nacreous rankNacreous
    Feb 25, 2014

    Can a v1 session move from one v1 server to another v1 server, or do they need to be sticky to the server?

     

    I think they key thing for you will be the use of the receive disable string in a health monitor which will allow sessions to be bled off servers.

     

    • Werner_Strydom_'s avatar
      Werner_Strydom_
      Icon for Nimbostratus rankNimbostratus
      Feb 25, 2014
      Yes, v1 sessions can move from one v1 node to another v1 node and does not have to be sticky to one specific node.
  • IheartF5_45022's avatar
    IheartF5_45022
    Icon for Nacreous rankNacreous
    Feb 26, 2014

    OK I think I have it. You'll need 4 pools;-

    • pl_server_v1 - contains all servers with http monitor that checks for "v1" returned from check
    • pl_server_v2 - contains all servers with http monitor that checks for "v2" returned from check
    • pl_server_v3 - contains all servers with http monitor that checks for "v3" returned from check
    • pl_server_all - contains all servers with http monitor that checks for "v" returned from check

    The virtual server will have pl_server_all as default pool, http and oneconnect profiles assigned, and the following iRule;

    when HTTP_REQUEST {

     Check AV cookie
    if {[HTTP::cookie exists "AV"]} {
         Assign pool based on AV cookie value
        pool "pl_server_[string tolower [HTTP::cookie value "AV"]"
    }
}

    Remember to use a receive disable string in all the monitors which you can use to drain connections from the server. Let me know if it's not clear how to use this from reading the doco and I can explain.

    • Werner_Strydom_'s avatar
      Werner_Strydom_
      Icon for Nimbostratus rankNimbostratus
      Mar 05, 2014
      Thanks. I used v1, v2, v3 as placeholders for versions. In reality the versions change with every deployment (almost daily) and so does the cookie value. Once we deploy a new version, we'd like to migrate users to that version, without any errors. Since the applications isn't compatible, it can only happen when the session expires or when the user logs off. Its unclear how you'd route that request to a newer server. The iRule you posted may be subject to a DoS attack. All I have to do is send you a lot of bogus requests with cookie "AV" with a value that doesn't exist. What would you do in that case. Or worse, flood the server with requests without a cookie (more likely) which overloads servers in pl_server_all. If there is no attack, I still have to ensure pl_server_all has enough servers to handle potential load.
  • IheartF5_45022's avatar
    IheartF5_45022
    Icon for Nacreous rankNacreous
    Mar 05, 2014

    Hi, I think you'll need to incorporate some form of automation in conjunction with your continuous deployments. Deploy a new version of the pool (with new monitor) using iControl, as each new version is deployed, and use the same process to remove pools no longer in use. It's the only way I can think of to get the flexibility you need.

     

    A request with an invalid cookie value will (with the iRule above), cause a TCL error (and subsequent RST) should the pool requested not exist. You can make this more elegant by using the 'catch' command to allow you to return a valid HTTP response to the user rather than a RST should the pool "pl_server_[string tolower [HTTP::cookie value "AV"]]" not exist.

     

    I don't see any risk of DoS with the strategy above that doesn't exist with any virtual servers with cookie persistence configured.