Forum Discussion

atomicdog_7107's avatar
atomicdog_7107
Icon for Nimbostratus rankNimbostratus
May 07, 2013

iRule for Priority Group Activation... with a twist

Hey guys, I have odd scenario. I have an application that requires an primary/secondary setup for pool members. Easy enough, I could use priority group activation, right? Here's the twist: when the failover occurs, the available member for the pool must REMAIN on the secondary until the application owners have re-synced their application, and we coordinate a reset of everything. I know... don't get me started talking about how bad of a design this is... but it is what it is. So, even if the primary server begins to pass health checks, I need the traffic to remain on the secondary server until some coordinated time when they have reset their app and we can direct traffic back to the primary.

I found a post where Hoolio suggested this iRule for a failover scenario:

when HTTP_REQUEST {
     Check if the VS default pool has any active members
    if {[active_members $default_pool]}{
        pool $default_pool
    } else {
        pool sorry_pool
    }
}

This should be easily modified for what I need... I need a way to ensure that I fall out of the loop when the members of $default_pool are <1, and then a way to reset everything when the app guys are ready to set everything back to the primary. Any suggestions? Thanks in advance, as always.

6 Replies

  • Should be pretty easy, just configure the monitor used with the primary (and only the primary) with Manual Resume enabled. That way a failed primary won't come back up until you manually mark it as up. Of course, you have a risk that the primary fails, then the secondary and even thought the primary has recovered you've lost your service until you sort it out manually. It sounds like in this case it's worth that risk but unless you're a 24/7 operation you might be setting yourself up for some out of hours call outs?
  • I read your response and was thinking "What's this manual resume you speak of?" And then a light went off in my head and I vaguely remembered seeing it in the advanced configuration of the monitors. Sure enough, there it is. I've passed over it countless times, I just hadn't had a need for it yet... most of our apps are designed to be truly load-balanced and can recover dynamically from a failure. Okay, so I think this will work. I'll make a custom monitor for the primary only that has manual resume enabled, fail over, make the primary pass heath checks, and then see if I'm still on the secondary.

     

     

    I agree with all of your concerns about how this is being set up. It's a requirement of the app, which based on this and some other aspects I've been exposed to, the app isn't very robust at all. I've voiced all of these concerns and they are supposed to fix this in a future version, but we all know how that goes.

     

     

    Thanks for the quick response!

     

  • You could also technically apply the monitors to the members individually instead of at the pool, so that the primary members could have the manual resume monitors and you can do something else for the secondaries.
  • Yessir, that's the plan... at least that's how I interpreted what "What Lies Beneath" suggested above. I'll have one pool with Priority Group activation with a setting of "Less than 1 Available Member(s)"... and then I now have a custom monitor that is applied to the primary member only with Manual Resume enabled... and another monitor applied to the secondary that doesn't use Manual Resume.

     

     

    Should have everything tested out by the end of the day if I can get the app guys lined up to confirm that it's what they're hoping for. I'll let everyone know how it goes.

     

     

    Thanks again folks.
  • Hey guys, just wanted to report back that everything tested out as expected. Thanks again for the help!