Forum Discussion

Chris_Phillips's avatar
Chris_Phillips
Icon for Nimbostratus rankNimbostratus
Sep 18, 2014

implicitly disabling half of a pools members

Howdy,

 

We're looking at ways to isolate one of the two data farms that we LB to in LTM. Currently we script out iControl calls to disable hundreds of pool entries, and I'm thinking about ways to remove this mass requirement. One option I was thinking about was having a generic iRule catchign LB_SELECTED and if the selected member is in a certain subnet, do an LB::reselect. Given the blocked subnet would be typically 2 out of 4 members, I'm concerned that if we're just doing an RR across a busy pool, we'd risk having a hell of a lot of retries, indeed MOST connections would presumably be retried nu my reckoning. Is this approach just insane, or is it more rational than my original thoughts suggest?

 

Keen to find some suggestion that can implicitly control 30+ pools over a handful on virtuals without a lot of manual work.

 

Thanks

 

Chris

 

application delivery
design
devops
iControl
iRules
LTM
performance

3 Replies

Sort By
  • David_Larsen_23's avatar
    David_Larsen_23
    Historic F5 Account
    Sep 18, 2014
    I would think the same thing. You would be placing a lot of work on the F5 to reselect. The LB can most likely handle it, but there should be better ways to do this. Are you doing monitoring on the pool members?
  • Chris_Phillips's avatar
    Chris_Phillips
    Icon for Nimbostratus rankNimbostratus
    Sep 19, 2014
    Yes, we're monitoring, but the monitors currently in action aren't up for messing with. Some form of aliased transparent monitor might work, no idea what it could look like though.
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Sep 19, 2014
    Do you have a list of conditions and requirements? I'm thinking if the farms are very easily distinguished, (assuming different subnet(s), you could use a fake uri path to set/unset the isolation to steer the traffic accordingly. Understanding what your environment looks like now (taking pools, pool members, or nodes out of service, or some combination of the three?) would be helpful to recommending a solution