HP StorageWorks SAN Virtualization Services Platform Best Practices Guide (5697-0935, May 2011)
13 Monitoring the SVSP environment
The SVSP environment can be complex, and research into proper sizing is still ongoing, making
it difficult to assess when configuration changes, additional quads, DPMs, or domains are needed
to process the load. Monitoring of system health should be a part of any SAN, but as configurations
approach the SVSP limits, it is important to monitor the system more closely. HP recommends that
you first monitor for errors (using some of the tools listed below) in the environment, and then if
the SAN is clean, monitor for performance. Errors in the SAN can lead to performance problems,
but errors could also be unrelated to SVSP performance. High latency with applications may be
seen as a result of SVSP struggling to keep up with the work.
Where to start monitoring
Based upon SVSP field experience, there are several areas that should be explored initially if
problems are suspected.
• ISL between switches—There are several areas in this guide that mention best practices for
designing and provisioning an ISL. To monitor an ISL, establish usage alerts on the switch
ports. See the switch specific mechanisms for setting up alerts.
• Traffic pattern—When SVSP is introduced to the SAN environment, traffic patterns are changed,
and some links without errors before SVSP was introduced, may experience a higher level of
problems because of the increase in load.
• Switch buffers—In some configurations and loads, SVSP holds onto switch buffers longer and
the fabric might need additional buffers (see switch manufacturer), or it may be necessary to
reduce the I/O load (see “Synchronous mirroring” (page 40)). Many of the reasons for
discarded frames in the fabric may be due to an improperly sized SVSP configuration. Because
SVSP does not have non-volatile cache it must hold onto fabric buffers until the command is
complete. This is typically not a problem, but for large transfer requests and synchronous
mirroring, SVSP must perform a fair amount of work before it can return buffers. Correctly
sizing SVSP so that it has enough processing power will ease the situation.
• Work load concentration—SVSP relies on the back-end arrays to handle the I/O workload.
The virtual disk management capabilities permit focusing the workload of multiple front-end
virtual disks onto one back-end virtual disk array or path. Careful design and monitoring are
required to ensure that any of these are not running too close to saturation. Following the
storage pool configuration best practices is the first step in avoiding this problem. Monitoring
the array performance is the second step. Components operating too close to saturation (as
defined by the vendor) should be migrated to components with spare capacity and
performance. Array-based tools, like EVAPerf for the EVA, should be used to monitor the load
on back-end physical LUs and the array. Unless specifically conducting stress testing, SAN
components should not be run "in the red zone" and should be 80% or less loaded during
normal testing. If maintaining performance is critical during a component failure, this number
may be closer to 40%.
• Health monitoring SVSP (see the HP StorageWorks SAN Virtualization Services Platform
Administrator Guide for specifics):
◦ VSM GUI
◦ VSM event logs
◦ Alerts—In addition to using the VSM GUI to manually monitor the VSM system, you can
configure the VSM to provide alerts. The VSM system includes an automated alert feature.
You can configure the VSM to send alerts for specific events to an e-mail address or to
syslog servers.
◦ DPM SNMP traps
Where to start monitoring 53