HP StorageWorks SAN Virtualization Services Platform Best Practices Guide (5697-0935, May 2011)

SCSI flow control
The SCSI standard provides mechanisms for target devices to temporarily back off initiators. These
mechanisms are not available to SVSP because it is not an end point in the way it operates.
SVSP operations
There are some SVSP operations that require the breaking up of large commands, striping for
performance, or mirroring to multiple destinations. These operations take many resources and time,
and can slow down the processing of new commands by SVSP.
Dual SAN
SVSP is in a unique position by bridging two SANs; a front-end SAN and a back-end SAN. Devices
on a single SAN share the difficulties when the SAN is slow. This is especially apparent if the
back-end SAN is slow or is having problems. The front-end SAN users do not understand why the
SVSP is so slow.
Remedy
Control outstanding requests
Use SVSP HBA parameters to manage the number of outstanding commands they will queue to
SVSP targets or LUNs. See “Synchronous mirroring” (page 40) for guidance (even if the problem
is not associated with synchronous mirroring). This will dramatically improve both performance
and latency for customers that are experiencing problems due to issues listed above. See the
"Monitoring the SVSP domain" chapter in the HP StorageWorks SAN Virtualization Services
Platform Administrator Guide for information on how to monitor for dropped frames. See the HBA
vendor documentation for information about managing the queue depth.
Figure 20 (page 63) is an example of managing the queue depth. It is assumed that dropped
frames are a significant problem, average latencies greater than 10 ms and high maximum latencies
in the range of seconds are present, and there are significant spikes in the number of requests.
This flowchart is only an example because the values are dependent on the entire SAN load and
configuration, not just the SVSP load.
62 Remedies for SAN and SVSP issues