Beowulf Questions

[Mark Hahn]

> > > Some companies will setup their own, internal distribution/grids - think of
> > > Walmart - and inside the company they'll deal with however the cost recovery
> > > method needs to work. Others will get it from the big boys - you'll want 
> > 
> > OK, this is the "Grid is a batch/queueing system with elaborate accounting"
> > explanation - exactly my understanding of grid ala Globus.
> > 
> > I don't really understand the appeal of this: on my clusters, I want users
> > to have actual user accounts, and to write, tune and compile their programs
> > for  the cluster's specific hardware, running them under the cluster's 
> > resource management (queueing/batch/accounting) software. 
> 
> Do you really think that's what your users want, though?

yes, I KNOW they do.  why?  because it makes for efficient use of the
cluster.  OK, so I add to my list of grid premises: assume cycles are 
cheap and efficiency is not important.

there's nothing wrong with genericity that preserves efficiency.
the problem is that genericity often implies a noticable loss there.

> And what happens when
> they need more compute power than you can give them, and want to use a 128
> node cluster instead of a 64 node cluster? They go to a different cluster and
> learn everything again?

you seem to have users who have loosely-connected, non-compute/ram/io/ipc
intensive programs.  you're right: for them, grid is going to be great.
for my main machine, the priority is specifically to run tightly-coupled,
compute and memory-intensive, long-running codes.  for that class of
problems, grid is just a toy.

> > AFAIKT, the grid
> > approach would have them running sandbox'ed, interpreted java programs on a
> > generic proxy account.
> > 
> 
> Nothing in grid computing says that it's any sort of generic account - all
> authorization to use a resource is entirely up to the resource owner - if they
> want every user on the resource to have an actual, seperate account they can.
> If they want everyone to share a generic account they can. There's a seperate
> mapping of "grid identities" to local unix accounts, for systems that it
> makes sense on.

so what does it buy?

> And who said anything about grid computing requireing interpreted Java 
> programs? If you wanna run x86 code go ahead and do so, provided you've got
> access to some x86 resources.

OK, I'm puzzled now.  how does a grid user do that?  he doesn't even know
what machines the code is going to run on, whether it's got 3dnow or sse2,
etc.  not to mention libraries, etc.

maybe I'm totally confused.  you seem to be saying that grid will 
provide something new.  users still have to ssh in to an account
that I still have to make for them.  they still have to use our 
queueing system, and obey our resource limits.  grid gives them what,
just a plugin that lets them have a meta-scheduler across multiple
clusters?

> > OK, so grid is just cycle scavenging with its own meta-queueing,
> > its own meta-authentication and its own meta-accounting?
> 
> It's not cycle scavenging. 
> It's a standard way of talking to queuing systems.

ah, that's all.

> It's strong authentication and a seperate authorization step

ah, interesting.  I know Globus uses its own random/nih PK infrastructure,
but is it in some way better than the standard (ssh)?

> Accounting is accomplished however it makes sense for the resource owners who
> have put together that grid.

if accounting is separate, it sure looks like a cycle scavenger to me.
oops: "cycle harvester".