  Cluster Path Selection, DSSI Bandwidth? 
 The Question is:
 
We have a cluster consisting of a VAX 4705A and a VAX 7740.  They are
 interconnected by 4 DSSI busses, each from a separate controller.  Two of the
 DSSI busses each have a single HSD30 controller with all the shared disk
 volumes.  Each disk volume from on
e HSD30 is shadowed to a corresponding volume on the other HSD30.  Our problem
 is that occasionally the VAXcluster locking traffic gets moved onto a DSSI
 circuit path that also supports one of the HSD30 controllers.  This causes a
 significant performance
degredation.  It seems most likely to occur when one of the machines re-joins
 the cluster after leaving the cluster suddenly (via a "crash" or power-fail.
We can force the vaxcluster/lock traffic to be re-allocated onto one of the
 unused DSSI channels by running simultaneous backups to a TZ87 tape drive in
 each HSD30 controller.  Why does the vaxcluster/lock manager traffic get
 allocated to a disk-intensive
 DSSI buss?  Is there some patch to resolve this issue?  Is there an easier way
 to cause the DSSI traffic to be re-balanced?
 
 The Answer is :
 
  DSSI is roughly analogous to SCSI-1 in its performance, with a peak
  bandwidth of approximately four megabytes per second.
 
  Fast-wide (FW) SCSI-2 bandwidth is approximately twenty megabytes
  per second.  First-generation UltraSCSI provides roughly forty
  megabytes per second. More current UltraSCSI generations have yet
  higher bandwidth ratings.
 
  Aggregate HSD30 bandwith is approximately four megabytes per
  second.
 
  Recent OpenVMS Alpha systems provide read-costing capabilities for
  shadowing, as well as improvements to the path selection processing.
  V7.3-1 also includes greatly improved lock remastering capabilities.
 
  Within OpenVMS versions as old as this OpenVMS VAX V6.2 cluster
  configuration, SCS path utilization was not a particularly large
  consideration within the path selection algorithms.
 
  Realize that there are two levels of path choice here, the MSCP
  (disk) path choice and the lower-level SCS (cluster) path choice.
 
  A static series of SCS path selection choices was implemented, and
  within the group  of functioning cluster communications paths of the
  same rating, the particular path initially chosen is not deterministic.
 
  That said, OpenVMS VAX V6.1 (and later OpenVMS VAX versions) will
  dynamically attempt to re-route the SCS connection if the current
  SCS path is overloaded, and if the path hasn't recently been relocated.
  This latter check is intended to prevent cases of cluster saturation
  leading to excessive circuit re-selection; to path flailing.  Further,
  the cluster software will not re-route an overloaded path if moving
  the traffic will likely overload the target path.
 
  On a configuration this old, the current manual path selection
  process is probably the best available option; starting and stopping
  DSSI busses using tools from SYS$EXAMPLES:.  Either the preferred
  path selection for the MSCP path selection process, or the *BUS*
  tools used to entirely start or stop the SCS communications path,
  or both.
 
  Most any newer OpenVMS Alpha system (or OpenVMS on Itanium, as
  that becomes available) will greatly exceed the complete aggregate
  capabilities of this particular DSSI VAX cluster configuration.
  Processor performance, I/O bandwidth, disk storage capabilities
  and other relevent factors have all seen significant increases.
 
 Answer written or last revised on  21-NOV-2002 
