What will happen if the client's DNS caches the domain name to an IP, which
is then dead  ? If I understand it corrently, the current system can work
only if there is something like NAT in front of the machines, which
dynaimcally forward each request. Won't it ?


Peter Bi


----- Original Message -----
From: "Medi Montaseri" <[EMAIL PROTECTED]>
To: "Andrew Ho" <[EMAIL PROTECTED]>
Cc: "Benjamin Elbirt" <[EMAIL PROTECTED]>; "modperl list" <[EMAIL PROTECTED]>
Sent: Wednesday, April 17, 2002 9:08 PM
Subject: Re: Sharing Variable Across Apache Children


> You had us going for a while....I thought you are talking about some
> distributed
> session management (accross different boxes)....
>
> Another suggestion is to use lbnamed. lbnamed is a DNS server and Load
> Balancing
> server that listens to port 53 and resolves IPs, but on the other side of
its
> personality
> it talks to bunch of agents who are running on workers. You get to set
what
> the
> parameters or criteria is and assign a cost factor for a worker. lbnamed
then
>
> distributes the work on the lightest/least cost worker.
>
> In this scenario, whence a box is out (or its critical piece like Oracle,
or
> HTTP server)
> then no further work is routed to it .
>
> Also, be aware that using CNAME in DNS does not provide a uniform
> distribution
> of load. Imagine a web page having 20 images and another 5 images. You'll
not
> know
> with good certainty that if your heavy work like database access is really
> being
> distributed. With CNAME you do have a chance of developing harmonics.
CNAME
> (aka round robin) is totally unaware of the load on the worker. Maybe
that's
> why
> your boxes are bulking....
>
> See http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html
>
>
>
> Andrew Ho wrote:
>
> > Hello,
> >
> > BE>Let me explain in more detail what I'm doing.
> >
> > So if the situation you explain is the only reason you want a variable
> > shared load balanced machines, I'd suggest a totally different way of
> > doing this altogether. Best would be to use an already shared persistent
> > storage mechanism (NFS or Oracle) but it looks like Oracle warnings are
> > precisely what you want distinct alerts on (why are you getting so many
> > Oracle errors anyway? that might be the first thing you want to check).
> >
> > I'm assuming the number of warning e-mails you get is less than 450,000
/
> > 5 == 90,000 each day, so that if each warning e-mail were a web request,
a
> > single box could handle them (if more than 1/5 of your requests result
in
> > errors, you REALLY want to just fix the problem first). So put up a
single
> > webserver box to serve as an error reporter and logger. You could either
> > use distributed logging (like mod_log_spread) or simpler, just set up
> > another webserver that takes requests like
> > /record_error.pl?error_msg=foo&remote_addr=bar or whatever.
> >
> > Your error handlers on your five load-balanced boxes send an HTTP
request
> > to this error handling box. All error e-mails can originate from this
box,
> > and the box can internally keep a lookup table (using any of the fine
> > techniques discussed by the folks here) to avoid sending duplicate
errors.
> >
> > In this scenario error handling is offloaded to another box, and as a
> > bonus you can track the aggregate number of errors each day in an
> > automated way and run reports and such (without having to count e-mails
in
> > your inbox).
> >
> > Humbly,
> >
> > Andrew
> >
> > ----------------------------------------------------------------------
> > Andrew Ho              http://www.tellme.com/       [EMAIL PROTECTED]
> > Engineer                   [EMAIL PROTECTED]          Voice 650-930-9062
> > Tellme Networks, Inc.       1-800-555-TELL            Fax 650-930-9101
> > ----------------------------------------------------------------------
>
> --
> -------------------------------------------------------------------------
> Medi Montaseri                               [EMAIL PROTECTED]
> Unix Distributed Systems Engineer            HTTP://www.CyberShell.com
> CyberShell Engineering
> -------------------------------------------------------------------------
>
>
>

Reply via email to