[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

571.0. "System disk shadowing "not recommended"?" by PGREEN::GRAVESG (Geoff Graves, Global Knowledge Network (UK)) Wed May 07 1997 06:49

    Just had two customers, from completely different companies in
    different countries, tell me that "Digital recommended they did not
    shadow their system disks becuase of problems". Neither of them can
    tell me what the "problems" were and in both cases, they were told this
    "a couple of years ago".
    
    I know this is a bit vague, but am I missing something here about what
    is recommended, or not, by Digital?
    
    Geoff
T.RTitleUserPersonal
Name		DateLines
571.1UTURBO::utojvdbu1.uto.dec.com::JurVanDerBurgChange mode to Panic!Wed May 07 1997 09:514
Rubbish. System disk shadowing works fine.

Jur.
571.2Confused Customer?XDELTA::HOFFMANSteve, OpenVMS EngineeringWed May 07 1997 10:516
  If the customer uses the system disk as the quorum disk, this is correct
  advice -- the quorum disk cannot be shadowed.  We have also traditionally
  recommended against configuring the system disk as a volume set, though a
  volume set is quite different from a shadow set.
571.3Whoever recomended that was wrong.CSC32::B_HIBBERTWhen in doubt, PANICWed May 07 1997 11:0729
    The only "problems" with shadowing a system disk had to do with dump
    file syncronisation.  These problems would NOT cause any operational
    problems with the system, just problems reading a crash dump file after
    a crash.  These problems have been fixed in recent versions of VMS.
    
    Shadowing not only works on system disks, but I would recomend it.
    System disks tend to be read intensive so shadowing will probably
    improve performance (even though that is not the goal of shadowing).
    Shadowing will improve availability and reduce downtimes in the case of
    a single system disk failure (this is the primary goal of shadowing).
    
    There are configurations where the locations of the shadowed disks put
    limitations on system disk shadow sets, perhaps this is what caused the
    confusion.  A system needs to have equal access to all the drives on
    the system shadow set, or you can get into an unbootable situation. 
    For example, if you have a locally connected member of the shadow set
    and one that is served from another system and your system is shut
    down your system will not be able to reboot off the local disk until
    the remote node is shut down or dismounts the other shadowed disk.
    The reason is that the remote node will have a more current copy of the
    shadow set than the local node.  When the local node attempts to
    reform it will find that the remote node already has the drive mounted
    and the local node will crash with a SHADBOOTFAIL due to booting off a
    stale shadow set member.  The solution is not to configure the system
    disk shadow sets this way.
    
    Brian Hibbert
571.4Thanks for confirmationPGREEN::GRAVESGGeoff Graves, Global Knowledge Network (UK)Wed May 07 1997 11:369
    Re .-*
    
    Thanks for confirming what I thought - the customers have been
    ill-advised in the past but I'll put them straight.
    
    Cheers,
    
    Geoff
571.5EVMS::MORONEYvi vi vi - Editor of the BeastWed May 07 1997 12:504
In addition, shadowing has been substantially reworked for V7.1 (and the
"Redhawk" 6.2 kit) so "problems" of a few years ago aren't relevant.

-Mike
571.6use DSAx:, *not* DUSx: !!CUJO::SAMPSONThu May 08 1997 03:342
    ...and, they should move from Phase I (controller-based)
    to Phase II (host-based) shadowing, if they haven't already...