<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Currently, im going on the following assumptions:<br>
<br>
1. Have a HTTP command for reporting load of backend servers<br>
2. Have a HTTP command for moving a backend OFFLINE (for testing of
load balancing mostly, but i can see this beeing useful for
maintainance)<br>
3. Have a HTTP command for moving a backend back ONLINE<br>
<br>
A command for adding backends dynamically seems illogical (remember,
this is all temporary data which is lost with a restart/reload). If you
want to add a new backend, add it in the config.<br>
<br>
Does anyone (except maybe google or something) have such a dynamic
pool, that you would want to add new servers dynamically on run-time?
Anyone need this?<br>
<br>
4. Have a HTTP command for getting weight statistics (ie, load on all
backend servers, weights on all backend servers, other) for monitoring
(munin, ganglia, etc)<br>
<br>
I don't exactly know how we will invoke the real load balancer, but i
suppose it will be with the 'real;' keyword, like the fair load
balancing<br>
<br>
upstream wwwbackend {<br>
&nbsp;&nbsp;&nbsp; real;<br>
&nbsp;&nbsp;&nbsp; server earth&nbsp;&nbsp;&nbsp;&nbsp; weight=20;<br>
&nbsp;&nbsp;&nbsp; server wind&nbsp;&nbsp; &nbsp; weight=20;<br>
&nbsp;&nbsp;&nbsp; server water&nbsp;&nbsp;&nbsp; weight=20;<br>
&nbsp;&nbsp;&nbsp; server fire&nbsp;&nbsp; &nbsp; &nbsp;&nbsp; weight=20;<br>
}<br>
<br>
Weights take a default value, but will be adjusted depending on the
load responses from backend servers.<br>
<br>
Discuss.<br>
<br>
Delta Yeh wrote:
<blockquote
 cite="mid:beffb2170807232210h7558f82cx5b699ac18b24926d@mail.gmail.com"
 type="cite">
  <div>how about store the backend server in memchached.</div>
  <div>so 3rdhparty tool can update the server status for nginx.</div>
  <div>But I don't know whether the performance is enough.<br>
  <br>
&nbsp;</div>
  <div><span class="gmail_quote">2008/7/24, mike &lt;<a
 moz-do-not-send="true" href="mailto:mike503@gmail.com">mike503@gmail.com</a>&gt;:</span>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">sorry
not "monitor that file" but MANAGE that file.<br>
    <br>
as in, keep a list of upstreams, and update the file, send HUP/etc to<br>
nginx after it's updated<br>
    <br>
On 7/23/08, mike &lt;<a moz-do-not-send="true"
 href="mailto:mike503@gmail.com">mike503@gmail.com</a>&gt; wrote:<br>
&gt; yeah you could have an<br>
&gt;<br>
&gt; include 'upstreams.conf';<br>
&gt;<br>
&gt; and some external process monitor that file, and then send a HUP or<br>
&gt; whatever the appropriate process signal to nginx is, but that
seems a<br>
&gt; little messy. it would be nice if nginx had support built-in for
the<br>
&gt; most graceful recovery/best user experience when an upstream dies<br>
&gt; (maybe it already does, i am just speculating)<br>
&gt;<br>
&gt;<br>
&gt; On 7/23/08, Istvan Szukacs &lt;<a moz-do-not-send="true"
 href="mailto:leccine@gmail.com">leccine@gmail.com</a>&gt; wrote:<br>
&gt; &gt; but if you store the upstreams in memory(very simple
structure) after the<br>
&gt; &gt; nginx restart, and remove the dead one(might be dead for some
reason)...<br>
&gt; &gt;<br>
&gt; &gt; monitoring should be configurable, what parameter and what
value...<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; mike wrote:<br>
&gt; &gt; &gt; for this to happen i believe<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; a) there needs to be a way to dynamically add/remove
upstreams (or at<br>
&gt; &gt; &gt; least mark them active/inactive) from an external call
to nginx daemon<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; b) monitoring has to be there, which could be built in,
or could be an<br>
&gt; &gt; &gt; external process. personally i'd be happy with an
external monitoring<br>
&gt; &gt; &gt; thing like ldirectord (some sort of healthchecking
script) that upon<br>
&gt; &gt; &gt; noticing a server being down tells nginx "stop this
upstream" etc.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On 7/23/08, Almir Karic &lt;<a moz-do-not-send="true"
 href="mailto:almir@kiberpipa.org">almir@kiberpipa.org</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; i'm kinda interested in implementing a true load
balancer functionality<br>
&gt; &gt; &gt; &gt; in nginx, my idea is to extend the upstream module
so that it would be<br>
&gt; &gt; &gt; &gt; able to dynamically modify the configuration of
servers (such as mark<br>
&gt; &gt; &gt; &gt; them down or change the weight) i see two possible
ways:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; - controlling socket over which you would feed the
commands<br>
&gt; &gt; &gt; &gt; - UPSTREAM method (similar to ncache's PURGE), the
advantages of this<br>
&gt; &gt; &gt; &gt;&nbsp;&nbsp;being easier control of configuration file and no
need for a dedicated<br>
&gt; &gt; &gt; &gt;&nbsp;&nbsp;thread to listen on the socket<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; the idea is to implement just the controling
protocol in nginx, it would<br>
&gt; &gt; &gt; &gt; require some controling daemon/script to actually
do anything useful.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; thoughts? advices?<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; also any chance of this kind of code making it to
official nginx?<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; --<br>
&gt; &gt; &gt; &gt; vi vi vi -- the number fo the beast<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
    <br>
  </blockquote>
  </div>
  <br>
</blockquote>
</body>
</html>