true load balancer

[mike]

sorry not "monitor that file" but MANAGE that file.

as in, keep a list of upstreams, and update the file, send HUP/etc to
nginx after it's updated

On 7/23/08, mike <mike503 at gmail.com> wrote:
> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>