It’s a commonly used practice these days for web applications to make use of sessions to keep track of a requesting client’s data. This is done for many reasons, authentication, user privileges, shopping cart contents, etc.

One of the hindrances of this practice is the need for a persistent connection to a single webserver for that client. Without persistence, you don’t know which server you’ll actually be routed to, assuming you’re accessing an application that’s being served in a load balanced fashion. If this occurs with an application where sessions are required, your session data could be on one server, while you’re connecting to another…which isn’t very likely to produce the desired result. The answer to this issue is to create a persistent connection when a client connects, to ensure that once they’ve been sent to a webserver, they continue to be sent back to that webserver until their interaction is complete.

What if, however, you have an instance where somehow all of your main web servers are offline? Incoming connections get routed to that failover pool that you implemented to be safe, so the customers are at least getting a “Temporarily Unavailable” message, rather than a default error. But now what happens when those clients get a persistence record created, pointing them to the failover server? When your main web servers come back online, how do you make sure that you don’t have anyone persisting to the failover pool? Why…with an iRule, of course.

With this simple rule, and the proper pool configuration (I.E. a separate pool for your failure server[s] ) you can be sure that you aren’t persisting to the failure server, and that your users will be back to using the proper web servers as soon as they’re back online.

rule nopersist_failover {
  when LB_FAILED {
    persist none
    LB::reselect pool FAILURE_POOL
  }
}

It may not be complex, but it doesn’t have to be. Four simple lines to save a lot of time, and headaches. And that's the power of iRules.

Disabling persistence when nodes are down