Two heads are better than one! :)

[Robert G. Brown]

On 31 Oct 2002, Dean Johnson wrote:

> On Thu, 2002-10-31 at 14:05, Robert G. Brown wrote:
> > 
> > The original >>beowulf<< concept was more like "the COTS cluster is the
> > supercomputer", and that is what scyld and the nasa goddard folks have
> > largely focused on, so most "true beowulfs" have a single head node, but
> > the strictly defined beowulf is far from the first or the only cluster
> > architecture.  Even in the early days, there were a number of linux
> > beowulfish clusters (that really did have dedicated, isolated nodes and
> > access only via head nodes) with more than one head node.
> > 
> 
> The closer you come to having all the nodes externally accessible (ie.
> like head nodes), the more it smells like a 'grid'.

Well sure, but remember that there were (if you like) "grid" computing
operations, even ones with dedicated software support, long before GRID
was even coined as a term.  We called brahma a "distributed parallel
supercomputer", which was definitely not as sexy as beowulf or grid;-).
And distributed parallel "supercomputing" itself predates brahma by many
years, at least back to the invention of pvm (which in many cases -- at
least my own case, but how could I be unique -- was used to run
grid-like master/slave computations over widely distributed networks and
resources), and I'd argue even further back to the invention of TCP/IP
and rsh, which I was using that way before I learned of PVM in about
'93.  Or even further As soon as there were systems connected with a
network with a remote execution protocol and with idle cycles, bottom
feeders like myself were lurking, ready to pounce:-) 

Note that I am not implying in any way whatsoever that I invented any of
this (I certainly did not) -- rather I'm just noting that all of this
was fairly commonplace whereever the local environment could support it,
and ours did starting in the late 80's.  Others with more money were
probably doing it on thickwire or serially connected sun 1 clusters or
dec vax clusters in the early 80's -- I dunno because back then I was
still enamored with DOS and my first IBM PC.

There are now a bunch of terms at this point for many of the cluster
variants which is great as it makes discussing them a bit easier, but it
is still important to remember that with any of the COTS architectures
YOU get to engineer YOUR cluster to meet YOUR needs, and need not be a
slave to any of the existing named templates (although it doesn't hurt
to learn about them and use them if appropriate).  It is foolish to
build a "true beowulf" if one really needs something closer to a compute
farm (another pre-GRID term:-), just as it is foolish to build a compute
farm if one really has to do something moderately fine grained and
require node predictability and network/access isolation.

The major point being that if you need two head nodes, or ten, don't let
the fact that the cluster you build won't be a "true beowulf" stop you
from building it that way.  When you're done, call it whatever you
like...;-)

The minor point being that you should FIRST look at your particular
task(s) and THEN decide on cluster architecture.  If your cluster is
going to be running fine grained synchronous code and you really want
the ease, convenience, power, and excellent support one can get by going
with a proper Scyld license (with Don Becker basically one of your many
personally accessible consultants:-) then you should probably conform to
the true beowulf paradigm and provide "multiheaded" access by logging
into the head node from multiple workstations on the external network
(which should be perfectly possible and reasonably convenient).  If
you're doing embarrassingly parallel monte carlo or simple master/slave
moderately coarse grained parallel (especially if it isn't synchronous
and you expect to support generations of systems in the same cluster)
then what they heck, put the dedicated cluster on a flat network with
all your workstations and load up gridware (or not -- you may just need
PVM and/or ssh and some scripts).

   rgb

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