Re: History of term "Grid Computing"
- From: "Henry" <torty5737@xxxxxxxxxxx>
- Date: 31 May 2006 16:23:15 -0700
David DiNucci wrote:
Henry wrote:
David DiNucci wrote:
[Silly acronyms for GRID]
:)
I guess it reveals more than I'd like that most of mine end in
"...is DOOMED!".
Just in case anybody who pays me money reads this thread, I'll
sneak a gratuitous claim in here that "scurrilous" acronyms are
by definition bound to overstate the case.
I'd be interested to hear your perspectives. For example, if "is
doomed" really reflects your thoughts, I presume that for some
definitions of grid (e.g. grid = cluster), you don't believe this, so
what is the "least complex" definition of grid that you feel "is doomed"?
My general view is roughly covered by my suggested acronym
(which Google now refuses to show me, even though it posted
it twice!) along the lines of
"Great Research; Implementation Disaster" -
where "disaster" may be too strong (see above) and "research"
should really be "idea" or "concept", but it's an acronym...
My perspective comes from involvement with running a production site
within a large, global Grid project.
Thanks to some (old and new) friends, I had the opportunity to hover
about at the SC'05 conference in Seattle last year, where I ran into
some people who were heavy into grids about the same time I was ('97,
'98), and I heard some discussion about how they now believed their
sights had been set too high.
My feeling is that the difficulties of actual deployment of a platform
useful to end-users have been grossly underestimated. People tend
to think of scalability issues as "will we need to track more than 255
of those", but there is a whole separate set of difficulties involved
in trying to get software correctly deployed by sysadmins around
the world (whose native language may not be English) with often
poor documentation, on a variety of hardware and software platforms
(neither "Windows" nor "Linux" exist), with differing network
connectivity, access and firewall technology and even with differing
personal or institutional priorities to getting things working.
It doesn't help that the thing is very interconnected so that resources
all have to talk to each other, so misconfigured sites can affect
others directly (as well as the usual "black-hole" problem).
(Compare with e.g. BOINC where there is a single server, and a
client is either successfully connected or not).
Note that the original Arpanet project (before my time) expressly
tried to avoid this by centrally issuing identical interface nodes
(TIP?) to each site.
I'm not sure of the extent to which the Architecture makes this
problem worse - I think deployment is just naturally Very Hard.
A second problem is that the Grid is implemented as a stack of
layers of middleware, which is probably the Right way: if a
particular layer or service has scalability or functionality problems
then it can be replaced by something else. (It doesn't help that
as actual users start using the thing, they find that they actually
want to use it in a totally different way to what was expected.)
Except "Something Else" will be closer to developer code (and
developer documentation!) and will take a while to get deployed
consistently _correctly_ - I would budget 1 or 2 _years_ for this,
and that's a loooong time in Grid projects.
So we end up with a lot of subtly different sites trying to install
stuff we don't really understand!
The problem with this: if user jobs are to succeed > 90% of
the time, how reliable must every layer[*] and every step[**] in
the process be?
I'm not sure what a "less complex" Grid would look like - if
you take out the many sites around the globe aspect (or
"spanning multiple administrative domains" in fancy-speak)
you get back to batch-queueing jobs among a local group
of systems - i.e. the 1960s!
[IMO the single key concept behind "Grid Computing" is
the Virtual Organisation - this notion encapsulates both
single-sign across real organisations/resources and also
lots of collaborative possibilities.
The cynic would still point out that it's just Unix' groups
writ large!]
The problem or challenge is to get all the interconnectedness
to work, reliably and usefully.
Hth
Henry
* User submits job: needs information system to find resources,
matchmaking to pick one, job transfer to resource e.g. GRAM,
maybe local queueing and transfer to execution node,
job progress monitoring...
** A user executable starts running on a node. The first thing it
may want to do is locate and download input data: a whole
separate Grid transaction.
.
- Follow-Ups:
- Re: History of term "Grid Computing"
- From: David DiNucci
- Re: History of term "Grid Computing"
- Next by Date: Re: Testing of distributed systems.
- Next by thread: Re: History of term "Grid Computing"
- Index(es):
Relevant Pages
|
|
