IBM goes grid

Fri Aug 3 07:46:51 PDT 2001

	Correct me if I'm wrong, but isn't the grid starting as a
supercomputing center initiative?  Not a spare CPU cycle harvester like
SETI at home, but a way of processing batch jobs on combined supercomputing
platforms.  This kind of limits the security problems being discussed so
far.  The internet2 is probably being used for communication, so that
should also help somewhat with security.  Of course it won't be
impervious, but every supercomputing center tries it's best to put up a
"sandbox" anyway.  I'm sure beowulfs at larger centers will be included,
but I imagine it will be a long, long time before general desktop
machines on the internet get added (if ever).
	So far distributed computing takes on two veins: controlled clusters
(which I'd call parallel computing, but many people reserve that for
single machines), and web-based codes.  I especially noticed this when
talking to my graduate advisor and we had a bit of a semantic difference
(other than the Indian - American thing) when I said I was interested in
parallel computing, and he said he only did distributed computing.  I
said Beowulf, he said he'd consider that to be distributed.  Anyway, my
point is that the grid is a great way to start merging these two
distinct sections of distributed/parallel computing.  They really are
taking the best path starting with trusted supercomputing centers and
migrating from there.
	By the way, the initial e-mail said that the grid vision is for
everyone on the internet to have the power of a supercomputer.  That's
not right.  I don't want every Joe Blow's bomb building codes (or kiddie
porn) running on the internet (and my computer), and neither do the
founders of the grid (I hope).  I think what they mean is that anyone
with a connection could potentially use the power of a supercomputer
(assuming their password is validated).  But doesn't that already exist
with say ssh and to a supercomputer site?  I think really what they have
in mind is a new "mega-computer" that incorporates many super
computers.  What do you think?

"Robert G. Brown" wrote:
> 
> On Thu, 2 Aug 2001 john.hearns at framestore.co.uk wrote:
> 
> > Or the use of remote archives of 3D medical datasets via fast links.
> > Blue skying, a physician would be able to call up a series of known
> > diagnosed cases of a certain pathology on his workstation,
> > and have the data transferred (with suitable anonymity) to it.
> > Or could submit computationally demanding tasks, like cancer treatment
> > planning, to a fast central compute resource.
> 
> Sure, one can imagine lots of users.  But.
> 
> > > The first one that comes to mind is overwhelmingly security.
> > Absolutely.
> > How do you authenticate someone from a partner institution who
> > wants to use CPU on your farm, or access data in your silo?
> > Efforts are currently underway in areas like this.
> 
> The problem is that I doubt that it can be done globally.  Ever.  I
> think that you are on the wrong side of a critical regime in complexity.
> The only two solvable limit points that I can see are:
> 
>   a) Universal "Trust".  Presuming that one can build a truly secure
> sandbox on a per-system basis (which I believe to be possible but not
> necessarily easy or robustly secure as kernels and libraries evolve), I
> can see a kernel which always allows its system's surplus resources to
> be used by basically anybody on the Grid perhaps weighted by a project
> choice matrix ("I want my computer to be used to help beat cancer") or
> ("No distributed games, please").
> 
> It will be spoofed, abused, misused, and there will be a constant
> policing problem that will probably need to be mostly ignored.  We all
> agree that our front yards are part of the village green and just grit
> our teeth and bear it when the cows come in to graze or folks decide
> to make a temporary mudbath there for the pigs.  Obviously laws would
> have to be passed protecting participants from liability or criminal
> culpability when somebody uses their front lawn to launch surface to air
> missiles at passing jets or to hawk stolen goods or to put on an open
> air striptease.
> 
>   b) Universal "Mistrust".  STILL presuming that one can build a truly
> secure sandbox, have only a very small handful of projects that are
> "approved" to run within, hire vigilantes to guard the projects,
> legalize some medieval tortures applied to those that compromise their
> sanctity.  This is close to what one has now with SETI and RC5 but
> without the medieval tortures -- participants can only hope and pray
> that the RC5 and SETI vigilantes are successful in keeping out vermin
> who might (for example) slip a few hundred line loader into the code
> that on (pick a date) goes to (pick a site), grabs a carefully crafted
> softbomb, and loads/runs it.  Even the vigilantes might miss such a
> small thing in a really big application, and by loading the real bomb in
> real time all sorts of virus software can be circumvented.
> 
> By mistrust here I obviously mean that the public only trusts particular
> projects to be runnable universally, and those projects are subjected to
> an extraordinary (and expensive!) degree of scrutiny to keep them
> secure.  Even so, this sort of operation will only last until the first
> time SETI or RC5 areused as a cracking/viral insertion mechanism at
> which point trust for this sort of thing will evaporate and their
> success at harvesting cycles will quickly be forgotten.  Perhaps two
> projects can be kept secure enough that this is "unlikely" to happen.
> Perhaps five can.  Fifty cannot.
> 
> In between, the only solution that I see requires restricting the grid
> to a domain where authentication and job validation are possible and
> where users (and their jobs) are hence knowable and can be held
> accountable.  Universities sure.  Businesses sure.  Public research
> centers maybe.  Collectives of Universities and/or businesses or
> centers, possibly, but the probability of mishaps grows inexorably as
> you expand the pool of participants and dilute the direct administrative
> control you have over any one of them across "natural" adminstrative
> boundaries between organizations.
> 
> I see nothing surprising in turning a University's compute resources
> into a giant compute cluster -- I did it myself with Duke's public
> cluster using rsh, a shared AFS filespace, and a standard account seven
> or eight years ago and harvested a few GFLOP-years of cycles back when
> this was a LOT of computing.  Nowadays there are better tools for every
> step of this -- ssh, PBS, Condor, and more -- within an administrative
> domain.  I don't see the entire Internet (or any significant
> cross-section of it that crosses administrative authentication domains)
> becoming a giant compute cluster anytime soon, if ever, except in one of
> the two limits above.  It would require something truly fasicist to
> create a personal authentication namespace that spans the globe...
> something like get your driver's license, universal network
> account/license, and hardware authentication device all at the same
> time...(maybe even on the same card).  Shudder.
> 
> > I agree. I wonder how useful the 'traditional' model of
> > a departmental Beowulf, with the compute nodes 'hidden' on a private
> > network
> > behind a dual-headed master compute node will be to
> > these farms which need lots and lots of access to data stores, and data
> > stores that are potentially across WAN links at that.
> 
> This is the interesting question, of course.  A grid concept turns a
> beowulf "inside out" in some sense.  A grid more like a natural
> extension of a NOW to an CONOW (collection of NOW) and one would
> expect/prefer that the systems in some sense all be "publically
> accessible" rather than compute nodes simulating an SMP computer.  Of
> course a grid is only useful for extremely coarse grained to
> embarrassingly parallel tasks (in the outer regions of the Amdahlian
> speedup scaling equations where communications is all but negligible
> compared to computation) while a beowulf is designed for coarse to
> moderately fine grained work.
> 
> Still, one would like to be able to recover the wasted cycles in true
> beowulfs as well as in more general NOW-style clusters and compute farms
> (where the nodes support a shell and shared filesystem, if we can now
> begin to use this to distinguish at least Scyld-like beowulfs from
> sloppier clusters).  At any rate, I'll look over the resources you so
> generously include below (and others sent to me offline) and see what I
> can put together for Duke, as I have neither time nor inclination to
> reinvent wheels if I can avoid it.  Thanks loads.
> 
>    rgb
> 
> >
> >
> > You can do worse than start with the pages of the European datagrid:
> > http://www.eu-datagrid.org
> >
> > And the Globus project http://www.globus.org
> >
> > For those who haven't met it,
> > "The Grid: Blueprint for a new Computing Infrastructure" is IMHO
> > the canonical work in the field.
> > http://www.amazon.com/exec/obidos/ASIN/1558604758/qid=996769001/sr=2-1/ref=aps_sr_b_1_1/102-0420104-7691336
> >
> >
> > > Seems like a useful project for some grad students in CS departments
> > > that concentrate on cluster computing, e.g. Clemson.  Walt?  Anybody?
> >
> > Being cheeky, if anyone knows of interesting jobs in this area let me
> > know.
> >
> >
> > John Hearns
> >
> 
> --
> Robert G. Brown                        http://www.phy.duke.edu/~rgb/
> Duke University Dept. of Physics, Box 90305
> Durham, N.C. 27708-0305
> Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

-- 
Jared Hodge
Institute for Advanced Technology
The University of Texas at Austin
3925 W. Braker Lane, Suite 400
Austin, Texas 78759

Phone: 512-232-4460
Fax: 512-471-9096
Email: Jared_Hodge at iat.utexas.edu