Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!BYUVAX.BITNET!HIGHAMP
From: HIGHAMP@BYUVAX.BITNET
Newsgroups: comp.os.vms
Subject: RE: Request for information on volume shadowing.
Message-ID: <8708080142.AA10031@jade.berkeley.edu>
Date: Fri, 7-Aug-87 20:23:00 EDT
Article-I.D.: jade.8708080142.AA10031
Posted: Fri Aug  7 20:23:00 1987
Date-Received: Sun, 9-Aug-87 08:32:18 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 86

At the Signetics Orem plant, we've been shadowing our cluster system disk.
This last week, we stopped shadowing for a number of reasons.

We were running six (yes, six) systems off of the same shadow set.  The
shadow set consisted of two (the limit currently _supported_ by DEC) RA81's.
Why they limit you to two is something of a mystery, since their gurus at
a recent DECUS regional meet were boasting about how great the performance
was with three drives.  Another limitation is that the "Cluster disk" cannot
be on a shadow set.

The main problem with volume shadowing is writes.  The heads can read different
parts of the disk nicely, but they have to synch when they write.  We got
around this by moving certain files (SYSUAF.DAT, ACCOUNTNG.DAT, JBCSYSQUE.DAT,
etc.) to seperate disks.  We also made sure that the page and swap files
went elsewhere.  DEC was unwilling to give their blessing to moving the
operator log.

Performance, particularly when considering the number of CPUs involved,
was outstanding.  We occasionally experienced some contention, and our FE
complained about the number of collisions showing up in the error log, but
the ease of maintenance more that made up for these infrequent problems.

We stopped because of a probably unrelated hang up on our pair of HSC50s.
They kept passing the buck to each other.  I wasn't there at the time, but
we have conjectured that the second shadow volume may have somehow faulted
to an HSC other than the one that the shadow master was on.  This doesn't
work...

DEC hardware folks complain that you cannot reliably have more than three
systems on a single system disk.  They may be right.  Aside from the one
crash which may or not have been related to shadowing, we saw reasonable
success.

After discussing the problem with the Colo Springs shadowing group, we are
inclined to think that the problem was something of a fluke.  They were
quick to point out the the read optimization (sp?) performed by the shadowing
software, combined with our relocation of files that take a lot of writes
should have really made the disks fly.  They also mentioned that there must
be some reason why you can have sys0 thru sysf (minus one).  I guess the
only doubt is whether or not the hardware can handle it.

I suppose what I am trying to say in my long winded way is:  GO FOR IT!
We had a great time.

Just remember that DEC suggests no more than 40% writes to a database disks.
I personally doubt that you will see a satisfactory upgrade in performance
with this high a ratio of writes to reads.

A couple of hints...

We were running version 1.0, and have seen references to version 1.2, so
maybe it runs even better now ;-)

If you want to have fun, and have an HSC, you can do an HSC copy disk to
disk, and create a temporary shadow set.  It seems to use the same function
as the shadowing sofware, and will show up as a shadow set during the copy.

If you like faulting from one HSC to the other, don't do the shadow disks
seperate from one another.  You'll likely lose the shadow "slave".  Just
init the HSC.

There are no error references supplied in vol. 4 of the the VMS doc set
for shadowing problems.  There were also none in our shadowing manual.
It may be that this oversight has been corrected in recent revisions.

It is VERY difficult to nail DEC down on shadowing.  Their people obviously
like it, but the disagreements between the folks at hardware and the good
people at software were cause of some anxiety.  There simply don't seem
to be very many sites using shadowing.

We stopped only because of political reasons.  The ease of maintenance and
security of a "backup" system disk were worth the pain.

The only difference between a shadowed disk and a regular one is one quadword
that contains the last shadow set creation date.  If you mount the disk
/OVERRIDE=SHADOW, this quadword is cleared, and you have a normal disk again.

There is some lag at boot time, as the master disk is copied via HSC to
the slave.

Good luck, and have fun...

Dave Higham
System Programmer
Signetics Corp.
Orem, Utah