Forum Discussion
Jason_Hook_4092
Feb 16, 2012Nimbostratus
We have an n-tier application architecture. The web tier/pools are the entry point to the environment. The catch is that we have 2 production environments that reside behind the same VIP. Currently, one pool of web servers (PoolId=1) is for our web products as a service bureau offering...and the other pool (PoolId=2) is for one specific client that requires us to have a separate set of servers (pretty much a mirror of the architecture that is behind PoolId=1) so there is impact isolation (they are paying to have their own in order to not be impacted if another of our clients add load in the environment that slows it down).
so, I have to still decide PoolId 1 or 2, but need to add additional logic to splid PoolId into more pools based on URI.
1) Client A would route to PoolId 1 as a service bureau client, but they are accessing /appX so they need to be on service bureau side (PoolId=1) and then web pool 1B that contains /appX.
2) Client A calls another application so they are routed to PoolId=1 again, but they are calling for /appZ which isn't defined to its own pool so it would be sent to the PoolId=1 default of web pool 1A
3) Client B is the "special" client and will be routed to PoolId=2 and only has a subset of the applications that service bureau has so they just get routed to web pool 2A as the default.
4) Client C is another service bureau client so they will route to PoolId=1 and then we need to check the /app? URI again to route to the correct PoolId=1 (service bureau n-tier stack) web pool.
Make sense?
At this time...there is no requirement to split another customer to their own set of servers (which would just be added as PoolId=3 if needed) so I'm not worried there.
I have the PoolID 1 or 2 working...I am open to suggestions on bettering that iRule as-is, but I need to add the 2nd part where I route the request based on URI...AFTER I decide what stack (PoolID 1 or 2).
I'm just not sure the "best" way to add this extra level of logic without making the iRule a sloppy mess of "if..then" or "switch" statements.
Suggestions wanted...