Unsupported three-architecture cluster

First, thanks HP for not properly supporting this as you should have.
Makes the current situation just delightful.

Customer has a two-node LAN based cluster, Alpha and VAX. No shared
storage, all disks are local to one or the other. The Alpha is the
master node in voting and holds the authoritative SYSUAF, rightslist,
queue, etc shared files. The VAX keeps a local copy to boot
standalone or if coming up first to the point of waiting to form a
cluster.

They are adding an itanium. They are not removing the VAX. I know
its not supported but I also know it has worked in testing. Still LAN
based, still no shared storage.

The VAX is running the Process Software TCPware stack; the Alpha runs
the HP stack. Currently the VAX is at VMS V7.3, the Alpha at V8.2,
and the Itanium at V8.2-1. That is unlikely to change before summer.

I plan on keeping the Alpha as the 'master' node and keeper of the
shared files simply because of its excellent track record (actually
the old VAX has the best uptime but its pretty old/slow (3100-30).
Performance of the Itanium may make us move to it down the road but I
want it to run for a while before making it top node.

I've been refreshing on the cluster manual. Since we already have a
cluster most of the code needed to set up 'master' files and such is
in place, just needing tweaking for the new node. I'm also working
out the PQL parameters for each node.

Given the huge difference in account quota recommendations between the
three architectures, and the significant number of shared accounts
(user, system, tcpip, webserver, etc, most of which are shared between
either two or three nodes) will they be best served by leaving the UAF
account quotas at VAX levels and relying on the SYSGEN PQL settings
for the two newer nodes? That would severely restrict the ability to
customize account settings on the newer systems (not everyone on the
Alpha/itanium needs to run Java or Mozilla).

VAX usage is critical but not a lot of it goes on. PQL parameters
can't set MAX settings (which would be awfully useful in this
situation) but perhaps it would be better to use the Alpha as a
baseline for UAF quotas anyway. The accounts that do need to run Java
and Mozilla are not the ones generally used on the VAX (and we can
enforce that if need be) and baseline Alpha quotas do not need to be
overly large, so perhaps won't cause a problem for the VAX. That at
least gives us some leeway on the Alpha account quotas, though the
Itanium accounts will still end up one size fits all using PQL
parameters.

Thoughts appreciated. Thoughts about not putting all three
architectures up in the cluster noted but not helpful.

Thanks

Rich
.

Relevant Pages