 |
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.
|
|
|
|
|
