Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: domain of minfrin@sharp.fm designates
 64.49.220.200 as permitted sender)
Message-ID: <44829.196.8.104.31.1154363186.squirrel@www.sharp.fm>
In-Reply-To: <1154362594.7894.66.camel@cal.cotef.org>
References: <65FEF6CD-73FC-4427-9940-D552FB458688@jaguNET.com>
    <1154356149.7894.39.camel@cal.cotef.org>
    <47512.196.8.104.31.1154357647.squirrel@www.sharp.fm>
    <1154360559.7894.53.camel@cal.cotef.org>
    <33199.196.8.104.31.1154361785.squirrel@www.sharp.fm>
    <1154362594.7894.66.camel@cal.cotef.org>
Date: Mon, 31 Jul 2006 18:26:26 +0200 (SAST)
Subject: Re: load balancer "cluster" set
From: "Graham Leggett" <minfrin@sharp.fm>
To: dev@httpd.apache.org
Cc: dev@httpd.apache.org
User-Agent: SquirrelMail/1.4.6-7.el4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

On Mon, July 31, 2006 6:16 pm, Guy Hulbert wrote:

>> At the network layer, your metrics are pretty much "volume of data" or
>
> Nope.
>
> Routers can look at anything in the packets which is not encrypted.
> They can also measure server response (by packet stats) directly or via
> SNMP.  There are all sorts of things that *cannot* be done on the server
> without introducing all sorts of p2p communications requirements.

I'm sure they can. This doesn't make them the right solution for all cases.

In a multi tier architecture, you already have front end servers
implementing URL strategies, common logging, all sorts of other things.

Adding an extra router layer to handle load balancing, when your already
existing frontend can do this job is not only extra cost, but extra
complexity and an additional point of failure.

Regards,
Graham
--