Forum Discussion
Nimbostratusimplicitly 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
3 Replies
- 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_PhillipsYes, 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
Admin
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
