Re: Cluster computing drawbacks



"Stephen Fuld" <s.fuld@xxxxxxxxxxxxxxxxxxxx> writes:
> Is loosly coupled essentially a cluster? I thought that there was a
> distinction in that loosly coupled meanst shared DASD (disk to non-IBMers)
> wheras a cluster (in today's parlance) typically meant totally independent
> systems but with some I/O type interconnect. But not direct access to a
> common disk pool without going through another CPU. But I may be wrong in
> my terminology.

in the 60s they were mostly in the same data center with connectivity
to common i/o pool ... especially in availability configurations (and
because dasd/disk price/bit was quite expensive).. later availability
configurations over geographic distances became replicated/mirrored
data.

in any case, some amount of the driving factors for common i/o pool
was significant dasd/disk costs. at various points the disk business
unit pulled in more revenue than the processor/memory business unit.

some of the 60s scenarios may have made common i/o pool for
availability easier ... since 360 I/O channels had 200ft runs ... you
could place processor clusters in the center and then have 200ft
radius connectivity. this was increased with data streaming in the 70s
to 400ft runs (allowing 400ft radius) .... although some larger
installations found even this a limitation ... so there were some
datacenters that spread in 3d over multiple floors/stories.

possibly the first SAN was at ncar. disk/dasd pool managed by ibm
mainframe ... but also hyperchannel A515 adapters providing ibm
channel emulation access to other processors (having connection in the
hyperchannel environment). various processors in the complex (crays,
other processors) would communicate to ibm mainframe (control
channel). ibm mainframe would setup i/o transfer commands in the A515
.... and return a handle for the (a515) i/o commands to the requesting
processer. The requesting client (cray supercomputer) would then
invoke the A515 i/o commands for direct disk/dasd data transfer (using
the same i/o interconnect layer for separate control with ibm
mainframe and direct disk data transfer).

One of the reason for 3party transfer specification in HiPPI switch
specification ... was to be able to emulate the ncar hyperchannel
environemnt.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
.