Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.9 3/12/85; site unisoft.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!tektronix!hplabs!intelca!qantel!dual!unisoft!pc
From: pc@unisoft.UUCP (n)
Newsgroups: net.unix-wizards,net.unix
Subject: Re: VAXclusters and UN*X
Message-ID: <479@unisoft.UUCP>
Date: Wed, 5-Jun-85 11:50:39 EDT
Article-I.D.: unisoft.479
Posted: Wed Jun  5 11:50:39 1985
Date-Received: Tue, 11-Jun-85 03:11:15 EDT
References: <208@uwvax.UUCP> <6211@umcp-cs.UUCP>
Distribution: net
Organization: UniSoft Systems, Berkeley
Lines: 38
Xref: watmath net.unix-wizards:13487 net.unix:4761

<munch>

	I went to a DEC presentation of how their Vax Clusters run under VMS
over a year ago. It goes somewhat like this. 

	The hardware connects upto 16 Vaxes and HSC50s (pdp11s controlling
lots of disk/tape as servers) the servers take care of logical to physical
translations (to the clients the disks are acontiguous defect free array
of blocks). The VMS systems take care of file system management, they run
a distributed heirarchical lock manager between to controll access to the
shared file systems (VMS does not buffer blocks in core in the same way that
Unix does), it is possible to lock at both a file and record level. When a
system goes down all the other systems compare notes, see who has which
locks outstanding and put the shared database in a good state. Again the
disk servers have no part in this they only provide blocks. Their are
several protocols involved. The one to the HSC50s for IO (also vax systems
may provide their own MSCP servers so that other people may access local
disks, at some overhead of course), a lock protocol, (very fast, only needs
one reply ... at 70MHz, dual ported) and DECNet. Note these protocols share
a common physical medium but are separate (nothing rides on top of DECNet) and
the HSC50 doesn't understand DECNet, DECNet is there for remote log throug and
system management (plus the fact that only one node on a cluster need be 
connected to an internet). One good thing about what DEC had to do to get
this running was that they did away with the cumbersome ACPs (disk structure
daemons) hooray!! Most of the synchronisation is in RMS as that is where the
buffering is. All the above is embodied in VMS4.0 and presumably runs
. . . especially considering the time it took them to get it out the door!!

	Anyway that is what I know about VMS VaxClusters, some of this may
have changed since I talked to the DEC people about it, potentially it is
a very cheap way to add more CPU power without spending big

	(I have no connection to DEC apart from being involved in buying
a VaxCluster for my previous employer ...)


		Paul Campbell		..!ucbvax!unisoft!paul