|
HP OpenVMS Systemsask the wizard |
|
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).
|