Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!ames!ptsfa!ihnp4!inuxc!iuvax!bsu-cs!jdh From: jdh@bsu-cs.UUCP (John Hiday) Newsgroups: comp.os.vms Subject: Re: Request for information on volume shadowing. Message-ID: <942@bsu-cs.UUCP> Date: Sat, 8-Aug-87 16:31:26 EDT Article-I.D.: bsu-cs.942 Posted: Sat Aug 8 16:31:26 1987 Date-Received: Sun, 9-Aug-87 12:14:13 EDT References: <8708080142.AA10031@jade.berkeley.edu> Reply-To: jdh@bsu-cs.UUCP (John Hiday) Organization: Ball State University UCS, Muncie, IN Lines: 76 In article <8708080142.AA10031@jade.berkeley.edu> HIGHAMP@BYUVAX.BITNET writes: >At the Signetics Orem plant, we've been shadowing our cluster system disk. > ... > >We were running six (yes, six) systems off of the same shadow set. >... Another limitation is that the "Cluster disk" cannot be on a shadow >set. ^^^^^^^^^^^^^^ I assume that you mean a quorum disk here. You stated before that you have six systems in your cluster. A quorum disk is only needed for small (2 or 3 VAXen) clusters. DEC recommends that you do not use a quorum disk on larger clusters. >Performance, particularly when considering the number of CPUs involved, >was outstanding.... Same here. We've been running 3 785s and an 8650 off of a two member shadow set for about 6 months now and the difference is great. We've had everything bailed of the system disk for some time now (since we have 18,000 accounts and SYSUAF is > 30,000 blocks long) so we didn't have to make any special effort to move files which are written to a lot. Towards the end of school this year due to a severe lack of user disk space the bean counters wanted us to stop using shadowing and stop "wasting" a disk which could be put to "real" use. So we stopped shadowing for a week let the systems grunt along the week before finals. Well after that they stopped bitching about the waste of a disk. Not only was the difference noticeable to most users, SPM proved that without shadowing the system disk could only complete about half as many I/O requests per second (so it does increase performance almost x 2). >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. The only shadowing related problems we have had are while booting. Since we shadowed the system disk, when booting the entire cluster at the same time there is always at least one, sometimes two of the 785s which get a device timeout when trying to bring up VMS. If you just try it again everything is OK. > >A couple of hints... > >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. No, no, no unless you want to sit back for about five minutes while the VAXes wait for the shadow set to stabilize. If the HSC hosting the shadow set dies it will take upwards of five minutes for it to failover to the other HSC and the dust to settle. Read the manual. This is only the way to go if you can stand to have your users hung up for a few minutes. Of course failing them over as normal, then adding the shadow copies back in later will also cause a severe performance hit during the ensuing shadow copy. Normally a shadow copy will take 20 minites or so when the system isn't too busy. However we have had the misfortune in the past of trying to add the second member while the system is very busy. Beleive me don't try it. We let it go for about 2 hours before finally killing the shadow copy. It really drug the system down during the copy too. >There is some lag at boot time, as the master disk is copied via HSC to >the slave. You may already be doing it, but the best solution to this is to delay mounting the second member of the set until the last thing. If you do it at the beginning of startup you've got the shadow copy pounding the disk contending with the startup process. -- == John Hiday UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!jdh == Ball State University / University Computing Services GEnie: JDHIDAY == Muncie, IN 47306