Article 171517 of comp.os.vms:
In article <3399D946.6B62@us.ibm.com>, Greg Pfister <pfister@us.ibm.com> writes:
> Glenn C. Everhart wrote:
>> 
>> Running a copy of the OS per machine is not what's unique about Galaxy.
>> You need however to consider more of the problem space to understand
>> the benefits. Real loads require the ability to do I/O as well as
>> computes, and the ability to have OS services. Clustering provides a way
>> to do simultaneous I/O from all over the cluster, without causing
>> data corruption. Only OpenVMS has this; the other things called clusters
>> are IMO misappropriating the name. You can prevent data corruption by
>> having a server make storage available to a network too, and at low
>> loads it can look very like a cluster. However such a thing runs out of
>> gas when the server can't manage the load any more; it acts as a bottleneck.
> 
> I believe I detect a tad of overgeneralizing without adequate data. 
> Suggested cure: Take a long look at IBM's S/390 Parallel Sysplex, as
> well as other approaches to doing clustering.
> 

	Galaxies is about running multiple copies of the OS in a single 
	machine (for example, 8 copies running with 4 CPUs per copy inside a 
	Wildfire).

	Parallel Sysplex allows up to 32 computers running MVS to
	share data using a Coupling Facility that itself would be a bottleneck.
	It does however allow for locking across the "cluster". 

http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/books/E0S1P103/2.1.2.4

	But why the necessity of a Coupling Facility??  Why not a true
	Distributed Lock Manager?  That way as MUCH faster communication
	among the clusters becomes possible (especially if they are in
	the same cabinet ;-) lock traffic becomes a non-issue.  That
	Coupling Facility is little more than a glorified Memory Channel
	Interconnect.

	Also, workloads are assigned to specific engines in the Sysplex.
	So?  Why not do like Galaxies?  As one of your clusters gets
	CPU saturated, add another!  Load balance CPUs.  How does that
	work in a Sysplex???  Galaxies seems to say "let the workload go where 
	it may, the system will handle it no matter what node it runs on."

> Parallel Sysplex has just about everything you mention, and probably
                                                          ^^^^^^^^^^^^
> more.  This includes the ability to do just-as-real I/O as you're
  ^^^^

	Actually, a lot less.

> mentioning (I absolutely agree it's very important) across multiple
> machines, very efficiently, with very good scaleup for hard (heavy
> write, transaction) workloads.  This comes complete with policy-driven
> workload management which redistributes things automatically in the case
> of a failure.  
> 

	For how many nodes?  IBM is stating 1.8 scale when one node
	is added to another.  Would IBM be willing to say that as you
	go from your 7th 390 to 8th 390 in the Sysplex you get scaling just
	as good??

	When Galaxies rolls out TPC-D and TPC-C and the new 1998 TPC-? whatever... 
	click on http://www.tpc.org/ to get the WOW effect.  We would love to 
	see some Parallel Sysplex numbers.  But then again, you would claim 
	this is about very large, very scalable, mission critical, yada yada 
	yada.  I believe Galaxies will say hello to that.  In fact, I am
	willing to bet Galaxies scales considerably higher.  Willing to 
	post some TPC-D or TPC-C numbers??? 

	Where Sysplex ends Galaxies just begins.

	Can one member of a Sysplex directly access memory of another member?
	No, they can read and write across the Coupling Facility.

	Wouldn't be much of a stretch to imagine 8 or so Wildfires connected to 
	each other.  How else to directly read memory from each other?  Go
	through a Memory Channel Interconnect?  Wouldn't that be somewhat 
	limiting (avoid it if possible)?   Someone strongly hinted of a
	memory sharing API that allows such a thing ;-).

	By the way:

> as well as other approaches to doing clustering.

	What might they be?

				Rob