HP3000-L Archives

April 2003, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lars Appel <[log in to unmask]>
Reply To:
Lars Appel <[log in to unmask]>
Date:
Wed, 16 Apr 2003 08:34:37 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
Dane wondered...

> How reliable is Cluster /iX and how long has it been around ??

I don't have a lot of practical experience with it (due to lack of
appropriate "toy equipment" like 2 hp3000 systems, dual ported disc
arrays like XP, etc ;-) so I cannot tell any -ahem- war stories.

I believe that it was introduced in the MPE/iX 6.5 timeframe. Guy
already shared the hyperlink to the manual as far as I noticed.

When I once had a chance to try Cluster/iX it looked pretty simple
and straightforward to setup and use. Much simpler than SharePlex,
for example, but this is most likeley due to it's much simpler and
more "restricted" design/nature.

It simply allows to "switch" user volume set "ownership" from one
to another 3000 in case of emergency. Just like unplugging the disc
drives from one machine and plugging them to the other. In case of
Cluster/iX you have the dual ported array "wired" to both systems
and just set an "ownership" field in the volume set label on disc.

The nice thing about the "software control" is that you can even do
that remotely (eg via dial up) whereas physical unplug/plug would
need someone onsite.

One potential gotcha... Someone might decide to have the second 3000
"take over" the volume set while the other 3000 is not really "dead"
and I suspect that by doing so, you could end up in both boxes trying
to write to the discs at the same time (in uncoordinated fashion).

Other than that it seems pretty straightforward to me.

However, as Guy already mentioned, it does not do any kind of shadow
replication or grant access to the same data from both systems at the
same time. It simply helps to protect against SPU outages because it
allows another SPU to take over the volume set for new user access.

It does require that you setup account structures properly on both
systems, so that the "fail over" machine can actually "see" the user
set (i.e. it needs current NEWGROUP;HOMEVS= in place -- unless you
bring a current BULDJOB# pair with you on the user set itself).

Cheers, Lars.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2