Recently, Chris Tyler <chris @
dejong .
com> wrote:
=>
=> Gregg Williams wrote:
=>
=> > When your web browser connects to home.netscape.com, you actually
=> > get home1.netscape.com or home2.netscape.com or home3...
=>
=> This can be done with URL redirects. Configure your master home page to be a CGI
=> script that returns a redirect to the home page on the appropriate server. For
=> example,
=>
=> http://www.company.com/ --> CGI script that returns a URL
=> redirect to one of www1.company.com, www2.company.com,
=> or www3.company.com
=>
=> This script could return the URL randomly, or in rotary fashion (www1 the first time,
=> www2 the second, etc), or it could be more intelligent and go out and see which
=> server(s) had the lightest load. You could also make it check that the server was
=> "up" and that it was not undergoing maintenance (e.g., page updating). One problem
=> is that users will tend to hotlist or bookmark files on one specific server, so that
=> eventually even a sequential or random URL redirection may not balance the load
=> properly... thus it's best to check actual load. Round-robin DNS will solve this
=> bookmark problem, but it won't detect when you take a server down and it won't
=> always accurately balance the load.
I have reservations about such a DNS solution, use of short time-to-live A records
is considered bad for because of the excessive network (DNS/ARP) overhead it adds.
On the other hand, it is a royal pain to parse vmstat/sar/etc. to figure out what the
darned system load is. Even then, I haven't come up with a good way to make this data
readily accessible to the server. Any suggestions?
=>
=> Note also that in order to make the URL redirects work nicely, you'll need to
=> configure your server so that the master homepage can be a CGI script without some
=> awkward directory name in there (so the main URL is http://www.company.com/
=> instead of http://www.company.com/cgi-bin/homepage.html)... it might be easier to do
=> that with (say) Apache or Spider rather than something like NCSA httpd.
You may also want to consider use of a default file to be served, make doc-root a cgi
directory, and make the served file a cgi-bp. These options are available using Netscape's
products, and I *thought* that similar functions were available with the current version of
NCSA. As a security measure, I have architected all of my client's systems such that
doc-root is a cgi, and contains the default script. It makes use of wild-card certificates
a viable solution (with multiple Secure Servers, e.g. www*.foo.com). I force ALL of the Web
servers to load balance by forcing a URL redirect if there is another server *known* to
have less utilization (set the utilization deltas low so you don't end up pinging). This
dynamic load balancing becomes very important if you are using e.g. a Commerce server to
serve up files (i.e. where the Web server is sort of a fancy SSL-ftp server).
I am currently working on a client's solution where EVERY page is CGI'ed, and every cgi
program will load balance (wild-card'ed Certificates are used). This is complicated by the
fact that most of the server instances will be enqued on a reply from mainframe (CICS in
this case) systems.
=>
=> (You must have a pretty big pipe... or a slow machine... if your server and not your
=> pipe is your bottleneck!).
Or some pretty serial cgi's.
=>
=> Chris Tyler Chris @
DeJong .
Com CTyler @
Oxford .
Net
=> Systems Development Manager, Wm. De Jong Enterprises Inc.
=> +1-519-424-9007 / fax +1-519-424-2399
=>
Follow-Ups:
|
|
