true load balancer

[mike]

yeah you could have an

include 'upstreams.conf';

and some external process monitor that file, and then send a HUP or
whatever the appropriate process signal to nginx is, but that seems a
little messy. it would be nice if nginx had support built-in for the
most graceful recovery/best user experience when an upstream dies
(maybe it already does, i am just speculating)


On 7/23/08, Istvan Szukacs <leccine at gmail.com> wrote:
> but if you store the upstreams in memory(very simple structure) after the
> nginx restart, and remove the dead one(might be dead for some reason)...
>
> monitoring should be configurable, what parameter and what value...
>
>
> mike wrote:
> > for this to happen i believe
> >
> > a) there needs to be a way to dynamically add/remove upstreams (or at
> > least mark them active/inactive) from an external call to nginx daemon
> >
> > b) monitoring has to be there, which could be built in, or could be an
> > external process. personally i'd be happy with an external monitoring
> > thing like ldirectord (some sort of healthchecking script) that upon
> > noticing a server being down tells nginx "stop this upstream" etc.
> >
> >
> >
> > On 7/23/08, Almir Karic <almir at kiberpipa.org> wrote:
> >
> >
> > > i'm kinda interested in implementing a true load balancer functionality
> > > in nginx, my idea is to extend the upstream module so that it would be
> > > able to dynamically modify the configuration of servers (such as mark
> > > them down or change the weight) i see two possible ways:
> > >
> > > - controlling socket over which you would feed the commands
> > > - UPSTREAM method (similar to ncache's PURGE), the advantages of this
> > >  being easier control of configuration file and no need for a dedicated
> > >  thread to listen on the socket
> > >
> > >
> > >
> > > the idea is to implement just the controling protocol in nginx, it would
> > > require some controling daemon/script to actually do anything useful.
> > >
> > >
> > > thoughts? advices?
> > >
> > > also any chance of this kind of code making it to official nginx?
> > >
> > > --
> > > vi vi vi -- the number fo the beast
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>