true load balancer

[Delta Yeh]

how about store the backend server in memchached.
so 3rdhparty tool can update the server status for nginx.
But I don't know whether the performance is enough.


2008/7/24, mike <mike503 at gmail.com>:
>
> 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080724/3f2c572d/attachment.html>