An f5 health check will drop the member from the pool, thus stopping all traffic to it. It's a bit more extreme than an alarm for an administrator to check. The goal with the health check is to add/remove pool members based on whether or not they work and to do it quickly (within seconds or faster) with the goal of minimizing user outages.
I considered making the aravail program network aware so that it could process requests from the f5 LTM, but this still introduces a middle layer that, in principal, should not be there. On Mon, Oct 31, 2011 at 12:44 PM, Doug Blair <d...@blairing.com> wrote: > Look at is this way.... > > If the web works, the AR server works and the database works too, and all > is well. If the web doesn't work, the AR server might still be functional, > but in any case you have to go investigate it :-). Not perfect for > metrics, but good enough for administrator's alarms. > > Doug > > -- > Doug Blair > +1 224-558-5462 > > Sent from my iPad2 > Auto-corrected typos, misspellings and non-sequiturs are gratefully > attributed to Steve Jobs :-) > > On Oct 31, 2011, at 10:14 AM, patchsk <vamsi...@gmail.com> wrote: > > > ** Thanks Doug, but we can use this only when we are 100% web. > > We do not want to tie the app load balancing with web. > > Because we still have some users using the client, so there are > scenarios where a web maynot work but the app could still be working.. > > Also we are not always sure that our midtiers will always be pointing to > different ARS servers. > > > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
