Re: Unsupported three-architecture cluster
- From: Rich Jordan <jordan@xxxxxxxxxxx>
- Date: Mon, 31 Dec 2007 14:12:49 -0800 (PST)
On Dec 31, 1:28 pm, Bob Gezelter <gezel...@xxxxxxxxx> wrote:
On Dec 31, 1:18 pm, Rich Jordan <jor...@xxxxxxxxxxx> wrote:
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
Rich,
Using the PQL settings to set MINIMUM parameters is certainly useful,
as is looking at whether it is safe to raise parameters such as
CHANNELCNT on all of the systems.
For situations where accounts are used, consider the fact that while
it is normal practice for there to be one Account Name PER UIC, this
is by no means mandatory. Also note that quotas and related settings
are by Account Name, not by UIC (Protection, on the other hand IS by
UIC).
I would seriously take a look at using different account Names on the
different nodes for the situations are different. I would consider
creating a separate (for efficiency reasons) logical name table, not
in the normal search path, that would store this information. Then
each reference need only include a reference to the logical name using
F$TRNLNM.
Please let me know if I am not sufficiently clear.
- Bob Gezelter,http://www.rlgsc.com
Bob,
I'm afraid the customer will insist on a single username across
the cluster. They won't want to maintain multiple passwords in any
case which is why we're aiming at a single SYSUAF file.
Thanks for the input!
Rich
.
- References:
- Unsupported three-architecture cluster
- From: Rich Jordan
- Re: Unsupported three-architecture cluster
- From: Bob Gezelter
- Unsupported three-architecture cluster
- Prev by Date: Re: FLIST Installation and Setup
- Previous by thread: Re: Unsupported three-architecture cluster
- Index(es):
Relevant Pages
|