[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Re: [Ltsp-discuss] New LTSP + openMosix How-To

--- Hans Ekbrand <hans sociologi cjb net> wrote:
> On Sat, Nov 23, 2002 at 11:45:48PM -0800, James Jensen wrote:
> > --- Utsav Pardasani <pardasaniman yahoo com> wrote:
> > > Hello friends.  I am thinking of including openmosix on our network
> with
> > > LTSP.  
> > > 
> > > My possible clients are a group of 166Mhz machines.  What sort of
> setup
> > > would cause openMosix to
> > > give a boost over the standard K12LTSP setup.
> [...]
> > >  If a machine is runnning a
> > > process, for another,
> > > will that process be nullified if that machine is shutdown?
> > 
> > Yes & no, I've done some limited testing, forcing processes to run on
> > specific nodes (LTSP clients) and then just dropping that node by
> powering
> > it off.  In most instances, since the process has vanished with the
> node
> > you will see it hang on the system the lost node was running it for. 
> > Strangely, at other times it keeps right on going.
> Have you asked on the mosix lists how that can even happen?

No, not yet anyway.  In reality it can't happen.  Per Moshe, if a node
shuts down cleanly--no problem.  If it shuts down hard (power failure,
etc.) then the processes the node is running are gone...

> > > Basically my question is --> Is is a good idea to use openmosix in
> > > diskless environment.  If not,
> > > what is it meant for?
> > 
> > That depends on what you are trying to do.
> > 
> > 1. Cluster everything (server & clients) in a user production
> environment? 
> > I would say no (as much as that pains me to say).  Not unless you're
> > positive regarding the impact of client nodes dropping out of the
> cluster
> > on the rest of your clients...
> If you have really fast clients, consider using local apps (not local
> drives!) instead.

Why?  Because OpnOff and/or Mozilla don't migrate (or migrate well)?  Moshe
addressed this a few weeks back.  Forget the magic of migration for
migrations sake.  It's the *overall* load balance of the cluster that is
the important factor.  And, this is something that can be measured and
quatified--for instance, if you are using openMosixview (cluster

Still, your suggestion is a viable alternative when you do not want to
cluster the clients with the server(s)...

> > 2. Balance the load on the backend, the LTSP server in a user
> production
> > environment?  My answer is yes!  This can be achieved quite easily. 
> And,
> > since no one had better be turning off your servers you won't lose
> migrated
> > processes.
> Note that most applications in the "desktop-productivity" class (OO,
> Mozilla comes to mind) will tend to not migrate. Actually I THINK OO
> and Mozilla CANNOT migrate because of issues with shared memory. In
> any case should programs that use much user "realtime" I/O (screen
> refreshs, sound etc) be *slower* if they do migrate. (Please correct
> me if I am wrong here James).

I am happy to report that upon inquiring on openMosix network overhead (a
question that visits us frequently on this list) the response is a positive

Moshe Bar wrote, "...special care was put into making sure that overhead,
network or otherwise, does not increase as you add nodes. In other words,
you have the same overhead with 2 nodes or 2000 nodes. Network traffic is
in all cases, ie worst case, limited to no more then 2% of bandwidth.
Independent tests and benchmarks by research institutions confirm this."

> Investigate wether or not the applications the users will run will
> actually migrate or not before investing too much in openMosix.

Yes, and post your findings so they can be added to the main How-To!  While
I have reached the tentative conclusion that clustering clients with the
server(s) is probably not a good solution (unless you can gaurentee that
the users won't just hit the ol' power button on their client systems when
they want to quit), clustering the backend machines, IMHO, is still an
avenue worthy of exploration.

James Jensen
live free() or die()

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]