Failover instead of Load Balancing Pool members?

The easiest way to get it done from my perspective works without an iRule.

Just apply destination address affinity to the virtual server.

Now check the persistence table:

watch -d -n 1 tmsh show ltm persist persist-records   

You will notice a single entry only. Traffic to the virtual server (persistence key) is balanced to selected pool member. No matter who the client is.

As soon as the pool member fails all incoming traffic will be directed to the alternative pool member and the persistence record will be updated.

That´s it. Obviously the feature was intended to be used in another context but it works pretty well for this particular purpose.

I actually started using it this way in BIG-IP v4.2. 🙂

Thanks, Stephan

You need to use priority group activation. Set is up so that it activaties the second group when less than 1 server is availible. The set the server you want to be primary with a priority of 1 and the backup as priority 2. You may be able to find a doc on ask f5 that exsplains it better, but that iis the basic way to do what you are looking to do. I do this for mail servers too and it works well.

For this setup, can it be achieved that the backup server remains active after the primary server comes back up?

There is a nice example of single node load balancing in the iRules Codeshare:

 

 

Single Node Persistence (Click here)

 

 

 

The first connection will create a single universal persistence record with a key of "1". All subsequent connections will look up persistence using "1" as the key, resulting in truly universal persistence for all connections. (Use 1 or any constant value. 0 will have the same affect as using 1. One of my customers uses "persist uie [TCP::local_port]"

 

 

When one node fails, the other is persisted to by all comers. When the 2nd node fails, the 1st again becomes the preferred node for all, ad infinitum.

 

 

Doesn't offer the capability of manual resume after failure, or true designation of a "primary" and "secondary" instance (sometimes required for db applications), but it sure does solve the problem of "only use one node at a time, I don't care which one, please" (You can use priority to gravitate towards the top of a list...)

 

 

 

 

Aaron