[ic] Cluster and/or load balancing question

John Beima interchange-users@icdevgroup.org
Sat Jul 13 13:49:01 2002


Quoting Dan Browning <dbml@kavod.com>:

> At 08:46 AM 7/11/2002 -0400, you wrote:
> >On Thu, Jul 11, 2002 at 07:20:46AM -0400, Bill Carr wrote:
> > > On Thu, 2002-07-11 at 04:19, Joachim Leidinger wrote:
> > > > Hi List,
> > > >
> > > >
> > > > I've searched for any answer in the mail archivs to get a right
> > > > using/installation/configuration of IC with 2 servers as a cluster
> and
> > > > later with a load balancing solution. But I'm unsure about the right
> way
> > > > to the solution.
> > > >
> >
> >...
> > >
> > > I use a LVS-DR setup like this:
> > >
> > >           Internet
> > >              |
> > >         ----------
> > >         | LVS-DR |
> > >         ----------
> > >              |
> > >       ----------------
> > >       |              |
> > > ------------    ------------
> > > | www/ic 1 |    | www/ic 2 |
> > > ------------    ------------
> > >       |              |
> > >       ----------------
> > >              |
> > >         ---------------------
> > >         | MySQL/NFS Server  |
> > >         ---------------------
> > >
> > > I would start with this and once you get something like this working
> > > consider load balancing or replicating your database. You will have a
> > > single point of failure in your database server so through your best
> and
> > > most sturdy hardware at it.
> > >
> > > Please go for it and become an expert. I think that there is only
> myself
> > > and Dan Browning that run any kind of rig like this now.
> > >
> >
> >I'm curious as to what level of activity justifies load balancing?
> >Or are you doing it just for redundancy?
> 
> For us, the nature of the application required a lot of processing power 
> per user, but it would have been done anyway for the redundancy (or reduced
> 
> failure percentages anyway).
> 
> >I'd think NFS would cost you more performance in the above setup than it
> >would be worth vs more beef for handling session files.
> 
> We use MySQL for sessions, and it seems really fast.


Dan, have you thought of posting how to use MySQL for sessions instead of the
traditional method? That alone would help many people with clustering issues.
Getting the sessions off the hard drive of one machine and into an SQL server is
most peoples breaking point.

I had spoken with Mike about this a long time ago...

He mentioned his method was to have an Apache server up front. It would take the
http requests and hand off new requests to a session server. That server would
issue the session number. Then the client was handed back and forth between all
the Interchange servers, since they all shared a common session database. You
just needed to go to the main session server first. Then, if I recall correctly,
he had a MySQL server as well. Depending on the needs.

So to sum it up. One Apache server, one Interchange initial session server,
several Interchange servers, and one MySQL server.

With that model, if you stepped it up to say 2 MySQL servers. One for sessions
and one for the Interchange tables, you could have a nice little boost as well.
Again the only thing would be to publish how to use MySQL for the sessions as
opposed to the default methods.


> >One might also consider separating www/ic into two machines.  We don't
> >use apache on our vanilla sites; where we do, it's a mod_perl, mod_ssl,
> >mod_rewrite behemoth with all the bells and whistles
> >and that really hammers a machine compared to WN or Roxen.  A straight
> >version might be a lot easier on the machine, I'd guess.  We've found
> >separating those mod_* apaches from ic makes a huge difference.  YMMV.
> >
> >
> >cfm
> 
> Yes, I agree.  There has also been a lot of work done in 4.9 to reduce 
> memory footprint (including Mike Heins' great tag breakout as well as Jon 
> Jensen's mod_perl integration).  Separating out IC, http, and db are always
> 
> good measures for performance improvement, however.
> 
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | Dan Browning, Kavod Technologies <db@kavod.com>
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users@icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>