Forum Discussion

Niko1978's avatar
Niko1978
Icon for Nimbostratus rankNimbostratus
Mar 15, 2021

big ip failover and back issue

Hi,

I'm a customer with big ip hardware. I use them to lb few services and also as failover for few others.

It's the last case where I'm facing some problems.

So I have 2 servers behind big ip vip (srvA and srvB), srvA is the primary and srvB the backup.

What I want is just a pure failover : so if srvA is down, redirect all trafic to srvB AND if srvA is back, redirect again ALL trafic to it, not just new connections.

My issue is that when srvA is back, only new connections arrive on it... old ones are still on srvB.

In my case it's not acceptable.

So how to do to switch all trafic (even if that needs to reset connections) to the first server when it is back online ?

 

If that can help, I use BIG-IP 15.1.0.4 Build 0.0.6 Point Release 4

failover is defined like that :

- default & fallback persistance profile : none

- priority group activation "less than 1" with a srvA=10 and srvB=0

 

Thanks for your help

Regards

Nicolas

3 Replies

  • eey0re's avatar
    eey0re
    Icon for Cirrostratus rankCirrostratus

    Hi Nicolas,

     

    I assume you are using Priority Group Activation in the pool to achieve the failover/failback (if not, do explain your method). What is the application protocol?

     

    If it is HTTP, attaching a OneConnect profile may do what you want without having to reset connections. OneConnect with an HTTP profile means each HTTP request is load balanced individually (using a shared pool of server-side connections) instead of just the initial TCP connection. (Just make sure you aren't also using a persistence profile.)

  • hi eey0re,

    Thanks for your reply.

     

    So I use well "priority group activation" with setting "Less than 1"

    First srv has value of 10, the second 0

     

    About protocol : it's for streaming, so vip f5 receives rtmp (tcp 1935) or rtmpt (tcp 80) or rtmps (tcp 443 so tls here) then forward them to srv on tcp 1935. They are configured as HTTPS for 443 and L4 for two others.

     

    I added some screenshots.

     

    I will try OneConnect. Do I need to check something else than persistence if I test it ?

     

    Thanks

    NIko 

  • eey0re's avatar
    eey0re
    Icon for Cirrostratus rankCirrostratus

    Try OneConnect if you have an HTTP profile attached. The other thing to note is that each backend connection will now carry requests from a mix of users. Almost all application servers these days are fine with this, but a very few may break (for example, if they only check authentication on the first request of the connection). The only way to know is to test.

     

    Read the support article K7208: Overview of the OneConnect profile.

     

    I can't think of a solution if you don't have an HTTP profile. Depending on your system, switching from fastL4 to Standard could add load, and I don't know much about RTMP to say if it's compatible. The TCP::close irule command can close the connection, but the problem is what event to trigger it with, since it's an L4 VS.

     

    You can of course drop the connections manually through TMSH. (delete /sys connection). Maybe this could be automated with the tmsh scripting API, but I can't say if this is a good idea.

     

    I'm interested to see if others here have more ideas.