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