|
I was wondering if anyone had any suggestions as to the best way to setup a
redundant (no single point of failure) Load-balanced webserver environment
using LVS.
I was thinking something like this
2 LVS systems (for redundancy)
6 - 20 Webservers, pretty much the same specs
2 File servers (NFS) with replication
(Is this possible, I've looking into a lot of solutions, but I was wondering
if anyone has any experience with this)
(Is it possible to load balance Mysql, reading over NFS, or would I be in
better shape trying to setup two seperate DB servers with some sort of
replication?)
If I can't get the replication working, I may just buy a Sparc, and pray
that they are as stable as they are expensive.
(Advantages of the file servers is that It makes the Webservers a lot
cheaper (no need for RAIDs, or Big drives)
Also I was wondering if there were any plans for a CPU LOAD based
implementation of the LVS software, using daemons on the webservers, or if
you can change the weights (for the weighted round robin) in real-time, so
that we could write our own Pseudo CPU load balancing system..
Thanks in Advance,
Ben
----- Original Message -----
From: Joseph Mack <mack.joseph@xxxxxxx>
To: Lars Marowsky-Bree <lmb@xxxxxxx>
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, November 21, 2000 9:41 AM
Subject: Distributions with pre-installed LVS [was Re: regarding LVS for
DIRECT ROUTING configuration]
> Lars Marowsky-Bree wrote:
> >
> > On 2000-11-20T14:54:51,
> > Joseph Mack <mack.joseph@xxxxxxx> said:
> >
> > > Probably the single most often questions asked here are based on wierd
> > > errors that come from people doing multiple patches and not
understanding
> > > what they've done.
> >
> > People not reading manuals will not be easily cured.
>
> knowing this we should minimise the opportunities for and consequences
> of any mistakes they do make.
>
> RedHat has created a situation which makes them money and stops
> others from working on LVS. Any problem from a person
> with RedHat - can't compile, can't find modules, doesn't work,
> I have to read through and think about. I then have to make a reasonable
> guess as to whether this is a RedHat induced problem or a real problem.
> Presumably as the obvious problems get solved, it will be harder to
> separate the obscure problems from those added by distributions.
> Eventually fixing problems with LVS will stop and we'll only be dealing
> with distribution added problems.
>
> > > This is a large load on the mailing list and has stretched my patience
> > > with RedHat.
> >
> > I don't agree -
>
> you don't agree that this is a large load and has erased any good will
> I had towards RedHat?
>
> > what these people do will not work for _any_ patch, not just
> > LVS.
>
> This is why patches that change between kernel releases should be
> treated differently. LVS has been releasing about 2 versions for
> each kernel release for 2 yrs now.
>
> > If the distribution shipped reiserfs included, and they tried to patch
> > a newer release of reiserfs into that, that will break too.
>
> Does reiserfs have full releases between kernels?
> If so what do the people who answer questions in their own time about
reiserfs
> think about including it in the distribution?
>
> > > I really would like you to reconsider this. Having 2 distributions
that
> > > don't work for LVS would be more than I could bear. Could you instead
> > > include in the menuconfig scripts a routine that applies an LVS
patch - anything
> > > that will allow someone to patch your kernel with the current LVS
patch.
> >
> > Very unlikely. You have to understand that a kernel shipped by a
distribution
> > is patched with around ~100 patches or even more, so you can't "just
apply" a
> > patch as downloaded and expect it to fit in perfectly.
>
> I didn't know that individual distributions have that many patches.
> I've assumed that if the standard kernel is good enough for Linus and for
> me then it is good enough for most of us.
> I don't know the concerns and pressures that people who create
distributions.
>
> How many of these patches are from projects that have production releases
> between kernels.
> How many of them are small (<10 lines) bug fixes?
>
> > It would also be a nightmare to support, and compiling a kernel with all
the
> > necessary patches merged on their own is beyond the ability of most
users.
>
> agree.
>
> How many of these 100 patches are from projects with the functionality
> and support required for a project like LVS?
>
> > And we also want to have LVS available as a default component on a SuSE
> > system,
>
> no problem with that
>
> > so we have to include it in our kernel.
>
> could you put the patches in a contrib directory and have the patch
applied
> as part of the build?
>
> > Having LVS included will work fine for most people
>
> it's the other people that I'm concerned about.
>
> Any idea of the number of people who have got a fully functional LVS
> without asking a question on the LVS mailing list? I would imagine it
> is small, in which case "other" is really "most"
>
> > and ease their lifes. LVS
> > is at 1.0.0 now, so that makes a reasonable good time to include it in a
> > distribution.
>
> LVS has been production level for 2 yrs now, there is no sudden change in
> the quality, reliability or functionality of the LVS code just because it
> has gone to 1.0.0.
>
> > I would suggest that a specific comment is added to the LVS docs, about
how
> > you cannot just expect to be able to patch LVS into your distribution
kernel
> > without any problem, and that special care must be taken to make sure
you
> > apply and merge all the patches necessary.
>
> we tell people to drive carefully, have sex carefully and to choose
marriage
> partners carefully too. If you expect the SuSE users to be careful then
> you'll have to be prepared for SuSE users to find themselves
> in the computer equivelant of being killed, maimed, pregnant, having AIDS
> and divorced with traumatised children and paying their life savings to
> wealthy lawyers. I don't want to deal with these people.
>
> The number 1 thing with anything new, is to minimise the effect of
mistakes.
> It's not to maximise performance, money return... I have spent most of my
life
> living and working in situations with radiation, toxic chemicals, life
> threatening
> organisms, heavy machinery that can take your hands off, lasers that can
blind,
> rock climbing and spending long periods in wildernesses. Whenever I'm
introduced
> to a new
> situation, say a milling machine, the person first tells me all the things
that
> can go wrong, what the effects will be, what to do if things go wrong.
Sometimes
> they'll tell you how to use the machine, but usually you work that out
yourself.
> It's the mistakes that are important.
>
> Rather than SuSE easing the lives of its purchasers, I'd rather SuSE
> first minimised its impact on people developing the software that SuSE
uses
> and who are doing it in their spare time.
>
> I realise that you have to make money and that SuSE helps the Linux
> community and that we need you to succeed. I will not be happy with SuSE
> if you take the road that RedHat has taken here.
>
> > The best thing for the masses really is to have the distributions
provide the
> > kernel with LVS included, and provide an updated kernel if LVS fixes a
> > significant bug.
>
> there has only been 1 or 2 of these in the last 2 yrs. This is not a
> significant factor in deciding how to use LVS.
>
> Joe
> --
> Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
> contractor to the National Environmental Supercomputer Center,
> mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
