Forum Discussion

fxn-f5-bot_3543's avatar
fxn-f5-bot_3543
Icon for Nimbostratus rankNimbostratus
Feb 28, 2018
Solved

Delayed Fail over to a secondary server

Hi All,

 

I have a unique requirement where the client would like to have a delayed fail over between 2 nodes in a pool. There will be a database application behind an LTM with a pool containing 2 nodes active/passive. In an event where the active unit goes down, the passive unit requires some manual intervention/checks before it can be brought up as a live active node. Now I know one may ask why you need F5 here? but here its purely to consolidate a single IP address to represent a database service behind a VIP. The challenge is, will it be possible for F5 to wait certain period of time before failing over to the secondary node in the pool? Will the F5 have some logic to perform some check on the passive unit to make sure that its database service is running as expected? and then trigger a fail over.

 

Any help will be appreciated? Regards

 

  • Seems like all you need is a ratio configuration to make sure your primary DB node gets all connections as long as its available, and a health-check monitor. Maybe even tcp-half-open healt-check monitor will do. As long as the Standby Database Node keeps its TCP listener closed while it's sub-services are unavailable, you will not need any complex alchemy. That's how most database systems operate - if service is down, TCP listener is closed. BigIP can identify this and not send any traffic there. What DB system are you using?

     

    https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-monitors-reference-11-2-0/1.html

     

4 Replies

  • Seems like all you need is a ratio configuration to make sure your primary DB node gets all connections as long as its available, and a health-check monitor. Maybe even tcp-half-open healt-check monitor will do. As long as the Standby Database Node keeps its TCP listener closed while it's sub-services are unavailable, you will not need any complex alchemy. That's how most database systems operate - if service is down, TCP listener is closed. BigIP can identify this and not send any traffic there. What DB system are you using?

     

    https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-monitors-reference-11-2-0/1.html

     

    • fxn-f5-bot_3543's avatar
      fxn-f5-bot_3543
      Icon for Nimbostratus rankNimbostratus

      Hi Hannes,

       

      Many thanks for your response. It kind of makes sense, as long as the secondary passive DB server is not listening on its service port the F5 will declare the node as down and will not forward any traffic. I will confirm with the client if this is the case (Though I don't see a reason why would someone run a service on a passive DB server). This is a Sybase database, now probably part of the SAP platform.

       

      Thanks for your help. Regards

       

  • Seems like all you need is a ratio configuration to make sure your primary DB node gets all connections as long as its available, and a health-check monitor. Maybe even tcp-half-open healt-check monitor will do. As long as the Standby Database Node keeps its TCP listener closed while it's sub-services are unavailable, you will not need any complex alchemy. That's how most database systems operate - if service is down, TCP listener is closed. BigIP can identify this and not send any traffic there. What DB system are you using?

     

    https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-monitors-reference-11-2-0/1.html

     

    • fxn-f5-bot_3543's avatar
      fxn-f5-bot_3543
      Icon for Nimbostratus rankNimbostratus

      Hi Hannes,

       

      Many thanks for your response. It kind of makes sense, as long as the secondary passive DB server is not listening on its service port the F5 will declare the node as down and will not forward any traffic. I will confirm with the client if this is the case (Though I don't see a reason why would someone run a service on a passive DB server). This is a Sybase database, now probably part of the SAP platform.

       

      Thanks for your help. Regards