I've have a couple of Alphastation 200s that I've played with in this manner as well.
In terms of basic steps, you'll be doing this:
Make sure all 3 are connected to the same LAN.
At this point, all 3 systems have their own system disks, so as you put them into a cluster, they will all 3 will be "boot members" and not satellite nodes.
You will run CLUSTER_CONFIG.COM on each node. Tell it you'll be enabling the LAN for cluster communications, and use the same value for cluster group number and cluster password on all 3 nodes. If you wish, you can enable serving of disks and/or tape drives between machines. CLUSTER_CONFIG.COM adds lines to MODPARAMS.DAT for you. After an AUTOGEN run and a reboot for each node, you'll have a cluster of 3 nodes.
After that point, you may want to play around some more. It is often handy to have a single copy of system files like SYSUAF, RIGHTSLIST, etc. for the entire cluster, so you see the same environment as a user regardless of which node you log in to, and when you change passwords, it gets changed once for all nodes. You can point to a cluster-common version of files using logical names in SYLOGICALS.COM.
You could boot a couple of systems from the third node's system disk by setting them up as satellite nodes and booting over the network instead of booting form a local disk. This would allow you to upgrade VMS once for all 3 nodes, instead of once per node, but does introduce a dependency of the satellite nodes on the boot node.
That might also free up disk drives so you could shadow a couple of them for higher availability. (But to do this, you'd need to put a disk allocation class on each node using the ALLOCLASS paramter, since host-based Volume Shadowing requires that.)
You might consider tying a couple of your Alphastation 200s together in a multi-host SCSI configuration, so the disks are accessible from either system, for higher availability. (Simply connecting a short SCSI cable between the integrated SCSI ports works, in my experience, but be careful that all SCSI IDs, including that of the host SCSI ports (set at SRM level using console environment variables), are different. You could also connect a pair of systems to an external StorageWorks BA350 box, but be sure to keep the cables short since you're dealing with Single-Ended SCSI here. (And no tape drives are allowed on this shared bus, as a SCSI Reset from either system would rewind the tape, and that could happen at an inopportune time.)
With such high-availabilty access to the shared SCSI disks, including the system disk, you could then boot the 3rd node from the other 2 as a satellite node and it could continue running even if either boot node were down.
Have fun!
