|
Michael,
Thanks for your input, I'm getting prepared to start working towards some
more solidifed implementation plans. I didn't even consider the possabilty
of overflow buckets, I guess I assumed it was a hard limit. I wonder if the
overflow buckets have some limit to their total size thus leading to a soft
limit followed after a given number of connections to a hard limit. My real
intrest in the LVS is to avoid purchaseing a Cisco LocalDirector, which as I
understand it has something of a maxconnections command which will limit the
total number of connections to the cluster. It would also be nice to one up
the local director with some sort of connection status checking code before
hashing the entry which would, if the currently handled connection is
greater than a set limit, redirect it to a different service then the one
requested, informing the user that the cluster has currently reached it's
max load. Perhaps the service handling the max load could also inform the
user of the expected time delay before he/she should attempt to connect once
more? Perhaps the LVS code LC/WLC algroithm could be adjusted to do the
connection status checking and redirection? Perhaps I ask too many
questions? Does the last question support itself? Did that one?
P.S. This is question is for Michael:
I don't know if you are the one to ask but what do forgin( I'm in America )
Universities( in the UK perhaps Manchester ) think of American students
looking for enrollment in undergrad/grad school?
----- Original Message -----
From: Michael Sparks <zathras@xxxxxxxxxxxxxxxxxx>
To: Ty Beede <tybeede@xxxxxxxxxxxxx>
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 02, 2000 4:52 PM
Subject: Re: [lvs-users] IP management & LinuxDirector
> Ty,
>
>
> I can't answer most of your questions, (*) but can perhaps help on
> speaking up for the reliability part of the LVS director code. We're
> currently shipping about 36 million HTTP requests per day through a bunch
> of cache boxes load balanced by 2 LVS directors. Since we've been running
> these systems, we've experienced zero downtime due to the LVS director
> code.
>
> Put it this way - if you're planning to load balance a system that will
> need to balance a billion or more HTTP requests per month, LVS is
> *definitely* up to the job.
>
> I'd compare the stability of the unmodified LVS code to that of a
> router/hub based on this.
>
> (*) I think you're under a mis-apprehension though - the number set in the
> kernel config of the table size beinga power of 2 isn't a limit on the
> numbers of concurrent connections, it relates to a hash table, which I
> presume has overflow buckets, because during our test phase the number
> of concurrent connections through the director exceeded this - which
> presumably meant overflow buckets got used. (We're now running with a
> much larger table size :-)
>
> I may of course be *completely*, and utterly wrong here, since I
> didn't write the code, and have only passed a highly curious eye over
> it to see how it could be extended in other ways :-)
>
> I suspect some of the the changes you're requesting are possible and would
> be useful in many contexts. (eg during failover scenarios)
>
>
> Michael.
> --
> National & Local Web Cache Support R: G117
> Manchester Computing T: 0161 275 7195
> University of Manchester F: 0161 275 6040
> Manchester UK M13 9PL M:
Michael.Sparks@xxxxxxxxxxxxxxx
>
>
> ----------------------------------------------------------------------
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
