HP OpenVMS Systems

Clusters, Locking, and Application Failover?

» close window

The Question is:

 
My application runs in a VMS Cluster consisting of 2 nodes.  The app has its
 own "failover" processes which use a middleware product for the interprocess
 communicaion between the 2 Failover Managers (one on each node).  The
 middleware product uses the net
work.  When a network problem occurs, both Failover Managers assume that their
 partner node is down, when in fact the node is ok, it's the network that's down.
 
Is there a means of interprocess communication in a VMS cluster that does not
 use the network?
 
 

The Answer is :

 
  If you have a two-node OpenVMS Cluster, you must have a quorum disk,
  or you must have a primary-secondary configuration, or you must add
  a third node.  Please see the OpenVMS FAQ for details of the VOTES
  and EXPECTED_VOTES system parameter settings.
 
  You do not indicate the particular cluster configuration -- there
  are configurations that use the same Ethernet or FDDI network that
  you seem to be having problems with, and there are configurations
 
  Interestingly, that your two failover managers continued to operate
  indicates this was a network protocol or routing failure, or that
  there is an additional interconnect between these two cluster nodes.
  (Had the cluster been partitioned, one or both of the nodes would
  have paused pending quorum.)
 
  That said, you will want to examine the use and operation of the
  distributed lock manager (DLM), as the DLM is the component that
  is specifically targeted at this class of problem.  Using the DLM,
  an application can be designed to permit exactly one and only one
  process to hold a particular resource name, and the holder of this
  lock resource will be assumed to be the primary.  For details on
  uses of the DLM please see the OpenVMS Programming Concepts Manual.
 
  Please note: the DLM is the mechanism that supports synchronization
  of the file system.  The DLM is designed to be capable of synchronizing
  completely arbitrary activities among any cooperating applications.
 
  OpenVMS VV7.2 and later IntraCluster Communications Services (ICC),
  which allows a user process directly communicate via the Systems
  Communications Services (SCS) protocols used within an OpenVMS
  Cluster.
 
  With OpenVMS V5.0 and later, the peer node status can be determined
  using $GETSYI and the state of the peer process(es) can be determine
  using $GETJPI.  With more recent OpenVMS versions (V7.*), you can
  request notifications of arriving and departing cluster members using
  the cluster event services ($SETCLUEVT, etc).
 

  

     

     
answer written or last revised on ( 12-MAR-2001 )
     
» close window